Google Talk recently joined the open XMPP (Jabber) federation so their users can now message users on any of the other open networks including the one I'm running (dl.nibble.bz). Bitchin! I dropped my Google Talk login and added all my contacts to my own login. So far, there's been no problems. Anyone with compatible clients will be able to any of the (pseudo) peer-to-peer stuff like voice and video. That includes multi-platform clients like... Well it's coming. Gaim has been working hard to introduce voice and video (vv) based on Google's technology and Gaim expects to be able to interoperate across platforms and domains very soon. We're all very excited at the possibility :D
In other "old" news, my luck has been holding with KDE and KDE PIM (Personal Information Management). I have been saving my calendar and contacts as files on a USB key and it works great! I just plug in the key, point KMail at the calendar and contact files on there and *bam* it works!
The other thing with mail is managing filters. Well it turns out KMail doesn't let me filter messages to IMAP folders (at least with the versions I have installed) so I ended up looking at Procmail which runs on the server side. A bit of poking around and it actually works really well! A little bit obtuse to be doing just text-based configs with yet another file format, but it's fairly simple and does the job and naturally no filters need "synching" on the client-side.
The one last issue is that I want to maintain a unified list of syndicated feeds. I can manually export/import my feed list with aKgregator (which is a good RSS/Atom client btw) but it's hardly unified. Oh well.
Tuesday, 31 January 2006
Friday, 20 January 2006
Syslog: Good for info, good for DOS attacks
So after getting some odd complaints from the mail server this morning about "insufficient space", I had to take a closer look at Siona's var partition which was appearing to fluctuate by ~600MB per day. A quick du -sh * pointed to /var/log being the culprit.
So on first inspection, the mysql-bin logs were not being compressed. A gzip on the old logs there gave a couple hundred megs back. Not a world of difference, but a lot.
Next up, it turns out that syslog.0 and debug.0 were over 300MB each and today's syslog/debug were already over 10MB (having been just rotated). So I take a quick look and I see the usual chatter from various services... But it turns out that "the usual chatter" from slapd was 99.96% of the log. Other then enabling it for debugging, I've never found the stuff getting logged to be especially useful to have around so I've disabled that. It was recording a half dozen lines every time PAM or NSS wanted user info (e.g. perpetually).
In summary, the Squid cache (256MB) didn't make the top 3 disk usage problems under var. It was Syslog that was doing a DOS attack.
So on first inspection, the mysql-bin logs were not being compressed. A gzip on the old logs there gave a couple hundred megs back. Not a world of difference, but a lot.
Next up, it turns out that syslog.0 and debug.0 were over 300MB each and today's syslog/debug were already over 10MB (having been just rotated). So I take a quick look and I see the usual chatter from various services... But it turns out that "the usual chatter" from slapd was 99.96% of the log. Other then enabling it for debugging, I've never found the stuff getting logged to be especially useful to have around so I've disabled that. It was recording a half dozen lines every time PAM or NSS wanted user info (e.g. perpetually).
In summary, the Squid cache (256MB) didn't make the top 3 disk usage problems under var. It was Syslog that was doing a DOS attack.
Wednesday, 11 January 2006
Gateways and KDE
I finally got around to installing protocol gateways on the Jabber server. It was far easier then I expected. I downloaded and ran PyMSN-t and PyICQ-t and that was that. A couple config file options needed to be set for the gateways, a couple on the Jabber server, and away we go. I was able to "discover" the gateways with Psi very easily and that was it. Pretty handy stuff.
The other adventure was migrating to KDE. After much poking and frustration with various services to get a functional integration of my address book and get a working calendar going, I ended up going with KDE. I'm not too sure how well this will go since I do have to give up on the cross-platform aspect, but we'll go with it for now. I might have to adopt some different storage method but KMail is very versatile in that regard so it may work well on the client side if nothing else.
I have been reluctant to adopt WebDAV as a storage method for the calendar and I don't want to go so far as installing a fully web-based groupware environment. Web-based stuff just seems to fall short on usability and security. Then again, maybe I just need to tighten up the web-access. Now I'm ranting... Must be time to finish my coffee.
The other adventure was migrating to KDE. After much poking and frustration with various services to get a functional integration of my address book and get a working calendar going, I ended up going with KDE. I'm not too sure how well this will go since I do have to give up on the cross-platform aspect, but we'll go with it for now. I might have to adopt some different storage method but KMail is very versatile in that regard so it may work well on the client side if nothing else.
I have been reluctant to adopt WebDAV as a storage method for the calendar and I don't want to go so far as installing a fully web-based groupware environment. Web-based stuff just seems to fall short on usability and security. Then again, maybe I just need to tighten up the web-access. Now I'm ranting... Must be time to finish my coffee.
Monday, 2 January 2006
Python is n337!
Ah, the festive season. Time for friends and family. Lots of that, not a lot of computer stuff in the last couple weeks. I have been doodling with Python a bit though. It sure does make strapping together scripts very easy. The is enough versitility in the language itself and the plethora of available modules that many scripts are quite simple (e.g. short). In writing code to interact with a database and the local filesystem, I was able to test the scripts by executing the code, including exception handling, in an interactive session. 40 lines will go a long way in Python which is really nice. And it is easy to make it legible, unlike you, Perl.
Enough about that, I'm going back to poking stuff with sticks.
Enough about that, I'm going back to poking stuff with sticks.
Monday, 19 December 2005
Spam + Cacti + Wildfire = Software Sammich
It turns out that I was more then a little confused on how SMTP AUTH/SASL worked. Now I have no idea how to get that going... Ugh!
On the other hand, I did get something actually working for Spam/virus filtering. Turns out AMaVIS is a handy scanner that includes spam filtering and will run external spam filtering and virus filtering. I was able to hook AMaVIS in to the mail system to scan spam and ClamAV into AMaVIS to combine the scanning on that front too. So far, it is already tossing out spam, yay! It is supposed to be assigning a score to all mail but I'm not too sure where that is at... Anyhow, it is throwing spam out so I probably just need to do some tuning.
In other messaging news, of the instant type, Jive Messenger released version 2.4.0 including a new name: Wildfire. I've upgraded the Jabber server from Messenger 2.3.1 to Wildfire 2.4.0. Always good to see great projects remaining active. Gaim 1.5 still doesn't work with it (TLS issue of some sort still) but Gaim just announced their 2.0 beta. I haven't tried that yet but I doubt I'll get to it until the stable release what with the holidays and such.
The last interesting tidbit is that I installed Cacti from package on Siona. I just added Siona and Friday in there and so far so good. Check it out and login as username "guest" password "password". I like this tool...
For upcoming plans, I'm still sorting out some of the domain and hosting issues leftover from Nikita's passing. Not too tricky, but we just have to get some stuff cleaned up. Mmm also syndicating news. Possibly giving up on my hand-written news doodad and switching to something with features, like WordPress. Who knows? Stranger things have happened.
On the other hand, I did get something actually working for Spam/virus filtering. Turns out AMaVIS is a handy scanner that includes spam filtering and will run external spam filtering and virus filtering. I was able to hook AMaVIS in to the mail system to scan spam and ClamAV into AMaVIS to combine the scanning on that front too. So far, it is already tossing out spam, yay! It is supposed to be assigning a score to all mail but I'm not too sure where that is at... Anyhow, it is throwing spam out so I probably just need to do some tuning.
In other messaging news, of the instant type, Jive Messenger released version 2.4.0 including a new name: Wildfire. I've upgraded the Jabber server from Messenger 2.3.1 to Wildfire 2.4.0. Always good to see great projects remaining active. Gaim 1.5 still doesn't work with it (TLS issue of some sort still) but Gaim just announced their 2.0 beta. I haven't tried that yet but I doubt I'll get to it until the stable release what with the holidays and such.
The last interesting tidbit is that I installed Cacti from package on Siona. I just added Siona and Friday in there and so far so good. Check it out and login as username "guest" password "password". I like this tool...
For upcoming plans, I'm still sorting out some of the domain and hosting issues leftover from Nikita's passing. Not too tricky, but we just have to get some stuff cleaned up. Mmm also syndicating news. Possibly giving up on my hand-written news doodad and switching to something with features, like WordPress. Who knows? Stranger things have happened.
Tuesday, 6 December 2005
Goodbye, Nikita
Nikita has officially passed on. May she find peace in Computer Heaven where all good computers go if they have led a long and happy life which Nikita certainly had. She first started out as workstation ion 1997 with few aspirations other then to run a word processor, a browser, and a couple of games.
In her life, Nikita was able to overcome this humble life of low-speed network links and buggy office applications to become a webserver on a high speed connection, eventually as high as dual-OC3's with failovers. In her last days, she served as a primary DNS server and mail host for a lucky group of friends.
It was on a quiet Sunday in December when the power went out. Her health had been failing but this was the last power failure for her. She passed quietly idling and is in a better place now.
Nikita
Rest In Peace
~1997 - December 6, 2005
In her life, Nikita was able to overcome this humble life of low-speed network links and buggy office applications to become a webserver on a high speed connection, eventually as high as dual-OC3's with failovers. In her last days, she served as a primary DNS server and mail host for a lucky group of friends.
It was on a quiet Sunday in December when the power went out. Her health had been failing but this was the last power failure for her. She passed quietly idling and is in a better place now.
Nikita
Rest In Peace
~1997 - December 6, 2005
Monday, 21 November 2005
Duplicating data one more time
Last week I was reading up a bit on SPF and briefly at the other proposals for verifying that email is legitimate rather then spam. So far as I can see, the basic premise of these types of solutions is that the recipient (e.g. you) can find out if the email message is from a legitimate source.
The basis of SPF if that the sender's domain (e.g. nibble.bz in my case) would include a TXT record that lists all valid sending email servers. I really find this astounding. DNS has been messed with for a lot of things and now this? The RFCs state that TXT records are not to be used for structured data. I don't know how those bird-brains could promote such trash as being a good idea. "But it's easy!" Well, find me a paper or a book on computer security and I'll show you at least two places that say computer security comes at the expense of ease of use. Sorry folks, I don't buy SPF.
Holistic dicussion aside, one of the underlying shortcomings of many existing mail setups, Nibble Net's included, is that the sender is never authenticated in the first place. I use my email from all over the lower mainland and when I send mail I just use whatever the nearest relay is. At work, I use the SFU mail servers, at home, I might use the Shaw mail servers. Why? Relaying mail is typically permitted on the basis of IP address alone and not any sort of login.
Now we get in to authenticated SMTP. Users within a domain can login and send mail from one of the various hosts within that domain isntead of using, say, the SFU mail server. Ah! See there's the rub. For a client (my workstation at SFU) to send an email, I use the same protocol for talking to the server and the server uses for talking to the recipient's mail server. To talk to the server here, it would make sense that I put in a username and password so the server can identify me. Fine, great, swell. Now for the server here at SFU to send a message to hotmail.com, for example, there's no password involved. There's no certificates, no nothing. See where I'm going with this? The Simple Mail Transport Protocol is geared for exchanges messages equally well between your mail program and a server as it is between a virus-infected PC and a mail server. "You don't know where it's been" couldn't be more true.
Well SPF, SenderID, DomainKeys all try to address the server-to-server side of the problem. The client-to-server is best solved by forcing users to provide authentication information which is what I took a stab at on the weekend. Now all the user information for our users is stored in a LDAP directory so it is best if users authenticate against that. Not so fast, sport. Aparently, we're going to have to use Simple Authenticate and Security Layer (SASL). "That's pretty cool," I think to myself, "I'll be able to use PLAIN, CRAM-MD5, DIGEST-MD5, or GSSAPI (if I had Kerberos installed)."
So I poke around and poke around and to the best of my searching, it turns out there's a couple things going on here. Firstly, SASL is a set of libraries so that clients and servers can perform the various SASL operations and secondly Postfix will do SASL authenticate against a seperate SASL password file. Suposedly, I would have to duplicate all the user data in another password file. Heck, even with system logins and Jive Messenger logins using LDAP, I still have a seperate Samba password file and a plethora of htpasswd type files and up until I retired NIS there was the yppasswd database as well! Common folks, let's duplicate the user info ONE MORE TIME! So far as I can tell, I will have to setup an additional daemon, sasld. So the users email program talks to Postfix, Postfix talks to the SASL daemon, the SASL daemon talks to the OpenLDAP server, and finally the user will be authenticated and allowed to send mail. Excitement! Well, if I'm even in the right ballpark, then the setup is actually pretty simple. A couple options in each of three servers to get strong authentication working. Nevertheless, a task for another day.
Speaking of other tasks, I did finally start trying to clean up the DNS names and SSL certificates. So the best convention for keeping the DNS stuff organized that I can figure is to give each machine a proper host name (siona.dl.nibble.bz, friday.dl.nibble.bz, etc) and then give each *service* a hostname to match the service like imaps.dl.nibble.bz. Then issue a certificate for each service such that there's no confusion as to what's going on (you're authenticating the service you're accessing) and if services do get moved to different machines, changes like that are transparent to the user.
Anyhow, enough excitement, it's time to go home.
The basis of SPF if that the sender's domain (e.g. nibble.bz in my case) would include a TXT record that lists all valid sending email servers. I really find this astounding. DNS has been messed with for a lot of things and now this? The RFCs state that TXT records are not to be used for structured data. I don't know how those bird-brains could promote such trash as being a good idea. "But it's easy!" Well, find me a paper or a book on computer security and I'll show you at least two places that say computer security comes at the expense of ease of use. Sorry folks, I don't buy SPF.
Holistic dicussion aside, one of the underlying shortcomings of many existing mail setups, Nibble Net's included, is that the sender is never authenticated in the first place. I use my email from all over the lower mainland and when I send mail I just use whatever the nearest relay is. At work, I use the SFU mail servers, at home, I might use the Shaw mail servers. Why? Relaying mail is typically permitted on the basis of IP address alone and not any sort of login.
Now we get in to authenticated SMTP. Users within a domain can login and send mail from one of the various hosts within that domain isntead of using, say, the SFU mail server. Ah! See there's the rub. For a client (my workstation at SFU) to send an email, I use the same protocol for talking to the server and the server uses for talking to the recipient's mail server. To talk to the server here, it would make sense that I put in a username and password so the server can identify me. Fine, great, swell. Now for the server here at SFU to send a message to hotmail.com, for example, there's no password involved. There's no certificates, no nothing. See where I'm going with this? The Simple Mail Transport Protocol is geared for exchanges messages equally well between your mail program and a server as it is between a virus-infected PC and a mail server. "You don't know where it's been" couldn't be more true.
Well SPF, SenderID, DomainKeys all try to address the server-to-server side of the problem. The client-to-server is best solved by forcing users to provide authentication information which is what I took a stab at on the weekend. Now all the user information for our users is stored in a LDAP directory so it is best if users authenticate against that. Not so fast, sport. Aparently, we're going to have to use Simple Authenticate and Security Layer (SASL). "That's pretty cool," I think to myself, "I'll be able to use PLAIN, CRAM-MD5, DIGEST-MD5, or GSSAPI (if I had Kerberos installed)."
So I poke around and poke around and to the best of my searching, it turns out there's a couple things going on here. Firstly, SASL is a set of libraries so that clients and servers can perform the various SASL operations and secondly Postfix will do SASL authenticate against a seperate SASL password file. Suposedly, I would have to duplicate all the user data in another password file. Heck, even with system logins and Jive Messenger logins using LDAP, I still have a seperate Samba password file and a plethora of htpasswd type files and up until I retired NIS there was the yppasswd database as well! Common folks, let's duplicate the user info ONE MORE TIME! So far as I can tell, I will have to setup an additional daemon, sasld. So the users email program talks to Postfix, Postfix talks to the SASL daemon, the SASL daemon talks to the OpenLDAP server, and finally the user will be authenticated and allowed to send mail. Excitement! Well, if I'm even in the right ballpark, then the setup is actually pretty simple. A couple options in each of three servers to get strong authentication working. Nevertheless, a task for another day.
Speaking of other tasks, I did finally start trying to clean up the DNS names and SSL certificates. So the best convention for keeping the DNS stuff organized that I can figure is to give each machine a proper host name (siona.dl.nibble.bz, friday.dl.nibble.bz, etc) and then give each *service* a hostname to match the service like imaps.dl.nibble.bz. Then issue a certificate for each service such that there's no confusion as to what's going on (you're authenticating the service you're accessing) and if services do get moved to different machines, changes like that are transparent to the user.
Anyhow, enough excitement, it's time to go home.
Subscribe to:
Posts (Atom)