Wednesday, May 14, 2014

CARDIGAN - automated install for Tribblix

A little while ago, I explained how to set up pxe to boot and install Tribblix.

Now, as of the m10 update, that's a bit easier, and can be made fully automated.

You'll need an existing jumpstart server, probably running Solaris 10, a web server installed and running, and the Tribblix iso image. The following commands should be executed as root.

First, mount up the iso image, on /mnt1 for example

mkdir /mnt1
mount -F hsfs`lofiadm -a /path/to/tribblix-0m10.iso` /mnt1

Then go to the mounted image

cd /mnt1

and run the setup script

./tools/setup-pxe-server -t m10 \
  -h /opt/apache2/htdocs/m10 \

There are three arguments here.

The -t flag names the location where the files will be placed on your tftp server, this will be a subdirectory of /tftpboot.

The -h flag tells the script where on the local file system to place the solaris.zlib file and the packages. This must be writable by root.

The -u flag specifies the URL that corresponds to the location you set up with -h.

To add a pxe client, go to the directory under /tftpboot

cd /tftpboot/m10

and there's a script there to set up a pxe client

 ./add-pxe-client -e 00:14:4f:e5:4d:78 \
  -t ttya

You just need to tell it what the ethernet address of your client is. I've also used the -t flag to direct the console onto ttya (this is a convenience shortcut to generate the correct boot arguments). It will configure tftp correctly, and tell you what to add to your dhcp server. (If you're familiar with setting up jumpstart, this is designed to look very similar.)

If you want the system to install itself automatically, then create a configuration file, and tell the script where that file is:

./add-pxe-client -e 00:14:4f:e5:4d:78 \
  -t ttya \
  -c /tmp/myclient.cfg

The client will be provided with that script as a boot argument. If install configuration is detected, the system will automatically run the normal install script with that configuration file as input.

(If the configuration file isn't valid it'll just exit and leave the system at the login prompt. At this point, if you run the normal installer, it will try and use the configuration file again - so you have the opportunity to fix it [it will be copied into the directory specified by the -h flag to the setup-pxe-server script, so you can edit that directly].)

What can go into this configuration file? Here's an example:

DRIVELIST="c3t0d0s0 c3t1d0s0"

This should be relatively obvious. (It's sourced by the install script, so it's just setting some variables for the install script to use. Yes, it's that straightforward.)

If you want to install to a mirrored root pool, then set ZFSARGS="mirror".

The DRIVELIST specifies which disk or disks to install to.

If BFLAG is set to "-B" then the devices you give will be partitioned with fdisk and given wholly to Tribblix. If you don't set BFLAG, then fdisk won't run and the installer will try and use the devices you specify as it finds them.

You can modify the amount of swap by setting SWAPSIZE.

You can control whether the system automatically reboots at the end of installation or not. By default, the interactive installation doesn't, whereas the automatic installation will reboot.

You can explicitly specify the nodename (not all dhcp servers are configured to hand out the node name, for some reason, or you may wish to specify an unqualified or fully qualified name to override what dhcp gives you).

You can specify the system timezone.

And finally, you can specify one or more overlays to be installed.

That's it, reboot your client and tell it to boot via the network, and off it will go. A few minutes later you'll have an installed system.

The two common failures I've seen are:

  • For the initial PXE boot, not getting the URL right, so the system can't boot properly because it can't get hold of /usr
  • For automated install, not getting the drive list correct - not helped by the unpredictable way that Solaris enumerates drives. Log in interactively, and run format to see what devices it's actually allocated.

The current implementation is functional and has proven to work pretty well for me, but some improvements are already lined up. There will be a replacement for jumpstart's begin and finish scripts, and a standardized first-boot script mechanism. And you'll be able to use Tribblix itself as the install server, with full integration with a local web and dhcp server (rather than having to set those up separately). Perhaps even a graphical browser UI to manage the server and its clients.

If you're wondering what CARDIGAN stands for, it doesn't, unless it's something like Completely Automated Remote Deployment Including Graphics And Networking. That's what I came up with initially, and the name seemed good enough.

Changes in 0m10 prerelease

Python 3.4

Firefox 29

Disable autoupdate for Firefox

OpenJDK 8

Update CDE

Add libxml2-python

Add iso-codes

Update itstool

Update Emacs to 24.3

Add gdmap

Perl 5.18.2

Add Node.JS

Add Qt4, Qt5

Add Cool Reader 3

Add erlang

Add CA certificate bundle

Update curl

Add LIVE555(TM)

Add lightdm display manager

Update glib

Zap uninstall-overlay

Zap: overlay refresh triggers a catalog refresh

Update ruby 1.9.3 and 2.0.0

Update jfreechart, jkstat, kar

Update samba

Update rdesktop

Add protobuf

Add perl IO::Tty

Add mosh

Update BIND to 9.9.5

Add jangle snmp viewer

Add Groovy

JRuby 1.7.12

Partial root zones

Update illumos

Fix xcb python packaging

Update xcb, and ship 64-bit libraries

Browsable package catalogs on website

CARDIGAN - automated installation

Live media packages use devprop, not prtconf

Zap can manage zones

Zap: trust the catalog, no more blind package retrieval

Zap: use nawk when awk gets out of its depth

Virtualized drivers

New server hosting the repos