Also sprach Frank Küster <[EMAIL PROTECTED]> (Wed, 16 Nov 2005 17:36:56 +0100): > Richard Mittendorfer <[EMAIL PROTECTED]> 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
