[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debconf preloading, standard method?

Sam Vilain wrote:
> All I can add is that having this in the front-end that takes its
> answers from a flat file is very good for doing things like installing
> security updated ssh on large clusters of servers you don't have
> primary control over or cannot guarantee any particular configuration
> (other than a patched debconf);
> scp answers target:/etc/debconf/answers
> ssh target "DEBIAN_FRONTEND=Managed apt-get install ssh"
> About 2 minutes work and 10 minutes to wait for about 40 hosts.  The
> RedHat admin took all day and then some to do a similar number of
> red bin hakt hosts.

Useful but gross use of the frontend concept in my mind. Doing it in the
backend is a lot better.

> If it was possible to supply the debconf.conf location via an
> environment variable, then you could override it for one installation
> with two config files.  Or switch between two `stack' drivers.
> You could even add another database via an environment variable that
> is queried in preference of the defaults in the package template, but
> after any local config databases specified in /etc/debconf.conf.  So
> then it could be something like
> ssh -R 389:ldap:389 root@target \
>     "DEBCONF_FALLBACK=LDAP:host=localhost apt-get install ssh"
> To log in, specify a temporary forwarded tunnelled ldap connection to
> debconf and then install ssh.

Right, or perhaps easier,

cat /var/cache/debconf/config.dat |
	ssh root@host "DEBCONF_FALLBACK=Pipe apt-get install ssh"

This is exactly what that dbdriver was designed for. The code will need to
figure out that this is not an existing database name of course, though 
this database is created with no parameters.

> or
> scp config.dat root@target:/var/run/config.dat
> ssh root@target "DEBCONF_FALLBACK=File:/var/run/config.dat apt-get install ssh"
> or, if you know that you can at least get one known entry added to
> /etc/debconf.conf, but not left as default:
> ssh root@target "DEBCONF_BACKEND=easydb apt-get install ssh"
> Take a look at the attached patch, works in the trivial testing I've
> attempted here and with the above examples.  Don't know if you want to
> put those functions in a separate module or change their semantics a
> bit; that's a rough cut.

I think this is a the right approach. I will change the dbdriver
parameter passing a bit for consistency:

DEBCONF_DB_FALLBACK='File{filename:/var/run/config.dat blah:bah}'

I'm unsure whether it would still be useful to add a format driver for a
much simplified file format that lets you only set seen flag and default
quesiton value. That might help if you want to write a override database
file by hand or modify one, but perhaps it's sufficiently easy with the
existing 822 format driver.

And this all needs documentaton that people will understand and not hack
around the frontend replacement wheel anymore. Something like...

Unattended Package Installation
       If  you have many machines to manage you will sometime find yourself in
       the position of  needing  to  perform  an  unattended  installation  or
       upgrade  of  packages on many systems, when the default answers to some
       configuration questions are not acceptable.  There  are  many  ways  to
       approach this; all involve setting up a database and making debconf use
       it to get the answers you want.

       You should really read debconf.conf (5) before this secton, as you need
       to understand how debconf's databases work.

       The  easiest  way  to set up the database is to install the packages on
       one machine and answer their questions as usual. Or you might just  use
       dpkg-preconfigure(8)  to  configure  a set of packages without actually
       installing them. Or you might even decide to write a plain text debconf
       database by hand or something.

       Once  you  have  the  database,  you  need to figure out how to make te
       remote systems use it. This depends of course on the  configuration  of
       those systems and what database tyes they are set up to use.

       If you are using the LDAP debconf database, an entire network of debian
       machines can also  have  any  or  all  package  installation  questions
       answered automatically by a single LDAP server.

       But  perhaps you're using something a little bit easier to set up like,
       say, the default debconf database configuration, or you just don't want
       your  remote  systes  to  use  LDAP all the time. In this case the best
       approach is to temporarily configure the remote systems to  stack  your
       database  underneath their own existing databases, so they pull default
       values out of  it.  Debconf  offers  two  environment  variables,  DEB-
       CONF_DB_FALLBACK and DEBCONF_DB_OVERRIDE, to make it easy to do this on
       the fly. Here is a sample use:

          cat /var/cache/debconf/config.dat | \
          ssh root@target "DEBCONF_FRONTEND=noninteractive \
                         DEBCONF_DB_FALLBACK=Pipe apt-get upgrade"

       This makes the debconf on the remote host read  in  the  data  that  is
       piped  accross the ssh connection and interpret it as a plain text for-
       mat debconf database. It then uses that database as a fallback database
       --  a read-only database that is queried for answers to questons if the
       system's main debconf database lacks answers.

       Here's another way to use the DEBCONF_DB_FALLBACK environment variable:

         ssh -R 389:ldap:389 root@target \
            "DEBCONF_DB_FALLBACK='LDAP{host:localhost}' apt-get upgrade"

       Here  ssh is used to set up a tunneled LDAP connection and run debconf.
       Debconf is told to use the LDAP server as the fallback  database.  Note
       the  use  of  "{host:localhost}"  to configure how debconf accesses the
       LDAP database.

       Here's another method:

         scp config.dat root@target:
         ssh root@target "DEBCONF_DB_FALLBACK='File{/root/config.dat}' apt-get

       Here  you  copy  the database over with scp, and then ssh over and make
       debconf use the file you copied over. This illistrates a shorthand  you
       can  use  in  the  DEBCONF_DB_FALLBACK parameters -- if a field name is
       left off, it defaults to "filename".

       There is only one problem with these uses  of  the  DEBCONF_DB_FALLBACK
       parameter:  While the fallback database can provide answers to questons
       the other debconf databases have never seen, it is only  queried  as  a
       fallback; after the other databases. If you need to instead temporarily
       override an existing value on the remote host, you should  instead  use
       the  DEBCONF_DB_OVERRIDE variable. Like DEBCONF_DB_FALLBACK, it sets up
       a temporary database, but this database is consulted before any others,
       and can be used to override existing values.

              Stack a database after the normally used databases, so  that  it
              is used as a fallback to get configuration information from. See
              "Unattended Package Installation" above. If  the  value  of  the
              variable  is  the  name of an existing database in debconf.conf,
              then that database will be  used.   Otherwise,  the  environment
              variable  can  be  used  to  configure a database on the fly, by
              telling the type of database, and optionally passing field:value
              settings,  inside  curly  braces after the type. Thus, this uses
              the fallbackdb in debconf.conf:

              Whle this sets up a new database of type File, and  tells  it  a
              filename to use and turns off backups:
                DEBCONF_DB_FALLBACK=File{Filename:/root/config.dat Backup:no}

              And  as a shorthand, this sets up a database of type File with a

              Note that if a database is set up on the fly, it will  be  read-
              only by default.

              Stack a database before the normally used databases, so that  it
              can  override  values from them. The value of the variable works
              the same as does the value of DEBCONF_DB_FALLBACK.

see shy jo

Reply to: