Nach Security-update unvention-directory-policy start fails

UCS - Univention Corporate Server
#1

Hallo,

nach Einspielen des Secrurity-Updates 2 zu UCS 2.4 auf dem Domain Master scheitert beim Reboot der Start der univention-directory-policy. Auch der LDAP-Server ist angeblich nicht erreichbar, obwohl slapd auf dem Domain Master läuft. Vermutlich aus demselben Grund meldet der univention-directory-listener im syslog fortlaufend: “failed to connect to notifier”.
Offensichtlich läuft da jetzt einiges falsch, aber was? Bis zu dem Security-update klappte alles einwandfrei.
Ich hoffe, da kann mir schnell jemand weiterhelfen.

MfG - swimmer

#2

Ich will die Fragestellung mal eingrenzen. Das Kernproblem scheint zu sein, dass der Listener auf dem Domain Master den Ldap-Server auf selbigem nicht kontaktieren kann. Wie lässt sich herausfinden, warum nicht? Wenn ich diesen Fehler beheben kann, bin ich wahrscheinlich einen großen Schritt weiter.

Mit Dank für jede Hilfe

swimmer

#3

P.S. Vielleicht ist das Kernproblem aber doch ein anderes. Wie ich jetzt erst gesehen habe, erscheint nach jedem Neustart des Univention-Directory-Listeners eine Segfault-Meldung im Log, bevor es dann endlos weitergeht mit “failed to connect to notifier”.

#4

Hallo,

die beschriebenen Meldungen von Listener und Notifier sind vermutlich Folgefehler die entstehen da der LDAP-Server nicht abgefragt werden kann.

Wenn der “slapd”-Prozess läuft, prüfen Sie bitte ob eine Verschlüsselte Verbindung möglich ist:

eval $(ucr shell) ldapsearch -x -ZZZ -s base -h $hostname.$domainname

Mit freundlichen Grüßen
Janis Meybohm

#5

Hallo Herr Meybohm,

danke, dass Sie sich der Sache annehmen.
Die verschlüsselte Abfrage klappt einwandfrei. Am Ende steht:
search: 3
result: 0 Success

numResponses: 2

numEntries: 1

MfG swimmer

#6

Hallo,

die Problemlage scheint sehr komplex zu sein.
Es läuft in einer DomU eine pfSense-Firewall, die eine Bridge auf eine zweite Netzwerkkarte Eth1 für die Verbindung nach außen benutzt. In der Dom0 sieht die Datei /etc/network/interfaces in Anlehnung an einen C’T- Debian Server so aus:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.1.2
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
gateway 192.168.1.1

eth1 -> extern

allow-hotplug eth1
iface eth1 inet manual
up ifconfig eth1 0.0.0.0 promisc up

auto extern
iface extern inet manual
bridge_ports eth1
bridge_fd 1
bridge_stp off
bridge_hello 1

Im Prinzip funktioniert das auch. Aber die Schnittstelle Eth1 ist nun auch im Domain Master mit der IP 0.0.0.0 registriert, was zur Folge hat, dass diese IP automatisch zusätzlich in die Datei /etc/hosts des Domain Masters eingetragen wird. Und das scheint alles durcheinander zu bringen. Wo muss hier eine Fehlerkorrektur ansetzen?

MfG - swimmer

#7

Im letzten Security Update wurde der Kernel aktualisiert. Funktioniert es wieder, wenn mit dem vorherigen Kernel gestartet wird?

Viele Grüße
Stefan Gohmann

Mastodon