Zielgruppe BetriebVersion: GSB10.1Installationsanleitung – Schritt für Schritt

Diese beispielhafte Installationsanleitung führt Schritt für Schritt durch eine Installation eines GSB 10.1 auf einem einzelnen Server.

Grundlage der Beispiel-Installation ist ein virtualisierter Linux-Server mit CentOS Release 7.6. Weiterhin wurden statt der kommerziellen Datenbank MySQL 8.0 die dazu kompatible lizenzkostenfreie Datenbank MariaDB in der Version 10.3 verwendet. Besonderheiten, die sich aus dem Betriebssystem bzw. der Datenbanksoftware ergeben, werden im Folgenden mit CentOS bzw. MariaDB markiert.

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.

Die Installation erfolgt bis auf die Installation des eigentlichen GSB durchgehend als User root. Falls dies nicht möglich ist, müssen die Kommandos mittels sudo […] bei entsprechender Berechtigung ausgeführt werden.

Hinweis zum Einsatz von MySQL:
Die MariaDB-Datenbank-Skripte sind auf MySQL übertragbar. Spezielle Policies / DB-spezifische Einstellungen sind bei der Installation / Bereitstellung der Datenbank entsprechend zu berücksichtigen. Bitte beachten Sie auch: 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.

Hinweis zum Einsatz von MySQL:

Die MariaDB-Datenbank-Skripte sind auf MySQL übertragbar. Spezielle Policies / DB-spezifische Einstellungen sind bei der Installation / Bereitstellung der Datenbank entsprechend zu berücksichtigen.

Bitte beachten Sie auch: 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.

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.

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.

Beistellungen

Eine GSB Hosting Plattform setzte eine Reihe von Beistellungen voraus, die im Folgenden kurz vorgestellt werden.

Java

Die Tomcat-Server basierten und auch die Standalone- und Solr Service-Instanzen benötigen eine Java-Runtime Installation. Details zu den unterstützten Java-Versionen finden sich im Kapitel „Eingesetzte Softwareversionen“. Die Java-Installation wird auf Basis des OpenJDK durchgeführt. Die weitere Installationsanleitung stützt sich auf die für die Installation genutzten Pfade und Konventionen. Die im GSB Kernrelease enthaltenen Konfigurationen setzen ebenfalls eine „Standard-Installation“ voraus.

Details zur Installation finden sich im Kapitel „Java“.

Tomcat-Server

Der Tomcat-Server muss durch den Systembetrieb auf allen Servern installiert werden, auf denen Tomcat-Server basierte Service-Instanzen betrieben werden sollen. Pro Server ist nur eine zentrale Tomcat-Server Installation erforderlich. Zusätzlich werden in der Tomcat-Server Installation noch die Datenbanktreiber und ggf. Hosting Plattformspezifisch benötigte Bibliotheken im Tomcat-Server libs-Ordner abgelegt.

Details zur Installation finden sich im Kapitel „Tomcat-Server“.

Solr-Server

Der GSB nutzt für die Bereitstellung der Suchfunktionalität Solr 7. Diese Version steht nicht mehr als Webapplikation zur Verfügung, so dass die für den Betrieb einer GSB Infrastruktur benötigten Solr-Server nicht mehr in einem Tomcat-Server betrieben werden können. Der Solr-Server wird seitens des Herstellers ausschließlich als Standalone Applikation bereitgestellt.

Der Solr-Server muss ähnlich wie der Tomcat-Server auch in der Infrastruktur bereitgestellt werden.

Details zur Installation finden sich im Kapitel „Solr-Server“.

Httpd-Server

Der httpd-Server kann über die Standard RPM-Repository des zugrundeliegenden Betriebssystems installiert werden. Das httpd-RPM enthält bereits alle für den Betrieb des GSB Apache benötigten Module, so dass an dieser Stelle keine zusätzlichen Module mit installiert werden müssen.

Üblicherweise wird auf einer Hosting Plattform eine SSL-Terminierung durch einen vorgeschalteten Load Balancer durchgeführt. Wenn kein Load Balancer zur Verfügung steht, muss zusätzlich das Modul mod_ssl installiert werden, um eine SSL-Terminierung durch den httpd-Server bereitstellen zu können. Das Release enthält einen GSB „Pseudocustomer“ https, der eine exemplarische httpd-Konfiguration für die https-Terminierung enthält (VirtualHost-Definitionen, SSL-Zertifikat für *example.com).

Details zur Einbindung der GSB spezifischen Webserver-Konfiguration finden sich im Kapitel “Httpd-Server“.

Datenbanken

Die für den Betrieb des GSB benötigten Datenbanken werden auf einem Datenbankserver installiert, der als Beistellung durch den System- bzw. Datenbankbetrieb in der Infrastruktur zur Verfügung stehen muss. Details zu den unterstützten Datenbanken und Versionen finden sich im Kapitel "Eingesetzte Softwareversionen“. Der GSB Kern stellt SQL-Skripte zur Einrichtung und Initialisierung der Datenbanken zur Verfügung.

Details zur Einrichtung und Initialisierung der benötigten Datenbanken finden sich im Kapitel „Datenbanken“.

Exemplarische Konfiguration

Der GSB enthält eine exemplarische Beispielkonfiguration aller GSB-Komponenten, die für den Aufbau einer GSB Infrastruktur benötigt werden. Diese Beispielkonfiguration ist so angelegt, dass

Ein Betrieb aller Komponenten auf einem Server grundsätzlich möglich ist sowie
Eine ausfallsichere und redundante Auslieferung der Live-Auftritte unterstützt wird.

D.h. die benötigten GSB Services sind von Ihren Servernamen und benötigten Ports überlappungsfrei definiert, so dass ein gleichzeitiger Betrieb auf einem Server möglich ist. Weiterhin sind die Komponenten der Live-Auslieferung mehrfach vorhanden, so dass auf dieser Basis einfach der Aufbau einer skalierbaren und redundanten Hosting Plattform abgeleitet werden kann.

Der Aufbau der exemplarischen Beispielkonfiguration wird in den folgenden Kapiteln näher beschrieben.

Domainnamen und Zonen

Die exemplarische Beispielkonfiguration nutzt die Domain example.com, d.h. alle Domain und auch Servernamen sind Bestandteil der für Testzwecke zu verwendenden Domain example.com.

Für die weitere Strukturierung und Verteilung der einzelnen GSB Services in unterschiedliche Zonen werden Subdomains verwendet. Im Einzelnen werden für die Beispielkonfiguration die folgenden Subdomains genutzt:

preview.example.com enthält alle GSB Services des Redaktionssystems wie Content-, Workflowserver, Editor, Preview, Solr.
master.example.com ist Bestandteil der Live-Umgebung und enthält alle Services der Liveauslieferung. Das Master-Contentrepository nimmt hierbei die zentrale Rolle ein, da publizierte Inhalte in dieses Repository publiziert werden.
replication.example.com ist ebenfalls Bestandteil der Live-Umgebung und ermöglicht den Aufbau einer redundanten u. ausfallsicheren Liveumgebung.
service.example.com enthält GSB Services, die Basisdienste und Services bereitstellen und aus der Live- bzw. der Preview-Umgebung genutzt werden.
database.example.com enthält die für den Betrieb der GSB Infrastruktur benötigten Datenbanken.
extern.example.com enthält externe Systeme, die kein essentieller Bestandteil der GSB Infrastruktur sind. Hierzu zählt bspw. ein externer Mailserver.

Die oben skizzierten Zonen bzw. Domainnamen dienen lediglich der logischen Strukturierung und Gruppierung der GSB Services und ermöglichen eine einfache Identifikation von aus fachlicher Sicht zusammengehörigen Komponenten.

Für den Aufbau einer konkreten Hosting-Infrastruktur und Verteilung der GSB Services auf Server und Zonierung der Server können die Zonen der Beispielkonfiguration als Grundlage und Ausgangspunkt genommen werden.

Die folgende Grafik verdeutlicht die logische Struktur der Domänen und Zonen. Die in der Grafik mit Webserver verzeichnete Zone ist in der Beispielkonfiguration nicht als explizite Zone definiert, da diese Zone nur den Webserver enthält, der über die dort definierten VirtualHost-Definitionen für den Zugriff von außen (Redakteure, SiteAdministratoren, Internetnutzer) zuständig ist.

Zonen der GSB Beispielkonfiguration Zonen der GSB Beispielkonfiguration

Service- und Servernamen

Die einzelnen GSB Services, die als identifizierbare Komponente in Form eines Prozesses gestartet und betrieben werden, werden in der Beispielkonfiguration jeweils über einen dedizierten Servernamen angesprochen.

Das zugrundeliegende Namensschema für die Benennung der Service- und Servernamen entspricht dem Schema <SERVICE>.<ZONE>.example.com und wird anhand der folgenden Beispiele verdeutlicht:

repository.preview.example.com entspricht dem Content-Repository der Redaktionsumgebung (Service=repository, Zone=Preview),
repository.replication.example.com entspricht dem Replication Content-Repository (Zone Replication).
site.master.example.com entspricht den Site-Servern der Master-Zone
preview.database.example.com entspricht dem DB-Server unter dem die Preview Content-Repository Datenbank angesprochen wird.

Die GSB Services innerhalb einer Zone sind bis auf die Site-Server jeweils nur einmal vorhanden, so dass für jeden Service ein eindeutiger „Service-Name“ verwendet wird. Die in einer Zone redundant ausgelegten Site-Server der Beispielkonfiguration werden unter dem Namen site.<ZONE>.example.com angesprochen.

Die Verwendung der dedizierten Servicenamen in der Beispielkonfiguration soll wie angedeutet eine einfache Identifikation der anzupassenden Properties ermöglichen, wenn Servicenamen auf konkrete Hostnamen geändert werden sollen. Für den Aufbau einer konkreten Hostingplattform können die Servicenamen der Beispielkonfiguration auf den Hostnamen, auf dem die Services betrieben werden sollen, umgeschrieben werden.

Ports

Die einzelnen GSB Service-Instanzen nutzen jeweils individuelle Ports, die die folgenden Anforderungen erfüllen:

Eine Portdefinition für alle Service-Instanzen der Beispielkonfiguration ohne Überlappungen verwendet wird. So wird sichergestellt, dass alle Service-Instanzen grundsätzlich auf einem Server betrieben werden können.
Die genutzten Ports eine einfache Identifikation der Zone (s.a. Kapitel „Domainnamen und Zonen“) sowie des zugrundeliegenden Service-Typs ermöglichen.

Um eine möglichst homogene Konfiguration für die genutzten Ports bereitzustellen sieht die exemplarische Beispielkonfiguration das dem folgenden Schema folgt:

Die einzelnen Zonen verwenden dedizierte und überlappungsfreie Portranges für die GSB Tomcat-Service-Instanzen. So wird sichergestellt, dass alle GSB Komponenten konfliktfrei auf einem Server betrieben werden können. Für jede Zone ist ein 1000er Block vorgesehen. Die folgenden Blöcke werden in der Beispielkonfiguration genutzt:

Preview-Zone: 6xxx
Master-Live-Zone: 7xxx
Replication-Live-Zone: 8xxx
Service-Live-Zone: 9xxx

Die einzelnen Tomcat-Service-Instanzen werden je nach Service-Typ mit den folgenden Subranges konfiguriert (100er Block):

Repository: x0xx
Site: x1xx-x3xx
Solr: x4xx
Service: x5xx
Adminportal: x6xx
CAS: x7xx
Maildistributor: x8xx

Wie dem skizzierten Schema zu entnehmen ist steht für jeden Typ ein 100er-Block zur Verfügung. Die Site-Tomcats nutzen einen 300er-Block. Jede Tomcat-Instanz nutzt einen 10er-Block, so dass in einer Zone grundsätzlich 10 Instanzen eines Typs bzw. 30 Site-Instanzen betrieben werden können.

Das in der Beispielkonfiguration verwendete Schema für die Definition der Ports der einzelnen Service-Instanzen dient der einfachen Strukturierung der Definitionen der Beispielkonfiguration und kann beim Aufbau einer konkreten Hostingplattform bei Bedarf an die individuellen Belange der Hostingplattform angepasst werden.

Kommunikationsmatrix

Die in der Beispielkonfiguration genutzten Kommunikationsbeziehungen sind in der Kommunikationsmatrix zusammengestellt. Das Excel Sheet definiert für jede einzelne Service-Instanz der Beispielkonfiguration (Quellsystem) die benötigten Kommunikationsendpunkte (Zielsystem).

Die Quellsysteme können mit Hilfe der vorhandenen Excel-Filter einfach auf Servicename, Service-Typ bzw. Service-Instanz gefiltert werden. Die gleichen Filtermöglichkeiten stehen auch für die Zielsysteme zur Verfügung.

Vorbereitung der Installation

Für eine Installation des GSB 10.1 sind neben dem GSB-Softwarepaket und einer gültigen Lizenz die folgenden Komponenten erforderlich:

*Komponente*	*Version laut Vorgabe*	*Verwendete Version*
OpenJDK Java Laufzeitumgebung	11.0.2 GA	11.0.4
Apache Tomcat Servlet Container	9.0.27	9.0.24
Apache Portable Runtime	1.6.2	1.7.0 (für nicht produktiven Betrieb nicht erforderlich)
Apache Portable Runtime Util	1.6.0	1.6.1 (für nicht produktiven Betrieb nicht erforderlich)
Apache Tomcat Connector	1.2.42	1.2.46 (für nicht produktiven Betrieb nicht erforderlich)
Apache HTTPD Server	2.4.39	2.4.41
Apache SOLR	7.7.1	7.7.2
Apache SOLR JTS-Core	(nicht benannt)	1.16.1
MySQL Datenbank	8.0.14 GA	(nicht verwendet) MariaDB 10.3.17
MySQL JDBC-Connector	8.0.16	8.0.17 MariaDB Connector/J 2.4.3
Liferay Portal Community Edition	-	7.1.3 (wegen fehlender MariaDB-Komponente)

Einige dieser Komponenten werden über den Paketmanager yum installiert, andere müssen von den zugehörigen Web-Seiten heruntergeladen werden.

Erforderliche Downloads

Legen Sie zunächst ein Verzeichnis downloads im /tmp-Verzeichnis an:

mkdir /tmp/downloads
chmod -R 777 /tmp/downloads
cd /tmp/downloads

Der Apache Tomcat Servlet Container, die Zusatzkomponenten Apache Portable Runtime, Apache Portable Runtime Util und Apache Tomcat Connector sowie der Apache SOLR Server werden von einem Spiegel-Server der Apache Software Foundation heruntergeladen. Lediglich die SHA-Checksummen sollen vom Hauptserver heruntergeladen werden. Die Checksummen-Prüfung erfolgt mit sha512sum bzw. sha256sum und muss als Ergebnis OK liefern.

wget "http://mirror.23media.de/apache/tomcat/tomcat-9/v9.0.24/bin/apache-tomcat-9.0.24.tar.gz"
wget "https://www.apache.org/dist/tomcat/tomcat-9/v9.0.24/bin/apache-tomcat-9.0.24.tar.gz.sha512"
sha512sum -c apache-tomcat-9.0.24.tar.gz.sha512

wget "http://mirror.23media.de/apache/apr/apr-1.7.0.tar.gz"
wget "https://www.apache.org/dist/apr/apr-1.7.0.tar.gz.sha256"
sha256sum -c apr-1.7.0.tar.gz.sha256

wget "http://mirror.23media.de/apache//apr/apr-util-1.6.1.tar.gz"
wget "https://www.apache.org/dist/apr/apr-util-1.6.1.tar.gz.sha256"
sha256sum -c apr-util-1.6.1.tar.gz.sha256

wget "http://mirror.23media.de/apache/tomcat/tomcat-connectors/jk/tomcat-connectors-1.2.46-src.tar.gz"
wget "https://www.apache.org/dist/tomcat/tomcat-connectors/jk/tomcat-connectors-1.2.46-src.tar.gz.sha512"
sha512sum -c tomcat-connectors-1.2.46-src.tar.gz.sha512

wget "http://mirror.23media.de/apache/lucene/solr/7.7.2/solr-7.7.2.tgz"
wget "https://www.apache.org/dist/lucene/solr/7.7.2/solr-7.7.2.tgz.sha512"
sha512sum -c solr-7.7.2.tgz.sha512

Die JTS-Core-Bibliothek zur Unterstützung von geometrischen Umkreissuchen mit Polygonen in Apache SOLR muss separat heruntergeladen werden. Die Checksumme wird mit sha1sum erzeugt und muss manuell mit dem Inhalt der sha1-Datei verglichen werden.

wget "http://central.maven.org/maven2/org/locationtech/jts/jts-core/1.16.1/jts-core-1.16.1.jar"
wget "http://central.maven.org/maven2/org/locationtech/jts/jts-core/1.16.1/jts-core-1.16.1.jar.sha1"
sha1sum jts-core-1.16.1.jar
cat jts-core-1.16.1.jar.sha1

Zur Kommunikation mit der MySQL-Datenbank wird ein JDBC-Connector benötigt. Der Download erfolgt von der MySQL-Download-Seite (https://dev.mysql.com/downloads/connector/j/8.0.html). Es ist hier unter „Select Operating System“ der Wert „Platform independent“ auszuwählen. Zur Checksummenprüfung muss der MD5-Hash der Datei ermittelt und mit dem auf der Downloadseite angegebenen Wert verglichen werden.

wget "https://dev.mysql.com/get/Downloads/Connector-J/mysql-connector-java-8.0.17.tar.gz"
md5sum mysql-connector-java-8.0.17.tar.gz

Die GSB-Software wird auf der GSB-Downloadseite zur Verfügung gestellt. Für den Download benötigen Sie eine Benutzerkennung und ein Passwort.

curl --user [Benutzername] https://download.gsb.bund.de/GSB/gsb-10.1.0.zip

MariaDB

Für die Verwendung von MariaDB wird ein eigener JDBC-Connector benötigt. Der Download erfolgt von der MariaDB-Download-Seite. Die Checksummen-Prüfung erfolgt mit sha512sum und muss als Ergebnis einmal OK sowie zweimal einen Fehler liefern, da die Quell- und Dokumentationsdateien nicht herunter geladen werden.

Außerdem fehlt in der GSB-Komponente adminportal, welche auf Basis des Liferay Portal Servers 7.1 realisiert wurde, eine in der Original-Liferay-Tomcat-Distribution enthaltene Bibliothek zur Verwendung mit MariaDB. Diese muss aus der Original-Distribution kopiert werden. Die Checksummen-Prüfung erfolgt mit md5sum und muss als Ergebnis OK liefern.

wget "https://downloads.mariadb.com/Connectors/java/connector-java-2.4.4/mariadb-java-client-2.4.4.jar"
wget "https://downloads.mariadb.com/Connectors/java/connector-java-2.4.4/sha512sums.txt"
sha512sum -c sha512sums.txt

wget "https://downloads.sourceforge.net/project/lportal/Liferay%20Portal/7.1.3%20GA4/liferay-ce-portal-tomcat-7.1.3-ga4-20190508171117552.tar.gz"
wget "https://downloads.sourceforge.net/project/lportal/Liferay%20Portal/7.1.3%20GA4/liferay-ce-portal-tomcat-7.1.3-ga4-20190508171117552.tar.gz.MD5"
md5sum -c liferay-ce-portal-tomcat-7.1.3-ga4-20190508171117552.tar.gz.MD5

Installation von zusätzlichen Tools

CentOS

Im CentOS-Betriebssystem ist in der Regel die Kernel-Erweiterung SELinux (Security-Enhanced Linux) aktiv. Für die Konfiguration von Zugriffsrechten im Dateisystem mit dem Werkzeug semanage wird das Paket policycoreutils-python benötigt. Weiterhin fehlen die Werkzeuge zip und unzip.
Die Installation erfolgt mittels:

yum -y install zip unzip policycoreutils-python

RedHat und CentOS verfolgen eine relativ konservative Strategie bzgl. der Aktualisierung der in den Distributionen enthaltenen Softwarepakete. So wird über die OS-Repositories auch eine relativ alte Version des Apache-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" (https://ius.io/GettingStarted/).

Eine aktuelle Version des Apache HTTPD-Webservers kann über die IUS-Repositories installiert werden. Dazu muss allerdings das IUS-Repository manuell installiert werden.

wget "https://centos7.iuscommunity.org/ius-release.rpm"
yum -y localinstall ius-release.rpm

Installation der Komponenten

Java

Details zu den benötigten Java-Version finden Sie in der Tabelle Systemvoraussetzungen.

Die Installation erfolgt in der Regel unter dem Verzeichnis /usr/lib/jvm. Dort werden auch einige symbolische Links angelegt, die bei Aktualisierungen mit aktualisiert werden (in diesem Fall /usr/lib/jvm/jre-11-openjdk). Daher empfiehlt es sich, den im GSB verwendeten Java-Pfad ebenfalls als symbolischen Link auf diesen Link zu setzen.

mkdir -p /usr/java
ln -s /usr/lib/jvm/jre-11-openjdk /usr/java/default

Alternativ kann der Link auch an anderer Stelle angelegt werden (z.B. in Analogie zu den übrigen Software-Komponenten unter /opt/software/java). In diesem Fall muss die JAVA_HOME-Variable in den GSB systemd-Service-Units entsprechend angepasst werden.

Tomcat-Server

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 (z.B. /opt/software/tomcat/apache-tomcat-9.0.24) gesetzt, da innerhalb der für den Start der Komponenten eingesetzten systemd-Service-Units die Definitionen der Start- und Stopp-Skripte 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.

Die Installation erfolgt durch Entpacken des heruntergeladenen Archivs:

mkdir -p /opt/software/tomcat
tar -xvzf ~/downloads/apache-tomcat-9.0.24.tar.gz -C /opt/software/tomcat/
ln -s /opt/software/tomcat/apache-tomcat-9.0.24 /opt/software/tomcat/default

Solr-Server

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-Servers finden sich auf den Webseiten des Herstellers unter "Installing Solr" (https://lucene.apache.org/solr/guide/7_0/installing-solr.html).

Die Installation des Solr-Servers erfolgt unterhalb des Ordners /opt/software/solr. Durch Setzen eines symbolischen Links von /opt/software/solr/default auf das konkrete Installationsverzeichnis wird eine Installation bereitgestellt, die analog zur Tomcat-Server-Installation aufgebaut ist. Hierdurch wird sichergestellt, dass

der Solr-Server analog zum Tomcat-Server abgelegt ist und somit eine gleichfö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 erfolgt durch Entpacken des heruntergeladenen Archivs:

mkdir -p /opt/software/solr
tar -xvzf ~/downloads/solr-7.7.2.tgz -C /opt/software/solr/
ln -s /opt/software/solr/solr-7.7.2 /opt/software/solr/default

Weiterhin müssen einige Zusatzbibliotheken kopiert werden:

mkdir -p /opt/software/solr/default/lib
cd /opt/software/solr/default
cp ./contrib/analysis-extras/lib/icu4j-*.jar ./lib/
cp ./contrib/analysis-extras/lucene-libs/lucene-analyzers-icu-*.jar ./lib/
cp ./dist/solr-analysis-extras-*.jar ./lib/
cp /tmp/downloads/jts-core-*.jar ./server/solr-webapp/webapp/WEB-INF/lib/

Httpd-Server

Die Installation des Apache HTTPD-Servers sowie des zusätzlich erforderlichen Moduls mod_ssl erfolgt über den Paketmanager yum.

yum -y install httpd mod_ssl

CentOS

Im CentOS-Betriebssystem lautet der Aufruf wegen der Nutzung des IUS-Repositories:

yum -y install httpd24u httpd24u-mod_ssl

Damit der HTTPD-Server abgehende Verbindungen herstellen kann, muss folgendes Kommando aufgerufen werden:

setsebool -P httpd_can_network_connect 1

Die Standard-Konfigurationsdateien müssen gelöscht werden, da sie im Zuge der Konfiguration des GSB ersetzt werden.

rm /etc/httpd/conf.d/*.conf

Datenbanken

Der GSB unterstützt die Datenbanken MySQL und Oracle.

Installation der Datenbank

Die Installation der eigentlichen Datenbankserver kann anhand der Installationsanleitungen der Datenbankhersteller durchgeführt werden.

MySQL

Die Installationsanleitung der MySQL Datenbank findet sich auf der Seite https://dev.mysql.com/doc/refman/8.0/en/linux-installation.html.

Die MySQL-Datenbank sollte so konfiguriert werden, dass die Datenbanktabellen case-insensitiv gespeichert werden (s.a. https://dev.mysql.com/doc/refman/8.0/en/identifier-case-sensitivity.html).

Weiterhin muss der Parameter max_allowed_packet größer gewählt werden als das größte Blob-File welches im Content-Repository gespeichert werden soll. In diesem Zusammenhang muss dann auch der Parameter innodb_log_file_size geeignet erhöht werden.

Oracle

Die Installationsanleitung der Oracle Datenbank findet sich auf der Seite https://docs.oracle.com/database/121/LADBI/toc.htm

Der für den Zugriff auf die Datenbanken erforderliche JDBC-Treiber muss anschließend im Order /opt/gsbos/lib abgelegt werden. Legen Sie dazu zunächst den Ordner an:

mkdir /opt/gsbos/lib

cp [Pfad-zu-JDBC-Treiber] /opt/gsbos/lib

chown -R gsbos: /opt/gsbos/lib

MariaDB

Die Installation der MariaDB-Datenbank erfolgt über den Paketmanager yum. Anschließend wird der entsprechende Service eingerichtet und aktiviert sowie die Installation abgesichert.

yum -y install mariadb103-server mariadb103-client
systemctl enable mariadb
systemctl start mariadb

Bei einer neuen Standardinstallation empfiehlt es sich, die Berechtigungen einzuschränken. Dies erfolgt mit dem Kommando

mysql_secure_installation

Auf die Frage

Enter current password for root (enter for none):

wird die Enter-Taste gedrückt.

Die Frage

Set root password? [Y/n]

wird mit Y und Enter-Taste beantwortet.

Danach muss zweimal das neue Kennwort für den root-User der Datenbank (nicht den System-root-User) eingegeben werden.

Die folgenden Fragen

Remove anonymous users? [Y/n]
...
Disallow root login remotely? [Y/n]
...
Remove test database and access to it? [Y/n]
...
Reload privilege tables now? [Y/n]

werden sämtlich mit Y und Enter-Taste beantwortet.

Auch für die MariaDB müssen die für MySQL dokumentierten Parameter lower_case_table_names, max_allowed_packet und innodb_log_file_size angepasst werden. Legen Sie dazu unter /etc/my.cnf.d/ die Datei gsbos_extras.cnf mit folgendem Inhalt an:

[mysqld]
lower_case_table_names=1
max_allowed_packet=536870912
innodb_log_file_size=4294967296

Die angegebenen Werte entsprechen 500MB für max_allowed_packet bzw. 4GB für innodb_log_file_size. Passen Sie die Werte entsprechend Ihren Erfordernissen an.

Weiterhin muss der globale Parameter SQL_MODE der Datenbank um den Modus ANSI_QUOTES ergänzt werden. Führen Sie dazu das folgende Kommando aus (Angabe des Passworts des DB-root-Users erforderlich):

mysql -u root -p -e "SET @@GLOBAL.SQL_MODE = CONCAT(@@SQL_MODE, ',ANSI_QUOTES');"

Starten Sie danach die MariaDB neu:

systemctl restart mariadb

Hinweis:
Damit Änderungen des Modes '`ANSI_QUOTES`' auch für weitere Restarts wirksam sind, muss diese Option in /etc/my.cnf.d/gsbos_extras.cnf gesetzt werden.

Kopieren Sie den MariaDB-JDBC-Treiber in das zentrale Bibliotheksverzeichnis:

cp /tmp/downloads/mariadb-java-client-2.4.4.jar /opt/gsbos/lib/

chown -R gsbos: /opt/gsbos/lib

Installation des GSB

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 gsb@itzbund.de. Die Lizenzdaten sind anschließend in der Runtime-Konfiguration der Repository Webapplikation zu hinterlegen.

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:

gsbos-Nutzer
Parameter	Wert
LOGIN	gsbos
GROUP	gsbos
HOME_DIR	/home/gsbos
SHELL	/bin/bash

Die Anlage erfolgt mittels:

mkdir /home/gsbos
useradd -r -s /bin/bash -d /home/gsbos gsbos
chown -R gsbos: /home/gsbos
chmod 700 /home/gsbos

Für die weitere Installation, die mit dem Nutzer gsbos durchgeführt wird, müssen noch zwei Basis-Verzeichnisse angelegt und für den Nutzer gsbos berechtigt werden:

mkdir -p /opt/gsbos
mkdir -p /space/gsbos
chown -R gsbos: /opt/gsbos
chown -R gsbos: /space/gsbos

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:

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.1.0 und /home/gsbos/releases/customers abgelegt werden.

Bewegungsdaten- und Datenverzeichnisse

Der GSB 10 speichert einige Daten im Dateisystem des zugrundeliegenden Servers. Hierbei handelt es sich um persistente Daten wie bpsw. das Contentrepository der CMS-Servers sowie Bewegungsdaten wie Logfiles und temporäre Daten, die nur zur Laufzeit einer Komponente erzeugt und benötigt werden. Diese Daten werden jeweils in dedizierten Basisverzeichnissen gespeichert und sind aus Sicht des System- bzw. Applikationsbetriebs jeweils unterschiedlich zu behandeln.

Die exemplarische Konfiguration geht davon aus, dass alle Datenverzeichnisse unterhalb des Basisverzeichnisses /space/gsbos abgelegt werden. Die unterschiedlichen Datenarten des GSB 10 werden jeweils in dedizierten Unterverzeichnissen in dem skizzierten Basisverzeichnis abgelegt, die in der folgenden Tabelle vorgestellt werden.

Datenverzeichnisse
Verzeichnis	Inhalt
/space/gsbos/data	Im Data-Verzeichis werden alle persistenten Daten der GSB Komponenten abgelegt. Dieses Verzeichnis beinhaltet somit alle zu sichernden Dateien.
/space/gsbos/logs	Log-Dateien der GSB Komponenten werden in dem Logs-Verzeichnis abgelegt.
/space/gsbos/temp	Temporäre Dateien werden unterhalb des Temp-Ordners abgelegt.

Das Data-Verzeichnis (/space/gsbos/data) beinhaltet alle persistenten Dateien einer GSB Infrastruktur. Hierbei handelt es sich insbesondere um das Content-Repository und die zugeordneten Solr-Indices.

Es empfiehlt sich daher in einer produktiven Infrastruktur dieses Verzeichnis in ein dediziertes Filesystem auszulagern. Das Filesystem muss hinreichend groß dimensioniert sein, um sowohl den aktuellen Informationsbestand speichern zu können als auch zusätzliche Daten bspw. durch redaktionelle Tätigkeiten, automatische Importe oder neue Mandanten speichern zu können.

Darüber hinaus sollte sichergestellt werden, dass keine anderen Serverkomponenten schreibend auf dieses Filesystem zugreifen, um so ein unbeabsichtigtes Volllaufen des Filesystems verhindern zu können. Um bei sich ankündigenden Engpässen schnell reagieren zu können empfiehlt sich ein dediziertes Monitoring des Füllstandes des Data-Verzeichnisses mit hinreichend konservativ gewählten Alarmierungsparametern, um frühzeitig reagieren und zusätzlichen Speicherplatz im Data-Verzeichnis bereitstellen zu können.

Der Wechsel auf den Nutzer gsbos erfolgt mit folgendem Kommando:

su - gsbos -s /bin/bash

Die erforderlichen Verzeichnisse werden mit folgenden Kommandos angelegt:

mkdir -p ~/config
mkdir -p ~/releases/core
mkdir -p ~/releases/customers
mkdir -p ~/platformBundle
mkdir -p ~/patches
mkdir -p /opt/gsbos/runtime
mkdir -p /space/gsbos/data
mkdir -p /space/gsbos/logs
mkdir -p /space/gsbos/temp

Zur Vorbereitung der Installation wird das GSB-Archiv im gsbos-Home-Verzeichnis entpackt.

unzip /tmp/downloads/gsbos-10.1.0.zip -d ~/

Die Installation erfolgt in drei Schritten: zunächst wird das Platform-Bundle erstellt, welches im Wesentlichen die einzelnen Service-Typen als installierbare Archive enthält; danach werden die gewünschten Service-Typen auf den jeweiligen Zielserver installiert; abschließend erfolgt die Konfiguration der Service-Instanzen.

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 Platform-Bundle ist eine GSB 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.

Die Shellskripte für die Erzeugung des Platform-Bundles sowie Installation erfordert die Ausführung in einer Bash Version 4.x.

Für die Erstellung des Platform-Bundles ist das Skript der zugrundeliegenden GSB-Version zu verwenden, da die Skripte aus anderen GSB-Versionen ggf. inkompatibel sein können zur aktuell genutzten Version.

Konfigurationsdateien

Um eine Lieferung zu erstellen werden drei Konfigurationsdateien benötigt.

gsbos_global.cfg
serviceTypes.cfg
platformBundle.cfg

Die drei Konfigurationsdateien müssen in einem Verzeichnis liegen. Das Standardverzeichnis ist ~gsbos/config.

Im Folgenden werden die drei Konfigurationsdateien beschrieben.

gsbos_global.cfg

Im Folgenden wird die Konfigurationsdatei gsbos_global.cfg beschrieben.

Beschreibung

Diese Konfigurationsdatei wird für folgende Punkte benötigt:

Globale Konfiguration des GSB

Die Konfigurationsdatei wird mit jedem GSB Release ausgeliefert und befindet sich im infrastructure-Verzeichnis des Kerns (core) unter ~gsbos/releases/core/10.1.0/infrastructure/platform/conf/.

Diese Datei sollte in ein zentrales Konfigurationsverzeichnis kopiert werden.

cp ~gsbos/releases/core/10.1.0/infrastructure/platform/conf/gsbos_global.cfg ~gsbos/config/

Danach kann diese an die Plattform angepasst werden.

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"

serviceTypes.cfg

Im Folgenden wird die Konfigurationsdatei serviceTypes.cfg beschrieben.

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 Release ausgeliefert und befindet sich im infrastructure-Verzeichnis des Kerns (core) unter ~gsbos/releases/core/10.1.0/infrastructure/platform/conf/.

Diese Datei sollte in ein zentrales Konfigurationsverzeichnis kopiert werden.

cp ~gsbos/releases/core/10.1.0/infrastructure/platform/conf/serviceTypes.cfg ~gsbos/config/

Danach kann diese an die Plattform angepasst werden.

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-Typs angepasst, so muss auch die Runtime entsprechend abgelegt werden.

bashdeclare -g -A gsbos_serviceTypes

###############################################################################
# Globale Service-Typen (Redaktions- und Live-Umgebung)
###############################################################################
# Beschreibt die Komponenten des ServiceType *site*
gsbos_serviceTypes[site]="tomcat site"
# Beschreibt die Komponenten des ServiceType *repository*
gsbos_serviceTypes[repository]="repository"
# Beschreibt die Komponenten des ServiceType *indexer*
gsbos_serviceTypes[indexer]="indexer"
# Beschreibt die Komponenten des ServiceType *solr*
gsbos_serviceTypes[solr]="solr"

###############################################################################
# Preview Service-Typen (Redaktionsumgebung)
###############################################################################
# Beschreibt die Komponenten des ServiceType *workflow*
gsbos_serviceTypes[workflow]="workflow"
# Beschreibt die Komponenten des ServiceType *editor*
gsbos_serviceTypes[editor]="tomcat editor"
# Beschreibt die Komponenten des ServiceType *eventdispatcher*
gsbos_serviceTypes[eventdispatcher]="eventdispatcher"

###############################################################################
# Service Service-Typen (Service-Umgebung)
###############################################################################
# Beschreibt die Komponenten des ServiceType *userservice*
gsbos_serviceTypes[userservice]="userservice"
# Beschreibt die Komponenten des ServiceType *adminportal*
gsbos_serviceTypes[adminportal]="tomcat liferay adminportal"
# Beschreibt die Komponenten des ServiceType *serviceportal*
gsbos_serviceTypes[serviceportal]="serviceportal"
# Beschreibt die Komponenten des ServiceType *maildistributor*
gsbos_serviceTypes[maildistributor]="maildistributor"
# Beschreibt die Komponenten des ServiceType *cas*
gsbos_serviceTypes[cas]="cas"
# Beschreibt die Komponenten des ServiceType *cmisserver*
gsbos_serviceTypes[cmisserver]="cmisserver"
# Beschreibt die Komponenten des ServiceType *cmisclient*
gsbos_serviceTypes[cmisclient]="cmisclient"

###############################################################################
# HTTPD
###############################################################################
# Beschreibt die Komponenten des ServiceType *httpd*
gsbos_serviceTypes[httpd]="httpd"

platformBundle.cfg

Im Folgenden wird die Konfigurationsdatei platformBundle.cfg beschrieben.

Beschreibung

Diese Konfigurationsdatei wird für folgende Punkte benötigt:

Beschreibung des Platform-Bundles

Die Konfigurationsdatei wird mit jedem GSB Release ausgeliefert und befindet sich im infrastructure-Verzeichnis des Kerns (core) unter ~gsbos/releases/core/10.1.0/infrastructure/platform/conf/.

Diese Datei sollte in ein zentrales Konfigurationsverzeichnis kopiert werden.

cp ~gsbos/releases/core/10.1.0/infrastructure/platformBundle/platformBundle.cfg ~gsbos/config/

Danach kann diese an die Plattform angepasst werden.

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>

# Liste der Mandanten und deren Version

customers=(

<CUSTOMER1_NAME>:<CUSTOMER1_VERSION>

<CUSTOMER2_NAME>:<CUSTOMER2_VERSION>

<CUSTOMER3_NAME>:<CUSTOMER3_VERSION>

)

###############################################################################

# Patch Definition (Optional)

###############################################################################

# Liste der Core-Patches

core_patches=(

# PATCH-FILE-NAME

)

# Liste der Customer-Patches

#customer_patches[standardlsg]="PATCH-FILE-NAME"

Die Token <CUSTOMER1_NAME> und <CUSTOMER1_VERSION> müssen durch den Namen und die Version des ersten Mandanten ersetzt werden.

Die Token <CUSTOMER2_NAME> und <CUSTOMER2_VERSION> müssen durch den Namen und die Version des zweiten Mandanten ersetzt werden.

Die Token <CUSTOMER3_NAME> und <CUSTOMER3_VERSION> müssen durch den Namen und die Version des dritten Mandanten ersetzt werden.

Das Token <CORE_VERSION> muss durch die genutzte Core-Version ersetzt werden.

Sollte das Plattform-Bundle nur einen Mandanten beinhalten dann müssen die im obigen Beispiel enthaltenen Definitionen für CUSTOMER2 und CUSTOMER3 gelöscht werden.

Verwendung

Bevor das Skript verwendet werden kann, muss es ausführbar sein.

chmod +x ~gsbos/releases/core/10.1.0/infrastructure/platform/scripts/platformBundle.sh

Um das Skript einfacher auszuführen zu können sollte es in ein Verzeichnis kopiert werden, welches in der PATH Variable includiert wird/ist.

Das Skript kann mit folgenden Parametern ausgeführt werden:

-c Angabe des Pfad zum Konfigurationsverzeichnis

◦ Standardwert: ~gsbos/config/

-f Überschreiben des Platform-Bundle, falls dieses bereits existiert

◦ Standardwert: -

-h Hilfe (usage) des Skript

Vorgehen zur Erstellung

Nachdem die oben beschriebenen Konfigurationen auf die jeweilige Hostingplattform angepasst wurden, wird das Platform-Bundle mit dem folgenden Script erzeugt:

~gsbos/releases/core/10.1/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.

Installation des Platform-Bundles

Das Skript install-gsbos.sh wird zum Installieren des Platform-Bundle benötigt. Ein Platform-Bundle ist eine GSB Lieferung angepasst an eine definierte Plattform. Dabei wird über Konfigurationsdateien das zu installierende Platform-Bundle definiert.

Konfigurationsdateien

Um ein Platform-Bundle 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.

Es handelt sich hierbei um die gleichen Konfigurationsdateien wie sie für die Erstellung des Platform-Bundles verwendet wurden (s. Abschnitt Konfigurationsdateien unter "Erstellung des Platform-Bundles").

Verwendung

Bevor das Skript verwendet werden kann, muss es ausführbar sein.

chmod +x ~gsbos/releases/core/10.1.0/infrastructure/platform/scripts/install-gsbos.sh

Um das Skript einfacher auszuführen zu können sollte es in ein Verzeichnis kopiert werden, welches in der PATH Variable includiert wird/ist.

Das Skript kann mit folgenden Parametern ausgeführt werden:

-c Angabe des Pfad zum Konfigurationsverzeichnis

◦ Standardwert: ~gsbos/config/

-t Angabe expliziter Service-Typen (z.B. um nur die Site neu zu installieren)

◦ Standardwert: - (verwendet alle)

-h Hilfe (usage) des Skript

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:

~gsbos/releases/core/10.1.0/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>

Konfiguration

Die folgenden Kapitel finden sich in der ursprünglichen Anleitung bereits nach der Installation der Datenbank-Software. Da die erforderlichen SQL-Skripte und Konfigurationsdateien aber erst mit Bereitstellen/Extrahieren der GSB-Software zur Verfügung stehen, wurden sie an diese Stelle verschoben.

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.

Diese Einrichtung erfolgt in zwei Schritten:

Als erstes werden für jede Instanz der GSB Applikationen entsprechende User/Schemata angelegt.
In jedem erstellen User/Schema muss das Datenmodell (Tabellen/Spalten) erstellt oder ggf. aktualisiert werden.

Die Skripte hierfür befinden sich im Infrastructure-Artefakt, im Ordner infrastructure/sql, in dem für jede unterstützte Datenbank ein Unterordner (mysql, oracle) vorhanden ist.

Hinweis zu MySQL:
Die MySQL-Skripte beinhalten exemplarischen Passwörter, die nicht für den Betrieb einer Plattform geeignet sind. Für den Produktiv-/Testbetrieb sollten aufgrund der Passwort-Policy MySQL8-konforme Passwörter verwendet werden.

Für jede einzurichtende Datenbank (bzw. GSB Komponente mit Datenbankunterstützung) ist ein Unterordner vorhanden, in dem Skripte zum Anlegen der benötigten Datenbank(en) abgelegt sind.

Einrichten der User/Schemata

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.

create tablespace gsbos

datafile 'gsbos.dbf' size 500M reuse autoextend on next 100M

maxsize unlimited extent management local segment space management auto;

Für das Einrichten der User/Schemata können die create<XX>Db.sql Skripte genutzt werden.

Anlegen von MySQL Datenbanken

Die create<XX>Db.sql Skripte für MySQL setzen nur Properties und verweisen dann auf ein gemeinsames _createDatabase.sql Skript, welches die eigentliche Funktionalität enthält. Die Datenbanken können am einfachsten mit dem folgenden Kommando angelegt werden:

cd /home/gsbos/releases/core/10.1/infrastructure/sql/mysql
mysql --user=root --password=<ROOT_PASSWORD> < site/createSiteDb.sql

Das Token <ROOT_PASSWORD> muss durch das Passwort des MySQL Root-Benutzers ersetzt werden.

Das generische Skript _createDatabase.sql zum Anlegen einer MySQL Datenbank ist wie folgt aufgebaut:

#### Create Database

SET @createDb = CONCAT ('CREATE DATABASE IF NOT EXISTS ',@databasename,' CHARACTER SET = ''utf8mb4'' COLLATE = ''utf8mb4_bin''');

PREPARE stmt FROM @createDb; EXECUTE stmt; DEALLOCATE PREPARE stmt;

#### Create User

SET @createUser = CONCAT ('CREATE USER IF NOT EXISTS ''',@username,'''@''%'' IDENTIFIED BY ''',@userpassword,'''');

PREPARE stmt FROM @createUser; EXECUTE stmt; DEALLOCATE PREPARE stmt;

#### Disable Rights on all databases for @username

SET @grantUsage = CONCAT ('GRANT USAGE ON *.* TO ''',@username,'''@''%'';');

PREPARE stmt FROM @grantUsage; EXECUTE stmt; DEALLOCATE PREPARE stmt;

#### Set Rights on @databasename for @username

SET @grantRights = CONCAT ('GRANT ',@userrights,' ON ',@databasename,'.* TO ''',@username,'''@''%''');

PREPARE stmt FROM @grantRights; EXECUTE stmt; DEALLOCATE PREPARE stmt;

FLUSH PRIVILEGES;

Erstellen/Aktualisieren der Tabellen

Im Falle einer Neuinstallation (d.h. es sind noch keine Tabellen/Daten) in der Datenbank vorhanden, können die Skripte, deren Dateinamen mit init_ beginnen, genutzt werden, um die benötigten Tabellen zu erstellen.

Im Falle eines Updates von einer vorherigen GSB-Version, können analog dazu die Skripte, deren Dateinamen mit migrate_ beginnen, genutzt werden, um die vorhandenen Tabellen und Daten auf die neue GSB-Version zu migrieren.

Eine vollständige Neuinstallation mit einer MySQL-Datenbank (oder einer MariaDB-Datenbank) erfolgt also mit den folgenden Aufrufen ([Root-Passwort] muss durch das Passwort des MySQL Root-Benutzers ersetzt werden):

cd ~gsbos/releases/core/10.1.0/infrastructure/sql/mysql

mysql -u root -p[Root-Passwort] < adminportal/createAdminportalDb.sql

mysql -u root -p[Root-Passwort] < maildistributor/createMailDistributorDb.sql

mysql -u root -p[Root-Passwort] < maildistributor/init_maildistributor_10.1.0.sql

mysql -u root -p[Root-Passwort] < serviceportal/createServiceportalDb.sql

mysql -u root -p[Root-Passwort] < serviceportal/init_serviceportal_10.1.0.sql

mysql -u root -p[Root-Passwort] < site/createSiteDb.sql

mysql -u root -p[Root-Passwort] < site/init_site_10.1.0.sql

mysql -u root -p[Root-Passwort] < userservice/createUserserviceLiveDb.sql

mysql -u root -p[Root-Passwort] < userservice/init_usersrvc_live_10.1.0.sql

mysql -u root -p[Root-Passwort] < userservice/createUserservicePreviewDb.sql

mysql -u root -p[Root-Passwort] < userservice/init_usersrvc_preview_10.1.0.sql

mysql -u root -p[Root-Passwort] < workflow/createWorkflowDb.sql

mysql -u root -p[Root-Passwort] < workflow/init_workflow_10.1.0.sql

Eine Migration von einer bestehenden GSBOS 10.0.0-Installation erfolgt mit folgenden Aufrufen ([Root-Passwort] muss durch das Passwort des MySQL Root-Benutzers ersetzt werden):

cd ~gsbos/releases/core/10.1.0/infrastructure/sql/mysql

mysql -u root -p[Root-Passwort] < maildistributor/migrate_maildistributor_from_10.0.0_to_10.1.0.sql

mysql -u root -p[Root-Passwort] < serviceportal/migrate_serviceportal_from_10.0.0_to_10.1.0.sql

mysql -u root -p[Root-Passwort] < site/migrate_site_from_10.0.0_to_10.1.0.sql

mysql -u root -p[Root-Passwort] < workflow/migrate_workflow_from_10.0.0_to_10.1.0.sql

In der Version GSB 10.1.0 sind die Userservice Datenbanken usersrvc_live und usersrvc_preview im Initialzustand leer, was dazu führt, dass keine Anmeldung am Admin-Portal möglich ist. Die Initialisierung der Datenbank wird im Kapitel „Ersteinrichtung Adminportal“ beschrieben.

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.

Zertifikat

Der Ordner certificates in der exemplarischen Runtime-Konfiguration nimmt eine Sonderstellung ein, da hier keine klassischen Runtime-Konfigurationen einer GSB Applikation abgelegt sind sondern SSL-Zertifikate. Die Zertifikate werden für eine SSL-Kommunikation der GSB Applikationen untereinander und bei Verwendung des https-Mandanten im Webserver verwendet.

Durch die Speicherung der Zertifikate im Runtime-Ordner sind diese unabhängig von der eingesetzten Java-Version, so dass ein Update der Java-Version ohne Verlust der im Java-Keystore eingetragenen Zertifikate durchgeführt werden kann.

Das Release enthält selbstgenerierte Zertifikate für die genutzte Domain example.com. Im Einzelnen sind die folgenden Dateien enthalten:

ca-cert.conf: Konfigurationsdatei für die Generierung von selbstsignierten Zertifikaten. Diese Datei kann an plattformspezifische Belange angepasst werden, um Zertifikate für die Plattform zu generieren.
ca-cert.pem: Generiertes SSL-Zertifikat für die Einbindung in den Webserver (https-Mandant)
generateCert.sh: Skript zur Generierung der SSL-Zertifikate und Java-Keystores auf Basis der Konfigurationsdatei ca-cert.conf
keystore.p12: Generierter Java-Keystore für die Nutzung in den GSB Applikationen

Im Folgenden wird der Aufbau der Runtime-Konfiguration der einzelnen Arten von Service-Typen beschrieben.

Standalone Applikationen

Die Runtime-Konfiguration der GSB Standalone-Applikation Service-Instanzen umfasst die beiden Dateien

systemd.env enthält Umgebungsvariablen für die Applikation. Über eine spezielle <servicetyp>_OPTS Variable können hier z.B. JVM Parameter konfiguriert werden. (In der mitgelieferten Beispiel-Runtime wird hier exemplarisch der JVM Parameter -server gesetzt)
application.properties beinhaltet die applikationsspezifischen Parameter. Die zentralen anzupassenden Properties sind der Port unter dem die Anwendung bereitgestellt werden soll sowie die Urls der Kommunikationsendpunkte der anderen GSB Applikationen (s.a. Auszug der Properties-Datei)

Auszug Application-Properties

logging.config=${gsb.software.dir}/logback-spring.xml

server.port=6501

indexer.repository.url=http://repository.preview.example.com:6001

indexer.solr.url=http://solr.preview.example.com:6401

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 site1-master wie folgt aus:

site1-master
- systemd.env
- tomcat.properties
- application.properties

Die Datei systemd.env enthält mit der Umgebungsvariablen-Definition CATALINA_OPTS alle instanzspezifischen JVM Parameter wie z.B. 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=site.master.example.com

tomcat.server.port=7105

tomcat.server.shutdown=AGkkv,aSL!

tomcat.server.jvmRoute=site1-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 site1-master/application.properties) sind individuell für die einzelnen Webapplikationen, so dass diese an dieser Stelle keine Beispiele vorgestellt werden können. Die wesentlichen Anpassungen in den webapplikationsspezifischen Properties betreffen Servernamen sowie Ports.

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://site1.master.example.com:7109 route=site1-master

BalancerMember ajp://site2.master.example.com:7119 route=site2-master

BalancerMember ajp://site1.replication.example.com:8109 route=site1-replication

BalancerMember ajp://site2.replication.example.com:8119 route=site2-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 site[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. dass nachfolgende Requests eines Browsers immer an denselben Tomcat-Server weitergeleitet werden.

Die Konfigurationsdateien des HTTPD müssen noch in das Standardkonfigurationsverzeichnis des HTTPD eingehängt werden. Führen Sie dazu das folgende Kommando aus:

ln -s /opt/gsbos/runtime/httpd/conf.d/gsbos.conf /etc/httpd/conf.d/

Solr-Server

Der GSB nutzt eine 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-Runtime-Konfiguration 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

◦ systemd.env

Die Datei systemd.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_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

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.

Konfiguration der Servernamen

Eine Modifikation der Hosts-Datei sollte in einem produktiven Umfeld die Ausnahme sein; in der Regel sollten die Beispiel-Servernamen in den Runtime-Konfigurationsdateien durch die realen Servernamen bzw. DNS-Einträge ersetzt werden. Dies gilt insbesondere für die Adressen, die von außen durch einen Browser aufgerufen werden.

Das Anlegen der Konfigurationen für die in diesem Dokument beschriebene Installation auf einem einzelnen Server erfolgt durch Kopieren der Beispiel-Konfigurationen:

cp -pr ~gsbos/releases/core/10.1.0/infrastructure/runtime/* /opt/gsbos/runtime/

Die Anpassung der Servernamen vollzieht am besten mit einem Shell-Skript, in dem die Beispielnamen durch die realen Servernamen bzw. DNS-Einträge ersetzt werden. Im unten angeführten Beispiel-Shell-Skript werden z.B. die verschiedenen Datenbank-Servernamen (z.B. adminportal.database.example.com, site.database.example.com) auf einen einzigen Servernamen database.gsbos-test.de abgebildet.

Bei der Ersetzung der Servernamen muss beachtet werden, dass hier teilweise eine interne Kommunikation ohne „Umweg“ über den HTTPD-Server betroffen ist, teilweise aber auch URLs konfiguriert werden, bei denen ein abgehender Request über den HTTPD-Server anhand des Servernamens in der URL dem entsprechenden Service zugewiesen wird (z.B. https://caspreview.service.example.com/cas).

Bei interner Kommunikation kann als Zielname der reale Servername verwendet werden (z.B. bei Installation auf einem einzelnen Server immer dessen Servername). Bei Kommunikation über den HTTPD muss jedoch ein Name verwendet werden, anhand dessen das Routing erfolgen kann, auch wenn die IP-Auflösung zum gleichen Server führt.

Die Unterscheidung von interner und externer Kommunikation erfolgt anhand der angehängten Kommunikations-Ports. Im Beispiel-Shell-Skript werden alle internen Kommunikationen auf den Zielservernamen server.gsbos-test.de (bzw. database.gsbos-test.de für Datenbankserver) geändert. Allerdings gibt es auch Sonderfälle, z.B. im Adminportal oder im GSB Editor.

Shell-Skript setServerNames.sh zum Anpassen der Servernamen

#!/bin/bash

#Interne Kommunikation
sed -i "s/adminportal\.preview\.example\.com$:[0-9]\{1,5\}$/server.gsbos-test.de\1/g" $1
sed -i "s/adminportal\.service\.example\.com$:[0-9]\{1,5\}$/server.gsbos-test.de\1/g" $1
sed -i "s/caslive\.service\.example\.com$:[0-9]\{1,5\}$/server.gsbos-test.de\1/g" $1
sed -i "s/caspreview\.service\.example\.com$:[0-9]\{1,5\}$/server.gsbos-test.de\1/g" $1
sed -i "s/cmisserver\.service\.example\.com$:[0-9]\{1,5\}$/server.gsbos-test.de\1/g" $1
sed -i "s/editor\.preview\.example\.com$:[0-9]\{1,5\}$/server.gsbos-test.de\1/g" $1
sed -i "s/indexer\.preview\.example\.com$:[0-9]\{1,5\}$/server.gsbos-test.de\1/g" $1
sed -i "s/eventdispatcher\.preview\.example\.com$:[0-9]\{1,5\}$/server.gsbos-test.de\1/g" $1
sed -i "s/maildistributor\.service\.example\.com$:[0-9]\{1,5\}$/server.gsbos-test.de\1/g" $1
sed -i "s/newsletter\.preview\.example\.com$:[0-9]\{1,5\}$/server.gsbos-test.de\1/g" $1
sed -i "s/repository\.master\.example\.com$:[0-9]\{1,5\}$/server.gsbos-test.de\1/g" $1
sed -i "s/repository\.preview\.example\.com$:[0-9]\{1,5\}$/server.gsbos-test.de\1/g" $1
sed -i "s/repository\.replication\.example\.com$:[0-9]\{1,5\}$/server.gsbos-test.de\1/g" $1
sed -i "s/serviceportal\.service\.example\.com$:[0-9]\{1,5\}$/server.gsbos-test.de\1/g" $1
sed -i "s/site1\.master\.example\.com$:[0-9]\{1,5\}$/server.gsbos-test.de\1/g" $1
sed -i "s/site1\.replication\.example\.com$:[0-9]\{1,5\}$/server.gsbos-test.de\1/g" $1
sed -i "s/site2\.master\.example\.com$:[0-9]\{1,5\}$/server.gsbos-test.de\1/g" $1
sed -i "s/site2\.replication\.example\.com$:[0-9]\{1,5\}$/server.gsbos-test.de\1/g" $1
sed -i "s/site\.preview\.example\.com$:[0-9]\{1,5\}$/server.gsbos-test.de\1/g" $1
sed -i "s/solr\.master\.example\.com$:[0-9]\{1,5\}$/server.gsbos-test.de\1/g" $1
sed -i "s/solr\.preview\.example\.com$:[0-9]\{1,5\}$/server.gsbos-test.de\1/g" $1
sed -i "s/solr\.replication\.example\.com$:[0-9]\{1,5\}$/server.gsbos-test.de\1/g" $1
sed -i "s/indexer\.master\.example\.com$:[0-9]\{1,5\}$/server.gsbos-test.de\1/g" $1
sed -i "s/userservicelive\.service\.example\.com$:[0-9]\{1,5\}$/server.gsbos-test.de\1/g" $1
sed -i "s/userservicepreview\.service\.example\.com$:[0-9]\{1,5\}$/server.gsbos-test.de\1/g" $1
sed -i "s/workflow\.preview\.example\.com$:[0-9]\{1,5\}$/server.gsbos-test.de\1/g" $1

sed -i "s/adminportal\.database\.example\.com$:[0-9]\{1,5\}$/database.gsbos-test.de\1/g" $1
sed -i "s/maildistributor\.database\.example\.com$:[0-9]\{1,5\}$/database.gsbos-test.de\1/g" $1
sed -i "s/serviceportal\.database\.example\.com$:[0-9]\{1,5\}$/database.gsbos-test.de\1/g" $1
sed -i "s/site\.database\.example\.com$:[0-9]\{1,5\}$/database.gsbos-test.de\1/g" $1
sed -i "s/userservicelive\.database\.example\.com$:[0-9]\{1,5\}$/database.gsbos-test.de\1/g" $1
sed -i "s/userservicepreview\.database\.example\.com$:[0-9]\{1,5\}$/database.gsbos-test.de\1/g" $1
sed -i "s/workflow\.database\.example\.com$:[0-9]\{1,5\}$/database.gsbos-test.de\1/g" $1

# Externe Kommunikation
sed -i "s/$https\?\:\/\/\|DNS\.[0-9]\+\s*=\s*$adminportal\.service\.example\.com/\1adminportal.service.gsbos-test.de/g" $1
sed -i "s/$https\?\:\/\/\|DNS\.[0-9]\+\s*=\s*$caslive\.service\.example\.com/\1caslive.service.gsbos-test.de/g" $1
sed -i "s/$https\?\:\/\/\|DNS\.[0-9]\+\s*=\s*$caspreview\.service\.example\.com/\1caspreview.service.gsbos-test.de/g" $1
sed -i "s/$https\?\:\/\/\|DNS\.[0-9]\+\s*=\s*$editor\.preview\.example\.com/\1editor.preview.gsbos-test.de/g" $1
sed -i "s/$https\?\:\/\/\|DNS\.[0-9]\+\s*=\s*$piwik\.example\.com/\1piwik.gsbos-test.de/g" $1
sed -i "s/$https\?\:\/\/\|DNS\.[0-9]\+\s*=\s*$cmisserver\.service\.example\.com/\1cmisserver.service.gsbos-test.de/g" $1
sed -i "s/$https\?\:\/\/\|DNS\.[0-9]\+\s*=\s*$serviceportal\.service\.example\.com/\1serviceportal.service.gsbos-test.de/g" $1
sed -i "s/$https\?\:\/\/\|DNS\.[0-9]\+\s*=\s*$preview\.standardlsg\.example\.com/\1preview.standardlsg.gsbos-test.de/g" $1
sed -i "s/$https\?\:\/\/\|DNS\.[0-9]\+\s*=\s*$preview-subsite\.standardlsg.example\.com/\1preview-subsite.standardlsg.gsbos-test.de/g" $1
sed -i "s/$https\?\:\/\/\|DNS\.[0-9]\+\s*=\s*$editor\.standardlsg\.example\.com/\1editor.standardlsg.gsbos-test.de/g" $1
sed -i "s/$https\?\:\/\/\|DNS\.[0-9]\+\s*=\s*$live\.standardlsg\.example\.com/\1live.standardlsg.gsbos-test.de/g" $1

# Sonderfall AdminPortal
sed -i "s/$web\.server\.host\s*=\s*$adminportal\.service\.example\.com/\1adminportal.service.gsbos-test.de/g" $1

# Sonderfall GSBEditor
sed -i "s/$gsbeditor\.customer\.servername\.standardlsg\s*=\s*$editor\.standardlsg\.example\.com/\1editor.standardlsg.gsbos-test.de/g" $1
sed -i "s/$gsbeditor\.adminportal\.url\s*=\s*$adminportal\.preview\.example\.com/\1adminportal.service.gsbos-test.de/g" $1

# Hostnamen
sed -i "s/mail\.extern\.example\.com/mail.extern.gsbos-test.de/g" $1
sed -i "s/adminportal\.preview\.example\.com/server.gsbos-test.de/g" $1
sed -i "s/adminportal\.service\.example\.com/server.gsbos-test.de/g" $1
sed -i "s/caslive\.service\.example\.com/server.gsbos-test.de/g" $1
sed -i "s/caspreview\.service\.example\.com/server.gsbos-test.de/g" $1
sed -i "s/cmisserver\.service\.example\.com/server.gsbos-test.de/g" $1
sed -i "s/editor\.preview\.example\.com/server.gsbos-test.de/g" $1
sed -i "s/indexer\.preview\.example\.com/server.gsbos-test.de/g" $1
sed -i "s/maildistributor\.service\.example\.com/server.gsbos-test.de/g" $1
sed -i "s/newsletter\.preview\.example\.com/server.gsbos-test.de/g" $1
sed -i "s/repository\.master\.example\.com/server.gsbos-test.de/g" $1
sed -i "s/repository\.preview\.example\.com/server.gsbos-test.de/g" $1
sed -i "s/repository\.replication\.example\.com/server.gsbos-test.de/g" $1
sed -i "s/serviceportal\.service\.example\.com/server.gsbos-test.de/g" $1
sed -i "s/site1\.master\.example\.com/server.gsbos-test.de/g" $1
sed -i "s/site1\.replication\.example\.com/server.gsbos-test.de/g" $1
sed -i "s/site2\.master\.example\.com/server.gsbos-test.de/g" $1
sed -i "s/site2\.replication\.example\.com/server.gsbos-test.de/g" $1
sed -i "s/site\.preview\.example\.com/server.gsbos-test.de/g" $1
sed -i "s/solr\.master\.example\.com/server.gsbos-test.de/g" $1
sed -i "s/solr\.preview\.example\.com/server.gsbos-test.de/g" $1
sed -i "s/solr\.replication\.example\.com/server.gsbos-test.de/g" $1
sed -i "s/userservicelive\.service\.example\.com/server.gsbos-test.de/g" $1
sed -i "s/userservicepreview\.service\.example\.com/server.gsbos-test.de/g" $1
sed -i "s/workflow\.preview\.example\.com/server.gsbos-test.de/g" $1

# Domain
sed -i "s/$*\.\|@\|=\s*$example\.com/\1gsbos-test.de/g" $1

Erstellen Sie das Skript setServerNamesRuntime.sh im Home-Verzeichnis des gsbos-Nutzers mit dem oben angegebenen Inhalt und passen Sie die Ziel-Servernamen ihrer Umgebung an.

Starten Sie dann das Skript mit folgenden Kommandos:

chmod +x ~gsbos/setServerNamesRuntime.sh
find /opt/gsbos/runtime/ $ -name "*.conf" -or -name "*.properties" -or -name "*.env" $ -exec ~gsbos/setServerNamesRuntime.sh {} \;

Weiterhin befinden sich auch im Verzeichnis /opt/gsbos/software/httpd Dateien, in denen die Domänen-Namen eingetragen sind. Auch diese Namen müssen angepasst werden.

Erstellen Sie dazu das Skript setServerNamesSoftware.sh im Home-Verzeichnis des gsbos-Nutzers mit dem folgenden Inhalt und passen Sie die Ziel-Servernamen ihrer Umgebung an.

#!/bin/bash

sed -i "s/adminportal\.service\.example\.com/adminportal.service.gsbos-test.de/g" $1

sed -i "s/caslive\.service\.example\.com/caslive.service.gsbos-test.de/g" $1

sed -i "s/caspreview\.service\.example\.com/caspreview.service.gsbos-test.de/g" $1

sed -i "s/serviceportal\.service\.example\.com/serviceportal.service.gsbos-test.de/g" $1

sed -i "s/cmisserver\.service\.example\.com/cmisserver.service.gsbos-test.de/g" $1

sed -i "s/editor\.standardlsg\.example\.com/editor.standardlsg.gsbos-test.de/g" $1

sed -i "s/preview\.standardlsg\.example\.com/preview.standardlsg.gsbos-test.de/g" $1

sed -i "s/preview-subsite\.standardlsg\.example.com/preview-subsite.standardlsg.gsbos-test.de/g" $1

sed -i "s/live\.standardlsg\.example\.com/live.standardlsg.gsbos-test.de/g" $1

Führen Sie das Skript mit folgenden Kommandos aus:

chmod +x ~gsbos/setServerNamesSoftware.sh
find /opt/gsbos/software/httpd/ -name "*.conf" -exec ~gsbos/setServerNamesSoftware.sh {} \;

Für die Standardlösung existiert eine Definitionsdatei /opt/gsbos/software/httpd/conf/variables/standardlsg_variables.conf, in der die zugehörigen Servernamen definiert werden (*-servername), allerdings fehlen dort die Definitionen für die jeweiligen Serveralias-Werte (*-serveralias). Diese müssen auf den gleichen Wert wie der zugehörige Servername gesetzt werden.

Sofern der Pseudomandant https benutzt wird, muss auch in diesem der Servername angepasst werden. Die Konfigurationseinstellung befindet sich in der Datei /opt/gsbos/software/httpd/conf/vhosts/https/https_vhost.conf, d.h. nicht im Runtime-Bereich. Tragen Sie dort unter ServerName den/einen Servernamen bzw. DNS-Namen ein, unter dem der HTTPD-Server erreichbar ist. Dieser Name muss auch im selbstgenerierten SSL/TLS-Zertifikat eingetragen werden, falls Sie ein solches einsetzen (s. nächster Abschnitt).

Aufgrund der geänderten Servernamen muss ein selbstgeneriertes Server-Zertifikat bzw. der Keystore neu erstellt werden.

Wechseln Sie dazu in das Verzeichnis /opt/gsbos/runtime/certificates/ und starten danach die Zertifikatserzeugung:

cd /opt/gsbos/runtime/certificates/

rm keystore.p12

chmod +x generateCert.sh

./generateCert.sh

MariaDB

Bei Verwendung einer MariaDB müssen die JDBC-URLs und die JDBC-Treiber-Klasse in den Konfigurationsdateien angepasst werden.

Erstellen Sie dazu ein Skript setJDBCDriver.sh im Home-Verzeichnis des gsbos-Nutzers mit dem oben folgenden Inhalt:

#!/bin/bash

sed -i "s/com\.mysql\.jdbc\.Driver/org.mariadb.jdbc.Driver/g" $1

sed -i "s/com\.mysql\.cj\.jdbc\.Driver/org.mariadb.jdbc.Driver/g" $1

sed -i "s/hibernate\.dialect\.MySQL57Dialect/hibernate.dialect.MariaDB103Dialect/g" $1

sed -i "s/^$spring\.datasource\.url=$jdbc:mysql:$.*$/\1jdbc:mariadb:\2\&useMysqlMetadata=true/g" $1

sed -i "s/^$jdbc\.default\.url=$jdbc:mysql:$.*$\&useSSL=false/\1jdbc:mariadb:\2/g" $1

Starten Sie dann das Skript mit folgenden Kommandos:

chmod +x ~gsbos/setJDBCDriver.sh
find /opt/gsbos/runtime/ -name *.properties -exec ~gsbos/setJDBCDriver.sh {} \;

Der JDBC-Treiber selbst muss sich im zentralen Bibliotheksverzeichnis /opt/gsbos/lib befinden.

Für das Adminportal wird noch die Bibliothek mariadb.jar aus dem Liferay-Tomcat-Paket benötigt. Extrahieren Sie diese mit dem folgenden Kommando:

tar -C /opt/gsbos/software/adminportal/lib/ --strip-components=4 -xvzf /tmp/downloads/liferay-ce-portal-tomcat-7.1.3-ga4-20190508171117552.tar.gz liferay-portal-7.1.3-ga4/tomcat-9.0.17/lib/ext/mariadb.jar

Einrichten der Unit-Files

Um das Starten und Stoppen der Komponenten zu vereinfachen, sind im Release exemplarische systemd Unit-Files enthalten, welche für die Einrichtung entsprechender Start- und Stopp-Services verwendet werden können. Zusätzlich ermöglicht die Verwendung zugehöriger Targets über einen einzigen Aufruf das Starten und Stoppen kompletter Umgebungen oder Teilen davon .

Die Nutzung von systemd erfordert entweder Systemadministratorenrechte (root) oder eine entsprechende sudoers-Konfiguration.

Die Vorlagen sind im GSB Kern im Infrastructure-Artefakt unterhalb des Verzeichnisses infrastructure/systemd zu finden. Für jede Service-Typ Art gibt es eine Vorlage, die bei der Installation der Service-Typen genutzt wird. Im Einzelnen gibt es folgende Vorlagen:

application: Die Dateien application@.service und application.target können für alle APPLICATION basierten Service-Typen genutzt werden.
solr: Die Dateien solr@.service und solr.target können für den Solr Service-Typen benutzt werden.
tomcat: Die Dateien tomcat@.service und tomcat.target können für alle TOMCAT basierten Service-Typen genutzt werden.

Eine Übersicht über die vorhandenen GSB Service-Typen und eine Zuordnung der Art und der jeweils enthaltenen GSB Applikation findet sich in der Tabelle der Service-Typen (siehe „Im GSB-Kern definierte Service-Typen“). Für den Site Service-Typen (Art=TOMCAT) müssen z.B. die Dateien tomcat@service und tomcat.target als site@.service und site.target nach /etc/systemd/system kopiert werden, um den site Service-Typen unter die Kontrolle von systemd zu stellen. Anschließend können die Site-Tomcat-Instanzen mit Hilfe von systemd gestartet und gestoppt werden..

Voraussetzung dafür ist natürlich, dass die Standardverzeichnisse während der Installation verwendet wurden. Andernfalls ist die Service-Datei vorher entsprechend anzupassen.

Auf einem Server müssen Service-Units und Service-Targets für alle Service-Typen angelegt werden, die auf diesem Server betrieben werden.

Die Solr basierte Suche im GSB wird mit Hilfe der Standalone Solr-Applikation betreiben, d.h. die Solr-Applikation wird nicht in einem Tomcat-Server betrieben sondern wird als Self-Contained Applikation mit einem Embedded Jetty-Server ausgeführt. Im Release stehen mit den Dateien solr@.service und solr.target spezielle Vorlagen für die systemd-Einbindung der GSB Solr-Server zur Verfügung. Diese sind ebenfalls im Ordner /etc/systemd/system abzulegen, um Solr unter die Kontrolle von systemd stellen zu können.

Das Einrichten und Aktivieren der Service-Units erfolgt mit dem root-User. Für eine vollständige Installation aller Service-Typen sind die Vorlagen folgendermaßen zu kopieren:

cd ~gsbos/releases/core/10.1.0/infrastructure/systemd/

cp gsbos.target /etc/systemd/system/gsbos.target

cp tomcat@.service /etc/systemd/system/adminportal@.service

cp tomcat.target /etc/systemd/system/adminportal.target

cp tomcat@.service /etc/systemd/system/site@.service

cp tomcat.target /etc/systemd/system/site.target

cp application@.service /etc/systemd/system/cas@.service

cp application.target /etc/systemd/system/cas.target

cp application@.service /etc/systemd/system/cmis-client@.service

cp application.target /etc/systemd/system/cmis-client.target

cp application@.service /etc/systemd/system/cmis-server@.service

cp application.target /etc/systemd/system/cmis-server.target

cp application@.service /etc/systemd/system/editor@.service
cp application.target /etc/systemd/system/editor.target

cp application@.service /etc/systemd/system/eventdispatcher@.service

cp application.target /etc/systemd/system/eventdispatcher.target

cp application@.service /etc/systemd/system/gsbshell@.service

cp application.target /etc/systemd/system/gsbshell.target

cp application@.service /etc/systemd/system/indexer@.service

cp application.target /etc/systemd/system/indexer.target

cp application@.service /etc/systemd/system/maildistributor@.service

cp application.target /etc/systemd/system/maildistributor.target

cp application@.service /etc/systemd/system/repository@.service

cp application.target /etc/systemd/system/repository.target

cp application@.service /etc/systemd/system/serviceportal@.service

cp application.target /etc/systemd/system/serviceportal.target

cp application@.service /etc/systemd/system/userservice@.service

cp application.target /etc/systemd/system/userservice.target

cp application@.service /etc/systemd/system/workflow@.service
cp application.target /etc/systemd/system/workflow.target

cp solr@.service /etc/systemd/system/solr@.service

cp solr.target /etc/systemd/system/solr.target

Die einzelnen Service-Instanzen werden mit dem systemctl-Kommando eingerichtet:

systemctl enable adminportal@adminportal-service

systemctl enable cas@caslive-service

systemctl enable cas@caspreview-service

systemctl enable cmis-client@cmisclient-service

systemctl enable cmis-server@cmisserver-service

systemctl enable editor@editor-preview

systemctl enable eventdispatcher@eventdispatcher-preview

systemctl enable gsbshell@gsbshell

systemctl enable indexer@indexer-master

systemctl enable indexer@indexer-preview

systemctl enable maildistributor@maildistributor-service

systemctl enable repository@repository-master

systemctl enable repository@repository-preview

systemctl enable repository@repository-replication

systemctl enable serviceportal@serviceportal-service

systemctl enable site@site1-master

systemctl enable site@site1-preview

systemctl enable site@site1-replication

systemctl enable site@site2-master

systemctl enable site@site2-preview

systemctl enable site@site2-replication

systemctl enable site@sitenewsletter-preview

systemctl enable solr@solr-master

systemctl enable solr@solr-preview

systemctl enable solr@solr-replication

systemctl enable userservice@userservicelive-service

systemctl enable userservice@userservicepreview-service

systemctl enable workflow@workflow-preview

Der Service httpd wurde bereits mit der Installation des Apache HTTPD eingerichtet.

CentOS

Im CentOS-Betriebssystem ist der Schreibzugriff für den HTTPD-Server auf das Log-Verzeichnis /space/gsbos/logs beschränkt, sofern der HTTPD-Server als Systemdienst unter dem Konto apache läuft.Um dem HTTPD-Server dort Schreibrechte zu erteilen führen Sie bitte folgende Kommandos (als root-User) aus:

mkdir -p /space/gsbos/logs/httpd

semanage fcontext -a -t httpd_sys_rw_content_t /space/gsbos/logs/httpd

restorecon -R -v /space/gsbos/logs/httpd

Weiterhin ist standardmäßig die lokale Firewall aktiv, die verhindert, dass von außen auf das System zugegriffen wird. Um die http- und https-Kommunikation mit dem Server zu ermöglichen, müssen die entsprechenden Ports geöffnet werden. Führen Sie dazu die folgenden Kommandos aus:

firewall-cmd --zone=public --permanent --add-service=http

firewall-cmd --zone=public --permanent --add-service=https

firewall-cmd --reload

Starten und Stoppen per systemctl

Nach der Einrichtung der Service-Units können die einzelnen Instanzen mittels des Befehls systemctl gestartet oder gestoppt werden:

Starten und Stoppen von GSB Diensten

sudo systemctl start site@site1-preview.service

sudo systemctl stop site@site1-preview.service

sudo systemctl start site@site2-preview.service

sudo systemctl stop site@site2-preview.service

Der erste Teil der Service-Bezeichnung vor dem ‚@‘ gibt den Namen des Service-Typen an welcher gestartet oder gestoppt werden soll. Dieser wird verwendet um das Installationsverzeichnis des Service-Typs zu ermitteln. Bei Verwendung der Standardpfade wäre im oben genannten Fall das Verzeichnis

/opt/gsbos/software/site

Der zweite Teil site1-preview oder site2-preview gibt den Namen der Instanz an welche gestartet oder gestoppt werden soll. Dieser wird sowohl für die Identifikation der zugehörigen Runtime-Konfiguration

/opt/gsbos/runtime/site1-preview
/opt/gsbos/runtime/site2-preview

als auch für die Festlegung des data-Verzeichnisses der Service-Instanz verwendet (Speicherung von Bewegungsdaten). Bei Verwendung der Standardpfade ergibt sich für die obigen Beispiele:

/space/gsbos/data/site1-preview
/space/gsbos/data/site2-preview

Über das Target des Service-Typs können alle gestarteten Service-Instanzen gleichzeitig gestoppt werden. Für den Service-Typ „site“ ist dies das folgende Kommando:

Stoppen aller Site-Tomcats

sudo systemctl stop site.target

Für eine minimale Testumgebung mit Admin-Portal, Editor, Workflow, Preview- und Live-Umgebung sind die folgenden Service-Instanzen zu starten:

systemctl start adminportal@adminportal-service

systemctl start cas@caspreview-service

systemctl start editor@editor-preview

systemctl start eventdispatcher@eventdispatcher-preview

systemctl start indexer@indexer-master

systemctl start indexer@indexer-preview

systemctl start maildistributor@maildistributor-service

systemctl start repository@repository-master

systemctl start repository@repository-preview

systemctl start serviceportal@serviceportal-service

systemctl start site@site1-master

systemctl start site@site1-preview

systemctl start site@sitenewsletter-preview

systemctl start solr@solr-master

systemctl start solr@solr-preview

systemctl start userservice@userservicepreview-service

systemctl start workflow@workflow-preview

systemctl start httpd

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.

Ein Shortcut für den Import des Content und der Benutzer- und Gruppen findet sich im Mandanten in der Datei infrastructure/importCustomer.gsbshell. Diese Datei kann als GSB-Shell Input für einen Komplettimport des Mandanten durchzuführen.

Das folgende Kommando führt nach Anpassung der Server-Urls den Import durch:

cd /home/gsbos/releases/customers/standardlsg/10.1.0/infrastructure

/opt/gsbos/software/gsbshell/bin/gsbshell @importCustomer.gsbshell

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.zip enthält den redaktionellen Content des Mandanten
editor.zip enthält die Mandantenkonfiguration des Editors

Auf dieser Maschine wird der Content des Mandanten über das importcontent Kommando der GSB Shell importiert.

importcontent --file <FILENAME>.zip

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/logs/repository-preview zu finden.

Direkte Publikation

Der zu importierende Content kann direkt und unmittelbar beim Import in das Content-Repository des Redaktionssystems durchgeführt werden. Damit eine Publikation erfolgreich durchgeführt werden kann, muss das Content-Repository des Master-Servers gestartet sein, um die Publikation vom Redaktionssystem in das Live-System entgegennehmen zu können. Die ggf. in der Infrastruktur vorhandenen Replication-Server müssen bei der Publikation nicht zwingend verfügbar sein, da eine Replikation des publizierten Contents vom Master- auf die Replication-Server unabhängig von der eigentlichen Publikation auf den Master-Server durchgeführt wird.
Um beim Content-Import zusätzlich eine Publikation durchzuführen, wird der Parameter --publish genutzt (s.a. folgendes Beispiel).

importcontent --publish --file <FILENAME>.zip

Der Importprozess und der Fortschritt des Import- und Publikationsprozesses kann am einfachsten auf Basis der Logdateien der beteiligten Repository-Server nachvollzogen werden. Um bspw. die Replikation nachzuvollziehen muss der Log-Level des Replication-Packages auf info gesetzt werden. Die Logback-Konfiguration des Repositories ist in der Datei /opt/gsbos/software/repository/logback-spring.xml definiert.

<logger name="de.bund.gsb.replication" level="info" />

Abschließende Contentanpassung

Nach dem initialen Import des Contents eines GSBOS Mandanten müssen im Content noch einige redaktionelle Änderungen über den GSBOS Editor durchgeführt werden. Der Content der Standardlösung enthält einige Servernamen gemäß der exemplarischen Beispielkonfiguration, die auf die konkreten Namen der jeweiligen Hostinginfrastruktur anzupassen sind.

Die Editorkonfiguration des Mandanten enthält im Dokument __EditorConfig/Json/Categories/Preview/PreviewConfiguration noch eine Auflistung der Servernamen aller Sites (Hauptmandant und Subsites) des jeweiligen Mandanten. Die Standardlösung definiert hier bspw. die Namen preview.standardlsg.example.com (Hauptmandant) und preview-subsite.standardlsg.example.com (exemplarische Subsite). Die 'url'-Attribute des JSON-Arrays müssen an die jeweilige Infrastruktur angepasst werden.

Das Dokument _config/AdditionalResponseHeaders_editor enthält für einige Response-Header Attribute noch die Defintion des Servernamens für den Editor. Hier muss der Name der exemplarischen Runtime (editor.standardlsg.example.com) auf den passenden Namen der Hostinginfrastruktur angepasst werden.

Benutzer-, Gruppen und Rechte Einspielung

Die Benutzer und Gruppen eines Mandanten werden in dem User Service gepflegt. Nach dem erfolgreichen Import des Contents des Mandanten, muss die Rechtedefinition in das Redaktions-Repository eingespielt werden. Das Einspielen der Benutzer, Gruppen und Rechte erfolgt über das importsecurity Kommando der GSB Shell.

importsecurity --customer standardlsg --file security.xml

Der Befehl beinhaltet zwei Parameter:

file Pfad zur XML Datei der Rechtedefinition
customer Name des Mandanten. In dem oben genannten Beispiel ist dies der Mandant „standardlsg“.

Ersteinrichtung Adminportal

Für die Ersteinrichtung des Adminportal nach einer Installation ohne vorhandenen Datenbank-Stand sind nachfolgende Schritte auszuführen:

"Admin-Benutzer anlegen
"Erstmaliges Anmelden"
"Öffentliche Seiten anlegen"

Admin-Benutzer anlegen

Der Admin-Benutzer des Adminportals muss, falls noch nicht vorhanden, durch den Import der Rechtedefinition in das Redaktions-Repository angelegt werden. Das Einspielen von Benutzern, Gruppen und Rechten erfolgt über das importsecurity Kommando der GSBOS Shell.

importsecurity --customer adminportal --file adminportal.xml

Die Datei befindet sich im Kern unterhalb von infrastructure/security/

Der Befehl beinhaltet zwei Parameter:

file Pfad zur XML Datei der Rechtedefinition
customer Name des Mandanten. In dem oben genannten Beispiel ist dies der Mandant „adminportal“.

Das initiale Anlegen des Admin-Benutzers kann alternativ auch mit Hilfe des Gsbhsell-Skriptes initAdminportal.gsbshell (Ordner infrastructure/security) durchgeführt werden. In dem Gsbshell-Skript muss die URL zum Repository vor Aufruf der Gsbshell noch auf den plattformspezifischen Repository-Server angepasst werden.

Der Aufruf erfolgt über:

cd ~gsbos/releases/core/10.1.0/infrastructure/security /opt/gsbos/software/gsbshell/bin/gsbshell @initAdminportal.gsbshell

Erstmaliges Anmelden

Der erste Login erfolgt über den CAS mit Hilfe der Schaltfläche Anmelden im oberen rechten Bereich des Liferays, wie nachfolgend zu sehen. Hier ist der Mandant adminportal und der Benutzer admin auszuwählen, um das Liferay-Portal administrieren zu können.

Liferay Login Liferay-Login

Die Weiterleitung auf https://adminportal.service.example.com/admin wird bei der ersten Anmeldung nicht auffindbar sein, die Seite wird erst mit dem Import der öffentlichen Seiten angelegt. Nach einem erneuten Klick auf Anmelden kann oben links in der Leiste das seitliche Menü ausgeklappt werden.

Liferay Menü Liferay-Menü

Öffentliche Seiten anlegen

Die öffentlichen Seiten des Adminportals (Willkommen, Impressum, Kontakt) werden mit Hilfe des Imports eines LAR-Files (Liferay Archive File) erstellt. Dazu ist im Menü unter der aktuell gewählten öffentlichen Site mit Namen GSB der Menüpunkt Publikation → Importieren aufzurufen. Der Import wird wieder über das blaue Plus-Symbol am oberen Rand rechts eingeleitet.

Import der öffentlichen Seiten einleiten Import der öffentlichen Seiten einleiten

Für die öffentlichen Seiten ist das im Release enthaltene LAR-File createPublicWelcomePages.lar zu importieren (im Ordner core/<version>/infrastructure/adminportal). Nach Auswahl des LAR-Files und der Bestätigung über die Schaltfläche Fortfahren muss in der nächsten Ansicht noch die Checkbox Berechtigungen importieren aktiviert werden, bevor der Import über den Button Importieren durchgeführt werden kann.

Import der öffentlichen Seiten durchführen Import der öffentlichen Seiten durchführen

Beim Aufruf des Adminportals sollte die Startseite nun im GSB-Theme erscheinen.

Öffentliche Startseite Öffentliche Startseite

Ersteinrichtung Mandant

Für die Ersteinrichtung eines neuen Mandanten sind nachfolgende Schritte auszuführen:

„Benutzergruppe des Mandanten anlegen“
„Mandanten-Bereich (Site) mit privaten Seiten anlegen“
„Benutzergruppe dem Mandanten-Bereich zuweisen“
„Site-Admin Status einem Benutzer zuweisen“
„Synchronisation der Dateien und Ordner des Mandanten-Contents ins Serviceportal anstoßen (optional)“
„Einschränkung der Berechtigungen von Seiten des Mandanten-Bereichs zur Steuerung über Adminportal-Gruppen (optional)“

Benutzergruppe des Mandanten anlegen

Die Benutzergruppe des Mandanten wird mit dem Namen <mandantenName>-Users angelegt (z.B. standardlsg-Users). Dazu wird im Menü unter Kontrollbereich der Menüpunkt Benutzergruppen unterhalb von Benutzer aufgerufen und es wird die entsprechende Benutzergruppe über das blaue Plus-Symbol hinzugefügt.

Liferay-Benutzergruppenverwaltung öffnen Liferay-Benutzergruppenverwaltung öffnen

Mandanten-Benutzergruppe hinzufügen Mandanten-Benutzergruppe hinzufügen

Mandanten-Bereich (Site) mit privaten Seiten anlegen

Die Mandanten-Site wird im Kontrollbereich unter Sites → Seiten hinzugefügt (vgl. Abbildungen: „Mandanten-Site hinzufügen“, „Mandanten-Site speichern“). In der folgenden Ansicht wird als Seitenvorlage beim Anlegen einer Site der Typ Leere Site gewählt.

Mandanten-Site hinzufügen Mandanten-Site hinzufügen

Mandanten-Site speichern Mandanten-Site speichern

In der darauffolgenden Ansicht der Site-Einstellungen ist der Mitgliedschaftstyp auf Zugangsbeschränkt zu ändern und zu speichern.

Mandanten-Site Einstellungen Mandanten-Site-Einstellungen

Anschließend werden die privaten Seiten des Mandanten mit Hilfe des Imports eines LAR-Files erzeugt (vgl. Abschnitt „Öffentliche Seiten anlegen“). Für die privaten Seiten ist das im Release enthaltene LAR-File createPrivateCustomerPages.lar zu importieren. Dabei ist darauf zu achten, dass in der Importprozess-Ansicht die Radio-Option Private Seiten ausgewählt ist und nicht wie im vorherigen Abschnitt Öffentliche Seiten. Weiterhin sind hier auch wieder die Berechtigungen zu importieren (Checkbox).

Private Mandanten-Seiten importieren Private Mandanten-Seiten importieren

Private Mandanten-Seiten importieren 2 Private Mandanten-Seiten importieren (Forts.)

Benutzergruppe dem Mandanten-Bereich zuweisen

Die Mitgliedschaft von Benutzern zur Mandanten-Site wird über die bereits angelegt Benutzergruppe <mandantenName>-Users aufgelöst. Dazu muss diese Gruppe der soeben angelegten Mandanten-Site über die Site-Einstellungen zugeordnet werden: Menü → Mitglieder → Sitemitgliedschaften. Im Reiter Benutzergruppen ist die entsprechend passende Benutzergruppe über das Plus-Symbol hinzuzufügen.

Benutzergruppe hinzufügen Benutzergruppe hinzufügen

Site-Admin Status einem Benutzer zuweisen

Das Anlegen und Löschen von Benutzergruppen über die Gruppenverwaltung ist den Site-Administratoren vorbehalten, weshalb diese mit der Benutzergruppe siteAdmin ausgestattet werden müssen (vgl. Abschnitt „Benutzergruppe des Mandanten anlegen“).

Die Zuweisung von Benutzergruppen zu Benutzern ist im Menü → Kontrollbereich → Benutzer → Benutzer und Organisationen bei der Bearbeitung eines Benutzers möglich. Da die Benutzer-Accounts erst nach der erstmaligen Anmeldung im Liferay-Portal angelegt werden, ist ein An- und Abmelden mit den Site-Admin-Accounts notwendig, bevor die Benutzergruppe mit dem Admin-Account im Kontrollbereich zugeordnet werden kann.

Benutzergruppe zuweisen Site-Admin Status einem Benutzer zuweisen

Benutzergruppe zuweisen 2 Site-Admin Status einem Benutzer zuweisen (Forts.)

Synchronisation der Dateien und Ordner des Mandanten-Contents ins Serviceportal anstoßen (optional)

Um die einzelnen Funktions-Entitäten (Gästebuch, Bewert-/Kommentierbare Dokumente, Datentabellen, Umfragen, Mailing-Listen) des Mandanten in den einzelnen Portlets sichtbar zu machen, muss eine Synchronisierung zwischen Repository und Serviceportal mit Hilfe des Event-Dispatchers erfolgen. Wenn der Event-Dispatcher und das Serviceportal zum Zeitpunkt des Content-Imports aktiv sind, werden die importierten Dokumente automatisch ins Serviceportal übertragen. Falls der Content-Import des Mandanten erfolgt ist ohne dass Event-Dispatcher und Serviceportal verfügbar waren, kann der Synchronisationsprozess mit nachfolgendem curl-Befehl nachträglich auf der Kommandozeile der Plattform angestoßen werden. Dabei ist der Mandantenname <mandantenName> durch den Namen des Mandanten zu ersetzen.

curl --data "portalAssetsPath=%2F<mandantenName>&portalAssetsLimit=5000" http://localhost:6511/synchronizePortalAssets

für den Mandanten standardlsg also:

curl --data "portalAssetsPath=%2Fstandardlsg&portalAssetsLimit=5000" http://localhost:6511/synchronizePortalAssets

Die Beispiel-URL spricht den Event-Dispatcher auf der gleichen Maschine unter dem Standard-Port 6511 an.

Einschränkung der Berechtigungen von Seiten des Mandanten-Bereichs zur Steuerung über Adminportal-Gruppen (optional)

Ohne die Einschränkung der Berechtigung von Seiten des Mandanten-Bereichs können sich alle Benutzer und Benutzerinnen des Mandanten am Adminportal anmelden und haben den vollen Zugriff auf alle Administrations-Portlets.

Um die Steuerung der Berechtigungen mit Hilfe der Adminportal-Gruppen zu realisieren ist die generelle „Anzeigen“-Berechtigung für Site-Member in den Site-Einstellungen der Mandanten-Site von den betreffenden Seiten zu entfernen. Diese Berechtigung kann dann in einem zweiten Schritt wieder mit Hilfe einer Adminportal-Gruppe hinzugefügt werden, so dass nur Benutzer und Benutzerinnen dieser Adminportal-Gruppe Zugriff auf die Seite / das Administations-Portlet haben. Die erforderlichen Einstellungen werden anhand des folgenden Beispiels gezeigt:

Der Mandant soll so konfiguriert werden, dass alle Mandanten-Benutzer und -Benutzerinnen ohne Einschränkung auf das Benutzerprofil zugreifen können. Alle anderen Seiten sollen nur zugreifbar sein, wenn dem Benutzer / der Benutzerin die Adminportal-Gruppe site_admin zugeordnet wurde.

Mit dem Admin-Benutzer werden die Seiten der Site-Einstellungen der Mandaten-Site im Menü aufgerufen. Dort wird unterhalb der Private Seiten die Seite gewählt, für die die allgemeine „Anzeigen“-Berechtigung entfernt werden soll. Mit Auswahl einer Seite können die Berechtigung in den Details der Seite geöffnet werden (vgl. Abbildung: Seitenberechtigung öffnen).

Seitenberechtigung öffnen Seitenberechtigung öffnen

Das „Anzeigen“-Recht wird für die Rolle Site Member abgehakt und entfernt.

Seitenberechtigung setzen Seitenberechtigung setzen

Diese Aktion muss für alle Seiten wiederholt werden, die nicht automatisch zugreifbar sein sollen. Für das Beispiel also für alle Seiten außer „Benutzerprofil“.

Um die Beschränkung für ausgewählte Benutzer aufzuheben, sind in der Gruppenverwaltung zwei Adminportal-Gruppen anzulegen. Zum einen die allgemeine Gruppe adminportal, die die Wurzel der Adminportal-Gruppenhierarchie darstellt (analog zu mandant_standardlsg bei ContentServer-Gruppen) und zum anderen wird für das Beispiel die Gruppe site_admin hinzugefügt.

Als gewählter Gruppentyp im oberen rechten Bereich der Gruppenverwaltung muss Adminportal ausgewählt sein.

Adminportal-Gruppen hinzufügen Adminportal-Gruppen hinzufügen

Im Bereich der Rechteverwaltung werden die Regeln für die Seiten hinzugefügt, die mit der Gruppe site_admin aufrufbar sein sollen.

Rechte der Gruppe site_admin Rechte der Gruppe site_admin

Zuletzt muss die Adminportal-Gruppe noch über eine Rolle oder als Erweiterung den entsprechenden Benutzern zugeordnet werden, die Zugriff auf die in der Gruppe enthaltenen Seiten haben sollen.

Natürlich ist neben dem Beispiel auch eine feinere Aufteilung der Rechte mit Hilfe von mehreren Gruppen denkbar, beispielweise könnte es eine datentabellen_admin- und newsletter_admin-Gruppe geben oder aber eine benutzerverwaltung_admin-Gruppe, die den Zugriff auf Benutzer, Gruppen und Rollen gewährt.

Exemplarische Datentabelle/-Umfrage

Die Standardlösung enthält jeweils eine exemplarische Datentabelle und Umfrage im Content des Mandanten.

Um die benötigten Definitionen (Schema und exemplarische Beispieldaten) im Adminportal ebenfalls einfach anlegen zu können, beinhaltet die Standardlösung ein entsprechendes Shellskript mit dem die Erstellung und Befüllung der Datentabelle und Umfrage mit den Beispielwerten durchgeführt werden kann:

infrastructure/adminportal/importDatatableContent.sh

Die Datentabellen und Umfragedefinitionen im Adminportal sind mit den zugehörigen Dokumenten im Content des Mandanten über die Dokument-IDs verknüpft. D.h. das Skript wird mit den Dokument-IDs der exemplarischen Dokumente für die Datentabelle und Umfrage parametriert. Die Dokument-IDs sind erst nach Import des Content eines Mandanten bekannt, so dass diese vor Aufruf des Skriptes ermittelt werden müssen.

Es sind die Dokument-IDs der folgenden Dokumente zu ermitteln. Die Ids können mit dem Editor aus dem Content ausgelesen werden:

/standardlsg/_doc/Datentabelle/Datentabelle

/standardlsg/_doc/Umfrage/Umfrage

An erster Stelle wird die Dokument-Id des Datentabellen-Dokuments, danach die des Umfrage-Dokuments erwartet. D.h. das Skript wird wie folgt aufgerufen:

sh importDatatableContent.sh xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx yyyyyyyy-yyyy-yyyy-yyyyyyyyyyyy

Die im Aufruf skizzierten Dokument-IDs müssen durch die konkreten Dokument-IDs der beiden exemplarischen Dokumente ersetzt wie folgt ersetzt werden:

xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx = Id des Datentabellen-Dokuments

yyyyyyyy-yyyy-yyyy-yyyyyyyyyyyy = Id des Umfrage-Dokuments

Das Skript versucht per http (curl) mit dem Serviceportal zu kommunizieren. Die URL zum Serviceportal ist im Skript in der Variablen BASE_URL definiert. Die BASE_URL ist mit dem Namen des Serviceportals der exemplarischen Beispielkonfiguration vorbelegt, so dass der Wert ggf. an den konkreten Namen der jeweiligen Infrastruktur angepasst werden muss.

Nach erfolgreicher Ausführung sollten jeweils 6 Einträge für die Datentabelle / Umfrage angelegt worden sein.

Bereichsmenü

Betriebsmodell
GSB Kern
Adminportal
Editor
CMIS
Publikationsprozess
Mandanten
Migration
Best Practices:
- Sicherheit
- Installation - Schritt für Schritt
- Backup und Recovery
- Contentpatch
- JCR-Publisher
- Version Cleaner
Release Notes

GSB 7.0 Standardlösung

Suche

Hauptmenü

Nut­zung

Unternavigationspunkte

Be­trieb

Unternavigationspunkte

Ent­wick­lung

Unternavigationspunkte

Zielgruppe BetriebVersion: GSB10.1Installationsanleitung – Schritt für Schritt

Beistellungen

Java

Tomcat-Server

Solr-Server

Httpd-Server

Datenbanken

Exemplarische Konfiguration

Domainnamen und Zonen

Service- und Servernamen

Ports

Kommunikationsmatrix

Vorbereitung der Installation

Erforderliche Downloads

MariaDB

Installation von zusätzlichen Tools

Installation der Komponenten

Java

Tomcat-Server

Solr-Server

Httpd-Server

Datenbanken

Installation der Datenbank

MySQL

Oracle

Installation des GSB

Lizenzschlüssel

Benutzer

Verzeichnisse

Bewegungsdaten- und Datenverzeichnisse

Erstellung des Platform-Bundles

Konfigurationsdateien

gsbos_global.cfg

Beschreibung

Konfiguration

serviceTypes.cfg

Beschreibung

Konfiguration

platformBundle.cfg

Beschreibung

Konfiguration

Verwendung

Vorgehen zur Erstellung

Installation des Platform-Bundles

Konfigurationsdateien

Verwendung

Vorgehen zur Installation

Konfiguration

Einrichtung GSB Datenbanken

Einrichten der User/Schemata

Anlegen von MySQL Datenbanken

Erstellen/Aktualisieren der Tabellen

Runtime-Konfiguration

Zertifikat

Standalone Applikationen

Tomcat-Server

Httpd-Server

Solr-Server

Host-Datei

Konfiguration der Servernamen

Einrichten der Unit-Files

Starten und Stoppen per systemctl

Mandant Import

Mandanten Content Import

Direkte Publikation

Abschließende Contentanpassung

Benutzer-, Gruppen und Rechte Einspielung

Ersteinrichtung Adminportal

Admin-Benutzer anlegen

Erstmaliges Anmelden

Öffentliche Seiten anlegen

Nutzung

Betrieb

Entwicklung