After some discussion on irc a while ago I've been thinking somewhat about managing multiple computers. We have reached the point where managing single computers is easy, using the new bootdisks and apt. I think now is a good time to think about a next step: managing a network of computers and making life for system administrators easier. One aspect of this is configuration of machines. There has already been some discussion about this, but now seems like a good time to begin thinking about implementing this. I've been thinking about doing this for a while and put some ideas in here. Basic ideas: - questions should not be asked during the postinst. The postinst is for general post-installation work, not for determining the (desired) system configuration. - With the current systems most questions are asked multiple times. Some because a package asks the same question when it's upgraded, some because multiple packages need to work out some common setup (install-mime comes to mind). - packages should not mess with each others configuration. This let me to a couple of conclusions: - every package that needs it supplies, besides the control.tar.gz and data.tar.gz a new script or program to handle configuration management - the package manager that handles the installation should provide the interface to the configuration module. - there should be a hierarchy of namespaces to seperate the configuration information from different packages. Packages which share a common purpose may use a shared namespace, preferably with the same name as a shared packagename (for example, mutt and elm may both use mail-reader) I put the configuration module directly into the .deb so we can get at it before unpacking the package. And now a tricky part: how do we get the configuration information? We want to use a flexible system so nobody is obliged to use a specific lanaguage or userinterface. We do this by using two different parts that can communicate with each other. From the user-side this makes it possible to use different kind of frontends: text/console, X11, web or (very important for me) remote configuration. From the developer-side it means you're not bound to a specific language but are free to use anything you want, as long as it's capable of communicating with the front-end. Now let's move a bit toward implementation. We want to keep the communication between the frontend and backend as simple as possible. We need to divide the responsibilaties of the two parts and make the backend as simple as possible. First a list of all kinds of data we use. A quick check gives: 1) booleans (yes/no, on/off) 2) strings 3) numbers 4) choice from a list 5) ordering of a list 6) static text (extra information for the user) The backend must be able to give one or more questions to the frontend, receive the answers and verify answers. This can be reapated multiple times if necessary. The frontend has complete responsibility for the layout of the questions, with the exception that the ordering must not be changed. To keep communication as simple as possible stdin/stdout are used. Commands are all 1-line, which means we can also use standard line-buffered I/O. Examples of this are in apt (methods supplying status/progress information) and xcdroast (mkisofs,cdrecord giving progress to the tcl frontend). Both are only one-way, while we need two-way communication though. A problem that remains is that we currently use dpkg to install packages, and dpkg is not able to supply us with a user-interface. This can be solved by using a wrapper which dpkg calls for each package that supplies a configuration-module. We can use different wrappers for the different frontends. At the moment apt and linuxconf seem likely frontends. You might wonder why I don't use linuxconfig completely? There are multiple reasons: from what I see linuxconf is designed to be one big interface for all configuration stuff. What I'm aiming toward there is simpler: getting configuration information when installing. We don't want to start linuxconf completely when we install a single package. Secondly, linuxconf is very linux specific (at the moment at least), and especially since Debian/HURD is begining a more general solution would be A Good Thing(tm). Wichert. -- ============================================================================== This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: wakkerma@wi.LeidenUniv.nl WWW: http://www.wi.leidenuniv.nl/~wichert/
Attachment:
pgp73SSVwAy6S.pgp
Description: PGP signature