Nutzerdatenbank irgendwie korrupt?

Nur LDAP. (incl. 2FA mit den Plugins Two-Factor Authentication via Nextcloud notification und Two-Factor TOTP Provider)

So, ich grenze weiter ein:
Wenn man die Tabelle oc_activity nach Timestamp sortiert und sich nur von einem Nutzer die Datensätze anzeigen lässt, dann sieht man, was passiert:

❯ SELECT activity_id,timestamp,type,affecteduser,app,subject,subjectparams FROM `oc_activity` where affecteduser="tester" ORDER BY timestamp DESC ;
+-------------+------------+----------------+------------------+----------+---------------+-----------------------------------------------------+
| activity_id | timestamp  | type           | affecteduser     | app      | subject       | subjectparams                                       |
+-------------+------------+----------------+------------------+----------+---------------+-----------------------------------------------------+
|     2177015 | 1689079610 | group_settings | tester           | settings | group_added   | {"user":"tester          ","group":"p_wilma"}       |
|     2177014 | 1689079610 | group_settings | tester           | settings | group_removed | {"user":"tester","group":"p_wilma"}                 |
|     2177013 | 1689079606 | group_settings | tester           | settings | group_added   | {"user":"tester          ","group":"teachers"}      |
|     2177012 | 1689079606 | group_settings | tester           | settings | group_removed | {"user":"tester","group":"teachers"}                |
|     2177011 | 1689079605 | group_settings | tester           | settings | group_added   | {"user":"tester          ","group":"p_sekretariat"} |
|     2177010 | 1689079605 | group_settings | tester           | settings | group_removed | {"user":"tester","group":"p_sekretariat"}           |
|     2177009 | 1689079602 | group_settings | tester           | settings | group_added   | {"user":"tester          ","group":"p_support"}     |
|     2177008 | 1689079601 | group_settings | tester           | settings | group_removed | {"user":"tester","group":"p_support"}               |
+-------------+------------+----------------+------------------+----------+---------------+-----------------------------------------------------+

Definitiv wird der Nutzer aus der Gruppe geschmissen, weil der Nutzer, der zum Vergleich hergenommen wird, Leerzeichen hinter dem relevanten Teil hat.
Ich habe noch keine LDAP-Abfrage gefunden, die solche Nutzerdaten zurückliefert. Es ist sehr wahrscheinlich, dass das in der Nextcloud irgendwo passiert.

Die Frage ist, warum hat das außer mir keiner gemerkt? Ist es ein unglückliches Zusammenspiel von Plugins?

Meine zur Zeit aktivierten Apps:

... aufklappen
❯ claudiocc app:list
Enabled:
  - activity: 2.18.0
  - admin_audit: 1.16.0
  - announcementcenter: 6.6.1
  - audioplayer: 3.4.0
  - bbb: 2.4.0
  - bookmarks: 13.0.1
  - bruteforcesettings: 2.6.0
  - calendar: 4.4.3
  - cloud_federation_api: 1.9.0
  - comments: 1.16.0
  - contacts: 5.3.2
  - contactsinteraction: 1.7.0
  - dashboard: 7.6.0
  - dav: 1.25.0
  - deck: 1.9.2
  - event_update_notification: 2.2.0
  - external: 5.1.0
  - externalpassword: 1.1.0
  - federatedfilesharing: 1.16.0
  - files: 1.21.1
  - files_accesscontrol: 1.16.0
  - files_automatedtagging: 1.16.1
  - files_external: 1.18.0
  - files_fulltextsearch: 26.0.0
  - files_pdfviewer: 2.7.0
  - files_rightclick: 1.5.0
  - files_sharing: 1.18.0
  - files_trashbin: 1.16.0
  - files_versions: 1.19.1
  - firstrunwizard: 2.15.0
  - fulltextsearch: 26.0.0
  - fulltextsearch_elasticsearch: 26.0.0
  - groupfolders: 14.0.2
  - integration_zammad: 2.0.6
  - logreader: 2.11.0
  - lookup_server_connector: 1.14.0
  - mail: 3.2.3
  - nextcloud_announcements: 1.15.0
  - notes: 4.8.0
  - notifications: 2.14.0
  - oauth2: 1.14.0
  - onlyoffice: 7.8.0
  - password_policy: 1.16.0
  - passwords: 2023.7.30
  - photos: 2.2.0
  - provisioning_api: 1.16.0
  - quota_warning: 1.17.0
  - recommendations: 1.5.0
  - serverinfo: 1.16.0
  - settings: 1.8.0
  - snappymail: 2.28.4
  - spreed: 16.0.4
  - support: 1.9.0
  - suspicious_login: 4.4.0
  - systemtags: 1.16.0
  - tasks: 0.15.0
  - text: 3.7.2
  - theming: 2.1.1
  - theming_customcss: 1.14.0
  - twofactor_backupcodes: 1.15.0
  - twofactor_nextcloud_notification: 3.7.0
  - twofactor_totp: 8.0.0
  - updatenotification: 1.16.0
  - user_ldap: 1.16.0
  - user_usage_report: 1.10.0
  - viewer: 1.10.0
  - workflowengine: 2.8.0

Das ist echt strange…
LG Jesko

Hallo Jesko,

Definitiv wird der Nutzer aus der Gruppe geschmissen, weil der Nutzer,
der zum Vergleich hergenommen wird, Leerzeichen hinter dem relevanten
Teil hat.
Ich habe noch keine LDAP-Abfrage gefunden, die solche Nutzerdaten
zurückliefert. Es ist sehr wahrscheinlich, dass das in der Nextcloud
irgendwo passiert.

Die Frage ist, warum hat das außer mir keiner gemerkt?

… mein „best guess“ … keiner hat seine NC so aktuell wie du … schau
mal nach, ob es ein update gibt … die haben das vielleicht gemerkt und
es gibt einen Fix?
Ich drück die Daumen …

… ich mach erstmal kein Update :slight_smile:

LG

Holger

26.0.3 hab ich auch. daran liegts eher net…
php vielleicht?

27.0.0 wollt ich aber abwarten bis mal die Noten und Dach und Fach sind

wenn ich auf meiner nc26.0.3 oc_activity anschaue haben die Kids da auch Dreibuchstaben (unsere Lehrerkürzel) gefolgt von Leerzeichen. die und so sieht so aus, hat eine vorgegebene stringlänge was mich jetzt nicht wirklich beunruhigt.

ich hab aus deiner ldap config mal den ldapgruppen filter in den ldapanalyzer eingegeben https://piellardj.github.io/ldap-filter-analyzer/
und der mag da gar nicht wie du da die klammern gesetzt hast. ich glaube bei einem der & schliesst die klammer nicht an der rechten stelle.
am besten einfach mal selber prüfen….

ich könnte mir vorstellen dass aus den usern Attributen die Leute in die Gruppen eingeschrieben werden, wenn aber die gruppensynchroniserung läuft alles wieder rausgeworfen wird… aber wie genau technisch das netcloud das macht weiss ich auch nicht ist aber mal ne Idee :slight_smile:

so wears wahrscheinlich korrekt:

(&(objectclass=group)(|(cn=teachers)(cn=0*)(cn=1*)(cn=p_)(cn=sozial)(cn=testklasse)(cn=hausm*)))

Aber wenn i h nochmal drueber nachdenke kannd as auch nicht wirklich das problem sein… Das ist scchond as problem mit den leerzeichen.

Ich wuerde doch mal probieren die
Expertuuidgroup auf nix setzen und expertuuiduser auch auf nix.
Aber experusertname auf samaccountname
Sowie es bei.mir ist. Ich sehe keinen vorteil darin die uuids zu erzwingen auf ein kurzes kuerzel…

Dann gibts zwar kryptische uuids aber vielleicht braucht die nextcloud halt…
Das entscheidende ist ja das expertusername gesetzt wird

Vielleicht kommen sich da die beiden overrides irgendwie in die quere…

Danke!!
Da war tatsächlich früher mal was drin, aber jetzt nur noch ein Argument für das erste oder.
Ist korrigiert nach


(&(objectclass=group)(|(cn=teachers)(cn=0*)(cn=1*)(cn=p_*)(cn=sozial*)(cn=testklasse)(cn=hausm*)))

Man weiss ja nie, aber ich glaub dass das nicjt zum Problem gehört.

Das würde ich nur sehr ungern haben wollen.
Da fie Cloud jetzt seit 3,5 Jahren ohne zu mucken lief, kann ich mir auch nicht vorstellen dass die das braucht :slight_smile:

Nichts zur Problemlösung, aber ACHTUNG HIER!!!

mit der Version 27 kann man im Moment Groupfolders nicht gleichzeitig mit Volltextsuche verwenden. Das resultiert in einem „internal Error“ und nichts geht mehr.
Siehe groupfolders and fulltextsearch cannot coexist on 27.0.0 · Issue #2428 · nextcloud/groupfolders · GitHub

Also entweder auf die geniale Volltextsuche verzichten (geht für mich nicht) oder Groupfolders nicht benutzen (geht für mich nicht) oder Version 27 noch nicht benutzen (das ist das einzige, was für mich gerade machbar scheint.)
Da in der neuesten fulltextsearch das Problem behoben scheint, kann es also sein, dass nächste Woche mit der 27.0.1 das auch funktioniert. (siehe Maintenance and Release Schedule · nextcloud/server Wiki · GitHub)

In der Testinstanz werde ich mal updaten, um zu sehen, ob das andere Problem damit weg ist…

Hi zusammen,

ich bin jetzt vorsichtig optimistisch. Seit 26h hab ich keine blöden Benachrichtigungen mehr erhalten.
Was hab ich gemacht? Beim Stochern im Nebel hab ich plötzlich die Eingebung gehabt, dass ich den Redis-Cache vielleicht mal löschen sollte.
Und das hab ich dann mit

             ~$ redis-cli
127.0.0.1:6379> FLUSHALL

auch gemacht.
seither ist Ruhe.
Jetzt bin ich noch etwas angespannt, weil ich ja schon vorher auch längere Abstände zwischen den Grauen hatte. Aber das fühlt sich doch jetzt schon so an, als ob das ein guter move war.

Ich werd mich melden, wenn die Ruhe stabil bleibt… und sonst auch…
LG Jesko

1 „Gefällt mir“

… Nachtrag: Bei occ user:list sind jetzt auch wieder alle Nutzer (incl. meinem eigenen, der sicher gefehlt hat die letzten Wochen) aufgelistet.
Das war also sicher kein Fehler, den Cache zu löschen.

…ich sage mal aus anderem Grund DANKE! Durch deinen Hinweis ist mir erst aufgefallen, dass mein Redis nicht mehr läuft!? …das muss beim Upgrade auf 27.0.0 passiert sein…und ich wundere mich die ganze Zeit über die unterirdische Performance…

LG
Dominik

2 „Gefällt mir“

Hallo Dominik,

aber Redis ist doch keine Funktion von NC, sondern wird nur von ihr genutzt.

Ich sehr den Zusammenhang mit dem NC Update nicht.

Am Rande: Nutzt ihr die BBB-App in NC? Funktioniert die in NC 27 noch? Wird ja schon bei NC 26 als inkompatibel gemeldet, funktioniert aber.

Viele Grüße
Steffen

Hi,

der gesamte Redis Block war in der config.php kommentiert. Habe gerade in einem Backup der 26.0.4 nachgesehen, da war das noch nicht so…ich habe nichts an der Konfiguration gemacht, also bleibt eigentlich nur noch das Upgrade auf 27…warum…?

Ja nutzen wir und ja funktioniert noch.

VG
Dominik

1 „Gefällt mir“

:sunglasses:

mein vorsichtiger Optimismus ist in den letzten 41 Stunden zu einer ausgewachsenen Gewissheit gewachsen, so dass ich jetzt zusammenfassend sagen kann: Der Redis-Cache war korrupt. Seit dem restlosen Leeren desselben ist ein Problem sicher beseitigt (das mit den fehlenden Nutzern in occ user:list) und das Ausgangsproblem der massenhaften Neuzuweisungen von Gruppen ist nicht mehr aufgetreten.
Lösung war also:

~$ docker exec -it redis redis-cli
127.0.0.1:6379> AUTH [username] password
127.0.0.1:6379> FLUSHALL

:sunglasses: Danke fürs mitdenken und liebe Grüße
Jesko

1 „Gefällt mir“

… und so werde ich, sobald ich alles aufgearbeitet habe, was durch den Mist jetzt liegen geblieben ist, der LDAP-Mirror-Geschichte eine neue Chance geben :slight_smile:

hab heute mal nc27.0.1 probiert mit fulltext elastic search

und groupfolders → internal server error

also nochmal bissle warten ist da angesagt…

1 „Gefällt mir“

Das Problem hatte ich auch - bei mir hat da ein
sudo -u www-data php occ app:disable files_fulltextsearch
geholfen. (leider dann keine Volltextsuche mit elasticsearch mehr…)

seit heute gibts neue apps fuer fulltextsearch.

habe gerade erfolgreich ein update auf nextcloud 27.0.1 gemacht mit aktiviertem groupfolder und fulltextsearch und der gefürchtete internal server error blieb aus.

1 „Gefällt mir“