David North

So, as those not reading via one of the planets will be aware, I’ve rolled out the fourth (or is it fifth?) new theme for this site since May 2007. I’m definitely more pleased with this one than any of its predecessors, and intend to stick with it for a good while.

In other news, I blew £160 on new technology for my desk this week: specifically, a new 4GB USB pendrive to replace my ailing 256mb one, a 250GB external hard disk for my backups, and best of all, a 19 inch TFT monitor to act as a second screen for my laptop.

All of the above were very reasonably priced over at Dabs, and the £100 inc delivery cost of the monitor in particular came as a very pleasant surprise.

This is the first time I’ve given multiple monitors a serious go under Linux (specifically Kubuntu), and KDE certainly puts Windows (at least up to and including XP) into the shade here: a taskbar on each monitor? Yes, it can do that. Separate background images per monitor (without silly hacks involving stitching image files together)? Yes. Only show the buttons for the windows on this monitor on this monitor’s taskbar? Certainly, sir.

It’s only been two days, but I’m already wondering how I ever managed without a secondary screen. It certainly made finishing the new theme for this site a lot easier.

I’d been a regular user of SSH for several months before I discovered screen. For the uninitiated, it allows you to create multiple ‘windows’, each containing as shell, inside a single SSH session. It also allows you to detatch the whole session from the terminal, log out, then log in and reattach it later, with all programs that were running in it still there. I’ve now fixed up my SSH logins to automatically reattach my screen, and create it if it isn’t there:

ssh -t david@machinename screen -d -R

In PuTTY, the ‘remote command’ option in the SSH config area (as per the relevant manual section) achieves the same effect.

This ‘automatically-reattach-or-create’ stuff all worked fine on one Ubuntu, three Debian, and one Solaris machine when I tested it last week, but trying to log in to the Solaris box last night produced

bash: screen: command not found

I think this is because the screen binary lives in /opt/sfw/bin/ on these machines for some reason, hence it’s not in the default PATH variable. It is in my user PATH, but I presume that isn’t loaded when SSH tries to execute the command. Anyway, specifying /opt/sfw/bin/screen rather than ’screen’ in the SSH command solved the problem.

I needed to set up a Planet recently, and there appears to be very little online documentation about the process. To be fair, if you install it on Debian using apt-get, debconf will walk you through most of the setup, and it drops some examples into /usr/share/doc/planet to get you started, but here’s my quick guide anyway:

How to install planetplanet on Debian

Follow these instructions at your own risk:

1. sudo apt-get install planet
2. Follow the prompts from the installer to fix up your basic configuration
3. Create a virtualhost on your web server if necessary, and make the directory which the planet URL will map to
4. Edit /etc/planet.conf to change the output_dir line to the directory you just created
5. debconf should have set up a cron job to update the planet if you asked it to, but meanwhile you might find ’sudo planetplanet /etc/planet.conf’ handy to manually update it whilst checking it’s all working.

My friend and web host, Martin, recently decided to scrap his old server running DirectAdmin, and replace it with a shiny new CentOS VPS running Plesk. Having spent an enjoyable day with him last week rummaging in the bowels of the old server trying to fix SpamAssasin, I agreed heartily with his decision. I got dnorth.net over to the new machine with reasonably little fuss, apart from a few minutes when I hosed the DNS by being in too much of a hurry. I also forgot to copy the .htaccess file, which resulted in everything but the front page of this blog being down for several hours. Of course, I didn’t check anything except the front page.

Moral of the story: command-line scp doesn’t copy files whose names begin with a dot, unless you explicitly tell it to, i.e do this:

scp -r user@host:'/dir/* /dir/.*' destination-dir

Rather than this:

scp -r user@host:'/dir/*' destination-dir

And just because the front page works, that doesn’t mean the rest of the site is OK…