linux registry (no, not that again!)

[Rafael Garcia Leiva]

On Tuesday 27 July 2004 19:15, Neal D. Becker wrote:
> Yes, here's the linux registry topic again.  This project looks
> interesting. Any comments?

Yes, many comments!

I think that almost everybody will agree that Linux needs a different approach 
to store configuration information for the system, applications and users, 
other than the traditional configuration files under /etc. The problem is 
that we do not agree how this new approach should look like. Perhaps, 
everybody agrees that it must be a kind of local centralized system with a 
common framework for accessing configuration information.

Regarding to this new "Linux Registry" proposal, I see many problems:

* It provides a system namespace but, how the information is organized? Does 
every application have its own registry subset? What if two or more 
applications share configuration values? Shall they duplicate configuration 
information?

* "It is not an alternative to network information systems": fine, but it 
should take into account that most of the Linux boxes are networked machines, 
and presumably, centrally managed. So it should provide a (optional) 
mechanism for the synchronization with a central networked configuration 
database.

* "It doesn't know a thing about the semantics of each data it stores": this 
is a bad thing because we cannot validate configuration information. It 
assumes that the registry administrator knows what he is doing, and people 
does not makes mistakes when typing.

* It expects to rewrite all the applications to use the new framework. This is 
not realistic.

I think that "Linux registry" is a nice step in the right direction, but if we 
have to change /etc, and change a lot of the already existing code, we should 
try to do it in the right way, and provide a much more powerful solution.

I your are interested, you can take a look to the solution that the quattor 
project (see http://www.quattor.org) proposes. Quattor has not been designed 
as a replacement of the /etc directory, but it can be in the future. Among 
the advantages the quattor's local Configuration Cache Manager 
(http://hep-proj-grid-fabric-config.web.cern.ch/hep-proj-grid-fabric-config/documents/cache-spec.pdf) 
has with respect of the Linux Registry I can mention:

* It provides a "User 
Conventions" (http://quattor.web.cern.ch/quattor/documentation/docs/PanUserConventions.pdf) 
document as a proposal for a standard to how to organize configuration 
information.

* It provides the NVA-API library 
(http://hep-proj-grid-fabric-config.web.cern.ch/hep-proj-grid-fabric-config/documents/nva.pdf), 
to read configuration information (current implementation is in Perl)

* It provides a set of wrapper "configuration components" that reads the 
cached configuration information and create traditional configuration files. 
This eases the adoption of the new technology.

* It has a high level configuration language (called pan), that uses a much 
powerful syntax than these key-value pairs to describe configuration 
information, and it lets the system manager to perform validations (and then, 
it is compiled into an internal key-value pairs format)

* It can be used in a networked environment to keep the configuration 
information centralized.

I do not pretend to convice everybody to move to quattor, what I want to say 
is that we need a much powerful approach that this simple Linux Registry.

Cheers

-- 
Rafael Angel Garcia Leiva
Universidad Autonoma Madrid
http://www.uam.es/angel.leiva