Xubuntu

I've been running Ubuntu 10.04 for a couple of years, but it goes end-of-life soon. I knew that upgrading would more-or-less mean learning a new window manager: Unity or something else. I decided to try going with XFCE in Xubuntu 12.04 (which will have support until April 2017).

I have so far been pretty happy with it. I backed up everything I could think of to a second hard drive, and then did a fresh install off of a USB drive. It didn't take long, and then I spent a couple of hours restoring files and setting up software and stuff, such as...

• installing google chrome and importing bookmarks (I'd exported them prior to the upgrade)
• restoring ~/.purple so that pidgin would work
• installing postfix and configuring it to relay off of gmail, so that logwatch and my cron jobs would land in my gmail inbox (I'd already done this, so I just had to restore a couple of files)
• installing VirtualBox and restoring ~/.virtualbox (and my guest machines booted without much complaint)
• pointing gmusicbrowser at my MP3 collection and skinning it to look like rhythmbox (there are some minor differences I'm still getting used to, but it looks like the playlists I exported from rhythmbox import right into gmusicbrowser, so that's a pleasant surprise)
• setting up an encrypted subdirectory in $HOME

I find that I don't much care for the panel at the bottom (the one that's supposed to look like OS X), so I may end up removing it. And I'm finding that the keyboard shortcut for "maximize window" is flaky for some reason. But those are about the only two wrinkles I've found. It was otherwise pretty painless, and it took less time than I expected.

Red Hat and CentOS process locks do not belong in /var/lock/subsys

I have a bash script that runs via cron every night. It's a software package repository mirroring process, so it has the potential to run for a long time. I don't want two of them running at the same time, and I want to know if one is running for more than 24 hours.

So the first thing the script does is to check for the presence of a lock file in a particular location. If the lock file exists, that means that the previous instance didn't complete, so it spits out an error message (which will land in my email) and quits. If the script does not find the lock file (which is the normal condition), it creates the lock file (via touch) on the very next line. The very last thing the script does is to remove the lock file.

if [ -f /var/lock/subsys/mirror ] ; then
    echo 'previous instance running--quitting'
    exit
fi
touch /var/lock/subsys/mirror

# long-running mirroring process...

rm -f /var/lock/subsys/mirror

We have scheduled downtime from time to time to do operating system upgrades and other maintenance. I typically create the lock file manually at the beginning of maintenance, because I don't want my local repository changing while I'm running updates. And then I manually remove the lock file at the end of maintenance.

We did maintenance last night, and the server that runs this mirroring process was having some kind of problem. We ended up rebooting the server (which, in this case, resolved the problem we were experiencing).

Turns out that part of the reboot process on Red Hat (and CentOS) is to clear out the /var/lock/subsys directory, which is where I'd been putting the lock file for the mirroring process. Oops.

Fortunately, the reboot happened after the cron job, and so the cron job didn't run unexpectedly. But that was just a matter of lucky timing.

So today I'm moving the lock file to /var/run. And I may as well make it work like the other files in that directory. So instead of

touch /var/lock/subsys/mirror

I'll do

echo $$ > /var/run/mirror.pid

Travel-related tech

I recently took a trip, and here are a few notes about some of my technology-related experiences.

I knew I'd probably want Internet access at the hotel, but I figured it would be wireless, and I was hoping for some kind of VPN. In the past I've used ssh's socks proxy feature, but I've found it to be pretty slow. So I thought I'd give wonderproxy a try. You can get a VPN account for a month for around $5, and I thought it worked really well. It was fast, and it made me feel a little better about using the hotel's wireless.

I bought a Macbook Air not long ago, and I like it. So I took it with me on the trip. I took some pictures, and I used iPhoto to copy the pictures off the camera onto the laptop. Then I tried using iPhoto to upload the photos to flickr, and that didn't work well for me. iPhoto crashed at one point during an upload of a bunch a photos, and there was no obvious way to resume the upload. I was able to figure out where it quit, and then I just told it to upload the photos it missed. But many of the photos on flickr don't have the original size--the largest version of many of them is 1024x768 (there should be three larger sizes). So I have to upload those images again or just be OK with the smaller sizes on flickr. So I'm glad I hadn't told iPhoto to delete them off the camera.

I also told iPhoto to mark several of the photos as private, and they ended up as public on flickr.

So I probably won't be using iPhoto any more.

And although southwestvacations.com did a great job of booking the trip, they totally FAIL in password security. When I created the account, I used a password generator to create a long password with all four character classes, and I saved the password in my password wallet. At one point during the trip, I needed to access something in my account. But when I tried to log in, I got invalid username/password errors. I ended up using the "forgot my password" link, thinking it would send me a login token. Nope, it sent me my password. It wasn't even my original password (which is why I was having trouble logging in). The original was around 20 characters long, but what they sent me was the first 10 characters of the password I'd created. So southwestvacations.com

• restricts password complexity (they truncated my password at 10 characters--the 11th was a percent sign, so I don't know if it was the length or the character)
• they truncated my password without warning me
• they store non-hashed passwords
• and they'll send passwords by email

FAIL.

Otherwise, it was a lovely trip. Have a look, if you like.

shadow passwords with openssl

I once had to break in to a CentOS box, because I'd forgotten root's password and didn't know the passwords to any other users (I think it had been shut down for a while). So I booted with a rescue disc (I think it was a CentOS installation disk, and I typed "linux rescue" at the prompt). The rescue disc mounted the filesystems, and I tried running passwd in a chroot. I got some kind of error message, and it wouldn't reset the password for root in /etc/shadow on the filesystem. I ended up editing /etc/shadow by typing in a password I got out of /etc/shadow on another box.

As I'm writing this, it occurs to me that if I knew the password to some other user (at this point I don't remember if I did or not), I could have just edited /etc/sudoers to give root to that other user, rebooted, logged in as that user, and done "sudo passwd" to reset root's password.

But if you ever need to create /etc/shadow entries by hand for some weird situation, here are a few suggestions involving openssl's passwd utility.

Incidentally, if you have trouble finding the man page for openssl's passwd ("man passwd" is likely to get you the man page for thing that resets your login password), try "man 1ssl passwd" (Ubuntu) or "man sslpasswd" (Red Hat 5).

The hashed passwords in /etc/shadow look something like this:

$1$.oDCRZmb$mYZm6IzfMWVfe38Pr4fHt0

The shadow entry has three parts delimited by dollar signs. The 1 indicates that this shadow entry was computed with the MD5 password algorithm. The next section (".oDCRZmb") is the salt, and the final portion is the hashed password.

You can generate these yourself. If you type the following (the "-1" requests the MD5 algorithm)

echo password | openssl passwd -1 -stdin

you should get something resembling

$1$DcuakEM4$c4WDkEXKd6YXNYjAfN2Sh/

You can reproduce this by providing the salt:

carl@stilgar:~$ echo password | openssl passwd -1 -stdin -salt DcuakEM4
$1$DcuakEM4$c4WDkEXKd6YXNYjAfN2Sh/

And it looks like openssl is smart enough to strip the newline:

carl@stilgar:~$ echo -n password | openssl passwd -1 -stdin -salt DcuakEM4
$1$DcuakEM4$c4WDkEXKd6YXNYjAfN2Sh/

Without the "-1" argument, openssl uses the standard crypt algorithm. The first two characters from crypt output are the salt, and this is what the Apache webserver's htpasswd uses for making passwords (at least, crypt seems to be the default algorithm for the Ubuntu and Red Hat 5 packages):

carl@stilgar:~$ echo password | openssl passwd -stdin
BxZPctq22eZ4M
carl@stilgar:~$ echo password | openssl passwd -stdin -salt Bx
BxZPctq22eZ4M

passwd also knows the Apache variant of the MD5 algorithm:

carl@stilgar:~$ echo password | openssl passwd -apr1 -stdin
$apr1$z4cUIQjr$fXbDk6ypzyZIIIb/OIp0I.
carl@stilgar:~$ echo password | openssl passwd -apr1 -stdin -salt z4cUIQjr
$apr1$z4cUIQjr$fXbDk6ypzyZIIIb/OIp0I.

Looks like Ubuntu uses the sha-512 algorithm for hashing passwords, and openssl's passwd doesn't support this. If you want to try making /etc/shadow entries w/ sha-512, try saving the following file as passwd.c:

#define XOPEN_SOURCE
#include 
#include 

int main(int argc, char *argv[]) {
    if ( argc < 2 ) {
        printf("usage: %s password salt\n", argv[0]);
        return;
    }
    printf("%s\n", (char *)crypt(argv[1], argv[2]));
    return;
}

And then try this:

gcc -lcrypt -o passwd passwd.c
./passwd password '$6$salt$'