Original Gorilla Ubuntu Server

This is one of a series of computer configuration stories, in reverse chronological order. Others are accessible as follows:

  1. 2018 desktop system apollo
  2. 2017 home server go3
  3. 2014 successor home server go-ng
Or, return to the home page for this activity.

Project Motivation

Experiment with operation and use of headless server.

System Setup

16 May 2009

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.

7 Feb 2010

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.

Operational Results

15 Aug 2010

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.

22 Aug 2010

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.

28 Aug 2010 – 6 September 2010

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

12 September 2010

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.