GSB 7.0 Standardlösung

Installation

Die notwendigen Schritte zur Vorbereitung und zur Durchführung der Installation werden in diesem Kapitel vorgestellt. Die Installationsanleitung ist geeignet, um die Installation des GSB auf dem präferierten Betriebssystem Redhat Linux bzw. CentOS Linux einfach nachvollziehen zu können.

Weiterhin geht die Installationsanleitung davon aus, dass für die geforderten Beistellungen die Standard Pakete des Betriebssystems bzw. die von den jeweiligen Herstellern zur Verfügung gestellten RPMs genutzt werden. Die in der Installationsanleitung angesprochenen Pfade und die im GSB Release enthaltenen Vorlagen (bspw. für Service-Units) verwenden die Standard Pfade und Installationsverzeichnisse der Beistellungen.

1. Vorbereitung

Die Vorbereitung der Installation der GSB Infrastruktur erfordert die Bereitstellung einiger Beistellungen sowie der Runtime-Konfigurationen für die einzelnen Service-Instanzen.

1.1. Lizenzschlüssel

Der Betrieb des GSB erfordert eine gültige Lizenz, die vom GSB Produkthersteller ausgestellt wird. Für die Beantragung einer Lizenz wenden Sie sich bitte an die Mailadresse gsb@itzbund.de. Die Lizenzdaten sind anschließend in der Runtime-Konfiguration der Repository Webapplikation zu hinterlegen.

1.2. Beistellungen

Der GSB erfordert eine Reihe von Beistellungen deren Installation und Konfiguration in den folgenden Unterkapiteln beschrieben wird. Die in der Beschreibung benannten Links und Versionen stellen die zum Zeitpunkt der Erstellung dieser Dokumentation aktuellen Versionen dar.

1.2.1. Java

Der GSB benötigt eine Java 8 SE Runtime Edition für den Betrieb der Tomcat-Server basierten Service-Instanzen. Details zu den benötigten Versionen finden sich in der Tabelle Systemvoraussetzungen.

Das RPM für die zurzeit aktuelle Java Standard Edition kann per Download von Oracle Website bezogen werden.

Das RPM kann nach dem Download bspw. mit dem Kommando

Java RPM-Installation

sudo yum –y install <JAVA_SE_RPM>

installiert werden wobei das Token <JAVA_SE_RPM> durch den Pfad zum RPM ersetzt werden muss.

Die Java-Runtime ist nach Installation des RPM unterhalb des Pfades /usr/java/default zugreifbar und wird vom GSB auch in diesem Pfad erwartet, da dieser Pfad in den für den Start der GSB Tomcat-Service-Instanzen eingesetzten Systemd Service-Units gesetzt ist.

Das Java RPM kann auch auf anderen Linux Distributionen für die Installation genutzt werden, so dass an dieser Stelle keine distributionsspezifischen Besonderheiten zu berücksichtigen sind.

Sollte eine Installation von Java im Pfad /usr/java/default nicht möglich sein, dann muss die JAVA_HOME Variable in den GSB Systemd Service-Units entsprechend angepasst werden (Dateien /etc/systemd/system/<SERVICE_TYP>@.service).

1.2.2. Tomcat-Server

Der GSB benötigt einen Tomcat-Server für den Betrieb der GSB Webapplikationen. Details zu den benötigten Versionen finden sich in der Tabelle „Systemvoraussetzungen“.

Die einzelnen GSB Tomcat-Instanzen werden mit einer Tomcat Multi-Instance-Konfiguration betrieben. Details hierzu finden sich im Kapitel „Advanced Configuration - Multiple Tomcat Instances“ auf der Seite https://tomcat.apache.org/tomcat-8.5-doc/RUNNING.txt. Der Betrieb in einer Multi-Instance-Konfiguration hat den Vorteil, dass auf einem Server nur eine Tomcat-Installation durchgeführt wird und nicht für jede Tomcat-Instanz eine dedizierte Installation vorhanden sein muss.

Installation Tomcat-Server

Für den Zugriff auf den Tomcat per JMX muss zusätzlich noch das JMX-Remote-Jar installiert werden. Dieses Jar-File ist spezifisch für die jeweilige Tomcat-Version zu nutzten, so dass dieses zusammen mit der eingesetzten Tomcat-Version geladen und im Tomcat Lib-Ordner abgelegt werden muss.

Die für die Installation genutzte Tomcat-Server Version kann der Tabelle „Systemvoraussetzungen“ entnommen werden. Das in der weiteren Beschreibung genutzte Token <TOMCAT_VERSION> muss durch die gewünschte Tomcat-Server Version ersetzt werden.

Der Tomcat-Server wird unterhalb des Pfades /opt/software/tomcat installiert. Zusätzlich wird ein symbolischer Link von /opt/software/tomcat/default auf die einzusetzende Tomcat-Server Installation (bspw. /opt/software/tomcat/apache-tomcat-<TOMCAT_VERSION>) gesetzt, da innerhalb der für den Start der Komponenten eingesetzten Systemd Service-Units die Definitionen der Start- und Stopskripte (ExecStart und ExecStop) entsprechend definiert sind. Weiterhin können Tomcat-Server Updates einfacher vorbereitet und durchgeführt werden, da im Anschluss an die Installation nur der symbolische Link angepasst werden muss.

Sollte eine Installation des Tomcat-Servers im Pfad /opt/software/tomcat/default nicht möglich sein, dann kann auch ein anderer Pfad für die Installation genutzt werden. In diesem Fall muss anschließend die Definition der Start- und Stop-Skripte in den Variablen ExecStart und ExecStop in den Systemd Service-Units entsprechend angepasst werden.

Die folgenden Shell-Kommandos können für eine exemplarische Installation genutzt werden und müssen als User root ausgeführt werden:

export TC_VERSION=<TOMCAT_VERSION>

mkdir -p /opt/software/tomcat/

wget http://apache.mirror.digionline.de/tomcat/tomcat-8/v${TC_VERSION}/bin/apache-tomcat-${TC_VERSION}.tar.gz

tar -xfz apache-tomcat-${TC_VERSION}.tar.gz -C /opt/software/tomcat

wget http://apache.mirror.digionline.de/tomcat/tomcat-8/v${TC_VERSION}/bin/extras/catalina-jmx-remote.jar

cp catalina-jmx-remote.jar /opt/software/tomcat/apache-tomcat-${TC_VERSION}/lib

ln -s /opt/software/tomcat/apache-tomcat-${TC_VERSION} /opt/software/tomcat/default

Die Standard Tomcat-Installation kann bei Bedarf reduziert werden, da diese einige überflüssige Komponenten/Dateien enthält. Im Einzelnen können folgende Dateien oder Verzeichnisse gelöscht werden:

·         conf/*

·         webapps/docs

·         webapps/examples

Integration Datenbanktreiber

Weiterhin müssen im Libs-Verzeichnis des installierten Tomcat-Servers noch die Datenbanktreiber der zugrundeliegenden Datenbanken abgelegt werden. Die entsprechenden Treiber können von den Webseiten der Datenbankhersteller geladen werden. Hinweise zum Download können dem Abschnitt "Download Links" im Artikel Systemvoraussetzungen entnommen werden.

Der benötigte Treiber muss anschließend im Lib-Verzeichnis des Tomcat-Servers abgelegt werden. D.h. der Treiber muss in das Verzeichnis /opt/software/tomcat/apache-tomcat-<TOMCAT-VERSION>/lib kopiert werden.

1.2.3. Solr-Server

Der GSB benötigt einen Solr-Server für den Betrieb der GSB Suchfunktionen. Details zu der benötigten Solr-Version finden sich in der Tabelle „Systemvoraussetzungen“.

Die Solr-Infrastruktur wird ähnlich zur Tomcat-Infrastruktur aufgebaut, d.h. der eigentliche Solr-Server wird auf einem System nur einmal installiert, ermöglicht aber den Start und Betrieb mehrerer GSB Solr-Instanzen. Allgemeine Hinweise zur Installation des Solr-Server finden sich auf den Webseiten des Herstellers unter "Installing Solr".

Im folgenden Unterkapitel wird eine GSB konforme Installation des Solr-Servers beschrieben.

Installation Solr-Server

Die folgende Beschreibung zur Installation des Solr-Servers durch das vom Hersteller bereitgestellte Archiv (s.a. "Download Links") wird davon ausgegangen, dass das Archiv im /tmp-Ordner unter dem Namen solr-<SOLR_VERSION>.tgz abgelegt ist. Weiterhin muss für die Durchführung der Installation das Token <SOLR_VERSION> durch die gewünschte Solr-Version (s.a. „Systemvoraussetzungen“) ersetzt werden.

Die eigentliche Installation des Solr-Servers erfolgt im Ordner /opt/software/solr/solr-<SOLR_VERSION>. Durch Setzen eines symbolischen Links von /opt/software/solr/default auf das Installationsverzeichnis wird eine Installation bereitgestellt, die analog zur Tomcat-Server Installation durchgeführt wird. Hierdurch wird sichergestellt, dass

  • der Solr-Server analog zum Tomcat-Server abgelegt ist und somit eine geleichförmige und homogene Integration der GSB Service-Instanzen in die Betriebsprozesse umgesetzt werden kann sowie
  • ein einfaches Update bzw. Wechsel der Solr-Version durchgeführt werden kann.

Die Installation wird wie folgt durchgeführt:

Installation Solr-Server

export solr_version=<SOLR_VERSION>

export solr_archive=/tmp/solr-${solr_version}

export solr_install_dir=/opt/software/solr/

export solr_base=${solr_install_dir}/solr-${solr_version}

tar -xvf /tmp/${solr_archive} -C ${solr_install_dir} (1)

mkdir ${solr_base}/lib

cd ${solr_base}

cp ./contrib/analysis-extras/lib/icu4j-*.jar lib (2)

cp ./contrib/analysis-extras/lucene-libs/lucene-analyzers-icu-${solr_version}.jar lib

cp ./dist/solr-analysis-extras-${solr_version}.jar lib

ln -s /opt/software/solr/solr-${solr_version} /opt/software/solr/default (3)

1Entpacken der Archivdatei im Installationsordner (/opt/software/solr)
2Kopie benötigter Bibliotheken in einen zentralen Ordner (/opt/software/solr/solr-<SOLR_VERSION>/lib)
3Anlegen eines symbolischen Links von /opt/software/solr/default auf /opt/software/solr/solr-<SOLR_VERSION>

1.2.4. Httpd-Server

Der Httpd-Server kann am einfachsten aus dem RPM-Repository des zugrundeliegenden Linux Betriebssystems installiert werden. Hierbei ist zu beachten, dass neben dem eigentlichen Httpd-Server noch eine Reihe von Modulen für den Betrieb des GSB Httpd-Servers benötigt wird. Die benötigten Module sind in dem Redhat RPM bis auf das optional benötigte mod_ssl enthalten, und müssen daher nicht gesondert installiert werden.

sudo yum –y install httpd

sudo yum –y install mod_ssl

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

RedHat und CentOS verfolgen eine relativ konservative Stragie bzgl. der Aktualisierung von in den Distributionen enthaltenen Softwarepaketen. So wird über die OS-Repositories auch eine relativ alte Version des Httpd-Webservers installiert.

Das Community-Project "Inline with Upstream stable" stellt aktuelle Versionen ausgewählter Softwarepakete zur Verfügung. Hinweise zur Anbindung der IUS-Repositories finden sich auf der Seite "Getting Started",

Eine aktuelle Version des Httpd-Webservers kann über die IUS-Repositories installiert weden.

1.2.5. Optional: Manuelle Installation Httpd-Server

Wenn der Httpd-Server aus den Sourcen individuell übersetzt wird, dann werden noch weitere Dateien benötigt. Im Einzelnen handelt es sich um

Nachdem die benötigten Sourcen in einem Build-Verzeichnis entpackt worden sind, kann der Webserver wie auf http://httpd.apache.org/docs/current/de/install.html beschrieben kompiliert und installiert werden.

Benötigte Httpd-Module

Konfiguration des GSB httpd-Servers bzw. der eingesetzten VirtualHost-Definitionen setzt wie skizziert einige Module voraus. Die Liste der benötigten Module kann aus der Datei httpd/conf/include/loadModules.conf des GSB Kerns entnommen werden. Alle Module die in dieser Datei über die LoadModule-Direktive geladen werden, müssen im httpd-Server zur Verfügung stehen.

Die Modulliste ist für die Erstellung und Installation des Httpd-Servers aus den Sourcen relevant, die diese beim Configure- und Compile-Lauf mit übergeben werden müssen. Bei Verwendung des httpd-RPMs des zugrundeliegenden Betriebssystems sollten alle benötigten Module wie skizziert bereits mitinstalliert werden.

1.2.6. Datenbanken

Der GSB unterstützt die Datenbanken MySQL und Oracle. Die Installation der eigentlichen Datenbankserver kann anhand der Installationsanleitungen der Datenbankhersteller durchgeführt werden.

MySQL Datenbank

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

Oracle Datenbank

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

Einrichtung GSB Datenbanken

Nachdem der Datenbank-Server installiert ist, müssen die für den Betrieb des GSB benötigten Datenbanken eingerichtet werden. Die Einrichtung der Datenbanken wird über entsprechende SQL-Skripte durchgeführt.

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

Für jede einzurichtende Datenbank (bzw. GSB Komponente mit Datenbankunterstützung) ist ein Unterordner vorhanden in denen Skripte zum Anlegen der benötigten Datenbank(en) abgelegt sind (create<XYZ>DB.sql).

Bei Verwendung einer Oracle-Datenbank muss im Vorfeld noch der benötigte gsbos-Tablespace mit dem Skript createTablespace.sql angelegt werden. Der Vollständigkeit halber ist an dieser Stelle das Skript zum Anlegen des Oracle-Tablespace aufgeführt, um die Defaultwerte des exemplarischen Skriptes für die Einrichtung des Tablespace nutzen zu können.

createTablespace.sql

create bigfile tablespace gsbos

size 500M reuse autoextend on next 100M

maxsize unlimited extent management local segment space management auto;

1.2.7. Verzeichnisdienst

Die Installation des OpenLDAP-Servers erfolgt am einfachsten über das Paket-Repository des zugrundeliegenden Linux Betriebssystems. Details zur Installation und Administration des Verzeichnisdienstes finden sich auf der Seite http://www.openldap.org/doc/admin24/.

Installation LDAP-Server

sudo yum -y install openldap-servers openldap-clients

cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG

chown ldap /var/lib/ldap/DB_CONFIG

GSB LDAP-Konfiguration

Nach Installation des OpenLDAP-Verzeichnisdienst müssen noch einige GSB spezifische Konfigurationen, Schemamodifikationen durchgeführt werden.

Die Basiskonfiguration des OpenLDAP-Verzeichnisdienstes wird über GSB spezifische LDIF-Dateien durchgeführt. Diese finden sich im infrastructure-Artefakt, im Ordner infrastructure/ldap. Die darin enthaltenen Skripte sind durchnummeriert und müssen in der Reihenfolge der Nummerierung mit dem folgenden Kommando ausgeführt werden.

Import von LDIF-Dateien

ldapmodify -Y EXTERNAL -H ldapi:/// -f <LDIF-FILE>

Das Token <LDIF-FILE> wird durch den Pfad zur LDIF-Datei ersetzt.

Mandantenkonfiguration

Die Einrichtung der Gruppen und Benutzer eines GSB-Mandanten erfolgt ebenfalls mit dem oben aufgeführten Kommando. Die für die Einrichtung und Konfiguration der Standardlösung benötigten LDIF-Files befinden sich im Standardlösung Customer-Ordner im Verzeichnis infrastructure/ldap.

1.2.8. Runtime-Konfiguration

Die Runtime-Konfiguration der einzelnen GSB Service-Instanzen muss individuell für jede einzelne Instanz bereitgestellt werden. Der GSB Kern liefert eine exemplarische Runtime-Konfiguration die als Grundlage für die individuelle Erstellung der Runtime-Konfiguration genutzt werden kann.

Die Runtime-Konfigurationen der Service-Instanzen eines Systems werden im Ordner /opt/gsbos/runtime abgelegt. Für jede einzelne Service-Instanz existiert ein Unterordner, in dem die Service-Instanz spezifischen Konfigurationen abgelegt wird.

Der GSB Kern enthält Runtime-Konfigurationen für eine exemplarische GSB Infrastruktur, die als Grundlage für den Aufbau einer individuellen GSB Infrastruktur genutzt werden kann. Diese findet sich im infrastructure-Artefakt im Ordner infrastructure/runtime. Details zum Aufbau und Inhalt der Runtime-Konfiguration finden sich auf den Seiten zur Runtime-Konfiguration.

Der GSB stützt sich auf Httpd- und Tomcat-Server basierte Service-Instanzen, deren Konfigurationsschema im Folgenden vorgestellt wird.

1.2.9. Httpd-Server

Die Runtime-Konfiguration des Httpd-Servers umfasst ausschließlich die Balancer-Definitionen für die Anbindung der Tomcat-Server. Für jede logische Zone (live, preview, service) sind in der Vorlage entsprechende Balancer-Konfigurationen enthalten, die individuell anzupassen sind.

Die exemplarische Konfiguration des Live-Balancers (Datei infrastructure/runtime/live/balancer_live.conf) sieht wie folgt aus:

Webserver Balancer-Definition

# Setzen der Balancer Mitglieder,

# zum deaktivieren bitte auskommentieren,

# zum erweitern bitte eine BalancerMember Zeile kopieren und anpassen

<Proxy balancer://balancerlive>

  BalancerMember ajp://delivery1.master.example.com:7109 route=delivery1-master

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

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

  BalancerMember ajp://delivery2.replication.example.com:8119 route=delivery2-replication

  ProxySet nofailover=off

  ProxySet stickysession=JSESSIONID

</Proxy>

Der Live-Balancer besteht also aus vier Tomcats, die vom Httpd-Server eingebunden werden. Die Balancer-Member (=Tomcat-Server) sind jeweils unter einem dedizierten Namen und Port (Namen delivery[1|2].(master|replication).example.com, Ports: 7109…​ 8119) erreichbar. Für jeden Balancer-Member muss ein eindeutiger Name definiert werden, damit das Routing der Requests vom Httpd-Server „sticky“ erfolgen kann, d.h. nachfolgende Requests eines Browsers sollen immer an denselben Tomcat-Server weitergeleitet werden.

1.2.10. Tomcat-Server

Die Runtime-Konfiguration der Tomcat-Service-Instanzen umfasst

  • Tomcat-Properties: Diese Properties werden für die Konfiguration des Tomcat-Servers benötigt
  • Webapp-Properties: Für jede Webapplikation die in einem Tomcat betrieben wird ist ein applikationsspezifischer Satz von Properties vorhanden.

Der Aufbau der Runtime-Konfiguration einer Tomcat-Service-Instanz sieht damit am Beispiel der Instanz delivery1-master wie folgt aus:

  • delivery1-master

    • tomcat

      • env
      • properties
    • webapps

      • site

        • properties

Die Datei tomcat.env enthält mit der Variablendefinition CATALINA_OPTS alle instanzspezfischen Konfigurationen wie bspw. Memory-, Garbage-Collection-Settings.

Die Datei tomcat.properties enthält alle Properties die für die Tomcat-Konfiguration benötigt werden. Die zentralen anzupassenden Properties sind die hostname, port und jvmRoute-Properties (s.a. Auszug der Properties-Datei):

Auszug Tomcat-Runtime-Properties

tomcat.server.hostname=delivery.master.example.com

tomcat.server.port=7105

tomcat.server.shutdown=AGkkv,aSL!

tomcat.server.jvmRoute=delivery1-master

 

# Konfiguration Tomcat HTTP

tomcat.server.http.port=7101

 

# Konfiguration Tomcat AJP

tomcat.server.ajp.port=7109

 

# Konfiguration Tomcat JMX Remote Lifecycle Listener. Definiert die Ports fuer

# JMX/RMI Server Verbindung von Clients hinter einer Firewall

tomcat.server.jmxRemoteLifecycleListener.rmiRegistryPortPlatform=7103

tomcat.server.jmxRemoteLifecycleListener.rmiServerPortPlatform=7104

Die Properties Dateien der einzelnen Webapplikationen (im Beispiel delivery1-master/webapps/site/site.properties) sind individuell für die einzelnen Webapplikationen, so dass diese an dieser Stelle keine exemplarischen Beispiele vorgestellt werden können. Die wesentlichen Anpassungen in den webapplikationsspezifischen Properties betreffen Servernamen sowie Ports.

1.2.11. Solr-Server

Der GSB 10 nutzt eine aktuelle Solr Version, die ausschließlich als Standalone Applikation betrieben werden kann. Ein Betrieb als Webapplikation in einem Tomcat-Server ist nicht mehr möglich. Der Aufbau der Solr-Runtimekonfiguration weicht somit von dem der anderen Service-Instanzen ab. Die Runtime-Konfiguration der Solr-Service-Instanzen umfasst

  • Portdefinitionen für den Zugriff auf die Solr-Service-Instanz
  • Homeverzeichnis der GSB Solr-Installation

Der Aufbau der Runtime-Konfiguration einer Solr-Service-Instanz sieht damit am Beispiel der Instanz solr-replication wie folgt aus:

  • solr-replication

    • env

Die Datei env.env enthält alle Properties, die für die Solr-Konfiguration des Replication-Servers benötigt werden.

Auszug Solr-Runtime-Properties

SOLR_CONFIGSETS_DIR=/opt/gsbos/software/solr/configsets

SOLR_HOME=/opt/gsbos/software/solr/replication

SOLR_SHARED_LIB_DIR=/opt/software/solr/default/lib

 

SOLR_RMI_PORT=8403

# Sets the port Solr binds to, default is 8983

SOLR_PORT=8401

# Sets the port Solr binds to stop the server

SOLR_STOP_PORT=8405

 

# Solr-Replication-Configuration

# s.a.: http://lucene.apache.org/solr/guide/7_2/index-replication.html#configuring-the-replication-requesthandler-on-a-slave-server

SOLR_MASTER_HOST=solr.master.example.com

SOLR_MASTER_PORT=7401

SOLR_REPLICATION_INTERVAL=00:00:20

1.2.12. Host-Datei

Die in der exemplarischen Beispielkonfiguration/Infrastruktur verwendeten Hostnamen finden sich im Kernrelease im infrastructure-Artefakt im Verzeichnis infrastructure/etc und kann als Grundlage für die Erstellung der plattformspezifischen Hostdateien genutzt werden.

Die exemplarische Host-Datei enthält alle Servernamen, die in der exemplarischen Runtime-Konfiguration verwendet werden.

2. Benutzer

Die Installation des GSB und der GSB Komponenten erfolgt durch einen gsbos-Benutzer der auf den Servern eingerichtet werden muss. Der Nutzer ist wie folgt anzulegen:

Tabelle 1: gsbos-Benutzer

ParameterWert
LOGINgsbos
GROUPgsbos
HOME_DIR/home/gsbos
SHELL/bin/bash

3. Verzeichnisse

Die folgende Beschreibung geht davon aus, dass die GSB Komponenten als Benutzer „gsbos“ installiert werden. Für die Vorbereitung und Durchführung der Installation werden die folgenden Verzeichnisse benötigt:

Tabelle 2. Benötigte Verzeichnisse

VerzeichnisInhalt
/home/gsbos/configEnthä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/coreBasisverzeichnis 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/customersBasisverzeichnis 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/platformBundleDie auf der Hostingplattform erstellten und benötigten Platform-Bundles werden in diesem Verzeichnis abgelegt.
/home/gsbos/patchesVerzeichnis mit Patches, welche beim Erstellen des Platform-Bundles eingespielt werden sollen.
/opt/gsbosInstallationsverzeichnis der GSB Komponenten.
/opt/gsbos/runtimeRuntime-Konfigurationen der einzelnen GSB Komponenten werden in diesem Verzeichnis bereitgestellt.

Die Vorlagendateien und Beispielkonfigurationen gehen davon aus, dass der Tomcat-Server unter /opt/software/tomcat/default installiert ist. Ist dies nicht der Fall, dann sollte durch den Systembetrieb ein entsprechender symbolischer Link angelegt werden.

Das für die Installation zu verwende Release wird nach der oben definierten Struktur somit in /home/gsbos/releases/core/10.0.0 und /home/gsbos/releases/customers abgelegt werden.

4. Erstellung des Platform-Bundles

Die Installation des GSB auf einer produktiven Infrastruktur erfolgt mittels eines Platform-Bundles. Für die Erstellung eines Platform-Bundles werden Konfigurations-Dateien und ein Shell-Skript zur Erzeugung des Platform-Bundles benötigt. Ein PlatformBundle ist eine GSBOS Lieferung angepasst an eine definierte Plattform. Dabei wird über Konfigurationsdateien die zu erstellende Lieferung beschrieben. Zum Erstellen eines Platform-Bundles wird das Skript platformBundle.sh verwendet.

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

4.1. Konfigurationsdateien

Um eine Lieferung zu erstellen werden drei Konfigurationsdateien benötigt

• gsbos_global.cfg
• serviceTypes.cfg
• platformBundle.cfg

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

Im folgenden werden die drei Konfigurationsdateien beschrieben.

4.2. gsbos_global.cfg

Im folgenden wird die Konfigurationsdatei gsbos_global.cfg beschrieben.

4.2.1. Beschreibung

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

  • Globale Konfiguration des GSB/OS

Die Konfigurationsdatei wird mit jedem GSB/OS Release ausgeliefert und befindet sich im infrastructure-Verzeichnis des Kerns (core).

~gsbos/releases/core/10.0.0/infrastructure/platform/conf/

Diese Datei sollte in ein zentrales Konfigurationsverzeichnis kopiert werden.

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

Danach kann diese an die Plattform angepasst werden.

4.2.2. Konfiguration

In den folgenden Abschnitten werden die Parameter der Konfigurationsdatei beschrieben.

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

# GSB/OS-Folder

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

# Home-Verzeichnis des GSB/OS Benutzer

gsbos_base_dir="/home/gsbos"

# Zielverzeichnis der Installation

gsbos_install_dir="/opt/gsbos/software"

# Zielverzeichnis der Persistenten Daten (z.B. Log-Dateien)

gsbos_data_dir="/space/gsbos/data"

 

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

# GSB/OS-User

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

# Benutzername des GSB/OS Benutzer

gsbos_user=gsbos

# Gruppename des GSB/OS Benutzer

gsbos_group=gsbos

  

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

# Do not touch

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

# Pfad zum GSB/OS Kern

gsbos_core_base_dir="${gsbos_base_dir}/releases/core"

# Pfad zu den Mandanten

gsbos_customers_base_dir="${gsbos_base_dir}/releases/customers"

# Pfad zur Ablage der PlatformBundle

platform_bundle_dir="${gsbos_base_dir}/platformBundle"

# Pfad zur Ablage der Patche

patch_base_dir="${gsbos_base_dir}/patches"

4.3. serviceTypes.cfg

Im folgenden wird die Konfigurationsdatei serviceTypes.cfg beschrieben.

4.3.1. Beschreibung

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

  • Definieren der Service-Typen

Ein Service-Typ beinhaltet eine Liste von Artefakten die bei der Erstellung des Platform-Bundle für die Assemblierung des Service-Typ-Artefakts genutzt werden.

Die Konfigurationsdatei wird mit jedem GSB/OS Release ausgeliefert und befindet sich im infrastructure-Verzeichnis des Kerns (core).

~gsbos/releases/core/10.0.0/infrastructure/platform/conf/

Diese Datei sollte in ein zentrales Konfigurationsverzeichnis kopiert werden.

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

Danach kann diese an die Plattform angepasst werden.

4.3.2. Konfiguration

In den folgenden Abschnitten werden die Parameter der Konfigurationsdatei beschrieben.

Wenn die Namen der Service-Typen angepasst werden, müssen diese auch in anderen Konfigurationsschritten angepasst werden (z.B. Systemd-Unit)
Wird die Liste der Komponenten eines Service-Typ angepasst, so muss auch die Runtime entsprechend abgelegt werden

declare -g -A gsbos_serviceTypes

 

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

# Globale Service-Typen (Redaktions- und Live-Umgebung)

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

# Beschreibt die Komponenten des ServiceType *service*

gsbos_serviceTypes[service]="tomcat indexer eventdispatcher"

# Beschreibt die Komponenten des ServiceType *repository*

gsbos_serviceTypes[repository]="tomcat repository replication"

# Beschreibt die Komponenten des ServiceType *delivery*

gsbos_serviceTypes[delivery]="tomcat site"

# Beschreibt die Komponenten des ServiceType *solr*

gsbos_serviceTypes[solr]="solr"

 

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

# Preview Service-Typen (Redaktionsumgebung)

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

# Beschreibt die Komponenten des ServiceType *workflow*

gsbos_serviceTypes[workflow]="tomcat workflow"

# Beschreibt die Komponenten des ServiceType *editor*

gsbos_serviceTypes[editor]="tomcat editor"

 

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

# Service Service-Typen (Service-Umgebung)

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

# Beschreibt die Komponenten des ServiceType *adminportal*

gsbos_serviceTypes[adminportal]="tomcat liferay adminportal serviceportal"

# Beschreibt die Komponenten des ServiceType *maildistributor*

gsbos_serviceTypes[maildistributor]="tomcat maildistributor"

# Beschreibt die Komponenten des ServiceType *cas*

gsbos_serviceTypes[cas]="tomcat cas"

 

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

# HTTPD

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

# Beschreibt die Komponenten des ServiceType *httpd*

gsbos_serviceTypes[httpd]="httpd"

4.4. platformBundle.cfg

Im folgenden wird die Konfigurationsdatei platformBundle.cfg beschrieben.

4.4.1. Beschreibung

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

  • Beschreibung des Platform-Bundles

Die Konfigurationsdatei wird mit jedem GSB/OS Release ausgeliefert und befindet sich im infrastructure-Verzeichnis des Kerns (core).

~gsbos/releases/core/10.0.0/infrastructure/platform/conf/

Diese Datei sollte in ein zentrales Konfigurationsverzeichnis kopiert werden.

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

Danach kann diese an die Plattform angepasst werden.

4.4.2. Konfiguration

In den folgenden Abschnitten werden die Parameter der Konfigurationsdatei beschrieben.

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

# Platform Definition

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

# Name der Plattform/des PlatformBundle

platform_name=showcase

# Version der Plattform/des PlatformBundle

platform_version=1.0

 

# Version des zu verwendenden Kern

gsbos_core_version=<CORE_VERSION> (4)

 

# Liste der Mandanten und deren Version

customers=(

  <CUSTOMER1_NAME>:<CUSTOMER1_VERSION> (1)

  <CUSTOMER2_NAME>:<CUSTOMER2_VERSION> (2)

  <CUSTOMER3_NAME>:<CUSTOMER3_VERSION> (3)

)

 

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

# Patch Definition (Optional)

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

# Liste der Core-Patches

core_patches=(

# PATCH-FILE-NAME

)

 

# Liste der Customer-Patches

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

1Die Token <CUSTOMER1_NAME> und <CUSTOMER1_VERSION> müssen durch den Namen und die Version des ersten Mandanten ersetzt werden.
2Die Token <CUSTOMER2_NAME> und <CUSTOMER2_VERSION> müssen durch den Namen und die Version des zweiten Mandanten ersetzt werden.
3Die Token <CUSTOMER3_NAME> und <CUSTOMER3_VERSION> müssen durch den Namen und die Version des dritten Mandanten ersetzt werden.
4Das Token <CORE_VERSION> muss durch die genutzte Core-Version ersetzt werden.
Sollte das Plattformbundle nur einen Mandanten beinhalten dann müssen die im obigen Beispiel enthaltenen Definitionen für CUSTOMER2 und CUSTOMER3 gelöscht werden.

4.5. Verwendung

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

chmod +x platformBundle.sh

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

Das Skript kann mit folgenden Parametern ausgeführt werden:

  • -c Angabe des Pfad zum Konfigurationsverzechnis

    • Standardwert: ~gsbos/config/
  • -f Überschreiben des PlatformBundle, falls dieses bereits existiert

    • Standardwert: -
  • -h Hilfe (usage) des Skript

4.5.1. Vorgehen zur Erstellung

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

/home/gsbos/releases/core/{revnumber}/infrastructure/platform/scripts/platformBundle.sh

Im einfachsten Fall wird dieses ohne Parameter direkt aufgerufen:

./platformBundle.sh

Dieses sucht unter ${HOME}/config die zu verwendende Konfiguration und erstellt das Platform-Bundle im Verzeichnis:

/home/gsbos/platformBundle/{platform_name}/{platform_version}/

Für den Fall, dass die Installations-Konfiguration aus einem anderen Verzeichnis, als ${HOME}/config, verwendet werden soll, kann dies über den Parameter -c definiert werden:

./platformBundle.sh –c /home/gsbos/gsbos/config

Vor der Erstellung des Platform-Bundles wird geprüft, ob bereits ein entsprechendes Bundle mit dem Namen und derselben Versionsnummer existiert. Sollte dies der Fall sein, wird die Erstellung des Bundles abgebrochen.

Durch die Verwendung des Force-Parameters -f kann die Erstellung des Platform-Bundles erzwungen werden. In diesem Fall wird ein evtl. vorhandenes Platform-Bundle überschrieben.

5. Installation des Platform-Bundles

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

5.1. Konfigurationsdateien

Um ein PlatformBundle zu installieren werden zwei Konfigurationsdateien benötigt.

  • gsbos_global.cfg
  • platformBundle.cfg

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

Im folgenden werden die zwei Konfigurationsdateien beschrieben.

5.2. gsbos_global.cfg

Im folgenden wird die Konfigurationsdatei gsbos_global.cfg beschrieben.

5.2.1. Beschreibung

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

  • Globale Konfiguration des GSB/OS

Die Konfigurationsdatei wird mit jedem GSB/OS Release ausgeliefert und befindet sich im infrastructure-Verzeichnis des Kerns (core).

~gsbos/releases/core/10.0.0/infrastructure/platform/conf/

Diese Datei sollte in ein zentrales Konfigurationsverzeichnis kopiert werden.

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

Danach kann diese an die Plattform angepasst werden.

5.2.2. Konfiguration

In den folgenden Abschnitten werden die Parameter der Konfigurationsdatei beschrieben.

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

# GSB/OS-Folder

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

# Home-Verzeichnis des GSB/OS Benutzer

gsbos_base_dir="/home/gsbos"

# Zielverzeichnis der Installation

gsbos_install_dir="/opt/gsbos/software"

# Zielverzeichnis der Persistenten Daten (z.B. Log-Dateien)

gsbos_data_dir="/space/gsbos/data"

 

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

# GSB/OS-User

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

# Benutzername des GSB/OS Benutzer

gsbos_user=gsbos

# Gruppename des GSB/OS Benutzer

gsbos_group=gsbos

 

 

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

# Do not touch

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

# Pfad zum GSB/OS Kern

gsbos_core_base_dir="${gsbos_base_dir}/releases/core"

# Pfad zu den Mandanten

gsbos_customers_base_dir="${gsbos_base_dir}/releases/customers"

# Pfad zur Ablage der PlatformBundle

platform_bundle_dir="${gsbos_base_dir}/platformBundle"

# Pfad zur Ablage der Patche

patch_base_dir="${gsbos_base_dir}/patches"

5.3. platformBundle.cfg

Im folgenden wird die Konfigurationsdatei platformBundle.cfg beschrieben.

5.3.1. Beschreibung

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

  • Beschreibung des Platform-Bundles

Die Konfigurationsdatei wird mit jedem GSB/OS Release ausgeliefert und befindet sich im infrastructure-Verzeichnis des Kerns (core).

~gsbos/releases/core/10.0.0/infrastructure/platform/conf/

Diese Datei sollte in ein zentrales Konfigurationsverzeichnis kopiert werden.

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

Danach kann diese an die Plattform angepasst werden.

5.3.2. Konfiguration

In den folgenden Abschnitten werden die Parameter der Konfigurationsdatei beschrieben.

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

# Platform Definition

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

# Name der Plattform/des PlatformBundle

platform_name=showcase

# Version der Plattform/des PlatformBundle

platform_version=1.0

 

# Version des zu verwendenden Kern

gsbos_core_version=<CORE_VERSION> (4)

 

# Liste der Mandanten und deren Version

customers=(

  <CUSTOMER1_NAME>:<CUSTOMER1_VERSION> (1)

  <CUSTOMER2_NAME>:<CUSTOMER2_VERSION> (2)

  <CUSTOMER3_NAME>:<CUSTOMER3_VERSION> (3)

)

 

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

# Patch Definition (Optional)

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

# Liste der Core-Patches

core_patches=(

# PATCH-FILE-NAME

)

 

# Liste der Customer-Patches

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

1Die Token <CUSTOMER1_NAME> und <CUSTOMER1_VERSION> müssen durch den Namen und die Version des ersten Mandanten ersetzt werden.
2Die Token <CUSTOMER2_NAME> und <CUSTOMER2_VERSION> müssen durch den Namen und die Version des zweiten Mandanten ersetzt werden.
3Die Token <CUSTOMER3_NAME> und <CUSTOMER3_VERSION> müssen durch den Namen und die Version des dritten Mandanten ersetzt werden.
4Das Token <CORE_VERSION> muss durch die genutzte Core-Version ersetzt werden.
Sollte das Plattformbundle nur einen Mandanten beinhalten dann müssen die im obigen Beispiel enthaltenen Definitionen für CUSTOMER2 und CUSTOMER3 gelöscht werden.

5.4. Verwendung

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

chmod +x install-gsbos.sh

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

Das Skript kann mit folgenden Parametern ausgeführt werden:

  • -c Angabe des Pfad zum Konfigurationsverzechnis

    • Standardwert: ~gsbos/config/
  • -t Angabe expliziter Service-Types (z.B. um nur die Delivery neu zu installieren)

    • Standardwert: - (verwendet alle)
  • -h Hilfe (usage) des Skript

5.5. Vorgehen zur Installation

Nachdem das Platform-Bundle und somit die gewünschten Service-Typen erstellt wurden, können diese installiert werden. Dies wird mit dem folgenden Script durchgeführt:

/home/gsbos/releases/core/{revnumber}/infrastructure/platform/scripts/install-gsbos.sh

Bei Verwendung der Standardpfade muss dem Script als Parameter nur die Liste der gewünschten Service-Typen mitgegeben werden:

./install-gsbos.sh -t <SERVICE-TYP>

Wie beim Erstellen des Plattform-Bundles kann auch diesem Script über den -c Parameter mitgeteilt werden, welche Konfiguration verwendet werden soll:

./install-gsbos.sh –c /home/gsbos/config -t <SERVICE-TYP>

6. Mandant Import

Nach der Installation und dem Starten der Komponenten muss der Content der gehosteten Mandanten in das Redaktions-Repository importiert und die Rechtedefinition des Mandanten eingespielt werden.

6.1. Mandanten Content Import

Dazu muss der Content eines Mandanten welcher im Ordner content in zwei Zip-Dateien abgelegt ist in das Repository importiert werden.

  • zip enthält den redaktionellen Content des Mandanten
  • zip enthält die Mandantenkonfiguration des Editors

Auf dieser Maschine wird der Content des Mandanten über die Importer-Schnittstelle des Redaktions-Repository eingespielt.

Content Import

curl –F „file=@<FILENAME>.zip“ http://repository.preview.example.com:6001/repository/content/importer/zip/execute

Der Import läuft synchron ab. Das heißt, dass der Aufruf des Konsolenbefehls erst beendet wird, nachdem der Import abgeschlossen ist. Der Status des Imports kann im Log des Redaktions-Repositorys überprüft werden. Diese ist unter dem Pfad /space/gsbos/data/repository-preview/logs zu finden:

Soll der Content des Mandanten nach dem Import direkt publiziert werden, kann als zusätzlicher Parameter publish=true ergänzt werden. Der folgende Aufruf führt einem Import mit anschließender Publikation durch.

Content Import mit Publikation

curl -F "file=@<FILENAME>.zip" -F "publish=true" http://repository.example.com:6001/repository/content/importer/zip/execute

6.2. Benutzer- und Gruppen Einspielung

Die Benutzer und Gruppen eines Mandanten werden in einem LDAP gepflegt. Innerhalb eines Release liegen sie in Form eines LDAP Exports, eines sogenannten „ldif“, vor.

Im Release ist dieser LDAP Export im Verzeichnis infrastructure/ldap. Die folgenden ldif-Dateien sind Bestandteil eines GSB Mandanten:

  • <MANDANT>.ldif enthält die Benutzer- und Gruppendefinitionen für Redakteure und SiteAdminisstratoren
  • <MANDANT>-adminportal.ldif enthält Benutzer- und Gruppendefinitionen für das Adminportal

Das Einspielen der Benutzer und Gruppen erfolgt über den LDAP-Befehl ldapadd.

LDAP Benutzer- und Gruppenimport

ldapadd -v -x -D cn=Manager,dc=example,dc=com -w secret -f <FILENAME>.ldif

Hierbei muss statt secret das Password des LDAP-Managers eingetragen werden.

6.3. Mandanten Rechtedefinition Einspielung

Nach dem erfolgreichen Import des Contents des Mandanten, muss die Rechtedefinition in das Redaktions-Repository eingespielt werden.

Dieses ist Teil des Mandanten-Release und ist dort unter folgendem Pfad zu finden: * infrastructure/security/preview/security-ldap.xml

Zum Einspielen der Rechtedefinition wird folgender Konsolenbefehl verwendet:

Einspielung Repository Berechtigungen

curl --noproxy localhost -F "jcrxml=@security-ldap.xml" -F "jcrname=standardlsg" http://repository.preview.example.com:6001/repository/security

Der Befehl beinhaltet zwei Parameter:

  • jcrxml Dateiname der Rechtedefinition
  • jcrname Name des Mandanten. In dem oben genannten Beispiel ist dies der Mandant „standardlsg“.