Bobulate

[[ OSOL-only entry here, with interest for KDE only from the perspective of “it’s a package server that will be serving up the KDE packages for OSOL”. ]] There’s some bits and pieces involved in setting up an OSOL appliance to be actually useful for serving up packages, so I thought I would document them here.

Adding a user and configuring ssh access: The adduser command in OSOL is a little arcane compared to the interactive versions available on FreeBSD and GNU/Linux, so may as well: useradd -s `which bash` -m username and remember to set up ssh access for that user. This user is also going to have the pkg repository available.

Making sure that the user can ssh login: On my OSOL appliance, /dev/ptmx is missing (which is a known problem, see this forum thread with the always-helpful Alan Coopersmith on it), so I followed the instructions there.

Setting up static IP: The appliance is configured to use DHCP from the local network. For my later use I need a static IP, so I picked 10.0.0.26 and solaris.bionicmutton.org as hostnames (there’s already a host with that name, elsewhere, which is the current FreeBSD-based package server for KDE’s OSOL packages). I added the hostname and IP in /etc/hosts, checked that /etc/nsswitch.conf was using files and dns, edited /etc/nwam/llp to set the interface to static IP (as described here), and added an /etc/hostname.e1000g0 matching one of the hostnames I had just set up. One reboot later (presumably svcadm restart would do, but it didn’t work for me in my haste), things were working and I could ssh in. While I was at it, I also modified /etc/nodename to use the new name of the machine (see, for instance, this thread on changing the hostname).

Setting up pkg.depotd space: As root, I ran pkg.depotd once to set up the repository space before setting it up to auto-start. /usr/lib/pkg.depotd -d /export/home/pkg -p 10000 --set-property publisher.prefix=solaris.bionicmutton.org starts the server. I checked that it was working at all by visiting 10.0.0.26:10000 from the host machine and then I stopped the server again.

Further configuration of pkg.depotd: Next, I use the Service Management Facility (SMF) to configure the package server further. svccfg -s application/pkg/server starts a command-line for configuration purposes. I set the port and root directory for the pkg.depot server here:
setprop pkg/port = 10000
setprop pkg/inst_root = /export/home/pkg
After that bit of configuration was done, I used svcadm refresh svc:/application/pkg/server ; svcadm restart svc:/application/pkg/server to start up the package server by hand, and checked once again that it was actually running. Then I rebooted, and checked that it was running still, just to be sure it will come back under a reboot of the host.

Minor remaining configuration issues: I switched off atime on the filesystem hosting the package respository, so that those are not updated on every package view (zfs set atime=off rpool/export, which reminds me I could have gone for a finer-grained setup by creating a filesystem for the packages first). I also set the read-only flag so that people can’t just publish into this repository — the KDE4-OpenSolaris people use tarballs + ssh for that. I also modified some settings in /export/home/pkg/cfg_cache to reflect the purpose of the repository better.

The OSOL appliance released by Jignesh Shah is 2009.6 — nearly a year old now. Since then the packaging tools for OpenSolaris have made great strides. IPS remains .. interesting. I’m not entirely convinced that it was worth the effort of not using some of the existing package formats. However, by now I understand the API it brings in as well as the various uses of the tool, (and it crashes no more) so I’m starting to like it.

Anyway, the point of this particular appliance is to host KDE4 packages for OpenSolaris in an IPS repo. To do that means running the IPS pkg.depotd. I have a port of an older version of pkg(5) to FreeBSD, but it all seems a little klunky and hard to maintain. So using an OpenSolaris VM seems the right approach.

Except that the OSOL VM from Jignesh is kind of old, isn’t it. So I ended up looking into upgrading the OSOL VM after installation, and ended up with the following steps:

1. Set the publisher to the dev branch: pkg set-publisher -O http://pkg.opensolaris.org/dev/ opensolaris.org . This means that future packages will come from the dev branch, not the released branch.
2. pkg refresh --full to fetch all the new package references.
3. pkg image-update -f (I have to force it, because something’s wrong with cherrypy and the image will not update otherwise) and wait a while while 138MB of package updates are downloaded.
4. Reboot into the new boot environment (VOSApp-1). This will fall into a root shell for fixit-purposes, because the filesystems are messed up.
5. Fix mountpoints for those messed-up filesystems and reboot again; I recall I needed to re-set a number of zfs mountpoints to get the correct organization for regular system operation. Bear in mind this isn’t needed with normal OSOL upgrades, just for this slightly peculiar application setup. I think I had to set the new rpool/ROOT/VOSAPP-1/opt/ (and var and root) to mount in the right places and move the older rpool/ROOT/VOSApp/ filesystems to somewhere in /mnt.
6. Reboot, possibly fix up remaining mountpoints, then zfs destroy the old ones.

There’s a useful HOWTO entry on updating OSOL to a specific build which I might otherwise have used, but the appliance image does not have an entire package installed which could be used to drive the upgrade. Hence this slightly klunkier approach.

Since Jignesh has left Sun, I’m not sure if there will be any future growth in these appliance builds. They were popular enough in Nigeria, where I distributed verbatim copies of the original (probably still in violation of the license terms though) to people interested in running OSOL at all.

The server running the EBN (a Sun X4200 running FreeBSD — soon to be running OpenSolaris in a VM) is getting a bit long in the tooth, software-wise, and it turns out that it can no longer even run all of the software needed for improvements to the EBN. Bertjan has been bugging me to update it, which I can’t until I update the whole machine from 6-CRUFTY to 8-STABLE, so I’m going to plan some downtime for the EBN machine: this weekend, 8 and 9 may 2010, from 12 noon (GMT) on the 8th until midnight (GMT) on the 9th. That should give me enough time to bring the machine down, make additional backups, upgrade the heck out of it (all except hardware, unless someone cares to donate a pair of ECC Registered DDR2-800 DIMMs) and bring it back up. There may be some additional downtime on Monday (but only brief) as some disks are swapped and I correct some historical mistakes in the machine’s hardware configuration regarding disk layout and management.

Sites affected: the EBN itself (www.englishbreakfastnetwork.org) and the KDE4-OpenSolaris package site (solaris.bionicmutton.org) and some personal sites, including Sebas’ vizzzion.org, bionicmutton.org and euroquis.nl.

After a week in Kano, Nigeria — where I picked up my awesome cold again, the same one that has been keeping me low since January — I spent a few days on the Dutch island of Terschelling with the family, to get back into the swing of things. Let me tell you, trading 40 degrees and dust for 12 degrees and rain doesn’t help much. Not much actual KDE coding planned this week, partly because of the NLUUG spring conference on Systems Administration (where I’ll meet up with Rainer from the FSFE and Donna from the Amsterdam Girl Geeks).