The blog of Karl Majer…

Ah, the wonderful world of MS Windows. An environment ripe with complexities and peculiarities unique to the GUI based world loved and scorned by many. Traditionally, the windows installation procedure requires a windows RIS server to handle the duties of the installation server. The production Multi-OS install server was ultimately a Redhat EL 5 64bit host, however all of my development work and the prototype were built on an intel Solaris 10 64 bit installation.

The system built for the client, however, made use of both a single box running tftp, samba, and the python RIS implementation from http://oss.netfarm.it/guides/pxe.php. The basic setup is as follows:

TFTP – tftp-hpa 0.42 – With remap and with tcpwrappers was chosen as the tftp server to be used. The using of tcpwrappers is generally a good practice, but the remap function was the desired functionality in this version of tftpd. RHEL 5 ships with this binary as an rpm. The map file will be explained in further detail in when the image preparation is discussed.

SAMBA – samba 3.023c-2 – Was selected as the version of samba to run. Again, this was available as an rpm on RHEL 5 and made the selection easy. The following lines were added to the smb.conf configuration file to support the RIS installation environment:

encrypt passwords = yes
null passwords = yes
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
idmap uid = 16777216-33554431
idmap gid = 16777216-33554431
template shell = /bin/false
winbind use default domain = no
guest account = nobody
map to guest = Bad User

The last line allows any user that fails authentication to map to the guest account. If the samba server is setup on a different domain than the rest of the organization, as it was in the case on this network, the desktop computers will have access to the CIFS shares to pull cabs, or other files, from the CD images available on the shares. Note: While testing on unix using smbclient, the share name is \\\\HOST\\SERVICE. If you happen to add a trailing \\ on the end, the service name wont match and the connection will fail with a “tree connect failed: NT_STATUS_BAD_NETWORK_NAME.”

RIS – The UDA v 1.4 provided the foundation binlsrv.py and infparser.py files that were used to initialize the 32 bit OSes. As written, the core binl code needed to be refactored and extended for the intelligent inclusion of additional operating systems, both 32 and 64 bit. The biggest change was made to the infparser and allows it to read the list of operating systems to be parse from a text file. A link to my updated versions of the files can be found here: binlsrv.py, infparser.py, and windirs.conf.sample.

Once the requisite software has been installed, the image will need to be prepared. This will be covered in the next section entitled “Multi-OS Installation: Configuring the Windows Image.”

The production system and the prototype were built on differing operating systems. Solaris 10 was initially used to allow for native Solaris Jumpstart procedures for Jumpstarting Solaris 9 on both Intel and Sparc. While migrating the completed prototype to RHEL 5.0 64, the Sparc Solaris issues, Sparc lacking  pxe boot loader capabilities to boot the operating system, were addressed by adding the appropriate stanzas to the dhcpd configuration files.

Unless otherwise specified, the Solaris installation was built from the source tarball, whereas the Linux installation came from an official RedHat RPM. This typically accounts for any version differences found between the two operating systems.

The network services required to fully netboot and install a machine are as follows:

• At the lowest level there is a dhcp server listening for initial boot requests. ISC’s dhcpd server, specifically version 3.0.6 which was the current version at the time. On the RHEL machine, version 3.0.5, was used.
• A tftp server is required to make the necessary files available. The files in question could be either pxe bootloaders for Linux and Solaris 10, the actual boot files in the case of Solaris 9, and the WINNT bootloader in the case of Windows. Tftp-hpa version 0.42 was chosen as the tftp server of choice as it supported the remapping of file paths in requests, and offered tcp wrappers as an added bonus.
• An HTTP server is made available on the network to support Solaris jumpstart and Linux kickstart. The server offers media for both of the installation processes. The Apache that shipped with Solaris 10, Apache/2.0.58, and the Apache that shipped with RHEL 5, Apache/2.2.3, worked without a problem.
• An NFS server is made available on the network to support Solaris installations including jumpstart. The server offers the entire media tree to any client that may desire it. Linux NFS servers may have problems with Solaris clients on anything other than NFSv2. The converse is not true.
• To support windows, a CIFS needed to be offered. Samba was picked as it is the primary software of choice. Version 3.023c-2 was used on RHEL, 3.025c on Solaris.
• RIS Services are required to properly net install a Windows machine. The software used was a python implementation of the binl server and is covered in greater detail in the Windows section.
• Additionally, OS ISOs for every operating system to be installed must be obtained for both the Windows and Unix environments. This must be done in accordance to appropriate licensing for each respective OS.

The delivered product was capable of installing: Linux RHEL 3,4,5 32 and 64 bit variants, Solaris 9, 10, both intel and sparc at multiple releases, Windows 200[03], XP, both 32 and 64 bit including the unpatched and last two service pack levels. All in all a total of 27 windows offerings, 6 Solaris offerings, and 6 Linux offerings were available to any server or desktop that supported pxe booting.

More to come…

>>> Karl

Recently a client expressed interest in having me build an installation environment wholly contained on a single, preferably unix, server. The client had a requirement of being able to Kickstart any RedHat/Fedora Linux distribution they chose, Jumpstart Solaris 9 & 10 for Sparc and Intel, and net install a wide range of windows installations. The unix installation environments were straightforward, both taking advantage of the pxe bootloader environment. Linux uses pxelinux, and Solaris uses a Sun modified version of pxegrub. Windows was an entirely different issue.

After a bit of research I decided to use a combination of the theory behind the Ultimate Deployment Appliance (UDA) VM, available from http://www.vmware.com/appliances/directory/232 , VMWare’s appliances directory, as well as the information found on the RIS for Linux site located at http://oss.netfarm.it/guides/pxe.php around which the UDA is built.UDA v1.4 was already capable of booting a considerable variety of 32 bit windows images, however it lacked the ability to easily add 64 bit images. Additionally, there was no need for the pretty HTML GUI that the package offered and so they were omitted in favor of a pxelinux and pxegrub menu system.

This series of articles will describe how the system was built as well as provide examples on how to build your own. It will be written in several parts, at least one for each of Solaris, Linux, and Windows, and the Windows article may be further subdivided into several more.

More will follow as time permits.

>>> Karl