Migration to Whofig

There are many small steps that can be taken on the path to an OS that fully divides files up by "who" as well as what. In fact, many tools already take such good steps.

Many of these steps make it easier to attain full whofig operation if you have a whofig filesystem.

Include directive in configuration files

The simplest thing a tool can do is have an "include" directive in config files, ideally one that can nest. If the config file has an order to the declrations, there many need to be multiple includes at various points in the file.

Even better is an include directive that can include an entire directory or a group of files that match a pattern, so that multiple files, one per configurer, can easily be maintained independently.

I use such directives to minimize how much I change a package's original configuration file. Then, when I get a new release, I just patch the new file to re-insert the includes where possible.

To make this work, packages should either not explicitly declare their defaults, and/or they should allow declarations in the include files to supersede declarations in the master file. Indeed, it should be possible to reverse or change anything done in the master file with a directive in an included config file. Ideally with a single included config file per master config file, per custodian.

Of course, one should go a step further and have the master config file already contain include directives to localized config files or config directories which, by default are empty.

Some config files have "sections" where various types of config go. Having an include in every section is cumbersome. A better solution is to arrange so that included files can repeat the sections, and thus add or replace material in the appropriate section, all in one file (per custodian.)

Or you can have...

Explicit localized configuration

It's even better if a package is explicit about the concept of putting local configuration in its own files or directories, and which are designed so that the local site will never change the master file. (It should even be set as read-only in a package.)

Users can then put symlinks in for the local configuration files pointing to their own configuration tree. They can do this safe in knowing the tool won't try to write the local config.

Many tools do this for individual users, having a system config file and a file in the user's home directory. The extra step simply involves expanding this concept to allow for files for changes by multiple sysadmins as well as users.

This means a local plugin directory different from the pre-installed plugin directory, and so on. Ideally in all cases, there should be support for "N" local files or directories, not just one extra, as long as there is an easy way to figure how to combine them and prioritize them.

File ownership

If software packages can be convinced to have multiple sets of configuration for each major type of custodian, it would make sense to create a standard unix userid for each type of custodian, and to have those files owned and writable only by that party. Thus there would be a userid for different sysadmin roles, a special userid for the OS distributor and so on.

In theory, there should be a userid for every different package owner, but there are immense numbers of those so it's not practical. As such, one would create a generic userid that would own files of general packages that don't need their own userid. Of course, ones that want their own userid tend to also use it to read and write local files, which means they still use the standard userid on the read only files. Setuid binaries present a problem.

It might also make sense to use a Unix "group" rather than a userid. This can allow more security, since in a system as I have described, having configuration files that are not readable by all users becomes difficult. Programs needing secret config would need to run setuid or setgid to assure only the right users or groups can read the secret files.

With such file ownership, it becomes possible to find all the files maintained by a given custodian, and to back them up or track changes on them. To do this well, all packages must remain in the exact same file tree or the files can't be imported and exported as easily.

Whofig generated configuration files

Before packages switch to reading their configuration from a whofig database, the whofig tools will be able to merge changes from various maintainer's trees, as well as the original configuration file of the software package, and create a new configuration file written where the package expects to find it. The original file will need to be stored in a special place (a virtual tree for the package itself) as it is an important component in building the final result and noticing changes.

SVN (Version Control) management of configuration files.

As noted elsewhere there are some similarities to the problem of multiple-administration and other collaborations. The most common tools people use for collaborating on software are Subversion and CVS.

When a package was installed, the package manager (ideally with the help of the package) would check copies locally-changable files into their own directory and check that into the version control system, and then check them back out into where the package's configuration files go. Hopefully they are all in one place -- if not, symlinks may be needed.

When local admins wish to change a file, they would check out their own version, change it, and issue a special command to the package manager which checks in their changes, and merges them, and upon success checks out the live running copy and possibly signals the program to re-read its configuration.

When a new update to the package is installed, the new configuration files would be copied into the directory where the old base files went, and checked in, and assuming no conflicts, go through the re-checkout and reload process.

(Perhaps there is a version control system able to do this more easily.)

Of course, all levels of admins can have their own checked out versions.

This would do a lot, but doesn't solve the problem fully, though with some modification of the version control system, you could encapsulate your changes for use in things like switching distributions.

Independent directory for local memory and logs

Many tools already do this, creating a directory in a different place for logs, spools, local databases and other data written out by the package. Perfect adherance to this allows the main directory to be read only, and possibly on a different disk. Also, many programs keep a file or directory in the user's home space, and the right step is to extend this principle.

Using a better configuration file format

You want a configuration file format that allows values to supersede values set at other levels, and indeed in both directions.

In other words, a local sysadmin wants to be able to supersede a value set by the OS distribution, and the OS distribution needs the ability to detect, warn or even supersede old configuration changes made at more local levels which were made for older versions.

Programs can start with today's typical styles, namely "Fieldname = Value" or some variant, but I suspect eventually an XML will make sense, because structure can be applied. Of course, an XML can consist of just wrapping an old style of configuration in two XML tags, or even doing so implicitly.

Some configuration files have a very definite order to their declarations, requiring multiple includes to let local config appear in different places in the order. Some have no real ordering. If ordering is needed, it's good if it's done with "sections" where the same section can appear in more than one file. That lets a single custodian's file apply changes at every level in the ordering.

A registry database

Yes, there are a few good ideas to be found in Windows, and one is a database which all tools can use, and can be used to query where things are. It's possible that whofig could be designed so that all installed packages are always in a standard place, such as /whofig/packagename/..., but in truth as a package moves from being the property of its first coder, to a local sysadmin, to an OS distribution, to full independence, this can't be maintained.

A configuration database

This database is in fact what will expand to do the entire whofig system. Tools needing to fetch values from their local configuration will no longer read their own configuration files, but instead query the database for them. The database will be built up by combining all the data from all the various party's configuration files, being updated when a change is made or noticed. Thus the system remains efficient.

The database will have an API allowing the easy extraction of objects ranging from configuration values to lists of all the files found in directories such as plugin directories. Ideally the creators of the API work hard to make it easy for software developers to use the config.

In addition, tools to help edit the standard XML format will arise, including perhaps a stanard GUI tool which can be easily trained to provide a nice interface, full of help screens, for configuring tools. This saves the programs the need to write their own such configurations. Of course, the XML should remain easy to hand-edit.