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:
127.0.0.1 localhost localhost 192.168.1.1 NAS NAS 192.168.1.2 NAS2 NAS2 192.168.1.101 openstack1.home.mydomain.co.uk openstack1 192.168.1.102 openstack2.home.mydomain.co.uk openstack2 192.168.1.103 openstack3.home.mydomain.co.uk openstack3 192.168.1.104 openstack4.home.mydomain.co.uk openstack4 192.168.1.105 openstack5.home.mydomain.co.uk openstack5
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):
# Ensure the areas that Dnsmasq wants to read/write to/from is set correctly user=admin group=everyone # Enable TFTP service enable-tftp # Where to put the pxeboot images (our Ubuntu netboot image) tftp-root=/share/HDA_DATA/Public
We now have a TFTP service, but it’s no good without any images to boot from. Since I’m interested in running RPC on Ubuntu 12.04, I head over to grab an Ubuntu 12.04 ISO and copy the /images/netboot/pxeboot directory to /share/HDA_DATA/Public. If you don’t have an Ubuntu 12.04 ISO handy, you can grab this directory and files from here http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd64/current/images/netboot/.
You will end up with a directory called /share/HDA_DATA/Public/pxeboot with the following files in:
pxelinux.0 -> ubuntu-installer/amd64/pxelinux.0 pxelinux.cfg -> ubuntu-installer/amd64/pxelinux.cfg/ ubuntu-installer/ version.info
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:
default ks label ks menu label ^Kickstart Install menu default kernel ubuntu-installer/amd64/linux append vga=788 initrd=ubuntu-installer/amd64/initrd.gz http_proxy=http://192.168.1.2:3128/ ks=ftp://192.168.1.2/Public/ubuntu/ks.cfg -- quiet label install menu label ^Install kernel ubuntu-installer/amd64/linux append vga=788 initrd=ubuntu-installer/amd64/initrd.gz -- quiet
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:
lang en_GB langsupport en_GB keyboard gb timezone Etc/UTC text install skipx reboot url --url http://gb.archive.ubuntu.com/ubuntu/ rootpw --disabled user openstack --fullname "openstack" --password openstack authconfig --enableshadow --enablemd5 clearpart --all --initlabel zerombr yes part /boot --fstype=ext2 --size=64 part swap --size=1024 part / --fstype=ext4 --size=1 --grow bootloader --location=mbr firewall --disabled %packages ubuntu-minimal openssh-server screen curl wget sshpass git %post apt-get update apt-get upgrade -y # setup locales locale-gen en_GB.UTF-8 update-locale LANG="en_GB.UTF-8" echo 'LANG=en_GB.UTF-8' >> /etc/environment echo 'LC_ALL=en_GB.UTF-8' >> /etc/environment # Set up root keys (all use same root key - NOT FOR PROD!) wget -O /tmp/root-ssh-key.tar.gz ftp://192.168.1.2/Public/ubuntu/root-ssh-key.tar.gz cd /target tar zxf /tmp/root-ssh-key.tar.gz # Pull down installer for later use wget -O /root/install-openstack.sh ftp://192.168.1.2/Public/ubuntu/install-openstack.sh chmod 0700 /root/install-openstack.sh # Convenient script to power off all my machines wget -O /root/all-off.sh ftp://192.168.1.2/Public/ubuntu/all-off.sh chmod 0700 /root/all-off.sh
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.