Thinking about what we'll need for reproducible OmniOS installs

December 18, 2013

We have a thing here where we like all of our fileservers to be exactly identical to each other (apart from configuration information), even if they happen to be installed or reinstalled some time apart. In the old days of basically static systems this was easy to achieve; if you installed everything from the media for OS release X.Y, they all wound up the same. Today, in a world of (online) patches and package updates and security fixes and so on, this is not necessarily all that simple. This is especially so for free software whose distribution mirrors may not have either the disk space or the interest in keeping every package version ever released around for perpetuity (especially if those package versions are perhaps known to have security bugs).

(This generously assumes that the package management system can be used to install a very specific version of a set of packages even when there are newer versions available. Not all package systems are happy about that.)

OmniOS is installed from versioned install media and then updated and supplemented through package updates with IPS. In practice the OmniOS base package repository is not enough and we'll likely supplement it with pkgsrc to get various important things. IPS supports mirroring selected packages to your own local repository (although I don't know if this can easily be done on a non-Solaris platform). I haven't looked at pkgsrc but it can probably do something.

There is also two somewhat crazier options that I've thought of: building our own install media with current updates and packages rolled in, and ZFS level copies. Building our own install media would cut out a bunch of the update process although not all of it, since pkgsrc probably couldn't be bundled into the install media. As a result I probably won't look much at this. ZFS level copies are much more potentially promising.

OmniOS installs to a ZFS root pool, in which you have a core filesystem. OmniOS already supports multiple iterations of this core filesystem through ZFS snapshots, clones, and so on; it uses this to support having multiple boot environments for rollback purposes. So what would happen if we installed the base OmniOS and then instead of customizing it, simply copied over the current root filesystem from a working system with zfs send and zfs recv, modified or reset things like IP address information, and then made this copy the current boot environment? This could blow up spectacularly or it could be a great way to make an exact duplicate of an existing system.

(One issue is actually finding all of the places where an OmniOS system stashes things like IP addresses and other host-specific bits. In the new world of state-manipulating commands like dladm and ipadm, they are probably not stored in any simple text file. Another issue is making this process play nice with the boot environment maintenance commands.)

Sadly the whole ZFS idea is probably working too hard at something we can solve in simpler, more brute force ways (at the cost of some more disk space). I'm not sure if it's a good use of my time to investigate it much.

(One excuse is that I should understand boot environment administration and so on much better than I currently do, and that all by itself would tell me a lot.)

Written on 18 December 2013.
« You probably don't want to use Make to build your generated files
Your (HTML) template language should have conditionals »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Dec 18 01:32:21 2013
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.