Kein Host-Account mehr für DC-Slave in Samba 4

Moin,

ich hab’s auch gelesen, plädiere aber wieder für die Radikalvariante: Host aus LDAP entfernen, alle davon abhängigen Dinge entfernen (Hostnamen, falls die noch in irgendwelchen DNS-Einträgen herumgeistern), verifizieren, dass im S4 ebenfalls alles davon weg ist, anschließend neu joinen. Auch wenn das sehr nach »have you tried turning it off and on again?« klingt: dann hat man einen definierten Ausgangszustand.

Gruß,
mosu

Hallo,

aber es sollte doch auch kein Problem sein, vorher noch mal einen normalen Sync aus den LDAP zu probieren (also keinen Resync!). Die Radikal-Variante kann man danach doch immer noch probieren sofern nötig. Oder sehe ich das Falsch?

Danke und viele Grüße,
SirTux

Kaputter sollte es nicht werden :wink:

Hallo,

heute gab es Probleme mit der Vertrauenstellung im Netz des problematischen SDCs. Dies hat mich dazu bewogen erstmal alle Updates einzuspielen. Dies hat aber erstmal nichts gebracht. Danach habe ich einen rsync des gelöschten Host-Accounts erzwungen. Danach klappte wieder der Login auf dem Windows-Client. Der Host-Account sieht auch wieder in Ordnung aus.

Schon vor dem Resync bekomme ich aber folgende Ausgabe beim Samba-Tool auf den anderen DCs (Auszug):

==== INBOUND NEIGHBORS ====

DC=ForestDnsZones,DC=top2,DC=top1
        Default-First-Site-Name\DELETED-SDC via RPC
                DSA object GUID: 0c81b8f5-df46-49e0-a5c9-999baec66d90
                Last attempt @ Sun Aug  7 23:02:02 2016 CEST failed, result 2 (WERR_BADFILE)
                7308 consecutive failure(s).
                Last success @ NTTIME(0)

DC=DomainDnsZones,DC=top2,DC=top1
        Default-First-Site-Name\DELETED-SDC via RPC
                DSA object GUID: 0c81b8f5-df46-49e0-a5c9-999baec66d90
                Last attempt @ Sun Aug  7 23:02:02 2016 CEST failed, result 2 (WERR_BADFILE)
                7308 consecutive failure(s).
                Last success @ NTTIME(0)

DC=top2,DC=top1
        Default-First-Site-Name\DELETED-SDC via RPC
                DSA object GUID: 0c81b8f5-df46-49e0-a5c9-999baec66d90
                Last attempt @ Sun Aug  7 23:02:03 2016 CEST failed, result 2 (WERR_BADFILE)
                7308 consecutive failure(s).
                Last success @ NTTIME(0)

CN=Schema,CN=Configuration,DC=top2,DC=top1
        Default-First-Site-Name\DELETED-SDC via RPC
                DSA object GUID: 0c81b8f5-df46-49e0-a5c9-999baec66d90
                Last attempt @ Sun Aug  7 23:02:04 2016 CEST failed, result 2 (WERR_BADFILE)
                7308 consecutive failure(s).
                Last success @ NTTIME(0)

CN=Configuration,DC=top2,DC=top1
        Default-First-Site-Name\DELETED-SDC via RPC
                DSA object GUID: 0c81b8f5-df46-49e0-a5c9-999baec66d90
                Last attempt @ Sun Aug  7 23:02:05 2016 CEST failed, result 2 (WERR_BADFILE)
                7308 consecutive failure(s).
                Last success @ NTTIME(0)

Ein weiterer Rejoin ist hier wahrscheinlich das Mittel der Wahl? Der aus dem LDAP resyncte Host-Account wurde übrigens auch auf den FAILED-SDC repliziert.

Danke und viele Grüße,
SirTux

Moin,

ich gehe davon aus, dass die Kerberos-Daten des Slaves schlicht nicht mehr zu denen im LDAP passen, abgelaufen sind oder so, und dadurch keine vernünftige Verbindung mehr zustande kommt. Ja, ein Rejoin ist hier das Mittel der Wahl; es ist auch schlicht der geringste Aufwand.

Gruß,
mosu

Hallo,

dies scheint soweit geklappt zu haben :slight_smile:

Allerdings tauchen beim anderen SDC ähnliche Einträge auf für den Backup DC und den FAILED-SDC. Seltsamerweise lief über ihn aber der Samba-4-Rejoin. Den anderen SDC sollte ich vermutlich auch noch mal rejoinen oder?

EDIT: Für den DC Master war als letztes erfolgreiches Datum der 02.08 angegeben. Nach einem Samba-Neustart scheint der Kontakt mit dem DC Master und dem DC Backup wieder zu funktionieren. Für den FAILED-SDC gibt es jetzt folgende Einträge:

Last attempt @ NTTIME(0) was successful
0 consecutive failure(s).
Last success @ NTTIME(0)

EDIT2: Ich hab wohl doch nicht lang genug gewartet. Die Verbindung mit dem FAILED-SDC scheint jetzt auch in Ordnung zu sein.

“Der andere” SDC scheint sich wohl regelmäßig mal aufzuhängen. Aufgefallen ist mal wieder, weil eine Windows-Anmeldung nicht funktioniert hat. Ein Samba-Neustart hat wieder geholfen.

Ist jemanden schon ähnliches aufgefallen? Der fragliche SDC läuft als KVM-VM.

Hier ist ein Log-Eintrag, der damit zeitlich korreliert:

./source4/rpc_server/common/forward.c:55(dcesrv_irpc_forward_callback)

Nach dem Neustart taucht er nicht mehr auf.

Keine Idee, sorry. Solch ein Verhalten habe ich bisher bei keinem von mir betreuten Server beobachtet.

Mastodon