Hello,
i've read many mails in the archive in order to make me an opinion
about the configuration management system discussed here.
The orientation is good I think. But the proposed implementation
is IMHO too much complicated. Here's a list of my thoughts on
various points of the problem.
1. Database access
I agree with Ian that each machine should have only one database,
possibly none too (think about a remote db).
The DB access should be done through a program call for the packages,
and this program could be configured in order to use a local
or remote database.
2. The DB format
Like a big multilevel hash. The data consistency should be checked
by the postinst scripts either by checking itself the data or by telling
the program that read the DB the format the data should have.
The simplest way would be to use a directory tree, with the filenames
beeing keys and the contents beeing the data.
3. The implementation in new packages
We must add a 'config' script (or better 'preconfig') to the
control.tar.gz archive. The preconfig should use a program
dcfgset (his role is to ask data and store them in the database)
whereas the postinst script should use a dcfgget program (this
program would look for the data in the DB and ask the user if data
cannot be found. We can imagine that the postinst might fail if
the install is non-interactive and data cannot be found).
4. The frontend
It is called by the scripts themselves not by dpkg. It's better
this way, I think. The little need of interactions can be
managed with exit code / simple stdout values.
The dcfg* programs may use an X interface or a curses interface or
a text only interface depending on the case.
5. Interaction with dpkg / backward compatibilities
The implementation would be quite easy with my solution. dcfgget
and dcfgset are only interfaces beetween the DB, the user and the
install scripts. Dpkg needs to be modified anyway in order to support
a --pre-configure flag and possibly --non-interactive flag too.
The packages will work with older dpkg if dcfgget is installed.
At the beginning of the postinst script we could check that
dcfgget is available, if it's not we
change it into a shell function in order to make it work.
Here's an example of how it would work :
---
#!/bin/sh
set -e
DCFG="dcfgget"
COMMAND=`which $DCFG` || true
if [ -z "$COMMAND" ]; then
dcfgget ()
{
## The following lines should be replaced by a more complete
## rewriting of dcfgget ...
echo "$3" >/dev/tty
read reply
echo $reply
}
fi
## Simulate access to the db..
reply=`$DCFG -b general/test "Do you want to test ?"`
echo "Answer : $reply"
---
6. Packaging problems
Since the preconfigure script and the part that is in postinst will
be very similar (maybe just dcfgset replaced by dcfgget), a
helper script could automate the process of writing both parts
from only one file.
7. The registry aspect
I'm against using this configuration database as a windows-like registry.
This db should only be used for installing packages. It is not intented
for beeing a big configuration file for software that could access to
it through an API.
8. Problems
All the problems already raised can be solved (in a way or in a other)
with this system :
- having a back button by using Ian's proposal (special exit code for
the preconfig script) (or managed directly by the script)
- multiple questions on a screen can be passed as multiple arguments
to dcfgset
So, what problem(s) did I miss ? :) Criticisms are welcome...
If this proposal figures out to be a possible solution, I can work
to implement it in Perl (I don't know enough C). Of course, we need
before to define many things (db format, interface to programs, ...).
Cheers,
--
Hertzog Raphaël ¤ 0C4CABF1 ¤ http://www.mygale.org/~hra/
