On Thu, 2004-10-14 at 06:50, Michael A. Peters wrote:
> I'd like to suggest a change to the way Fedora Core does some
things.
> I'm not talking about "standard" linux config files like /etc/ passwd
or /
> etc/group or /etc/fstab (though the latter would be nice) - I'm
talking
> about Fedora (and RH I suppose since Fedora has become a RH test
bed)
> specific configuration files, such as /etc/security/console.perms
and /
> etc/sysconfig/network-scripts/ifcfg-[iface] type stuff.
>
> Rather than store them in flat files, which have different
> configuration parameters depending upon the file etc., use (maybe
> optionally) BerkeleyDB.
Just to point that I don't like central configuration databases, and I
don't think it's the way to go.
They're single failure points for the whole system.
They don't need to be.
You can get redundance either through automated backups which are reverted to if corrupt, flat file backups, etc.
System would still boot if the database was corrupt - flat files are also single points of failure. Can you boot if /etc/fstab is crapped?
In fact with current selinux improvements, you will not be able to
have
a central database for all the system, but some smaller databases with
different security contexts, to manage MAC on different roles.
With this scenario, I don't see any improvements with this changes.
The database can only be updated with utility xyz per selinux policy.
utility xyz can then have its own policy with respect to what/where/how it is called.
SELinux problem is not one that isn't easily solved.
Flat files are pretty nice to manage/label.
> bdb is already needed for the rpm database, so a Fedora system will
> have bdb installed. > > Both Python and Perl (as well as many other languages) already have
> good bdb interfaces, and both Python and Perl also have gtk+ bindings > too.
What's sure is any scripting language will support open/write/read operations on flat files.
Yes - but you then have to write a utility for each different type of config file, and then maintain those utilities. Otherwise - you end up with a system that is not friendly for the typical desktop user to administrate. With an embedded database, such admin tools are trivial - you don't have to learn how program xyz pases its config file etc.
A plain python - or shell, or Perl, ... - script can do the job on flat files also.
Look at the mess that the RH 5/6 configuration tool was - I forget what they called it (linuxconfig??), but it often did not work properly, and never worked properly with all things, because all the different flat files used different syntax in how the config files were used. Some were read by a C program, some were sourced by a shell script, etc.
That made it a nightmare to maintain the administration utility.
With a database, it is much easier. The value for the setting is requested from the database, or inserted into the database. It greatly simplifies how configuration information is stored and retrieved.
And an embedded database is easily backup up. I back up my rpm database daily (cron) - it hasn't failed on me in eons, but back when it did fail - it was trivial to go to a backup database.
An embedded database for system config files does not need to be terribly complex, and redundancy could easily be built into a wrapper app that handles the request for info. If there is a database integrity problem, it alerts the administrator and uses the last backup.
Clearly you would not want the database to contain data necessary to boot, such as your grub.conf info. But stuff like your yum repositories, network interface settings, console.perms data, etc. - that really would be better off (imho) in a single database.
I know people are put off by this because of what MS did with the registry. But that was MS. Gnome does exactly this - a database for gnome application settings, gconf - and it works extremely well, and is a hell of a lot nicer than config files.
