Dateimanagement

Das Dateimanagement auf dem Kitodo.Production-Server ist komplexer.

• Im Ordner “metadata” befinden sich die Dateien zu den einzelnen Vorgängen als nummerierte Unterordner, wobei die Nummer der ID des Vorgangs in der Datenbanktabelle “processes” entspricht.
• Wird ein neuer Vorgang angelegt, erzeugt es dazu einen Unterordner im Ordner “metadata”, den Vorgangsordner (z.B. .../metadata/42/). Da dies zu einer Zeit implementiert wurde, als Java noch nicht die spezifischen Eigenschaften von Linux-Systemen beherrschte, wird dazu ein .sh-Script (script_createDirMeta.sh) aufgerufen. Manche Institutionen machen in diesem Skript noch andere Dinge, deswegen ist das so beibehalten worden.
• Im Vorgangsordner wird ein Unterordner “images” angelegt und darin ein Ordner für die Originale. Dieser wird meist nach dem Vorgangstitel benannt. (Beispiel: .../metadata/42/images/LoremIpsum_1234567X_tif/) Das muss man nicht so machen, aber es ist weit verbreitet. Welche Ordner angelegt werden findet sich in den Projekteinstellungen auf Reiter 2 in der Mitte. In diesem Fall hieße der Ordner dort: images/(processtitle)_tif. (Siehe dazu auch: Platzhalter)
• Wenn ein Benutzer einen Arbeitsschritt “Scannen” übernimmt, wird im Benutzerordner ein symbolischer Link auf den images-Ordner des entsprechenden Vorgangs erzeugt. Auch das wieder per Skript (script_createSymLink.sh). Der Benutzerordner ist der Ordner, der per SMB-Freigabe auf dem PC oder Scanner als Netzlaufwerk verbunden wird. Der Benutzer “sieht” also immer nur die images-Ordner der Vorgänge, an denen er gerade arbeitet. Der Name des symbolischen Links besteht aus dem Vorgangstitel und der ID. (Beispiel: Der symbolische Link im Benutzerordner von Hans .../users/hans/LoremIpsum_1234567X_[42], unter Windows dann z.B. M:\LoremIpsum_1234567X_[42], verweist auf den Ordner .../metadata/42/images/. Scannen muss Hans dann in den Ordner M:\LoremIpsum_1234567X_[42]\LoremIpsum_1234567X_tif\)
• Damit der Benutzer per SMB in dem Ordner schreiben darf, muss jeder Benutzer der Webanwendung als Linux-Nutzer verwaltet werden, und beim Erstellen des symbolischen Links der Inhalt des images-Ordners dem Benutzer zugewiesen werden (chown). Dazu werden die Benutzer der Webanwendung, wenn man einen neuen Benutzer anlegt, in ein lokales LDAP geschrieben, das per Name Service Switch (nsswitch) eingebunden ist, um die Benutzer als Linux-Nutzer verfügbar zu machen. Damit das funktioniert, werden die vielen Felder in den LDAP-Gruppen benötigt.
• Wenn der Benutzer den Arbeitsschritt “Scannen” beendet, wird der symbolische Link wieder gelöscht (script_deleteSymLink.sh). Ein Benutzer kann also nicht versehentlich Vorgänge verändern, an denen er nicht gerade per Workflowsteuerung auch arbeiten will / soll.
• Wenn ein Benutzer einen Arbeitsschritt “Qualitätskontrolle” übernimmt, er die Bilder also nur ansehen, aber nicht verändern können soll, wird ebenfalls ein symbolischer Link angelegt, die Dateien werden dann aber mit chown root nur-lesbar gemacht.
• Andere Ordner (für Derivate / OCR / …) im Vorgangsordner sind möglich und tauchen auch auf, sind aber nicht für den Benutzer auf diesem Wege zugänglich.

Der magische Unterordner images

Alle Ordner in den Projekteinstellungen mit images/ vorne an gestellt, sind für den Benutzer unter dem symbolischen Link sichtbar und (je nach Berechtigung) ihre Inhalte änderbar, alle anderen Ordner sind für den Benutzer auf diesem Wege nie zugänglich. Je nach Berechtigungskonfiguration, die das script_createSymLink durchführt sind in der Regel die Verzeichnisse im Unterordner images/ schreibbar, der Ordner selbst aber nicht. Kommt dann aber im Einzelfall drauf an, wie die Skripte die Berechtigungen setzen.

Skripte und WebDav

WebDav unterstützt per Definition keine symbolischen Links, diese werden nicht angezeigt. Hier muss man die Skripte grundsätzlich anders entwerfen. Wird das Web-Dav-Modul des Apache Webservers benutzt, müssen die Dateien auch nicht dem Benutzer gehören, damit er dort schreiben darf, sondern dem Apache-Benutzer (meist www-run oder www-data). In dem Fall braucht man kein nsswitch. Der Apache kann ebenfalls auf den LDAP zugreifen um die einzelnen WebDav-Ressourcen zu authentifizieren. (Ein Beispiel für eine Installation mit WebDav findet sich in der Installation instructions for Kitodo.Production 2.3.1. Diese bezieht sich zwar auf Production 2.x, die Webdav betreffenden Teile kann man aber weiterhin so umsetzen.)