Configuration 4 GNU (CFG)

The Configuration 4 GNU project is an open source project which hopes to improve the 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 reliability.

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 anywhere.

• 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.

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 Web-Based Enterprise 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 tried:

• Use SSH as a transport, like Rsync. This means you don't actually need a Config4GNU daemon running on a system to manage it.
• Write a WBEM server completely in Perl. This means you can manage any system that has Perl available.