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
upgrade
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.
...
ENVIRONMENT
...
DEBCONF_DB_FALLBACK
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
filename:
DEBCONF_DB_FALLBACK=File{/root/config.dat}
Note that if a database is set up on the fly, it will be read-
only by default.
DEBCONF_DB_OVERRIDE
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: