Re: Konfigurationsfiles mit dpkg wiederherstellen
Also sprach Frank Küster <frank@debian.org> (Wed, 16 Nov 2005 17:36:56
+0100):
> Richard Mittendorfer <delist@gmx.net> wrote:
[...]
> >> >> > apt-get install apache2 --reinstall
> >> >> >
> >> >> > ..damit laedst du das gesamte packet nochmal runter & installierst
> >> >> > drueber.
> >> >>
> >> >> ... außer die gelöschten conffiles. Sicher kann man die dpkg-Option
> >> >> --force-confmiss auch irgendwie in apt's Konfigurationsdateien
> >> >> angeben.
> >> >
> >> > Den Apache wollt ich jetzt nicht abwuergen,
> >>
> >> Wieso wäre das ansonsten nötig gewesen?
> >
> > Weil hier ja debconf bei einer installation von apt aufgerufen wird und
> > der mir vermutlich den apache mit der nicht modifizierten httpd.conf
> > restartet haette. Auch handelt sich's um 1.3 und nicht um 2 wie beim
> > OP.
>
> Ich kann über den alten Apachen nichts sagen - aber wenn ein Programm
> beim upgrade (und das reinstallieren der gleichen Version sollte genauso
> behandelt werden) Konfigurationsdateien verändert, dann hat es einen
> schweren Bug. Wenn debconf verwendet wird, muss das die existierenden
> Konfigurationsdateien einlesen oder parsen, und die vorher vorhandenen
> Einstellungen als default-Antwort vorgeben. Im noninteractive-Modus
> muss dann hinterher genau das gleiche rauskommen wie vorher.
Neinnein. Die Configs werden nicht "veraendert" _wenn_ sie vorhanden
sind. Sind sie aber nicht vorhanden, werden die default- bzw.
debconf-Configs neu angelegt. Das scheint jetzt mal distcc und mserv zu
betreffen.
> In der Praxis kann das bei upgrades ein bisschen anders sein: wenn
> z.B. die neue Version ohne eine bestimmte Änderung nicht laufen würde,
> wird der Upgrade diese vielleicht erzwingen müssen. Aber bei einem
> reinstall der gleichen Version darf da nicht verändert werden.
nach .dpkg-dist. mhm.
> >> > die (vorher entfernte) conf
> >> > von distcc wird sehrwohl wieder hergestellt. AFAIK trifft das mit
> >> > "apt-get install --reinstall" auch auf andere Packete zu
> >>
> >> Das wäre ein Bug in apt-get - entweder sollten sie hinschreiben, dass
> >> sie bei --reinstall dpkg mit --force-confmiss aufrufen,
> >
> > Das wuerde zutreffen, wenn ein derartiger Eintrag von apt an dpkg
> > uebergeben wuerde (/etc/apt.conf[.d])?
> >
> > man apt-get sagt zu --reinstall nur
> >
> > --reinstall
> > Re-Install packages that are already installed and at the newest
> > version. Configuration Item: APT::Get::ReInstall.
> >
> > --reinstall wuerde also ein fehlendes Teil erneut installieren, da
> > sich's nicht mehr am System befindet. So zumindest denk' ich mir das.
>
> Das stimmt schon, aber es betrifft nur normale Dateien - gelöschte
> Konfigurationsdateien dürfen nicht wiederhergestellt werden, es sei denn
> eben mit der dpkg-Option --force-confmiss.
i see.
> >> oder noch besser
> >> es lassen. Bust du dir sicher?
> >
> > Durchaus. Und ich finde dieses behavior korrekt, so werden nicht
> > vorhandene Dateien beim --reinstall wiederhergestellt (In diesem Fall
> > mit den gemerkten debconf Angaben) und Kaputtgegangene ebenfalls.
>
> Nein, das wäre, je nachdem wie man es sieht, eine dicke Policy-Verletzung
> oder nur ein (IMHO schwerwiegender) Fehler in der Dokumentation.
Da hast du recht. Manche Dinge werden _ohne_ vorhandene
Konfigurationsdatei schlicht anders behandelt (zB. nicht gestartet) als
mit der default. Das kann in der Tat in vielen Faellen ein grobes
Problem sein.
> Aber ich kann es hier nicht nachvollziehen:
>
> riesling:~# dpkg -S /etc/issue
> base-files: /etc/issue
> riesling:~# rm /etc/issue
> riesling:~# apt-get --reinstall install base-files
> [...]
> riesling:~# ls /etc/issue
> ls: /etc/issue: No such file or directory
> riesling:~#
cel02:/etc# mv issue issue.orig
cel02:/etc# apt-get install base-files --reinstall
Reading Package Lists... Done
Building Dependency Tree... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 462 not
upgraded. Need to get 34.0kB of archives.
After unpacking 0B of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://ftp.tu-graz.ac.at etch/main base-files 3.1.9 [34.0kB]
Fetched 34.0kB in 0s (1287kB/s)
(Reading database ... 55601 files and directories currently installed.)
Preparing to replace base-files 3.1.9
(using .../base-files_3.1.9_i386.deb) ... Unpacking replacement
base-files ... Setting up base-files (3.1.9) ...
cel02:/etc# ls -l issue
ls: issue: No such file or directory
hmm. Jetzt bin ich doch etwas verwirrt :-/
Selbiges Verhalten auf meinen zwei Schuesseln hier. Es handelt sich um
ein auf Etch gebrachtes Sarge, das nicht unbedingt aktuell gehalten
wird.
Der bug waere wohl eher in den /var/lib/dpkg/info/ scripts des .deb's
zu suchen? So wie's dort aussieht wird, im Fall mserv,
1) in .prerm mserv gestoppt
2) in .postrm die /etc/mserv rm -rf'd & ...
3) in .postinst wirds interessant
angleichen der Userrechte & anderes
per db_get (die evtl. vorhandene) debconf abgerufen und ..
if [ ! -e "$CONF_FILE" ]; then
cat /usr/share/doc/mserv/example_config > $CONF_FILE
fi
finally mserv gestartet..
Inwieweit aber ein "Preparing to replace" einer Neuinstallation
gleichkommt, ist mir nicht bekannt - ebenso, ob diese Skripts in beiden
Faellen ausgefuehrt werden. Ich nehm's aber mal an. Auch, das Packete,
bei denen es kritisch waere die Configs wiederherzustellen, ein
--reinstall doch genau das gleiche bedeuten wie eine _neue_
Installation. Und somit die Configs (wenn denn nicht schon vorhanden!)
erstellt werden.
Das waer' natuerlich ungut, wenn zB. ein vorher absichtlich geloeschter
ipsec-schluessel nach --reinstall wieder gueltig ist. Ich nehm' mal an,
dass in solchen Faellen die dpkg/info-Skripts genauere checks
beinhalten (sollten) und es so nicht dazu kommt.
> [...]
> Gruß, Frank
sl ritch
Reply to: