Lieber Herr Gerhardt, Liebe Kitodo-Community,
Danke für die schnelle und ausführliche Antwort!
Ich werde Ihre verschiedenen Lösungsansätze ausprobieren und mich gegebenenfalls bei
Problemen noch einmal melden.
Viele Grüße,
Clarissa Kopanitsak
---------------------------------------------------
Karlsruher Institut für Technologie (KIT)
KIT-Archiv
Clarissa Kopanitsak
Studentischer Mitarbeiter
Kaiserstraße 12
76131 Karlsruhe
Telefon: +49 721 608-45443
Fax: +49 721 608-943494
E-Mail: clarissa.kopanitsak2(a)parnter.kit.edu
Web:
http://www.archiv.kit.edu
KIT – Die Forschungsuniversität in der Helmholtz-Gemeinschaft
Das KIT ist seit 2010 als familiengerechte Hochschule zertifiziert.
________________________________________
Von: kitodo-community-bounces(a)kitodo.org <kitodo-community-bounces(a)kitodo.org> im
Auftrag von kitodo-community-request(a)kitodo.org
<kitodo-community-request(a)kitodo.org>
Gesendet: Freitag, 19. Juli 2019 16:21
An: kitodo-community(a)kitodo.org
Betreff: Kitodo-Community Nachrichtensammlung, Band 35, Eintrag 2
Um e-Mails an die Liste Kitodo-Community zu schicken, nutzen Sie bitte
die Adresse
kitodo-community(a)kitodo.org
Um sich via Web von der Liste zu entfernen oder draufzusetzen:
https://maillist.slub-dresden.de/cgi-bin/mailman/listinfo/kitodo-community
oder, via Email, schicken Sie eine Email mit dem Wort 'help' in
Subject/Betreff oder im Text an
kitodo-community-request(a)kitodo.org
Sie koennen den Listenverwalter dieser Liste unter der Adresse
kitodo-community-owner(a)kitodo.org
erreichen
Wenn Sie antworten, bitte editieren Sie die Subject/Betreff auf einen
sinnvollen Inhalt der spezifischer ist als "Re: Contents of
Kitodo-Community digest..."
Meldungen des Tages:
1. Re: Probleme bei Insterllieren von Kitodo 2.2.0 - Evlt. ein
Rechtevergabe-Problem? (Henning Gerhardt)
----------------------------------------------------------------------
Message: 1
Date: Fri, 19 Jul 2019 15:45:28 +0200
From: Henning Gerhardt <henning.gerhardt(a)slub-dresden.de>
Subject: Re: [Kitodo] Probleme bei Insterllieren von Kitodo 2.2.0 -
Evlt. ein Rechtevergabe-Problem?
To: <kitodo-community(a)kitodo.org>
Message-ID: <2978791a-ab74-ebff-ebc8-66c333c3bfcd(a)slub-dresden.de>
Content-Type: text/plain; charset="utf-8"
Liebe Frau Kopanitsak, liebe Community,
in den Kitodo Shell Scripten
- script_createDirUserHome.sh
- script_createSymLink.sh
wird jeweils der Benutzer übergeben, dem dann das Verzeichnis gehören
soll. Ein normaler Benutzer, wie der tomcat Benutzer des Tomcat-Servers,
kann aber nicht "fremden" Benutzern die Berechtigung dafür geben bzw.
die Berechtigung dafür an diese abgeben. Man hat mehrere Möglichkeiten:
1) Man passt die Scripte an, so dass keine Benutzer-Änderung mehr
stattfindet. Sofern man nur einen oder wenige Benutzer hat, geht dies.
Bei größeren Einrichtungen und / oder mehreren Benutzern ist dies aber
kein Weg.
2) Man installiert bspw. das Paket sudo (oder etwas ähnliches) mit
dessen Hilfe es möglich ist, kurzfristig Aufrufe mit System/root-Rechten
auszuführen. Die enthaltenen Aufrufe in den Scripte müssten dann
wenigstens um ein sudo erweitert werden und in der /etc/sudoers die
passenden Einträge hinterlegt werden.
Es gibt darüber hinaus noch sicher andere Möglichkeiten, die der
Möglichkeit 2) ähneln oder diese noch stark erweitern.
Wenn man sich für den Weg 2) entscheidet, dann muss auch jeder Benutzer,
der diese Berechtigungen bekommen soll, auf dem jeweiligen System
existieren bzw. bekannt sein. Auch dafür gibt es mehrere Möglichkeiten:
1) Man legt den Benutzer lokal auf dem jeweiligen Server an. Dies kann
bei einer überschaubaren Nutzeranzahl noch gut machbar sein sofern man
darüber hinaus nicht noch weitere Komponenten für den Datenaustausch auf
u.a. anderen Servern nutzen will / muss.
2) Man hinterlegt den Benutzer in einem zentralisierten
Authentifizierungssystem wie LDAP / AD und bindet dieses auf dem Server
mit ein. Dies ist der bessere Weg bei größeren Installation und / oder
wenn man bspw. den Datenaustausch via WebDAV oder Samba / Cifs
realisieren muss.
Da es sehr viele Möglichkeiten gibt und diese auch noch stark von der
genutzten Infrastruktur abhängen, ist es nicht wirklich möglich eine
überschaubare Installationsanleitung zu schreiben, die viele
Möglichkeiten mit inkludiert.
Viele Grüße
Henning Gerhardt
On 7/19/19 3:14 PM, Kopanitsak, Clarissa (ASERV) wrote:
Sehr geehrte Damen und Herren der Kitodo-Community,
im Auftrag des Archivs vom Karlsruher Institut für Technologie
(KIT) habe ich die Aufgabe übernommen im Rahmen des
Digitalisierungsprojekts einen METS-Editor ausfindig zu machen, der
unseren Zwecken entspricht.
Kitodo hat mich hierbei durch die Internetpräsentation und des
auf Github bereitgestellten "Tutorial für Kitodo 2.x"
(
https://github.com/kitodo/kitodo-tutorials/tree/master/kitodo2?)
anlässlich des Workshops "Kitodo for newbies" vollends überzeugt.
Auch, wenn ich beim Einrichten eines lokalen Servers, ähnlich wie
der von Zeutschel, auf einige Schwierigkeiten stieß, konnte ich
diese dank der Dokumentation auf github und der Hilfe des Internets
weitestgehend beseitigen.
Leider stehe ich nun einem Problem gegenüber bei dem ich nicht mehr
weiterkomme und die Hilfe der Kitodo-Community benötige.
Ich vermute, dass das Problem an der Rechtevergabe von
Benutzer "tomcat7" liegt.
Die Hauptfehlermeldungen, um die es mir geht, beginnen nach dem
"Tutorial für Kitodo 2.x" ab "5. Vorgänge anlegen", wenn dem
"Scanner-Nutzer" die weitere Bearbeitung des Vorgangs übertragen wird.
(Bei der lokalen Durchführung des Workshops habe ich die bereits
angelegten Test-Nutzer benutzt. Das Anlegen neuer Benutzer verläuft
soweit ohne Probleme, auch das Einloggen. Ab der Übergabe des Vorgangs
zum Scanner-Nutzer taucht jedoch der Fehler "/bin/chown: ungültiger
Benutzer: ?workshop2019scanning? ?auf; der Image-Ordner zum Vorgang
kann jedoch ohne weiteres angelegt werden. Ich denke, dass dieser
Fehler auch mit dem beschriebenen Problem im Zusammenhang steht.)
Bei der Einrichtung des Lokalen Servers orientierte ich mich an
der "Installationsanleitung für Kitodo 2.1"
(
https://github.com/kitodo/kitodo-production/wiki/Installationsanleitung-für…)
Folgende Fehlermeldung wird bei der Aufgabenanahme durch den
Test-Scanner-Benutzer ausgegeben:
* ?/usr/local/kitodo/users/testScanning/5635__[12]? ->
?/usr/local/kitodo/metadata/12/images?
* das Ändern des Eigentümers von
?/usr/local/kitodo/metadata/12/images/tiffwriter.conf? von tomcat7
zu testScanning ist fehlgeschlagen
* das Ändern des Eigentümers von
?/usr/local/kitodo/metadata/12/images/master_5635_media? von
tomcat7 zu testScanning ist fehlgeschlagen
* das Ändern des Eigentümers von
?/usr/local/kitodo/metadata/12/images? von tomcat7 zu testScanning
ist fehlgeschlagen
* /bin/chown: der Eigentümer von
?/usr/local/kitodo/metadata/12/images/tiffwriter.conf? wird
geändert: Die Operation ist nicht erlaubt
* /bin/chown: der Eigentümer von
?/usr/local/kitodo/metadata/12/images/master_5635_media? wird
geändert: Die Operation ist nicht erlaubt
* /bin/chown: der Eigentümer von
?/usr/local/kitodo/metadata/12/images? wird geändert: Die
Operation ist nicht erlaubt
Die Fehlermeldung zieht sich hierbei auch beim Quality-Check-Nutzer
durch, unabhängig davon, ob im Mediaordner Bilder abgelegt wurden oder
nicht:
* ?/usr/local/kitodo/users/testQC/5635__[12]? ->
?/usr/local/kitodo/metadata/12/images?
* das Ändern des Eigentümers von
?/usr/local/kitodo/metadata/12/images/tiffwriter.conf? von tomcat7
zu root ist fehlgeschlagen
* das Ändern des Eigentümers von
?/usr/local/kitodo/metadata/12/images/master_5635_media? von
tomcat7 zu root ist fehlgeschlagen
* das Ändern des Eigentümers von
?/usr/local/kitodo/metadata/12/images? von tomcat7 zu root ist
fehlgeschlagen
* /bin/chown: der Eigentümer von
?/usr/local/kitodo/metadata/12/images/tiffwriter.conf? wird
geändert: Die Operation ist nicht erlaubt
* /bin/chown: der Eigentümer von
?/usr/local/kitodo/metadata/12/images/master_5635_media? wird
geändert: Die Operation ist nicht erlaubt
* /bin/chown: der Eigentümer von
?/usr/local/kitodo/metadata/12/images? wird geändert: Die
Operation ist nicht erlaubt
Entsprechend wird beim Metadateneditor-Nutzer, wenn man auf "Metadaten
bearbeiten" und anschließend auf "Paginierung bearbeiten" klickt
folgendes ausgegeben, auch, wenn Bilder vorhanden sind:
* ?[???] No objects found
Wenn Bilder im Media-Ordner abgelegt wurden haben sie durchgehend
diese Rechteverteilung:
-rw-r--r-- 1 tomcat7 tomcat7 8375330 Jul 13 18:42 0001.jpg
Wie unter "Grundkonfigurationen" bei "Installationsanleitung für
Kitodo 2.1" angegeben, ist die Rechteverteilung der Ordner
unter /usr/local/kitodo/ wie folgt:
dr-xr-sr-x 2 tomcat7 tomcat7 4096 Jul 13 17:00 config
drwxrwsrwx 2 tomcat7 tomcat7 4096 Jul 12 18:13 debug
dr-xr-sr-x 2 tomcat7 tomcat7 4096 Jul 12 18:13 import
drwxrwsrwx 2 tomcat7 tomcat7 4096 Jul 12 19:13 logs
dr-xr-sr-x 2 tomcat7 tomcat7 4096 Jul 12 18:13 messages
drwxrwsrwx 13 tomcat7 tomcat7 4096 Jul 15 13:52 metadata
dr-xr-sr-x 7 tomcat7 tomcat7 4096 Jul 13 16:52 plugins
dr-xr-sr-x 2 tomcat7 tomcat7 4096 Jul 13 18:07 rulesets
dr-xr-sr-x 2 tomcat7 tomcat7 4096 Jul 12 18:56 scripts
drwxrwsrwx 2 tomcat7 tomcat7 4096 Jul 12 18:13 swap
drwxrwsrwx 2 tomcat7 tomcat7 4096 Jul 12 18:13 temp
drwxrwsrwx 11 tomcat7 tomcat7 4096 Jul 13 18:53 users
dr-xr-sr-x 2 tomcat7 tomcat7 4096 Jul 13 17:01 xslt
Die Rechte wurde mit -R vererbt.
Die Gruppenzugehörigkeit und Rechte von tomcat7 sind: uid=119(tomcat7)
gid=126(tomcat7) Gruppen=126(tomcat7)
Um meine Vorgehensweise bei der Installation besser nachzuvollziehen
ist hier der Installationsablauf nach "Installationsanleitung für
Kitodo 2.1" angegeben:
* ?Das vorgebene Betriebsystem Debian 8 wurde mit der auf
https://www.debian.org <https://www.debian.org> zur
Verfügung gestellten Netinsall debian-8.11.1-amd64-netinst.iso
auf Oracle VirtualBox 6.0 (6.0.8) realisiert.
* ?Sowohl der Dienst Tomcat7 als auch der MySQL Server 5.5 laufen
auf dem System reibungslos.
* Die my.cnf wurde wie angegeben bearbeitet
* Die gewünschte Datenbank "kitdodo" wurde angelegt und alle
Privilegien auf kitodo übertragen
* Die Datei "tomcat7" unter /etc/default/tomcat7 ist wie vorgegeben
ergänzt worden mit: JAVA_OPTS="-Djava.awt.headless=true -Xmx1920m
-XX:MaxPermSize=128m -XX:+UseConcMarkSweepGC"
* Es wurde die "kitodo-production-2.2.0.war" unter
"https://github.com/kitodo/kitodo-production/releases" geladen,
nach /var/lib/tomcat7/webapps/ verschoben und automatisch deployt
* Die hibernate.cfg.xml wurde für die lokale Installation so
belassen wie sie ist??
* Die Dateien "schema.sql" und "default.sql" wurden mit dem
angegebenen Befehl eingebunden
* Folgendes gibt MySQL bei "show databases" aus
*
+--------------------+
| Database |
+--------------------+
| information_schema |
| kitodo |
| mysql |
| performance_schema |
+--------------------+
*
Die Grundkonfiguration wurde wie gewünscht durchgeführt.
(Rechtevergabe und angelegte Ordner siehe oben)
*
Die "goobi_config.properties?" wurden wie vorgegeben angepasst.
*
Die "kitodo.log" funktioniert. (Die entsprechende *.log befindet
sich im Anhang. Bitte ignorieren sie den Fehler am Anfang des
Dokuments was die gdz.xml angeht. Dieser konnte behoben werden.)
*
Die angegebenen goobi_*.xml-Dateien und die modules.xml-Datei
wurden in das in goobi_config.properties angegebene
KonfigurationVerzeichnis kopiert (und die kitodo_mods_opac.xml)
*
-r-xr-xr-x 1 tomcat7 tomcat7 30693 Jul 12 18:48
goobi_config.properties
-r-xr-xr-x 1 tomcat7 tomcat7 420 Jul 13 12:49
goobi_digitalCollections.xml
-r-xr-xr-x 1 tomcat7 tomcat7 232 Jul 12 18:48
goobi_loginBlacklist.txt
-r-xr-xr-x 1 tomcat7 tomcat7 102898 Jul 12 18:48
goobi_metadataDisplayRules.xml
-r-xr-xr-x 1 tomcat7 tomcat7 0 Jul 12 18:48
goobi_opacLanguages.txt
-r-xr-xr-x 1 tomcat7 tomcat7 537 Jul 12 18:48 goobi_opacUmlaut.txt
-r-xr-xr-x 1 tomcat7 tomcat7 5304 Jul 12 18:48 goobi_opac.xml
-r-xr-xr-x 1 tomcat7 tomcat7 851 Jul 12 18:48
goobi_processProperties.xml
-r-xr-xr-x 1 tomcat7 tomcat7 6950 Jul 13 12:36 goobi_projects.xml
-r-xr-xr-x 1 tomcat7 tomcat7 337 Jul 12 18:48 goobi_webapi.xml
-r-xr-xr-x 1 tomcat7 tomcat7 3488 Jul 13 17:00 kitodo_mods_opac.xml
-r-xr-xr-x 1 tomcat7 tomcat7 506 Jul 12 18:50 modules.xml
*
Die docket.xsl und docket_multipage.xsl wurden in den
entsprechenden XsltFolder verschoben (und die kalliope2kitodo.xsl)
*
-r-xr-xr-x 1 tomcat7 tomcat7 20577 Jul 12 18:52 docket_multipage.xsl
-r-xr-xr-x 1 tomcat7 tomcat7 20478 Jul 12 18:52 docket.xsl
-r-xr-xr-x 1 tomcat7 tomcat7 5485 Jul 13 17:01 kalliope2kitodo.xsl
* Die Konfigurationsdatei goobi_projects.xml wurde so belassen wie
sie ist.
* Die
Dateien goobi_metadataDisplayRules.xml, goobi_processProperties.xml
und goobi_digitalCollections.xml wurde so belassen wie sie sind.
* die Dateien ruleset_slubdd.xml und ruleset_subhh.xml wurde in den
entsprechenden rulesets-Ordner verschoben (Die gdz.xml wurde aus
dem Tutorial über Github geladen)
*
-r-xr-xr-x 1 tomcat7 tomcat7 135926 Jul 13 18:17 gdz.xml
-r-xr-xr-x 1 tomcat7 tomcat7 216636 Jul 12 19:08 ruleset_slubdd.xml
-r-xr-xr-x 1 tomcat7 tomcat7 87928 Jul 12 19:08 ruleset_subhh.xml?
Die einzige Stelle an der der Benutzer "root" noch auftaucht ist, wenn
man im /usr/local/kitodo die Besitzer und die Rechte abfragt, da
jedoch im übergeordneten Ornder.
Siehe:
root@debian:/usr/local/kitodo# ls -la
insgesamt 60
drwxrwsrwx 15 tomcat7 tomcat7 4096 Jul 12 18:13 .
*drwxrwsr-x 11 root staff 4096 Jul 12 18:12 ..*
dr-xr-sr-x 2 tomcat7 tomcat7 4096 Jul 13 17:00 config
drwxrwsrwx 2 tomcat7 tomcat7 4096 Jul 12 18:13 debug
dr-xr-sr-x 2 tomcat7 tomcat7 4096 Jul 12 18:13 import
drwxrwsrwx 2 tomcat7 tomcat7 4096 Jul 12 19:13 logs
dr-xr-sr-x 2 tomcat7 tomcat7 4096 Jul 12 18:13 messages
drwxrwsrwx 13 tomcat7 tomcat7 4096 Jul 15 13:52 metadata
dr-xr-sr-x 7 tomcat7 tomcat7 4096 Jul 13 16:52 plugins
dr-xr-sr-x 2 tomcat7 tomcat7 4096 Jul 13 18:07 rulesets
dr-xr-sr-x 2 tomcat7 tomcat7 4096 Jul 12 18:56 scripts
drwxrwsrwx 2 tomcat7 tomcat7 4096 Jul 12 18:13 swap
drwxrwsrwx 2 tomcat7 tomcat7 4096 Jul 12 18:13 temp
drwxrwsrwx 11 tomcat7 tomcat7 4096 Jul 13 18:53 users
dr-xr-sr-x 2 tomcat7 tomcat7 4096 Jul 13 17:01 xslt
Der Server wurde bereits mehrfach nochmals aufgesetzt, auf die
Vermutung hin, dass ich einen Flüchtigkeitsfehler gemacht haben
könnte. Die Fehlermeldungen taucht jedoch konstant immer wieder auf.
Ich hoffe ich konnte mein Problem verständlich darlegen und Sie haben
eine Idee was die Lösung sein könnte, weil ich im Moment keinen
Lösungsansatz mehr habe.
Bitte geben Sie mir Bescheid sollten Sie noch weiter Angaben benötigen.
Mit freundlichen Grüße,
i.A.
Clarissa Kopanitsak
---------------------------------------------------
Karlsruher Institut für Technologie (KIT)
KIT-Archiv
Clarissa Kopanitsak
Studentischer Mitarbeiter
Kaiserstraße 12
76131 Karlsruhe
Telefon: +49 721 608-45443
Fax: +49 721 608-943494
E-Mail: clarissa.kopanitsak2(a)parnter.kit.edu
Web:
http://www.archiv.kit.edu
KIT ? Die Forschungsuniversität in der Helmholtz-Gemeinschaft
Das KIT ist seit 2010 als familiengerechte Hochschule zertifiziert.
_______________________________________________
Kitodo-Community mailing list
Kitodo-Community(a)kitodo.org
https://maillist.slub-dresden.de/cgi-bin/mailman/listinfo/kitodo-community
--
Henning Gerhardt
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek Dresden (SLUB)
Abt. Informationstechnologie (IT), Ref. 2.5 - Digitale Objekte
01054 Dresden
Besucheradresse: Zellescher Weg 18, 01069 Dresden
Tel.: +49 351 4677 227
E-Mail: henning.gerhardt(a)slub-dresden.de
www.slub-dresden.de
-------------- n?ster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL:
http://maillist.slub-dresden.de/pipermail/kitodo-community/attachments/2019…
-------------- n?ster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname : smime.p7s
Dateityp : application/pkcs7-signature
Dateigröße : 5408 bytes
Beschreibung: S/MIME Cryptographic Signature
URL :
http://maillist.slub-dresden.de/pipermail/kitodo-community/attachments/2019…
------------------------------
_______________________________________________
Kitodo-Community mailing list
Kitodo-Community(a)kitodo.org
https://maillist.slub-dresden.de/cgi-bin/mailman/listinfo/kitodo-community
Ende Kitodo-Community Nachrichtensammlung, Band 35, Eintrag 2
*************************************************************