smithj’s blog

Xiaowen recently posted an article in which she claimed that the traditional OS’s update mechanism is rendered obsolete by software appliances.

I don’t agree.

Her implied assumption is that configuration data is easily separated from the OS, an assumption that is suspect, at best. In UNIXy systems, all configuration data is supposedly stored in /etc, and /etc is supposed to contain only configuration data. In reality, that line is hard to draw, and harder still to enforce.

Consider cron jobs (regularly executed scripts and programs) stored in /etc/cron*. I’m sure Windows has a similar concept. Some cronjobs are scheduled by administrators, some by users, and some by OS distributors. Some which are shipped by the OS, such as logwatch, are often modified by administrators. Modifying system configuration files and settings is difficult under a read-only OS scheme.

Presumably it should be possible to merge such changes via a read-write layer on top of the read-only system files, via UnionFS or similar. This is harder than it seems; to do the merge, the update mechanism needs to know the state of the file as shipped with the older version of OS, as modified by the user, and as shipped with the newer version of the OS. An update mechanism which relies solely on image-based updates would not have access to that information. Contrast with conary, which has access to a networked repository containing every version of every file ever shipped in a given OS. This allows conary to do intelligent merging of changes, preventing a new (and potentially critically important) configuration option from either the OS or the user from being lost on update.

There are some ways to mitigate this failing of image-based update schemes. The OS can be redesigned to have, as Linux distro maintainers call them, dot-d directories for every possible configuration option. So, instead of having a single file, you have a directory (usually ending in .d, hence the name) which can contain both user- and system-defined options. However, this clutters the filesystem and doesn’t address what would happen should the filenames ever collide. Another option is to redesign every system component so the OS defaults are built in to the programs themselves, leaving /etc only for user-defined configuration. That would be *alot* of work, and would make it harder for users to see which config options the system is using by default. Presumably this is what folks like TiVO do, but the number of user-configurable options TiVO has is laughable compared with the options needed by an enterprise (or even a small/medium business) deploying a software appliance. Enterprises need to be able to change things like login schemes, security and auditing models, configuring for external databases, SAN- and NAS-based storage, etc. Addressing all these intelligently in an image-based setup would be very difficult.

An image-based solution simply can’t keep up with my needs. So, for now, I’m very happy using conary to manage my appliances… long live conary!