The Software.CFG Frequenty Asked Questions
First to clear up some common misconceptions:
Our system is an abstraction layer, just like other config tools. It is not a replacement for native config files, it does not require apps to use it, and it certainly does not intend to force a single way of doing things. It is just a tool that people can use to edit existing, plain text files one day, and the next day to edit them by hand if you wish. The system will provide an XML-based representation of the configuration which you can use for various purposes. This XML cache will be kept up to date with the native config files, and NOT the other way around. The beauty of our system is that you get an XML-based, structured interface to the native config files. Its just an interface, not necessarily a replacement.
Our system currently allows application developers to read their configuration easily using our API, though it does not require it. It is not a registry, it is an interface. If you want to write your own parser or your own file format, go ahead. We'll try to handle your special formats, but we'd like to keep the number of config file formats to a minimum if possible.
We intend the our base system to be for people who more or less know what they're doing or for foolproof frontends. Someone made a good point that even if you have been a sysadmin for 20 years, there are just some apps that you don't configure often enough to remember all the details needed to hand edit a config file without consulting a fair amount of documentation.
Of course there are reasons why someone who doesn't know squat about unix should not be able to configure an important server in a production environment. Thats up to the boss. If they want to depend on someone being able to use our tool for their business to stay alive, they've got bigger problems.
More importantly*, what if someone wants to mess with configuration on a testing machine? Why should it be so hard for them to learn?
General Questions:
Don't you guys know about [SOME CONFIG PROJECT]?
- We've looked at various config editing projects, such as Webmin, Linuxconf, Ximian Setup Tools, and Debconf to name a few. In short, they aren't as flexible or modular as we think they should be. We've spent a lot of time fiddling with the design, and we think that our system is unique and that it provides significant benefits over existing tools. If we didn't think that, we wouldn't be wasting our time. :)
Isn't Software.CFG doomed to fail because the formats and options change so fast?
In contrast to all other config tools around, the Software.CFG framework has the key advantage of external meta-configuration files.
Well, first off the project will create meta-config-data files for current versions of popular software (apache, samba, php, qmail, etc.) Once these initial files are made, it is our hope (and we will work hard on making this happen) that the software maintainers or distro maintainers will include these files in the package with the software. This way, when user installs version x.y.z of software A on distro 34, the installer (whether its a tarball w/, an rpm, a .deb, an ebuild, whatever) will put the necessary files in the right place. If this were to happen, the headache would be gone. It is also important to know that these files consist of XML which is read by our system, and the XML would just define the configuration options and how they should be displayed, so that any reasonably up-to-date version of our software is able to handle it. If we can't get software maintainers to include the file, we'll make a web-based database which the system can automatically check and get the necessary files from.
All the configuration will be in XML. If a particular configuration directive isn't recognized, it will be marked as such and will likely be displayed as a generic text entry field (although we're open to better suggestions). Since neither using our system or editing the config files by hand will exclude doing the other, extremely special situations won't be a problem as you can resort to doing it by hand. Keep in mind that both of us use a text editor to edit 99% of our config files and are more or less happy with that. We just think that there could (and should) be more options.
To help people understand the configuration, we would like to provide context-sensitive documentation inside the config interfaces where possible. For example, I plan to write a parser that will take things like samba's man page (which is excellent) and create an XML representation of it to allow our middle layer to associate the documentation with each directive. This, of course, needs to be mostly automatic, since I know that I definitely don't want to write lots of XML documentation by hand for every release of every project if I can help it.
This is bloat!
As for the problem of bloat, we're hoping that will be avoided by the fact that no information about specific software is going to be included in our actual code. That way, when someone is editing samba's configuration, only the general core, the specific backend, the users's chosen frontend, and the XML meta-config-data files for samba will be needed. A user may or may not have the files on his/her system needed to allow him/her to configure apache with our system, but either way they won't be loaded.
And after all, Software.CFG makes a lot of redundant code currently in different tools unneseccary.
I think Software.CFG is a bad idea because [your opinion or experience with other config tools].
People like different things. There's nothing wrong with that. If you don't want to use our system, rest assured that even if you find yourself at a box which previously had only been configured by our system, you wouldn't even notice. And Software.CFG won't even change the layout or comments of your files if used intermittently, it will only change single values if asked to do so. This is because Software.CFG works with external meta-config-information and has been designed to be absolutely non-intrusive to other means of configuration handling.
Wouldn't it be better to only use multiple diffs as entities to apply to config files?
Software.CFG uses individual configuration settings and even comments as entities that can be individually validated and changed. As far as using only diffs of the new and current config files, we can currently completely reconstruct the config file exactly (byte for byte identical) as it was from our XML representation of the data. If we can do this, and we checked to make sure the file hadn't been changed by one user as another was editing it by hand, we should be ok. Either way, since we can re-create the exact (or slightly modified) config file, producing a diff of the two wouldn't be difficult either, and may be a good option (among others) for logging.
Why don't you just concentrate on establishing a better standard for configuration storage like a virtual filesystem to access XML or some other nice thing?
Again, this could be a possible alternate interface, which would certainly make configuration very accessibly at the command line and using already existing tools. This isn't a primary interface because it ties it to that specific OS, but it could easily be added later. Still, the native configuration needs to be parsed to and from XML in order to get into the XML-to-filesystem code, so this type of an extension would work nicely as an add-on interface. We hope to make libraries available so that such a thing could be done. I think it is a great idea, and would definitely work nicely over a network.
Initially, our system will probably just rely on standard file permissions to determine whether a user can or can't update a configuration file, since that makes things simple. We want to make a durable core which allows these sorts of things to be easily added on, but we do agree that its important to keep things simple and not re-invent anything if we can help it.
Re: GConf
We did look at GConf among other projects, hoping that we could build on some existing code. One of GConf's main flaws is that the method for adding support for a new thing to configure involves writing a lot of C code and various other things, which we felt was too cumbersome.
We want to make things simpler, and the architecture for GConf and most of the other tools wasn't flexible enough to accomplish what we're looking to do. Unfortunately (depending on how you look at it), it looks like we ended up writing lots of new code in order to accomplish this. The upside is that since we've putting tons of effort into planning, soliciting comments, and really thinking this through, the release should turn out pretty close to what we're going for.
Re: Webmin
There are some tools that are good at a lot of things. Webmin is one of them. Webmin has some flaws which detract from its usefulness to some extent. First, it is only web-based, which although that is probably the best interface to pick if you're going to focus on a single one, picking only one can also be bad.
Second, webmin requires a module be written for each new software, and that this module be added by the user. Our system will (ideally) handle this automatically as version-appropriate files will be included with each software package.
Third, webmin doesn't make it terribly easy to allow people to write new modules. There are some things built in, but not nearly enough. There's little reason why someone should have to write more than a basic text file to explain how a piece of software (or part of the system) is configured. We want our system to be easy and straightforward to use for everyone involved, without keeping people too far from the details. For example, we may want to display someplace in most of our interfaces a note explaining what actual config file the user is editing should they want to edit it by hand.
Our system is specific to the task of configuration, but it will be general enough so that it won't need to be re-written to add support for new things. The process will be very simple, and may even be mostly automatic.
About the Implementation:
Doesn't Software.CFG have too many dependencies?
Why is this not in my favourite programming language?
In the case you would actually need a new parser or frontend you can write it in the language you prefer due to Software.CFG's modularity. However chances are you won't need to.
Perl is used because it is well suited for parsing and wide spread.
Why C and glib not just C++ ?
How is Software.CFG's config representation organized?
The actual XML data is organized by nested
Properly handling defaults & inheritance is very important for the project's success since otherwise it won't be very useful for a lot of situations.
Ok, now I want to have support for my own application, what do I need to do? How do I define my own XML meta-config-data?
Currently you'd have to look at our extending howto at http://config4gnu.sourceforge.net/docs/extending/ particularly the section on adding entities. Also in CVS take a look at config4gnu/data/classes/ to see our current meta-data files.
Our meta-config XML actually does not have a DTD for a couple of reasons. While we never actually tried, I don't think our meta-data could be validated against a schema/dtd.
All our XML nodes are defined in meta-data as basically sub-classes of other nodes. Because of this, there are 2 problems with using standard schema/dtd validation, I'm assuming you're referring to #1 but I'll include #2 anyway.
1) each node defined in meta-data can have ANY child elements that it wants to. While they are restricted to certain classes of nodes, current XML libraries don't support this type of validation. So, we can't validate them in the traditional way. It would be possible to write our own validator to do a good amount of sanity-checking, but we have not done this yet.
2) the actual config data that comes from one of our more generic parsers (i.e., the apache-style parser) could be validated against a DTD. However, in practice we primarily use more specific parsers, and by the time the XML reaches the front-ends, it may have additional nodes added to it as defined in the meta-data, which as mentioned in #1 can't be validated using traditional XML libs.
Finally, here is a working example of how you could edit your Samba configuration with a perl script:
!/usr/bin/perl use config4gnu;
my $samba = config4gnu::get_configuration_root->resolve_path("/Daemons/Samba Configuration");
my $global_section = $samba->resolve_path(".samba-global");
my $wins_setting = $global_section->resolve_path(".wins_server");
print "Your samba's wins server is " . $wins_setting->get_string_value;
This example script asks the config4gnu library to load the samba configuration file (i.e., /etc/samba/smb.conf) into XML, locate specific nodes in it, and retrieve the output. Modifying it is just as easy, and the change is saved back in the native config file without changing ANYTHING else (whitespace, comments, blank lines, etc.).
Hacking on a frontend: emit clashes with the QT emit !!!
Simply put the include to sigc++ BEFORE the includes for QT
See: http://mail.gnome.org/archives/gnome-kde-list/1999-July/msg00012.html