Re: Configuration management, revision 3

[Manoj Srivastava <srivasta@datasync.com>]

     [[[[[Re post of bounced message, also posted to debian-policy]]]]]
Hi,

	I think we may be making the mistake of rushing too soon to
 implemetation details; I think we need to consider ideas and visions
 that have come up before, and even if they are not implemented
 immediately, I would rather we put in some thought so that we have
 leeway to implement things in the future. 

>>"Wichert" == Wichert Akkerman <wichert@wiggy.ml.org> writes:

 Wichert> The toplevel of the hierarchy is for packages. Each package
 Wichert> is free to use a flat space, or divide it's space further
 Wichert> into subhierarchies.  If multiple packages share a common
 Wichert> purpose they may use a shared toplevel hierarchy, preferably
 Wichert> with the same name as a shared (virtual) packagename (for
 Wichert> example, both mutt and elm can use mail-reader, strn an nn
 Wichert> could use news-reader).  


	I think we should not leave it up i the air about the
 heirarchy. I think the policy group should actively design the layout
 of the database, and create a heirarchical structure based on
 functionality -- kind of like a FHS for configuration space. 

	So, I object to the requirement for a  a virtual package name;
 I would rather the variable space was not flat.

	We also need to consider the need to possibly integrate
 several such databases -- a common site wide database, a local work
 group database, and local system defaults. So, I need only configure
 proxies on one darned machine, not on every one of the 150 machines
 in the lab. 

	So, the top level should be indeed for the source of the data
 -- a machine name, or something, and localhost maybe a valid
    one. Even if we do not initially implement cross machine sharing,
    we should design so that later on the configuration mechanism may
    be enhanced. 
 

 Wichert> 3. Accessing the configuration
 Wichert> The configuration space is implemented by a shared
 Wichert> library. This library contains all functions necessary to
 Wichert> open the database, retrieve and store information and close
 Wichert> it. For scripts there will also be a dpkg-var utility to
 Wichert> access the configuration space.

	This is way too early to be talking about implementation
 details. Especially when we have not fully realized the ramifications
 of central configuration and control of a farm of machines. 

"James R. Van Zandt" <jrv@vanzandt.mv.com> said it first:


1) The package installer should be able to get configuration
information from several places:
        - a same-host database
        - a database on a specified host
        - default answers supplied with the package
        - from the sysadmin (interactive)

2) The sysadmin should be able to specify a set of rules for where the
information should come from.  The source could depend on
        - the host being installed to
        - the package being installed
        - the specific question for a specific package
        - whether the package is new or an upgrade
        - default

There could also be several default methods, of specified priorities.
The package installer would try each in turn.  If using a database,
the installer would supply answers like "expect".  Any method could
fail (including interactive, if the sysadmin does not know an answer),
and the installer should leave that package in an unconfigured state.
Providing this fallback is critical, because it lets the installer
handle a mixed collection of ordinary and database-aware packages.

3) There should be several ways to load a database.  The installer
should be able to monitor interactive installations and record the
sysadmin's answers.  If the installer is told to get answers from a
database, but a configuration script asks a question for which the
database has no answer, then that configuration fails.  However, the
question should also be added to the database.  The sysadmin could use
a tool like the kernel's menuconfig to review these questions and
supply answers later.  He should also be able to copy answers from one
database to another on a per-package basis.

	manoj
-- 
 Conserve energy, kill yourself. jon@dscatoh0.sac.ca.us
Manoj Srivastava  <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

--XAA04502.901687280/tiamat.datasync.com--



--  
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org