DIY Eco Linux Fileserver (part 2)

Earlier this month, I was attempting to appease my wife by reducing my server’s power consumption physical footprint.  In this follow-up, I’ll give you an update on how I got on and pass on a few tips if you’re planning to do the same.

Normal I Manage Products service will be resumed in the next article!

When I left you last, I’d selected the combination of an Acer Aspire Revo for the server and a 2TB Iomega Prestige Professional eSATA hard disk.  These duly arrived a few days later and I set about cloning my old Debian server onto the new one.

(Update: amusingly I had this originally as 2GB as I either have nothing worth storing, or I’m so past it I still think 2GB is a lot of storage space.  Thanks to @lukosan for pointing out my amusing error.)

The steps I followed were:

1. Install Debian Lenny onto the Revo box
2. Synchronise the Debian packages installed
3. Replicate the configuration of the services
4. Synchronise the files and cronjobs
5. Switch off the old server

1. Installing Debian Lenny onto the Revo #

Installing Debian was remarkably straightforward.  The Revo came with Linpus pre-installed.  All very nice, but not what I wanted.  What I did before I started blitzing the partitions was to create a recovery DVD ISO (the Revo has no optical drive) and keep that for later.

I wasn’t particularly interested in running X Windows, but if you are, you might want to take a closer look at the hardware and configuration settings and make notes while you’ve got a working system.

I did make a couple of tweaks in the Revo BIOS: one was to enable AHCI on the disk controllers, the other was to ensure that the internal disk was the primary boot device.  It seems that when you use an external eSATA disk with the Revo, out of the box it will become the boot disk, not necessarily what you want.

The original disk layout for the Revo was a small recovery partition (~2GB) and the remainder of the 160GB drive allocated to the Linpus operating system.  Using Unetbootin on a flash drive, I installed using the Debian Lenny x86_64 netinst image.  It’s pretty straightforward, no gotchas here, assuming you’ve installed Debian before.

I partitioned up the boot disk inside the server on ext3 in a fairly similar way to the original server, separate /usr /var /home and /tmp partitions, with most of the disk space allocated to /home.  Clearly you should partition the way you want to.  It’s a generally a good idea to have separate partitions.  The 2TB disk was also divided into two large ext3 partitions.

2. Synchronising the Debian packages #

I have a lovely tip for you here to save you time and effort:

• As root on the original server, run dpkg –get-selections > myselections.txt
• Transfer over the myselections.txt file to the new server
• If you want to keep the basic packages already installed on the new server, as root, run dpkg –get-selections >> myselections.txt
  • This appends the selections already on the new server to your list from the original server
  • This is useful if for example you want to ensure you retain the right kernel image package and dependencies
• As root on the new server, run dpkg –clear-selections then dpkg –set-selections < myselections.txt
  • This sets the list, but doesn’t actually do any package changes
• Finally, as root on the new server, run apt-get dselect-upgrade
  • This will make the appropriate package changes all in one go

Job done!

Replicate the configuration of the services #

Depending on what services you were running on the original server, you’re going to need to configure the new server to behave in the same way.  This is time-consuming and assumes you know what you’re doing for each.  What I found useful were the following commands to remind me what I actually had running on the original server to create my todo list:

• netstat -at | grep LISTEN – tells me what TCP services are listening on a network port
• netstat -ant | grep LISTEN – as above but with IP addresses and port numbers listed explicitly
• ps aux – tells me what processes are running

Synchronise files and cronjobs #

This can be pretty straightforward. However, it’s generally a good idea not to pull across configuration files or databases in this manner (use the dump and import functions of the database).  Great for MP3s, images, documents etc., though.

On the new server, pull the files on from the original server using rsync -a original:/yourfiles/here/ /destinationforyourfiles/here/

Cronjobs are pretty easy as well, though you may wish to disable cronjobs (comment out the lines in the crontabs) until you’re ready for the new server to take over.  Check /var/spool/cron/crontabs/ to see which users have personal crontabs, plus also /etc/cron.* . Personal crontabs can be copied over, then checked with crontab -l -u [username]

Switch off the old server #

Once you’re happy that you’ve cloned everything, your last steps are to switch off the old server and for the new server to assume its identity (if that’s how you’ve planned it).  This will mean changing the hostname and network configuration on the new server to that of the old.  A gotcha here is if there are any network services explicitly listening on a particular IP address – you’ll need to update these also.

As an aside, I avoided a lot of this pain by using role-based IP addresses in addition to the server-specific one, which I could easily migrate from one server to another.  For example, my server’s real address is 192.168.0.10, but I also have raised another IP address: 192.168.0.3

My DNS points to this address and all my network services listen on this, not the real address.  This means I can keep more of the service configuration the same and all I need to do is lower the 192.168.0.3 address on the old server and raise it on the new one.  Voilà, everything now points to the new server with minimal faff.

Shut down the old server so you know you’re definitely seeing only the new server.  Restart the new server as it’s also important to check that everything starts up automatically.  Believe me, there’s always something you’ve missed.  A common gotcha is forgetting to put in appropriate symlinks in the /etc/rc[0-6].d folders pointing to the /etc/init.d scripts.

Benefits so far #

My home office is a lot quieter now.  The Revo and Iomega disk are almost silent and draw a fraction of the power of the old beige box.  The physical footprint is tiny compared to the beige box and could be even smaller if I wasn’t using the funky stands for both.  I’m also enjoying the speed increase from the dual-core Atom box and 2GB RAM.  The old beige box was an ancient Celeron from circa 2002 – perfectly sufficient for running the network services up until now, though.

On the downside, I’ve suddenly realised how cold the office has become now that I don’t have the beige box pumping out so much heat.  This is probably a good thing, though I’m off to grab another layer and a cup of tea…