Lösung/Workaround für Direktzugriffe auf den Filserver (verschwindende oder falsch angezeigte Dateien)

[Rüdiger Kupper]

Inzwischen verstehe ich besser, was die Ursache für die berüchtigten "verschwindenden Dateien" ist. Nextcloud ist generell völlig ignorant gegenüber Dateiänderungen, die nicht durch das NC-Interface selbst geschehen (Browser, WebDAV, App).
Ändert man Dateien "an NC vorbei" direkt auf dem Fileserver, so erfährt NC davon nichts. Bei uns passiert das aber ständig, weil die stationären Rechner direkt ans GlusterFS angebunden sind. Arbeitet man also vormittags an den Schulrechnern, so wundert man sich, dass die Änderungen nicht in NC erscheinen und auch nicht per Sync-Client synchronisiert werden. Das führt dann zu ärgerlichen Konflikten.

Generell ist das kein echter Fehler in NC, es wäre nur schön gewesen, wenn dieser Umstand irgendwo dokumentiert gewesen wäre.

Der "NC-konforme" Weg (sofern man nicht völlig auf die Direktanbindung des Filservers verzichten will) wäre, nach jeder Änderung an einer Datei auf dem Fileserver den Befehl "occ files:scan --path=…" für die betreffende Datei auszuführen. Dann wird NC auf den aktuellen Stand dieser Datei gebracht.

Leider sehe ich keinen geeigneten Mechanismus hierfür. Entweder müssten die Ubuntu-Rechner alle Dateiänderungen überwachen und an den NC-Server "melden", oder der Gluster-Server müsste das machen (was mir noch schwieriger scheint).

[Rüdiger Kupper]

Ich habe daher jetzt als "Workaround" zwei Cron-Jobs auf dem NC-Server erstellt. Der erste läuft jede Stunde und scannt für alle Lehrer-Accounts den kompletten Dateibaum unterhalb "Fileserver" neu. (Bei der derzeitigen Datenmenge dauert das 16 Minuten). Der zweite Cron-Job macht das selbe für die Schüler-Accounts und läuft einmal täglich.

Dasd ist natürlich völliger Overkill, denn es ändern sich ja höchstens ein paar Dateien, dennoch werden alle neu gescannt. Es arbeitet aber einstweilen um das Problem herum. Bearbeiten Kollegen Dateien an den Rechnern, dann weiß NC spätestens nach einer Stunde und 16 Minuten darüber Bescheid. Bei mir funktioniert das derzeit ganz gut.

[Rüdiger Kupper]

Ich frage mich, wie die aktuelle Linuxmusterlösung mit diesem Problem umgeht. Meines Wissens bindet die auch Teile des Homeverzeichnisses der Nutzer in NC ein. Haben die dafür eine elegantere Lösung gefunden, oder leidet das unter dem selben Problem?

[bau]

Damit der Workaround performant laufen kann, sollten nur die neuen Dateien gescannt werden.
Entweder kann man dazu die NC-Datenbank verwenden, wenn dort irgendwie sinnvoll die Files aufgelistet werden - oder es muss eine eigene Datenbank erzeugt werden. Erstmal kann auch der Cronjob selbst das Datum der letzten Änderung anschauen und nur diese Dateien syncen.

[Stephan Richter]

Da sollte doch einfach find reichen!?

find . -type f -cmin +60

[Rüdiger Kupper]

Replying to rich:

Da sollte doch einfach find reichen!?

find . -type f -cmin +60

Gute Idee, ich schaue mal, ob ich den Job entsprechend ändern kann. Allerdings scheint er auch auf dem Server keine besondere Last zu erzeugen.
Und vermutlich erzeugt der find-Befehl die selbe Last :-).

Es bleibt der Nachteil, dass der Scan nur alle 60 Minuten läuft. Die befriedigende Lösung wäre, wenn der Client, der eine Datei direkt in GlusterFS ändert, den NC-Server informiert. Ich sehe aber keinen Mechanismus, mit dem man das sinnvoll machen kann.
Letztlich wäre das ein Feature, das die „External Files“-App von NC anbieten müsste. Oder es sollte für diesen Usecase eine eigene NC-App geben. Da ist aber nichts geplant.

Die Alternative, unsere Clients nicht per GlusterFS sondern WebDAV anzubinden funktioniert zwar inzwischen (seit dem letzten Image-Update). Allerdings ist das völlig unperformant (Solange man nur eine Präsentation bearbeitet klappt’s, doch z.B. eine LaTeX-Datei darauf zu kompilieren scheitert kläglich).
Außerdem führt es den ganzen Performancegewinn durch redundante Server an drei Stellen im Schulhaus ad absurdum, wenn plötzlich wieder alle Clients über einen einzigen Server zugreifen. Da wären wir zurück in den alten „Peadml-Zeiten“, aus denen wir uns mühsam herausgearbeitet haben.

[Rüdiger Kupper]

Hinweis: das Argument zu -cmin muss "-60" lauten.

Der find-Befehl läuft tatsächlich deutlich schneller, allerdings ist es dafür nötig, die User-Homes seperat direkt über GlusterFS zu mounten (NC greift über SSH im Namen des Users zu). Leider ist zur Umsetzung etwas Bastelarbeit nötig, weil die Pfade im echten Dateisystem und für Nextcloud verschieden aufgebaut sind. Beispiel:

GlusterFS direkt

/home/teachers/kup/Dokumente

Nextcloud (Argument für occ:scan)

kup/files/Fileserver/Dokumente/

Zudem muss der find-Befehl als der betreffende User ausgeführt werden (hier kup), das occ:scan aber als User www-data. Man kann also nicht einfach die dafür vorgesehene --exec-Option von find verwenden.

Lässt sich alles skripten, aber eigentlich vermeide ich solche Bastelskripte. Besonders, wenn ich die Administration an eine andere Person übergeben will. Mal sehen, wann ich dafür Zeit finde.

[Rüdiger Kupper]

Da es absehbar (auch langfristig) keine Unterstützung für dieses Szenario in NC geben wird, habe ich beschlossen, die Fileserver-Anbindung an NC völlig aufzuheben. Nur dadurch werden wir die wiederkehrenden Probleme wie verschwindende Shares los.

Fahrplan:

1. Fileserver-Freigabe und Cronjob für Schüler entfernen (erfordert keine größere Information, denke ich)
2. Lehrer über die bevorstehenden Änderungen informieren und Alternativen erklären:
   • Zugriff über WebDAV (von zuhause und den Kepler-Clients)
   • Sync-Client (von zuhause und den Kepler-Clients)
3. dann Fileserver-Freigabe und Cronjob auch für Lehrer entfernen

[Rüdiger Kupper]

Cronjob und Fileserver-Freigabe für Schüler ist jetzt deaktiviert.