Not So Typical Jumpstart: Part Three - The Scripts

In part three of the series, we ended with a working Custom Jumpstart setup, but you most certainly will be left wanting to do more.  That's where the begin and finish scripts come into play -- anything you can do via /bin/sh you can do via Jumpstart. Up until now, the series has been more of a "Typical Jumpstart" tutorial -- this post is where this series of posts earns it's name. Read more for about 200 lines of shell-scripting goodness.

 

Simple Begin Script: delete_raidctl_vols

As noted in part two, we specified a begin script named delete_raidctl_vols.  This script will look for any existing volumes that raidctl can see, and delete them.  Obviously, this is a relatively dangerous script, so be careful:

cd /export/home/jumpstart/configs/
cat <<EOD > delete_raidctl_vols
#!/bin/sh

VOLUMES=`/usr/sbin/raidctl | grep '^c' | awk '{ print $1 }'`
if [ -n "$VOLUMES" ]; then
  for v in $VOLUMES; do
    echo "Deleting volume $v"
    /usr/sbin/raidctl -f -d $v
  done
fi

EOD
chmod 755 delete_raidctl_vols

Now you have an example of what can be done. Let's get more in-depth!

Tips for Writing a Complex Finish Script

When writing your own finish scripts, keep these tips in mind:

• Keep things modular - when possible, create separate scripts that you call from your primary finish script, passing arguments into it. This makes your code reusable between different Jumpstart installations. In our example, we put the separate scripts in /export/home/jumpstart/configs/scripts/.
• When your finish script is being run, it is being run from within the miniroot with your actual system mounted under /a. This is the biggest cause of mistakes, and they are often hard to find the cause of. For example, if you run the command 'echo "nameserver 1.2.3.4" > /etc/resolv.conf' from your finish script, it will succeed. However, you are actually modifying a file that is stored in RAM which will be lost upon reboot. What you actually want to run from your script is 'echo "nameserver 1.2.3.4" > /a/etc/resolv.conf'
• Your config server root directory and it's subdirectories are mounted and available at the location $SI_CONFIG_DIR. This is a key environment variable that allows you a lot of flexibility.
• To make packages and scripts that aren't aware of an alternate root work properly, use chroot. Most all Sun packages can be installed using 'pkgadd -R /a', but some homegrown packages and quite possibly some of your own scripts all assume that the root directory is at '/'. You can use the chroot command (examples below) to make these scripts and packages work without modification.
• /etc/mnttab and the /proc filesystem aren't visible to chroot unless you make them available. I'll show you how to do this later.
• Use an admin file to install packages without prompting. Examples will be given below.
• Fire off a shell as the last step in your finish script to prevent rebooting after installation. This tip saved me huge amounts of time. The whole point of Jumpstart is that it is automated -- so it reboots the machine when done. At that point, you no longer have access to the miniroot environment. By firing off a shell as your last command in a finish script, you get dropped into the miniroot interactively, where you can look around and see what has worked correctly and why certain things are failing.
• Use install_debug as a last resort. When you boot to the installation, you normally use 'boot net:dhcp - install'. If you change install to 'install_debug', then all shell scripts will be executed with -x. This generates a huge amount of verbose output, but at times it helps in your troubleshooting.

With all that out of the way, here is my webserver_finish script from start to finish:

Breaking it all down

Lines 1 through 10: Variable Initialization

Here we're just doing some variable initialization. One cool trick I came up with was to install wget into the target system, then use that binary to fetch files out of Subversion.

Lines 13 through 17: Setup mnttab and proc for chroot

In the tips and tricks, I mentioned you might need to do this. I recommend doing it all the time, I haven't found a case where it messes with anything yet.

Lines 19 through 23: Setting Static Routes

Here's how you can set persistent static routes in Solaris 10.

Lines 25 through 27: Creating /etc/defaultdomain

Here is the first example of calling out to a separate script from our finish script. This subscript determines the current domainname and sticks that in /a/etc/defaultdomain. Here's the contents of that script:

Lines 29 through 31: Setting up /etc/hosts

The use of DHCP for jumpstart can do funny things to the /etc/hosts file, so I just override in in my finish script. Here's our first example of a subscript that takes arguments. The script determines the current hostname and FQDN, and creates aliases for any arguments. Here's scripts/create_etc_hosts.sh:

Lines 33 through 35: Setup mail aliases and smarthost configuration

This script echoes a few custom mail aliases to /etc/mail/aliases, and then runs a perl one-liner that sets up sendmail to use the smarthost with a hostname of 'smarthost':

Lines 37 through 39: Setup NTP

Here I call a script and pass it a parameter of whether the server is in production or not, and use the appropriate NTP servers based on the value of the first argument:

Lines 41 through 48: Create extra ZFS datasets, set a quota, and make some directories.

While the jumpstart profile only allows you to create / and /var ZFS datasets, you can create whatever you want using a finish script. We also set a quota on the /export/home dataset.

Lines 50 through 52: Install Sun Glassfish Webstack

Here's our first example of chroot. It's also our first use of the $SI_CONFIG_DIR variable. I have a directory named /export/home/jumpstart/configs/webstack that contains the latest Glassfish Webstack release. I copy that directory over to /var/tmp and then run the installation routine. Finally, I add the RBAC auths for controlling the Webstack Apache to /etc/security/auth_attr:

Lines 55 through 64: Installing Companion CD and 3rd Party Packages

I copied over the contents of the Companion CD into /export/home/jumpstart/install/s10u7_companion_cd on a NFS server. This script mounts that directory, creates a package admin file that disables all prompting, and then installs all packages specified as arguments to the script:

The ESUscponly package is a 3rd party package that doesn't respect the -R flag to pkgadd, so it's installed by running pkgadd from within the chroot environment.

Lines 66 through 70: Setup a few symlinks

Here's a simple for-do loop that creates some symlinks in /usr/bin that point to their counterparts in /opt/sfw/bin.

Lines 72 through 74: Install pkgutil from Blastwave

This script uses wget to fetch the latest pkgutil from Blastwave, installs it, and updates the catalog:

Lines 76 through 78: Install Blastwave Packages

Here we call a script that will install all the packages we specify on the command line using Blastwave's repository (NRPE in this case):

Lines 82 through 85: Setup Apache Log Rotation using logadm

A quick example on how to setup log rotation using Solaris tools.

Lines 87 through 90: Setup an RBAC Profile

Here I create an RBAC profile that contains the auths necessary to control the Webstack Apache service.

Lines 92 through 94: Setup the custom NDD SMF service

Here, I download the method and the manifest for our NDD SMF service from Subversion. Since the SMF repository hasn't been setup yet, we simply need to copy the xml file to the proper place, and it will be imported into the repository on first boot. Part of the service involves specifying a profile name, so the script knows which ndd tunings to perform. The profile is passed in as an argument to the script:

Lines 96 through 101: Modify /etc/system

Quick example of how to modify /etc/system.

Lines 103 through 105: Install pca (Patch Check Advanced) and apply updates

This subscript installs the latest stable pca script, mounts a shared patch server NFS mountpoint, and then installs all recommended and security patches applicable. The beauty of this script is that each jumpstart updates the NFS server with the latest patch files from Sun:

Lines 107 through 108: Install site.xml

Here, I copy a site.xml that specifies which services I want enabled on bootup to the appropriate directory. For reference, here's what's in that site.xml file:

Lines 110 through 125: Setup passwordless users with SSH access and RBAC Profiles

This for-do loop is pretty cool. It creates the users user1, user2, and user3. It sets their password to an impossible value, but the account is unlocked. It then sets up their authorized_keys file to allow access from the ${SI_CONFIG_DIR}/sshkeys/$u/sshpubkey.txt file on the jumpstart server. As part of the useradd, it gives the users the previously defined "WebServer Admin" RBAC profile.

Lines 127 through 129: Setup a zpool scrub cronjob

This is a good example of how to create a cronjob from within jumpstart:

For reference, here's the scrubbing script:

Lines 131: Don't reboot.

Here is where we fire off a shell to prevent the automatic reboot. This line is commented out once everything has been tested and verified to be working:

Summary

As you can see by the length of this post, you can do just darn near anything when you have a jumpstart finish script available. This is by no means perfect, there's some code that could be modularized, bug-proofed, etc. I should note that an epiphany occured to me while setting all this up. The perfect approach would be to setup only the bare minimum required installation to get puppet working via Jumpstart, and then to let puppet do it's thing to get the server to it's proper state immediately after installation as described perfectly over at madstop.com. I've ordered my copy of "Pulling Strings with Puppet", and I hope the only changes I make this jumpstart config is to get puppet up and running on the target. If you're going to be doing this much with Jumpstart, I have to at least mention the Jumpstart Enterprise Toolkit which I probably would have used except that it requires the use of the Sun DHCP server.

This concludes the series of posts, I hope you enjoyed them! If you find any bugs, have any questions, or just have something to add, please do so in the comments!

Average: Select ratingPoorOkayGoodGreatAwesome

No votes yet