2016.06

MIR

Installation

Voraussetzungen

Neben den allgemein für MyCoRe-Anwendungen geltenden Systemanforderungen benötigen Sie für den Betrieb einer MIR-Anwendung noch die folgende Software:

  • bibutils

Download

Informationen zum aktuellen Release und ein Changelog befinden sich im Download-Bereich. Hier kann das aktuelle MIR-Paket (speichern als mir.war) heruntergeladen werden. Dieses kann mit dem Context 'mir' direkt in einen Servlet Container ausgeliefert (deployed) werden.

Für administrative Zwecke kann zusätzlich eine MIR-CLI in zwei verschiedenen Formaten heruntergeladen werden:

  1. ZIP archive (speichern als mir-cli.zip)
  2. tar.gz archive (speichern als mir-cli.tar.gz)

Solr-Installation

Soll ein eigener Solr-Server aufgesetzt werden, sind weitere Informationen dazu in unserer Solr-Dokumentation zu finden. Den Solr-Kern für MIR liefert die Installation über den MIR-Wizard mit. Soll nicht das vom MIR-Wizard angelegte solr-home verwendet werden, so muss das Verzeichnis mir/data/solr/collection1 entsprechend umkopiert werden. Auch der Name des Solr-Kerns kann beliebig angepasst werden. Wo der passende Kern gefunden werden kann, wird im MIR-Wizard konfiguriert.

Weitere Möglichkeiten der Konfiguration und mehr Informationen zur Solr-Installation finden sich in der Solr-Dokumentation.

Datenbank

MIR bringt H2 und HSQLDB als im-Speicher-laufende relationale Datenbanksysteme mit. Bei der Installation können diese beiden (neben verschiedenen anderen) gewählt werden. Dann ist nichts weiter zu tun. Soll eine andere Datenbank genutzt werden, so muss diese entsprechend im Wizard konfiguriert werden und ggf. weitere Anpassungen in der durch den Wizard angelegten hibernate.cfg.xml vorgenommen werden. Das zur Datenbank passende Treiber-Paket wird im lib-Verzeichnis abgelegt und muss ggf. ersetzt werden, sollte der Wizard kein passendes Paket finden können. Weitere Information zur Konfiguration sind auf in der Dokumentation zu Datenbank & Hibernate zusammengetragen.

bibutils

bibutils ist ein kleines Kommandozeilenwerkzeug, das zwischen verschiedenen gängigen Bibliotheksformaten konvertiert. Um die Exportschnittstelle bei MIR vollständig zu unterstützen, muss aus der Webanwendung heraus dieses Kommandozeilenwerkzeug ausgeführt werden können. Der Nutzer mit dem der ServletContainer läuft muss also beispielsweise den Befehl bib2xml ausführen können (konvertiert BibTeX nach MODS-XML).

Dokumentation, Download und Installationsanleitung zu den bibutils sind auf der Sourceforge-Projekt-Seite zu finden. Für Windows kann eine veraltete Version (3.4, aktuell ist 5.6 - Stand 08/2015) auf der ehemaligen bibutils-Homepage heruntergeladen werden.

MIR-Wizard

Nachdem das mir.war durch den ServletContainer bereitgestellt (deployed) wurde, erreicht man über die entsprechende Anwendungs-URL den MIR-Wizard, mit dem die Installation abgeschlossen wird. Wird Tomcat mit den Standard-Einstellungen genutzt, wäre das beispielsweise die URL http://localhost:8080/mir/.

Nach Aufruf dieser URL wird der MIR-Wizard gestartet, der wie Abb. 1 zeigt, ein Sicherheits-Token abfragt, das sich im Log des Servletcontainers (z.B. Tomcat-Log, siehe Abb. 2) befindet. Sucht man im Log nach "Login token", findet man die entsprechende Stelle recht schnell. Das Token - eine UUID - muss dann vollständig kopiert und eingefügt werden. Danach kann die Installation beginnen.

Tokenabfrage im MIR-Wizard
Abbildung 1: MIR-Wizard - Sicherheitsabfrage nach einem Token
Token-Logausgabe auf der Shell
Abbildung 2: MIR-Wizard - Token-Logausgabe auf der Shell

Auf der folgenden Konfigurationsseite des Wizards (Abb. 3) muss nun bekannt gegeben werden, wo der Solr-Kern für die MIR-Anwendung zu finden ist. Läuft Solr im gleichen ServletContainer wie die MIR-Anwendung und wird die Default-Einstellung verwendet, muss hier nur ggf. der Port angepasst werden (z.B. auf 8080 bei Standard-Tomcat-Installtionen). Die SMTP-Konfiguration ist optional, wird diese leer gelassen, kann die Anwendung keine Mails versenden. Mit funktionierender SMTP-Konfiguration versendet die Anwendung Mails bei der Selbstregistrierung um die Mail-Adresse zu validieren und auch im Rahmen des Publikationsworkflows. Diese Konfiguration kann auch nachträglich erfolgen. Als Datenbank kann zu Testzwecken ersteinmal H2 oder HSQLDB ausgewählt werden. Für den produktiven Betrieb empfehlen wir jedoch keine imRAM-Datenbank zu nutzen.

Konfigurationsseite des MIR-Wizards
Abbildung 3: MIR-Wizard - Konfiguration der MIR-Anwendung

Anschliessend auf "Speichern" drücken. Nun werden Konfigurationsdateien erzeugt, Datenbanktreiber heruntergeladen, ein Solr-Home mit einem Solr-Kern für die MIR-Anwendung angelegt und Klassifikationen, Nutzer und Rechtedaten geladen. Sind alle Schritte auf der nachfolgenden Seite erfolgreich abgeschlossen worden, muss als nächstes der ServletContainer einmal neu gestartet werden. Dazu kann man direkt den Knopf "Server Herunterfahren" am Ende der Seite verwenden. Wer nicht den gesamten ServletContainer neustarten möchte, kann auch nur die MIR-Anwendung neustarten. Erst mit diesem Neustart werden die neuen Konfigurationen gefunden und eingelesen. Dann steht unter http://localhost:8080/mir/ die Anwendung zur Verfügung und man kann sich mit dem Standardnutzer: "administrator" und dem Standardpasswort: "alleswirdgut" anmelden.

Im Rahmen der MIR-Installation wurde ein Konfigurationsverzeichnis angelegt. Dieses befindet sich typischer Weise unter:

  • Windows: c:\Users\<userName>\AppData\Local\MyCoRe\mir
  • Unix: ~/.mycore/mir

... wobei mir beispielhaft für den Context-Namen der Webanwendung steht. Diese Anleitung bezieht sich auf Tomcat als ServletContainer mit mir und solr als Anwendungen direkt unter localhost:8080. Sollte die eigene Umgebung davon abweichen, muss die Konfiguration entsprechend angepasst werden.

Konfiguration

Aufbau des Konfigurationsverzeichnisses

MIR-Konfigurationsverzeichnis
Abbildung 4: MIR-Konfigurationsverzeichnis

Properties

mycore.properties
enthält alle eigenen Properties, z.B. die URL zum verwendeten Solr-Core
mycore.active (nicht bearbeiten!)
listet alle verfügbaren (aktiven) Properties inkl. Kommentaren dazu und kann somit als Vorlage zur Übernahme in die eigenen Properties dienen
mycore.resolved (nicht bearbeiten!)
die aufgelösten Properties, wie sie in der laufenden Anwendung genutzt werden

Anpassungen

Alle Anpassungen am Layout, Webseiten-Inhalten, Erfassungsmasken etc. werden im Verzeichnis %MCR.datadir%/save/webpages hinterlegt. Beim Starten des Servlet-Containers wird der Inhalt dieses Verzeichnisses über das ausgepackte webapp-Verzeichnis im Servlet-Container kopiert und somit die default-Inhalte des mir.war überschrieben. Die nachstehende Abbildung gibt einen Überblick über typische Anpassungen bei einer eigenen MIR-Anwendung.

MIR-Webseitenverzeichnis
Abbildung 5: MIR-Webseitenverzeichnis

Als Vorlage können dafür die Dateien in den MIR-Komponenten verwendet werden. Dateien, die an der gleichen Stelle liegen (unterhalb von webpages == unterhalb von resources in den MIR-Komponenten) und den gleichen Namen haben wie in einer MIR-Komponente werden dann durch die eigene Angabe überschrieben. Alle Inhaltsseiten, Erfassungsmasken und Stylesheets zur MIR-Anwendung liegen in mir-module/src/main/resources/. Für Layoutanpassungen kann eine eigene css-Datei hinterlegt werden, die im Verzeichnis css wie in der obigen Abbildung dargestellt abzulegen ist. Sollte das Basis-HTML angepasst werden sollen, so stehen hierfür die beiden XSL-Dateien mir-flatmir-layout.xsl und mir-flatmir-layout-utils.xsl in mir-flatmir-layout/src/main/resources/xsl/ zur Verfügung.

Sollten diese Möglichkeiten zur Layoutanpassung nicht genügen, so empfehlen wir (auch in Hinblick auf Migrierbarkeit), ein eigenes Layoutmodul analog zum mir-flatmir-layout anzulegen. Diese jar-Datei kann dann im mir/libs-Verzeichnis bereitgestellt und über das Property MCR.LayoutTransformerFactory.Default.Stylesheets eingebunden werden.

        MCR.LayoutTransformerFactory.Default.Stylesheets=xsl/mir-myapp-layout.xsl
      

Aktivierung der Selbst-Registrierung

Um als Alternative zur Anmeldung auch eine Selbstregistrierung anzubieten, kann dies in der realms.xml im Verzeichnis data konfiguriert werden. Dazu muss der nachstehende Code ergänzt werden (siehe dazu auch die hier verfügbare vollständige realms.xml).

  <realm id="registerUser" setable="false">
    <label xml:lang="de">Registrierung</label>
    <label xml:lang="en">Register</label>
    <login url="../authorization/new-author.xed" redirectParameter="url">
      <label xml:lang="de">Neue Benutzerkennung anlegen</label>
      <label xml:lang="en">Create new User ID</label>
      <info>
        <label xml:lang="de">
          Neuen Benutzer für die Anwendung registrieren.
        </label>
        <label xml:lang="en">
          Register new user for application.
        </label>
      </info>
    </login>
  </realm>

MIR bringt bereits entsprechende Formulare und Logik mit. Um Spam zu vermeiden nutzen diese das Google-Captcha, für das entsprechend ein Schlüsselpaar registriert und in der MyCoRe-Konfiguration eingetragen werden muss. Details zur Registrierung finden Sie auf den entsprechenden Google-Seiten. Wenn Sie das Schlüsselpaar registriert haben, tragen Sie dieses in die mycore.properties wie folgt ein:

          ##############################################################################
          #                                                                            #
          # Google - ReCaptcha (https://www.google.com/recaptcha)                      #
          # registered for: www.mycore.de                                              #
          #                                                                            #
          ##############################################################################

            MIR.ReCaptcha.secret.key=1234hierkommtdannderprivateschluesselhin4321
            MIR.ReCaptcha.site.key=5678undhierderoeffentlicheschluessel8765
        

Diese Konfiguration ist so auch auf mycore.org/mir/ aktiv und kann dort getestet werden.

Aktualisierung

Für die Aktualisierung werden im Normalfall nur das mir.war und ggf. die solr-Konfigurationsdateien solrconfig.xml und schema.xml ausgetauscht und danach die Webanwendung inkl. Solr neu gestartet. Sollten Konfigurationen angepasst oder Daten migriert werden müssen, werden entsprechende Informationen an dieser Stelle bereitgestellt.

 Kathleen Neumann - 2016-07-19