[solved] Frage zu bind9 oder systemd oder zu sysvinit oder zu runit (Ich bin echt nicht sicher)

UCS - Univention Corporate Server
, ,
#1

Hi,

Ich bin nicht sicher wo das Problem liegt, daher erkläre ich einfach mal von vorne und spekuliere am Ende. Nötiges Hintergrundwissen: Wir haben hier einen named (bind9), aber kein Samba am Start. Der fragliche Server ist seit ewigen Zeiten installiert und wurde immer schön auf die aktuelle Version aktualisiert.

Vor wenigen Tagen so. Der “Auslöser”:

/etc/cron.daily/univention-upgrade:
Starting univention-upgrade. Current UCS version is 4.4-0 errata90
[---schnipp---]
The following packages will be upgraded:
 bind9-host,dnsutils,bind9,[---schnipp---]
ERROR: update failed. [---schnipp---]

Der Grund dieser Beschwerde war recht schnell gefunden:

# LANG=C apt-get install -f
[---schnipp---]
Setting up bind9 (1:9.10.3.dfsg.P4-12.3+deb9u5) ...
insserv: Service samba-ad-dc has to be enabled to start service bind9
insserv: exiting now!
update-rc.d: error: insserv rejected the script header
dpkg: error processing package bind9 (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 bind9
[---schnipp---]

# grep samba-ad-dc /etc/init.d/bind9
# Required-Start:    slapd samba-ad-dc
# Required-Stop:     slapd samba-ad-dc

Soweit klar: das insserv scheitert weil eben auch samba-ad-dc gestartet werden muss, der bei uns ja gar nicht installiert ist. Also mal schnell geschaut und folgenden commit vom Juni 2018(!) gefunden, der auf Bug 43689 mit Erata http://errata.software-univention.de/ucs/4.3/146.html verweist. Copy&Paste der Erata:

The bind9 service is now a native systemd service and does not use runsv anymore.

Alles schick? Nö! Wenn das ein nativer systemd service ist, warum gibt es dann den Verweis auf das runit (ich kann mich noch dunkel an diese Zeiten erinnern) und außerdem warum gibt es dann bei uns dann auch noch den sysvinit Eintrag, also die Datei /etc/init.d/bind9? Etwas verwirrend.

Und jetzt meine Spekulation: Aus unbekannten Gründen scheint bei uns ein Mix aus systemd und sysvinit vorzuliegen. Ich kann mir Vorstellen das dies so nicht sein soll. Es scheint so zu sein das bei einem (länger zurück liegenden) Update wohl ein cleanup nicht gelaufen ist, welches die sysvinit Einträge erklären würde.

Kann hier jemand sachdienliche Hinweise geben?

Und, rein aus historischem Interesse heraus, müsste nicht auch Datei https://github.com/univention/univention-corporate-server/blob/4.4-0/services/univention-bind/conffiles/etc/init.d/bind9 geändert werden? In etwa so:

# Provides:          bind9
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
- # Required-Start:    slapd samba-ad-dc
- # Required-Stop:     slapd samba-ad-dc
+ # Required-Start:    $remote_fs
+ # Required-Stop:     $remote_fs
+ # Should-Start:      $network $syslog slapd samba-ad-dc
+ # Should-Stop:       $network $syslog slapd samba-ad-dc
# Short-Description: bind9 Domain Name Server (DNS)
### END INIT INFO

Nachtrag:
Bei uns wird systemd benutzt, also ohne den Eintrag init=/lib/sysvinit/init gestartet:

# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.9.0-9-amd64 root=UUID=dbe61b22-2909-4b2e-8f86-694037e4649a ro console=tty0 console=ttyS0 net.ifnames=0 quiet loglevel=0 rootdelay=5 nosplash

Liebe Grüße Lutz

#2

Moin,

Aus unbekannten Gründen scheint bei uns ein Mix aus systemd und sysvinit vorzuliegen.

systemd und sysvinit laufen nie gleichzeitig. Allerdings enthält systemd Kompatibilität zu alten sysvinit-Scripten und kann diese nutzen, wenn es für einen Dienst keine nativen systemd-Units gibt.

Konkret: das Paket bind9 beinhaltet Init-Scripte für sowohl systemd (/lib/systemd/system/bind9.service und zwei weitere) als auch sysvinit (/etc/init.d/bind9), vermutlich, weil die Original-Debian-Pakete ebenfalls beides beinhalten und Univention die Pakete nicht mehr als nötig anpassen möchte. systemd ist dabei so schlau, die native systemd-Unit gegenüber einer gleichnamigen sysvinit-Unit zu bevorzugen. Das »gleichnamig« ist hier wichtig; hieße das sysvinit z.B. /etc/init.d/bind-dns-server, würde systemd dafür automatisch eine zweite Unit dafür anlegen.

Falscher Test. Welche Unit systemd tatsächlich nutzt, sollte man nicht einfach erraten, sondern schlicht systemd fragen:

$ systemctl cat bind9.service
# /lib/systemd/system/bind9.service
[Unit]
Documentation=man:named(8)
Wants=nss-lookup.target
Before=nss-lookup.target

[Service]
Restart=on-failure

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/bind9.service.d/10-configure-backend.conf
# Warning: This file is auto-generated and might be overwritten by
#          univention-config-registry.
#          Please edit the following file(s) instead:
# Warnung: Diese Datei wurde automatisch generiert und kann durch
#          univention-config-registry ueberschrieben werden.
#          Bitte bearbeiten Sie an Stelle dessen die folgende(n) Datei(en):
#
#       /etc/univention/templates/files/etc/systemd/system/bind9.service.d/10-configure-backend.conf
#


[Unit]
Description=BIND Domain Name Server with samba4 backend
After=network.target samba-ad-dc.service
Wants=samba-ad-dc.service

[Service]
# Stop univention-bind-ldap.service if needed
ExecStartPre=-/bin/systemctl stop univention-bind-ldap.service
ExecStart=/usr/lib/univention-bind/samba4 start
ExecReload=/usr/lib/univention-bind/samba4 reload
ExecStop=/usr/lib/univention-bind/samba4 stop
ExecStartPost=/usr/lib/univention-bind/samba4 wait-for-startup

Das ist die Ansicht, die systemd intern von der Unit hat. Wir sehen hier also nicht nur, dass die native Unit /lib/systemd/system/bind9.service genutzt wird, sondern auch, dass Teile der Einstellungen durch das Drop-In /etc/systemd/system/bind9.service.d/10-configure-backend.conf überschrieben wird.

Die Datei /etc/init.d/bind9 spielt also unter einem aktuellen Univention mit systemd schlicht keine Rolle mehr.

Dieses Drop-In hängt in meinem Fall in der Tat von samba-ad-dc ab, was aber auch zu erwarten ist, da mein Bind-Backend Samba ist. Was sagt denn systemctl cat bind9.service bei dir?

m.

#3

Oh, Nachtrag. Ich hab mir deinen Post eben noch mal durchgelesen — und meine Antwort ist zwar nicht falsch, aber auch nicht passend.

Ich vermute, dass du hier schlicht auf einen Bug in insserv getroffen bist. insserv ist ja ein Debian-Mechanismus, der die Behandlung der Abhängigkeiten für sysvinit-Scripte vornimmt — weil Debian ja nun mal verschiedene Init-Systeme gleichzeitig unterstützen möchte. Für systemd ist die Abhängigkeitskette bei dir eigentlich OK, aber aus insserv-Sicht halt nicht — und da man bei Init-Scripten nichts mit Drop-Ins überschreiben kann, passieren halt solche Dinge…

Mögliche Workaround wäre, die /etc/init.d/bind9 ebenfalls aus einem Template zu erzeugen und die Dienst-Abhängigkeiten in Abhängigkeit des Bind-Backends zu setzen, ähnlich wie das für das systemd-Drop-In gemacht wird.

Ich weiß nicht, ob es möglich ist, die Behandlung durch insserv komplett zu deaktivieren. Falls ja, wäre das evtl. auch ein Workaround.

#4

Hi Moritz,

und Danke. Mir geht es hier im Post darum zu erfahren ob bei uns einprinzipielles Problem vorliegt. Scheinbar wird in der Tat beides gepflegt, systemd und sysvinit. (Klar läuft immer nur eines von beiden). Und damit ist das Verhalten wie erwartet, und bei uns liegt kein prinzipielles Problem vor. Supi!

NACHTRAG/EDIT: Scheinbar doch. Stichwort “insserv” ist installiert, siehe später im thread.

Das bringt mich dann wieder zu /etc/init.d/bind9. Die Datei wäre ja dann momentan nicht mit vollkommen korrekter Abhängigkeitsbeschreibung ausgeliefert. Die harte Abhängigkeit zu samba-ad-dc ist ja definitiv nicht vorhanden (weil UCS mehrere Backends unterstützt), und zu meiner Frage ob es dann nicht besser wäre Required-Start: mit Should-Start: zu ersetzen.

Wenn ja dann mache ich dafür einen bugreport auf und schreibe einen kleinen Patch

#5

Huhu,

und zu meiner Frage ob es dann nicht besser wäre Required-Start: mit Should-Start: zu ersetzen.

Halte ich nicht für die richtige Variante, sondern eher, die Required-Start so anzupassen, wie die Abhängigkeit für das systemd-Drop-In auch angepasst wird, sprich wenn LDAP-Backend-Modul, dann samba-ad-dc in /etc/init.d/bind9 gar nicht erwähnen. Ja, ein Bugreport wäre dafür super (ich hab eben auf die Schnelle keinen dazu passenden gefunden).

#6

Halli Hallo,

es scheint nun ein Bug-Report (wieder) da zu sein: https://forge.univention.org/bugzilla/show_bug.cgi?id=49440

Gibt es denn einen einfachen Patch oder entsprechende Befehle, den/die ich schon anwenden könnte?

Grüße,
Bernd

#7

Moin Bernd,
Jepp, der bug report trifft das Problem super gut.

Als schneller Workaround: (works for me! Ich bin nur Anwender, diese Lösung ist also nicht “approved”)
Das was ich getan habe war die Datei /etc/init.d/bind9 temporär manuell zu ändern. Ich habe die harte Abhängigkeit von samba-ad-dc durch eine weiche Abhängigkeit ersetzt, also dort die Zeilen # Required-Start: slapd samba-ad-dc und # Required-Stop: slapd samba-ad-dc ersetzt mit # Should-Start: slapd samba-ad-dc und # Should-Start: slapd samba-ad-dc.

Danach habe ich mittels apt-get install -f das bind9 Paket installiert. Da durch die Änderung die Abhängigkeiten von insserv nicht mehr verletzt werden klappt das ohne Fehler.

Danach wurde die Datei /etc/init.d/bind9 wieder in den Originalzustand versetzt, damit sie durch zukünftige Updates überschrieben werden kann.

Wie Moritz schon schrieb, es wird ja ein systemd benutzt, die Datei /etc/init.d/bind9 wird also nach der Installation nicht mehr wirklich genutzt und “legacy”. Dein named sollte also nach dieser Aktion gestartet sein.

Zur Sicherheit solltest Du dann wohl noch einmal ein univention upgrade durchführen, um zu sehen ob wirklich alles in Ordnung und auf dem neuesten Stand ist. Auf der Kommandozeile (im screen oder tmux, und Vorsicht: Dieser Befehl fragt nicht mehr sondern installiert sofort) ein univention-upgrade --ignoressh --noninteractive --ignoreterm ausführen. Oder eben auf der Weboberfläche auf Update (oder so) klicken.

Gruß Lutz

1 Like
#8

Moin Moritz,
Deine Variante ist viel eleganter, aber ich glaube das geht so nicht. Die Datei /etc/init.d/bind9 ist ja Teil vom deb, und deshalb wird insserv ausgeführt bevor univention da wirklich eine Chance hat etwas in der Datei zu verändern. Eventuell würde das mit einem eingeschobenen preinstall script gehen, ich habe da nicht wirklich Ahnung. Auf jeden Fall wäre das ein großer Aufwand. Aber elegant :wink:

Wie auch immer die finale Lösung sein wird, ich bin jetzt eininteressierter Zaungast in https://forge.univention.org/bugzilla/show_bug.cgi?id=49440 :wink:

#9

Hallo und einen guten Morgen @damrose und @pmhahn,

vom Bugreport:

I also found that insserv on the affected machine is from the unmaintained repository - starting with UCS 4.3 insserv was moved to unmaintained.

Das sagt mir das insserv nicht mehr wirklich benötigt wird, korrekt? Da mein System super mit systemd arbeitet die Frage ob ich hier im Laufe der Zeit einfach nur übersehen habe es zu deinstallieren? Gibt es dazu eine Anleitung?

Liebe Grüße aus Berlin Lutz

#10

Moin Lutz,

das hat so auch bei mir funktioniert. Ein dpkg --configure -a reichte dann bei mir und zeigt zwar 7 mal:

insserv: Script bind9 is broken: incomplete LSB comment.
insserv: missing `Required-Start:' entry: please add even if empty.
insserv: missing `Required-Stop:'  entry: please add even if empty.

läuft aber durch.

Danke,
Bernd

PS:

Die Frage habe ich mir auch gestellt :slight_smile:

#11

Aus historischen Gründen nutzt UCS runit, um wichtige Dienste am Leben zu halten. Da aber bis vor UCS-4.2 klassische SysV-Init benutzt wurde, waren passende init-Skripte notwendig, um die runit-Dienste auch zu starten und zu stoppen. insserv wird/wurde dafür verwendet, die Skripte anhand der Abhängigkeiten anstatt der zum Zeitpunkt des Paketbau definierten und von Hand vergebenen Ordnungsnummer in die richtige Reihenfolge zu bringen.
Mit UCS-4.2 erfolgte dann die Umstellung auf systemd, aber bisher ist die nicht vollständig umgesetzt und wir haben damit jetzt derzeit eine hässliche Mischung aus 3 Init-Systemen: SysV-Init, runit und systemd. insserv wird dann eigentlich nicht mehr benötigt, ist aber ggf. weiterhin auf alt-Systemen installiert, die vor UCS-4.2 aufgesetzt wurden.
Da insserv mit 4.2 nicht mehr notwendig ist, ist es inzwischen von unserem Mechanismus aus versehen(?) als unmaintained deklariert worden. Mit UCS-4.3-2 gab es ein Update von Debian, wobei beim Import dann unsere Patches verloren gegangen sind, was jetzt zu besagtem Bug #49440 geführt hat.

Unser Ziel ist es, alle Dienste auf systemd umzustellen, wobei wir mit BIND9 angefangen haben: Bug #43689. Dabei haben wir dann feststellen müssen, das wir die SysV-init-Skript derzeit noch nicht loswerden können: Es wurde damals die Entscheidung getroffen, schon während der Installation von DVD die Dienste zu starten, um sie einrichten zu können. Debian verbietet das in seiner Policy, aber das wird von UCS ignoriert und führt zu zahlreichen Problemen: Eins ist, das während der Installation eben noch kein systemd verwendet wird und damit BIND9 über das klassische-init-Skript gestartet werden muss. Nur dafür haben wir es noch.
Beim wieder hinzufügen war der Kollege dann leider zu übereifrig und hat die Required-Start: samba-ad-dc-Zeilen hinzugefügt, um nur eine Warnung zu verhindert, was jetzt aber zu einem Problem wird. Mir war das damals in der QA auch nicht aufgefallen, weil es eben nur Systeme mit installierten insserv und ohne Samba4 betrifft.

Zum beheben des konkreten Problem reicht es, in der /etc/init.d/bind9 die besagten Zeilen zu löschen:

sed -i -e '/^# Required-St/s/ samba-ad-dc//' /etc/init.d/bind9

Nach der Installation reicht dann ein ucr commit /etc/init.d/bind9, um die Datei erneut generieren zu lassen. Ich arbeite aber gerade noch an einem Update, was das für zukünftige Updates automatisch macht - für Kunden, die bereits jetzt in das Problem gelaufen sind, hilft das natürlich leider nichts mehr.

2 Likes
#12

Wir haben einen bug report, eine wirklich ausführliche Beschreibung des Problems, einen workaround - ich setzte das Thema auf [solved]. Danke an alle Beteiligten

Das einzige was mir noch fehlt wäre ein kleiner Hinweis ob man insserv und eventuell auch initscripts von älteren Systemen (ursprünglich mit einer Version älter als UCS-4.3 installiert) auch deinstallieren kann und auch deinstallieren sollte, wenn man auf die aktuelle Version aktualisiert hat und keine Probleme mit systemd hat. Schließlich haben die neueren Systeme es nicht mehr installiert und dieses Überbleibsel der Vergangenheit ist ja der Auslöser des aktuellen Übels.
Wenn Ja: muss neben dem reinen deinstallieren der Pakete auf noch etwas geachtet werden? Beispielsweise die grub config neu erzeugen lassen oder ähnliches?

#13

Meinem Wissen nach können folgende Pakete gefahrlos entfernt werden:

  • init
  • initscripts
  • insserv
  • systemd-sysv
  • sysv-rc
  • sysvinit

Auf einem bereits installierten UCS wird sowieso systemd verwendet und die Pakete werden damit nicht mehr benötigt.
Bevor man das aber macht, sollte man sich vergewissern, dass durch das apt-get remove --purge init initscripts insserv systemd-sysv sysv-rc sysvinit nicht noch zusätzliche Pakete entfernt werden und man plötzlich ohne wichtige Dienst dasteht. Der Befehl muss explizit bestätigt werden, weil das Paket init noch von UCS-4.3-Zeiten als Important: yes markiert ist.

1 Like
Mastodon