Linux and Windows deployment
Contents
Introduction
This document covers the setup and deployment of a pxe boot solution consisting of 2 pxe servers and one dhcp server. The 2 pxe servers are linux and windows - the former running pxelinux and tftp and the latter one running WDS (Windows Deployment Services), with a linux server providing DHCP services. This document will describe the setup of the Linux PXE server and the Linux DHCP server.
Motivation
Because it's perfectly possible to use a windows WDS solution running in "legacy" mode (having RIS enabled) to pxeboot and network install linux hosts one might ask why should one bother with having 2 pxe servers on one network, if one can do the trick. This was indeed the setup we were using prior to this change, but we've experience numerous problems booting linux machines from a windows powered solution:
- not possible to manage the windows host using standard tools like ssh and text editors
- very difficult to deploy updated boot files / linux kernels to the storage location on the windows host
- overlap of responsibilities - windows admins take care of the windows machines, but linux admins needed to have access and knowledge about the pxe boot solution
Because of these reasons we've decided to split Linux and Windows altogether, having a Linux pxe boot server for the linux clients and a windows WDS for the windows clients.
Architectural overview
The way network deployment works in this scenario is:
- A client starts up, broadcasts for it's IP address
- The DHCP server checks if the client is a known client (it's defined in a configuration file) and gives it it's IP
- The DHCP server also knows if the client is "windows" or "linux" - each group of clients have their separate config file
- The DHCP server gives the client it's IP and points it to the correct pxeboot server
- Client loads pxe information and proceeds
DHCP server setup
Main configuration file
The DHCP server acts as an "arbitrator" in that it sends the client to either the Linux pxe server or the windows WDS server. As mentioned before, this is done by assigning the client to a specific group of hosts. In this case, we will have 2 groups - one for linux clients and one for windows clients, and each group will have a file associated with it, containing client definitions. This means that our DHCP config will consist at a bare minimum of 3 configuration files - the main config, the linux hosts and the windows hosts. Let's start with the main dhcp configuration:
authoritative;
ddns-update-style interim;
allow booting;
allow bootp;
option routers 192.168.3.1;
option subnet-mask 255.255.255.0;
option domain-name "test.al.com.au";
option domain-name-servers 10.10.1.8;
group {
# linux hosts
use-host-decl-names on;
include "/etc/dhcp/hosts/linux.hosts";
next-server 192.168.3.14;
filename "/pxelinux.0";
}
group {
# windows hosts
use-host-decl-names on;
include "/etc/dhcp/hosts/windows.hosts";
next-server 192.168.3.8;
# Windows deployment server settings
option tftp-server-name "192.168.3.8";
option bootfile-name "boot\\x86\\wdsnbp.com";
}
shared-network ALtest
{
subnet 192.168.3.0 netmask 255.255.255.0
{
option netbios-node-type 8;
option routers 192.168.3.1;
}
}
The global options are quite standard DHCP options and you can put anything you want here, as long as these two are kept:
allow booting; allow bootp;
These two options tell the DHCP server that it should respond to bootp requests and that it should give out boot information to hosts. They are on by default, but it helps having them explicitly stated. Now we have the group definitions:
group {
# linux hosts
use-host-decl-names on;
include "/etc/dhcp/hosts/linux.hosts"; #Include the linux hosts from a separate file
next-server 192.168.3.14; #This points to the linux PXE server. It can be either IP or FQDN
filename "/pxelinux.0"; #This is the PXElinux kernel that gets booted. Resides on the PXE server
}
group {
# windows hosts
use-host-decl-names on;
include "/etc/dhcp/hosts/windows.hosts"; #Include the windows hosts from a separate file
next-server 192.168.3.8;
# Windows deployment server settings
option tftp-server-name "192.168.3.8"; #The tftp-server-name and bootfile-name directives must be present for the windows booting to work
option bootfile-name "boot\\x86\\wdsnbp.com";
}
Notice also that we're pointing to boot\x86\wdsnbp.com. What if we're imaging 64bit hosts also? No problem, this kernel file will automatically detect if the host is 64bit or 32 bit, and will send the correct boot kernel file to the windows host.
Host file formats
There are several ways one can write entries into host files for dhcp, I'm listing one of them for reference:
/etc/dhcp/hosts/linux.hosts:
host pxeclient { hardware ethernet 00:50:56:04:03:0f; fixed-address pxeclient.test.al.com.au; }
PXE Server setup
The PXE server uses PXELINUX and it's setup is detailed quite well in the PXELINUX document. To recap in short, the PXE server will need to have tftp enabled, and have the correct PXE files present in the root of the tftp server. Then you'll need to copy over the linux kernels for the different linuxes that you wish to boot, create the menus and then optionally add images to pretty print the entire setup. For reference, i am including the output of the tree command, which shows how I've structured my pxe server directory.
/tftpboot/ |-- 0README |-- chain.c32 |-- images | |-- centos | | |-- 4 | | | |-- x86 | | | | `-- 4.6 | | | | |-- initrd.img | | | | `-- vmlinuz | | | `-- x86_64 | | | `-- 4.7 | | | |-- initrd.img | | | `-- vmlinuz | | `-- 5 | | |-- x86 | | `-- x86_64 | | |-- 5.1 | | | |-- README | | | |-- initrd.img | | | `-- vmlinuz | | `-- 5.3 | | |-- README | | |-- initrd.img | | `-- vmlinuz | |-- esx | | `-- 3.5 | | `-- u4 | | |-- initrd.img | | `-- vmlinuz | |-- misc | | |-- clonezilla | | |-- memtest | | | `-- memtest86+-4.00.bin.gz | | `-- rescue | `-- rhel | |-- 4 | | |-- x86 | | | `-- 4.6 | | | |-- initrd.img | | | `-- vmlinuz | | `-- x86_64 | | `-- 4.4 | | |-- README | | |-- TRANS.TBL | | |-- initrd.img | | `-- vmlinuz | `-- 5 | |-- x86 | `-- x86_64 | `-- 5.3 | |-- README | |-- TRANS.TBL | |-- initrd.img | `-- vmlinuz |-- mboot.c32 |-- memdisk |-- menu.c32 |-- pics | |-- 300.png | |-- al_swan.png | |-- guardians.png | |-- happyfeet.png | |-- knowing.png | |-- matrix.png | `-- zombie.png |-- pxelinux.0 |-- pxelinux.cfg | |-- default | |-- menu | | |-- default_workstation | | |-- tools | | |-- x86_64_servers | | |-- x86_64_workstations | | `-- x86_servers | `-- screens | |-- expert.msg | |-- general.msg | |-- help.msg | |-- param.msg | `-- rescue.msg `-- vesamenu.c32
It's also perfectly possible to have the PXE and tftp setup reside on the same server as the DHCP server, but in our environment we chose not to. It depends entirely on your environment. As for menu configuration, there are plenty of links and documents out there, and there is great documentation included in the syslinux package itself (it usually lives in /usr/share/doc/syslinux-*/)
Conclusion
If you follow this setup, you will be able to boot your hosts into either the linux pxe menu that you prepared and image them to linux, and have the same flexibility for windows hosts. (they will boot into a WDS boot menu). Also, you will have the flexibility to change the designation of your hosts - changing a host from windows to linux and vice versa is as simple as removing the host entry from one definition file and adding it into the other one. Using this mechanism you will also have an authoritative copy of which of your hosts are windows and which one are linux.
