Jumpstarting a SPARC over the WAN - Part 2, the Jump.
In the last segment, we got a remote machine booting off the WAN. But altogether that isn't terribly useful. The goal here is to get that machine installed off the WAN... probably, so that we can get other machines installed off that first box.
The main problem we're working around is that the Solaris Jumpstart scripts will, at least on the SPARC platform, assume that your install media is located on the same type of media as your boot filesystem. Booting off the WAN, using wanboot, is meant to work around the lack of any control of the network your machine is located on. Installing this way is meant to work around the assumption that boot media == install media. In this case, the idea that since the boot media is HTTP, that your install media is located via HTTP as well (a FLAR).
To get our Jumpstart Jumpstarting, the very next step we'll need to do is configure our system_conf file, as was specified in the wanboot.conf configuration file. In my example earlier, I used sys-conf.s10-sparc as the name of this file. So, the file we'll need to edit is /etc/netboot/sys-conf.s10-sparc, which is a plain text file. In mine, I placed the following two lines:
SsysidCF=http://192.168.1.10/wanboot/client-sysidcfg
SjumpsCF=http://192.168.1.10/wanboot/js-rules
Note how similar the keywords are to how you'd often configure your DHCP server for Jumpstart?
"client-sysidcfg" should be a directory. If you've Jumpstarted Solaris machines on your LAN, then you know this trick... Solaris always looks for a file named "sysidcfg", so you create a separate directory for your differing client machines. So, in keeping with my earlier examples, this directory would be /var/apache2/htdocs/wanboot/client-sysidcfg on my webserver.
In this directory, place your sysidcfg file. Keep in mind that Solaris processes this file just like it would if it was fetching it via NFS... if you make any mistakes in it, the Jumpstart won't be non-interactive. In this case that's probably fine. You'll likely be babysitting a weird install like this.
Now you'll need your Jumpstart files, particularly your "rules.ok" and install profile. These files are made in exactly the same way as you would for a normal, NFS-based install. You'll need to edit your "rules" file, create a jumpstart profile, and then process them using the "check" script to generate rules.ok. However, there is one more step.
The Jumpstart "begin" script isn't something used often... most of us don't need it. So we leave the field in rules - the field between the rule conditions and the Jumpstart profile - as the plain dash to indicate we don't need it. However, in this case we do.
After Solaris WAN-boots, it'll be confused about the install media. If you were installing via a local server, or with a disc, the install media would be mounted on /cdrom (regardless of the actual media type). This won't happen in this case, so Jumpstart will drive on blindly and eventually explode, complaining that it can't find the install content. However, this error will happen *after* the begin script has run.
So, to fool Jumpstart, we slip in and mount the install media ourselves. The script itself is trivial. Assuming you've shared the install media via NFS, with anon=0 and ro to the world or (better) just to the client machine, you mount it just as you would via the command-line. Assuming your NFS server has the IP address of 192.168.2.10, and your Jumpstart base directory (the directory with the .volume.inf* files in it) is mounted at /js/sol10, your begin script would look like:
#!/bin/sh
echo 'Mounting WAN install media'
mount -F nfs -o ro 192.168.2.10:/js/sol10 /cdrom
Nothing to it. I should note that the install media can be located *anywhere*. It might be on the same machine as you have serving the wanboot media. It could be a general campus Jumpstart server. It doesn't matter, so long as the machine you're installing is allowed to mount it. The only caveat I would give is that I'd avoid using a Linux machine. I know Linux does a poor job booting SPARC clients with an NFS root... those problems might extend into installing as well, although I haven't tested. Mounting in this way actually gives more wiggle room, as you can provide mount options to NFS, without letting Solaris figure it all out... so Linux might actually work in this case.
I saved this begin script as "wan_start.sh". So, my rules file actually looked like:
hostname client wan_start.sh client.js -
A quick run of "check", and I have my rules.ok file.
Create the directory /var/apache2/htdocs/wanboot/js-rules. Dump rules, rules.ok, wan_start.sh, and client.js into it. Now, your client machine can fetch each of them as it needs.
At this point, you should be able to reset your machine, do a "boot net - install" (network-boot-arguments is persistent across reboots), and Jumpstart should roll, doing a complete install.
The Jumpstart will fail at the end, because some post-setup scripts can't be run... in my testing, these failures were not fatal to the Jumpstart. I believe it was just various crap that Solaris sets up to run the installers for extra discs and the like, not particularly needed during a Jumpstart. Still, this is a hack, so problems might arise later. As I've said, this is mostly just to get a foothold when installing a number of remote machines.
I've left out a number of little tweaks to this process. For instance, wanboot-cgi can be made far more secure... it has the capability of hashes that the client can present to the wanboot server to verify its identity and the like. That would be part of a more formal wanboot infrastructure, and hopefully any serious setup like that would have the capability of generating a proper FLAR, making this whole WAN-NFS thing a bit of quaint nonsense.
I encourage people to read the actual scripts that deal with the guts of the Jumpstart process. The majority can be found right on your install media, under Solaris_10/Tools/Boot/sbin, named install-*. Keep in mind that you can activate debugging of many of the scripts at the ok prompt, using "boot net - install install_debug". It can be interesting to see some of the extra noise generated, as you follow the Jumpstart through some (not all) of the Jumpstart process.
Posted at
09:58PM Sep 02, 2008
by Brandon Hume in Solaris |