Livejournal Chatting

According to this post, Livejournal is in the process of setting up an integrated instant messaging service for their users. And unlike MySpaceIM, it is properly integrated with the service such that if you have Livejournal friends, they will automatically be available for chatting, and Livejournal will use the standard instant messaging protocol/network (XMPP/Jabber) so that you can chat to users on other services including Google Talk and Nibble Jabber.

With one small step, there's now 12 million more Jabber people in the world :D

Sometimes, You Just Have to Reboot

Well, Sunday I was messing around with the systems at home. Installing updates, kicking the NFS server for fun, only to find that when I logged in to my workstation, KDE wouldn't start. I got a solid blue background and a cursor that I could move around, but nothing was happening. Nothing suspicious in top, ps, or even .xsession-errors per se. I just could not figure it out for the life of me.

So I started thinking, well, maybe it is just me. Some config file for KDE got corrupted and it is holding the whole thing up. So I started poking around, but couldn't see anything obvious. So I trashed some configs I figured might be the problem, still no change so I restored them. Then I figured I should test whether it was a config thing so I stomped the whole config directory in .kde, still not change. I was still convinced at that point that it was just me and in particular, something with KDE, so I stomped my whole .kde folder. Still no change.

I had to admit I had assumed I knew what was wrong when clearly, I was just making an ass of u and me... Mostly just me.

So then I tested whether other user accounts were affected. Sure enough, other accounts were affected. Precisely, the network accounts, but not the local accounts. Something was wrong with NFS.

I poked at siona a bunch and rebooted the workstation a bunch, but still no change. Every time, friday would reboot and I could authenticate, but then nothing would happen on login. Well, not quite nothing. It was just so slow that login/logout took something like a half hour.

Finally admitting I could not fix the problem by hand, I installed the latest kernel on siona (the only good reason for rebooting a GNU/Linux box other then adding new hardware), and rebooted. "Lo and behold", as Professor Tang used to say.

That was it. Kicking the portmapper, restarting the NFS services, re-exporting the shares, nothing I tried made a difference. Rebooting was just the easiest and most effective solution.

But it did cost siona 116 days of uptime for which we are all very sad :( Not a record, but still a good run. We'll miss you, 116 days uptime.

Backup to an Encrypted Disk

For external backup, I got a nice encrypted disk setup. Well, I don't know about "nice", but it works and it's easy enough for me to use. Basically, I took an old 80GB IDE drive, bought a cheap ($15 cdn) external drive enclosure, setup a LUKS/dm-crypt partition on it, an ext filesystem on that, and away we go!

The drive enclosure is basically just a tin shell you stuff the drive into with two plugs (one for power, one for USB), a switch, and an LED. That's it. Once the drive is in there, flip it on, then hook it up to the computer. This turns out to be very important, on my workstation, if I connected it to the computer, then flipped it on, Linux would spew some cryptic error in dmesg and then ignore the drive. I had to have the drive on and ready before plugging it in to the computer. Quirks aside, I basically have an 80GB USB drive. Very nice.

So for setting up drive encryption, I roughly followed this. And by roughly followed, I meant that I didn't recompile my kernel (how very 1999), I just loaded the aes and dm-crypt modules and then in the last step, I used the correct syntax for closing the device (cryptsetup luksClose <name>, not luksClose /dev/mapper/<name>).

Basicallly, setting up the drive encryption was easy:

1. Wipe the drive (with random data),


2. create a partition,


3. run cryptsetup luksSetup on the partition to create the encrypted volume,


4. initialize the encrypted volume with cryptsetup luksOpen,


5. create the file system,


6. mount the file system and enjoy!

Well, okay, it's hardly like boiling water, but once it is setup, it is slightly easier. Before mounting the drive, you just run cryptsetup luksOpen and after unmounting the drive, it is cryptsetup luksClose.

So the last question is: How slow is it? Well, not to put too fine a finger on it, but it's fucking slow. The initial rsync to local un-encrypted disk as mentioned in my earlier post takes about an hour. The rsync to the encrypted disk? Well, I don't know but it was over eight hours, less then fourteen hours. So it appears roughly an order of magnitude slower. Fortunately, not bad since I'm only going to be doing it once a month or so. An hour is okay, but man, I wouldn't want to be doing it on a larger volume.

But there you have it. Encrypted external backups for $15.

Here's a First: It Works!

It feels like the first time in a while that having left town for more then a week, nothing seems to have failed with siona. Mail servers all happy, no known network outages, no disks filling up. Seems a little creepy for it to be so quiet after two weeks with zero maintenance... I had better install some updates and break some stuff just to get back in the swing of things.

Local backups

The motto of a good sys admin is backup often, and backup automatically, and make sure you can recover from a disaster. In general, my practices have been sorely lacking. No copies, no RAID, no external backup other then a couple random backups and dumping the databases (from MySQL) and the directory (from OpenLDAP).

I finally just went with one of the many rsync backup script/utilties: rsnapshot. There is a article about it on www.debian-administration.org. It's simple, supports remote backups using rsync over SSH, and gives you nice rotated backups. Easy, effective, automated. What more do you want?

So now the one thing I have still to do is do an external backup. The current backup is ~17GB. As much as I'd like to burn about two dozen CDs (or even 5 DVDs) with a spanned tarball, that sounds like a pain in the ass. I guess that means an external drive which I take off-site. Ah well, a problem to solve another day.

APT repository by SSH

So while on the www.debian-administration.org site today I noticed an article about Restricting access to your private Debian repository where amongst other gems, they mention that you can use "ssh://" URIs in your sources.list file. Pretty nice, yes?

Well on top of that, mixed in with the comments, someone points out there's a helper utility called ssh-copy-id which copies your SSH public key(s) to a specified machine. It takes care of appending your key to the existing authorized_keys file and fixing file permissions on .ssh and the authorized_keys file.

As Borat says: "Verry nasse!"

Fiesty Fawns and ATI drivers

I succesfully updated Friday, my computer at home, to Fiesty Fawn! Hooray! It was only a little be of a pain. The GUI updater thing seized up during the upgrade. Sucks, but I just did "apt-get dist-upgrade" from the terminal a couple times and all was well. As an added bonus, Fiesty now boots way faster. At some point, probably since Dapper, Friday would hang waiting to connect to the directory server on siona. It would go through a half dozen exponential timeouts before it would proceed so overall, that added 5 minutes to the boot time. Anyhow, with Fiesty, Friday just boots right up!

Now on Santana, my workstation at work, apache was totally messed. I ended up having to blow away apache and all the modules before the update would proceed. I don't know what happened there. Some crazy dependancy hell.

Now in other news, I've been having problems with the proprietary ATI drivers (the fglrx drives) on my office workstation for a long time. Every time I logged out, system freezes. Argh! But I worked around that by only logging out once a week ;) Anyhow, it turns out, the Gentoo people know it's a problem and even have a solution. Well, more of a workaround. Apparently the problem stems from a memory leak or some such. Bad. So I'm going to try their work-around and if it doesn't work *shrug* I'll go to the F/OSS ATI driver. I haven't been playing much UT2004 at work recently which was the only reason I bothered with the fglrx driver in the first place.