BerkeleyDB and config files

[Michael A. Peters]

On 10/14/2004 03:32:46 AM, Iago Rubio wrote:
> 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.