a debconf backend db finally...

[Joey Hess <joey@kitenet.net>]

Hi folks. I've been writing a backend db for debconf, since nobody else
will do it. Here is how the debconf config file would look for this
thing.

  # This is my own local database. The text driver writes it out to
  # a bunch of files in a directory.
  Database: mydb
  Driver: Text
  Directory: /var/lib/debconf

  # This is another database that I use to hold only X server configuration.
  Database: X
  Driver: Text
  Directory: /etc/X11/debconf/
  # It's sorta hard to work out what questions belong to X; it
  # should be using a deeper tree structure so I could just match on ^X/
  # Oh well.
  Accept-Name: xserver|xfree86|xbase
  
  # This is our company's global, read-only (for me!) debconf database.
  Database: company
  Driver: SQL
  Server: debconf.foo.com
  Readonly: 1
  Username: foo
  Password: bar
  # I don't want any passwords that might be floating around in there.
  Reject-Type: password

  # This special driver provides a few items from dhcp.
  Database: dhcp
  Driver: DHCP
  Reject-Type: password

  # And I use this to hold passwords safe and secure in a single file.
  Database: passwords
  Driver: FlatFile
  File: /etc/passwords.debconf.db
  Mode: 600
  Owner: root
  Group: root
  # Only take passwords.
  Accept-Type: password

  # Let's put them all together in a database stack.
  Database: main
  Driver: Stack
  Stack: passwords, X, mydb, company, dhcp
  # So, all passwords go to the password database. Most X configuration
  # stuff goes to the x database, and anything else goes to my main
  # database. Values are looked up in each of those in turn, and if none has 
  # a particular value, it is looked up in the company-wide database or maybe 
  # dhcp (unless it's a password).

I'm probably about 2 days away from having this example working (except
the dhcp and sql and flatfile drivers, which I will not bother writing).
I've thought about making it use a more bind-like format, but the above
seems clear enough (but I'm very interested to know if people not on the
config list can make head or tail of it), and parsing the other could get
tricky if I have nested databases. This lacks the glorious nested bindish
beauty of Wichert's original idea, but it captures the essence of it. 

I actually have code to allow mounting a database atop a partion of the
name space of another, sorta like mounting a drive, but I think the 
Accept-Name/Reject-Name thingies I just thought of will allow me to get
rid of it.

Adding new drivers isn't too bad: Simplistic db drivers have to implement
only save and load methods, more complex drivers need to implement some
16 different methods.

I _should_ have enough hooks in to make database browser programs
possible too.

Randolph, it's sorta annoying that cdebconf uses /etc/debconf.conf, is
there any possibility it could use /etc/cdebconf.conf instead? Also, the 
output format of the text driver isn't the same as what cdebconf uses
(instead, it's more 822-ish format files), but I'm thinking about making it
the same. Dunno.

Current todo list:

# * I need to implement the accept and reject thingies; add the fields to
#   DbDriver class I guess, and add a new method to check whether it 
#   accepts a given item. (Or do I need to break out a new type of object to
#   handle this? That would be a LOT more flexiable, and I could just
#   use new stanzas in the config file for those objects. Hmmmm.)
# * I need to modify stacks a bit, to make this example work. When setting a
#   value, call the accept method on each writable driver in turn, and write
#   to the first that accepts it, rather than always writing to topmost.
# * Parser for config file; object instantiation will be straightforward.
# * Hook into the Question class.
# * DbDriver's need access to Templates so they can tell what Type a
#   given item is.
# * Make FlatDir write out password type thing mode 600.
# * Do something about Templates. What, I dunno.
# * Transition from perldb.

-- 
see shy jo, sleeping on it