OS installers should be easy to open up and modify

October 14, 2015

A while back I tweeted:

Every so often I dream of genuinely sysadmin-friendly OS installers. I doubt I'll ever get them, though.

As it happens, I have a specific vision of what being sysadmin friendly here should be and that is easy modifications.

The reality of life is that OS installers are necessarily very general but they are most frequently used in much more specific situations, ones where you already know the answers to a lot of the questions they'll ask. At the same time there's often a few local questions of your own that are important and need to get answered in order to set up a machine properly, and not infrequently the set of packages that is available on the install media is not ideal.

A genuinely sysadmin friendly installer would be one that fully understood this reality. It would make it not merely possible but easy to open up the installer image, make this sort of straightforward changes to it, put the whole thing back together, and have a custom setup that fit your environment. Want to run a post-install script? It should let you do that. Want to drop some additional scripts and files into the installed system? Ditto. And so on.

(A nice implementation would allow you to ask your own questions within the installer's Q/A framework and then export those answers to your post-install scripts or write them into the system or the like. A really nice implementation would allow you to use these answers to drive some of the regular installer actions somehow, although that gets more complicated.)

Of course I know that this is a quixotic quest. The modern world has decided that the answer to this problem is doing as little as possible in the actual installer and customizing the system after install using an automation framework (Puppet, Chef, Ansible, etc). I can't even argue with the pragmatics of this answer; getting an automation framework going is a lot easier than trying to persuade Debian, Red Hat, FreeBSD, OmniOS, and so on and so forth to change their installers to be nicer for sysadmins (and a full framework gives you a much more uniform cross system experience).

(Debian and Ubuntu have a 'preseed' feature but apparently rebuilding installer images is somewhat of a pain and preseed only goes so far, eg I don't think you can add your own questions or the like.)

(This whole chain of thought was sparked by working with our standard install system and thinking about how much of it could and really should be in the actual installer.)

Comments on this page:

By liam at unc edu at 2015-10-14 09:42:47:

So more like the old Solaris 10 Jumpstart experience?

By Tilman Baumann at 2015-10-14 10:56:33:

I'm surprised by the way you phrase the problem.

I suppose you know that you don't actually need to rebuild the installer image to either use Red Hats kickstart or Debians preseed? (No unified installer yet I'm afraid) Unless you really want to install from CD which these days seems arcane.

Just point the installer to the right file via DHCP/PXE parameter. I mean, you want hands off installation anyway, right? So just set the DHCP options and reboot. (A process which can be automated with tools like cobbler/spacewalk/sattelite)

It's not a brilliant solution. But some kind of magic is always required. (And because pressed is not exactly awesome)

By cks at 2015-10-14 12:41:39:

I've never used Jumpstart so I can't comment specifically, but I have the impression it's designed to be an automated install system. We specifically don't want automated installs; we really do want to be asked a few crucial questions during the install (and to have to approve a few crucial choices, like system disks and the specific NICs used).

Also, yes, we really do want to use install CDs (although I'm happy to virtualize them through a IP KVM or the like). We're not fans of DHCP/PXE install booting for various reasons.

This comes back to the packaging problem - the packaging systems used by nearly every OS really make it hard to make distributable changes to a system without a lot of trouble. The tools to create, modify, and diff packages need to get as good as the ones we have for code in a modern DVCS's, but that work isn't being done.

I'd also love to see a packages broke down into the various parts (binaries, config files, documentation) that can be replaced independently. For example, if you wanted to install the vendor's binaries for say Apache, but supply a custom config file, you'd do it by making your own config package, but you could still get security patches to the binaries from the upstream vendor.

As other's say, automation exists when doing PXE installations, but these require more ongoing work, and frequently a PXE or install file caching server running the OS that's being installed in order to install current OS's, which is a challenge in heterogeneous environments. Also, they fall down in ways - Debian's disk partitioning automation is nigh inscrutable, for example.

By James (trs80) at 2015-10-15 11:36:23:

Preseed files are fairly easy to add to CDs: http://d-i.alioth.debian.org/manual/en.i386/apbs02.html

I won't say that further modifications are easy, but they're certainly documented https://wiki.debian.org/DebianInstaller/Modify/CD

Written on 14 October 2015.
« Why I've come to really like git
Some notes on finding package versions in OmniOS with pkg »

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

Last modified: Wed Oct 14 02:24:39 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.