Thinking About Installers: Discord and Happiness

[wblock@]

For the last several years, I've been thinking about what various installers did right and wrong, and what they should do. This article was the basis for a short presentation I gave at BSDCan 2015: Thinking about Installers: Discord and Happiness. Then, in a fit of recursive approximation, the article was updated from the presentation.

The presentation was recorded, but has not yet made it to the web. If/when it does, a link will be posted.

 

[Beastie7]

This sounds a lot like Solaris AIs with manifests (Profiles), which is freakin awesome. Distributed installs with it looks easy too from the docs I've read. I would love to have something like this in base.

 

[protocelt]

This is a great article! I especially like the idea of profiles.

 

[usdmatt]

Really good article. Also similar is the unattended XML file for Windows. It's so clear when you simply describe an installer as creating a profile, then installing the OS based on that profile. It seems so obvious that a basic feature of an installer should be the ability to output that profile, then re-use it at a later date.

I like the idea of being able to create a profile file and just pass that to the installer, or select it in the installer. Also being able to use a remote profile is really interesting. I don't fully get the many sub-profiles bit; To me the benefit is being able to create a single profile file that can easily be moved around, posted on the web, maybe listed in some online profile database, then passed to the installer to create a specific environment.

"Walk-Away design" is a big one for me that should be implemented even if it's the only thing that is. I installed CentOS the other day while playing about with my bhyve script, and the console installer is simple but very good. You set all configuration - including timezone/users/password - in a numbered menu first, then once the installer starts there is minimal interaction (if any? can't remember now). I'd really like to be able to set an install going, then come back to a booted system; In a lot of cases you could leave the installer to run, then just SSH in remotely once it had finished, which would be amazing.

"No Entrapment" - Lol, I've been installing FreeBSD for 10 years and I still don't know if I'm picking the right option for UTC clock.

The non-base utilities is a difficult one. While, as you say, the installer could be its own distribution, the current installer can be run from a running system or live cd, which is a useful feature. Being able to run something like the following from a basic live cd or even existing system (to an inactive disk) would be awesome

# bsdinstall http://myserver.net/some-custom-config.profile da0

Have you got as far as thinking of a format for the profile files? At the moment there's growing momentum to get UCL support in base which seems an obvious contender.

 

[wblock@]

The idea of the sub-profiles for different systems is the same as with the overall system profile, to save the user time and effort. Say the user wants to have multiple partitions set up in a particular way. When creating or editing a profile, the work of creating that partition list does not need to be done again, just choose it. By saving that previously-done work, we make it easier for the user to get what they want the next time. The installer becomes better for them each time they use it.

An installer with these features could be just another port or package, easy to add to a running system but not included in base. Or maybe the project to rebuild the loader with Lua will mean we get Lua in the base. Any language that supports features invented in the 30 years since sh(1) has been static would be an improvement. Installers written in sh(1) are hard to maintain, hard to modify, hard to even get correct when it takes so much code for basic things. I say this having written my own experimental installer in sh(1). Also, the intentions of a normal FreeBSD install and an installer are kind of opposites. A normal FreeBSD install tries to be just the base system, while the installer itself should be free to use anything that makes the installation easier for the user (or installer author).

UCL might be fine for profiles, that question has not really come up yet. For now, it's nice just to get people thinking of the installer as an assistant to the user instead of a slightly-customizable script.

pc-sysinstall(8), the PC-BSD installer, is in the FreeBSD base system. Current versions support some of the things talked about here, like being able to save a configuration, or fetch one from a URL. The version in FreeBSD looks to be fairly old and might not support that yet. Also, from what I recall about the last time I installed PC-BSD, it did the walk-away design part correctly, too.

The OpenBSD guys were talking about this a bit, too. Their installer can also run from a configuration file. I'm not sure if I emphasized enough that, in my opinion, the really important parts are to let the user easily modify and re-use profiles. They might have their own take on that which does it in a different but better way.