This is one of a series of computer configuration stories, in reverse chronological order. Others are accessible as follows:
Or, return to the home page for this activity.Experiment with operation and use of headless server.
Revisited the idled home server project, having gotten the Gorilla desktop to boot again. It does, however, sometimes seem to take a few minutes of flashing front panel LED time before doing so. Will see if the hardware is now stable, and also check how much power it's burning during idle, but will at least experiment with the configuration. It's an old box with ¾ GB of memory (subsequently upgraded to 1.5GB), but retrofitted with a 400 GB hard disk, currently 80% managed under lvm.
Once installed, Ubuntu server doesn't seem to have any problems running headless, using a hardwired Ethernet connection. Ubuntu's CLI-only administration, accessed through ssh, is somewhat spare but workable, offering yet another Linux Learning Experience. I like the idea that the server configuration is on the stripped-down side rather than erring towards too many packages. Installed the non-X version of emacs to edit server-side files as needed.
Ubuntu server setup was fairly quick and easy. To use .local addresses, need to load the appropriate mdns/avahi packages. The Ubuntu “Uncomplicated Firewall” (ufw) was straightforward. It wasn't hard to start serving pages with Apache.
Now updated to Ubuntu Server 9.10. This caused me to encounter a bug that made the server freeze after 10 minutes of uptime. Googling showed that this was related to Intel chipsets and timing to blank the (nonexistent) monitor. Putting a "nomodeset" argument in the grub boot line seems to fix this. I also left in an earlier fix, which was insufficient in itself, under the name of powerfix-910 in /etc/init.d. Maybe this can be flushed later, but I haven't checked.
In December, I'd replaced the power supply, which had been causing problems. I also removed the wireless adaptor for power reasons. I could probably disable at least some removable media drives as well, but am unsure whether they cause significant drain unless selected.
Now that I've been using the server more frequently, as to provide an rsync service, I decided to change the password. I stashed a copy of the ecryptfs metadata at the top of /home with a handcrafted pathname. I also tried Dustin Kirkland's instructions, which (after a reboot) now seem to have put metadata in /home/.ecryptfs/jlinn/.ecryptfs/.Private rather than /var/lib/ecryptfs as was the configuration when I originally built the server under 9.04. (It's now up to 10.04 LTS, following a clean live version upgrade.) NB: All of the files in home/.ecryptfs/jlinn/.ecryptfs/.Private appear to be FNEKs, but it may be notable that two of them are links, with timestamp likely corresponding to the password change. I'm hoping that the data there is sufficient for recovery, but have left my hand-copied version in /home as well for the time being.
Noted: It doesn't appear that a forced fsck with touch
/forcefsck yields a new log entry in /var/log/fsck, but it does
seem to take place on next boot, and is noted in /var/log/boot.log.
That log also shows a syntax error re “powerfix-910” - see also 7
February 2010 note below, but it's been harmless for several months,
so I won't feel compelled to tweak with it now.
Given that I'm gradually moving most of my personal writing and
data creation into a Linux environment and using Gorilla as a means
to consolidate and backup files there, I thought it was worth
checking the ability to make an off-site backup of the server itself.
I created a “backing” user with sudo privileges for this purpose,
so it could run without decrypting and mounting my personal home
directory. I can plug an NTFS-formatted USB hard drive in, locate it
with fdisk -l, and mount it on /media/external. A cp -r of the
Gorilla root fails with a read error somewhere in /proc; I eventually
used an rsync command with excludes of /proc, /sys, and /media for
various reasons, which seems to succeed and hopefully doesn't miss
anything that's valid and important to back up.
It's probably slowed down by the “c”-for-checksum option, which I'm currently including for the purpose of capturing changes in TrueCrypt volumes, and which may be more expediently handled in some other way rather than causing more pervasive overhead. Also observed re rsync and TrueCrypt: the rsync -z compression option seems to be able to transfer changes within a part of an encrypted volume while managing to send far less than the volume's full length, which implies something about error propagation. As another next step, once I have more removable hard drives in hand, it may make sense to format some in ext3 and to try to mount encrypted directories from them. Looking at the discussion on the Ubuntu wiki, I think I'd prefer to try this first when running in a home directory that's not itself ecryptfs-encrypted, so as to avoid the (unstated) possibility of confusing FNEKs from different installaations.
Following the discussion above, I recycled Doughnut's former hard
drive by formatting it in ext3, and battling with rsync's apparently
inconsistent exclusion rules. I didn't time it formally, but think
that transfer to ext3 may be noticeably faster than to NTFS. I found
that exclusion of /media is quite important to have if writing to a
locally mounted ext3 file system, as otherwise there can be infinite
recursion of files with paths beginning
/gorilla/media/external/gorilla/media/external and so on. (This
hadn't happened when writing to a USB NTFS disk, which also doesn't
appear to automount if connected on startup.) I saw that this was
happening after a few hours; when sudo rm -r
/media/external/gorilla/media unwrapped the mess, it freed about 40
GB. I've no idea how far down the recursion went. I eventually
converged on the following rsync command file (in
/home/backing/bin/gorilla-to-disk), which seems to do what one might
want (though not capturing TrueCrypt volume changes with checksums,
but that's OK for an initial copy and can be worked around in other
ways):
sudo rsync -av --delete / /media/external/gorilla \
--exclude /media \
--exclude /dev \
--exclude /proc \
--exclude /sys
A wattmeter suggests that Gorilla idles in Linux at about 50-55 watts, spiking up to 80-90 when busy. This idle consumption is about half that of my office desktop (Tadpoles). Current BIOS power-related settings (in Dell terms) are:
Suspend mode: S3 AC Power Recovery: Off Low Power Mode: Disabled
I'm unsure how much optimization from this point would be feasible or useful.