Nach der ansonsten erfolgreichen Migration von lmn6.2 nach lmn7 hab ich in der Nextcloud (LDAP-Anmeldung) ein seltsames Phänomen:
Bei (ungefähr) der Hälfte der User sind die Dateien „weg“.
Nähere Untersuchung zeigt: die Daten sind noch da, aber unter einem anderen Nutzernamen.
Beispiel:
Nutzer „ge“: kann sich anmelden, sieht seine Daten nicht.
Auf dem Server gibt es das Verzeichnis ge mit allen seinen Daten und ein neues Verzeichnis „ge_6453“ welches leer ist.
ge_6453 ist auch plötzlich der interne Nutzername des Users in der Nextcloud. Anmelden geht aber nach wie vor mit ge.
Mir stellen sich drei Fragen:
warum passiert das?
wenn es passiert, warum nur bei jedem zweiten Account?
Hi Jesko,
im LDAP-Modul der Nextcloud kannst Du unter „Experte“ die LDAP-Benutzernamenzuordnung (auch die Gruppen) löschen, dann stimmt das wieder. Backup vorher ist natürlich sinnvoll
LG
Max
das Löschen der Homeverzeichnisse hat keine Besserung gebracht.
Ich denke, dass in der Datenbank die alten User von der lmn6 mit irgendeiner UUID gespeichert und damit für neue User geblockt sind.
Jetzt habe ich das auf die Holzhammer-Methode gemacht und stelle bisher keine Probleme fest, die darüber hinaus gehen, dass alle Freigaben weg sind (was erträglich ist. muss man halt neu machen.
Wie hab ich das gemacht?
→ ich habe in der Datenbank-Tabelle oc_ldap_user_mapping einfach das Feld „owncloud_name“ auf den selben Wert gesetzt wie „directory_uuid“
Ehrlich gesagt habe ich nicht damit gerechnet, dass das (augenscheinlich) noch funktioniert hinterher… aber wie gesagt… bislang keine Probleme.
Die Sache mit den Freigaben hat mir gezeigt, dass institutionelle Tauschordner besser mit Gruppenordnern realisiert werden sollen. Bei denen konnte ich einfach die neue Gruppe zuordnen und alles ist wieder gut.
das Phänomen tritt leider nicht nur bei der Migration von V6 auf V7 auf, sondern (bei uns zumindest) auch beim normalen Schuljahreswechsel innerhalb der V7.
Und es bringt leider weitere Probleme mit sich - s.u.
Wir vermuten, dass (in unserem Fall) die Nextcloud die Versetzung der SuS in die neue Klasse nicht „mitmacht“.
Nach dem sophomorix-update mit der neuen schueler.csv (Und einer gewissen Wartezeit wegen ldapUserCleanupInterval) zeigte dann sudo -u www-data php occ ldap:show-remnants hunderte nicht mehr existente Useraccounts an.
Der musterma aus der letztjährigen 8b ist für Nextcloud offensichtlich nicht der musterma aus der diesjährigen 9b. Folgerichtig vergibt die Nextcloud dem neuen ldap-user einen anderen „internen Benutzernamen“. So steht das auch im Bereich „Experte“ der LDAP/AD-Einstellungen: „Bei Kollisionen wird eine Nummer hinzugefügt/erhöht.“
Das ist unschön, wäre mir aber egal, wenn es da nicht einen echten Fehler gegeben hätte :
Wir haben beobachtet: Wenn ein LDAP-Benutzer, den es „nicht mehr gibt“ (also die versetzten SuS oder die Abgänger), eine Datei z.B. mit mir geteilt hat, bekomme ich (!) das Verzeichnis nicht mehr angezeigt und eine Fehlermeldung. Blöd, wenn die geteilte Datei im Hauptverzeichnis der Nextcloud liegt.
Wir wussten auf die Schnelle nichts anderes, als alle alten Benutzer (remnants) in der Nextcloud zu löschen (mit occ user:delete)… Nun sind halt auch die Dateien, welche außerhalb von (dem als externen Speicher eingebundenen) Home_auf_Server liegen, futsch. Alle Freigaben, Kalender, Deck-Karten etc. sind damit natürlich auch weg.
So wie’s aussieht sind wir trotzdem die musterma_4567-Benutzernamen nicht losgeworden…
Die ganze Benutzernamenzuordnung zu löschen, wie @maxEG vorschlägt, würde ich nicht machen, damit wären auch die Zuordnungen der LuL gelöscht… Das kann m.E. auch insgesamt nicht gut gehen…
Ich bin (für nächstes Jahr) gespannt, ob @Jesko s Methode den Fehler verhindert. Aber ehrlich - ich bin skeptisch ob Holzhammer-Methode nebenwirkungsfrei funktioniert…
Ich befürchte z.B. Fehler, wenn ein:e S:in letztes Jahr eine Datei mit ihrer Klasse geteilt hat - und jetzt gar nicht mehr zu der Klasse gehört…
Kriegt man irgendwie die SuS zuverlässig mit ihrem Account ins nächste Schuljahr?
Hat da irgendjemand eine best practice???
Da das ja mit der Benutzerverwaltung der lmn6.2 wie geschnitten brot lief, würde ich hier mal @jeffbeck einschalten wollen. @jeffbeck was meinst du, woran liegt das? Bug oder Feature? Wenn Feature, wie kann man ohne das Feature zu verlieren die Nextcloudanbindung wieder sinnvoll hinbekommen? Weil so ist das leider ein Showstopper aus meiner Sicht.
Und ich würde wirklich sehr sehr ungern wieder in das csv-hochlade-Zeitalter zurückfallen…
LG Jesko
auch ich bin auf das „Nummern anhängen Problem“ letztes Wochenende gestoßen.
… man kann … wenn man will … die Zuordnung wieder geradeziehen in der Datenbank …muss man halt ein script schreiben (ich kann das nciht).
Was in der Datenbank angepaßt werden muss steht hier:
Ok, danke!
Ich habe das Phänomen zum Glück nur bei wenigen Schülern, es sind die, die wohl gerade in „attic“ liegen. Jetzt ist die Frage, warum das bei mir anders ist?
Hattet ihr das nach der Migration oder nach dem Versetzen ins neue Schuljahr?
LG
Max
Hallo!
Vermutung: Das Phänomen tritt auf, sobald ein Nutzer mal bei „attic“ war.
Mir ist das mit zwei Klassen passiert, die wurden beim aSV-Export vergessen, waren kurz in attic und haben jetzt alle eine Nummer…
LG
Max
Hej,
bei mir war’s ein reines Versetzen. Kann es nicht sein, dass das daran liegt, dass die user nach Versetzung / Migration an einer anderen Stelle im AD-Baum auftauchen (OU=9a statt OU=8a)?
Das würde auch erklären, warum die LuL (und die Sitzenbleiber) bei uns nicht betroffen waren.
Holgers erster Links bestätigt ja Jeskos Vorgehen…
Ich bin trotzdem skeptisch, ob man sich damit nicht doch die DB zerschießt. Immerhin ist owncloud_name ja Primärschlüssel in oc_ldap_user_mapping. Nicht dass das irgendwo als Fremdschlüssel auftaucht…
MariaDB [nextcloud_db]> show fields from oc_ldap_user_mapping;
+----------------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------------+--------------+------+-----+---------+-------+
| ldap_dn | varchar(255) | NO | UNI | | |
| owncloud_name | varchar(255) | NO | PRI | | |
| directory_uuid | varchar(255) | NO | | | |
+----------------+--------------+------+-----+---------+-------+
@Jesko Wie bist Du denn vorgegangen um die Einträge zu ersetzen? Über SQL-Befehle? Weiß jemand: Erkennt SQL entstehende Inkonsistenzen?
Ja, das weiß ich halt auch nicht. Bisher hab ich nichts bemerkt, was blöd wäre, aber natürlich kann es sein, dass in verschiedenen Tabellen noch „Leichen“ rumliegen jetzt…
Ich hab das einfach mit einem UPDATE oc_ldap_user_mapping SET owncloud_name=directory_uuid; gemacht.
SQL führt hier einfach aus, was ich sage… da wird nichts geprüft. Inkonsistenzen werden nicht verhindert.
:
