Univention Bugzilla – Bug 21263
UCR-Templates/Info-Files bei Paket-Removal entfernen
Last modified: 2011-12-13 15:49:24 CET
In UCS3 sollten beim Deinstallieren ("remove", nicht "purge") eines Pakets auch die UCR-Templates, UCR-Info-Files und mögliche Diversions rückstandsfrei entfernen.
Beim deinstallieren von Paketen rufen diese nur "ucr unregister $pkgname" auf, die zugehörige "/etc/univention/templates/info/$pkgname.info"-Datei bleibt aber weiterhin bestehen, d.h. sie wird u.a. bei einem "ucr update" weiterhin beachtet. Da es sich eigentlich nicht um eine Konfigurationsdatei im engeren Sinn handelt, wäre eigentlich /var/lib/univention-config-registry/ der bessere Ort für .info-Dateien. Zumindest sollten diese aber beim "remove" entfernt werden, nicht nur beim "purge". Da das auch noch nachträglich für bereits längst deinstallierte Pakete sinnvoll ist, soll hierfür ein Skript erstellt werden, daß u.a. auch in postup.sh aufgerufen wird. Siehe auch Bug #3382.
#!/bin/sh for f in /etc/univention/templates/info/*.info do case "$(dpkg-query -W -f '${Status}' "$(basename "$f" .info)")" in deinstall\ *\ config-files) rm -f "$f" ;; esac done
Bei Updates treten weitere Probleme auf: 1. Da "ucr unregister" nur bei "remove" und "purge" aufgerufen wird, nicht aber "upgrade", geht die Information über Templates verloren, die in der alten Version noch vorhanden sind, in der neuen allerdings nicht mehr (z.B. wegen Umbenennung). Damit bleibt dann auch das "dpkg-divert" darauf bestehen. (Für das neue Template wird ein neues "dpkg-divert" hinzugefügt, weil das "ucr register" immer aufgerufen wird.) Das "ucr unregister" darf dagegen nur im Falle der Deinstallation des Pakets aufgerufen werden, da ansonsten bei einem Update ggf. kurzzeitig keine Templates mehr vorhanden sind und die Datei auf den ursprünglichen Zustand aus dem Debian-Paket zurückgesetzt würde. 2. Die .info-Datei ist zum Zeitpunkt des "ucr register"-Aufrufs auch bereits in Verzeichnis /etc/univention/templates/info/ vorhanden, so daß diese durch ein "ucr update" bereits eingelesen wird. Das führt derzeit zu dem unschönen Effekt, das bei der Registrierung einer neuen .info-Datei diese bereits bekannt ist, was das erkennen von neuen Multifiles erschwert. Umgekehrt muß beim de-registrieren die .info Datei noch vorhanden sein, damit UCR erkennen kann, welche Templates zu de-registrieren sind. Danach muß die .info-Datei allerdings sofort gelöscht werden, weil sie ansonsten beim nächsten "ucr update" Lauf wieder eingebunden wird. Sinnvoll wäre hier die Trennung in zwei verschiedene Verzeichnisse (ähnlich zu /etc/apache/*-{available,enabled}/): In dem einen installieren die Pakete ihre Version und rufen anschließend "ucr register" auf, das diese dann in sein internes Verzeichnis kopiert und die nötigen Aktionen dabei durchführt.
Beim "remove" wird nun zumindest auch die .info Datei gelöscht (wird durch u-i-c-r für das prerm gneriert), die anderen Dateien bleiben bis zum "purge" bestehen. Da die .info-Dateien für UCR die alleinige Informationsquelle sind, werden diese allerdings ab dann auch nicht mehr beachtet, so daß das gewünscht erreichte. Wegen Comment 1 und Comment 3 lass ich den Bug aber erst nochmal offen. svn24479, univention-config-registry_7.0.10-1.337.201105260930 ChangeLog: \item On package removal the package \ucsName{.info} file describing \ucsUCR{} templates is forcefully removed in addition to being unregistered (\ucsBug{21263}).
(In reply to comment #3) > Bei Updates treten weitere Probleme auf: > > 1. Da "ucr unregister" nur bei "remove" und "purge" aufgerufen wird, nicht aber > "upgrade", geht die Information über Templates verloren, die in der alten > Version noch vorhanden sind, in der neuen allerdings nicht mehr (z.B. wegen > Umbenennung). Damit bleibt dann auch das "dpkg-divert" darauf bestehen. (Für > das neue Template wird ein neues "dpkg-divert" hinzugefügt, weil das "ucr > register" immer aufgerufen wird.) > [...] Folgendes Problem trat in diesem Zusammenhang auf. Der neue UMC-Server benutzt keine runit-Skripte mehr, allerdings existiert nach einem Update des Paketes immer noch die entsprechende Template-Datei: /etc/univention/templates/files/etc/runit/univention-management-console-server/run Sowie das gesamte runit Verzeichnis: /etc/runit/univention-management-console-server/ Da die entsprechenden Dateien als Conf-Dateien registriert sind, werden sie (sowie die aus den Templates generierten Dateien) nicht gelöscht. FRAGE: Betrifft dieses Problem auch andere Pakete? Die einzige Lösung ist derzeit das manuelle Aufräumen über Postinst-Skripte.
Die Problematik beim Upgrade von Paketen (Comment 3) wird nun über Bug #23737 weiterverfolgt. Die Info-Datei wird bereits gelöscht und dadurch ggf. die Diversions rückgängig gemacht. Die eigentlichen Template-Files bleiben bestehen und müssen ggf. per Hand im PostInst gelöscht werden. Passende Helper gibt es in ucs/base/univention-lib/shell/ucr.sh,
Das funktioniert so wie beschrieben. Wenn ich etwa den AD Connector entferne, ist die /etc/univention/templates/info/univention-ad-connector.info anschliessend weg. Sie allerdings noch in der /vra/lib/dpkg/status registriert, da habe ich auch keinen Mechanismus gefunden, sie selektiv dort auch zu entfernen. Allerdings bin ich mir nicht sicher, ob ein Entfernen nicht doch zu radikal ist: Die Dateien sind als Konfigurations-Dateien markiert und wenn ein Admin die Info-Datei angepasst hat - z.B. um eine weitere Variable zu registrieren, was auch im Handbuch dokumentiert ist - wird die Datei einfach gelöscht. Es wäre IMO besser, sie nach /etc/univention/templates/removed zu verschieben (dieses Verzeichnis wird auch von der univention-lib-Funktion zum Entfernen eines UCR-Templates genutzt).
Zur Umstellung auf Verschieben statt Löschen.
Die .info-Datei wird beim "ucr unregister" im generierten .postinst jetzt nach /etc/univention/templates/removed/ verschoben, anstatt gelöscht zu werden. svn27290, univention-config-registry_7.0.20-1.356.201109280730 ChangeLog: ±0
Das hat in meinem Test nicht funktioniert: root@master:~# dpkg -L univention-mozilla-firefox /. /etc /etc/univention /etc/univention/registry.info /etc/univention/registry.info/variables /etc/univention/registry.info/variables/univention-mozilla-firefox.cfg /etc/univention/templates /etc/univention/templates/info /etc/univention/templates/info/univention-mozilla-firefox.info /etc/univention/templates/files /etc/univention/templates/files/etc /etc/univention/templates/files/etc/iceweasel /etc/univention/templates/files/etc/iceweasel/pref /etc/univention/templates/files/etc/iceweasel/pref/iceweasel.js /etc/univention/templates/files/etc/mozilla-firefox /etc/univention/templates/files/etc/mozilla-firefox/pref /etc/univention/templates/files/etc/mozilla-firefox/pref/firefox.js /etc/univention/templates/files/opt /etc/univention/templates/files/opt/firefox /etc/univention/templates/files/opt/firefox/browserconfig.properties /etc/univention/templates/files/opt/firefox/defaults /etc/univention/templates/files/opt/firefox/defaults/pref /etc/univention/templates/files/opt/firefox/defaults/pref/firefox.js /usr /usr/share /usr/share/doc /usr/share/doc/univention-mozilla-firefox /usr/share/doc/univention-mozilla-firefox/copyright /usr/share/doc/univention-mozilla-firefox/changelog.Debian.gz root@master:~# dpkg --remove univention-mozilla-firefox (Lese Datenbank ... 142416 Dateien und Verzeichnisse sind derzeit installiert.) Entfernen von univention-mozilla-firefox ... root@master:~# cd /etc/univention/templates/removed/ root@master:/etc/univention/templates/removed# ls menu.lst.template squid.conf root@master:/etc/univention/templates/removed#
(In reply to comment #10) > Das hat in meinem Test nicht funktioniert: Damit das funktioniert, müssen die Pakete mit der gefixten Version von UCR neu gebaut werden (da die korrigierte Version im Postinst aufgerufen wird). Ich habe univention-mozilla-firefox neu gebaut und damit geprüft, dass es funktioniert. Für den kompletten Rebuild habe ich Bug 23844 angelegt, das erfolgt dann, wenn die MS2-QA durch ist.
Changelog ist ebenfalls ok.
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"