Zielgruppe BetriebVersion: GSB10.0Installation
Die notwendigen Schritte zur Vorbereitung und zur Durchführung der Installation werden in diesem Kapitel vorgestellt.
- 1 Vorbereitung
- 2 Benutzer
- 3 Verzeichnisse
- 4 Erstellung des Platform-Bundles
- 5 Installation des Platform-Bundles
- 6 Mandant Import
Die Installationsanleitung ist geeignet, um die Installation des GSB auf dem präferierten Betriebssystem Redhat Linux bzw. CentOS Linux einfach nachvollziehen zu können.
Weiterhin geht die Installationsanleitung davon aus, dass für die geforderten Beistellungen die Standard Pakete des Betriebssystems bzw. die von den jeweiligen Herstellern zur Verfügung gestellten RPMs genutzt werden. Die in der Installationsanleitung angesprochenen Pfade und die im GSB Release enthaltenen Vorlagen (bspw. für Service-Units) verwenden die Standard Pfade und Installationsverzeichnisse der Beistellungen.
| Hinweis: |
|---|
| Bitte achten Sie darauf, Archive direkt auf Linux-Umgebungen zu entpacken, da es bei Datei-Operationen unter Windows zu Veränderungen der Rechte von Archivdateien kommen kann. So können Sie beispielsweise verhindern, dass ausführbare Dateien nach einem Transfer von Windows zu Linux nicht mehr "executable" sind. |
1 Vorbereitung
Die Vorbereitung der Installation der GSB Infrastruktur erfordert die Bereitstellung einiger Beistellungen sowie der Runtime-Konfigurationen für die einzelnen Service-Instanzen.
1.1 Lizenzschlüssel
Der Betrieb des GSB erfordert eine gültige Lizenz, die vom GSB Produkthersteller ausgestellt wird. Für die Beantragung einer Lizenz wenden Sie sich bitte an die Mailadresse mailto://gsb@itzbund.de. Die Lizenzdaten sind anschließend in der Runtime-Konfiguration der Repository Webapplikation zu hinterlegen.
1.2 Beistellungen
Der GSB erfordert eine Reihe von Beistellungen deren Installation und Konfiguration in den folgenden Unterkapiteln beschrieben wird. Die in der Beschreibung benannten Links und Versionen stellen die zum Zeitpunkt der Erstellung dieser Dokumentation aktuellen Versionen dar.
1.2.1 Java
Der GSB benötigt eine Java 8 SE Runtime Edition für den Betrieb der Tomcat-Server basierten Service-Instanzen. Details zu den benötigten Versionen finden sich in der Tabelle Systemvoraussetzungen.
Das RPM für die zurzeit aktuelle Java Standard Edition kann per Download von Oracle Website bezogen werden.
Das RPM kann nach dem Download bspw. mit dem Kommando
Java RPM-Installation
sudo yum –y install <JAVA_SE_RPM>
installiert werden wobei das Token <JAVA_SE_RPM> durch den Pfad zum RPM ersetzt werden muss.
Die Java-Runtime ist nach Installation des RPM unterhalb des Pfades /usr/java/default zugreifbar und wird vom GSB auch in diesem Pfad erwartet, da dieser Pfad in den für den Start der GSB Tomcat-Service-Instanzen eingesetzten Systemd Service-Units gesetzt ist.
| Hinweis: |
|---|
Das Java RPM kann auch auf anderen Linux Distributionen für die Installation genutzt werden, so dass an dieser Stelle keine distributionsspezifischen Besonderheiten zu berücksichtigen sind. Sollte eine Installation von Java im Pfad /usr/java/default nicht möglich sein, dann muss die JAVA_HOME Variable in den GSB Systemd Service-Units entsprechend angepasst werden (Dateien /etc/systemd/system/<SERVICE_TYP>@.service). |
1.2.2 Tomcat-Server
Der GSB benötigt einen Tomcat-Server für den Betrieb der GSB Webapplikationen. Details zu den benötigten Versionen finden sich in der Tabelle „Systemvoraussetzungen“.
Die einzelnen GSB Tomcat-Instanzen werden mit einer Tomcat Multi-Instance-Konfiguration betrieben. Details hierzu finden sich im Kapitel „Advanced Configuration - Multiple Tomcat Instances“ auf der Seite https://tomcat.apache.org/tomcat-8.5-doc/RUNNING.txt. Der Betrieb in einer Multi-Instance-Konfiguration hat den Vorteil, dass auf einem Server nur eine Tomcat-Installation durchgeführt wird und nicht für jede Tomcat-Instanz eine dedizierte Installation vorhanden sein muss.
Installation Tomcat-Server
Für den Zugriff auf den Tomcat per JMX muss zusätzlich noch das JMX-Remote-Jar installiert werden. Dieses Jar-File ist spezifisch für die jeweilige Tomcat-Version zu nutzten, so dass dieses zusammen mit der eingesetzten Tomcat-Version geladen und im Tomcat Lib-Ordner abgelegt werden muss.
Die für die Installation genutzte Tomcat-Server Version kann der Tabelle „Systemvoraussetzungen“ entnommen werden. Das in der weiteren Beschreibung genutzte Token <TOMCAT_VERSION> muss durch die gewünschte Tomcat-Server Version ersetzt werden.
Der Tomcat-Server wird unterhalb des Pfades /opt/software/tomcat installiert. Zusätzlich wird ein symbolischer Link von /opt/software/tomcat/default auf die einzusetzende Tomcat-Server Installation (bspw. /opt/software/tomcat/apache-tomcat-<TOMCAT_VERSION>) gesetzt, da innerhalb der für den Start der Komponenten eingesetzten Systemd Service-Units die Definitionen der Start- und Stopskripte (ExecStart und ExecStop) entsprechend definiert sind. Weiterhin können Tomcat-Server Updates einfacher vorbereitet und durchgeführt werden, da im Anschluss an die Installation nur der symbolische Link angepasst werden muss.
| Hinweis: |
|---|
| Sollte eine Installation des Tomcat-Servers im Pfad /opt/software/tomcat/default nicht möglich sein, dann kann auch ein anderer Pfad für die Installation genutzt werden. In diesem Fall muss anschließend die Definition der Start- und Stop-Skripte in den Variablen ExecStart und ExecStop in den Systemd Service-Units entsprechend angepasst werden. |
Die folgenden Shell-Kommandos können für eine exemplarische Installation genutzt werden und müssen als User root ausgeführt werden:
export TC_VERSION=<TOMCAT_VERSION>
mkdir -p /opt/software/tomcat/
wget http://apache.mirror.digionline.de/tomcat/tomcat-8/v${TC_VERSION}/bin/apache-tomcat-${TC_VERSION}.tar.gz
tar -xfz apache-tomcat-${TC_VERSION}.tar.gz -C /opt/software/tomcat
wget http://apache.mirror.digionline.de/tomcat/tomcat-8/v${TC_VERSION}/bin/extras/catalina-jmx-remote.jar
cp catalina-jmx-remote.jar /opt/software/tomcat/apache-tomcat-${TC_VERSION}/lib
ln -s /opt/software/tomcat/apache-tomcat-${TC_VERSION} /opt/software/tomcat/default
| Hinweis: |
|---|
Die Standard Tomcat-Installation kann bei Bedarf reduziert werden, da diese einige überflüssige Komponenten/Dateien enthält. Im Einzelnen können folgende Dateien oder Verzeichnisse gelöscht werden:
|
Integration Datenbanktreiber
Weiterhin müssen im Libs-Verzeichnis des installierten Tomcat-Servers noch die Datenbanktreiber der zugrundeliegenden Datenbanken abgelegt werden. Die entsprechenden Treiber können von den Webseiten der Datenbankhersteller geladen werden. Hinweise zum Download können dem Abschnitt "Download Links" im Artikel Systemvoraussetzungen entnommen werden.
Der benötigte Treiber muss anschließend im Lib-Verzeichnis des Tomcat-Servers abgelegt werden. D.h. der Treiber muss in das Verzeichnis /opt/software/tomcat/apache-tomcat-<TOMCAT-VERSION>/lib kopiert werden.
1.2.3 Solr-Server (UPDATE: 03.06.2019)
Der GSB benötigt einen Solr-Server für den Betrieb der GSB Suchfunktionen. Details zu der benötigten Solr-Version finden sich in der Tabelle „Systemvoraussetzungen“.
Die Solr-Infrastruktur wird ähnlich zur Tomcat-Infrastruktur aufgebaut, d.h. der eigentliche Solr-Server wird auf einem System nur einmal installiert, ermöglicht aber den Start und Betrieb mehrerer GSB Solr-Instanzen. Allgemeine Hinweise zur Installation des Solr-Server finden sich auf den Webseiten des Herstellers unter "Installing Solr".
Im folgenden Unterkapitel wird eine GSB konforme Installation des Solr-Servers beschrieben.
Installation Solr-Server
In der folgenden Beschreibung zur Installation des Solr-Servers durch das vom Hersteller bereitgestellte Archiv (s.a. "Download Links") wird davon ausgegangen, dass das Archiv im /tmp-Ordner unter dem Namen solr-<SOLR_VERSION>.tgz abgelegt ist. Weiterhin muss für die Durchführung der Installation das Token <SOLR_VERSION> durch die gewünschte Solr-Version (s.a. „Systemvoraussetzungen“) ersetzt werden.
Die eigentliche Installation des Solr-Servers erfolgt im Ordner /opt/software/solr/solr-<SOLR_VERSION>. Durch Setzen eines symbolischen Links von /opt/software/solr/default auf das Installationsverzeichnis wird eine Installation bereitgestellt, die analog zur Tomcat-Server Installation durchgeführt wird. Hierdurch wird sichergestellt, dass
- der Solr-Server analog zum Tomcat-Server abgelegt ist und somit eine geleichförmige und homogene Integration der GSB Service-Instanzen in die Betriebsprozesse umgesetzt werden kann sowie
- ein einfaches Update bzw. Wechsel der Solr-Version durchgeführt werden kann.
Die Installation wird wie folgt durchgeführt:
Installation Solr-Server
export solr_version=<SOLR_VERSION>
export solr_archive=/tmp/solr-${solr_version}
export solr_install_dir=/opt/software/solr/
export solr_base=${solr_install_dir}/solr-${solr_version}
tar -xvf /tmp/${solr_archive} -C ${solr_install_dir} (1)
mkdir ${solr_base}/lib
cd ${solr_base}
cp ./contrib/analysis-extras/lib/icu4j-*.jar lib (2)
cp ./contrib/analysis-extras/lucene-libs/lucene-analyzers-icu-${solr_version}.jar lib
cp ./dist/solr-analysis-extras-${solr_version}.jar lib
ln -s /opt/software/solr/solr-${solr_version} /opt/software/solr/default (3)
# Installation jts-core Library (4)
jts_version="1.15.0"curl -k -o /opt/software/solr/default/server/solr-webapp/webapp/WEB-INF/lib/jts-core-${jts_version}.jar http://central.maven.org/maven2/org/locationtech/jts/jts-core/${jts_version}/jts-core-${jts_version}.jar
| 1 | Entpacken der Archivdatei im Installationsordner (/opt/software/solr) |
| 2 | Kopie benötigter Bibliotheken in einen zentralen Ordner (/opt/software/solr/solr-<SOLR_VERSION>/lib) |
| 3 | Anlegen eines symbolischen Links von /opt/software/solr/default auf /opt/software/solr/solr-<SOLR_VERSION> |
| 4 | Für die Umkreissuche wird eine zusätzliche Bibliothek (jts-core) benötigt, die manuell installiert werden muss (s.a. https://lucene.apache.org/solr/guide/7_7/spatial-search.html#jts-and-polygons-flat). |
1.2.4 Httpd-Server
Der Httpd-Server kann am einfachsten aus dem RPM-Repository des zugrundeliegenden Linux Betriebssystems installiert werden. Hierbei ist zu beachten, dass neben dem eigentlichen Httpd-Server noch eine Reihe von Modulen für den Betrieb des GSB Httpd-Servers benötigt wird. Die benötigten Module sind in dem Redhat RPM bis auf das optional benötigte mod_ssl enthalten, und müssen daher nicht gesondert installiert werden.
sudo yum –y install httpd
sudo yum –y install mod_ssl
ln -s /opt/gsbos/runtime/httpd/conf.d/gsbos.conf /etc/httpd/conf.d/
| Hinweis: |
|---|
RedHat und CentOS verfolgen eine relativ konservative Stragie bzgl. der Aktualisierung von in den Distributionen enthaltenen Softwarepaketen. So wird über die OS-Repositories auch eine relativ alte Version des Httpd-Webservers installiert. Das Community-Project "Inline with Upstream stable" stellt aktuelle Versionen ausgewählter Softwarepakete zur Verfügung. Hinweise zur Anbindung der IUS-Repositories finden sich auf der Seite "Getting Started", Eine aktuelle Version des Httpd-Webservers kann über die IUS-Repositories installiert weden. |
1.2.5 Optional: Manuelle Installation Httpd-Server
Wenn der Httpd-Server aus den Sourcen individuell übersetzt wird, dann werden noch weitere Dateien benötigt. Im Einzelnen handelt es sich um
- Apache Portable Runtime Module APR und APR-util (Download von https://apr.apache.org/download.cgi)
- Apache Tomcat-Connector (Download von https://tomcat.apache.org/download-connectors.cgi)
Nachdem die benötigten Sourcen in einem Build-Verzeichnis entpackt worden sind, kann der Webserver wie auf http://httpd.apache.org/docs/current/de/install.html beschrieben kompiliert und installiert werden.
Benötigte Httpd-Module
Konfiguration des GSB httpd-Servers bzw. der eingesetzten VirtualHost-Definitionen setzt wie skizziert einige Module voraus. Die Liste der benötigten Module kann aus der Datei httpd/conf/include/loadModules.conf des GSB Kerns entnommen werden. Alle Module die in dieser Datei über die LoadModule-Direktive geladen werden, müssen im httpd-Server zur Verfügung stehen.
Die Modulliste ist für die Erstellung und Installation des Httpd-Servers aus den Sourcen relevant, die diese beim Configure- und Compile-Lauf mit übergeben werden müssen. Bei Verwendung des httpd-RPMs des zugrundeliegenden Betriebssystems sollten alle benötigten Module wie skizziert bereits mitinstalliert werden.
1.2.6 Datenbanken
Der GSB unterstützt die Datenbanken MySQL und Oracle.
| Bitte beachten Sie: |
|---|
| MariaDB wird aktuell von der von uns für das GSB-Adminportal eingesetzten Liferay-Version nicht unterstützt. Wir empfehlen daher im Moment den Einsatz von MySQL, arbeiten aber an einer zukünftigen durchgängigen MariaDB-Unterstützung. |
Die Installation der eigentlichen Datenbankserver kann anhand der Installationsanleitungen der Datenbankhersteller durchgeführt werden.
MySQL Datenbank
Die Installationsanleitung der MySQL Datenbank findet sich auf der Seite https://dev.mysql.com/doc/refman/5.7/en/linux-installation.html.
Oracle Datenbank
Die Installationsanleitung der Oracle Datenbank findet sich auf der Seite https://docs.oracle.com/database/121/LADBI/toc.htm
Einrichtung GSB Datenbanken
Nachdem der Datenbank-Server installiert ist, müssen die für den Betrieb des GSB benötigten Datenbanken eingerichtet werden. Die Einrichtung der Datenbanken wird über entsprechende SQL-Skripte durchgeführt.
Die Skripte befinden sich im Infrastructure-Artefakt, im Ordner infrastructure/sql, in dem für jede unterstützte Datenbank ein Unterordner (mysql, oracle) vorhanden ist.
Für jede einzurichtende Datenbank (bzw. GSB Komponente mit Datenbankunterstützung) ist ein Unterordner vorhanden in denen Skripte zum Anlegen der benötigten Datenbank(en) abgelegt sind (create<XYZ>DB.sql).
| Hinweis: |
|---|
Bei Verwendung einer Oracle-Datenbank muss im Vorfeld noch der benötigte gsbos-Tablespace mit dem Skript createTablespace.sql angelegt werden. Der Vollständigkeit halber ist an dieser Stelle das Skript zum Anlegen des Oracle-Tablespace aufgeführt, um die Defaultwerte des exemplarischen Skriptes für die Einrichtung des Tablespace nutzen zu können. createTablespace.sql create bigfile tablespace gsbos size 500M reuse autoextend on next 100M maxsize unlimited extent management local segment space management auto; |
1.2.7 Verzeichnisdienst
Die Installation des OpenLDAP-Servers erfolgt am einfachsten über das Paket-Repository des zugrundeliegenden Linux Betriebssystems. Details zur Installation und Administration des Verzeichnisdienstes finden sich auf der Seite http://www.openldap.org/doc/admin24/.
Installation LDAP-Server
sudo yum -y install openldap-servers openldap-clients
cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG
chown ldap /var/lib/ldap/DB_CONFIG
Nach Installation des OpenLDAP-Verzeichnisdienst müssen noch einige GSB spezifische Konfigurationen, Schemamodifikationen durchgeführt werden.
Die Basiskonfiguration des OpenLDAP-Verzeichnisdienstes wird über GSB spezifische LDIF-Dateien durchgeführt. Diese finden sich im infrastructure-Artefakt, im Ordner infrastructure/ldap. Die darin enthaltenen Skripte sind durchnummeriert und müssen in der Reihenfolge der Nummerierung mit dem folgenden Kommando ausgeführt werden.
Import von LDIF-Dateien
ldapmodify -Y EXTERNAL -H ldapi:/// -f <LDIF-FILE>
Das Token <LDIF-FILE> wird durch den Pfad zur LDIF-Datei ersetzt.
Mandantenkonfiguration
Die Einrichtung der Gruppen und Benutzer eines GSB-Mandanten erfolgt ebenfalls mit dem oben aufgeführten Kommando. Die für die Einrichtung und Konfiguration der Standardlösung benötigten LDIF-Files befinden sich im Standardlösung Customer-Ordner im Verzeichnis infrastructure/ldap.
Der GSB bietet keine Möglichkeit der Verschlüsselung von Passwörtern der GSB-Nutzer an, deren Speicherung über den LDAP-Server erfolgt. Die Passwortverschlüsselung muss daher über eine geeignete Konfiguration des LDAP-Servers erfolgen!
1.2.8 Runtime-Konfiguration
Die Runtime-Konfiguration der einzelnen GSB Service-Instanzen muss individuell für jede einzelne Instanz bereitgestellt werden. Der GSB Kern liefert eine exemplarische Runtime-Konfiguration die als Grundlage für die individuelle Erstellung der Runtime-Konfiguration genutzt werden kann.
Die Runtime-Konfigurationen der Service-Instanzen eines Systems werden im Ordner /opt/gsbos/runtime abgelegt. Für jede einzelne Service-Instanz existiert ein Unterordner, in dem die Service-Instanz spezifischen Konfigurationen abgelegt wird.
Der GSB Kern enthält Runtime-Konfigurationen für eine exemplarische GSB Infrastruktur, die als Grundlage für den Aufbau einer individuellen GSB Infrastruktur genutzt werden kann. Diese findet sich im infrastructure-Artefakt im Ordner infrastructure/runtime. Details zum Aufbau und Inhalt der Runtime-Konfiguration finden sich auf den Seiten zur Runtime-Konfiguration.
Der GSB stützt sich auf Httpd- und Tomcat-Server basierte Service-Instanzen, deren Konfigurationsschema im Folgenden vorgestellt wird.
1.2.9 Httpd-Server
Die Runtime-Konfiguration des Httpd-Servers umfasst ausschließlich die Balancer-Definitionen für die Anbindung der Tomcat-Server. Für jede logische Zone (live, preview, service) sind in der Vorlage entsprechende Balancer-Konfigurationen enthalten, die individuell anzupassen sind.
Die exemplarische Konfiguration des Live-Balancers (Datei infrastructure/runtime/live/balancer_live.conf) sieht wie folgt aus:
Webserver Balancer-Definition
# Setzen der Balancer Mitglieder,
# zum deaktivieren bitte auskommentieren,
# zum erweitern bitte eine BalancerMember Zeile kopieren und anpassen
<Proxy balancer://balancerlive>
BalancerMember ajp://delivery1.master.example.com:7109 route=delivery1-master
BalancerMember ajp://delivery2.master.example.com:7119 route=delivery2-master
BalancerMember ajp://delivery1.replication.example.com:8109 route=delivery1-replication
BalancerMember ajp://delivery2.replication.example.com:8119 route=delivery2-replication
ProxySet nofailover=off
ProxySet stickysession=JSESSIONID
</Proxy>
Der Live-Balancer besteht also aus vier Tomcats, die vom Httpd-Server eingebunden werden. Die Balancer-Member (=Tomcat-Server) sind jeweils unter einem dedizierten Namen und Port (Namen delivery[1|2].(master|replication).example.com, Ports: 7109… 8119) erreichbar. Für jeden Balancer-Member muss ein eindeutiger Name definiert werden, damit das Routing der Requests vom Httpd-Server „sticky“ erfolgen kann, d.h. nachfolgende Requests eines Browsers sollen immer an denselben Tomcat-Server weitergeleitet werden.
1.2.10 Tomcat-Server
Die Runtime-Konfiguration der Tomcat-Service-Instanzen umfasst
- Tomcat-Properties: Diese Properties werden für die Konfiguration des Tomcat-Servers benötigt
- Webapp-Properties: Für jede Webapplikation die in einem Tomcat betrieben wird ist ein applikationsspezifischer Satz von Properties vorhanden.
Der Aufbau der Runtime-Konfiguration einer Tomcat-Service-Instanz sieht damit am Beispiel der Instanz delivery1-master wie folgt aus:
- delivery1-master
- tomcat
- env
- properties
- webapps
- site
- properties
- tomcat
Die Datei tomcat.env enthält mit der Variablendefinition CATALINA_OPTS alle instanzspezfischen Konfigurationen wie bspw. Memory-, Garbage-Collection-Settings.
Die Datei tomcat.properties enthält alle Properties die für die Tomcat-Konfiguration benötigt werden. Die zentralen anzupassenden Properties sind die hostname, port und jvmRoute-Properties (s.a. Auszug der Properties-Datei):
Auszug Tomcat-Runtime-Properties
tomcat.server.hostname=delivery.master.example.com
tomcat.server.port=7105
tomcat.server.shutdown=AGkkv,aSL!
tomcat.server.jvmRoute=delivery1-master
# Konfiguration Tomcat HTTP
tomcat.server.http.port=7101
# Konfiguration Tomcat AJP
tomcat.server.ajp.port=7109
# Konfiguration Tomcat JMX Remote Lifecycle Listener. Definiert die Ports fuer
# JMX/RMI Server Verbindung von Clients hinter einer Firewall
tomcat.server.jmxRemoteLifecycleListener.rmiRegistryPortPlatform=7103
tomcat.server.jmxRemoteLifecycleListener.rmiServerPortPlatform=7104
Die Properties Dateien der einzelnen Webapplikationen (im Beispiel delivery1-master/webapps/site/site.properties) sind individuell für die einzelnen Webapplikationen, so dass diese an dieser Stelle keine exemplarischen Beispiele vorgestellt werden können. Die wesentlichen Anpassungen in den webapplikationsspezifischen Properties betreffen Servernamen sowie Ports.
1.2.11 Solr-Server
Der GSB 10 nutzt eine aktuelle Solr Version, die ausschließlich als Standalone Applikation betrieben werden kann. Ein Betrieb als Webapplikation in einem Tomcat-Server ist nicht mehr möglich. Der Aufbau der Solr-Runtimekonfiguration weicht somit von dem der anderen Service-Instanzen ab. Die Runtime-Konfiguration der Solr-Service-Instanzen umfasst
- Portdefinitionen für den Zugriff auf die Solr-Service-Instanz
- Homeverzeichnis der GSB Solr-Installation
Der Aufbau der Runtime-Konfiguration einer Solr-Service-Instanz sieht damit am Beispiel der Instanz solr-replication wie folgt aus:
solr-replication
- env
Die Datei env.env enthält alle Properties, die für die Solr-Konfiguration des Replication-Servers benötigt werden.
Auszug Solr-Runtime-Properties
SOLR_CONFIGSETS_DIR=/opt/gsbos/software/solr/configsets
SOLR_HOME=/opt/gsbos/software/solr/replication
SOLR_SHARED_LIB_DIR=/opt/software/solr/default/lib
SOLR_RMI_PORT=8403
# Sets the port Solr binds to, default is 8983
SOLR_PORT=8401
# Sets the port Solr binds to stop the server
SOLR_STOP_PORT=8405
# Solr-Replication-Configuration
# s.a.: http://lucene.apache.org/solr/guide/7_2/index-replication.html#configuring-the-replication-requesthandler-on-a-slave-server
SOLR_MASTER_HOST=solr.master.example.com
SOLR_MASTER_PORT=7401
SOLR_REPLICATION_INTERVAL=00:00:20
1.2.12 Host-Datei
Die in der exemplarischen Beispielkonfiguration/Infrastruktur verwendeten Hostnamen finden sich im Kernrelease im infrastructure-Artefakt im Verzeichnis infrastructure/etc und kann als Grundlage für die Erstellung der plattformspezifischen Hostdateien genutzt werden.
Die exemplarische Host-Datei enthält alle Servernamen, die in der exemplarischen Runtime-Konfiguration verwendet werden.
1.2.13 Hinweis zu MimeTypes
Die im GSB-Kern enthaltene Datei "DefaultMimeTypes.properties" enthält die Definition der in der Site-Applikation unterstützten/bekannten MimeTypes. Dieses Mapping kann nicht durch Ablage zusätzlicher Mapping-Dateien erweitert werden.
Um fehlende Mappings in einer Installation zu ergänzen bietet sich folgendes Vorgehen an.
- Kopie der DefaultMimeTypes.properties aus dem Kern und Ablage in einem GSB 10 Mandanten im Pfad site/src/main/resources/de/bund/gsb/site/util/DefaultMimeTypes.properties
- Erweiterung der Kopie um die benötigten Mappings
Bei der Erstellung eines Mandantenrelease wird diese Datei mit in das Mandantenrelease integriert. Da bei der Erstellung des Plattformbundle zunächst der Kern und anschließend die Mandanten in das Bundle integriert werden, wird die Definition aus dem Kern mit der im Mandanten erweiterten Definition überschrieben. Damit stehen nach der Installation des Bundle dann auch zusätzlich definierten Mappings in der Site zur Verfügung.
2 Benutzer
Die Installation des GSB und der GSB Komponenten erfolgt durch einen gsbos-Benutzer der auf den Servern eingerichtet werden muss. Der Nutzer ist wie folgt anzulegen:
Tabelle 1: gsbos-Benutzer
| Parameter | Wert |
|---|---|
| LOGIN | gsbos |
| GROUP | gsbos |
| HOME_DIR | /home/gsbos |
| SHELL | /bin/bash |
3 Verzeichnisse
Die folgende Beschreibung geht davon aus, dass die GSB Komponenten als Benutzer „gsbos“ installiert werden. Für die Vorbereitung und Durchführung der Installation werden die folgenden Verzeichnisse benötigt:
Tabelle 2. Benötigte Verzeichnisse
| Verzeichnis | Inhalt |
|---|---|
| /home/gsbos/config | Enthält die zu verwendende Konfiguration für die Installation des GSB. Da der Standard-Benutzer für die Installation „gsbos“ ist, ist der Default-Pfad somit „/home/gsbos/config“ |
| /home/gsbos/releases/core | Basisverzeichnis für die Ablage der GSB Kernreleases. Unterhalb dieses Verzeichnisses muss für jedes auf der Plattform vorhandene Kernrelease ein (Versions-)Unterverzeichnis angelegt werden in dem das jeweilige Kernrelease abgelegt wird. |
| /home/gsbos/releases/customers | Basisverzeichnis für die auf der Plattform gehosteten GSB-Mandanten. Jeder Mandant wird in einem dedizierten Unterverzeichnis verwaltet. Unterschiedliche Mandantenversionen werden in einem entsprechenden Versionsordner abgelegt. Der Unterordner …/customers/standardlsg/1.0.0 beinhaltet bspw. die Version 1.0.0 der Standardlösung. |
| /home/gsbos/platformBundle | Die auf der Hostingplattform erstellten und benötigten Platform-Bundles werden in diesem Verzeichnis abgelegt. |
| /home/gsbos/patches | Verzeichnis mit Patches, welche beim Erstellen des Platform-Bundles eingespielt werden sollen. |
| /opt/gsbos | Installationsverzeichnis der GSB Komponenten. |
| /opt/gsbos/runtime | Runtime-Konfigurationen der einzelnen GSB Komponenten werden in diesem Verzeichnis bereitgestellt. |
Die Vorlagendateien und Beispielkonfigurationen gehen davon aus, dass der Tomcat-Server unter /opt/software/tomcat/default installiert ist. Ist dies nicht der Fall, dann sollte durch den Systembetrieb ein entsprechender symbolischer Link angelegt werden.
Das für die Installation zu verwende Release wird nach der oben definierten Struktur somit in /home/gsbos/releases/core/10.0.0 und /home/gsbos/releases/customers abgelegt werden.
4 Erstellung des Platform-Bundles
Die Installation des GSB auf einer produktiven Infrastruktur erfolgt mittels eines Platform-Bundles. Für die Erstellung eines Platform-Bundles werden Konfigurations-Dateien und ein Shell-Skript zur Erzeugung des Platform-Bundles benötigt. Ein PlatformBundle ist eine GSBOS Lieferung angepasst an eine definierte Plattform. Dabei wird über Konfigurationsdateien die zu erstellende Lieferung beschrieben. Zum Erstellen eines Platform-Bundles wird das Skript platformBundle.sh verwendet.
Hinweise:
Beim Entpacken des Release können vorab vergebene Lese-, Schreib- oder Ausführrechte verloren gehen. Bitte beachten Sie daher folgende Rechtevergabe:
| Ordner | Rechte |
|---|---|
| /opt/gsbos/runtime/ | rwxrwxr-x |
| /opt/gsbos/software/ | rwxrwxr-x |
Die Shellskripte für die Erzeugung des Platform-Bundles sowie Installation erfordert die Ausführung in einer Bash Version 4.x.
4.1 Konfigurationsdateien
Um eine Lieferung zu erstellen werden drei Konfigurationsdateien benötigt
• gsbos_global.cfg
• serviceTypes.cfg
• platformBundle.cfg
| Hinweis: |
|---|
|
Im folgenden werden die drei Konfigurationsdateien beschrieben.
4.2 gsbos_global.cfg
Im folgenden wird die Konfigurationsdatei gsbos_global.cfg beschrieben.
4.2.1 Beschreibung
Diese Konfigurationsdatei wird für folgende Punkte benötigt:
- Globale Konfiguration des GSB/OS
Die Konfigurationsdatei wird mit jedem GSB/OS Release ausgeliefert und befindet sich im infrastructure-Verzeichnis des Kerns (core).
Pfad: ~gsbos/releases/core/10.0.0/infrastructure/platform/conf/
Diese Datei sollte in ein zentrales Konfigurationsverzeichnis kopiert werden.
cp ~gsbos/releases/core/10.0.0/infrastructure/platform/conf/gsbos_global.cfg ~gsbos/config/
Danach kann diese an die Plattform angepasst werden.
4.2.2 Konfiguration
In den folgenden Abschnitten werden die Parameter der Konfigurationsdatei beschrieben.
###############################################################################
# GSB/OS-Folder
###############################################################################
# Home-Verzeichnis des GSB/OS Benutzer
gsbos_base_dir="/home/gsbos"
# Zielverzeichnis der Installation
gsbos_install_dir="/opt/gsbos/software"
# Zielverzeichnis der Persistenten Daten (z.B. Log-Dateien)
gsbos_data_dir="/space/gsbos/data"
###############################################################################
# GSB/OS-User
###############################################################################
# Benutzername des GSB/OS Benutzer
gsbos_user=gsbos
# Gruppename des GSB/OS Benutzer
gsbos_group=gsbos
###############################################################################
# Do not touch
###############################################################################
# Pfad zum GSB/OS Kern
gsbos_core_base_dir="${gsbos_base_dir}/releases/core"
# Pfad zu den Mandanten
gsbos_customers_base_dir="${gsbos_base_dir}/releases/customers"
# Pfad zur Ablage der PlatformBundle
platform_bundle_dir="${gsbos_base_dir}/platformBundle"
# Pfad zur Ablage der Patche
patch_base_dir="${gsbos_base_dir}/patches"
4.3 serviceTypes.cfg
Im folgenden wird die Konfigurationsdatei serviceTypes.cfg beschrieben.
4.3.1 Beschreibung
Diese Konfigurationsdatei wird für folgende Punkte benötigt:
- Definieren der Service-Typen
Ein Service-Typ beinhaltet eine Liste von Artefakten die bei der Erstellung des Platform-Bundle für die Assemblierung des Service-Typ-Artefakts genutzt werden.
Die Konfigurationsdatei wird mit jedem GSB/OS Release ausgeliefert und befindet sich im infrastructure-Verzeichnis des Kerns (core).
| ~gsbos/releases/core/10.0.0/infrastructure/platform/conf/ |
Diese Datei sollte in ein zentrales Konfigurationsverzeichnis kopiert werden.
cp ~gsbos/releases/core/10.0.0/infrastructure/platform/conf/serviceTypes.cfg ~gsbos/config/
Danach kann diese an die Plattform angepasst werden.
4.3.2 Konfiguration
In den folgenden Abschnitten werden die Parameter der Konfigurationsdatei beschrieben.
| Wenn die Namen der Service-Typen angepasst werden, müssen diese auch in anderen Konfigurationsschritten angepasst werden (z.B. Systemd-Unit) | |
| Wird die Liste der Komponenten eines Service-Typ angepasst, so muss auch die Runtime entsprechend abgelegt werden |
declare -g -A gsbos_serviceTypes
###############################################################################
# Globale Service-Typen (Redaktions- und Live-Umgebung)
###############################################################################
# Beschreibt die Komponenten des ServiceType *service*
gsbos_serviceTypes[service]="tomcat indexer eventdispatcher"
# Beschreibt die Komponenten des ServiceType *repository*
gsbos_serviceTypes[repository]="tomcat repository replication"
# Beschreibt die Komponenten des ServiceType *delivery*
gsbos_serviceTypes[delivery]="tomcat site"
# Beschreibt die Komponenten des ServiceType *solr*
gsbos_serviceTypes[solr]="solr"
###############################################################################
# Preview Service-Typen (Redaktionsumgebung)
###############################################################################
# Beschreibt die Komponenten des ServiceType *workflow*
gsbos_serviceTypes[workflow]="tomcat workflow"
# Beschreibt die Komponenten des ServiceType *editor*
gsbos_serviceTypes[editor]="tomcat editor"
###############################################################################
# Service Service-Typen (Service-Umgebung)
###############################################################################
# Beschreibt die Komponenten des ServiceType *adminportal*
gsbos_serviceTypes[adminportal]="tomcat liferay adminportal serviceportal"
# Beschreibt die Komponenten des ServiceType *maildistributor*
gsbos_serviceTypes[maildistributor]="tomcat maildistributor"
# Beschreibt die Komponenten des ServiceType *cas*
gsbos_serviceTypes[cas]="tomcat cas"
###############################################################################
# HTTPD
###############################################################################
# Beschreibt die Komponenten des ServiceType *httpd*
gsbos_serviceTypes[httpd]="httpd"
4.4 platformBundle.cfg
Im folgenden wird die Konfigurationsdatei platformBundle.cfg beschrieben.
4.4.1 Beschreibung
Diese Konfigurationsdatei wird für folgende Punkte benötigt:
- Beschreibung des Platform-Bundles
Die Konfigurationsdatei wird mit jedem GSB/OS Release ausgeliefert und befindet sich im infrastructure-Verzeichnis des Kerns (core).
| ~gsbos/releases/core/10.0.0/infrastructure/platform/conf/ |
Diese Datei sollte in ein zentrales Konfigurationsverzeichnis kopiert werden.
cp ~gsbos/releases/core/10.0.0/infrastructure/platformBundle/platformBundle.cfg ~gsbos/config/
Danach kann diese an die Plattform angepasst werden.
4.4.2 Konfiguration
In den folgenden Abschnitten werden die Parameter der Konfigurationsdatei beschrieben.
###############################################################################
# Platform Definition
###############################################################################
# Name der Plattform/des PlatformBundle
platform_name=showcase
# Version der Plattform/des PlatformBundle
platform_version=1.0
# Version des zu verwendenden Kern
gsbos_core_version=<CORE_VERSION> (4)
# Liste der Mandanten und deren Version
customers=(
<CUSTOMER1_NAME>:<CUSTOMER1_VERSION> (1)
<CUSTOMER2_NAME>:<CUSTOMER2_VERSION> (2)
<CUSTOMER3_NAME>:<CUSTOMER3_VERSION> (3)
)
###############################################################################
# Patch Definition (Optional)
###############################################################################
# Liste der Core-Patches
core_patches=(
# PATCH-FILE-NAME
)
# Liste der Customer-Patches
#customer_patches[standardlsg]="PATCH-FILE-NAME"
| 1 | Die Token <CUSTOMER1_NAME> und <CUSTOMER1_VERSION> müssen durch den Namen und die Version des ersten Mandanten ersetzt werden. |
| 2 | Die Token <CUSTOMER2_NAME> und <CUSTOMER2_VERSION> müssen durch den Namen und die Version des zweiten Mandanten ersetzt werden. |
| 3 | Die Token <CUSTOMER3_NAME> und <CUSTOMER3_VERSION> müssen durch den Namen und die Version des dritten Mandanten ersetzt werden. |
| 4 | Das Token <CORE_VERSION> muss durch die genutzte Core-Version ersetzt werden. |
| Sollte das Plattformbundle nur einen Mandanten beinhalten dann müssen die im obigen Beispiel enthaltenen Definitionen für CUSTOMER2 und CUSTOMER3 gelöscht werden. |
4.5 Verwendung
Bevor das Skript verwendet werden kann, muss es ausführbar sein.
chmod +x platformBundle.sh
| Um das Skript einfacher auszuführen zu können sollte es in ein Verzechnis kopiert werden, welches in der PATH Variable includiert wird/ist. |
Das Skript kann mit folgenden Parametern ausgeführt werden:
-c Angabe des Pfad zum Konfigurationsverzechnis
- Standardwert: ~gsbos/config/
-f Überschreiben des PlatformBundle, falls dieses bereits existiert
- Standardwert: -
- -h Hilfe (usage) des Skript
4.5.1 Vorgehen zur Erstellung
Nachdem die oben beschriebenen Konfigurationen auf die jeweilige Hostingplattform angepasst wurden, wird das Platform-Bundle mit dem folgenden Script erzeugt:
/home/gsbos/releases/core/{revnumber}/infrastructure/platform/scripts/platformBundle.sh
Im einfachsten Fall wird dieses ohne Parameter direkt aufgerufen:
./platformBundle.sh
Dieses sucht unter ${HOME}/config die zu verwendende Konfiguration und erstellt das Platform-Bundle im Verzeichnis:
/home/gsbos/platformBundle/{platform_name}/{platform_version}/
Für den Fall, dass die Installations-Konfiguration aus einem anderen Verzeichnis, als ${HOME}/config, verwendet werden soll, kann dies über den Parameter -c definiert werden:
./platformBundle.sh –c /home/gsbos/gsbos/config
Vor der Erstellung des Platform-Bundles wird geprüft, ob bereits ein entsprechendes Bundle mit dem Namen und derselben Versionsnummer existiert. Sollte dies der Fall sein, wird die Erstellung des Bundles abgebrochen.
Durch die Verwendung des Force-Parameters -f kann die Erstellung des Platform-Bundles erzwungen werden. In diesem Fall wird ein evtl. vorhandenes Platform-Bundle überschrieben.
5 Installation des Platform-Bundles
Das Skript install-gsbos.sh wird zum Installieren des PlatformBundle benötigt. Ein PlatformBundle ist eine GSBOS Lieferung angepasst an eine definierte Plattform. Dabei wird über Konfigurationsdateien das zu installierende PlatformBundle definiert.
5.1 Konfigurationsdateien
Um ein PlatformBundle zu installieren werden zwei Konfigurationsdateien benötigt.
- gsbos_global.cfg
- platformBundle.cfg
| Die zwei Konfigurationsdateien müssen in einem Verzeichnis liegen. | |
| Das Standardverzeichnis ist ~gsbos/config. |
Im folgenden werden die zwei Konfigurationsdateien beschrieben.
5.2 gsbos_global.cfg
Im folgenden wird die Konfigurationsdatei gsbos_global.cfg beschrieben.
5.2.1 Beschreibung
Diese Konfigurationsdatei wird für folgende Punkte benötigt:
- Globale Konfiguration des GSB/OS
Die Konfigurationsdatei wird mit jedem GSB/OS Release ausgeliefert und befindet sich im infrastructure-Verzeichnis des Kerns (core).
| ~gsbos/releases/core/10.0.0/infrastructure/platform/conf/ |
Diese Datei sollte in ein zentrales Konfigurationsverzeichnis kopiert werden.
cp ~gsbos/releases/core/10.0.0/infrastructure/platform/conf/gsbos_global.cfg ~gsbos/config/
Danach kann diese an die Plattform angepasst werden.
5.2.2 Konfiguration
In den folgenden Abschnitten werden die Parameter der Konfigurationsdatei beschrieben.
###############################################################################
# GSB/OS-Folder
###############################################################################
# Home-Verzeichnis des GSB/OS Benutzer
gsbos_base_dir="/home/gsbos"
# Zielverzeichnis der Installation
gsbos_install_dir="/opt/gsbos/software"
# Zielverzeichnis der Persistenten Daten (z.B. Log-Dateien)
gsbos_data_dir="/space/gsbos/data"
###############################################################################
# GSB/OS-User
###############################################################################
# Benutzername des GSB/OS Benutzer
gsbos_user=gsbos
# Gruppename des GSB/OS Benutzer
gsbos_group=gsbos
###############################################################################
# Do not touch
###############################################################################
# Pfad zum GSB/OS Kern
gsbos_core_base_dir="${gsbos_base_dir}/releases/core"
# Pfad zu den Mandanten
gsbos_customers_base_dir="${gsbos_base_dir}/releases/customers"
# Pfad zur Ablage der PlatformBundle
platform_bundle_dir="${gsbos_base_dir}/platformBundle"
# Pfad zur Ablage der Patche
patch_base_dir="${gsbos_base_dir}/patches"
5.3 platformBundle.cfg
Im folgenden wird die Konfigurationsdatei platformBundle.cfg beschrieben.
5.3.1 Beschreibung
Diese Konfigurationsdatei wird für folgende Punkte benötigt:
- Beschreibung des Platform-Bundles
Die Konfigurationsdatei wird mit jedem GSB/OS Release ausgeliefert und befindet sich im infrastructure-Verzeichnis des Kerns (core).
| ~gsbos/releases/core/10.0.0/infrastructure/platform/conf/ |
Diese Datei sollte in ein zentrales Konfigurationsverzeichnis kopiert werden.
cp ~gsbos/releases/core/10.0.0/infrastructure/platformBundle/platformBundle.cfg ~gsbos/config/
Danach kann diese an die Plattform angepasst werden.
5.3.2 Konfiguration
In den folgenden Abschnitten werden die Parameter der Konfigurationsdatei beschrieben.
###############################################################################
# Platform Definition
###############################################################################
# Name der Plattform/des PlatformBundle
platform_name=showcase
# Version der Plattform/des PlatformBundle
platform_version=1.0
# Version des zu verwendenden Kern
gsbos_core_version=<CORE_VERSION> (4)
# Liste der Mandanten und deren Version
customers=(
<CUSTOMER1_NAME>:<CUSTOMER1_VERSION> (1)
<CUSTOMER2_NAME>:<CUSTOMER2_VERSION> (2)
<CUSTOMER3_NAME>:<CUSTOMER3_VERSION> (3)
)
###############################################################################
# Patch Definition (Optional)
###############################################################################
# Liste der Core-Patches
core_patches=(
# PATCH-FILE-NAME
)
# Liste der Customer-Patches
#customer_patches[standardlsg]="PATCH-FILE-NAME"
| 1 | Die Token <CUSTOMER1_NAME> und <CUSTOMER1_VERSION> müssen durch den Namen und die Version des ersten Mandanten ersetzt werden. |
| 2 | Die Token <CUSTOMER2_NAME> und <CUSTOMER2_VERSION> müssen durch den Namen und die Version des zweiten Mandanten ersetzt werden. |
| 3 | Die Token <CUSTOMER3_NAME> und <CUSTOMER3_VERSION> müssen durch den Namen und die Version des dritten Mandanten ersetzt werden. |
| 4 | Das Token <CORE_VERSION> muss durch die genutzte Core-Version ersetzt werden. |
| Sollte das Plattformbundle nur einen Mandanten beinhalten dann müssen die im obigen Beispiel enthaltenen Definitionen für CUSTOMER2 und CUSTOMER3 gelöscht werden. |
5.4 Verwendung
Bevor das Skript verwendet werden kann, muss es ausführbar sein.
chmod +x install-gsbos.sh
| Um das Skript einfacher auszuführen zu können sollte es in ein Verzechnis kopiert werden, welches in der PATH Variable includiert wird/ist. |
Das Skript kann mit folgenden Parametern ausgeführt werden:
-c Angabe des Pfad zum Konfigurationsverzechnis
- Standardwert: ~gsbos/config/
-t Angabe expliziter Service-Types (z.B. um nur die Delivery neu zu installieren)
- Standardwert: - (verwendet alle)
- -h Hilfe (usage) des Skript
5.5 Vorgehen zur Installation
Nachdem das Platform-Bundle und somit die gewünschten Service-Typen erstellt wurden, können diese installiert werden. Dies wird mit dem folgenden Script durchgeführt:
/home/gsbos/releases/core/{revnumber}/infrastructure/platform/scripts/install-gsbos.sh
Bei Verwendung der Standardpfade muss dem Script als Parameter nur die Liste der gewünschten Service-Typen mitgegeben werden:
./install-gsbos.sh -t <SERVICE-TYP>
Wie beim Erstellen des Plattform-Bundles kann auch diesem Script über den -c Parameter mitgeteilt werden, welche Konfiguration verwendet werden soll:
./install-gsbos.sh –c /home/gsbos/config -t <SERVICE-TYP>
6 Mandant Import
Nach der Installation und dem Starten der Komponenten muss der Content der gehosteten Mandanten in das Redaktions-Repository importiert und die Rechtedefinition des Mandanten eingespielt werden.
6.1 Mandanten Content Import
Dazu muss der Content eines Mandanten welcher im Ordner content in zwei Zip-Dateien abgelegt ist in das Repository importiert werden.
content.zipenthält den redaktionellen Content des Mandanteneditor.zipenthält die Mandantenkonfiguration des Editors
Auf dieser Maschine wird der Content des Mandanten über die Importer-Schnittstelle des Redaktions-Repository eingespielt.
Content Import
curl –F „file=@<FILENAME>.zip“ http://repository.preview.example.com:6001/repository/content/importer/zip/execute
Der Import läuft synchron ab. Das heißt, dass der Aufruf des Konsolenbefehls erst beendet wird, nachdem der Import abgeschlossen ist. Der Status des Imports kann im Log des Redaktions-Repositorys überprüft werden. Diese ist unter dem Pfad /space/gsbos/data/repository-preview/logs zu finden:
Soll der Content des Mandanten nach dem Import direkt publiziert werden, kann als zusätzlicher Parameter publish=true ergänzt werden. Der folgende Aufruf führt einem Import mit anschließender Publikation durch.
Content Import mit Publikation
curl -F "file=@<FILENAME>.zip" -F "publish=true" http://repository.example.com:6001/repository/content/importer/zip/execute
6.2 Benutzer- und Gruppen Einspielung
Die Benutzer und Gruppen eines Mandanten werden in einem LDAP gepflegt. Innerhalb eines Release liegen sie in Form eines LDAP Exports, eines sogenannten „ldif“, vor.
Im Release ist dieser LDAP Export im Verzeichnis infrastructure/ldap. Die folgenden ldif-Dateien sind Bestandteil eines GSB Mandanten:
- <MANDANT>.ldif enthält die Benutzer- und Gruppendefinitionen für Redakteure und SiteAdminisstratoren
- <MANDANT>-adminportal.ldif enthält Benutzer- und Gruppendefinitionen für das Adminportal
Das Einspielen der Benutzer und Gruppen erfolgt über den LDAP-Befehl ldapadd.
LDAP Benutzer- und Gruppenimport
ldapadd -v -x -D cn=Manager,dc=example,dc=com -w secret -f <FILENAME>.ldif
Hierbei muss statt secret das Password des LDAP-Managers eingetragen werden.
6.3 Mandanten Rechtedefinition Einspielung
Nach dem erfolgreichen Import des Contents des Mandanten, muss die Rechtedefinition in das Redaktions-Repository eingespielt werden.
Dieses ist Teil des Mandanten-Release und ist dort unter folgendem Pfad zu finden: * infrastructure/security/preview/security-ldap.xml
Zum Einspielen der Rechtedefinition wird folgender Konsolenbefehl verwendet:
Einspielung Repository Berechtigungen
curl --noproxy localhost -F "jcrxml=@security-ldap.xml" -F "jcrname=standardlsg" http://repository.preview.example.com:6001/repository/security
Der Befehl beinhaltet zwei Parameter:
- jcrxml Dateiname der Rechtedefinition
- jcrname Name des Mandanten. In dem oben genannten Beispiel ist dies der Mandant „standardlsg“.