Hallo zusammen,
wir hatten schon öfter (auch hier geschildert) das Problem, dass man sich mit einem Linux-Image, das erfolgreich der Domäne beigetreten ist, auf anderen Rechnern nicht anmelden konnte. Das Image war vorher sauber, es wurde sich also noch nicht angemeldet, etc.
Ich bin dem nun mal nachgegangen, weil das bei uns zunehmend zu einem Problem wird:
-
Fund: nach dem Synchronisieren an einem anderen Rechner keine Anmeldung möglich („das hat leider nicht funktioniert“. In den Logs gab es einen SSSD-Fehler.
-
Fund: es fehlte die macct-Datei auf dem Server - macht Sinn, dann kann es nicht gehen. Aber warum?
-
Funde: Linbo erstellt keine macct-Datei - also in die
/var/log/linuxmuster/linbo/rsync-post-upload.log
geschaut. Auffällig gleich zu Beginn:HOSTNAME: UNKNOWN.corvi.linuxmuster.lan IP: 10.0.102.101
Warum unknown - steht in der Devices und ist auch auf dem Musterclient als hostname sichtbar. Testen wir mal den Hostnamen hier und da
-
Fund:
nslookup 10.0.102.101
liefert:101.102.0.10.in-addr.arpa name = admin-tarox. 101.102.0.10.in-addr.arpa name = alephnvme-ubnvm.corvi.linuxmuster.lan.
DAS sollte nicht so sein. admin-tarox hieß mal ein Rechner unter dieser Adresse, aber das ist lange her. Es gibt ihn schon sehr lange nicht mehr in der devices.csv. Auf dem Musterclient ist es noch seltsamer, da liefert der obige nslookup:
nslookup 10.0.102.101 Server: 10.0.0.1 Address 1: 10.0.0.1 server.corvi.linuxmuster.lan Name: 10.0.102.101 Address 1: 10.0.102.101 admin-tarox
Also NUR den alten Hostnamen ohne Domäne. Ich durchsuche also mit
samba-tools
das AD:samba-tool dns query localhost corvi.linuxmuster.lan @ ALL | grep admin-tarox
liefert aber kein Ergebnis. Woher kommt dann der alte Rechnername?! -
Fund: auf gut Glück greppe ich mal die AD-Datenbank auf dem Server:
grep -r admin-tarox *
ergibt tatsächlich:grep: private/sam.ldb.d/DC=CORVI,DC=LINUXMUSTER,DC=LAN.ldb: binary file matches grep: private/sam.ldb.d/DC=DOMAINDNSZONES,DC=CORVI,DC=LINUXMUSTER,DC=LAN.ldb: binary file matches
-
Fund: der einzige Grund, warum Linbo die macct-Datei nicht erstellt, scheint mir hier zu liegen:
unicodepwd="$("$LDBSEARCH" "$url" "(&(sAMAccountName=$compname$))" unicodePwd | grep ^unicodePwd:: | awk '{ print $2 }')" [...] if [ -n "$unicodepwd" ]; then
Ich habe das händisch getestet und mit dem korrekten Hostnamen kommt auch das entsprechende Passwort. Aber da
$compname$
sich vonRSYNC_HOST_NAME
ableitet, bleibt die Variable hier leer.
Im Moment vermute ich, dass der Upload der aktuellen macct-Datei fehlschlägt, weil eine Prüfung des Hostnames im DNS schief läuft. Das würde aber bedeuten, dass man wirklich NIE irgendwelche IP-Adressen wiederverwenden darf. Oder dass - warum auch immer - hier irgendwelche Reste im DNS liegen, die dort nicht sein dürften. Und das ist bisher schon öfter passiert, wenn wir IPs neu vergeben haben (gibt’s auch hier im Forum etwas zu).
Ich werde da weiter suchen - aber hat jemand eine Idee, wie man diesem Problem näher kommen könnte? Und @thomas hast Du eine Idee, wie man RSYNC_HOST_NAME
debuggen könnte? Wie wird diese Variable erstellt? Kann man die Erstellung der macct-Datei evtl. (vorläufig) nachträglich erzwingen?
Ich bin mir nicht sicher, ob das ursächlich ein sophomorix-Problem oder ein Samba-Bug ist (es gibt da z.B. ein altes Ticket von Univention) und/oder ob man das über Linbo anders abfangen könnte (und will - ich denke eher, man müsste das DNS-Problem lösen).
In jedem Fall bin ich jeden Hinweis dankbar.
Viele Grüße
Thomas