Linux Quickies – Putting it all together

In the previous sequence of posts, I’ve documented how you can build a RCSL server that can act as a DHCP, DNS, NFS, Web and Time server.

But why do each one in isolation? Why not build a single server that is configured to be all of those things, so that when all is done, it acts as giant ‘toolbox’ of network services to your entire network? Actually, there is a good reason not to do that, called “single point of failure”. But in a home network/test lab environment, I don’t think that’s an important consideration. So the all-in-one toolbox approach sounds good to me!

You’ll notice from all those previous posts, though, that setting up each of these network services often takes a lot of typing -and thus has a high risk of getting something wrong.

So can we automatically build a single server that can provide all these services, configured correctly ‘out of the box’? Sure we can: and it’s our old friend Kickstart that will work this particular brand of magic. And here is a Kickstart script that will do everything discussed in the previous 6 posts, all in one, completely automatically:

#  =======================================================================
#  This Kickstart script written by Howard Rogers. 
#  Copyright (c) 2013 Howard Rogers,Dizwell Informatics
#  The script is supplied "as-is" with no warranties or guarantees of 
#  fitness of use or otherwise. Neither Dizwell Informatics nor 
#  Howard Rogers accepts any responsibility whatsoever for any 
#  damage caused by the use or misuse of this script.
#  =======================================================================

lang en_US.UTF-8
keyboard us
network --onboot yes --device eth0 --bootproto static --ip --netmask --noipv6 --nameserver --hostname marconi.dizwell.home
firewall --disabled
authconfig --enableshadow --passalgo=sha512
selinux --disabled
timezone Etc/GMT
bootloader --location=mbr --driveorder=sda --append="crashkernel=auto rhgb quiet"
clearpart --all
part / --fstype=ext4 --size 20000 --grow
part swap --size 1024

chkconfig iptables off

# Configure NFS Server
mkdir /griddata
mkdir /dbdata
echo "/dbdata,sync,no_wdelay,insecure_locks,no_root_squash)" > /etc/exports
echo "/griddata,sync,no_wdelay,insecure_locks,no_root_squash)" >> /etc/exports
chkconfig nfs on
service nfs start

#Configure DHCP Server
echo "option domain-name            \"dizwell.home\";" > /etc/dhcp/dhcpd.conf
echo "option domain-name-servers;" >> /etc/dhcp/dhcpd.conf
echo "default-lease-time   600;" >> /etc/dhcp/dhcpd.conf
echo "max-lease-time 6000;" >> /etc/dhcp/dhcpd.conf
echo "authoritative;" >> /etc/dhcp/dhcpd.conf
echo "subnet netmask {" >> /etc/dhcp/dhcpd.conf
echo "range dynamic-bootp;" >> /etc/dhcp/dhcpd.conf
echo "option broadcast-address;" >> /etc/dhcp/dhcpd.conf
echo "}" >> /etc/dhcp/dhcpd.conf
chkconfig dhcpd on
service dhcpd start

#Configure DNS Server
echo "options {" > /etc/named.conf
echo "    directory \"/var/named\";" >> /etc/named.conf
echo "    dump-file \"/var/named/data/cache_dump.db\";" >> /etc/named.conf
echo "    statistics-file \"/var/named/data/named_stats.txt\";" >> /etc/named.conf
echo "    memstatistics-file \"/var/named/data/named_mem_stats.txt\";" >> /etc/named.conf
echo "    allow-query { localhost;; };" >> /etc/named.conf
echo "    recursion yes;" >> /etc/named.conf
echo "    dnssec-enable no;" >> /etc/named.conf
echo "    dnssec-validation no;" >> /etc/named.conf
echo "    dnssec-lookaside auto;" >> /etc/named.conf
echo "    /* Path to ISC DLV key */" >> /etc/named.conf
echo "    bindkeys-file \"/etc/named.iscdlv.key\";" >> /etc/named.conf
echo "    managed-keys-directory \"/var/named/dynamic\";" >> /etc/named.conf
echo "    };" >> /etc/named.conf
echo "    logging {" >> /etc/named.conf
echo "        channel default_debug {" >> /etc/named.conf
echo "       file \"data/\";" >> /etc/named.conf
echo "       severity dynamic;" >> /etc/named.conf
echo "         };" >> /etc/named.conf
echo "    };" >> /etc/named.conf
echo "    zone \".\" IN {" >> /etc/named.conf
echo "         type hint;" >> /etc/named.conf
echo "         file \"\";" >> /etc/named.conf
echo "    };" >> /etc/named.conf
echo "    zone \"dizwell.home\" IN {" >> /etc/named.conf
echo "        type master;" >> /etc/named.conf
echo "        file \"dizwell.hosts\";" >> /etc/named.conf
echo "    };" >> /etc/named.conf
echo "    include \"/etc/named.rfc1912.zones\";" >> /etc/named.conf
echo "    include \"/etc/named.root.key\";" >> /etc/named.conf

echo "\$TTL 86400" > /var/named/dizwell.hosts
echo "@ IN SOA marconi.dizwell.home. (" >> /var/named/dizwell.hosts
echo "2013030501 ;Serial" >> /var/named/dizwell.hosts
echo "3600 ;Refresh" >> /var/named/dizwell.hosts
echo "1800 ;Retry" >> /var/named/dizwell.hosts
echo "604800 ;Expire" >> /var/named/dizwell.hosts
echo "86400 ;Minimum TTL" >> /var/named/dizwell.hosts
echo ")" >> /var/named/dizwell.hosts
echo "" >> /var/named/dizwell.hosts
echo "        IN NS   marconi.dizwell.home." >> /var/named/dizwell.hosts
echo "        IN A" >> /var/named/dizwell.hosts
echo "" >> /var/named/dizwell.hosts
echo "marconi         IN A" >> /var/named/dizwell.hosts
echo "alpher          IN A" >> /var/named/dizwell.hosts
echo "bethe           IN A" >> /var/named/dizwell.hosts
echo "alpher-priv    IN A" >> /var/named/dizwell.hosts
echo "bethe-priv    IN A" >> /var/named/dizwell.hosts
echo "alpher-vip      IN A" >> /var/named/dizwell.hosts
echo "bethe-vip       IN A" >> /var/named/dizwell.hosts
echo "racscan         IN A" >> /var/named/dizwell.hosts
echo "racscan         IN A" >> /var/named/dizwell.hosts
echo "racscan         IN A" >> /var/named/dizwell.hosts
echo ";; end of zone" >> /var/named/dizwell.hosts
echo ";;" >> /var/named/dizwell.hosts

echo "search dizwell.home" > /etc/resolv.conf
echo "nameserver" >> /etc/resolv.conf
chown named:named /var/named/dizwell.hosts
#service named start
chkconfig named on

#Configure NTP Server
echo "server" > /etc/ntp.conf
echo "fudge stratum 2" >> /etc/ntp.conf
echo "driftfile /var/ntp/ntp.drift" >> /etc/ntp.conf
echo "statsdir /var/ntp/ntpstats/" >> /etc/ntp.conf 
echo "filegen peerstats file peerstats type day enable" >> /etc/ntp.conf
echo "filegen loopstats file loopstats type day enable" >> /etc/ntp.conf
service ntpd start
chkconfig ntpd on

#Configure Web Server

if [ `lsb_release -d | grep 6.4 | wc -l` -eq 1 ]; then
elif [ `lsb_release -d | grep 6.3 | wc -l` -eq 1 ]; then

DISTRO=$(lsb_release -is)
if [ $DISTRO = "CentOS" ]; then
  mkdir -p /var/www/html/centos/$VERSION
elif [ $DISTRO = "OracleServer" ]; then
  mkdir -p /var/www/html/oel/$VERSION
elif [ $DISTRO = "Scientific" ]; then
  mkdir -p /var/www/html/sl/$VERSION
  mkdir -p /var/www/html/unknown/$VERSION  

mount /dev/sr0 /media
cp -rvf /media/* /var/www/html/$DISTRO/$VERSION
umount /media
service httpd start
chkconfig httpd on


This script works with any of the mainstream 64-bit RCSL distros: it’s been tested on 64-bit CentOS 6.3 and 6.4, Scientific Linux 6.3 and 6.4 and Oracle Enterprise Linux 6.3 and 6.4,

To use it, obviously you first need appropriate O/S installation media. Use the full DVD media that allows fully-functional installs from a single DVD, because the script can’t cope with changing DVDs half-way through an installation. Here are where I sourced my test ISOs from:

(Red Hat installation media are only available to paying customers, so I figure you’ll already know where to go on the Red Hat portal to get the appropriate ISO!)

The Kickstart script itself then needs to be copied to somewhere that your “toolbox server” can find it during O/S installation: a floppy disk is good, but they are getting a bit thin on the ground, physically, these days! A USB stick might do the job, too. But, for my money, the simplest approach is to burn it onto a CD (or ISO CD image). If 700MB or 4.7GB for a single text file seems a bit extravagant, so be it: at least it works. :-)

Here is an ISO file containing the above script. Burn it to a physical CD/DVD if you like, or use it as an ISO file to help boot a virtual machine. Of course, the Kickstart file it contains is hard-wired to build a server called Marconi with an IP address of, as per my previous posts. If you want a different configuration, you’ll have to build your own ISO having edited the script, first.

This Kickstart-on-DVD arrangement would mean, of course, that your physical server would need two DVD drives installed: the first to hold the O/S DVD media and the second to hold the Kickstart file. That might be a tall order on a physical server (though USB external DVD drives could potentially come to the rescue), but it’s easy on a virtual machine: just add the extra hardware at the time you create the new virtual machine:

That’s in VirtualBox: note that the full Linux installation disk is listed before the toolbox.iso: that’s important, because the boot disk has to be the first in order of boot priority. If the toolbox disk is listed first, you’ll be trying to boot from a text file… and that won’t work! Just alter the “IDE Primary/Secondary Master” and “IDE Primary/Secondary Slave” drop box against each disk until your boot disk is primary master and your toolbox ISO is listed as primary slave or secondary master/slave.

After that, you just have to intervene briefly at boot time:

As for any Kickstart installation, you simply press TAB when the boot welcome menu appears. That displays some existing text (vmlinuz initrd=initrd.img) and all you have to do is, as you see here, append a bit of information to say where your Kickstart file is. Mostly, that just means correctly identifying the device it’s stored on.

If your Kickstart file was stored on a floppy disk, the device identifier would be hd:fd0 (that’s a zero, not an oh). Since mine is on a secondary CD drive, my device identifier is as you see it here: hd:sr1. In either case, the Kickstart file itself is called “toolbox.ks”, so you just stick that on the end of the appropriate device identifier. In my case, I end up with:


The hardest part is working out your device names -and that might take a bit of trial and error. But once you get it right, your involvement in the rest of the installation will be absolutely minimal:

  • You may be prompted to agree to having your hard disk wiped, but only if it’s a completely new hard disk that has never been partitioned before. If you’re re-using a pre-loved hard disk, it will be wiped without any prompting.
  • You will be prompted once for a root password (typed in twice).

Other than that, the entire installation will complete automatically, and all the network services discussed over the past 6 posts (DHCP, DNS, NFS, NTP and Apache) will be auto-configured without any manual intervention on your part. At the end of the installation, therefore, you’ll be owner of a self-contained, highly functional Linux ‘toolbox’.

Remember, if you’re doing this in a Virtual Machine, that I’m expecting your toolbox to have just 512MB RAM, at least a 25GB hard disk and to be using Host-only networking.

To show you how painless it all is, here’s a video of me doing practically nothing! (I’ve cut out nothing, but I suggest you play it back at 2x or 3x speed, so that it’s not quite as boring as it was originally!):

Key features of the movie:

  • At ~0:38, I am asked to re-initialise the disk, because this one had never been used before. I select the Re-initialize all option.
  • At ~0:44, I supply a root password (twice)
  • At ~3:33, the installation process ends and the post-installation scripts are run. This involves copying the installation media itself from DVD to hard disk. Since about 4GB of data is involved, it takes a while to complete.
  • At ~5:00, I am asked to reboot. Once the machine does so, I log on as root and demonstate that all the network services are up and running -after precisely three bits of user input.

Assuming you can view the toolbox.ks file in a text editor that can display line numbers, here are a few observations about the file, referenced to the various lines.

Line 11: The RCSL install that uses this Kickstart file will do a text-mode install. This is good, because a server providing all the network services I’ve mentioned only needs around 512MB of RAM -but that’s not enough memory to do a graphical installation.

Line 15: The Server will end up part of the dizwell.home domain (you can obviously edit this to suit), and have an IP address of

Line 16: The Firewall is disabled. It’s a blunt approach: we should more properly open up ports 80, 53 and so on. But this is simpler: and it works!

Line 18: SELinux is disabled. SELinux afficionados will disapprove, but again, simply disabling it means everything works without fuss.

Lines 21 – 23: The server will expect a hard disk of at least ~25GB. Most of that will be assigned to a single root partition at least 20GB in size (but it can grow bigger than that if the disk space is there); a 1GB swap partition is also created. Note that this will wipe any hard disk it’s pointed at… making it lethal. If you don’t want a hard disk wiped, don’t use this script!

Lines 25 – 70: The bare minimum of software is installed. You’ll note that NFS, Apache, Bind (DNS), DHCP and NTP are all added to the mix, though.

Lines 73 – 79: Pretty much a re-hash of my recent ‘quickly build an NFS server’ post

Lines 81 – 92: Pretty much a re-hash of my recent ‘quickly build a DHCP server’ post

Lines 94 – 155: Pretty much a re-hash of my recent ‘quickly build a DNS server’ post

Lines 157 – 165: Pretty much a re-hash of my recent ‘quickly build an NTP server’ post

Lines 195 – 196: Getting the Apache webserver running and ensuring it runs at every server reboot thereafter, as explained in the ‘quickly build a webserver’ post.

Lines 192 – 194 Potentially the most important lines of the lot, because they ensure that the server copies its own installation DVD to hard disk -thus making it able to host future over-the-network installs of other RCSL servers. As future posts here will explain, that capability is going to become significant.

Linux Quickies #6 – Build a Time Server

The last in a short series of posts concerning things I’ve probably documented elsewhere (though not always) but which could do with being re-stated or refreshed a bit. This series closes with a look at how to make a freshly-built RCSL server act as an authoritative NTP time server.

Do all that follows as root.

1. Install the software

yum install ntp

2. Configure the server

vi /etc/ntp.conf

Add the contents:

fudge stratum 2
driftfile /var/ntp/ntp.drift
statsdir /var/ntp/ntpstats/
filegen peerstats file peerstats type day enable
filegen loopstats file loopstats type day enable

These server lines look a bit like an IP address, but is actually a pseudo address. The 127 elements basically say “I am a time server”, whilst the “1″ element in the address tells the ntp daemon to use the server’s own system clock as the source of time information. The fudge line says “any clients who are configured to use me as their source of authoritative time will think I am a Stratum 2 time server (pretty darn’d accurate, in other words).”

3. Start the service

service ntpd start
chkconfig ntp on

The first command starts the NTP daemon immediately; the second configures it to auto-start every time the server is bounced.

4. Configure Clients

Any client that you want to make use of the new time server should have the ntp software installed and its /etc/ntp.conf file configured as follows:

driftfile /var/ntp/ntp.drift
statsdir /var/ntp/ntpstats/
filegen peerstats file peerstats type day enable
filegen loopstats file loopstats type day enable

…which is pretty much the same sort of thing as the time server itself has -except it has no fudge component because the client isn’t pretending to be a server; and the server component is the IP address of the remote time server being sought as a source of time, rather than a pseudo address.

Linux Quickies #5 – Build a DHCP Server

The fifth in a short series of posts concerning things I’ve probably documented elsewhere (though not always) but which could do with being re-stated or refreshed a bit. This time, it’s time to turn a freshly-built RCSL server into a DHCP server -one that other boxes can look to to be assigned IP addresses dynamically.

As ever, do all that follows as root.

1. Installation and Configuration

yum install dhcp
vi /etc/dhcp/dhcpd.conf

Clear out any existing content and replace it with…

option domain-name            "dizwell.home";
option domain-name-servers;
default-lease-time   600;
max-lease-time 6000;
subnet netmask {
  range dynamic-bootp;
  option broadcast-address;

This configuration is hopefully quite self-explanatory. It simply states what domain IP addresses are allocated for and the length of time they’ll be allocated (in seconds). The meat is really in the last three lines: I’m asking for addresses in the – 240 range to be served up by this server to any 192.168.8.x client that wants them.

This is a very minimal configuration file: it’s sufficient for my purposes, but I haven’t tried to cover things like fixed IP addresses for specific clients (so-called “lease reservations”) or dynamic updates of DNS. Generally, this is because my servers run things like Oracle and, as such, would generally be configured with completely static IP addresses anyway. The only use for DHCP I really have, in fact, is for doing Kickstart installations of servers: the new build needs a dynamically-assigned IP address just until it gets to the part where a proper, static one can be assigned.

2. Switch On

chkconfig dhcpd on
service dhcpd start

The first command ensures DHCP will start at every subsequent server reboot; the second switches the DHCP daemon on right now.

Linux Quickies #4 – Build an NFS Server

The fourth in a short series of posts concerning things I’ve probably documented elsewhere (though not always) but which could do with being re-stated or refreshed a bit. This time, it’s how to turn a freshly-built RCSL distro into a functioning NFS server. As always this depends on having basic networking already sorted, which was discussed in the first post of the series.

Do all that follows as root:

1. Install the software

yum install rpcbind nfs-utils

2. Create some directories

mkdir /griddata
mkdir /dbdata

These are just examples: you can create your shared directories anywhere you like and call them anything you like, too, of course. But these two are fine for my purposes and keep things simple.

3. Configure Shares

vi /etc/exports

Add the following to the file


This says that the two directories I created are made available to any other host on the 192.168.8… network. A bunch of share options are then specified, chosen to allow maximal access but minimal inconvenience to clients.

4. Start it up

/etc/rc.d/init.d/rpcbind start
/etc/rc.d/init.d/nfslock start
/etc/rc.d/init.d/nfs start
service nfs restart
chkconfig nfs on

These first four commands get the NFS service working initially; the last command ensures it starts automatically at every subsequent server reboot.

Linux Quickies #3 – Build a DNS Server

The third in a short series of posts concerning things I’ve probably documented elsewhere (though not always) but which could do with being re-stated or refreshed a bit. This time, it’s how to turn a freshly-built RCSL distro into a functioning DNS server. As before, this depends on having basic networking already sorted, which was discussed in the first post of the series.

Note that in this article, I’m only going to bother doing forward names resolution. That is, I’m going to configure my DNS server to be able to turn the hostname “alpher.dizwell.home” into an IP address of I’m not interested here in being able to turn an IP address back into a hostname, which is called reverse names lookup. If you are interested in doing that, my full-blown DNS article has the details.

Finally, note that the example data used in this article suits the networking setup I described in an earlier post. You would obviously want to change domain names, host names and IP addresses to suit your own environment.

Anyway… let’s get on!

Do all that follows as root:

1. Install the software

yum install bind bind-utils

2. Configure the “named” service

vi /etc/named.conf

Remove all existing content and add the following:

options {
    directory "/var/named";
    dump-file "/var/named/data/cache_dump.db";
    statistics-file "/var/named/data/named_stats.txt";
    memstatistics-file "/var/named/data/named_mem_stats.txt";
    allow-query { localhost;; };
    recursion yes;
    dnssec-enable no;
    dnssec-validation no;
    dnssec-lookaside auto;

    /* Path to ISC DLV key */
    bindkeys-file "/etc/named.iscdlv.key";

    managed-keys-directory "/var/named/dynamic";
logging {
    channel default_debug {
        file "data/";
        severity dynamic;
zone "." IN {
     type hint;
     file "";
zone "dizwell.home" IN {
    type master;
    file "dizwell.hosts";

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

Note that this configuration doesn’t include anything about “forwarders” –DNS servers to forward lookup requests to if this server can’t resolve them itself. That’s because the network this is intended for can’t get to the Internet (see the earlier post for an explanation of why this is a design feature!), and therefore there’s nothing to forward to. Forwarding is included in my full-scale DNS article, though.

3. Configure the forward lookup zone

vi /var/named/dizwell.hosts

#Add the following
$TTL 86400
@ IN SOA marconi.dizwell.home. (
2013030001     ;Serial
3600         ;Refresh
1800         ;Retry
604800         ;Expire
86400         ;Minimum TTL 

        IN NS   marconi.dizwell.home.
        IN A

marconi         IN A
alpher          IN A
bethe           IN A
gamow          IN A
dalton          IN A
tesla           IN A
;; end of zone

4. Finish Up

vi /etc/resolv.conf

Make sure the following lines exist:

search dizwell.home

You set these two lines to tell a machine which host is acting as the DNS server for lookups in which zone. Here, I’m configuring the DNS server itself to know that it should consult itself for lookups that involve anything to do with the dizwell.home domain. All other servers I build as part of this domain will also need to have the resolv.conf file configured in this way.

service named start
chkconfig named on

The first command turns on the “named” service now; the chkconfig command ensures it restarts automatically every time the server is rebooted. Once the service is running correctly, you should be able to do something like this:

nslookup bethe

That should return a result such as:


Name:    bethe.dizwell.home

…which indicates that a successful name resolution lookup has been performed. Note that this should work even if you haven’t built a server called “Bethe” yet. The point is that the DNS server knows what IP address that name maps to, regardless of whether the IP address is actually being used yet or not.

Linux Quickies #2 – Build a Webserver

The second in a short series of posts concerning things I’ve probably documented elsewhere (though not always) but which could do with being re-stated or refreshed a bit. This time, it’s how to turn a freshly-built RCSL distro into a functioning web server -which depends on getting networking right, as documented in the previous piece.

Do all that follows as root:

1. Disable SELinux

vi /etc/selinux/config

Change the line:


…to read:


SELinux prevents the web server working properly. There are ways of configuring SELinux so that it doesn’t do that, but it’s a pain and I’m not documenting it here. You don’t have to completely disable SELinux: setting the parameter to permissive will keep it switched on, but it will just warn (quietly) that web serving breaches policy, rather than stopping web serving in its tracks.

2. Disable (or modify) the Firewall

Issue these commands:

service iptables stop
chkconfig iptables off

These two commands switch off the firewall and prevent it from re-starting. Without these commands, port 80 is blocked by default, so although your web server runs, no-one would be able to talk to it, which is a bit pointless. If you prefer having a firewall switched on, you can leave it on by issuing neither of those two previous commands and instead, just open up ports 80 and 443 (for https traffic), inbound and outbound, like so:

vi /etc/sysconfig/iptables

Add these lines BEFORE the two existing REJECT statements:

-A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT 
-A INPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT
-A OUTPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT 
-A OUTPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT


service iptables restart

3. Install and configure the Software

Issue these commands:

yum install httpd
service httpd start

If you want to configure lots of subtle options, then the configuration file is available in /etc/httpd/conf/httpd.conf -but usually, everything just works OK without any further configuration. You can at this point open a browser on a remote PC and enter the url (or whatever your web server’s IP address is). If all is well, you’ll see a test page that will just say “It works!” (if you’re using Scientific Linux) or a more elaborate test page with banner, graphics and explanatory text (if you’re using CentOS).

Your document root is /var/www/html, so drop any files you want to view via http in there, and change your remote browser’s URL to match. For example:

vi /var/www/html/dizwell.html

Add the following line, then save:

<h1>This is a Dizwell web page</h1>

Now browse remotely to and you’ll see this:

Linux Quickies #1 – Static IP and Hostname

A short series of posts concerning things I’ve probably documented elsewhere (though not always) but which could do with being re-stated or refreshed a bit.

We begin with: How to assign a static IP address and a proper hostname to a machine that has neither (perhaps because a minimal install of RCSL distro).

Do all that follows as root:

vi /etc/sysconfig/network-scripts/ifcfg-eth0

Add these lines:



service network restart
vi /etc/sysconfig/network

Add these lines:



hostname alpher.dizwell.home
vi /etc/hosts

Add a line which reads something like: alpher.dizwell.home alpher

That is, the machine’s IP address needs to be matched up to a fully-qualified hostname (one with a domain name component) and a short-form hostname (one lacking the domain name component).

Finish off with:


CentOS 6.4

Well done to the CentOS team who have, again, managed to build their new release (6.4) from Red Hat sources just two weeks or so after Red Hat published their new code. (RH6.4 was released February 21st; CentOS 6.4 was released last Saturday, 9th March. Impressive -and they beat Scientific Linux to the punch once more. Oracle Enterprise Linux 6.4 was out a week earlier still, of course, but I kind of expect Oracle Corporation to do that: they have significant resources to bring to bear on it, after all).

The release itself doesn’t have anything you might call significant in it, as the increment in merely the minor version number more-or-less tells you in advance.

Oracle and run on it fine, and a Kickstart file that does duty for auto-configuring a 6.3 server performs flawlessly for a 6.4 server, too.

Splendid Isolation

Here is my home network (or a bit of it, anyway):

(I apologise in advance for lack of abilities when it comes to using Dia, the Linux equivalent of Visio!)

What you have there is not very exciting: a couple of Centos-running servers called NEWTON and GALILEO, one of which connects to the Internet, thanks to a wireless dongle and the magic of 3G. There’s a wireless access point, handling all the “devices”: Nexus 7, Kindles, Smartphones and the like. Then there’s FEYNMAN, ToH’s Windows 8 PC doing sterling duty as a Photoshop workstation. RUTHERFORD’s the media centre (also running Windows 8, but with Windows Media Centre added). And my new PC is DIRAC, running Fedora 18. Everything is running on a 192.168.0… subnet.

I probably should expand this diagram, though: there are 7 different virtual machines which run routinely on Dirac: they all share the 192.168.0 subnet thanks to ‘bridged networking’ in VMware Workstation and can therefore access Galileo and, from there, the Internet. Though they are merely virtual machines in fact, they behave exactly as real, physical machines would: by sharing the same subnet as the PC they run on, they look just like real machines to all the other real machines on the network. Bridged networking is fine for VMs that are allowed to function as though they were real.

But here’s the problem: what if I want a bunch of new virtual machines to be able to talk amongst themselves as though they were part of a normal network but without any of the existing, physical machines being aware of the fact? For example, I may want to build a DHCP server -but I don’t want any of my ‘real’ PCs accidentally picking up their IP address from it. Similarly, I may want to build a new DNS server -but I wouldn’t want FEYNMAN trying to look up hostnames there.

The underlying reason for needing this ability is, in fact down to my laptop (which isn’t shown in the above diagram). I use it at work, so it needs to see proper, commercial DNS, DHCP, NTP and other servers -but if I want to run VMs on my laptop that are running their own DNS, DHCP, NTP and other servers, I have to be able to ensure that whatever I build can never, ever “leak” out onto the real network. I need, in fact, complete isolation of my network of virtual machines running on my laptop from the real corporate network my laptop is physically connected to.

Fortunately, this is easy to do with VMware Workstation -and VirtualBox: both employ a feature misleadingly called host-only networking. I say ‘misleadingly called’ there, because that name implies (to my mind, anyway) that virtual machines making use of it can only communicate with the physical host. If that were true, you could ‘network’ the host to the VM -but you’d be stuffed trying to network one VM with another VM. But happily, it’s the name that’s wrong, not the functionality: host-only networking in both virtualisation products actually means that any VM built to use the feature can communicate with the physical host and with every other host-only VM, too.

So here’s the network I want to build:

The virtual network is all the grey/brown-coloured stuff at the bottom. My physical PC, DIRAC, will host six different virtual machines, all running in host-only mode, and using the 192.168.42 subnet. Note that DIRAC itself acquires a second IP address, allowing it and it alone both to connect to the rest of the world and to connect to any of the 192.168.42 virtual machines.

How exactly is that to be achieved, then? Well, if I persist with my usual desktop virtualisation software (VMware Workstation), I’d find the menu option for the Virtual Network Editor (in Linux, you can launch it from the command-line by typing /usr/bin/vmware-netcfg -you’ll be prompted to supply root’s password if you’re not root at the point of issuing that command):

When you install VMware Workstation, you get three different network interfaces created for you automatically: one of them is used for bridged networking, one for Network Address Translation …and one for host-only networking. Highlight that last one and you’ll be able to alter its properties in the lower part of the screen. Here you see that I’ve switched off the virtual DHCP server that VMware offers to run for you on this interface; I’ve also altered the default subnet IP so that it matches my desired ’192.168.42…’ subnet address range. Leave the last octet of that address set to zero and you will find that your physical host PC or laptop is automatically assigned a address, which is fine.

You can create as many of these host-only network interfaces as you like: each one will create a new network adapter (if your host is running Windows) or a new network interface, visible via ifconfig, if your host runs Linux), meaning that if your host PC is powerful enough, there’s nothing to stop it running multiple, isolated virtual networks at the same time.

VirtualBox does it slightly differently: just use the File → Preferences menu options to bring up a Settings dialog, then select the Network item:

By default (at least on Fedora 18!), you don’t have any host-only network adapters installed here, but if you click that little green ‘plus’ button, a new one will be created for you and will be automatically named virtualbox0. After creating it, click the third little icon on the right to configure its settings:


Again, just type in a ‘starting address’ for your new isolated network. With VirtualBox, I find it necessary to specify the ‘.1′ at the end of the IP address, otherwise it doesn’t work properly. By specifying the address in full, therefore, I ensure my physical host is assigned that IP address on its new virtualbox0 interface. (As you can see from that last screenshot, too, I don’t have much use for IPv6 at the moment!)

Finish things off by switching to the DHCP Server tab and uncheck the ‘Enable Server’ option: again, VirtualBox proposes to run a virtual DHCP server for you, which you might find desirable, but which I definitely don’t!

Incidentally, if you happen to have VMware Workstation and VirtualBox installed on the one physical guest, make sure each uses a different isolated subnet, because they can’t both be configured to use the same one meaningfully! In other words, if I’ve created a 192.168.42.x host-only subnet in VMware, I’ll have to create a 192.168.43.x host-only subnet in VirtualBox. Networking won’t work reliably if you try assigning the same IP address to two different interfaces at the same time!

Once your network interfaces are configured properly, it’s simply a matter of choosing the right sort of networking for each new Virtual Machine that you build. In VMware, you do that as part of the ‘create new VM’ wizard:

By default, VMware threatens to create new VMs with a NAT interface, but it’s easy to switch to using a host-only one.

VirtualBox is not as easy, because the wizard you use to create a new VM doesn’t offer you any opportunity to specify anything about the network interface to use at all. It’s therefore necessary to create a new VM ‘blind’, and after it’s been created, right-click it and select Settings. Select the Network item on the left:

You’ll discover that, once again, a NAT interface has been assigned to your new VM by default. Just click that combo-box, though, and you’ll find an item for Host-only adapter. Select that, click OK, and you’re all done.

Once built, you’ll find that all your host-only VMs can ping each other and your physical PC on which they’re running -but they won’t be able to ping beyond your physical PC. That means, in my case, that ALPHER and BETHE can ping each other, or MARCONI, TESLA or DIRAC (my physical PC). But they won’t be able to ping GALILEO -and since GALILEO controls access to the Internet, that means my host-only VMs can’t reach the Internet, either.

For my purposes, that’s fine: why would I need an Oracle server (say) to be able to access the Internet? You wouldn’t normally do that in production (I hope!), so having a set of servers that behave similarly is not a problem for me. It does mean I have to have one of my VMs hosting a software repository from which my other VMs can download packages and so on necessary for running Oracle (or anything else), but that’s usually not difficult to do.

The main issue is easily solved, therefore: host-only networking allows your virtual machines and all the networking services they provide and consume to be completely isolated from the rest of the world -and any real corporate networks your physical PC might be attached to at the time! Splendid!!

(Oh, and as a side benefit: my laptop will be able to run a virtual network of six VMs even when I’m running it on a train and it’s stuck in a tunnel without a 3G signal. The virtual network will keep running just fine, even if the physical one decides to die -or even if you don’t have a physical network at all. Host-only VMs are a great way of virtualising networks on standalone PCs, in other words).

Toshiba P870, Fedora 18 and Networks

Fedora’s recent upgrade to the 3.8.1-201 kernel may have broken VMware Workstation (though now fixed by upgrading that to the latest 9.0.2 release), but it was a good day for networking on my Toshiba P870 laptop.

I mentioned a while ago that neither the wireless nor the gigabit Ethernet adapter worked out-of-the-box on this particular laptop when I first installed Fedora 18. There were some downloads and compilations needed before either would work -and then, those bits of compilation failed to re-compile if the kernel was ever updated, so I had to fiddle with setting default Grub menu options so that only the original 3.6 kernel would ever be used.

Well, as I say, the upgrade to the 3.8.1 kernel has fixed most of that: wireless networking now works without having to recompile or install anything. The gigabit Ethernet adapter still doesn’t work by default, though -which, I think, is the first time I’ve ever heard of wireless networking functioning better on Linux than the wired variety!

It is not difficult to fix, though. Just visit this site and download the 3.8.1 compat-driver file of your choice (I decided to use the bzip2 one). Extract the download, then as root:

cd compat-drivers-3.8-1-u
./scripts/driver-select alx
make install

Finish off when prompted with a modprobe alx and your wired network will be back up and running in no time.

Happily, this means I no longer need to force my laptop to boot the old 3.6 kernel, so it’s time to un-default that particular boot option. As root,

gedit /etc/default/grub

There’ll be a line in there which reads GRUB_DEFAULT=<something>. Just change the “something” to an unquoted zero (i.e., the line should end up reading GRUB_DEFAULT=0), That will now boot whatever the latest kernel happens to be.

If you ever want to re-set a default boot option, then type (as root):

grep menuentry /boot/grub2/grub.cfg

…and copy whichever of the single-quoted menu items displayed is the one you want to be the default, and set the GRUB_DEFAULT in the /etc/default/grub file to that.