Zielgruppe BetriebVersion: GSB10.1Installation - Auszüge
Auszüge zur Vorbereitung und Durchführung der Installation finden Sie in diesem Artikel.
- 1 Vorbereitung
- 2 Erstellung des Platform-Bundles
- 3 Installation des Platform-Bundles
- 4 Mandant Import
Die Installationsanleitung ist geeignet, um die Installation des GSB auf dem präferierten Betriebssystem Redhat Linux bzw. CentOS Linux einfach nachvollziehen zu können.
Weiterhin geht die Installationsanleitung davon aus, dass für die geforderten Beistellungen die Standard Pakete des Betriebssystems bzw. die von den jeweiligen Herstellern zur Verfügung gestellten RPMs genutzt werden. Die in der Installationsanleitung angesprochenen Pfade und die im GSB Release enthaltenen Vorlagen (bspw. für Service-Units) verwenden die Standard Pfade und Installationsverzeichnisse der Beistellungen.
| Hinweis: |
|---|
| Bitte achten Sie darauf, Archive direkt auf Linux-Umgebungen zu entpacken, da es bei Datei-Operationen unter Windows zu Veränderungen der Rechte von Archivdateien kommen kann. So können Sie beispielsweise verhindern, dass ausführbare Dateien nach einem Transfer von Windows zu Linux nicht mehr "executable" sind. |
1 Vorbereitung
Die Vorbereitung der Installation der GSB Infrastruktur erfordert die Bereitstellung einiger Beistellungen sowie der Runtime-Konfigurationen für die einzelnen Service-Instanzen.
1.1 Lizenzschlüssel
Der Betrieb des GSB erfordert eine gültige Lizenz, die vom GSB Produkthersteller ausgestellt wird. Für die Beantragung einer Lizenz wenden Sie sich bitte an die Mailadresse mailto://gsb@itzbund.de. Die Lizenzdaten sind anschließend in der Runtime-Konfiguration der Repository Webapplikation zu hinterlegen.
1.2 Beistellungen
Der GSB erfordert eine Reihe von Beistellungen deren Installation und Konfiguration in den folgenden Unterkapiteln beschrieben wird. Die in der Beschreibung benannten Links und Versionen stellen die zum Zeitpunkt der Erstellung dieser Dokumentation aktuellen Versionen dar.
1.2.1 Java
Der GSB benötigt ein Java JDK für den Betrieb der GSB-Komponenten, Details zu den benötigten Versionen finden sich in der Tabelle Systemvoraussetzungen.
Das zurzeit aktuelle OpenJDK können Sie auf der Webseite herunterladen (s.a. Systemvoraussetzungen).
Das Archiv kann nach dem Download bspw. mit dem Kommando
cd /usr/javatar xfz <OPENJDK_ARCHIVE>ln -s /usr/java/<OPENJDK_INSTALL_DIR> /usr/java/default
installiert werden wobei die Token <OPENJDK_ARCHIVE> durch den Pfad der heruntergeladenen Archiv-Datei und <OPENJDK_INSTALL_DIR> durch die jeweils installierte Version ersetzt werden muss.
Die Java-Runtime ist nach Installation des RPM unterhalb des Pfades /usr/java/default zugreifbar und wird vom GSB auch in diesem Pfad erwartet, da dieser Pfad in den für den Start der GSB Tomcat-Service-Instanzen eingesetzten Systemd Service-Units gesetzt ist.
| Hinweis: |
|---|
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-9.0-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
Die für die Installation genutzte Tomcat-Server Version kann der Tabelle „Systemvoraussetzungen“ entnommen 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-9.0.27) gesetzt, da innerhalb der für den Start der Komponenten eingesetzten Systemd Service-Units die Definitionen der Start- und Stopskripte (ExecStart und ExecStop) entsprechend definiert sind. Weiterhin können Tomcat-Server Updates einfacher vorbereitet und durchgeführt werden, da im Anschluss an die Installation nur der symbolische Link angepasst werden muss.
| Hinweis: |
|---|
Sollte eine Installation des Tomcat-Servers im Pfad /opt/software/tomcat/default nicht möglich sein, dann kann auch ein anderer Pfad für die Installation genutzt werden. In diesem Fall muss anschließend die Definition der Start- und Stop-Skripte in den Variablen ExecStart und ExecStop in den Systemd Service-Units entsprechend angepasst werden. |
Die folgenden Shell-Kommandos können für eine exemplarische Installation genutzt werden und müssen als User root ausgeführt werden:
export TC_VERSION=9.0.27
mkdir -p /opt/software/tomcat/
wget https://archive.apache.org/dist/tomcat/tomcat-9/v${TC_VERSION}/bin/apache-tomcat-${TC_VERSION}.tar.gz
tar -xfz apache-tomcat-${TC_VERSION}.tar.gz -C /opt/software/tomcat
ln -s /opt/software/tomcat/apache-tomcat-${TC_VERSION} /opt/software/tomcat/default
Integration Datenbanktreiber
Weiterhin müssen im Lib-Verzeichnis des installierten Tomcat-Servers und globalen Lib-Verzeichnis für die Standalone GSB Applikationen 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 Order /opt/gsbos/lib abgelegt werden. Dieser Ordner wird sowohl von den Tomcat-basierten GSB Applikationen als auch von den standalone GSB Applikationen beachtet..
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
In der folgenden Beschreibung zur Installation des Solr-Servers durch das vom Hersteller bereitgestellte Archiv (s.a. "Download Links") wird davon ausgegangen, dass das Archiv im /tmp-Ordner unter dem Namen solr-<SOLR_VERSION>.tgz abgelegt ist. Weiterhin muss für die Durchführung der Installation das Token <SOLR_VERSION> durch die gewünschte Solr-Version (s.a. „Systemvoraussetzungen“) ersetzt werden.
Die eigentliche Installation des Solr-Servers erfolgt im Ordner /opt/software/solr/solr-<SOLR_VERSION>. Durch Setzen eines symbolischen Links von /opt/software/solr/default auf das Installationsverzeichnis wird eine Installation bereitgestellt, die analog zur Tomcat-Server Installation durchgeführt wird. Hierdurch wird sichergestellt, dass
- der Solr-Server analog zum Tomcat-Server abgelegt ist und somit eine 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 wird wie folgt durchgeführt:
Installation Solr-Server
export solr_version=<SOLR_VERSION>
export solr_archive=/tmp/solr-${solr_version}
export solr_install_dir=/opt/software/solr/
export solr_base=${solr_install_dir}/solr-${solr_version}
tar -xvf /tmp/${solr_archive} -C ${solr_install_dir} (1)
mkdir ${solr_base}/lib
cd ${solr_base}
cp ./contrib/analysis-extras/lib/icu4j-*.jar lib (2)
cp ./contrib/analysis-extras/lucene-libs/lucene-analyzers-icu-${solr_version}.jar lib
cp ./dist/solr-analysis-extras-${solr_version}.jar lib
ln -s /opt/software/solr/solr-${solr_version} /opt/software/solr/default (3)
# Installation jts-core Library (4)
jts_version="1.15.0"curl -k -o /opt/software/solr/default/server/solr-webapp/webapp/WEB-INF/lib/jts-core-${jts_version}.jar http://central.maven.org/maven2/org/locationtech/jts/jts-core/${jts_version}/jts-core-${jts_version}.jar
| (1) | Entpacken der Archivdatei im Installationsordner (/opt/software/solr) |
| (2) | Kopie benötigter Bibliotheken in einen zentralen Ordner (/opt/software/solr/solr-<SOLR_VERSION>/lib) |
| (3) | Anlegen eines symbolischen Links von /opt/software/solr/default auf /opt/software/solr/solr-<SOLR_VERSION> |
| (4) | Für die Umkreissuche wird eine zusätzliche Bibliothek (jts-core) benötigt, die manuell installiert werden muss (s.a. https://lucene.apache.org/solr/guide/7_7/spatial-search.html#jts-and-polygons-flat). |
1.2.4 Httpd-Server
Der Httpd-Server kann am einfachsten aus dem RPM-Repository des zugrundeliegenden Linux Betriebssystems installiert werden. Hierbei ist zu beachten, dass neben dem eigentlichen Httpd-Server noch eine Reihe von Modulen für den Betrieb des GSB Httpd-Servers benötigt wird. Die benötigten Module sind in dem Redhat RPM bis auf das optional benötigte mod_ssl enthalten, und müssen daher nicht gesondert installiert werden.
sudo yum –y install httpd
sudo yum –y install mod_ssl
rm /etc/httpd/conf.d/*.conf
ln -s /opt/gsbos/runtime/httpd/conf.d/gsbos.conf /etc/httpd/conf.d/
| Hinweis: |
|---|
Die Access-Logs des GSB Mandanten RedHat und CentOS verfolgen eine relativ konservative Stragie bzgl. der Aktualisierung von in den Distributionen enthaltenen Softwarepaketen. So wird über die OS-Repositories auch eine relativ alte Version des Httpd-Webservers installiert. Das Community-Project "Inline with Upstream stable" stellt aktuelle Versionen ausgewählter Softwarepakete zur Verfügung. Hinweise zur Anbindung der IUS-Repositories finden sich auf der Seite "Getting Started", Eine aktuelle Version des Httpd-Webservers kann über die IUS-Repositories installiert weden. |
1.2.5 Optional: Manuelle Installation Httpd-Server
Wenn der Httpd-Server aus den Sourcen individuell übersetzt wird, dann werden noch weitere Dateien benötigt. Im Einzelnen handelt es sich um
- Apache Portable Runtime Module APR und APR-util (Download von https://apr.apache.org/download.cgi)
- Apache Tomcat-Connector (Download von https://tomcat.apache.org/download-connectors.cgi)
Nachdem die benötigten Sourcen in einem Build-Verzeichnis entpackt worden sind, kann der Webserver wie auf http://httpd.apache.org/docs/current/de/install.html beschrieben kompiliert und installiert werden.
Benötigte Httpd-Module
Konfiguration des GSB httpd-Servers bzw. der eingesetzten VirtualHost-Definitionen setzt wie skizziert einige Module voraus. Die Liste der benötigten Module kann aus der Datei httpd/conf/include/loadModules.conf des GSB Kerns entnommen werden. Alle Module die in dieser Datei über die LoadModule-Direktive geladen werden, müssen im httpd-Server zur Verfügung stehen.
Die Modulliste ist für die Erstellung und Installation des Httpd-Servers aus den Sourcen relevant, die diese beim Configure- und Compile-Lauf mit übergeben werden müssen. Bei Verwendung des httpd-RPMs des zugrundeliegenden Betriebssystems sollten alle benötigten Module wie skizziert bereits mitinstalliert werden.
1.2.6 Datenbanken
Der GSB unterstützt die Datenbanken MySQL und Oracle.
| Bitte beachten Sie: |
|---|
| MariaDB wird aktuell von der von uns für das GSB-Adminportal eingesetzten Liferay-Version nicht unterstützt. Wir empfehlen daher im Moment den Einsatz von MySQL, arbeiten aber an einer zukünftigen durchgängigen MariaDB-Unterstützung. |
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.
| Hinweise: |
|---|
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
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:
- Für jede Instanz der GSB Applikationen werdem 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: |
|---|
| 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 denen Skripte zum Anlegen der benötigten Datenbank(en) abgelegt sind.
Einrichten der User/Schemata
| Hinweis: |
|---|
| Bei Verwendung einer Oracle-Datenbank muss im Vorfeld noch der benötigte gsbos-Tablespace mit dem Skript createTablespace.sql angelegt werden. Der Vollständigkeit halber ist an dieser Stelle das Skript zum Anlegen des Oracle-Tablespace aufgeführt, um die Defaultwerte des exemplarischen Skriptes für die Einrichtung des Tablespace nutzen zu können. |
createTablespace.sql
create bigfile tablespace gsbos
size 500M reuse autoextend on next 100M
maxsize unlimited extent management local segment space management auto;
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:
Exemplarischer Aufruf zum Anlegen der Site Datenbank
cd /home/gsbos/releases/core/10.1.0-rc4/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 zum Anlegen einer MySQL Datenbank ist wie folgt aufgebaut:
createTablespace.sql
#### Create DatabaseSET @createDb = CONCAT ('CREATE DATABASE IF NOT EXISTS ',@databasename,' CHARACTER SET = ''utf8mb4'' COLLATE = ''utf8mb4_bin''');PREPARE stmt FROM @createDb; EXECUTE stmt; DEALLOCATE PREPARE stmt;#### Create UserSET @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 @usernameSET @grantUsage = CONCAT ('GRANT USAGE ON *.* TO ''',@username,'''@''%'';');PREPARE stmt FROM @grantUsage; EXECUTE stmt; DEALLOCATE PREPARE stmt;#### Set Rights on @databasename for @usernameSET @grantRights = CONCAT ('GRANT ',@userrights,' ON ',@databasename,'.* TO ''',@username,'''@''%''');PREPARE stmt FROM @grantRights; EXECUTE stmt; DEALLOCATE PREPARE stmt;FLUSH PRIVILEGES;
Erstellen/Aktualisieren der Tabellen
Für das Anlegen (bzw. aktualisieren) der Tabellen können die Skripte genutzt werden, deren Dateiname mit V beginnt. Diese Skripte sind versioniert und bauen aufeinander auf. Das Namenschema entspricht dabei immer dem Muster V<GSB_VERSION>_<LFD_NR>__<BESCHREIBUNG>.sql
Bei einer Neuinstallation müssen alle diese Skripte in der richtigen Reihenfolge (alphanumerisch aufsteigend) ausgeführt werden. Bei einem Update auf eine neuere GSB-Version müssen nur die noch nicht ausgeführten Skripte ausgeführt werden.
Beispiel
V10.1.0_0__Init.sql, V10.2.0_0__Migration.sql, V10.3.0_0__Migration.sql
- Bei einer Neuinstallation müssten alle 3 Skripte (in dieser Reihenfolge) ausgeführt werden.
- Bei einem Update von 10.1.0 auf 10.3.0 müssten nur die letzten beiden Skripte ausgeführt werden.
- Bei einem Update von 10.2.0 auf 10.3.0 müsste nur das letzte Skript ausgeführt werden.
1.2.7 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 Ordner certificates in der exemplarischen Runtime-Konfiguration nimmt eine Sonderstellung ein, da hier keine klassischen Runtimekonfigurationen 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 auf 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 generierenca-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 Konfigurationsdateica-cert.confkeystore.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.
1.2.8 Standalone Applikationen
Die Runtime-Konfiguration der GSB Standalone-Application Service-Instanzen umfasst die beiden Dateien
application.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 Anwenung 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.xmlserver.port=6501indexer.repository.url=http://repository.preview.example.com:6001indexer.solr.url=http://solr.preview.example.com:6401
1.2.9 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
tomcat
- tomcat.env
- tomcat.properties
- application.properties
Die Datei tomcat.env enthält mit der Umgebungsvariablen-Definition CATALINA_OPTS alle instanzspezfischen JVM Parameter 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=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 exemplarischen Beispiele vorgestellt werden können. Die wesentlichen Anpassungen in den webapplikationsspezifischen Properties betreffen Servernamen sowie Ports.
1.2.10 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. nachfolgende Requests eines Browsers sollen immer an denselben Tomcat-Server weitergeleitet werden.
1.2.11 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-Runtimekonfiguration weicht somit von dem der anderen Service-Instanzen ab. Die Runtime-Konfiguration der Solr-Service-Instanzen umfasst
- Portdefinitionen für den Zugriff auf die Solr-Service-Instanz
- Homeverzeichnis der GSB Solr-Installation
Der Aufbau der Runtime-Konfiguration einer Solr-Service-Instanz sieht damit am Beispiel der Instanz solr-replication wie folgt aus:
solr-replication
- env
Die Datei env.env enthält alle Properties, die für die Solr-Konfiguration des Replication-Servers benötigt werden.
Auszug Solr-Runtime-Properties
SOLR_CONFIGSETS_DIR=/opt/gsbos/software/solr/configsets
SOLR_HOME=/opt/gsbos/software/solr/replication
SOLR_SHARED_LIB_DIR=/opt/software/solr/default/lib
SOLR_RMI_PORT=8403
# Sets the port Solr binds to, default is 8983
SOLR_PORT=8401
# Sets the port Solr binds to stop the server
SOLR_STOP_PORT=8405
# Solr-Replication-Configuration
# s.a.: http://lucene.apache.org/solr/guide/7_2/index-replication.html#configuring-the-replication-requesthandler-on-a-slave-server
SOLR_MASTER_HOST=solr.master.example.com
SOLR_MASTER_PORT=7401
SOLR_REPLICATION_INTERVAL=00:00:20
1.2.12 Host-Datei
Die in der exemplarischen Beispielkonfiguration/Infrastruktur verwendeten Hostnamen finden sich im Kernrelease im infrastructure-Artefakt im Verzeichnis infrastructure/etc und kann als Grundlage für die Erstellung der plattformspezifischen Hostdateien genutzt werden.
Die exemplarische Host-Datei enthält alle Servernamen, die in der exemplarischen Runtime-Konfiguration verwendet werden.
1.2.13 Hinweis zu MimeTypes
Die im GSB-Kern enthaltene Datei "DefaultMimeTypes.properties" enthält die Definition der in der Site-Applikation unterstützten/bekannten MimeTypes. Dieses Mapping kann nicht durch Ablage zusätzlicher Mapping-Dateien erweitert werden.
Um fehlende Mappings in einer Installation zu ergänzen bietet sich folgendes Vorgehen an.
- Kopie der DefaultMimeTypes.properties aus dem Kern und Ablage in einem GSB 10 Mandanten im Pfad site/src/main/resources/de/bund/gsb/site/util/DefaultMimeTypes.properties
- Erweiterung der Kopie um die benötigten Mappings
Bei der Erstellung eines Mandantenrelease wird diese Datei mit in das Mandantenrelease integriert. Da bei der Erstellung des Plattformbundle zunächst der Kern und anschließend die Mandanten in das Bundle integriert werden, wird die Definition aus dem Kern mit der im Mandanten erweiterten Definition überschrieben. Damit stehen nach der Installation des Bundle dann auch zusätzlich definierten Mappings in der Site zur Verfügung.
2 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.
Hinweis:
Beim Entpacken des Release können vorab vergebene Lese-, Schreib- oder Ausführrechte verloren gehen. Bitte beachten Sie daher folgende Rechtevergabe:
| Ordner | Rechte |
|---|---|
| /opt/gsbos/runtime/ | rwxrwxr-x |
| /opt/gsbos/software/ | rwxrwxr-x |
| Hinweise Shellskripte: |
|---|
| 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. |
2.1 Konfigurationsdateien
Um eine Lieferung zu erstellen werden drei Konfigurationsdateien benötigt
• gsbos_global.cfg
• serviceTypes.cfg
• platformBundle.cfg
| Hinweis: |
|---|
| Die drei Konfigurationsdateien müssen in einem Verzeichnis liegen. Das Standardverzeichnis ist ~gsbos/config. |
Im folgenden werden die drei Konfigurationsdateien beschrieben.
2.2 gsbos_global.cfg
Im folgenden wird die Konfigurationsdatei gsbos_global.cfg beschrieben.
2.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.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.
2.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"
2.3 serviceTypes.cfg
Im folgenden wird die Konfigurationsdatei serviceTypes.cfg beschrieben.
2.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.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.
2.3.2 Konfiguration
In den folgenden Abschnitten werden die Parameter der Konfigurationsdatei beschrieben.
| Achtung: |
|---|
| 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 *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"
2.4 platformBundle.cfg
Im folgenden wird die Konfigurationsdatei platformBundle.cfg beschrieben.
2.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.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.
2.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)
)
| (1) | Die Token <CUSTOMER1_NAME> und <CUSTOMER1_VERSION> müssen durch den Namen und die Version des ersten Mandanten ersetzt werden. |
| (2) | Die Token <CUSTOMER2_NAME> und <CUSTOMER2_VERSION> müssen durch den Namen und die Version des zweiten Mandanten ersetzt werden. |
| (3) | Die Token <CUSTOMER3_NAME> und <CUSTOMER3_VERSION> müssen durch den Namen und die Version des dritten Mandanten ersetzt werden. |
| (4) | Das Token <CORE_VERSION> muss durch die genutzte Core-Version ersetzt werden. |
| Hinweis: |
|---|
| Sollte das Plattformbundle nur einen Mandanten beinhalten dann müssen die im obigen Beispiel enthaltenen Definitionen für CUSTOMER2 und CUSTOMER3 gelöscht werden. |
2.5 Verwendung
Bevor das Skript verwendet werden kann, muss es ausführbar sein.
chmod +x platformBundle.sh
| Hinweis: |
|---|
| 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 Konfigurationsverzechnis
- Standardwert: ~gsbos/config/
-f Überschreiben des PlatformBundle, falls dieses bereits existiert
- Standardwert: -
- -h Hilfe (usage) des Skript
2.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.
3 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.
| Hinweis: |
|---|
| 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. |
3.1 Konfigurationsdateien
Um ein PlatformBundle zu installieren, werden zwei Konfigurationsdateien benötigt.
- gsbos_global.cfg
- platformBundle.cfg
| Hinweis: |
|---|
| Die zwei Konfigurationsdateien müssen in einem Verzeichnis liegen. Das Standardverzeichnis ist ~gsbos/config. |
Im folgenden werden die zwei Konfigurationsdateien beschrieben.
3.2 gsbos_global.cfg
Im folgenden wird die Konfigurationsdatei gsbos_global.cfg beschrieben.
3.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.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.
3.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"
3.3 platformBundle.cfg
Im folgenden wird die Konfigurationsdatei platformBundle.cfg beschrieben.
3.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.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.
3.3.2 Konfiguration
In den folgenden Abschnitten werden die Parameter der Konfigurationsdatei beschrieben.
###############################################################################
# Platform Definition
###############################################################################
# Name der Plattform/des PlatformBundle
platform_name=showcase
# Version der Plattform/des PlatformBundle
platform_version=1.0
# Version des zu verwendenden Kern
gsbos_core_version=<CORE_VERSION> (4)
# Liste der Mandanten und deren Version
customers=(
<CUSTOMER1_NAME>:<CUSTOMER1_VERSION> (1)
<CUSTOMER2_NAME>:<CUSTOMER2_VERSION> (2)
<CUSTOMER3_NAME>:<CUSTOMER3_VERSION> (3)
)
###############################################################################
# Patch Definition (Optional)
###############################################################################
# Liste der Core-Patches
core_patches=(
# PATCH-FILE-NAME
)
# Liste der Customer-Patches
#customer_patches[standardlsg]="PATCH-FILE-NAME"
| (1) | Die Token <CUSTOMER1_NAME> und <CUSTOMER1_VERSION> müssen durch den Namen und die Version des ersten Mandanten ersetzt werden. |
| (2) | Die Token <CUSTOMER2_NAME> und <CUSTOMER2_VERSION> müssen durch den Namen und die Version des zweiten Mandanten ersetzt werden. |
| (3) | Die Token <CUSTOMER3_NAME> und <CUSTOMER3_VERSION> müssen durch den Namen und die Version des dritten Mandanten ersetzt werden. |
| (4) | Das Token <CORE_VERSION> muss durch die genutzte Core-Version ersetzt werden. |
| Hinweis: |
|---|
| Sollte das Plattformbundle nur einen Mandanten beinhalten dann müssen die im obigen Beispiel enthaltenen Definitionen für CUSTOMER2 und CUSTOMER3 gelöscht werden. |
3.4 Verwendung
Bevor das Skript verwendet werden kann, muss es ausführbar sein.
chmod +x install-gsbos.sh
| Hinweis: |
|---|
| 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 Site neu zu installieren)
- Standardwert: - (verwendet alle)
- -h Hilfe (usage) des Skript
3.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>
4 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.
| Hinweise: |
|---|
| Möglicherweise verhindern betriebssystemseitig aktivierte / konfigurierte Firewalls eine Kommunikation zwischen den GSB-Komponenten und führen damit zu einem Abbruch des Importskripts. Bitte überprüfen Sie daher gegebenenfalls die Einstellungen Ihrer Firewalls. |
| Mit Hilfe der gsbshell werden Operationen im Repository angestoßen. Die eigentliche Verarbeitung der jeweiligen Operation (bspw., Import von Content) erfolgt durch das Content-Repository. Der Fortschritt der jeweiligen Operation sowie ggf. auftretende Fehler können daher im Logfile des Content-Repositories nachvollzogen 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:
|
4.1 Mandanten Content Import
Dazu muss der Content eines Mandanten welcher im Ordner content in zwei Zip-Dateien abgelegt ist in das Repository importiert werden.
content.zipenthält den redaktionellen Content des Mandanteneditor.zipenthält die Mandantenkonfiguration des Editors
Auf dieser Maschine wird der Content des Mandanten über das importcontent Kommando der GSB Shell importiert.
Content Import
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:
Soll der Content des Mandanten nach dem Import direkt publiziert werden, kann als zusätzlicher Parameter --publish ergänzt werden. Der folgende Aufruf führt einem Import mit anschließender Publikation durch.
4.1.1 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).
Content Import mit Publikation
importcontent --publish --file <FILENAME>.zip
| Hinweis: |
|---|
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 Anpassung des Replication-Log-Level des Repositories:
|
4.1.2 Abschließende Contentanpassung
Nach dem initialen Import des Contents eines GSB Mandanten müssen im Content noch einige redaktionelle Änderungen über den GSB 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 Definition 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.
4.2 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.
Benutzer-, Gruppen und Rechteimport über die GSB Shell
importsecurity --customer standardlsg --file security.xml
Der Befehl beinhaltet zwei Parameter:
filePfad zur XML Datei der RechtedefinitioncustomerName des Mandanten. In dem oben genannten Beispiel ist dies der Mandant „standardlsg“.
| Hinweis: |
|---|
| Ein Beispiel für die Schritt-für-Schritt-Installation eines GSB 10.1 finden Sie hier. |