Configuration 4 GNU (CFG)
|
|
CFG Bottom Layer | | |
|---|
The bottom layer handles actual manipulation of the real
configuration data. The parsers & unparsers read data on standard
in and write on standard out, so they need not know the actual
path to the source or destination. This allows the middle layer
the possibility to transparently handle remote configuration
editing without the parsers needing to know.
There are two types of parsers: primary parsers and secondary
parsers. Primary parsers do a direct translation between one
native configuration file to an equivalent XML representation.
Secondary parsers operate a level above primary parsers, using
knowledge about a specific distribution to pull information from
one or more configuration files to create an XML representation
that is not distribution-specific.
Primary parsers do a simple translation from
a native configuration file format to an equivalent XML
representation. It may tailor the XML output to the specific
application it is working for, and it may apply knowledge of
what data types are allowed where, but the structure of the
XML representation is equivalent to the native file and all
information in the native file is represented in the XML
representation (including whitespace and comments).
Secondary parsers, which really should not be called parsers at
all, are used to work with an XML representation of
idea of configuration, not a specific
configuration file. An example of this might be an XML
representation of network settings, which might pull information
from /etc/hosts, /etc/resolv.conf
and several distribution
specific files that tell how the network interfaces are setup.
Perhaps a better example is an XML representation of all
shares that are exported on a computer. It would include shares
provided by NFS, Samba, anonymous FTP, and a web server.
Needless to say, there is no single configuration file that
can provide this information. When the user asks for this
XML representation, information would need to be pulled from
at least four different configuration files.
The parsers are written in Perl and all (un)parsers are implemented
by extending the CFGXML::Parser module, which
provides basic
parsing functions. Parsers can further be extended by adding
rewrite rules and changing other minor behavior without having to
re-write a new parser from scratch. For example, the Samba parser
extends the Ini parser by adding various rewrite rules specific to
Samba configuration.
The parsers are written in Perl (as opposed to C/C++) because this
allows new Perl modules to easily be dropped in as part of the
install of another package. For example, if Apache was not natively
supported by CFG (an unlikely case), the Apache maintainers could
include a Perl module which extended the CFGXML::Parser
module. This allows instant support for new
applications.
Parsers must be carefully written to make extending possible. For
example, the delimited file parser is defined to use the
$self->{DELIMITER} variable, which can be
redefined in new modules in init(). In cases
where an existing parser is not sufficiently flexible, it should
be re-written to become more flexible while maintaining its
default behavior. Modified behavior can then be achieved by
setting additional variables in init() in a
new module which extends the enhanced one.
To add support for an additional file format,
first create a parser for the generic file format. Then, extend
that parser by setting more specific options. For example, you
can create an Apache-style format parser, then extend it to
support Apache files. This is desirable because then someone else
can easily extend your Apache-style parser to support Proftpd
files, since its basic format is extremely similar.
The CFGXML::Parser module supports the use
of rewrite rules. They can be used by setting several variables
which are clarified in src/parsers/README.
Parsers for generic formats (INI, Delimited, etc.) should contain
little or no rewrite rules.
When distributions vary in the way they configure various things,
such as runlevels and network settings, separate parsers will
exist for each distribution. The parsers will be different from
each other, but their output will follow the same format, and
in this way the end-user will not need to know the details of
a particular distribution.
The only time a user will need to be concerned with the details
of a particular distribution is when incorporating a new aspect
of configuration. This is because when you add a new
configuration, you must select what parser to run to get that
configuration. (Remember that parsers will vary from one
distribution to another.) However, once the parser is selected,
the configuration can be manipulated without knowing what file
format it is, what files it uses, and what parsers are being
run.
For example, you have a GUI client of Config4GNU
running and you want to use it to configure
your system's runlevels. You select the
menu and choose .
You will see a dialog with a list of parsers. In this dialog,
you will find a group of parsers for your distribution (e.g.
Gentoo) and in this group you find a Runlevels parser.
Select this parser and you will see the runlevel configuration
appear in the client. At this point you can configure
runlevels just like runlevels on any distribution.
If the new configuration was created inside another document,
the parser you select, as well as any parameters you enter
to customize the behavior of the parser, will be saved inside
this "parent" document. In this way, you really do not need to
remember the details of your distribution. In fact, if each
distribution provides a configuration document that contains
entries for every node of configuration and what parser to use
for each, the end-user never has to manipulate new configurations
at all.
You may wonder why we are so concerned about what distribution
a user is using, and why knowing the differences between
distributions is so important.
Distributions tend to configure various features uniquely and
modificy application behaviors to suit their customers best.
One of the most prevelant things distributions do to customize
software is change the location of their configuration files--a
very important factor when considering configuration software,
such as Config4GNU.
| |
|
|
|
|