DNS/bind läuft nicht mehr nach Migrationsversuch

german

#1

Hallo zusammen,

nach einem erfolglosen Versuch, den kompletten Server auf eine neue Hardware zu migrieren, soll der bis dahin vorhandene, einzelne DC-Master vorerst weiter betrieben werden. Jedoch wurde während des Migrationsversuchs etwas in seinem DNS zerschossen. Bind läuft nicht mehr an und erzeugt seither minütlich folgende Fehlermeldungen in /var/log/syslog:

Feb 16 21:08:20 xxxxx named[28130]: starting BIND 9.8.4-rpz2+rl005.12-P1 -c /etc/bind/named.conf.samba4 -f -d 0 Feb 16 21:08:20 xxxxx named[28130]: built with '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' '--with-geoip=/usr' '--enable-ipv6' '--with-dlz-dlopen' 'CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2' Feb 16 21:08:20 xxxxx named[28130]: ---------------------------------------------------- Feb 16 21:08:20 xxxxx named[28130]: BIND 9 is maintained by Internet Systems Consortium, Feb 16 21:08:20 xxxxx named[28130]: Inc. (ISC), a non-profit 501(c)(3) public-benefit Feb 16 21:08:20 xxxxx named[28130]: corporation. Support and training for BIND 9 are Feb 16 21:08:20 xxxxx named[28130]: available at https://www.isc.org/support Feb 16 21:08:20 xxxxx named[28130]: ---------------------------------------------------- Feb 16 21:08:20 xxxxx named[28130]: adjusted limit on open files from 4096 to 1048576 Feb 16 21:08:20 xxxxx named[28130]: found 4 CPUs, using 4 worker threads Feb 16 21:08:20 xxxxx named[28130]: using up to 4096 sockets Feb 16 21:08:20 xxxxx named[28130]: loading configuration from '/etc/bind/named.conf.samba4' Feb 16 21:08:20 xxxxx named[28130]: reading built-in trusted keys from file '/etc/bind/bind.keys' Feb 16 21:08:20 xxxxx named[28130]: using default UDP/IPv4 port range: [1024, 65535] Feb 16 21:08:20 xxxxx named[28130]: using default UDP/IPv6 port range: [1024, 65535] Feb 16 21:08:20 xxxxx named[28130]: listening on IPv6 interfaces, port 53 Feb 16 21:08:20 xxxxx named[28130]: listening on IPv4 interface lo, 127.0.0.1#53 Feb 16 21:08:20 xxxxx named[28130]: listening on IPv4 interface eth0, 192.168.178.10#53 Feb 16 21:08:20 xxxxx named[28130]: listening on IPv4 interface docker0, 172.17.42.1#53 Feb 16 21:08:20 xxxxx named[28130]: generating session key for dynamic DNS Feb 16 21:08:20 xxxxx named[28130]: sizing zone task pool based on 1 zones Feb 16 21:08:20 xxxxx named[28130]: Loading 'samba4.zone' using driver dlopen Feb 16 21:08:20 xxxxx named[28130]: samba_dlz: ldb: dsdb_get_schema: refresh_fn() failed Feb 16 21:08:20 xxxxx named[28130]: samba_dlz: ldb: schema_load_init: dsdb_get_schema failed Feb 16 21:08:20 xxxxx named[28130]: samba_dlz: ldb: module schema_load initialization failed : Operations error Feb 16 21:08:20 xxxxx named[28130]: samba_dlz: ldb: module rootdse initialization failed : Operations error Feb 16 21:08:20 xxxxx named[28130]: samba_dlz: ldb: module samba_dsdb initialization failed : Operations error Feb 16 21:08:20 xxxxx named[28130]: samba_dlz: ldb: Unable to load modules for /var/lib/samba/private/sam.ldb: schema_load_init: dsdb_get_schema failed Feb 16 21:08:20 xxxxx named[28130]: samba_dlz: Failed to connect to /var/lib/samba/private/sam.ldb Feb 16 21:08:20 xxxxx named[28130]: dlz_dlopen of 'samba4.zone' failed Feb 16 21:08:20 xxxxx named[28130]: SDLZ driver failed to load. Feb 16 21:08:20 xxxxx named[28130]: DLZ driver failed to load. Feb 16 21:08:20 xxxxx named[28130]: loading configuration: failure Feb 16 21:08:20 xxxxx named[28130]: exiting (due to fatal error)
Die System-Fehlerdiagnose der UMC bringt:

1 der konfigurierten Nameserver anworten nicht auf DNS-Anfragen. Bitte sicherstellen, dass die DNS-Einstellungen in Modul "Netzwerk-Einstellungen" korrekt konfiguriert sind. Falls das Problem bestehen bleibt stellen Sie sicher, dass der Nameserver mit dem Netzwerk verbunden ist und die DNS-Forwarder das Internet erreichen können (www.univention.de). Der Nameserver 192.168.178.10 (UCR Variable 'nameserver1') ist nicht ansprechbar: Eine Zeitüberschreitung trat beim Erreichen des Nameservers auf (ist er online?).Dies stimmt jedoch nur teilweise. In einem Terminal klappt ein ping auf den Nameserver sowohl mit seiner IP, als auch über den Hostnamen. Auch externe Namen werden aufgelöst, jedoch erst nachdem ich in den Netzwerkeinstellungen zusätzlich zum nameserver1 dem nameserver2 die IP des davorgeschalteten Routers zugewiesen hatte. Ein Eintrag nur bei dns/forwarder1 hatte zuvor keinen Erfolg. Die DNS-Auflösung scheint aber grundsätzlich zu funktionieren.

Mit den vorstehenden Fehlermeldungen von bind komme ich jedoch nicht weiter. Im Forum habe ich jetzt bereits eine Menge Threads gefunden, die mit ähnlichen Problemen zu tun hatten. Dabei bin ich aber noch zu keiner Lösung gekommen, welche mein Problem beheben konnte.
Wo kann ich hierbei weiter ansetzen?

Gruß
Uwe


#2

Moin,

die Fehlermeldungen sehen für mich danach aus, als wenn die Samba-4-Datenbanken zerschossen sind. Hintergrund: Bind kann als Backend entweder das OpenLDAP oder das Samba-4-LDAP nutzen. Bei Ihnen (und den meisten anderen UCS-4-mit-Samba-4-Installationen) ist das Backend Samba 4.

Ich kann mir gut vorstellen, dass Sie in so einer Situation entweder jetzt schon Probleme mit Samba selber haben oder später noch bekommen werden. Sinnvollerweise sollten Sie daher das Samba-4-LDAP neu aufsetzen. Dafür haben Sie zwei Optionen:

[ol][li]Stellen Sie Samba 4 und das OpenLDAP aus einem Backup wieder her. UCS selber sichert beide Verzeichnisse täglich nach »/var/univention-backup«. Sie sollten der Konsistenz halber sowohl das OpenLDAP (»ldap-backup_DATUM.ldif.gz«), das Samba-4-Verzeichnis (»samba/samba4_private.DATUM.tar.bz2« sowie »samba/sysvol.DATUM.tar.bz2«) und die UCR-Variablen (»ucr-backup_DATUM.tgz«) vom selben Tag wiederherstellen. Infos hierzu finden Sie im Wiki.[/li]
[li]Provisionieren Sie nur das Samba-4-Verzeichnis aus den Informationen im OpenLDAP neu. Dadurch gehen potenziell Informationen aus dem Samba-4-Verzeichnis verloren, die nicht ins OpenLDAP synchronisiert werden (z.B. falls Sie mit AD-Standorten arbeiten und Rechner dort entsprechend eingefügt haben), aber gerade bei kleineren Umgebungen ist das eher unkritisch. Dieser Vorgang ist in der Support-Datenbank beschrieben.[/li][/ol]

Beachten Sie, dass beim Wiederherstellen aus dem Backup andere UCS-Server anschließend neu gejoint werden sollten, damit sie wieder auf einem konsistenten Stand sind. Weiterhin kann es sein, dass Windows-Clients neu gejoint werden müssen, wenn Sie ein zu altes Backup nehmen.

Daher rate ich eigentlich erst mal zu Methode 2.

Gruß,
mosu


#3

Hallo Herr Bunkus,

die Wiederherstellung nach Methode 2 scheiterte gleich bei Punkt 3 an ldbsearch… welcher keine Verbindung zur Datenbank bekam.

Ich bin dann nach Methode 1 vorgegangen. Dabei bin ich ab “Restoring the configuration” eingestiegen und konnte alles erfolgreich durchführen, bis auf das Zurückspielen der user homes und der ACLs ganz am Ende, da ich das Sichern der Berechtigungen ganz am Anfang nicht durchgeführt hatte. Die Homeverzeichnisse sind aber vollständig vorhanden, soweit erkennbar. Damit läuft der Server jetzt wieder, die eingangs beschriebenen Fehler treten nicht mehr auf.

Jedoch ergeben sich jetzt anderere Punkte.
Zarafa läuft ebenfalls auf diesem Server. Seit dem Restore ist keine Anmeldung mehr am Webapp bzw. über Z-Push möglich. Es wird jeweils ein falscher Benutzername/falsches Passwort des Users bemängelt. Der Fehler bleibt auch nach Änderung des entsprechenden Passworts in der UMC bestehen.
In /var/log/zarafa/server.log taucht zu diesem Zeitpunkt auf:

Cannot instantiate user plugin: Failure connecting any of the LDAP servers Unable to instantiate user plugin
Nagios meldet ebenfalls Fehler: SERVICE ALERT: server1.domain.tld;UNIVENTION_JOINSTATUS;CRITICAL;HARD;1;CRITICAL: auth failed: ldapsearch -x -h server1.domain.tld -p 7389 -D <ldap_hostdn>Der Dienst nagios3 steht in der UMC auf gestoppt. Ein manuelles Starten gelingt nicht.

Was mir noch aufgefallen ist: /var/log/samba/log.samba läuft voll mit

[2016/02/17 23:34:37.141500, 0, pid=4244] ../lib/util/util_runcmd.c:328(samba_runcmd_io_handler) /usr/sbin/samba_dnsupdate: dns_tkey_negotiategss: TKEY is unacceptable [2016/02/17 23:34:37.199666, 0, pid=4244] ../source4/dsdb/dns/dns_update.c:294(dnsupdate_nameupdate_done) ../source4/dsdb/dns/dns_update.c:294: Failed DNS update - NT_STATUS_UNSUCCESSFUL
Hier weiß ich jetzt erstmal nicht weiter.

Gruß
Uwe


#4

Moin,

zum Durchsuchen des LDAPs wird unter UCS im Normalfall eine Anmeldung benötigt; anonymes Durchsuchen ist per Default nicht erlaubt. Dafür wird für jeden Computer ein Objekt im LDAP angelegt. Ein Befehl wie »univention-ldapsearch« nutzt dabei das Objekt des aktuellen Computers zur Anmeldung; das dazugehörige Passwort steht in der Datei »/etc/machine.secret«. Derselbe Account wird auch von anderen auf diesem Computer laufenden Anwendungen benutzt, um das LDAP zu durchsuchen. Dazu zählt auch Zarafa.

Bei Ihnen passt also das Passwort in »/etc/machine.secret« nicht mehr zu dem, was momentan im LDAP steht. Das kann daran liegen, dass dieses Computerkennwort regelmäßig aktualisiert wird. Sie haben ein Backup vom LDAP eingespielt, und daher kann es sein, dass »/etc/machine.secret« nun abweicht.

Sie können einen Passwortwechsel triggern. Wie das geht, steht in diesem Support-Datenbank-Artikel.

Ein kurzer Test, ob’s funktioniert hat, ist der Aufruf von »univention-ldapsearch«.

Falls Sie weitere Server in der UCS-Domäne haben, so betrifft das die anderen Server genau so.

Zarafa sollten Sie anschließend neu starten. Es genügt, den Dienst »zarafa-server« neu zu starten, da alle anderen Zarafa-Dienste (z.B. das Gateway) zur Authentifizierung mit dem Zarafa-Server-Prozess kommunizieren und nicht direkt mit dem LDAP-Server.

Gruß,
mosu


#5

Hallo,

in der Tat war das abweichende Passwort in /etc/machine.secret für das Verhalten verantwortlich. Das Vorgehen nach diesem Support-DB-Artikel hat den Fehler behoben. Eine Anmeldung ist an der Webapp und über Z-Push möglich.

Ein bislang unentdeckter Fehler bleibt noch übrig. Die Anmeldung an der Nagios-Oberfläche scheitert jetzt.
/var/log/auth.log liefert dazu während des Anmeldeversuchs:Feb 20 10:49:41 server1 apache2: pam_tally(nagios:auth): Error opening /var/log/faillog for update Feb 20 10:49:41 server1 apache2: pam_tally(nagios:auth): Error opening /var/log/faillog for read Feb 20 10:49:41 server1 unix_chkpwd[8551]: check pass; user unknown Feb 20 10:49:41 server1 unix_chkpwd[8551]: password check failed for user (Administrator) Feb 20 10:49:41 server1 apache2: pam_unix(nagios:auth): authentication failure; logname= uid=33 euid=33 tty= ruser= rhost=192.168.178.xx user=Administrator Feb 20 10:49:41 server1 apache2: pam_krb5(nagios:auth): authentication failure; logname=Administrator uid=33 euid=33 tty= ruser= rhost=192.168.178.xx
Das Passwort des Administrators habe ich bereits geändert. Ein erneuter Versuch bringt aber keine Veränderung.

Gruß
Uwe


#6

Nachtrag:

bei weiteren Untersuchungen zeigen sich mit univention-s4connector-list-rejected eine ganze Menge Einträge unter S4 rejected: User, Gruppen sowie Rechner, jedoch nicht alle im System vorhandenen. Hat dies noch mit dem Zurückspielen von Samba/LDAP aus dem Backup zu tun? Wie bekomme ich dies wieder konsistent?

Gruß
Uwe


#7

Gut möglich. Vielleicht jetzt doch noch mal ein Neuprovisionieren des Samba 4?


#8

Hallo nochmal,

die Neuprovisionierung von Samba4 ist durchgelaufen. Anschliessend war noch einmal ein anstossen der Joinscripte notwendig. Danach gab es lediglich zwei verbleibende S4 rejects. Die user join-slave und join-backup waren aufgeführt. Ein Öffnen der beiden Benutzer in der UMC brachte jeweils folgende Meldung:[quote]Die folgenden leeren Eigenschaften wurden im Formular auf Vorgabewerte gesetzt. Die Werte werden beim Speichern angewendet.
Zarafa - Zarafa-Rolle: Keine
(Erweiterte Einstellungen) - Mailabruf von externen Servern - Protokoll: IMAP[/quote]
Durch das Übernehmen dieser Änderungen werden diese user nun nicht mehr rejected. Bis hierhin wunderbar, das sieht schon wesentlich besser aus!

Die Anmeldung des Administrators an der Nagios-Oberfläche jedoch scheitert nach wie vor mit den gleichen Einträgen in /var/log/auth.log:Feb 22 17:53:12 server1 apache2: pam_tally(nagios:auth): Error opening /var/log/faillog for update Feb 22 17:53:12 server1 apache2: pam_tally(nagios:auth): Error opening /var/log/faillog for read Feb 22 17:53:12 server1 unix_chkpwd[9391]: check pass; user unknown Feb 22 17:53:12 server1 unix_chkpwd[9391]: password check failed for user (Administrator) Feb 22 17:53:12 server1 apache2: pam_unix(nagios:auth): authentication failure; logname= uid=33 euid=33 tty= ruser= rhost=192.168.178.xxx user=Administrator Feb 22 17:53:13 server1 apache2: pam_krb5(nagios:auth): authentication failure; logname=Administrator uid=33 euid=33 tty= ruser= rhost=192.168.178.xxx
kinit mit verschiedenen usern bringt immer:kinit: krb5_get_init_creds: No ENC-TS found
Da läuft noch etwas mit Kerberos nicht rund…


#9

Hallo,

hat denn evtl. noch jemand eine Idee zu dem Fehler bei Kerberos? Ich finde im Zusammenhang mit UCS nichts, was mich bei der Wiederherstellung weiter bringt.

Gruß
Uwe


#10

Moin,

Sie können mal probieren, eine neue Keytab erstellen zu lassen. Dazu führen Sie einmal das Script »/usr/share/univention-samba4/scripts/create-keytab.sh« aus.

Haben Sie auch die »/etc/ldap.secret« richtig wiederhergestellt? Das können Sie testen, indem Sie versuchen, sich mit dem LDAP-Admin anzumelden und das LDAP zu durchsuchen. Dazu dient der folgende Befehl:

ldapsearch -x -H ldap://localhost:7389/ -b $(ucr get ldap/base) -D cn=admin,$(ucr get ldap/base) -w$(</etc/ldap.secret)

Unterschied zu »univention-ldapsearch«: bei »univention-ldapsearch« wird zur Anmeldung der Computeraccount desjenigen Computers im LDAP genommen, auf dem der Befehl ausgeführt wird; das Passwort dazu steht in »/etc/machine.secret«. Es gibt aber noch den Super-Duper-Ober-LDAP-Admin, und dessen Passwort steht in »/etc/ldap.secret«.

Gruß,
mosu


#11

Hallo Herr Bunkus,

vielen Dank für die Antwort. In der Zwischenzeit habe ich den Server auf der neuen Hardware von Grund auf neu installiert. Der Umzug der vorhandenen Daten (Zarafa, Owncloud, Bareos, Userverzeichnisse, …) hat gut funktioniert. Die Benutzer habe ich jedoch auf dem neuen Rechner neu angelegt, damit von dem nicht korrekt lauffähigen Zustand des alten Rechners nichts übernommen wird. Da der alte Rechner zwischenzeitlich abgeschaltet ist, habe ich Ihre letzten Hinweise jedoch nicht mehr testen können.

Gruß
Uwe