Re: BerkeleyDB and config files
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