Univention Bugzilla – Bug 22668
Wrapper für dpkg-divert --remove bei postrm
Last modified: 2011-12-13 15:50:46 CET
+++ This bug was initially created as a clone of Bug #17913 +++ Bisherige (<< UCS-3.0) Installationen nutzen dpkg-divert in ihrem preinst-, postrm-Skripten, um per UCS-Template-Mechanismus generierte Dateien per dpkg-divert zur Seite zu schieben. Durch die Änderung an Bug #17913 werden die Dateien nun durch "ucr (un)register" verwaltet. Da die alten postinst-Dateien aber weiterhin bestehen, muß das "dpkg-divert --remove" dort abgefangen und ggf. unterdrückt werden, wenn diese Datei weiterhin durch .info-Dateien registriert ist. Dazu muß ein Wrapper für dpkg-divert geschrieben werden, der den Aufruf durch ein postrm-Skript erkennt ($ParentPID?) und das eigentliche dpkg-divert nur dann aufruft, wenn die Zieldatei nicht länger in eine .info-Datei registriert ist.
Für /usr/sbin/dpkg-divert wird jetzt in univention-config-wrapper ein Wrapper installiert, der anhand einiger von dpkg gesetzter Variablen und den info-Dateien in /etc/univention/tempates/info/*.info ermittelt, was zu tun ist: Handelt es sich um ein Multifile, wird die Datei einfach erneut committed. Andernfalls wird der Aufruf normal an dpkg-divert weitergeleitet. Zudem wurde ucr nun so umgeschrieben, das durch ein "ucr update" alle Diversions ausgelesen werden und mit den .info-Dateien abgeglichen werden: Nicht mehr in den .info-Dateien erwähnte Diversions werden entfernt, fehlende Diversions ergänzt. Hierzu werden alle _lokalen_ Diversions betrachtet, die eine Umbenennung von "$p" nach "$p.debian" beschreiben. Durch ein "ucr register $p.info" bzw. "ucr unregister $p.info" kann dieser Vorgang durch die .postinst bzw. .prerm Skripte weiterhin per Hand getriggert werden. Zusätzlich nutzt UCR auch den dpkg-trigger-Mechanismus und wird darüber von dpkg informiert, wenn es Dateien in /etc/univention/templates/info/ auspackt oder entfernt. Bei einem Update-Lauf trat folgendes Phänomen auf: bind9 und univention-bind wurden beide aktualisiert, zuerst univention-bind und erst sehr viel später bind9. Beim Versuch, bind9 zu konfigurieren, gab es das init-Skript nicht (nur noch das divertete-Skript; ein commit hatte noch nicht stattgefunden), so daß das Update abgebrochen wurde. Nach einem "ucr commit /etc/init.d/bind9 ; dpkg --configure --pending" ging es dann reibungslos zu Ende. In einem anderen Fall trat die Konstellation auf, daß die alte .info-Datei entfernt worden war und die neue mit der Endung .info.dpkg-new daneben lag. Das UCR aber nur Dateien mit der Endung .info betrachtet, wurde die Diversion für die Dateien Rückgängig gemacht. In einem weiteren Fall wurde univention-gdm entfernt. Das prerm verschiebt dabei die .info-Datei in den ../removed/-Ordner. Beim anschließenden Neu-Installieren stellt dpkg dann die Datei nicht wieder her, wenn nicht explizit ein --force-confmiss mitgegeben wird. Insgesamt spricht das dafür, die .info-Dateien aus /etc/ wegzubewegen und nach /var/lib/ucr/ oder /usr/share/ucr/ zu verschieben. Zusätzlich zu den Dateien sollte UCR dann weiterhin in /etc/u/t/i/ nach zusätzlich vom Benutzer erstellen Zusatzinformationen suchen. svn28110, svn28122 ChangeLog: \item UCR now manages the state of template files itself. Previously each package diverted the files in its preinst script itself. This is now handled automatically when the corresponding .info file is registered (\ucsBug{22668}).
Ich bin mir nicht sicher, ob dies der richtige Bug ist. Während eines Master-Update von 2.4 nach 3.0 taucht die Zeile "Processing triggers for univention-config ..." häufiger auf, wobei diese nachfolgenden Fehlermeldungen fortlaufend mehr werden, bis schließlich folgendes erreicht wird: Processing triggers for univention-config ... The following Subfile doesnt exist: /etc/univention/templates/files/etc/syslog.conf.d/00syslog.conf univention-config-registry aborted mv: cannot stat `univention-bind-proxy.info': No such file or directory The following Subfile doesnt exist: /etc/univention/templates/files/etc/syslog.conf.d/00syslog.conf univention-config-registry aborted mv: cannot stat `univention-directory-manager.info': No such file or directory The following Subfile doesnt exist: /etc/univention/templates/files/etc/syslog.conf.d/00syslog.conf univention-config-registry aborted mv: cannot stat `univention-webui-style.info': No such file or directory Processing triggers for install-info ... install-info: warning: no info dir entry in `/usr/share/info/netmask.info.gz'
Created attachment 3736 [details] updater.log
(In reply to comment #2) > Während eines Master-Update von 2.4 nach 3.0 taucht die Zeile > "Processing triggers for univention-config ..." häufiger auf, wobei diese > nachfolgenden Fehlermeldungen fortlaufend mehr werden, bis schließlich > folgendes erreicht wird: > > Processing triggers for univention-config ... > The following Subfile doesnt exist: > /etc/univention/templates/files/etc/syslog.conf.d/00syslog.conf > univention-config-registry aborted Das Problem ist hier abermals die Handhabung von conffiles durch dpkg: Während des Updates werden die neuen conffiles zunächst als .dpkg-dist-Dateien neben die alten conffiles entpackt und erst beim Konfigurieren des Pakets umbenannt. Werden diese durch .info-Dateien referenziert, führte da bisher zu einem Abbruch des UCR-Prozesses (sys.exit(1)), so daß hier univention-config nicht erfolgreich den Trigger abarbeiten konnte. Das Fehlen eines SubFiles wird jetzt nicht länger als kritischer Abbruch gehandhabt, sondern nach Ausgabe einer Meldung ignoriert. Außerdem wurde noch ein Fehler korrigiert, der beim Wegbewegen der .info-Dateien von inzwischen de-installierten Paketen aufgetreten ist: Dort wurde der relative statt dem absoluten Pfad verwendet. svn28794,28798 univention-config-registry_7.0.27-3.366.201111071248 ChangeLog: ±0
Bei der Installation von "dash" tritt das Problem auf, das dieses im preinst ein "mv /bin/sh /bin/dash" ausführt und danach "dpkg-divert --list" aufruft, welches als "#!/bin/sh"-Skript dann seinen Interpreter nicht mehr findet: /var/lib/dpkg/tmp.ci/preinst: /usr/sbin/dpkg-divert: /bin/sh: bad interpreter: No such file or directory Deshalb wurde in der She-Bang-Zeile jetzt /bin/bash angegeben, was "Essential: yes" ist. Damit hat dann die Installation von "dash" funktioniert. svn29048, univention-config-registry_7.0.28-1.369.201111110849 ChangeLog: ±0
OK, funktioniert soweit, Update klappt (dash) und pre 3.0 Pakete können entfernt bzw. installiert werden. Der wrapper für dpkg merkt, wenn eine pre UCS 3.0 univention Paket ein dpkg-divert ausführen will, klingt sich ein und "repariert" die Situation. Bei anderen Paketen wird dann alles an das richtige dpkg-divert weitergeleitet. Das Problem an Bug #24867 ist erstmal nicht kritisch, da die Original-Konfigurationen je nach einem purge/install des Pakets wiederhergestellt werden. Auf neu installierten System gibt es keinen dpkg wrapper.
UCS 3.0-0 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte dieser Bug dupliziert werden: "Clone This Bug"