Today's Page Hits: 4
This page validates as XHTML 1.0, and will look much better in a browser that supports web standards, but it is accessible to any browser or Internet device. It was created using techniques detailed at glish.com/css/.
As part of my day job, I run a small lab of machines for my team. We've got 15 Sun x86 servers, split about evenly between v60z and v20x machines. Plus, a bunch of Sparc workstations.
One of the important features of this lab is the ability to punch a great big RESET button, and get a fresh OS install on a machine. So there is a network boot and install server, holding install images of the current versions of Solaris NV, 10, and 9; both SPARC and x86 versions. Plus a rudimentary bit of logic to have a user select which image to install, and a bit of minimal configuration.
Maintaining this takes a surprising amount of fiddling. SPARC network boot I had down cold a long time ago, that part gives me few headaches. The main thing that needs done there is making sure the OS images are kept up to date. The area that gives me trouble now are the x86 machines.
For the SPARC machines, I've got pretty much just one generic set of configuration for all machines. About all I need to keep track of is which OS version to install on which machine, and I'm done.
The simple problem with x86 network boot and install is that it's in flux, and each machine behaves somewhat differently. A good example comes in the differences between the v60z and v20x machines. I have no access to any of the graphical consoles, and I sit 140 miles away from this lab. So everything is done remote, and mostly through CLI tools, and access to serial consoles. Well, the serial console on the v60z is wired to the second serial port (ttyb, or COM2). The v20z's are a more complex story. From the OS persective, the serial port is the first one (ttya, or COM1). From my perspective, they are a pain to get to, since I have to ssh into the v20z service processor, and issue a command there. In order to have x86 machines boot, ignore the graphical console, and use the appropiate serial port requires different configuration for the v20z and the v60x, and a slightly different process.
Next, how Solaris itself boots has been in flux. Starting with Solaris10 U1, there was a shift from the old way of booting to using GRUB. I think that this is a great thing, but it did mean that I had to spend a bit of time figuring out how to configure both boot systems, and write a script to set one or the other up on demand. Plus, deal with Solaris 9's quirks in that regard - an effort I've pretty much abandoned. Everyone - for doing any serious work on x86 machines, don't use Solaris 9. Solaris 10 U1 or later works a lot better.
Lately, I took on a new challenge - figure out how to net boot and install Red Hat Enterprise Linux. To my surprise, it wasn't that hard - this Sun Blueprint let me through what I needed to configure.
The hardest part, really, was dealing with Red Hat's kickstart configuration files. RedHat doesn't seem to have a way where I can provide a configuration template, and tell it 'Yes, this boot is doing DHCP for installing, use the address assigned via DHCP as your static address once done' - an idiom that Solaris easily gets right.
My last challenge - I noticed that Solaris 10, Solaris NV, and Red Hat can all boot via grub, and yes! I can have one grub menu that boots any of those OSes. Only ... because there are differences between the v20z, v60x, and VMWare - I have to have different boot templates for each of them in the menu.lst. Grr.
Here's a incomplete recipie to do a netboot of a random x86 machine. There may well be pieces missing, don't complain to me if you try exactly what I put here and it doesn't work.
First, there's a magic DHCP macro that needs defining:
PXEClient:Arch:00000:UNDI:002001
:BootSrvA=192.0.2.1:BootFile="pxegrub.I86PC.Solaris_11-1":
Also on the boot server, there needs to be a file boot/grub/menu.lst available through TFTP.
Contents of menu.lst:
default=0
timeout=30
#
# Solaris 10
title Solaris_10 Jumpstart
kernel /I86PC.Solaris_10-2/multiboot kernel/unix - install -B install_config=192.0.2.1:/export/home/jumpstart,sysid_config=192.0.2.1/export/home/jumpstart,install_media=192.0.2.1:/export/s10u2/combined.s10x_u2wos/latest
module /I86PC.Solaris_10-2/x86.miniroot
#
# Solaris NV
title Solaris_11 Jumpstart
kernel /I86PC.Solaris_11-1/multiboot kernel/unix - install -B install_config=192.0.2.1:/export/home/jumpstart,sysid_config=192.0.2.1/export/home/jumpstart,install_media=192.0.2.1:/space/nv/combined.nvx_wos/latest
module /I86PC.Solaris_11-1/x86.miniroot
#
# Red Hat Linux
title Red Hat Linux 4 Update 3 - 32bit
kernel /rhel4-u3-i386/vmlinuz ksdevice=eth0 ks=nfs:192.0.2.1:/export/redhat/kickstart/ks.cfg load_ramdisk=1 network
initrd /rhel4-u3-i386/initrd.img
#
# Red Hat Linux
title Red Hat Linux 4 Update 3 - 32bit v60x
kernel /rhel4-u3-i386/vmlinuz ksdevice=eth0 ks=nfs:192.0.2.1:/export/redhat/kickstart/v60x.cfg load_ramdisk=1 network console=ttyS1,9600n8
initrd /rhel4-u3-i386/initrd.img
#
# Red Hat Linux
title Red Hat Linux 4 Update 3 - 64bit
kernel /rhel4-u3-x86_64/vmlinuz ksdevice=eth0 ks=nfs:192.0.2.1:/export/redhat/kickstart/ks64.cfg load_ramdisk=1 network
initrd /rhel4-u3-x86_64/initrd.img
#
# Red Hat Linux
title Red Hat Linux 4 Update 3 - 64bit v20z
kernel /rhel4-u3-x86_64/vmlinuz ksdevice=eth0 ks=nfs:192.0.2.1:/export/redhat/kickstart/v20z.cfg load_ramdisk=1 network console=ttyS0,9600n8
initrd /rhel4-u3-x86_64/initrd.img
Here, you can see that I have Solaris 10, Solaris NV, and RHEL 4 all booting from one file.