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.”
Comments on this entry are closed.
Great stuff! If you don’t mind I’ll be using your ideas for the UDA. I’m especially interested in the solaris sparc article that is about to come. Your changes to the binl python scripts are also very welcome! By the way: Is there a reason you chose a 64 bit RHEL?
RHEL is what the customer was running most of their infrastructure on and what was desired. There is no reason that the entire system couldn’t run on any other OS that is vaguely GNUish with functional compilers.
I realize I’m digging up some relatively old bones, but…
I have successfully set up my own Linux-based PXE/RIS server that is regularly distributing installations of 32-bit 2k3, 2k3 r2, and XP. I have been trying to figure out how to get the binlsrv.py script from the ris-linux package to handle both 32-bit and 64-bit drivers, but there doesn’t seem to be any support for it.
I googled, and found your page with a reference to your own “extended” version of binlsrv.py and infparser.py, but the links seem to be dead. I don’t suppose there’s any way to convince you to re-post the scripts so that I can attempt to implement them?
Most of the links I can find are over a year and a half old, so I am beginning to wonder if there has been some sort of new technique I’ve missed that would solve the distribution of both architectures via linux-based BINL.
Links are fixed, sorry about that. Seems I neglected to copy over the various scripts/configs when I upgraded wordpress last.