Support: 1-800-961-4454
Sales Chat
1-800-961-2888

Inside My Home Rackspace Private Cloud, OpenStack Lab, Part 2: The Networking

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.

About the Author

This is a post written and contributed by Kevin Jackson.

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.


More

Leave a New Comment

(Required)


Racker Powered
©2014 Rackspace, US Inc.