In the first part of this series, I introduced the kit that makes up my home lab. There’s nothing unusual or special in the kit list, but it certainly is affordable and makes entry into an OpenStack world very accessible.

This post explains some more basics of my networking: DHCP, DNS, Proxy and TFTP.

Rather than settle for the DHCP and DNS services provided by my broadband provider’s ADSL router, and given that I want to be able to do more than simply turn on a laptop or tablet and surf the ‘net, configuring a separate DHCP and DNS service is important and offers most flexibility on your network. This becomes important later on when setting up Rackspace Private Cloud using Chef: it’s requirement to have consistent FQDN for its nodes is one you don’t want to leave to chance and expect things to work as expected.

DHCP and DNS: Dnsmasq

To provide DHCP and DNS on my network, I utilize Dnsmasq on my QNAP TS-210 NAS (nas.home.mydomain.co.uk / 192.168.1.1). Installation on my QNAP is as simple as enabling the Optware plugin which allows me to simply install Dnsmasq using the following:

ipkg update
ipkg install dnsmasq

Configuration of Dnsmasq is then done in /opt/etc/dnsmasq.conf (/opt is where the QNAP places optional packages)

The uncommented sections of the file (i.e non-defaults):

# Use an alternative resolv.conf
# I use this to point a real external DNS service (i.e. don't point to itself!)
resolv-file=/opt/etc/resolv.conf
# Ensure the areas that Dnsmasq wants to read/write to/from is set correctly
user=admin
group=everyone
# for queries of hosts with short names, add on the domain name
expand-hosts
# my domain name to ensure FQDN queries all work as expected
domain=home.mydomain.co.uk
# DHCP Setup
# First the dynamic range for those that join my network
dhcp-range=192.168.1.20,192.168.1.50,12h
# Some static entries (i.e. the servers openstack1-5)
dhcp-host=64:70:02:10:4e:00,192.168.1.101,infinite
dhcp-host=64:70:02:10:6d:66,192.168.1.102,infinite
dhcp-host=64:70:02:10:48:11,192.168.1.103,infinite
dhcp-host=64:70:02:10:4e:22,192.168.1.104,infinite
dhcp-host=64:70:02:10:88:33,192.168.1.105,infinite
# A laptop that has a LAN and Wifi adapter - give it the same IP regardless
dhcp-host=5c:96:aa:aa:aa:aa,a8:20:bb:bb:bb:bb,192.168.1.19
# Some options for setting the gateway (which is my ADSL router IP)
# Some clients don't understand some DHCP options, so present both ways
dhcp-option=3,192.168.1.254
dhcp-option=option:router,192.168.1.254
# Ensure this is writeable by Dnsmasq
dhcp-leasefile=/opt/var/lib/misc/dnsmasq.leases
# When we're PXE Booting, where's the TFTP service (and filename to boot when found)
dhcp-boot=pxeboot/pxelinux.0,nas2,192.168.1.2
# And finally, this is the authoritative DHCP server on network
dhcp-authoritative

The above basically tweaks a default Dnsmasq set up to work on my network. I have a small DHCP range for any device I don’t care too much about (tablets, laptops, phones, Blu-Ray, TV, etc.). I then have a static block that match my servers — when they boot up they will always get that IP. And I have a line that allows me to control the same IP on a laptop whether I connect via the LAN or WiFi. This allows me to do some basic IPtable filtering on hosts based on IP – trusting that IP for example if need be.

For DNS, Dnsmasq relies on /etc/hosts – and reads this on startup. My hosts file on my Qnap is as follows:

For the vast majority of devices on my network, I don’t care enough to provide any entries. For the devices that I rely on for services and OpenStack, I put in here. The result is a very basic Dnsmasq setup that provides an important, fundamental job on my network.

You will also note a line pointing to my second NAS device denoted by the dhcp-boot line. This instructs any machine when they’re PXE Booting to go look at that IP for the boot image.

TFTP from Dnsmsaq + Kickstart

Now we have the basic services running on the network, we can take advantage of another feature of Dnsmasq: TFTP services. This allows me to PXE/Network boot my servers with Ubuntu 12.04 and by running some post commands once Ubuntu has been laid down gets my environment ready for a Rackspace Private Cloud installation.

Due to proximity of my network services and my servers, and a WiFi link being involved, I opted to run TFTP on another QNAP NAS (my QNAP TS-121 nas2.home.mydomain.co.uk / 192.168.1.2), which is connected to the same Gigabit switch as my servers. Dnsmasq was installed the same way on this second QNAP (by way of the Optware plugin and installation of dnsmasq package using ipkg command). The contents of /opt/etc/dnsmasq.conf on this second NAS are as follows (everything else is hashed out defaults, as before):

Booting this as it stands now will give you a graphical installer that allows you to install Ubuntu interactively. This is fine, but we prefer to automate all the things. To do this we edit the ubuntu-installer/amd64/boot-screens/txt.cfg file to give a choice in the menu to do an install of Ubuntu applicable. Mine is as follows:

Be careful with that first append line under the Kickstart Install stanza – it’s a single line, line-wrapped for this blog.

With this in place I now get a couple of options when I PXE boot a server (Pressing F12 during the N40L boot process), one of which is the option to do a Kickstart Install. This Kickstart Install option specifies a few things on the boot “append” line; particularly the http_proxy option and the ks option. The http_proxy option is fairly obvious – we’re passing the address and port of a proxy server to use as part of the installation. I’m specifying the proxy server running on my second NAS2 at address 192.168.1.2 where Squid has been setup to cache large objects so it can cache deb packages. The ks option specifies a kickstart configuration file to run as part of the installation, automating the options of the installation from choosing packages to formatting disk options, etc. This kickstart file is available on an anonymous FTP address running on the same NAS2 device and looks like the following:

A few things (this is clearly intended for a lab, feel free to edit and improve!): the result should be something that is convenient to you through automation. I set a user up called openstack – this is a requirement of Ubuntu to have a user other than just root set up. I also just pull down some scripts and items useful for my setup, one of which is a tarballed /root/.ssh/ directory. This has keys and .ssh/authorized_keys already pre-setup for when we get to do an install of Rackspace Private Cloud, which uses Chef that relies on an ability to ssh amongst the machines.

At this point, after PXE booting the five servers in my home lab setup, I have Ubuntu 12.04 installed and root keys ready to have Rackspace Private Cloud installed. On my ADSL setup, kicking the five machines takes about 15 minutes, which is an acceptable time to kick my lab and allows me to try various runs of installations – speed and automation are important for any lab.

In the next post I’ll cover off the steps to get a high availability (HA) Rackspace Private Cloud installed using the Rackspace Chef cookbooks.

Share this post:

Kevin Jackson, the author of OpenStack Cloud Computing Cookbook, is part of the Rackspace Private Cloud Team and focuses on assisting enterprises to deploy and manage their Private Cloud infrastructure. Kevin also spends his time conducting research and development with OpenStack, blogging and writing technical white papers.