.\" .\" .\" .\" This manpage has been automatically generated by docbook2man .\" from a DocBook document. This tool can be found at: .\" .\" Please send any bug reports, improvements, comments, patches, .\" etc. to Steve Cheng . .TH "SYSCONFTOOL" "7" "16 July 2005" "Double Precision, Inc." "" .SH NAME sysconftool \- format of configuration files installed by sysconftool .SH SYNOPSIS .PP .nf # ##VERSION: $Id$ ##NAME: configname1:configname1version # # Description SETTING1=VALUE1 ##NAME: configname2:configname2version # # Description SETTING2=VALUE2 ... .fi .SH "DESCRIPTION" .PP This manual page describes the format of configuration files installed by \fBsysconftool\fR(1)\&. This format is flexible enough to accomodate any kind of application configuration file format. \fBsysconftool\fR makes four assumptions about the configuration file: .TP 3 1. It is a plain text file. .TP 3 2. Lines that begin with a single '#' character are comments that contain a description of the following configuration setting. .TP 3 3. Lines that do not begin with the '#' character contain the configuration setting described by the previous comment lines. .TP 3 4. Configuration settings are self contained, and completely independent, changing one configuration setting never requires that another, different, configuration setting must be changed too (perhaps any logical conflicts are automatically resolved by the application in a safe, fallback, manner) .PP The additional information used by \fBsysconftool\fR is encoded as specially-formatted comment lines that begin with two '#' characters. .SH "FILENAMES" .PP An application installs a default configuration file as "\fIfilename.dist\fR", when the actual name of the configuration file is really "\fIfilename\fR". If there is no existing \fIfilename\fR, \fBsysconftool\fR simply copies \fIfilename.dist\fR to \fIfilename\fR, and calls it a day. Otherwise, \fBsysconftool\fR copies the existing \fIfilename\fR to \fIfilename.bak\fR and creates a new \fIfilename\fR based on the contents of both files. .PP \fBsysconftool\fR is designed to solve a common problem with application configuration. New versions of applications often include additional functionality that requires new configuration settings. Without the new configuration settings the application will not work, so new configuration files should be installed during the upgrade. However, when that happens, any changes to the existing configuration settings are lost. \fBsysconftool\fR is designed to solve this dillemma, and merge old configuration settings with new ones. \fBsysconftool\fR is designed in a fail-safe way. Whenever there's a doubt as to what's The Right Thing To Do, \fBsysconftool\fR will use the configuration settings from the new file, that are supposedly known to be good, and leave it up to a physical being to sort out any conflicts and make any manual decisions. .SH "FILE VERSIONING" .PP The following line should appear at the beginning of \fIfilename.dist\fR: .PP .nf ##VERSION: \fIversion\fR .fi .PP This doesn't have to be the very first line in \fIfilename.dist\fR, but it should appear somewhere within the first twenty lines, right before the first configuration setting. "\fIversion\fR" should be some kind of an identifier for this particular version of the configuration files. All that \fBsysconftool\fR cares about is that any change to the default configuration, in \fIfilename.dist\fR, results in a different \fIversion\fR\&. An excellent way to do this is to simply use the $Id$ RCS/CVS version identification strings, and have this little detail taken care of automatically. .PP New revisions of an application should not necessarily have a new configuration file \fIversion\fR\&. If the default application configuration settings have not changed from the previous release, \fIversion\fR can remain the same. \fIversion\fR is copied from \fIfilename.dist\fR to \fIfilename\fR\&. .PP If there's an existing \fIfilename\fR, and it includes the same \fIversion\fR identifier, \fBsysconftool\fR silently skips over this configuration file, and doesn't do anything, assuming that this configuration file has already been installed. Therefore, running \fBsysconftool\fR more than once (accidentally) will not break anything. .PP If there's an existing \fIfilename\fR, but it's \fIversion\fR is different, \fBsysconftool\fR backs it up to \fIfilename.bak\fR, then creates a new \fIfilename\fR\&. If there's an existing \fIfilename\fR, but it doesn't contain a recognizable "##VERSION: \fIversion\fR" line, \fBsysconftool\fR assumes that the previous version of the application did not use the \fBsysconftool\fR tool. That's not a problem. \fIfilename\fR is copied to \fIfilename.bak\fR, and \fIfilename.dist\fR gets installed as the new \fIfilename\fR, allowing \fBsysconftool\fR to work with the next version of this configuration file. .SH "CONFIGURATION SETTING VERSIONING" .PP Each configuration setting uses the following format in the configuration file: .PP .nf ##NAME: \fIname\fR:\fIrevision\fR # # \fIdescription\fR \fIsetting\fR .fi .PP \fBsysconftool\fR looks for a line that begins with "##NAME". This line gives the name and the revision of the following setting. \fIname\fR must be unique within its configuration file (the same \fIname\fR can be used by different configuration files, \fBsysconftool\fR works with one file at a time). \fIrevision\fR is used by \fBsysconftool\fR to decide when the configuration setting can be safely carried over from an older configuration file, and when it is better to reinstall the default setting from the new configuration file. .PP One or more comment lines - lines that begin with the '#' character - may follow "##NAME". The first line that does not begin with '#' is considered to be the first line that contains the value of the configuration setting, which lasts. The value can be spread over multiple lines. The configuration setting is considered to last until either the end of the file, or until the first following line that begins with another "##NAME". .PP Aside from that, \fBsysconftool\fR does not care how the configuration setting is represented. It can be "NAME=VALUE", it can be "NAME: VALUE", or "NAMEVALUE", it can even be a base64-encoded binary object, and it can always have leading or trailing blank lines. \fBsysconftool\fR merely looks at which lines begin with the '#' comment character. After the \&'##NAME:\&' line, \fBsysconftool\fR looks ahead until the first line that does not begin with '#', and that's the first line of the configuration setting. Then, \fBsysconftool\fR looks ahead until the next line that starts with a "##NAME:", which marks the end of this configuration setting. .PP For this reason it is important that all commented description lines that follow '##NAME:\&' must begin with the '#' character. If a blank line follows the line with '##NAME:\&' it is assumed to be the start of the corresponding configuration setting. For example, this is correct: .PP .nf ##NAME: flag1:0 # # # This is the first configuration flag # flag1=1 .fi .PP This is not correct: .PP .nf ##NAME: flag1:0 # # This is the first configuration flag # flag1=1 .fi .SH "CONFIGURATION FILE CREATION" .PP A new configuration file, "\fIfilename\fR", is created from its previous version, "\fIfilename.bak\fR" and the new default configuration file, "\fIfilename.dist\fR", using the following, simple, two-step process. .TP 3 1. \fBsysconftool\fR begins with \fIfilename.dist\fR in hand. This makes sure that \fBsysconftool\fR begins with a good, known, default configuration file. .TP 3 2. \fBsysconftool\fR then takes each configuration setting in \fIfilename.dist\fR, then searches \fIfilename.bak\fR\&. If it finds a configuration setting that has an identical "\fIname\fR" and "\fIversion\fR", then the corresponding configuration setting value is taken from \fIfilename.bak\fR, replacing the default in \fIfilename.dist\fR\&. After all configuration settings in \fIfilename.dist\fR are looked up (and potentially replaced), what's left becomes the new \fIfilename\fR\&. .SH "THE END RESULT" .PP The above process is a logical description. The actual technical implementation is slightly different (for example, \fIfilename\fR is not backed up to \fIfilename.bak\fR until the new configuration file has been already created), but is logically equivalent to this process. This process carries a number of consequences that must be considered. .PP If a new application revision needs a new configuration setting, it will get a new \fIname\fR and \fIversion\fR\&. Since \fIfilename.dist\fR is used as a starting point for the new configuration file, the new configuration file will include the new configuration setting. When a configuration setting is removed, it will disappear from the new configuration file for the same exact reason. .SH "CONFIGURATION SETTING VERSION" .PP \fBsysconftool\fR looks at both \fIname\fR and \fIversion\fR\&. A configuration setting with the same \fIname\fR but different \fIversion\fRs are seen by \fBsysconftool\fR as completely different settings. The existence of \fIversion\fR allows a finer-grained control of configuration upgrades, as described below. .PP \fBsysconftool\fR copies setting values with the same \fIname\fR and \fIversion\fR from the old configuration file to the new configuration file. However, the associated descriptive comments are not copied, and are taken from the new \fIfilename.dist\fR\&. Therefore, if a new version of the configuration file contains an updated or an embellished description of a particular setting, it will be included in the new configuration file, but the existing configuration value will be preserved! Generally, if a configuration setting does not change its meaning or function, its \fIname\fR and \fIversion\fR should remain the same. Its comments can be edited to fix a typo, or revised in a more substantive fashion. \fIName\fR and \fIversion\fR should only be changed if there's a functional change in the configuration setting. .PP What to do with \fIname\fR and \fIversion\fR after a functional change depends on the nature and the magnitude of the change. The nature and the magnitude of the change must be considered not only with respect to the most recent revision of the application, but to all the previous revisions as well. When in doubt, go based upon the largest change in magnitude, in order to guarantee a functional default setting, from \fIfilename.dist\fR, and leave it up to a living being to manually figure it out. .PP If only the default value of a setting should be changed for new application installation, but the existing installations can continue to use the existing value of the setting, both the \fIname\fR and \fIversion\fR should be left alone. Existing configuration settings will be preserved, and new installations will get the new default. The descriptive comment of this setting can be updated too (see above). .PP This should be done only as long as \fBALL\fR previous values of this configuration setting will ALWAYS be valid in the new application revision. If some possible values of this configuration setting will no longer be valid, \fIversion\fR should be changed. \fBsysconftool\fR does not care how \fIname\fR and \fIversion\fR are formatted. Both are opaque labels. The only requirements is for the label to be different. The difference between changing \fIversion\fR and changing both \fIname\fR and \fIversion\fR is this: .PP If there's an old configuration setting with the same \fIname\fR but different \fIversion\fR, \fBsysconftool\fR will still use the new, safe, default value from \fIfilename.dist\fR, however \fBsysconftool\fR will also append an additional comment, on its own accord, reminding the reader that this configuration value has been reset, and the reader should consider whether to manually restore the configuration value from the old configuration. .SH "MISCELLANEA" .PP When \fBsysconftool\fR decides to keep an existing setting, with the same \fIname\fR and \fIvalue\fR, it will also insert a short comment to that effect, reminding the reader to check the default in \fIfilename.dist\fR\&. .SH "SEE ALSO" .PP \fBsysconftool\fR(1)\&.