Configuration 4 GNU (CFG)
About the CFG Project
The Configuration 4 GNU project is an open source project which hopes to
nightmare that is the current state of Linux/Unix
configuration. We plan to provide a set of standardized tools for users,
administrators, and developers which make configuration more efficient and
powerful, while remaining true to the Unix philosophies of simplicity and
It was created in September 2002 as a year-long department honors project
led by Jason Long and Justin Yackoski, then senior computer science majors
at Messiah College.
As the founders and leaders of the project, we wanted to involve the open
source community as much as possible in addition to completing a
significant portion of the work ourselves. We
decided to start this project as a way to contribute to the Unix world and
gain valuable experience at the same time.
Interest in the project has come and gone over the years. Jason is
still contributing here and there, but these contributions are mostly
pretty experimental. Unfortunately, he's not very consistent at
communicating his ideas with the world, so they'll probably never get
- Multiple front-end interfaces
(e.g. command-line, web-based, GUI).
Some people do everything with a command-line, others like using
a web browser, still others want to write a Perl program to do it.
These different mechanisms should be provided.
- Use meta-data to describe configuration files.
Whichever front-end you use, the system will know which properties
expect numeric values vs text, and documentation (e.g. from man pages)
will be integrated in the user interface.
- Easy to extend. Developers of programs requiring a
configuration interface can take advantage of a Config4GNU system
by simply installing a few extra files as part of the program.
Config4GNU will automatically load those new files and know how
to work with the program's configuration files.
- Support common configuration file formats
(e.g. INI-style, flat/delimited text, Apache-style).
It should be easy to provide support for new configuration files
using these common formats.
- Operating system and distribution-agnostic.
Where different operating systems provide similar features,
they should be configured the same, even though the implementation
may be very different.
- Don't override the native config files.
Those human-readable files in /etc will still be the authoritative
copy of system configuration. When Config4GNU needs to modify
those files, comments and indentation should be preserved.
How It Is Accomplished
This is really still up in the air.
Originally, the Config4GNU project had an elaborate
three-tiered system that used XML to communicate between the layers.
The bottom layer consisted of "parsers", written in Perl, that were
responsible for reading and writing the native configuration files
and making them available in a general format. There were a few choices
for the upper layer, including a graphical client written in C++ and
a web based client written in PHP. The middle layer acted as a
know-it-all broker that handled communication between the layers.
In 2003, the Config4GNU developers became interested in a different
approach. Instead of exposing configuration data through XML,
Config4GNU exposed configuration data through the standards
developed and embraced by DMTF's
Management (WBEM) Initiative. In essence, a WBEM server becomes
the middle layer in the Config4GNU architecture.
Since then the project fizzled out a bit. Jason's still occassionally
contributing bits and pieces. Here are some new concepts being
- Use SSH as a transport, like Rsync. This means you don't
actually need a Config4GNU daemon running on a system to manage
- Write a WBEM server completely in Perl. This means you can
manage any system that has Perl available.