Re: automating debconf
On Sat, Feb 17, 2001 at 09:39:53PM -0800, Joey Hess wrote:
> Craig Sanders wrote:
> > is there any reason why "dpkg-reconfigure -ftext" requires a controlling
> > tty?
>
> It does some things to detect screen resizes. Have you tried ssh -t ?
nope, i'll try that....thanks.
> > dpkg-reconfigure -ftext debconf <<__EOF__
> > t
> > l
> > yes
> > no
>
> <gack>!
yes, it's ugly....but i've been using this kind of Q&D "HERENOW" script
for years. it's not as nice or as reliable as an expect script but it
does the job for simple situations.
> In the meantime, you could also grab deconf-utils and look at the
> debconf-communicate command, which allows you to do things like:
>
> debconf-communicate \
> "set foo/bar true" "fset foo/bar seen true" \
> "set baz/quux 11" "fset baz/quux seen true"
i'll take a look at it. sounds like it may be able to do at least some
of what i need.
> And then use the noninteractive frontend. This requires the questions
> that you are setting be existing questions that debconf knows about,
> though. (There are ways around this limitation.)
hmmm. that could be a problem. mostly what i need to be able to do is
to use a for loop around a script which connects to a remote machine
with ssh and either makes configuration changes or runs apt-get to
upgrade/install/remove packages from the system. the general procedure
is that i do the job manually on one or two of the systems then i write
a little script to do it on all the rest (i hate doing repetitive work
that a computer can do better).
anyway, if debconf needs to already know about the questions then
i can't use it to preconfigure a package before apt-get installing
it. i expect some packages will work fine if i configure them after
installation, but some others might not.
how do you work around the limitation?
> (Perhaps I should make that accept piped input. Hm, done.
> root@kite:/home/joey/debian/packages/debconf>./debconf-communicate
> get debconf/frontend
> 0 Text
> set debconf/frontend Slang
> 0 value set
> In Incoming.)
one thing that occurs to me is that the editor method for both
dpkg-reconfigure and dpkg-preconfigure is already 95% of what i need -
it generates a commented text file containing the questions for the user
to edit with $EDITOR, and then it parses the result and manipulates the
database accordingly.
the routine which creates the editable file could be used by itself
to just list the questions on stdout, say an executable called
"debconf-list".
the routine that parses the user-edited file back in could be modified
to accept it's input from a pipe/stdin.
(i haven't actually looked at the code yet, i'll do that later tonight
or tomorrow)
> > a utility to just list the questions would be useful. something a bit
> > more reliable than setting EDITOR to /bin/cat:
>
> DEBCONF_DEBUG=developer
i don't think this will actually do what i want. i need to be able to
just extract the list of debconf questions from a given .deb package file
and list them on stdout (actually, i'll redirect to a file).
then i will edit that file to suit my needs with vi.
finally, i want to be able to scp that file to a remote machine and use
it to pre-answer debconf questions before i install/upgrade any given
package.
result: completely scriptable package installs/upgrades.
i see this as working in a similar manner to the semi-automated method
i use to build debian boxes. i build one machine exactly as i want it
then run 'dpkg --get-selections "*"' and save the output to a file. for
subsequent machines, i just install the debian base system, copy the
selections file to it, and run "dpkg --set-selections"....and then run
"apt-get dselect-upgrade" to install all the packages. this saves a
couple of hours in dselect, and it gives me machines with an identical
set of installed packages.
this is all very simple and straight-forward, it just works without
having to waste hours or days learning some inflexible and complicated
scheme (like RH's kickstart) which ends up being unable to do what i
need anyway. one major advantage of using plain text files is that i can
modify them with vi or sed or perl or any other standard text processing
tool.
FYI, what i need this for is for maintainence of standardised internet
gateway/firewall/proxy servers deployed at public libraries out in the
bush across the state of Victoria. i'm particularly interested in being
able to roll-out important upgrades (e.g. security updates like bind and
ssh) to ALL of the machines in as short a time as possible....ideally,
i'd like to be able to have all the boxes upgraded within a day of me
hearing about the problem.
to do this manually across ~20 boxes (at the moment, more being added
all the time) is tedious. worse than that, it is difficult to do without
making a mistake or forgetting an important step or even forgetting to
do one of the machines because you accidentally skipped it in the list,
or getting distracted and losing track of where you're up to by some
other job you have to do.
debconf is a great tool, but it is actually making this job (automated
upgrades) harder to do because of it's insistence on having a real
tty...and it's getting worse as more packages get converted to use
debconf.
it wouldn't be a problem at all (in fact, it would be a fantastic tool!)
if debconf was also able to accept answers to questions from stdin.
anyway, thanks for your response. i'll try out the things you suggested.
craig
ps: i ended up upgrading ssh on all the boxes by hand. took me about two
days (including interruptions from other work that i had to do).
by way of contrast, i wrote a script which installed telnet-ssl, openssl
and telnetd-ssl, configured it to only allow secure logins ("-z secure"
on the command line in inetd.conf), and modified /etc/hosts.{allow,deny}
to reject telnet connections except from my /24 at work.
it took about an hour to do the first machine by hand and write the
little script, plus another hour and a half to run (most of that time
was in running "dselect update" and downloading the packages over the
sometimes sluggish links).
i wrote the script, ran it, got on with some other work and checked the
log a few hours later to verify that there were no problems.
--
craig sanders <cas@taz.net.au>
GnuPG Key: 1024D/CD5626F0
Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Reply to: