#4015 closed Defekt (erledigt)
NC: Einige Nutzer haben UID als internen Nutzernamen
| Reported by: | Rüdiger Kupper | Owned by: | Rüdiger Kupper |
|---|---|---|---|
| Priority: | schnell erledigen | Milestone: | Nextcloud: Optimierungen |
| Component: | Webdienst: Kepler-Cloud | Severity: | beeinträchtigt den Unterricht einiger Lehrer |
| Keywords: | Cc: | bau |
Description
Siehe sudo -u www-data php /var/www/nextcloud/occ user:list.
Eigentich ist NC so konfiguriert, dass es das LDAP-Attribut $uid als internen Nutzernamen verwendet. Das klappt offenbar bei einigen Nutzern nicht. Der interne Nutzername muss aber mit dem LML-Nutzernamen übereinstimmen, damit die Nutzer sich am Fileserver anmelden können.
Change History (10)
comment:1 by , 5 years ago
comment:2 by , 5 years ago
Ich denke mal, dass im LDAP die UID stimmt - oder?
LDAP für benzdiana: createTimestamp 20131026102303Z creatorsName cn=admin,dc=kg-fds,dc=de dn uid=benzdiana,ou=accounts,dc=kg-fds,dc=de entrycsn 20210818170258.462017Z#000000#000#000000 entryDN uid=benzdiana,ou=accounts,dc=kg-fds,dc=de entryUUID 5726b4d6-d274-1032-9d12-d91d5fdf7c7a hasSubordinates FALSE modifiersName cn=admin,dc=kg-fds,dc=de modifyTimestamp 20210818170258Z structuralObjectClass inetOrgPerson subschemaSubentry cn=Subschema cn Diana Benz description Diana Benz displayName Diana Benz E-Mail benzdiana@kg-fds.de gecos Diana Benz gidNumber 10052 givenName Diana homeDirectory /home/attic/benzdiana loginShell /bin/bash objectClass inetOrgPerson posixAccount shadowAccount top sambaSamAccount sophomorixData Passwort •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• sambaAcctFlags [UX] sambaHomeDrive H: sambaHomePath \\paedml\benzdiana sambaKickoffTime 2147483647 sambaLMPassword •••••••••••••••••••••••••••••••• sambaLogoffTime 2147483647 sambaLogonTime 0 sambaNTPassword •••••••••••••••••••••••••••••••• sambaPrimaryGroupSID S-1-5-21-3878879208-3767656771-1509607135-21105 sambaPwdCanChange 0 sambaPwdLastSet 1346320647 sambaPwdMustChange 2147483647 sambaSID S-1-5-21-3878879208-3767656771-1509607135-26306 sn Benz sophomorixstatus T uidNumber 12653 User Name benzdiana
LDAP für Zhu Kailin createTimestamp 20140915081921Z creatorsName cn=admin,dc=kg-fds,dc=de dn uid=zhukailin,ou=accounts,dc=kg-fds,dc=de entrycsn 20210818162529.326009Z#000000#000#000000 entryDN uid=zhukailin,ou=accounts,dc=kg-fds,dc=de entryUUID bd7fdaaa-d0fc-1033-8b35-776a170b54e0 hasSubordinates FALSE modifiersName cn=admin,dc=kg-fds,dc=de modifyTimestamp 20210818162529Z structuralObjectClass inetOrgPerson subschemaSubentry cn=Subschema cn Kailin Zhu description Kailin Zhu displayName Kailin Zhu E-Mail zhukailin@kg-fds.de gecos Kailin Zhu gidNumber 10320 givenName Kailin homeDirectory /home/students/13e/zhukailin loginShell /bin/bash objectClass inetOrgPerson posixAccount shadowAccount top sambaSamAccount sophomorixData Passwort •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• sambaAcctFlags [UX] sambaHomeDrive H: sambaHomePath \\paedml\zhukailin sambaKickoffTime 2147483647 sambaLMPassword •••••••••••••••••••••••••••••••• sambaLogoffTime 2147483647 sambaLogonTime 0 sambaNTPassword •••••••••••••••••••••••••••••••• sambaPrimaryGroupSID S-1-5-21-3878879208-3767656771-1509607135-21641 sambaPwdCanChange 0 sambaPwdLastSet 1410768840 sambaPwdMustChange 2147483647 sambaSID S-1-5-21-3878879208-3767656771-1509607135-27958 sn Zhu sophomorixstatus U uidNumber 13479 User zhukailin
Ich sehe keine eklatanten Unterschiede.
Man könnte mal in der Maria-Datenbank nachsehen, wo NextCloud das fälschlicherweise einträgt.
Die komische UID erzeugt der wohl selbst oder?
Die könnte man natürlich per einfachem SQL-Befehl korrigieren lassen.
comment:3 by , 5 years ago
Die Nummer kommt aus dem LDAP-Feld "entryUUID". Aber NC soll eigentlich das Feld "uuid" verwenden. Komisch, dass das bei manchen nicht funktioniert.
comment:4 by , 5 years ago
Ich kann mir eigentich nur vorstellen, dass im Moment des Account-Anlegens irgend etwas bei der LDAP-Abfrage fehlschlägt, so dass das Feld "uid" nicht gelesen werden kann. Die UUID bekommt der Empfänger wahrscheinlich immer, die ist nämlich ein "virtuelles Attribut" und wird vom LDAP-Server berechnet. Falls also die LDAP-Abfrage irgendwie fehlschlägt könnte es schon sein, dass zwar die UUID, aber nicht das (echte) Feld "uid" ankommt. Und dann nimmt NC natürlich die UUID als Benutzernamen.
So irgendwie vermute ich. Vielleicht ist das Ganze ein Nebeneffekt der hohen Last?
Ich setze jetzt erst mall alle Accounts mit UUID-Namen zurück.
comment:5 by , 5 years ago
Da ist ohnehin etwas faul, denn Nextcloud behauptet, es kennt 501 Nutzer:
root@cloud:~# sudo -u www-data php /var/www/nextcloud/occ user:list|wc
501 1896 21164
Und da sind wie gesagt auch noch die Exam- und Maschinen-Accounts dabei. Das sind doch viel zu wenige, oder? Wie viele Schüler und Lehrer haben wir denn?
(Und die Abfrage oben hat beim ersten Mal etwa zwanzig Sekunden gedauert, das kommt mir auch sehr lange vor für eine einfache LDAP-Suche?!)
comment:6 by , 5 years ago
Wenn ich vom cloud-Rechner aus auf der Kommadozeile die selbe Abfrage mache, die Nextcloud machen sollte, dann geht das gefühlt instantan:
ldapsearch -w ***password-removed*** -D cn=admin,dc=kg-fds,dc=de -b ou=accounts,dc=kg-fds,dc=de "(|(objectclass=inetOrgPerson))" Und ich bekomme dort 1569 Nutzer geliefert: dapsearch -w ***password-removed*** -D cn=admin,dc=kg-fds,dc=de -b ou=accounts,dc=kg-fds,dc=de "(|(objectclass=inetOrgPerson))"|grep "dn:"|wc 1569 3138 72897
Also hat NC irgendwelche Probleme, mit dem LDAP-Server zu kommunizieren(?)
comment:7 by , 5 years ago
Wieder etwas gelernt: Die Einträge mit den UUIDs stammen vermutlich aus der Phase, als der LDAP-Zugriff noch nicht richtig konfiguriert war. NC hat die Einträge gespeichert und versuchte, sie mit dem selben Nutzernamen wiederherzustellen.
NC ist ein Datensammler: alles, was es einmal in die Finger bekommen hat, landet in der Datenbank und wird weiter benutzt. Das ist bei einem System wie dem unseren, bei dem wir noch herumprobieren, gar nicht so praktisch. Wahrscheinlich sollten wir die Datenbank einmal komplett löschen und neu anlegen lassen, bevor wir in den Produktivbetrieb gehen.
comment:8 by , 5 years ago
| Resolution: | → erledigt |
|---|---|
| Status: | new → closed |
Die Accints mit UUID-Einträgen ließen sich zurücksetzen (ohne dass ein Verzeichnis unter /var/www/nextcloud/data angelegt worden war). Danach lieferte eine Anfrage per occ user:list nur noch korrekte Usernamen und keine UUIDs mehr.
comment:9 by , 5 years ago
Ich habe nun vorerst die Nutzerliste eingeschränkt. Einerseits sind wir uns über die Konfiguration noch nicht sicher und andererseits möchte ich nicht, dass sich Schüler zu dieser Zeit schon einloggen.
Der LDAP-Filter ist nun so eingestellt, dass nur die folgenden LDAP-Nutzer sich einloggen können: kup, bau, lehrer, schuelte. Und natürlich der lokale User akup.
Alle anderen Nutzeraccounts werden gerade gelöscht.
comment:10 by , 5 years ago
Vor der Einschränkung sah die Abfrage so aus:
root@cloud:~# sudo -u www-data php /var/www/nextcloud/occ user:report +----------------+------+ | User Report | | +----------------+------+ | Database | 1 | | LDAP | 1272 | | | | | total users | 1273 | | | | | disabled users | 0 | +----------------+------+
1272 Datensätze für Schüler und Lehrer (auch die im attic) scheinen mir plausibel.
Nach der Einschränkung sieht es jetzt so aus:
root@cloud:~# sudo -u www-data php /var/www/nextcloud/occ user:report +------------------+---+ | User Report | | +------------------+---+ | Database | 1 | | LDAP | 4 | | | | | total users | 5 | | | | | user directories | 1 | | disabled users | 0 | +------------------+---+
Und die Nutzerliste, die Nextcloud kennt, ist nun überschaubar:
root@cloud:~# sudo -u www-data php /var/www/nextcloud/occ user:list - akup: Rüdiger Kupper (Admin) - bau: Jens Baumgaertner - kup: Ruediger DrKupper - lehrer: Test Lehrer - schuelte: Test Schueler
Ein paar Beispiele:
Das problem scheint überwiegend Schüler zu betreffen, die Lehrernamen sehen richtig aus.
Wie man sieht gibt es aber durchaus auch Schüler, die den richtigen internen Namen haben.