nach einen reboot funktioniert bei meinen DC-Master die Authentifizierung nicht mehr. 1.Hinweis ist das Windows sich nicht an der Domäne anmeldet und auch keine Netzlaufwerke zur Verfügung stehen.
In der Datei /var/log/univention/listener.log steht alle 30 Sekunden
... LISTENER ( WARN ) : chosen server: xxxxxxxx.xxxxx.xxx:7389
... LISTENER ( ERROR ) : failed to connect to any notifier
... LISTENER ( WARN ) : can not connect any server, retrying in 30 seconds
invoke-rc.d slapd restart hat keine Änderung gebracht.
Den Debuglevel von slapd hatte ich auch schon auf -1 geändert, konnte aber keine Fehlermeldungen im Syslog finden.
Wo kann ich nach den Fehler suchen?
Die Debug-Ausgaben stehen in /var/log/debug, einige hundert Zeilen pro Sekunde. Bitte also Vorsicht mit Debuglevel -1 für längere Zeit.
Allerdings: “failed to connect to any notifier” da sollte man besser schauen, warum der Notifier selber nicht zu finden ist. Es ist ein Daemon “univention-directory-notifier”, der auf der Wildcard-Adresse (* oder : Port 6669 hört. Seln Logfile ist /var/log/univention/notifier.log, der Loglevel kann mit der UCR-Variable “notifier/debug/level” auf Werte von 0 (nichts) bis 4 (alles) gestellt werden.
[quote=“greif”]Hallo,
Allerdings: “failed to connect to any notifier” da sollte man besser schauen, warum der Notifier selber nicht zu finden ist. Es ist ein Daemon “univention-directory-notifier”, der auf der Wildcard-Adresse (* oder : Port 6669 hört. Seln Logfile ist /var/log/univention/notifier.log, der Loglevel kann mit der UCR-Variable “notifier/debug/level” auf Werte von 0 (nichts) bis 4 (alles) gestellt werden.
[/quote]
Auf Port 6669 hört bei mir nichts (netstat | grep 6669). Den Debuglevel habe ich von 1 auf 4 geändert, und danach ein Reboot gemacht.
Die letzte Meldung im Logfile ist:
03.09.15 07:52:38.427 DEBUG_INIT
Das passt zum letzten Reboot bevor der Fehler auftrat.
Beim Start des Dienstes auf der Konsole kommt:
[info] Starting Univention Directory Notifier daemon.
timeout: down: univention-directory-notifier: 0s, want up
failed.
Im angebenen Logfile gibt es wieder keine Einträge.
Wirklich? die letzte Meldung des Notifiers in seinem Log ist vier Tage alt? Da würde ich glatt vermuten, daß die Platte voll ist. Oder hatten Sie nur eine gleichlautende Meldung kopiert? Wie alt sind denn die jüngsten Logfiles überhaupt?
Gerade habe ich festgestellt das die Datei /usr/sbin/univention-directory-notifier nicht existiert.
Das war aber nicht die Lösung. Welche dateien werden noch benödigt?
Ich vermude das weitere Dateien fehlen oder falsche Zugriffsrechte haben.
da haben sich unsere Beiträge überschnitten. Und mein Vorschlag trifft dann wohl auch nicht mehr zu…
Wie bitte? /usr/sbin/univention-directory-notifier existiert nicht? Das muß erst mal einer schaffen, ein Programm verschwinden zu lassen, was systemseitig als “essentiell” geflaggt ist. Was war denn vor dem Reboot so alles gemacht worden?
Ist der Zustand der Pakete stimmig?
dpkg -C
Sind alle Join-Skripte durchgelaufen?
univention-check-join-status
Eine Kommandozeile zum Suchen der wirklich substantiellen Fehler kann ich nicht auf Anhieb sagen, aber der Notifier ist wahrscheinlich nicht die Ursache, sondern eine der Wirkungen.
Es gibt seit längeren 2 Probleme. Der Bootsektor ist verschwunden, und EFI fuktioniert nicht. Das habe ich versucht zu reparieren.
Als letztes habe ich das Update auf Version 4.0-3 errata302 gemacht.
nein
Die folgenden Pakete wurden entpackt, aber noch nicht konfiguriert.
Sie müssen mit dpkg --configure oder dem Konfigurations-Menüeintrag in
dselect konfiguriert werden, damit sie ordnungsgemäß funktionieren:
grub-efi-amd64-signed GRand Unified Bootloader, version 2 (EFI-AMD64 version,
Die folgenden Pakete sind nur halb konfiguriert, wahrscheinlich durch
Probleme während der ersten Konfiguration. Die Konfiguration sollte mit
dpkg --configure <Paket> oder mit dem Konfigurations-Menüeintrag in
dselect erneut versucht werden:
grub-efi-amd64 GRand Unified Bootloader, version 2 (EFI-AMD64 version)
Joined successfully
Davon gehe ich auch aus. Das Problem liegt irgentwo beim LDAP. Bind hat konnte sich auch nicht verbinden.
Gibt es hier Möglichkeiten zum testen?
Die einfachste Testmöglichkeit für LDAP ist das Skript “univention-ldapsearch”, im Prinzip ein Wrapper für ldapsearch welches das Maschinenkonto zur Authentifizierung benutzt, sich aber ansonsten wie ein normales ldapsearch verhält.
Das scheint zu funktionieren.
Der Notifier startet auch wieder. In /etc/runit/ haben Links und Dateien gefählt. Davon ist auch bind9 betroffen.
Ich glaube mitlerwile das hier auch mein Problem liegt. Der DNS läuft auf deen Server, liefert aber keine Informationen zu meiner Domäne.
Kann ich bind und alles was dazu gehört irgendwie neu installieren? Welche Pakete sind das genau?
im Allgemeinen sollte man “apt-get install --reinstall paket” machen können, das wird zum Beispiel beim Erneuern der kompletten SSL-Zertifikatskette so gemacht.
Für Bind gibt es ein Meta-Paket univention-bind
root@s:~# apt-cache depends univention-bind
univention-bind
Hängt ab von: univention-config
Hängt ab von: univention-base-files
Hängt ab von: bind9
Hängt ab von: univention-directory-manager-tools
Hängt ab von: univention-runit
Hängt ab von: shell-univention-lib
Hängt ab von: univention-ipcalc
Kollidiert mit: univention-bind-proxy
Kollidiert mit: <univention-dns>
Ersetzt: univention-bind-proxy
Ersetzt: <univention-dns>
root@s:~# apt-cache rdepends univention-bind
univention-bind
Reverse Depends:
univention-server-slave
univention-server-master
univention-server-backup
univention-network-common
univention-bind-proxy
univention-bind-proxy
univention-server-slave
univention-server-master
univention-server-backup
univention-bind-proxy
die Namensauflösung hat auch nach der Installation von bind nicht Funktioniert. Ich bin mir sicher das weitere Dateien "verschwunden"sind. Die alle zu suchen ist ein Fass ohne Boden und lohnt nicht.
Ich habe jetzt meinen DC-Backup zum Master gemacht. /usr/lib/univention-ldap/univention-backup2master -f hat hier super funktioniert. Die vermurkste Kiste installiere ich neu.