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.

Tocaraul now with searching and stuff

After making some modifications Tocaraul now has fewer bugs, a search function, and functions to delete songs from the request queue (or flush the whole thing). So far, we're doing good. I think that's probably going to be about all the features that I can update without making significant changes to how the code is structured.

I would like to break-up everything into views (request queue is one, library is another, search is a sort of sub-view of library) so that more and more features can be builtin to each part of the program without adding confusion to the interface. That smacks of effort so Fabio and I will see what else we're going to work on. Probably the play history. That would be cool.

Jivin' for Jabber

Turns out there are a few things to keep in mind when setting up an XMPP (Jabber) server. I had to change the domain name a couple times and add a couple service records but the system is now up and running in a standard open-federation configuration. Users on Siona can use their system login for user@dl.nibble.bz and then *poof* that's it. We can message eachother, message other users of different XMPP servers. Access for server-to-server in Jive can be configured eiher by white-list or black-list so I'm just running ours open for now.

And Google developers have said they will join the open federation as soon as possible. One of the sticking points they want to address is control over spammers and bots who could register on any server in the community that allows public registration and then spam the crap out of the Google Talk users. Which is a fair concern but we're all egerly awaiting Google's move to the open federation.

I've been spending more time working with Tocaraul as a front-end for the Icecast server I'm running from home. All the good Ogg encodings are in the library for a whopping total of 2377 songs. Tocaraul is a couple of Python scripts to handle song requests from a web interface. Basically, I'm learning Python :P It's pretty handy stuff. For info on Tocaraul progress, take a look at the WebSVN page there and there's both a change log and a TODO for upcoming features.

Things are Looking up in the Directory

Siona is now running a live LDAP directory and so far it is going pretty well. System authentication is all directory based. Logins and sessions and all that good fun. I configured a Jabber server (Jive Messenger) to auth users against the directory and it works swell! Any system users can login with their system account on the Jabber server and IM and that fun stuff.

I plan to migrate Samba next which is not a very big impact but would be good to get in the central user directory. Dovecot for IMAP and POP authentication after that. Postfix eventually as well which will be interesting. With Postfix, that will afect how mail is routed possibly making it easier to setup virtual domains or whatever. I think that about covers the auth stuff that's offered.

That Jabber server is a little special. I'll have to get some of the peeps using it so we can try to test some of the features. Just basic stuff like authorizing users and setting up or joining chat rooms. So far it seems a little sketchy. There are also some other handy features of the server like a searchable directory. I don't know how that will work out. I just know that I don't know how to get my IM client to even use that feature :P

At any rate, the LDAP works really great and after a bit of a rough start out of the gate, it is really going to be useful as heck. This Jabber we will have to see but it seems promising.

Auth This...

Well, I'm finally going to try to get a working LDAP server up and running on Siona finally. There are so many services that would just work better with a working directory, I gots to put one in. I'm still struggling with bootstrapping the whole operation. I've read some stuff, looked for some tools, but basically unless it's part of a big enterprise package, it's a little, uh, heavy for most operation.

But basically I would be able to run everything through it. Users could save their contact lists online. Login info could come from the directory for any number of services inluding system logins, Samba, Jabber, email, the works! It's all patched together right now with a crude mix of pam, maintenance scripts, and just plain not working. The only common service that I have been able to find is LDAP. PAM is really promising but a bunch of services, like Samba, do a challenge type auth so the passwords have to be decryptable rather then a straight hash.

And all-in-all, setting LDAP as a n00b is really confusing. I just hope this all works out in the end and we'll have world peace and a fair distribution of wealth.

Computers are glorified paperweights.

A handful of changes at skyhook. I finally dumped Ubuntu off Friday in favour of Debian. Basically, to be able to run a functional 64b environment was really cool. All the FOSS stuff ran great. Just really amazing. The one hang-up I had was that you can load 32b plugins from 64b applications. So generally, most things worked but a couple things I usually like to use didn't. So push came to shove and it turns out I'm not a good early-adopter so I went back to 32b land. Still, I was really happy with the system for the 3/4 months I ran in 64b GNU/Linux. But now it's back to 32b for me.

During all the excitement, the Windows XP took a dump. That piece of crap was a pain in the ass from the moment I tried to install it until the moment of its demise about a month later. Our best guess is that one of our guests used IE or some other MS program and got a virus. The virus just sat there eating system resources quietly for a while until I installed Debian. During that time, I swapped network cards. When the card was pulled, the virus crashed and took the system with it. In summary: fuck Windows.

Now Debian, on the other hand, is a real treat.

apt-get install gnome fluxbox xserver-xfree86

Need I say more?

There are a couple cool tricks that I tought the box, specifically GDM. So it turns out that "fast user switching" is the name for allowing multiple users to login and swap use of the workstation without closing their programs. With GDM, you just run gdmflexiserv (or click "New Login" under gnome) and it will prompt you. The trick there is that all this spawning and quitting of xservers makes GDM a little flaky so I added to inittab from which it can respawn if ever it tries to crash. Works like a charm.

The other fun thing to was that I added a user called "kiosk" which will login automatically if nobody else does after 60 seconds. Handy for letting house guests use the computer and not get the computer infected with a virus (I'm talking about you, Windows).

And for the last trick, I kick the UW pop and imap servers off Siona in favour of Dovecot. Dovecot, I must admit, is pretty cool. The migration itself was a little tricky. Various file permission issues plus pop clients might have all gotten duplicate messages. All-in-all, the dovecot stuff is more manageable and more extensible then the basic UW packages. The other nice thing too was that it was trivial to tell Dovecot to run IMAPS and POP3S alone and so now we only run encrypted services for mail on Siona. Pretty neat!

Needs RAM!

Well, it's been 5 weeks since putting in the new video card in Friday and nothing is blown. I declare this system finally fucking fixed! Goddammit, it had better stay fixed for a long time.

Now it's time to give Chevette some upgrades. Working display is a must. Probably just a messed-up latch so that should be fine. If that works out, then I'll get that fixed and dump some more RAM in her. As much as she can take. Well, I'll aim for a half gig but even 256MB would be a passable upgrade. We shall see.