Derzeit ist das Binärpaket univention-config-registry eine Sammelstelle für verschiedenen Templates. Anpassungen daran erfordern auch immer ein übersetzen aller anderen Binär-Pakete, darunter auch libunivention-config* und univention-config. Für eine saubere Trennung sollen alle bisherigen Templates in ein neues Paket univention-base-files ausgelagert werden.
Es gibt nun das Paket univention-base-files, in den allgemeine Dateien und Verzeichnisse ausgelagert wurden. Das Quellpaket "univention-config-registry" enthält nur noch die UCR-Programme und Bibliotheken (sowie einige allgemeine Tools wie jitter, ldapsearch-{decode,wrapper}) Das Binärpaket "univention-config-registry" ist leer und deklariert für die Übergangszeit eine Abhängigkeit auf "univention-base-files". Bei der Umstellung wurden einige Altlasten aus dem PostInst-Skript entfernt, da das nicht mehr für die Übergange UCS-2.x auf UCS-3.0 relevant ist. svn24489, univention-base-files_1.0.2-1.6.201105261248 ChangeLog: \item The template files and base configuration files have been moved to a separated source and binary package \ucsName{univention-base-files} (\ucsBug{22586}).
(In reply to comment #1) > Bei der Umstellung wurden einige Altlasten aus dem PostInst-Skript entfernt, da > das nicht mehr für die Übergange UCS-2.x auf UCS-3.0 relevant ist. Einige Variablen werden nicht mehr gesetzt, beispielsweise sshd/challengeresponse?yes und sshd/passwordauthentication?no. Dadurch startet der OpenSSH Server nach der Installation nicht.
sshd/challengeresponse?yes und sshd/passwordauthentication?no werden nun wieder gesetzt. Diese waren verloren gegangen, weil sie in einem else-Block standen, dessen kompletter if-then-else-fi-Block in svn24387 entfernt wurde. svn25771, univention-base-files_1.0.9-1.19.201108011537 Kein ChangeLog-Eintrag notwendig, da nur ucs-3.0-intern.
Das Paket bash-completion wird jetzt nicht mehr installiert. Und es scheint ein Problem mit dem Auslesen der timeserver Variablen zu geben: root@ucs3:~# grep NTPSERVERS /etc/default/ntpdate NTPSERVERS="timeserver2 timeserver3"
(In reply to comment #4) > Das Paket bash-completion wird jetzt nicht mehr installiert. Das wird jetzt Recommended. > Und es scheint ein Problem mit dem Auslesen der timeserver Variablen zu geben: > > root@ucs3:~# grep NTPSERVERS /etc/default/ntpdate > NTPSERVERS="timeserver2 timeserver3" Da hat ein ucr.get(...) drumherum gefehlt. svn22586, univention-base-files_1.0.10-2.21.201108021447 Beim Update traten folgende Fehler auf: ... File: /etc/sysctl.d/local.conf Module: keymap sh: /usr/sbin/install-keymap: not found File: /etc/cron.d/univention-ucr-cronjobs ... File: /etc/default/locale Module: locale 'module' object has no attribute 'handler' File: /etc/init.d/klogd ...
Nach eine 3.0 Installation/bzw Update -> ucr get sshd/challengeresponse yes -> ucr get sshd/passwordauthentication no -> dpkg -l univention-base-files ii univention-base-files 1.0.15-1.27.201108150932 UC... -> dpkg -l bash-completion ii bash-completion 1:1.2-3.3.201104192121 program... -> ucr set timeserver=ntp.pool.de -> ucr set timeserver2=ntp.pool.pl -> ucr set timeserver3=ntp.pool.us -> grep NTPSER /etc/default/ntpdate NTPSERVERS="ntp.pool.de ntp.pool.pl ntp.pool.us" Variablen(Registrierung) und Template sind (bis auf UCS 3.0 spezifische Änderungen) in 2.4 und 3.0 gleich. Changelog Eintrag ist vorhanden.
Ich hatte den Zustand, dass apt-get immer folgende Meldung anzeigte: N: Ignoring file '20secureapt.debian' in directory '/etc/apt/apt.conf.d/' as it has an invalid filename extension /etc/apt/apt.conf.d/20secureapt ist ein Template aus univention-base-files. Vielleicht sollte der divert an eine andere Stelle gemacht werden. dpkg-divert --list| grep secure lokale Umleitung von /etc/apt/apt.conf.d/20secureapt zu /etc/apt/apt.conf.d/20secureapt.debian
(In reply to comment #7) > Ich hatte den Zustand, dass apt-get immer folgende Meldung anzeigte: > > N: Ignoring file '20secureapt.debian' in directory '/etc/apt/apt.conf.d/' as it > has an invalid filename extension Das "N:" am Anfang steht für "Notice" und ist lediglich ein Hinweis. Interessanterweise wird dieser Hinweis auch nur ausgegeben, wenn man "apt-get" direkt in einem (Pseudo-)Terminal ausführt. Ruft man statt dessen "apt-get ... | cat" auf, so wird die Meldung nicht mehr ausgegeben. Ein «echo 'Dir::Ignore-Files-Silently:: "\.debian$";' >>/etc/apt/apt.conf» hilft hier leider auch nicht, da diese Einstellung zu spät kommt: Um die Einstellung zu bekommen, wird das Verzeichnis durchsucht, wofür die Einstellung bereits notwendig ist. Einziger mir bekannter Workaround für die UCS-Tools ist der Trick, per APT_CONFIG-Umgebungsvariable eine weitere Konfigurationsdatei anzugeben, die intern von den apt-Tools noch vor allen anderen Konfigurationsdateien zusätzlich ausgewertet wird: echo 'Dir::Ignore-Files-Silently:: "\.debian$";' >>/etc/apt/apt.conf.d/00silent export APT_CONFIG=/etc/apt/apt.conf.d/00silent Alternativ müsste man apt patchen: init.cc:86:+ Cnf.Set("Dir::Ignore-Files-Silently::", "\\.debian$"); > /etc/apt/apt.conf.d/20secureapt ist ein Template aus univention-base-files. > Vielleicht sollte der divert an eine andere Stelle gemacht werden. > > dpkg-divert --list| grep secure > lokale Umleitung von /etc/apt/apt.conf.d/20secureapt zu > /etc/apt/apt.conf.d/20secureapt.debian Das ist der allgemeine UCS-Template-Mechanismus, der schon immer .debian als zusätzliche Endung anhängt. I.d.R. sind Diverts über Verzeichnisgrenzen hinweg keine gute Idee, weil ... 1. das Bewegen dann nicht mehr atomar ist, statt dessen muß die Datei kopiert und das Original anschließend gelöscht werden. 2. (für UCR nicht relevant) das Security-Labeling (z.B. SELinux) oft Verzeichnisweise deklariert wird; durch das Verschieben bekommt die divertete Datei dann die falschen Security-Labels
apt wurde jetzt so gepatched, das .debian-Dateien in der silent-Liste stehen und damit für diese keine Notice mehr ausgegeben wird. svn9722, apt_0.8.10.3.46.201109281654 ChangeLog: ±0
OK, funktioniert /etc/apt/apt.conf.d-> ls *.debian 20secureapt.debian /etc/apt/apt.conf.d-> apt-get dist-upgrade Paketlisten werden gelesen... Fertig Abhängigkeitsbaum wird aufgebaut Statusinformationen werden eingelesen... Fertig Paketaktualisierung (Upgrade) wird berechnet... Fertig 0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Beim Update wird univention-config-registry zurückgehalten. Das führt zu diversen Problemen, u.a. weil dann univention-config und Co. aktualisiert werden, aber univention-base-files nicht mit installiert wird. In der control-Datei sollten die Dependencies untereinander auf (= ${binary:Version} angepasst werden, das ist aktuell nicht überall. Zusätzlich sollte sichergestellt werden, wenn ucr-Pakete aktualisiert werden, dann muss univention-base-files installiert werden.
*** Bug 23499 has been marked as a duplicate of this bug. ***
*** Bug 23588 has been marked as a duplicate of this bug. ***
*** Bug 23386 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > Beim Update wird univention-config-registry zurückgehalten. Das führt zu > diversen Problemen, u.a. weil dann univention-config und Co. aktualisiert > werden, aber univention-base-files nicht mit installiert wird. > > In der control-Datei sollten die Dependencies untereinander auf (= > ${binary:Version} angepasst werden, das ist aktuell nicht überall. Zusätzliche Depends sind selten gut, denn die verzögern nur weiter den Zeitpunkt, bis das Paket endlich vollständig konfiguriert werden kann. Zyklische Abhängigkeiten sorgen ferner dazu, das der Zyklus an irgendeiner Stelle aufgebrochen wird, so daß die Reihenfolge dann beliebig wird. > Zusätzlich sollte sichergestellt werden, wenn ucr-Pakete aktualisiert werden, > dann muss univention-base-files installiert werden. univention-base-files wurde jetzt nochmal aufgespalten: In dem Paket selber sind nur die conffiles. Alle anderen Abhängigkeiten auf Pakete, die standardmäßig installiert werden sollen, wurden in univention-base-packages ausgelagert, auf das das alte "univention-config-registry" Transition-Package eine Abhängigkeit hat. (Eine) Ursache für das Fehlschlagen des Updates ist allerdings etwas ganz anderes: Das alte univention-directory-manager-Paket aus UCS-2.4 wird während dem Update entfernt. Da es ein Multifile-Fragment für /etc/hosts mitbringt, steht in /var/lib/dpkg/info/univention-directory-manager.postinst Code, um die Diversion auf /etc/hosts rückgängig zu machen. Dieser löscht (!) /etc/hosts, so daß danach "localhost" nicht mehr auflösbar ist und deshalb der lokale "slapd" nicht mehr erreicht werden kann. Siehe dazu Bug #22668
(In reply to comment #15) > (Eine) Ursache für das Fehlschlagen des Updates ist allerdings etwas ganz > anderes: > Das alte univention-directory-manager-Paket aus UCS-2.4 wird während dem Update > entfernt. Da es ein Multifile-Fragment für /etc/hosts mitbringt, steht in > /var/lib/dpkg/info/univention-directory-manager.postinst Code, um die Diversion > auf /etc/hosts rückgängig zu machen. Dieser löscht (!) /etc/hosts, so daß > danach "localhost" nicht mehr auflösbar ist und deshalb der lokale "slapd" > nicht mehr erreicht werden kann. Siehe dazu Bug #22668 Das kann dann doch vermutlich sehr einfach in 2.4-4 behoben werden, oder? Falls es dann kein Problem ist, dass base-files zurückgehalten wird, dann kann die Installation auch einfach im postup.sh gemacht werden.
Umgesetzt wurde jetzt die Idee mit dem Wrapper für dpkg-divert: Bug #22668 Das Update lief bei mir nach umfangreichen Umbau- und Aufräumarbeiten (insbesondere nach dem Einfügen der vollständigen Abhängigkitsinformationen auf univention-config und univention-base-files) jetzt mehr oder minder durch. Eine Menge anderer Pakete hat noch Probleme bereitet, aber das ist was für andere Bugs. svn28102..28122
Zwei Probleme: Löscht man ein Paket mit info Datei (ohne purge), dann wird die info Datei verschoben (prerm). Installiert man das Paket dann wieder, wird die info Datei (da Conf Datei und händisch gelöscht) nicht wieder installiert. Purged man ein Paket, werden die diverts nicht entfernt, beim normalen Löschen hingegen schon: -> apt-get install univention-dansguardian -> dpkg-divert --list| grep dansgua|wc -l 38 -> apt-get --purge remove univention-dansguardian -> dpkg-divert --list| grep dansgua|wc -l 38
(In reply to comment #18) > Löscht man ein Paket mit info Datei (ohne purge), dann wird die info Datei > verschoben (prerm). Installiert man das Paket dann wieder, wird die info Datei > (da Conf Datei und händisch gelöscht) nicht wieder installiert. univention-install-config-registry wurde nun so angepasst, das im PreInst eine ggf. zur Seite bewegte .info-Datei aus /etc/univention/info/removed/ nach .../info/ zurückbewegt wird. > Purged man ein Paket, werden die diverts nicht entfernt, beim normalen Löschen > hingegen schon: Das war noch ein Fehler in "ucr remove": Dort wurden zwar die Diverts entfernt, im anschließenden "ucr update" Lauf aber gleich wieder hinzugefügt, weil der Zustand inklusive der .info Datei benutzt wurde. Dabei wurde auch noch ein Fehler beim Parsen von /var/lib/dpkg/diversions korrigiert. svn28832..5, univention-config-registry_7.0.27-4.367.201111080924 ChangeLog: ±0
> > Löscht man ein Paket mit info Datei (ohne purge), dann wird die info Datei > > verschoben (prerm). Installiert man das Paket dann wieder, wird die info Datei > > (da Conf Datei und händisch gelöscht) nicht wieder installiert. > > univention-install-config-registry wurde nun so angepasst, das im PreInst eine > ggf. zur Seite bewegte .info-Datei aus /etc/univention/info/removed/ nach > .../info/ zurückbewegt wird. > > > Purged man ein Paket, werden die diverts nicht entfernt, beim normalen Löschen > > hingegen schon: > > Das war noch ein Fehler in "ucr remove": Dort wurden zwar die Diverts entfernt, > im anschließenden "ucr update" Lauf aber gleich wieder hinzugefügt, weil der > Zustand inklusive der .info Datei benutzt wurde. Dabei wurde auch noch ein > Fehler beim Parsen von /var/lib/dpkg/diversions korrigiert. > > svn28832..5, univention-config-registry_7.0.27-4.367.201111080924 > > ChangeLog: ±0 OK, das funktioniert > univention-base-files wurde jetzt nochmal aufgespalten: In dem Paket selber > sind nur die conffiles. Alle anderen Abhängigkeiten auf Pakete, die > standardmäßig installiert werden sollen, wurden in univention-base-packages > ausgelagert, auf das das alte "univention-config-registry" Transition-Package > eine Abhängigkeit hat. OK > Für eine saubere Trennung sollen alle bisherigen Templates in ein neues Paket > univention-base-files ausgelagert werden. OK Changelog Eintrag vorhanden.
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"