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

Hallo,

heute Nacht gegen 1 Uhr scheint der Host-Account von einem DC-Slave aus dem Samba 4-LDAP verschwunden zu sein. Wie gehe ich jetzt am besten vor? Im UCS-LDAP ist er noch vorhanden.

Danke und viele Grüße,
SirTux

Die Namensauflösung klappt trotz Samba4-Backends übrigens noch.

Moin,

ich würd sagen: erst mal nachschauen, ob es Sync-Rejects gibt und diese auflösen, falls welche vorhanden sind.

Anschließend den Slave aus dem OpenLDAP löschen und einfach neu joinen. Vielleicht klappt auch ein Join ohne vorheriges Löschen.

Gruß,
mosu

Rejects gibt es nicht:

# univention-s4connector-list-rejected       

UCS rejected


S4 rejected


There may be no rejected DNs if the connector is in progress, to be
sure stop the connector before running this script.


        last synced USN: 7039

Ich hatte auch schon überlegt einen Resync aus dem UCS-LDAP anzustoßen mit

/usr/share/univention-s4-connector/resync_object_from_ucs.py --filter cn=sdc-name

Ist das eine sinnvolle Alternative?

Moin,

vielleicht :slight_smile: Wenn ich Probs in der Richtung habe, dann joine ich immer einfach neu. Ein Rejoin ist in dem Sinne ungefährlich und sollte slave-seitig nichts kaputt machen. Dauert halt nur einen Tick.

Gruß,
mosu

Anscheinend nicht:

(PROCESS): __sync_file_from_ucs: Object with entryUUID bjbjgdsgdjsgdsszensiert was already deleted. Don't re-create.

Vielen Dank für die moralische Unterstützung :slight_smile: Soweit scheint nach dem Join wieder alles zu funktionieren. Der Account ist jedenfalls wieder da.

Beim Join gabs noch einen Traceback:

Adding CNAME record "blabla._msdcs .top2.top1." to zone top2.top1...
Traceback (most recent call last):
  File "/usr/share/univention-directory-manager-tools/univention-dnsedit", line 400, in <module>
    main()
  File "/usr/share/univention-directory-manager-tools/univention-dnsedit", line 371, in main
    add_cname_record(*args)
  File "/usr/share/univention-directory-manager-tools/univention-dnsedit", line 296, in add_cname_record
    record.create()
  File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 295, in create
    return self._create()
  File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 730, in _create
    self._ldap_post_create()
  File "/usr/lib/pymodules/python2.7/univention/admin/handlers/dns/alias.py", line 132, in _ldap_post_create
    self._updateZone()
  File "/usr/lib/pymodules/python2.7/univention/admin/handlers/dns/alias.py", line 113, in _updateZone
    self.superordinate.modify()
  File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 307, in modify
    return self._modify(modify_childs,ignore_license=ignore_license)
  File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 775, in _modify
    self.lo.modify(self.dn, ml, ignore_license=ignore_license)
  File "/usr/lib/pymodules/python2.7/univention/admin/uldap.py", line 399, in modify
    raise univention.admin.uexceptions.ldapError(_err2str(msg), original_exception=msg)

Ich hoffe sonst gibt es keine weiteren Probleme mehr. Aber das wird die Zeit zeigen müssen.

Der neue Samba 4-Account scheint übrigens nicht mit dem UCS-LDAP syncronisiert zu sein, die Beschreibung ist z.B. im Samba 4 nicht gesetzt. Kann es zu einem Reject kommen, wenn ich den Account über die UMC ändere?

Moin,

ich würde zuerst jetzt nachschauen, ob es nicht schon wieder Konflikte gibt. Wenn ja, beheben. Wenn nein, einfach testen und die Beschreibung in der UDM ändern. Dabei die Logdatei »/var/log/univention/connector-s4.log« im Auge behalten und anschließend verifizieren, ob es nun neue Konflikte gibt.

Gruß,
mosu

Derzeit gibt es keine. Ich hatte gehofft man könnte vorab erkennenob es welche geben wird (z.B. andere ID oder was auch immer sonst zu einen Konflikt führen könnte). Aber dann werde ich es nächste Woche einfach mal ausprobieren. Diese Woche ist leider ungünstig.

Mir ist kein Weg bekannt, so etwas im Vorfeld wissen zu können. Ich habe Konflikte der verschiedensten Arten gesehen: z.B. dachte die eine Seite, das Objekt wäre schon gelöscht (das ist ja auch hier in Ihrem Fall so gewesen); oder die primäre Gruppe eines Users auf der Linux-Seite gibt’s auf der Windows-Seite nicht, und und und.

Hallo,

wie ich gesehen habe, gibt es auf dem anderen DC Slave seitdem ein failed.ldif. Die Fehlermeldung aus der tmp-Datei:

# Error: No such object (32), matched DN: cn=owncloud82,cn=apps,cn=univention,dc=top2,dc=top1
dn: univentionAppID=owncloud82_8.2.5,cn=owncloud82,cn=apps,c
 n=univention,dc=top2,dc=top1
changetype: delete

Hier hilft wahrscheinlich auch nur ein Rejoin oder? Das Objekt existiert übrigens im LDAP.

EDIT: Ich habe die Fehlermeldung falsch verstanden. Der Auszug aus der failed.ldif:

dn: univentionAppID=owncloud82_8.2.5,cn=owncloud82,cn=apps,c
 n=univention,dc=top2,dc=top1
changetype: delete

Laut SDB kann ich den Eintrag ja einfach löschen, was ich jetzt einfach mal getan habe. Die restlichen Einträge machten keine Probleme. Sie betrafen den Host-Account des Slaves mit dem ursprünglichen Problem.

[quote=“Moritz Bunkus”]Moin,

ich würde zuerst jetzt nachschauen, ob es nicht schon wieder Konflikte gibt. Wenn ja, beheben. Wenn nein, einfach testen und die Beschreibung in der UDM ändern. Dabei die Logdatei »/var/log/univention/connector-s4.log« im Auge behalten und anschließend verifizieren, ob es nun neue Konflikte gibt.

Gruß,
mosu[/quote]

Also ich habs jetzt mal ausprobiert: Einen Reject gibt es nicht. Vielmehr ist das Verhalten zum dem vor dem Rejoin. Der Pringt das Samba 4-Objekt gar nicht mit dem LDAP-Objekt in Verbindung. Die Meldung ist die von oben.

EDIT: Die SID ist übrigens in OpenLDAP und Samba 4 gleich.

Die Ausgabe von univention-s4-search ist auf dem DC Slave selber deutlich ausführlicher. So fehlen z.B. auf dem Master u.a. Einträge vom Typ servicePrincipalName.

Hallo,

ich habe noch überlegt wieso das Objekt überhaupt verschwinden konnte. Damals bin ich nicht auf die Idee gekommen in das Log des Connectors zu gucken:

13.07.2016 01:03:06,755 LDAP        (PROCESS): sync from ucs: [            dc] [    delete] CN=DELETED-SDC,ou=domain controllers,DC=top2,DC=top1
13.07.2016 01:03:09,716 LDAP        (PROCESS): __sync_file_from_ucs: Object with entryUUID 8dc5288e-b040-1032-940e-599332068d2d was already deleted. Don't re-create.
13.07.2016 01:03:10,745 LDAP        (WARNING): lastKnownParent attribute for deleted object rdn="CN=RID Set" was not set, so we must ignore the object
13.07.2016 01:03:10,747 LDAP        (PROCESS): sync to ucs:   [            dc] [    delete] cn=deleted-sdc,cn=dc,cn=computers,dc=top2,dc=top1
13.07.2016 01:03:10,747 LDAP        (PROCESS): Delete of cn=deleted-sdc,cn=dc,cn=computers,dc=top2,dc=top1 was disabled in mapping

Vielleicht kann ja jemand was damit anfangen.

Kann es helfen den Connector-Satatus zurückzusetzen, um wieder zu einem konsistenten Zustand zu kommen?

Moin,

ich habe nicht so richtig eine Idee, was bei Ihnen wirklich alles kaputt ist. Eine Reinitialisierung kann vielleicht helfen, aber das sollten Sie nur in einem konsistenten Zustand machen, denke ich. Also den Slave-DC noch einmal manuell entfernen, nach Resten von ihm im LDAP und S4 suchen, anschließend joinen, dann den Connector reinitialisieren.

Gruß,
mosu

Hallo,

danke, das habe ich auch schon überlegt. Wenn niemand sonst eine andere Idee hat, dann werde ich das wohl mal die Tage probieren.

Viele Grüße,
SirTux

Errata 224 scheint ja die Faktenlage zu ändern. Wie gehe ich unter diesem neuen Gesichtspunkt am besten vor?

Mastodon