apt-get dist-upgrade is getting a little less fun these days.

It’s not because of a problem with Debian or with apt-get. It’s because of things upstream authors are doing.

It seems that upstreams, for some reason, like to remove features from new versions of software.

The two recent examples to bite me are the removal of the Gnome Terminal features to play the bell through sound card rather than the console speaker, and the recent upgrade to gtkpod — the best iPod music manager out there — which removed the ability to actually, well, play music. Wha…?

Earlier examples where when Gnome removed the ability to type a filename in the Open dialog box (remember that? thankfully reverted eventually.) KDE 4 was infamous for this too, with maybe thousands of instances (and they broke Amarok so badly that it didn’t actually play music from my devices either.)

I don’t understand this. The Gnome people somehow thought that they knew better than I what options I might want, I guess. But I am totally baffled about gtkpod. All it ever did was call xmms (or something like it such as qmmp) with appropriate arguments to play a file. Simple, configurable, and supremely useful. Probably just a few lines of code. And even that is gone.

There is a post by Ingo Molnar complaining that perhaps Gnome and KDE are trying to mimic the Apple and Google result without internalizing the process. Perhaps. It all seems so baffling to me though.

Updated: rewrote introduction.

It’s time to change locations for my server. I’ve been with CoreNetworks for almost 5 years. They provide a good value, with fully dedicated servers a lot cheaper than most places, and good support to boot — targeting people that can handle root on their own box. I’m switching, though, to Hetzner Online (of Germany), primarily because I am needing more than 1GB RAM, and they can provide a 2GB box for less than I pay now for 1GB. I asked for feedback on Google+, and got positive feedback. Today, I migrated from one machine to another, copying a dozen or two GB of data, and only had about 15 minutes downtime.

I was able to do this without console access to the source machine, though console access wasn’t really required for either. This will work with any basic Linux install on the destination, or it could be prepared directly from a rescue environment.

Before I explain how I did it, I thought it was interesting to think of the different places that the machine that was known as complete.org has lived over the years. Here’s a map (click for detail):

Here’s the general process.

First, well in advance of the move, crank the TTL on the domains way down. This way, old IPs won’t be cached for very long once the system moves.

Next, start rsyncing data from the old machine to the new. Do not yet shut down daemons on the old. Shut down as much as you can on the new. You’ll want to focus on static data, such as /home. /usr is a good candidate as well. /var if you are selective — databases may be a good candidate, or may not. The idea is to seed the destination with data so that when we do the “real” rsync, most of the data will be there; it will have to tidy things up after daemons are stopped, and update some things, but the bulk of the work should be done.

Next, start preparing some exclude lists for the final rsync, which will copy an entire machine to the other. You will likely want to exclude files such as /etc/fstab, /etc/network/interfaces, /etc/resolv.conf, /etc/hosts, /etc/default/grub, /sys/*, /proc/*, /dev/*, and the like. I used rsync -v -P -a -H -A -X -S –numeric-ids –delete-after.

Now, start editing config files for the new IP, but do it on the old server (these will be synced over to the new one). Start with the bind config files, and touch anything else that needs it — maybe Apache configs, whatever.

Next, get ready to do the final sync. In an ideal environment, we’d just shut both machines down to single-user mode, but that’s not going to quite cut it here. Use ps and shut down all daemons except sshd and udev on the destination. Yes, including even syslog. This is to prevent anything actively accessing the disk during the rsync, and also to prevent any issues with clients accessing server daemons that aren’t ready yet.

Now, on the source machine, reload bind. This will start answering DNS queries with the new machine’s IP, and should also propagate the changes to your secondary DNS. Next, kill off all the daemons on the source machine, except for ssh and bind. You might want to set /etc/nologin to prevent regular users from logging in on ssh, if you have them. Now rsync things over to the new machine. Do any final tweaking over there (merging in /etc/hosts maybe, dealing with the udev rules.d persistent net thing, etc.). Reboot the new server and you should be up and running.