BerkeleyDB and config files

[Roberto Peon]

On Friday 15 October 2004 01:12 am, Michael A. Peters wrote:
<SNIP> (subject: redundancy)
>
> They don't need to be.
> You can get redundance either through automated backups which are
> reverted to if corrupt, flat file backups, etc.

Flat files can be backed up as well.

>
> 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?


Configuration files are single point of failures for the processes that 
depend on their existance.

If all configuration is stored in one file, then it is more probable that
filesystem corruption will be able to take out that file (and thus all of your
configuration)


<SNIP> (subject: SE-Linux)
> >
> > 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.

A database does not necessarily make it easier, but it certainly makes it more
centralized.

A properly organized filesystem based approach, however should also be easy to
use.

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

A directory is easy to backup as well.

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

Flat files don't need an additional wrapper to achieve this.

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

Properly done XML files are pretty darn legible, and by design are easily
extensible. 

Parsers for XML exist in many, if not most, scripting languages.
Since XML is text, it isn't all that hard to write a shell script to
modify a few key variables if necessary.

Databases have less tool coverage.

Also, one advantage that I might typically ascribe to databases, 
easy search (assuming, of course, that you have the right tool and you don't
have to know the database syntax, or write a program), is not likely to make
any difference, as 'grep' and 'find' are likely to suffice for any
configuration-setting searches.

Databases have one other advantage over flat files: diskspace usage.
A single file is going to be more efficent than a bunch of flat files.


Summary:

Database-based configuration approches have the following advantage:
1) more complete searching mechanisms (depending on the database)
2) better filesystem/filespace efficiency

Database-based configuration approaches suffer from:
1) increased chance of system failure
2) selinux+configuration database requires programmatic/script based
    workarounds 
3) less tool (scripting, bash, etc) support
4) VERY coarse-grained locking, so multiple simultaneous users suffer
5) Difficult to fix using vi (or some other text editor) in a 
   disaster-recovery situation


-Roberto JP