This is the current state of configuration in Linux. It is a bad state. Configuration of system-level properties, such as network interfaces and hostname, varies widely from one distribution to the next. System-level applications, such as Apache and Samba, each have a different method of configuration. Some tools and distributions provide applications to ease configuration, while some only provide a man page for the configuration file and leave it up to the user to edit. Nearly the only positive thing about Linux configuration is that it almost exclusively uses human-readable, human-editable text files.
This article is not going to talk about the existing state of configuration, however. This topic has been well discussed already. Instead, it will describe what it could be. It is a kick-off to a 9-month, 2-person project to address configuration in Linux. Hopefully, it won't be limited to 9 months or 2 persons, though. We invite your feedback and participation as we go.
In order to develop a system that people will use and give direction to the project, some goals need to be defined. The primary goal is to set up a clear architecture in which various components of the system are clearly defined and separated. This is what this document will attempt to do. The following are some more specific goals, categorized into user requirements, data requirements, process requirements, and interface requirements.
The architecture will be divided into many frontends, a middle layer, and many backends. The frontends will provide the user interface. This will allow commandline utilities that can be used in scripts, GUI interfaces for machines that have X installed, and remote interfaces such as Web and LDAP. The middle layer will provide shared functionality between the frontend interface and the backends. It could also be given capabilities like logging changes, controlling access, and caching configuration information. Finally, the backends will be the programs that actually read and manipulate the native configuration files. There may be backends for reading XML files and Windows INI-style files, as well as specialized backends for reading more complex configuration files (such as Apache's).
How the layers communicate is something to be decided in the design phase, but it should allow each frontend and each backend to be written in any particular programming language that is best suited for the task. Perl, for instance, would probably be best suited for most of the backends, since it can easily parse and modify text files.
One major feature of this three-tier design is that frontends are designed to handle configuring anything. In other words, the frontends know nothing about the programs and distributions they are configuring; they only provide an easy-to-use and consistent view of the configuration. How can you tell which frontend you want to modify, such as the list of users that are allowed to access one of your Samba shares? This is where the directory approach comes in.
Configuration will be modeled as a directory (or hierarchy), in a way similar to how GConf and the Windows registry handle configuration. Applications and system settings will be put into logical groups. Backends will be responsible for handling configuration "underneath" a particular branch of the directory.
|/||All configuration for the local machine is done under the "root". This root could be placed into another directory, which would be important for remote administration.|
|/apps||This contains configuration defining how some system applications run. These are not daemons; they don't run all the time. Examples might include sudo and Debian's apt-get.|
|/daemons||This contains system applications, such as Apache, Sendmail, and Samba. These are applications that normally run in the background, and are equivalent to "services" in MS Windows.|
|/daemons/samba||This is where the backend of Samba would exist. Anything under this path would be handled by the Samba backend, which would be responsible for mapping the configuration of smb.conf into a directory.|
|/hardware||This contains properties to configure hardware (e.g., sound card modules and network card IO addresses and IRQ numbers).|
|/network||This configures network interfaces (e.g., the IP address and default gateway).|
|/system||This contains system-level settings, such as hostname, default runlevel, and boot-loader settings.|
|/users||This manages the addition/modification/deletion of system users and their properties.|
Particular configuration locations are not fixed. Users should be allowed to rename, move around, or group system applications if they choose. As applications are installed, they will be placed in a suitable default location. Localization should be considered as well, so applications can be grouped using words from a user's native language. Users should also be able to create second copies of some applications, in case they want to run more than one version of the same application and they have more than one configuration file to edit.
The system described so far does not present an interface much different from the registry in Windows. If you want to make a modification, you must navigate through a hierarchy and know the name of the attribute you want to add or modify. This is probably worse than editing the configuration files; with configuration files, you at least have the comments that were built in. This is where forms, wizards, and metadata come in.
Forms will give users a window in which they can see the important information and edit it using text boxes, list boxes, buttons, and other common controls. The information will be presented in an organized way and may be split into multiple tabs or pages if there is a lot of data to present. Forms can probably be best thought of as providing an interface like Webmin in order to modify configuration.
Forms will be defined using an implementation-independent language, such as XML Forms. The same form definition files could be used to create dialog boxes and Web pages. Forms will be distributed with a program that supports the configuration system, or they may be provided by a third party. As new versions of a particular distribution or system application are released, the forms may need to be updated to support new features.
Here is a screenshot of a prototype of how a Samba share form might look. Notice how the properties for this share are organized into four tabs, one of which is a generic "Other" tab which is capable of showing all properties. On the "General", "Permissions", and "Users" tabs, the application will show a form based on an XML form definition file that describes a layout of controls and bounds the data on the form to certain attributes of the Samba share.
While forms allow users to manipulate existing configuration data, wizards will give them opportunities to add things to the configuration. Take for example, adding a Samba share. It requires not just changing an attribute, but rather adding a whole section to the configuration file. Wizards will ask the user all the information needed to create something, then perform the steps necessary to do it. Wizards overlap somewhat with forms, because they will probably ask for the same information that the forms manipulate. Wizards, like forms, can probably be defined using XML Forms.
Wizards could also be created to install entire services. If integrated into a particular distribution, you might be able to use a wizard to add Samba to your computer. The wizard would use the facilities provided by the distribution to download and install Samba onto your computer, then create an appropriate default configuration file.
Finally, metadata is information about the configuration data. Metadata could include the following items:
Of course, metadata will be available to the frontends. The frontends with a higher level of user interaction may wish to display descriptions of the items and the comments associated with them.
Access control defines who has access to read and/or change particular parts of the configuration. It will allow the root user to delegate control of the configuration to other users. This is important if more than one person is to administer a system, because a person who only needs to manipulate user accounts may not want access to the whole system.
Access control could potentially be quite flexible. In the traditional Unix filesystem, files and directories have three types of permissions which can be applied to the owner of the file, a group, and everyone. While pretty flexible, this has certain limitations, such as difficulty in giving two groups different levels of access while still denying access to everyone else. An access control language for Unix configuration could be much more flexible, allowing access to any number of users and groups and allowing very detailed types of access.
Access control is also useful when you start talking about logging, because it allows users to make changes as themselves instead of as root.
As users make changes to the configuration, they should be logged. The log could contain a date, the change that was made, and the user that made the change. If a remote access method is used, the IP address of the connecting machine could also be recorded.
A rich logging system would allow the creation of utilities that can "go back" to previous states of configuration. If someone made some changes that messed up the system, a "go back" utility could be used to revert the configuration to the state it was in just before those changes were made.
This "go back" utility would exist as a frontend, just like the commandline interface and the GUI interface. It wouldn't know anything about how to manipulate the configuration files; it would only know how to access the list of changes that were made and revert them.
In the world of Unix, managing a computer remotely is easy, thanks to the wonders of SSH and remote X. For many users, these methods may be enough, but for administrators who manage a lot of servers, we may be able to provide better solutions.
Imagine a single program that you could use to browse multiple machines and edit their configurations, one which could handle connecting to the appropriate servers and providing the proper credentials to access the configuration.
Furthermore, imagine that when there's a new exploit for BIND, you do a search for all BIND programs (on all the servers in your organization), disable them all in one keystroke, apply the patch, and re-enable them.
Remote administration could be taken to the next step by storing multiple copies of a computer's configuration on different servers. The primary source of the data would remain the computer that the configuration data is for, but secondary copies could automatically be kept on "peer" servers. This provides the unique ability to access configuration data when the server in question is down.
Furthermore, what if you were allowed to modify the configuration data when the computer is down? The modified data would be kept on the "peer" computer, and when the original computer came up, it would have to synchronize. The synchronization could lead to critical changes, so it might be best to synchronize before any daemons started.
These ideas about remote administration and data distribution are quite idealistic (and outside the initial scope of this project), but will give the project something to aim for.
At this point, we'd like to get feedback from the Linux and Open Source community. We'd like to answer questions like:
Addressing details like what programming languages should be used and how to interface the various components is not necessary right now. These things will be decided later, during the design phase.
We'd also like you to visit our project site at SourceForge, http://config4gnu.sf.net/.