Building a home server – Software

Install the Operating System

As detailed in the Introduction, we’re going to drop a standard install of Ubuntu Server Edition on here, and then customise for various additional functionality.

The first step, of course, is to obtain one Ubuntu install CD! Go to the download page for Ubuntu, then make sure you select the server edition. At the time of writing the latest version of this was 7.10, however what follows is unlikely to be greatly different for later versions.

A short aside on why we choose the server edition: it avoids installing a bunch of software we’re never going to use, prime examples of which would be Gnome or KDE. They take up space and, to some extent, use resources which we’d rather keep available. You can install the non-server version if you want, just as it’s trivially easy to upgrade the server version itself to, say, a full install of KDE. But for what we’re trying to do there’s no point. The server edition is “lighter” and has better default options selected.

Once you’ve downloaded the ISO file, you need to burn it to a CD. Then, of course, make sure you’ve got your install environment plugged in to the newly built server. We need:

  • Keyboard (USB or PS/2 will do – note that no mouse is required)
  • Screen – any old thing will do – this is just for a few minutes.
  • CD reader. If you’ve built the same server as me, then it does not have a CD reader – we need to temporarily cable one on to the IDE bus (or, if you have a SATA CD drive, then on to the SATA bus), just for the duration of the install.
  • Network connection. While not required for the initial install from CD, a working Internet connection will be required pretty soon thereafter.

Are you experienced? At least a little bit…?

Ubuntu is rightly praised as being easy to install. Take a desktop PC and the CD installation is pretty much automated. Afterwards you have a working system.

However if you are building a server, such as we are here, one must assume that you’ve at least a little Linux experience. And some network experience (If I say “DHCP” you know what I’m talking about, right?) And some general hacking around from the command line experience. Guru-level not required, but building this server is not maybe the first Linux project one might undertake…

Install and boot

The Ubuntu server install is really straightforward, but you do need to answer a few questions along the way. As with the hardware install, you almost certainly know enough to answer the questions asked and at the end we are told to eject the CD and reboot. The install has gone so swimmingly well that you just know it’s going to boot and fly first time. Right?

Upon reboot we quickly reach the GRUB display, and sit tight to let it take the default. Kernel load starts and… Kernel Panic. Complete lock up and failure. You try again (as if second-time lucky might actually work) and get the same thing. Leaving aside a very lengthy period of diagnosis I had to perform, let’s get right on with fixing this.

Kernel choice

The installation CD, which ran so well, boots off a generic kernel. However the installer does not stop to think, and merrily installs a different kernel than the one it successfully booted from. It installs the Ubuntu server kernel. Which sound reasonable, actually, as this is, errr, a server. OK, but just what do we mean by generic kernel or server kernel? Here and now is neither the place nor time to go into details, but suffice to say that when a kernel is built there are numerous (many hundreds) of features which can be enabled, disabled or generally fiddled with. The Ubuntu developers have duly fiddled to produce what they think is a really spiffy kernel for servers. And in doing so they made some assumptions about what sort of hardware you would actually install this on. And, guess what, those assumptions are Not Good for the hardware being used here.

Is it a bug or a feature? One could argue both ways. I do think the installer should at least warn of the incompatibility, though. It’s easy enough to check for, if you know where to look.

Completely optional paragraph: For the technically minded, the server kernel assumes you have a CPU with PAE extensions. These relate to very large memory configurations. Trouble is, though, the kernel requires PAE support and if your dear little VIA CPU doesn’t have them (and it sure does not) then the kernel dies an ugly death. (For the even more technically-minded, you would confirm this by doing a “cat /proc/cpuinfo” and looking to see if the “Flags:” contains a mention of PAE)

So what can we actually do about this?

Fixing the kernel

There’s a really easy solution to this. And there’s a really (and I do mean really) difficult one. The difficult path is, of course, hugely more fun and interesting, but you need plenty of spare time, a lot of experience and, ideally, a spare Linux system.

So, easy, recommended fix first: boot off the install CD again and choose the option to “Rescue a broken system”. Then, after various prompts, choose “Execute a shell in <your partition here>”. Then perform these commands:

  • apt-get update (if your network is up, otherwise skip this)
  • apt-get install linux-386
  • apt-get remove linux-server

Then you should be able to boot fine off the new kernel. See – easy??

Of course you might be asking yourself whether changing to this other kernel matters? I can confidently say that for a small, home server, no it does not matter one jot. The server optimisations in the Ubuntu server kernel only really matter for seriously big boxes, with many users, multiple disks, and so forth. So don’t worry.

However…………….. if your Inner Geek absolutely insists on having the server optimisations in your kernel: well, here’s where I’ll point you in the right direction and leave you to it. I actually did this. But it’s hard work…

Building your own kernel – Massively optional and not required… and not recommended!

You really want to build your own kernel? Hey, remember: the generic kernel will do you just fine. Really. But for fun, this outlines the steps you would follow:

  • You could install the tools and source on the VIA box itself. But building a kernel will be a slow process here. Ideally use another, more powerful, desktop Ubuntu system.
  • Install tools and source: sudo apt-get install build-essential linux-source-2.6 libncurses5-dev kernel-package
  • Go to the source: cd /usr/src
  • Unpack it: tar -xvjf linux-source*
  • Drop in to it: cd linux-source
  • Where to start? You might want to use an existing config file, so you could: cp /boot/config-<whatever> .config (Note that leading dot on the second file name)
  • Configure the kernel: sudo make menuconfig
  • Which options?: sorry, but if you cannot choose the options yourself then, honestly, you should not be building a customised kernel in the first place! Of course drop me a line and if I was nice I could send you a copy of my config file. 🙂
  • OK, I’ll relent and mention a few options, at least insofar as to what makes the server image a server image. But I’ll not go into details – you’ll need to do some research to learn more about these:
    • The I/O scheduler: a desktop system will typically use CFQ or, maybe, Anticipatory. A server will more typically want to have a default scheduler of Deadline.
    • Preemption. Desktops normally want a preemptive kernel. A server generally wants a non-preemptive kernel.
    • PAE. This is the option that caused us all this grief in the first place. So you do not want PAE support in the kernel. Except that it’s not mentioned by name. To disable PAE support you need to make sure the high mem model is set to 4GB, not 64GB.
    • You want on-demand interrupt timers, so select the “tickless” option. And for a server the “Hertz” setting for the interrupt rates is probably best set to 100 (somewhat lower than a desktop system)
  • And of course a zillion other choices to make too. Take particular care in the networking selections, as getting that wrong will cause subtle but very significant issues later when we try to get the firewall working.
  • Then build it all with: sudo make-kpkg kernel_image kernel_headers
  • Go up: cd /usr/src
  • Grab the debs: there will be two .deb packages there. These need to be transported to the VIA system and installed using “dpkg -i *deb”
  • Boot the server. If it works first time then, damn, you’re either very good or very lucky!
  • When the kernel does one day boot to completion start work on mopping up the error messages from the boot!! A prime example being the AppArmor module not loading… You need to either remove AppArmor altogether or, alternatively, rebuild it against your new kernel’s headers.

Remember: you do NOT need to do this. Building a customised kernel, particularly on this non-mainstream hardware, is great fun, but not at all easy. Only do it if you want to, not because you have to!

Basic configuration – Networking – Back to easy stuff

Before we get all carried away about installing non-standard software, let’s get the basic config right. This device is going to act as a firewall router, so we need to designate one Ethernet port as External (i.e. facing the Internet) and the other as Internal (facing the private network).

The internal interface is going to need a fixed IP address (pedants might say that a quasi-fixed address via DHCP would also do – but, clever clogs, this server is itself going to act as our DHCP server, so that wouldn’t be such a cool idea now, would it?). The external interface might or might not require it to be fixed. It depends on what network environment you have. Here in France, the ADSL termination equipment supplied by ISPs varies in its capabilities.

A FreeBox, for example, can terminate the ADSL but bridge the Ethernet across to the external port, thus allowing us to have a true Public IP address on our external interface. We’d want to set up the external port to use DHCP to the ISP. We would do this since (a) the address might change and (b) it allows us to pick up the DNS servers being used automatically.

However a LiveBox, unfortunately, cannot bridge the Ethernet connection, and the Public IP address sits on the LiveBox itself. So here you will want to do something like designate, on the LiveBox, the server’s external port as the DMZ destination for all traffic. In strictly networking terms you end up with two private networks, one each side of the server, with traffic being NAT’ed twice (on the server and the LiveBox) and where you treat the private network on the external side of the server as, for all practical purposes, a public network. Slightly inelegant but from a performance point of view it works just great.

So decide what you need and go to /etc/network/interfaces to configure it.

More software!

Where to start? We know we’re going to install various other things, but let’s try and break it all down in to administrative tools and applications themselves. Remember that as we installed the server edition of Ubuntu, we’ve already got MySQL, Apache and PHP installed and running in a default form. Here we consider what else will aid our administration of the server, before moving on to both advanced configuration of the server and the addition of application software.

For administration we might want to consider:

  • phpMyAdmin
  • Webmin
  • synaptic

Some will quibble about synaptic, as it doesn’t do anything you can’t do from the command line using “apt-get”. And, ’tis also true, installing it pulls in a certain amount of X-related libraries that were not there before. Your call. Frankly, I like it, but feel free to skip it. If used, though, remember that this server will be headless, so we need a X-server capability on the desktop PC being used to initiate something like synaptic. If that desktop PC is itself a Linux desktop system, then that’s likely no problem, but if we will admin from, say, a Windows system then we’d need something like Xming to run X apps back to our desktop display.

Webmin too is not required. But, again, I like it and it makes my life so much easier, most particularly when it comes to administering the Shorewall firewall. So we’ll install it. Alas it’s a bit fiddly to install, at least as compared with your average Ubuntu package installation. Here’s a summary of the steps required:

  1. sudo apt-get install openssl libauthen-pam-perl libio-pty-perl libmd5-perl
  2. wget http://ftp.fi.debian.org/debian/pool/main/libn/libnet-ssleay-perl/libnet-ssleay-perl_1.30-1_i386.deb
  3. sudo dpkg -i libnet-ssleay-perl_1.30-1_i386.deb
  4. wget http://garr.dl.sourceforge.net/sourceforge/webadmin/webmin_1.350_all.deb
  5. sudo dpkg -i webmin_1.350_all.deb

And phpMyAdmin? The zealots will tell you that you can do it all from the command line. But for those of us who only occasionally need to delve into MySQL administration, I greatly recommend it.

On the plus side, both Webmin and phpMyAdmin are web-based applications, so unlike synaptic they do not pull in too much in the way of generic cruft.

What else?

The list so far will give you a very useful generic server platform, that does…. well not much yet. We’ve got the infrastructure now, and what we actually do with it is pretty much a personal choice. Refer back to “Software Choices” in part one of this trilogy, and I mention that I install a web-based Torrent Client and a Media Center server. Of course one can also crank up NFS and/or Samba servers to act as remote disk space within the local network.

Apart from the big apps, it’s the little odds and sods you can set up which are so handy. Also on my network I have a big, fat-but-stupid NAS device (basically a big hard disk accessible via the network) It’s great for direct access by workstations – they all back up critical data to it throughout the day. But in turn I wish to back up parts of my NAS off-site, to a server somewhere far, far away. That’s where a small-but-smart home server is so useful. A couple of lines of rsync configuration, a dash of crontab activation and my local backups are magically mirrored to the remote server.

4 comments to Building a home server – Software