Configuring Intel Solaris is similar to Linux. The low level startup boot process is the same as Windows and Solaris, mainly the use of a PXE loader to start the process, however in order to keep the top level menuing consistent for the client, and to work around a dhcpd configuration issue, it was required to chain together Sun’s version of PXEgrub with PXELinux.

In both the Intel and Sparc cases, a request to boot is dropped on the wire, the dhcpd server accepts the request and issues a reply packet containing the IP address for the PXE client, the IP address of the next server to speak to, and the filename that the PXE client needs to request, still PXELinux for the first stage. For Sparc Solaris, the filename that the bootloader needs to request is not a PXE loader, but instead is the actual Solaris supplied boot file.

The operating system makes use of the PXE Loader configuration. Please go read that post if you have yet to do so as general configuration details are described in that article.

Please take note that a conscious design decision was made at this point to chain the bootloaders to present a mostly unified menu system to the end user. It is possible to create an Intel Solaris stanza in the dhcpd.conf and add the mac addresses of each host that would need to boot off of pxegrub instead of pxelinux. However, this would require the modification of the configuration and restarting of the dhcpd service for each new intel host added.

Since, in the environment, there were an exceptionally small number of Sparc hosts to be installed, and new Sparcs were added intermittently at best, it was considered more desirable to touch the dhcpd files only for the Sparcs rather than the often multiple installs/day required of the Intel machines. This would then allow the scheduling of dhcpd restarts during a maintenance window.

There was one modification made to the dhcpd.conf file which needs to be made regardless of the architecture. The following option statements need to be added to the file somewhere near the PXElinux lines that were added to support PXE booting.

option SUNW.root-mount-options code 1 = text;
option SUNW.root-server-ip-address code 2 = ip-address;
option SUNW.root-server-hostname code 3 = text;
option SUNW.root-path-name code 4 = text;
option SUNW.swap-server-ip-address code 5 = ip-address;
option SUNW.swap-file-path code 6 = text;
option SUNW.boot-file-path code 7 = text;
option SUNW.posix-timezone-string code 8 = text;
option SUNW.boot-read-size code 9 = unsigned integer 16;
option SUNW.install-server-ip-address code 10 = ip-address;
option SUNW.install-server-hostname code 11 = text;
option SUNW.install-path code 12 = text;
option SUNW.sysid-config-file-server code 13 = text;
option SUNW.JumpStart-server code 14 = text;
option SUNW.terminal-name code 15 = text;

These vendor specific lines assign human readable names to the various SUNW codes that are used to set various parameters such as the root path, the swap file, and the like.

The pxelinux menu entry needs to be changed to point to the location of the Sun PXEgrub file placed in the boot tree, and a menu.lst file will need to be created to support that bootloader. The single Solaris entry in my environment looks like this:

label solaris
kernel /boot/grub/pxegrub.0

In my boot directory you can find a grub directory containing the files pxegrub.0 and menu.lst. The menu.lst file is grub’s version of the default entry. It must always be named menu.lst either via the actual filename or through a tftp filename remap. After reading through the Solaris pxegrub source it seems highly likely that this filename cannot be changed via a vendor ID code in the dhcpd.conf file despite what the manpages say.

The three line Solaris 10 entry in my sample menu.lst looks like:

title Solaris 10 Interactive
kernel /images/SOL_10_U3_x86_64/boot/multiboot kernel/unix – install nowin dhcp -B install_media=172.16.32.16:/export/install/images/SOL_10_U3_x86_64
module /images/SOL_10_U3_x86_64/boot/x86.miniroot

The first line is the title as it will appear in the grub menu. The second describes the kernel file to load including all switches passed to the kernel. Given the strange wrapping, please take note that the line ends with the install_media stanza found in the SOL_10_U3_x86_64 directory. Finally, the final line specifies the module the kernel will need to load in order to run properly.

For an Intel installation, the prep work is completed and there remains only the image to prepare. For the sparc image, the dhcpd.conf file will need to be edited each time a new sparc host is added and the following stanza will need to be added and/or updated:

group {
vendor-option-space SUNW;
option SUNW.JumpStart-server “172.16.32.16:/export/JS/sol8/configs”;
option SUNW.install-server-hostname “gorgon”;
option SUNW.install-server-ip-address 172.16.32.16;
option SUNW.install-path “/export/install/images/SOL_9_U8_x86″;
option SUNW.root-server-hostname “gorgon”;
option SUNW.root-server-ip-address 172.16.32.16;
option SUNW.root-path-name “/export/install/images/SOL_9_U8_x86/Solaris_9/Tools/Boot”;
next-server 172.16.32.16;

host solclient01 {
hardware ethernet 00:0c:29:e3:e9:94;
fixed-address 172.16.33.69;
option host-name “solclient01″;
option SUNW.sysid-config-file-server=”172.16.32.16:/export/install/jumpstart”;
}
}

Each new sparc addition will require the addition of a new host substanza in this group. You’ll need to gather the mac address of the new host as well as assign it a static IP address. Once the configuration file has been updated, simply restart dhcpd and the configuration changes are complete. As a side note, installations were done using a small preallocated pool of statics outside the dhcpd range and then the host was reconfigured once the installation was complete.

Now that dhcpd has been setup, we can setup the images. Substitute x86_64 with SPARC as appropriate in the examples. Note that the solaris media comes on DVDs and so there is only a single image to copy.

mkdir /export/install/images/SOL_10_U3_x86_64 # or the path for the real vers.
mkdir -p /mnt/{1,2,3,4…N} # one per ISO
mount -o loop /path/to/iso/SOL_10_U3_x86.iso /mnt/1
…
mount -o loop /path/to/iso/SOL_10_U3_x86.iso /mnt/N
.
tar -C /mnt/1 cpvf – | tar -C /export/install/images/SOL_10_U3_x86_64/ -xpf -

When finished, in /export/install/images/SOL_10_U3_x86/ directory you should have the following directories: boot, Solaris_10, and a Copyright and installer file. Note that there is only a single ISO released from Sun. If the host is 64 bit capable the Solaris OS will boot in 64 bit mode. If the host is only 32 bit capable the OS will boot on its 32 bit kernel. The directory naming of _64 was chosen to remain consistent with the other directory names.

Next confirm that the boot/ directory contains the files you supplied paths to in the grub menu.lst, mainly multiboot and x86.miniroot:

ls -al /export/install/images/SOL_10_U3_x86_64/boot/
grep boot /export/install/boot/menu.lst

And that concludes all of the image prep necessary. The next item to configure is the apache server to ensure it can serve the http content from the /export/install mountpoint. To do so we need to edit the configuration of apache and add a section allowing the webserver to find our content at /images/. Edit the httpd.conf and add the following in an appropriate location, or use this snippet to create a new file uniquely named along the lines of install.conf in the httpd/conf.d directory, if present.

Alias /images/ /export/install/images/
< directory >
Options Indexes FollowSymLinks
AllowOverride Limit
Order allow,deny
Allow from all
< /directory >

Apache needs to then be restarted or HUP’ed for the configuration changes to take effect.

Unless the entire installation is being done over HTTP, Solaris also introduces the need for an NFS server for the image shares. How this is done will be dependent on your operating system, but assuming the nfs software is installed on the machine, in order to nfs export /export/install one needs to try one of the following:

Linux:
edit /etc/exports and add
/export/install *(ro)
service nfsd restart

Solaris:
edit /etc/dfs/dfstab and add
share -F nfs -o ro -d “Image Mounts” /export/install

All that is left now is to test the individual components:

First we need to make sure dhcpd is running:

ps -ef | grep dhcpd

Next we ensure apache is running:

ps -ef | grep httpd

Next ensure that nfsd is running:

ps -ef | grep nfs

Now we make sure that the repository is in proper order:

ls -al /export/install/boot/pxelinux # check for pxelinux
ls -al /export/install/boot/grub/pxegrub # check for pxegrub
ls -al /export/install/boot/grub/menu.lst # check for pxegrub’s menu file
ls -al /export/install/boot/default # check for the default menu file for your entry
ls -ald /export/install/images/SOL_10_U3_x86_64 # ensure the image is there
ls -ald /export/install/images/SOL_10_U3_x86_64/boot # should return 3 files: grub, multiboot, x86.miniroot

Now we make sure that tftp is working as expected (remember that tftp was chrooted to /export/install so everything will be relative to that path):

tftp localhost
cd images/SOL_10_U3_x86_64/boot/
get x86.miniroot

Next we ensure the apache is serving content properly.

wget http://localhost/images/SOL_10_U3_x86_64/boot/x86.miniroot

if, for some reason, you dont have wget on your server you can do it manually using telnet:

telnet localhost 80
HEAD /images/SOL_10_U3_x86_64/boot/x86.miniroot HTTP/1.0

Finally we test the NFS shares. Mount the filesystem on another machine if possible:

mount -o ro yourserver:/export/install /mnt
cd /mnt/images/SOL_10_U3_x86_64/boot
ls -al x86.miniroot

This essentially concludes the work required to net install a Solaris installation.

After finishing the configuration, all that is left is to reboot the machine and netboot using the F12 key, and then select the newly added menu entry from the pxelinux menu when prompted. Grub will then start and present its menu to you. From there select the entry you desire and then just wait until you reach the Solaris blue and green configuration screens.

Again, If you have any problems or questions, drop me a line and I’ll see what I can do to help. If there is interest in the topic, moving from an interactive installation to the configuring of jumpstart may be discussed in a later article should there be interest in the topic. If this article sounds familiar it is because I followed the guidelines I established in the Linux article. ;)

>>> Karl

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

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