Nach Upgrade auf LMN 7.3: Klassenarbeitsmodus ist nicht funktional

Server Schulkonsole
3

Hallo Arnaud,

vielen Dank für den Tipp mit dem Dev-Mode. Nachdem ich mir die Ausgaben angeschaut habe, war relativ schnell klar, dass es nicht an der Webui liegt, wie Du ja auch schon vermutet hast.
Also ging die Suche weiter.

In den letzten Wochen habe ich mehrere Anläufe genommen, den Fehler zu finden und bin nun endlich der Ursache auf die Schliche gekommen.

Dazu muss ich aber ein wenig ausholen.

Problem

Erste Analyse der Ausgaben von

sophomorix-exam-mode -vvv --set --supervisor lehreruser --participants schueleruser

zeigten, dass kein neuer Benutzer schueleruser-exam angelegt werden konnten:

##################################################################################
# Creating examuser for user: schueleruser (start)                                    #
##################################################################################
...
ERROR in Sophomorix::SophomorixSambaAD::AD_examuser_create:
   0000202F: lib/ldb/ldb_key_value/ldb_kv_index.c:3065: Failed to re-index objectSid in CN=schueleruser-exam,OU=Examusers,OU=default-school,OU=SCHOOLS,DC=DOMAIN,DC=TLD - lib/ldb/ldb_key_value/ldb_kv_index.c:2910: unique index violation on objectSid in CN=schueleruser-exam,OU=Examusers,OU=default-school,OU=SCHOOLS,DC=DOMAIN,DC=TLD
...

Dieser Fehler tauchte beim Upgradevorgang bei der der Installation vom Paket linuxmuster-tools7 ebenfalls auf und zwar an der Stelle, wenn die Klassen auf die neuen Gruppen klassenname-parents und klassenname-students geprüft werden:

...
Checking students groups from schoolclass klassenname
{'msgtype': 105, 'msgid': 2, 'result': 19, 'desc': 'Constraint violation', 'ctrls': [], 'info': '0000202F: lib/ldb/ldb_key_value/ldb_kv_index.c:3065: Failed to re-index objectSid in CN=klassenname-parents,OU=klassenname,OU=Students,OU=default-school,OU=SCHOOLS,DC=DOMAIN,DC=TLD - lib/ldb/ldb_key_value/ldb_kv_index.c:2910: unique index violation on objectSid in CN=klassenname-parents,OU=klassenname,OU=Students,OU=default-school,OU=SCHOOLS,DC=DOMAIN,DC=TLD'}
...

Der gleiche Fehler tauchte bei uns auch schon einmal im September 2024 auf

und konnte damals nur durch das Zurückspielen eines Backups behoben werden.

Analyse

Komisch dabei war jedoch, dass wohl für einige der Klassen die neuen Gruppen angelegt werden konnten und ab irgendeiner Klasse eben nicht mehr.
Da ich mehrere Upgradeversuche mit unterschiedlichen Ausgangszuständen der LMN 7.2 unternommen habe, konnte ich die Constraint violation leider nicht auf eine bestimmte Klasse eingrenzen.

Bei der Recherche dieses Fehlers und dessen Ursache im Netz las ich immer wieder, dass die Constraint violation immer dann auftritt, wenn versucht wird, ein Objekt im AD mit einer objectSid anzulegen, die bereits an ein anderes Objekt im AD vergeben wurde. Da ich ein absoluter DAU bin, konnte ich mir darauf aber keinen Reim machen.

Wie um alles in der Welt kann ich herausfinden, welche objectSid des neu anzulegenden Objekts verwendet wird?

Dann stieß ich endlich auf ein Wiki, das nicht nur exakt das selbe Problem beschreibt, sondern auch die Lösung des Problems:
https://deepdoc.at/dokuwiki/doku.php?id=prebuilt_systems:ucs:failed_to_re-index_objectsid_sambadb

Jede objectSid (Object Security Identifier) ist wie folgt aufgebaut:

S-1-5-21-<DomainID>-<RID>

Die DomainID ist für alle objectSid gleich, die RID (Relative Identifier) ist eine fortlaufende Nummer. Mit dem Anlegen eines neuen AD-Objekts wird die RID jeweils um 1 inkrementiert. Somit wird sichergestellt, dass jede objectSid im AD eindeutig ist.
Damit das AD immer weiß, welche RID für das zuletzt im AD angelegte objectSid erfolgreich vergeben wurde, wird dieser Wert im RID Set des Domänen Controllers im Attribut rIDNextRID gespeichert und kann wie folgt abgefragt werden:

# ldbsearch -H /var/lib/samba/private/sam.ldb CN="RID Set" -b CN="SERVER,OU=Domain Controllers,DC=DOMAIN,DC=TLD" rIDNextRID
# record 1
dn: CN=RID Set,CN=SERVER,OU=Domain Controllers,DC=DOMAIN,DC=TLD
rIDNextRID: 15496
...

Bleibt nur noch zu überprüfen, ob die rIDNextRID mit der höchsten RID übereinstimmt, die an ein im AD existierenden Objekt vergeben wurde. Dazu lässt man sich alle objectSid im AD auflisten, filtert die RID heraus, sortiert diese numerisch nach der Größe und gibt nur die letzte RID aus:

# ldbsearch --cross-ncs -H /var/lib/samba/private/sam.ldb objectSid | grep objectSid | cut -d '-' -f8 | sort -n | tail -n 1
15496

Passt doch!
Aber warum kommt es dann trotzdem zu einer Constraint violation?

Um das zu verstehen, muss man folgendes wissen: Werden Objekte im AD gelöscht (z. B. beim Beenden einer Püfung in der Webui), werden diese nicht sofort restlos aus dem AD entfernt, sondern landen als sogenannte Tombstones im versteckten AD-Zweig „Gelöschte Objekte“. Durch Hinzufügen des Schalters --show-deleted in obigem ldbsearch-Kommando kann man sich zusätzlich die objectSid der gelöschten Objekte ausgeben lassen:

# ldbsearch --cross-ncs --show-deleted -H /var/lib/samba/private/sam.ldb objectSid | grep objectSid | cut -d '-' -f8 | sort -n | tail -n 1
15500

Hoppla! Offenbar gibt es in meinem Fall vier Objekte im AD, die eine größere RID haben als im Zähler rIDNextRID abgespeichert. Will man nun ein neues Objekt im AD anlegen, dann würde dieses die objectSid mit der RID 15497 bekommen. Weil im AD jedoch bereits ein Objekt mit genau dieser objectSid existiert, schlägt das Anlegen des neuen Objekts mit einer Constraint violation fehl.

Lösung

Um im AD wieder neue Objekte anlegen zu können, müssen wir die rIDNextRID im RID Set anpassen, und zwar auf die höchste im AD vorkommende RID, in diesem Fall auf die Nummer 15500. Dazu muss man das Attribut rIDNextRID im RID Set direkt in der Datei sam.ldb mittels ldbedit verändern (Editierung erfolgt mittels Editor vi).
Achtung: Mit ldbedit kann man sich unter Umständen das komplette AD zerschießen.
→ Vorher ein Backup der Datei /var/lib/samba/private/sam.ldb oder einen Snapshot erstellen. You have been warned!

  1. Samba-AD-DC Dienst stoppen:

    # systemctl stop samba-ad-dc.service

  2. RID Set editieren

    # ldbedit -H /var/lib/samba/private/sam.ldb CN="RID Set" -b CN="SERVER,OU=Domain Controllers,DC=DOMAIN,DC=TLD"

  3. Samba-AD-DC Dienst starten:

    # systemctl start samba-ad-dc.service

Et voilà! Das Anlegen von Prüfungen über die Webui ist wieder möglich.

Ursachenforschung

Bleibt noch die Frage zu klären, wie es überhaupt dazu kommen konnte, dass im AD Objekte existieren, die eine höhere RID haben, als im Attribut rIDNextRID des RID Set hinterlegt ist. Dazu ließ ich mir mit

# ldbsearch --cross-ncs --show-deleted -H /var/lib/samba/private/sam.ldb "(objectSid=$(net getdomainsid | cut -d ' ' -f6)-15497)" dn

den DN der kollidierenden Objekte ausgeben.

Diese Objekte stammten nachweislich von einem Upgrade-Versuch auf LMN 7.3, der in den Herbstferien stattfand. Neben dem AD als Primary-DC (server) läuft in unserem Netz noch ein zweiter Full DC (dc2). Aus irgendwelchen Gründen kam es wohl zu einem Replikationsfehler.

Eine mögliche Erklärung dafür ist, dass beim Zurückspielen eines Snapshots der server-VM versehentlich nicht berücksichtigt wurde, dass die dc2-VM auf gleichen Zeitpunkt zurückgesetzt werden muss. Dann nämlich repliziert dc2 seinen aktuelleren Stand Richtung server. Allerdings werden dabei nur die Objekte repliziert, die einen neueren Stand haben, als im Primary DC. Da das Attribut rIDNextRID des RID Set ausschließlich auf dem Primary DC existiert, wird der RID-Zähler mit dem Zurückspielen des Snapshots auf einen früheren Stand zurückgesetzt, der natürlich kleiner ist als die höchste im AD existierende RID.

Viele Grüße
Jürgen

4 „Gefällt mir“