Version: GSB 7Installation

Einleitung

Dieses Dokument beschreibt die Basis-Installation des Government Site Builders (GSB). Die Installation sollte von einem technisch versierten Mitarbeiter durchgeführt werden, der entsprechendes UNIX-, System- und insbesondere auch CoreMedia-Know-How mitbringt.

Bitte lesen Sie sich diese Installationsanleitung zunächst vollständig durch und beginnen Sie erst dann mit der Installation, wenn alle notwendigen Voraussetzungen sichergestellt und alle Vorbereitungsschritte ausgeführt wurden.

Installationsablauf

Die Installation des GSB erfolgt in drei logischen Schritten. Im ersten Schritt wird die auf dem System benötigte Software installiert. Der zweite logische Schritt initialisiert die installierten Komponenten Content-Server, Workflow-Server, Master- oder Slave-Live-Server. Der abschließende dritte Schritt fügt die mandantenspezifischen Elemente (Content, GSB-Benutzer, Workflows) hinzu.

Installationsschema

Verzeichnisse

Für die Installation, Administration und den Betrieb der Software gibt es drei Verzeichnisbäume:

Im Quellverzeichnis werden die für eine Software-Installation notwendigen Dateien ausgepackt. Die Quellverzeichnisse aller Liefereinheiten haben ein gemeinsames Wurzelverzeichnis.
Im Administrationsverzeichnis $GSB_ADMIN_HOME befinden sich die plattformspezifischen Konfigurationsdateien, Lizenzdateien, Log-Dateien und zusätzliche Software, evtl. weitere Administrations-Software, soweit sie nicht direkt aus dem Quellverzeichnis benutzt wird.
Im Installationsverzeichnis liegt die installierte und komplett konfigurierte Software. Diese wird bei einem Installationsvorgang aus dem Quellverzeichnis und den Konfigurationsdateien im Administrationsverzeichnis erstellt. Neben einer aktuellen Software-Installation können im Verzeichnis oberhalb des Installationsverzeichnisses auch ältere bzw. andere Software-Versionen installiert sein.

Um die administrativen Tätigkeiten des Plattformbetreibers (Installation, Updates, Patches, Einspielen von Mandanten) und die Servicefähigkeit der Plattform zu unterstützen, werden die Namen und Strukturen der Verzeichnisse festgelegt. Ältere Software-Versionen werden systematisch nach den aktuellen Release-, Service-Pack- und Patch-Nummern benannt.

Konfigurationsdateien

Die gesamte Installation wird in den Konfigurationsdateien beschrieben, die im Administrationsverzeichnis abgelegt sind. Die Konfiguration setzt sich im Wesentlichen aus folgenden Dateien zusammen:

Für jede CoreMedia-Komponente (Content-Server, Workflow-Server, Editor, Master-, Slave-Live-Server, Suchmaschine) wie auch für die Tomcat-Instanzen und den Apache-Web-Server müssen sogenannte Build-Dateien build_komponente.properties angelegt werden. Diese enthalten die benötigten Konfigurations-Einträge („properties“) der Komponenten.
In der Datei host_specific.properties werden die für dieses System geltenden, komponentenübergreifenden Eigenschaften, z. B. Installationspfade, die Namen der installierten Mandanten etc., festgelegt.
Weitere Dateien werden vorgegeben (build.properties) oder während der Installation automatisch gepflegt (component.properties).

Anhand dieser in den Build-Dateien vorgegebenen Informationen werden die GSB-Komponenten installiert und anschließend konfiguriert.

Als Vorlage für die Build-Dateien stehen die allgemeine Datei

gsb/*/basis/buildProperties/host_specific.properties

und für jede komponente entsprechend vorgefertigte Beispieldateien unter

gsb/*/basis/buildProperties/build_komponente_example.properties

bereit. Diese Beispieldateien müssen bei der ersten Installation in das Administrationsverzeichnis

$GSB_ADMIN_HOME/config

kopiert und dann den gewünschten Verhältnissen angepasst werden. Dabei ist es sinnvoll, den Namensteil example durch den Rechnernamen zu ersetzen und auch nur die Dateien zu kopieren, deren Komponenten installiert werden sollen.

Bei der Installation mehrerer Komponenten auf einer Maschine ist darauf zu achten, dass Ports nicht mehrfach von verschiedenen Komponenten genutzt werden, da es hierdurch zu unerwarteten Seiteneffekten kommen kann. Die Beispieldateien sind so vorgefertigt, dass alle Komponenten (mit Ausnahme des lokalen Editors) auf einem Server installiert werden können. Es wird allerdings empfohlen, die Datenbank und die optionale Suchmaschine auf eigenen Rechnern zu installieren.

Soll die Installation auf mehreren Servern erfolgen, so sind die Beispieldateien bzgl. der Hostnamen der genutzten Server unbedingt anzupassen.

Nach der Festlegung der Konfiguration müssen noch die Lizenzdateien und die fehlenden Software-Archive in den entsprechenden Verzeichnissen

$GSB_ADMIN_HOME/licenses

und

$GSB_ADMIN_HOME/extern

bereitgestellt werden.

Administrations-Skript gsbinstall

Bei der Installation der einzelnen Komponenten werden Sie vom mitgelieferten Build-Tool Ant unterstützt. Das Build-Tool Ant muss nicht separat installiert oder aufgerufen werden. Es wird über das Administrations-Skript gsbinstall aufgerufen.

Folgender Aufruf gibt eine Übersicht über alle zur Verfügung stehenden Targets:

<syntaxhighlight lang="xml" enclose="div">gsbinstall -projecthelp</syntaxhighlight>

Anmerkung:

Sollten beim Aufruf Fehler auftreten, so sind die entsprechenden Umgebungsvariablen und die Berechtigungen der Dateien unter ~/gsb/active/basis/bin zu überprüfen bzw. zu setzen:

<syntaxhighlight lang="xml" enclose="div">chmod –R 755 ~/gsb/active/basis/bin</syntaxhighlight>

Bei der Beschreibung der Kommandos für die Installation der einzelnen Komponenten gehen wir von folgenden Annahmen aus:

Aufrufe, die mit cm beginnen, werden immer im Installationsverzeichnis der jeweiligen Komponente ausgeführt.
Aufrufe von gsbinstall arbeiten immer ausgehend vom Basis-Verzeichnis ~/gsb/active/basis. Wenn gsbinstall aus einem anderen Verzeichnis heraus aufgerufen wird, müssen die als Parameter angegebenen Dateinamen mit absoluten Pfaden angegeben werden.
Das Installationsverzeichnis einer Komponente setzt sich aus dem Wert der in den Build-Dateien konfigurierten Variablen „bol_home“ und dem Pfad coremedia/komponentenname zusammen.

Beim Content-Server würde das Installationsverzeichnis unter der Annahme, dass die Vorbelegung von bol_home aus den Build-Dateien verwendet wird, wie folgt lauten:

/opt/gsb/active/coremedia/contentserver

Zur einfachen Konfiguration des gesamten Systems wird empfohlen, den vorkonfigurierten Installationspfad beizubehalten.

Der Installationspfad des Apache2-Web-Servers ist fest vorgegeben und kann nicht geändert werden:

/opt/gsb/active/Apache2

Installationsablauf

Die eigentliche Installation der Komponenten Content-Server, Master-, Slave-Live-Server, Workflow-Server, Suchmaschine, Tomcat (Content), Tomcat (Master-/Slave-Live), Apache etc. erfolgt in zwei Schritten:

Zuerst muss jede der gewünschten Komponenten aktiviert werden, indem die zugehörige Build-Datei als Parameter an das mitgelieferte Build-Tool gsbinstall übergeben wird.

Beispiel: Zur Aktivierung des Content-Servers ist folgender Aufruf zu nutzen: <syntaxhighlight lang="xml" enclose="div">gsbinstall activateComponent $GSB_ADMIN_HOME/config/build_contentserver.properties</syntaxhighlight>

Nachdem für alle gewünschten Komponenten die zugehörigen Build-Dateien im Verzeichnis $GSB_ADMIN_HOME/config erstellt sind, kann die Aktivierung auch in einem Schritt erfolgen:

<syntaxhighlight lang="xml" enclose="div">gsbinstall activateComponent $GSB_ADMIN_HOME/config/build_*.properties</syntaxhighlight>

Nachdem alle Komponenten so aktiviert worden sind, kann das komplette System installiert werden: <syntaxhighlight lang="xml" enclose="div">gsbinstall rebuildSystem</syntaxhighlight>

Jeder Aufruf von gsbinstall übergibt typischerweise einen „Target“-(Befehls)-Namen (z. B. activateComponent), der angibt, welche Aktion durchgeführt werden soll, zusammen mit eventuellen weiteren Parametern, z. B. einer Build-Datei, in der die Konfigurationsparameter der Komponente definiert werden.

Zugangsdaten

An mehreren Stellen (Datenbank, Tomcat, Apache, Content-Server, Live-Server, Workflow-Server) werden Zugangsdaten (Benutzer/Passwörter) im System abgelegt. Da bei Auslieferung des GSB alle Passwörter Standardwerte enthalten, sollten bei der Installation eines produktiven Systems alle Passwörter geändert werden, um Sicherheitslücken zu vermeiden.

Voraussetzungen

Für den Produktivbetrieb des Government Site Builder ist SUSE Linux Enterprise Server 12 in Verbindung mit einer Oracle 12 Datenbank vorgesehen. Details zu den unterstützten Datenbanken und Versionen sind auch dem entsprechenden Kapitel des CoreMedia Dokuments Supported Environments zu entnehmen. Im Folgenden wird davon ausgegangen, dass

eine Oracle-Datenbank benutzt wird.
Die Installation unter dem User cmadmin stattfindet.

Komponente	Version
CoreMedia CMS	CM 7.1.12-9
Betriebssystem	Suse Linux Enterprise Server 12 (64-Bit)
Datenbank	Oracle 12c Release 2
Java	Oracle Java SE 8u202, 64 Bit für Serverkomponenten Oracle Java SE 8, latest version, 32 Bit für den Java-Editor (SiteManager)
Servlet Container	Tomcat 7.0.82
Webserver	Apache HTTP-Server 2.4.26
Suchmaschine	Apache Solr 4.10.4
LDAP	OpenLDAP
Java-Editor (SiteManager)	Windows 7 (64 Bit) Oracle Java SE 8, latest version (32 Bit) Microsoft Office 2010 (Rechtschreibprüfung)
GSBEditor/web	Firefox ESR Release 60 Google Chrome Microsoft Edge

Installierte Software

Vor der eigentlichen Installation müssen die folgenden Komponenten installiert sein:

Java SE Development Kit (JDK)

Sowohl für die Server als auch für den Java-Editor ist dieselbe Java-Version vorgeschrieben, da es bei einem Mischbetrieb zu Problemen kommen kann.

Bei der Installation ist zu beachten, dass für die Installation der Server eine reine JRE nicht ausreicht, es wird ein JDK benötigt. Für den Editor kann auch nur die JRE installiert werden.

Soll der Java-Editor auf Client-Rechnern per WebStart installiert werden, so sind dort vorher das passende JDK und JavaWebStart zu installieren.

Architektur / Hostnamen / Ports

Sämtliche Komponenten der gesamten Architektur können auf jeweils eigener Hardware installiert werden, wodurch ein sehr skalierbares und ausfallsicheres System entsteht.

Die GSB/CoreMedia-Server Content-Server, Workflow-Server und Active-Delivery-Server sowie der Web-Server Apache, die Suchmaschine und die Datenbank müssen teilweise untereinander und von den Arbeitsplatzrechnern aus erreichbar sein. Dazu werden in der Konfiguration jedes Servers die Hostnamen der von ihm jeweils benötigten weiteren Server angegeben.

Hostnamen-Auflösung

Damit sämtliche beteiligte Hostnamen, inklusive der VirtualHost-Definitionen des Apache, aufgelöst werden können, sollten sie im DNS eingetragen sein.

Alternativ können die Hostnamen aller Rechner auch auf allen Rechnern jeweils in der Datei /etc/hosts (Unix) aufgeführt werden, z. B.:

192.168.1.23 preview.domain.example www.domain.example192.168.1.45 database.domain.example

Die oben angegebenen IP-Nummern und Rechnernamen werden ausschließlich in dieser Dokumentation benutzt und dürfen in einer produktiven Installation nicht verwendet werden. Die Zeichenfolge domain.example steht als Platzhalter für die tatsächliche IP-Domain der Installation. Die Subnetze 192.168.x.y werden nicht geroutet, müssen also ebenfalls in konkreten Installationen durch die tatsächlich vergebenen IP-Nummern ersetzt werden.

Da man diese Namensliste auf allen beteiligten Rechnern, also auch auf den Arbeitsplatz-Rechnern, aktuell halten muss, wird von dieser Lösung (Eintrag in die hosts-Datei) abgeraten und die Verwendung eines Domain-Name-Servers (DNS) empfohlen.

Vereinfachte Architektur

In den ausgelieferten Beispiel-Konfigurationsdateien unterhalb von

gsb/active/basis/buildProperties

wird zur vereinfachten Installation davon ausgegangen, dass sämtliche Komponenten auf einem System installiert werden. Lediglich die Oracle-Datenbank und die optionale Suchmaschine werden auf einem eigenen System erwartet.

Um eine Umkonfiguration zur Verteilung der Komponenten auf dedizierte Systeme zu erleichtern, sind in Kommentaren die Parameter mit sprechenden Hostnamen versehen worden. Dadurch ist die Änderung der Konfiguration intuitiv möglich.

Server-Komponente	Hostname
Content-Server	content.domain.example
Datenbank	database.domain.example
Preview	preview.domain.example
Workflow-Server	workflow.domain.example
Web-Start-Editor	editor.domain.example
Suchmaschine	search.domain.example
Mail-Server	mail.domain.example
Master-Live-Server	master.domain.example
Slave-Live-Server	slave.domain.example

Bei einem isolierten Vorführsystem reicht es, sämtliche benutzte Hostnamen in die hosts-Datei des Systems einzutragen, z. B.:

<syntaxhighlight lang="xml" enclose="div"> 192.168.1.2 content.domain.example database.domain.example 192.168.1.2 workflow.domain.example 192.168.1.2 search.domain.example mail.domain.example 192.168.1.2 master.domain.example slave.domain.example</syntaxhighlight>

Jeder Mandant benutzt zusätzlich seine eigenen Web-Adressen (URLs) für den Preview und den Live-Web-Server, die jeweils als VirtualHost im Apache definiert sind. Diese Hostnamen müssen für den Apache, die Tomcat-Server und die Editoren aufzulösen sein. Eine Zeile in der hosts-Datei des Servers oder Client-Rechners lautet z. B.:

<syntaxhighlight lang="xml" enclose="div"> 192.168.1.2 preview.standardlsg.domain.example 192.168.1.2 www.standardlsg.domain.example</syntaxhighlight>

Die IP-Adresse des lokalen Server-Systems 192.168.1.2 ist entsprechend den lokalen Gegebenheiten anzupassen.

Will man von einem Client-Rechner auf diesen Server zugreifen, so sind die Hostnamen in die hosts-Datei des Client-Rechners einzutragen. Die Lage der hosts-Datei ist abhängig vom Betriebssystem:

Unix	/etc/hosts
Windows XP	C:\WINDOWS\SYSTEM32\DRIVERS\ETC\HOSTS
Windows 2000	C:\WINNT\SYSTEM32\DRIVERS\ETC\HOSTS

Bei einem produktiven System müssen die tatsächlichen Hostnamen in die Konfigurationsdateien eingetragen und das DNS um die Hostnamen der VirtualHost-Definitionen ergänzt werden.

Port-Nummern und Verzeichnisse

Bei der Installation auf ein System ist wichtig zu beachten, dass es zwischen den einzelnen Komponenten insbesondere in Hinblick auf verwendete Ports und Verzeichnisse keine Überlappungen bzw. Konflikte gibt. Daher sind die ausgelieferten Konfigurationsdateien mit entsprechend disjunkten Parameterwerten versehen worden. Folgende Tabelle listet die konfigurierten Parameter:

Komponente	Parameter	Wert
Content-Server	HTTP-Port der IOR-URL	44441
	IIOP-Port	44444
	Installationsverzeichnis	/opt/gsb/active/coremedia/contentserver
	Logverzeichnis	/space/gsb/active/coremedia/contentserver
Workflow-Server	HTTP-Port der IOR-URL	44450
	IIOP-Port	44445
	Installationsverzeichnis	/opt/gsb/active/coremedia/workflowserver
	Logverzeichnis	/space/gsb/active/coremedia/workflowserver
Master-Live-Server	HTTP-Port der IOR-URL	34441
	IIOP-Port	dynamisch ausgehandelt (44446)
	Installationsverzeichnis	/opt/gsb/active/coremedia/master-live
	Logverzeichnis	/space/gsb/active/coremedia/master-live
Slave-Live-Server	HTTP-Port der IOR-URL	24441
	IIOP-Port	dynamisch ausgehandelt (44447)
	Installationsverzeichnis	/opt/gsb/active/coremedia/slave-live
	Logverzeichnis	/space/gsb/active/coremedia/slave-live
Preview-Tomcat	HTTP-Port	8001
	Loopback-Port	8011
	Server-Port	8005
	Installationsverzeichnis	/opt/gsb/active/coremedia/contentserver/tomcat
	Logverzeichnis	/space/gsb/active/coremedia/contentserver/tomcat
Live-Tomcat (Master)	HTTP-Port	8101
	Loopback-Port	8111
	Server-Port	8105
	Installationsverzeichnis	/opt/gsb/active/coremedia/master-live/tomcat
	Logverzeichnis	/space/gsb/active/coremedia/master-live/tomcat
Live-Tomcat (Slave)	HTTP-Port	8201
	Loopback-Port	8211
	Server-Port	8205
	Installationsverzeichnis	/opt/gsb/active/coremedia/slave-live/tomcat
	Logverzeichnis	/space/gsb/active/coremedia/slave-live/tomcat
Apache	HTTP-Port	80
	Installationsverzeichnis	/opt/gsb/active/Apache2
	Logverzeichnis	/space/gsb/active/Apache2/logs

Datenbank-Konfiguration

Es wird davon ausgegangen, dass zur Installation des GSB eine Oracle-Datenbank verwendet wird. In den ausgelieferten Konfigurationsdateien sind einige Datenbank-spezifische Einstellungen enthalten, die in folgender Tabelle aufgelistet sind. Darüber hinaus enthält die Tabelle einige Konfigurationsparameter der Datenbank, die vor der Installation überprüft werden sollten.

Parameter	Wert	Bemerkung
Hostname	database.domain. example
Default tablespace	coremedia
Temporary tablespace	temp
SID	GSB
Admin-Account	system/oracle
Datenbank encoding	UTF8	Überprüfung mit: select * from nls_database_parameters;Dabei müssen NLS_CHARACTERSET und NLS_NCHAR_CHARACTERSET den Wert „UTF8“ besitzen.
Benutzer-Account für den Content-Server	CMCONTENT/ CMCONTENT	SQL-Statement zum Anlegen des Benutzers, siehe Kap. 4.1.12
Benutzer-Account für den Master-Live-Server	CMMASTER/ CMMASTER	SQL-Statement zum Anlegen des Benutzers, siehe Kap. 4.1.12
Benutzer-Account für den Slave-Live-Server	CMSLAVE/ CMSLAVE	SQL-Statement zum Anlegen des Benutzers, siehe Kap. 4.1.12
Benutzer-Account für Content-Tomcat	CMTOMCATCONTENT/CMTOMCATCONTENT	SQL-Statement zum Anlegen des Benutzers, siehe Kap. 4.1.12
Benutzer-Account für Master-Live-Tomcat	CMTOMCATLIVE/CMTOMCATLIVE	SQL-Statement zum Anlegen des Benutzers, siehe Kap. 4.1.12

Werden andere DB-Konfigurationen verwendet (z. B. Hostname, SID), so sind diese in den Build-Dateien entsprechend anzupassen. Dies sind alle Build-Dateien mit Ausnahme der Datei build_apache_example.properties.

Konfiguration der GSB-Mandanten

Die folgenden Mandanten werden ausgeliefert:

der Mandant GSBAdmin
der Mandant standardlsg

Die GSB-Mandanten benötigen Konfigurationsparameter, die sich auch auf die Systemkonfiguration auswirken: So ist sicherzustellen, dass die konfigurierten Parameter z. B. durch Anpassung der verwendeten Hostnamen-Auflösung Verwendung finden können oder entsprechend andere Parameter in der Applikationskonfiguration verwendet werden. Insbesondere die aufgeführten Hostnamen müssen auch von den Editoren, die üblicherweise auf anderen Rechnern installiert werden, korrekt auf die IP-Adresse des Installationsrechners aufgelöst werden (siehe Kapitel Hostnamen-Auflösung).

Konfiguration „GSBAdmin“

Parameter	Wert
ServerFQHN_preview	preview.GSBAdmin.domain.example
ServerFQHN_live	www.GSBAdmin.domain.example
ContentServer	content.domain.example
WorkflowServer	workflow.domain.example

Konfiguration „Standardlösung“

Parameter	Wert
ServerFQHN_preview	preview.standardlsg.domain.example
ServerFQHN_live	www.standardlsg.domain.example
ContentServer	content.domain.example
WorkflowServer	workflow.domain.example

Verfahren zur Installation und Administration

In diesem Kapitel werden einige Anwendungsfälle für die Installation von Liefereinheiten (Release, Service-Pack, Patch, Mandant) beschrieben und die dabei notwendigen Arbeitsabläufe festgelegt.

Bitte lesen Sie dieses Kapitel vorbereitend zur Installation.

Beachten Sie, dass die Installation erst mit dem Kapitel 4 „Installation des Servers“ beginnt!

Verzeichnisstruktur

Für die Installation, Administration und den Betrieb der Software gibt es die drei Verzeichnisbäume

Quellverzeichnis
Installationsverzeichnis
Administrationsverzeichnis

Quellverzeichnis

Im Quellverzeichnis werden die für eine Software-Installation notwendigen Dateien ausgepackt. Die Quellverzeichnisse aller Liefereinheiten haben ein gemeinsames Wurzelverzeichnis.

~cmadmin/gsb	Basisverzeichnis der GSB-Software, entspricht $GSB_HOME
~cmadmin/gsb/Rnr_Snr	Verzeichnis einer Version des GSB-Kerns
~cmadmin/gsb/active	Verzeichnis der aktiven Version des GSB-Kerns
~cmadmin/gsb/*/version.txt	Textdatei mit der Versionsnummer der jeweiligen Version, insbesondere zur Erkennung im active-Verzeichnis, stimmt mit Rnr_Snr überein
~cmadmin/gsb/*/build_id.txt	Textdatei mit der Versionsnummer und der Build-ID (Datum, Uhrzeit des Builds) der jeweiligen Version
~cmadmin/gsb/*/patchlevel.txt	Textdatei mit dem Patch-Stand der jeweiligen Version, falls ein Patch eingespielt wurde
~cmadmin/gsb/active/basis	Basisverzeichnis des GSB-Kerns, früher $BOL_DEV_HOME
~cmadmin/gsb/active/patches	Verzeichnis der Patches des GSB-Kerns
~cmadmin/gsb/customers	Verzeichnis, in dem die Basisverzeichnisse ${MANDANT}_basis der Mandanten abgelegt sind, entspricht $GSB_CUSTOMERS_DIR

Das Quellverzeichnis, in dem die Kern-Software nach dem Auspacken liegt, trägt den Namen des Releases/Service-Packs:

~/gsb/Rnr_Snr

Der Name jeder Version hat den Aufbau

Rnr_Snr

mit Release-Nummer Rnr und Service-Pack-Nummer Snr, wobei _Snr auch wegfallen kann.

Um ein Release/Service-Pack zu installieren, muss es vorher aktiviert werden. Dazu wird das Verzeichnis

~/gsb/Rnr_Snr

per Administrationsskript in

~/gsb/active

umbenannt.

Der Name des Wurzelverzeichnisses für alle Quellverzeichnisse wird während einer Installation automatisch in der Umgebungsvariablen GSB_HOME abgelegt und ändert sich bei einer neuen Installation nicht.

<syntaxhighlight lang="xml" enclose="div">GSB_HOME=~/gsb; export GSB_HOME</syntaxhighlight>

Innerhalb des Quellverzeichnisses liegen die Verzeichnisse

basis	GSB-Kern
patches	Patches

Außerdem befindet sich dort die Datei

~/gsb/Rnr_Snr/version.txt

Die Datei enthält den Versionsstand des Verzeichnisses:

Rnr_Snr

Folgende Datei enthält die Build-ID (Datum, Uhrzeit des Builds) sowie den Versions- und Patch-Stand des Verzeichnisses,

~/gsb/Rnr_Snr/build_id.txt

z. B.:

Version: R7.1_Build_1082Build-ID: 20161026_1082Release-Tag: GSB_R7_1

Wenn in dieser Version ein Patch eingespielt wurde, befindet sich dort die Datei

~/gsb/Rnr_Snr/patchlevel.txt

Sie enthält den Patch-Stand des Verzeichnisses:

Pnr

Neben den Kern-Verzeichnissen liegt das Mandantenverzeichnis

~/gsb/customers

Außerhalb der Quellverzeichnisse liegen die administrativen Daten des Plattformbetreibers (s. u.).

Installationsverzeichnis

Im Installationsverzeichnis liegt die installierte und komplett konfigurierte Software. Diese wird bei einem Installationsvorgang aus dem Quellverzeichnis und den Konfigurationsdateien im Administrationsverzeichnis erstellt. Neben einer aktuellen Software-Installation können im Verzeichnis oberhalb des Installationsverzeichnisses auch ältere bzw. andere Software-Versionen installiert sein.

/opt/gsb	Basisverzeichnis für alle Installationen der GSB-Software
/opt/gsb/R3.0	Installationsverzeichnis einer inaktiven (meist älteren) Version der GSB-Software, z. B. Release 3.0
/opt/gsb/active	Installationsverzeichnis der aktiven Version der GSB-Software
/opt/gsb/*/version.txt	Textdatei mit der Versionsnummer der jeweiligen Version, insbesondere zur Erkennung im active-Verzeichnis, stimmt mit Rnr_Snr überein
/opt/gsb/*/build_id.txt	Textdatei mit der Versionsnummer und der Build-ID (Datum, Uhrzeit des Builds) der jeweiligen Version
/opt/gsb/*/patchlevel.txt	Textdatei mit dem Patch-Stand der jeweiligen Version, falls ein Patch eingespielt wurde
/space/gsb/active	Verzeichnis für die im Produktionsbetrieb anfallenden Daten der GSB-Software, z. B. Log-Dateien, Lucene-Index; bleibt bei einer Update-Installation erhalten

Damit die komplette (Update-)Installation mit dem Benutzer cmadmin erledigt werden kann, braucht man für die Ablage der aktuellen und der älteren Versionen ein Verzeichnis, auf dem der Benutzer das Schreibrecht hat. Dies sind die Verzeichnisse

/opt/gsb/space/gsb

Das Zielverzeichnis, in dem die aktuelle Software nach der Installation liegt, ist dann:

/opt/gsb/active/space/gsb/active

oder z. B. (Windows)

D:\opt\gsb\activeE:\space\gsb\active

Innerhalb des Installationsverzeichnisses liegen je nach Installationsumfang (Komponentenauswahl) die Verzeichnisse

coremedia	CoreMedia-Software
bol	BundOnline-Software
Apache2	Apache Web-Server (Version 2.x)

Außerdem befindet sich dort folgende Datei

/opt/gsb/active/version.txt

Sie enthält den Versionsstand der Installation:

Rnr_Snr

Wenn in dieser Version ein Patch eingespielt wurde, befindet sich dort folgende Datei:

/opt/gsb/active/patchlevel.txt

Sie enthält den Patch-Stand des Verzeichnisses:

Pnr

Wenn ein weiteres Release/Service-Pack installiert werden soll, wird dieses active-Verzeichnis in den Release/Service-Pack-Namen Rnr_Snr umbenannt und das neue Release/Service-Pack bekommt wieder den Standardnamen active.

Der Name der nicht-aktuellen Versionen hat den Aufbau

/opt/gsb/Rnr_Snr

mit Release-Nummer Rnr und Service-Pack-Nummer Snr, wobei _Snr auch wegfallen kann.

Wenn eine ältere Version zur aktuellen gemacht werden soll, dann wird zunächst das aktuelle Verzeichnis wie oben umbenannt und anschließend bekommt das gewünschte Verzeichnis wieder den Standardnamen.

Beispiel:

<syntaxhighlight lang="xml" enclose="div">mv /opt/gsb/active /opt/gsb/R2_S3 mv /opt/gsb/R2_S2 /opt/gsb/active</syntaxhighlight>

Dies erledigt das Administrationsskript automatisch.

Variable Daten

Beim Ablauf der Software fallen Daten an, die abgelegt und verwaltet werden müssen, z. B. Log-Dateien und der Lucene-Index. Typischerweise werden solche dynamischen Daten in einem eigenen Bereich des Massenspeichers (Festplattenpartition) außerhalb der Software-Installation abgelegt.

Auch bei einer GSB-Installation kann man für jede Komponente in deren Konfigurationsdatei festlegen, wo die dynamischen Daten abgelegt werden sollen. Beispiel (build_tomcat_preview_example.properties):

tomcat_home=/opt/gsb/active/coremedia/contentserver/tomcattomcat_webapps_dir=/opt/gsb/active/coremedia/contentserver/tomcat/webappstomcat_logs_dir=/space/gsb/active/coremedia/contentserver/tomcatWährend der obige Tomcat in einem Unterverzeichnis von /opt installiert wird, wird als Basisverzeichnis für all seine dynamischen Daten ein gleichnamiges Unterverzeichnis von /space angegeben, wo im laufenden Betrieb dann das logs-Verzeichnis abgelegt wird.

Die Web-Applikation cae legt keine Daten unterhalb ihres Installationsverzeichnisses ab, sie greift aber auf einen vom Indexer generierten Lucene-Index über einen definierbaren Pfad zu.

Diese Verzeichnisorganisation hat den Vorteil, dass sich unter /space keine Software mehr befindet. Daher wird bei einem Software-Update nur noch unter /opt/gsb die alte Software weggeräumt und die neue installiert, das Verzeichnis /space mitsamt dem Lucene-Index und den Log-Dateien bleibt bei einer Update-Installation erhalten.

Administration

Die administrativen Daten des Plattformbetreibers liegen im Verzeichnis

~/admin

oder auch

$GSB_ADMIN_HOME

Empfohlen wird eine Verzeichnisstruktur, in der die entsprechenden Dateien abgelegt werden:

Im Administrationsverzeichnis $GSB_ADMIN_HOME (Unix) bzw. %GSB_ADMIN_HOME% (Windows) befinden sich die plattformspezifischen Konfigurationsdateien, Log-Dateien und evtl. weitere Administrations-Software, soweit sie nicht direkt aus dem Quellverzeichnis benutzt wird.

~cmadmin/admin	Verzeichnisbaum für die Administration der aktuellen Installation, muss als Umgebungsvariable GSB_ADMIN_HOME gesetzt werden
~cmadmin/admin/config	Konfigurationsdateien für die aktuelle Installation
~cmadmin/admin/extern	Zusätzliche Software z. B. Datenbanktreiber, CoreMedia Installationsdateien (Artefakt-Zip-Datei)
~cmadmin/admin/licenses	CoreMedia-Lizenzdateien für die aktuelle Installation
~cmadmin/admin/logs	Logdateien der Administration

Wichtige Konfigurationsdateien aus ~cmadmin/admin/config:

host_specific.properties	Definitionen für diesen Rechner
components.properties	Liste der Komponenten
build_Komponentenname. properties	Definitionen für eine Komponente
gsbinstall.log	Protokoll der Aktionen

Patch

Jeder Patch hat ein Quellverzeichnis, das seinen Namen (Version) trägt und in dem patches-Verzeichnis des Quellverzeichnisses des zugehörigen Releases/Service-Packs liegt:

~/gsb/Rnr_Snr/patches/Rnr_Snr_Pnr~/gsb/active/patches/Rnr_Snr_Pnr

Jeder Patch gehört zu genau einem Release/Service-Pack.

Innerhalb des Quellverzeichnisses für einen Patch liegen die zu ersetzenden Dateien in der gleichen Verzeichnisstruktur wie das Quellverzeichnis für ein Release.

Allerdings besteht ein Patch nur aus der minimal notwendigen Anzahl an Dateien, die zu ändern sind, und den folgenden administrativen Dateien:

readme.txt	enthält Erläuterungen zum Patch und zu seiner Installation
build.xml	enthält die Beschreibung der Durchführung des Patches und wird während der Patch-Installation aufgerufen
patchlevel.txt	Patch-Nummer in der bekannten Form Pnr
files.txt	enthält die Liste der im Patch enthaltenen Dateien
remove.txtv	enthält die Liste der mit dem Patch zu löschenden Dateien
patchinfo.txt	einige administrative Angaben zu dem Patch

Die Datei patchinfo.txt hat den Aufbau:

Patch-Nummer (gsb_patchlevel) in der bekannten Form Pnr
Notwendige Software-Version für die Durchführung der Patch-Installation (gsb_version_pred) in der Form Rnr_Snr
Patch-Nummer des notwendigen Vorgängers (gsb_patchlevel_pred) in der Form Pnr bzw. „not patched“ beim ersten Patch

Beispiel:

# patchinfo.txtgsb_patchlevel=P1gsb_version_pred=R3.0gsb_patchlevel_pred=not patched

Erstinstallation

Vorbereitung der Systemumgebung

Die Vorbereitung der Systemumgebung ist nur bei einer Erstinstallation erforderlich, um die Infrastruktur auf dem System zu erzeugen.

Aufgaben als Administration „root“:

Für den GSB-Administrator die Benutzerkennung cmadmin anlegen. In Linux z.B. mit

<syntaxhighlight lang="xml" enclose="div">useradd cmadmin</syntaxhighlight>

Arbeitsverzeichnisse für den GSB-Administrator anlegen und Berechtigungen vergeben für /opt/gsb, /space/gsb

<syntaxhighlight lang="xml" enclose="div">mkdir /opt/gsb /space/gsb chown cmadmin:users /opt/gsb /space/gsb</syntaxhighlight>

Es wird davon ausgegangen, dass der User keine root-Rechte besitzt!

Anzahl File-Handles eintragen. Für den Anwender cmadmin ist der Wert „open Files“ auf 4096 zu setzen.

Folgende Zeilen in der /etc/security/limits.conf hinzufügen:

<syntaxhighlight lang="xml" enclose="div">cmadmin soft nofile 4096 cmadmin hard nofile 4096</syntaxhighlight>

Folgende Zeile in die /etc/pam.d/xdm und /etc/pam.d/su eintragen:

<syntaxhighlight lang="xml" enclose="div">session required pam_limits.so</syntaxhighlight>

Damit die Einträge wirksam werden, ist das System zu rebooten.

In der Umgebung des Benutzers cmadmin ist dafür zu sorgen, dass

die Umgebungsvariable JAVA_HOME auf das Java Installationsverzeichnis gesetzt wird,

JAVA_HOME/bin in die Umgebungsvariable PATH aufgenommen wird (z.B. in der Datei ~/.profile des Benutzers cmadmin):

<syntaxhighlight lang="xml" enclose="div">PATH=$JAVA_HOME/bin:$PATH; export PATH</syntaxhighlight>

Die Hostnamen-Definitionen sind entsprechend Kapitel Hostnamen-Auflösung“ umzusetzen.

Später sind Anpassungen erforderlich, wenn neue Mandanten hinzukommen oder sich anderweitig VirtualHost-Definitionen ändern, jedoch nur, wenn die benötigten Host-Namen nicht im DNS definiert sind.

Update-Installation

Bei einer Update-Installation werden die Liefereinheiten genauso ausgepackt wie bei der Erstinstallation (siehe Kapitel Auspacken der Liefereinheiten).

Dann muss das neue Release/Service-Pack als das aktuelle ausgewählt werden. Dies geschieht, indem man genau das Skript gsbinstall aus dem gewünschten Paket ausführt:

<syntaxhighlight lang="xml" enclose="div">sh ~/gsb/Rnr_Snr/basis/bin/gsbinstall activateRelease</syntaxhighlight>

oder unter Windows

<syntaxhighlight lang="xml" enclose="div">gsb/Rnr_Snr/basis/bin/gsbinstall activateRelease</syntaxhighlight>

Damit wird das Verzeichnis der alten Version

~/gsb/active

in ihren Originalnamen umbenannt

~/gsb/Rnr_Snr1

und die neue Version

~/gsb/Rnr_Snr2

Umbenannt in

~/gsb/active

Danach werden die Konfigurationsdateien im Administrationsbereich manuell migriert. Gemäß der mitgelieferten Datei readme.txt bzw. den Release-Notes werden neue Properties ergänzt, vorhandene geändert und überflüssige entfernt, falls notwendig oder gewünscht. Bei Service-Packs werden dabei nur minimale Änderungen oder optionale Erweiterungen angestrebt.

Für die eigentliche Installation werden zuerst die Server-Prozesse beendet.

Anschließend wird eine normale Installation gestartet.

<syntaxhighlight lang="xml" enclose="div">gsbinstall rebuildSystem</syntaxhighlight>

Dabei werden die vorhandenen Zielverzeichnisse umbenannt und die Standard-Zielverzeichnisse neu angelegt.

<syntaxhighlight lang="xml" enclose="div"> mv /opt/gsb/active /opt/gsb/Rnr_Snr mv /space/gsb/active /space/gsb/Rnr_Snr mkdir /opt/gsb/active /space/gsb/active </syntaxhighlight>

Patch-Installation

Ein Patch wird an der gleichen Stelle wie die anderen Liefereinheiten ausgepackt und landet automatisch im patches-Verzeichnis des Quellverzeichnisses des zugehörigen Releases/Service-Packs.

~/gsb/Rnr_Snr/patches/Rnr_Snr_Pnr

bzw.

~/gsb/active/patches/Rnr_Snr_Pnr

Anschließend wird der Patch anhand der mitgelieferten Beschreibung seiner Durchführung angewandt.

Bei der Anwendung wird anhand der Informationen in der Datei patchinfo.txt zunächst getestet, ob die für diesen Patch notwendigen Voraussetzungen (z. B. Vorgängerversion) erfüllt sind. Ist dies der Fall, wird der Patch im zugehörigen Quellverzeichnis eingespielt.

Beim Einspielen eines Patches wird jede Datei, die durch eine neue Version ersetzt oder gelöscht werden soll (files.txt und remove.txt), in einen identisch aufgebauten Sicherungsverzeichnisbaum verschoben.

<syntaxhighlight lang="xml" enclose="div">~/gsb/Rnr_Snr/basis/ ~/gsb/Rnr_Snr/patches/Rnr_Snr_Pnr/backup/basis/ </syntaxhighlight>

Zur Vermeidung allzu tiefer Verzeichnisstrukturen könnte man statt eines Backup-Verzeichnisses auch die Dateien in einem Backup-Archiv (jar-Datei) sammeln.

Danach werden die Patch-Dateien in das Quellverzeichnis kopiert.

<syntaxhighlight lang="xml" enclose="div">~/gsb/Rnr_Snr/patches/Rnr_Snr_Pnr/basis/ ~/gsb/Rnr_Snr/patches/Rnr_Snr_Pnr/patchlevel.txt

~/gsb/Rnr_Snr/basis/ ~/gsb/Rnr_Snr/patchlevel.txt</syntaxhighlight>

Danach wird die Software mit den vorhandenen Konfigurationsdateien neu installiert. Hier kann man entscheiden, ob man für die Installation wie bei der Update-Installation die alten Installationsverzeichnisse umbenennt und neue anlegt oder die Installation in das aktuelle Verzeichnis hinein schreibt.

De-Installation eines Patches

Die zum Patch gehörenden Dateien (files.txt) werden aus dem Quellverzeichnis ~/gsb/Rnr_Snr gelöscht und die ursprünglichen Dateien aus dem Sicherungsverzeichnis ~/gsb/Rnr_Snr/patches/Rnr_Snr_Pnr/backup (bzw. Sicherungsarchiv) ins Quellverzeichnis zurück kopiert.

Wenn beim Einspielen des Patches die alte Installation umbenannt wurde, reicht es, die gewünschte Version wieder als aktuelle umzubenennen. Anderenfalls wird die Software mit den vorhandenen Konfigurationsdateien neu installiert.

Administration

Es werden die folgenden administrativen Tätigkeiten beschrieben:

De-/Aktivierung von Komponenten (activateComponent, deactivateComponent)
Anzeige der aktiven Komponenten (showActiveComponents)
Installation von aktiven Komponenten (rebuildComponent)
De-/Aktivierung von Mandanten

Administration von Komponenten

Systembeschreibung

Sowohl für die Festlegung des kompletten Funktionsumfangs einer GSB-Installation als auch die Verteilung einzelner Komponenten auf verschiedene Systeme ist es notwendig, auf jedem System die Komponenten festzulegen, die dort ablaufen sollen. Diese Liste der aktiven Komponenten wird zusammen gesetzt aus der Property active_components und den Properties Komponente_build_properties_file in der zentralen Konfigurationsdatei

$GSB_ADMIN_HOME/config/components.properties

Die Property active_components beschreibt, welche Komponenten hier administriert werden, die Properties Komponente_build_properties_file enthalten für jede Komponente, die installiert werden soll, deren Build-Properties-Dateinamen

$GSB_ADMIN_HOME/config/build_Komponentennamen.properties

Dabei steht Komponente für den Namen des Komponententyps, der in der Build-Properties-Datei build_Komponentennamen.properties in der Property install_component festgelegt wird. Derzeit zulässige Werte sind:

apache
contentserver
editor
importer
indexer
masterliveserver

slaveliveserver
solrtomcat
tomcatindexer
tomcatlive
tomcatpreview
webstartcommon
webstarteditor
workflowserver

Da für manche Komponenten (Editoren, Tomcats) mehrere Instanzen installiert werden können, kann die Property Komponente_build_properties_file eine mit Leerzeichen getrennte Liste von Dateinamen für die einzelnen Instanzen enthalten.

Während der Installation des GSB bestimmt die Liste in active_components, welche Komponenten installiert werden können, und die jeweiligen Listen Komponente_build_properties_file, welche tatsächlich installiert werden.

Aktivierung von Komponenten

Wenn eine Komponente mit einfachen Mitteln installiert werden soll, muss sie zunächst aktiviert werden. Dies geschieht mit dem folgenden Aufruf:

<syntaxhighlight lang="xml" enclose="div">gsbinstall activateComponent $GSB_ADMIN_HOME/config/build_Komponentennamen.properties</syntaxhighlight>

Dabei wird in der oben beschriebenen, zentralen Konfigurationsdatei eingetragen, welche Build-Properties-Datei für diese Komponente zuständig ist.

Zur nachträglichen Installation einer neuen Komponente ist in der Regel keine komplette Neuinstallation notwendig. Es reicht meistens, die Installation genau dieser Komponente aufzurufen.

<syntaxhighlight lang="xml" enclose="div">gsbinstall rebuildComponent Komponente</syntaxhighlight>

Je nach Art der neuen Komponente kann es danach nötig sein, bestehende Komponenten neu zu starten, um die neue Komponente bekannt zu machen. Dies ist häufig beim Tomcat und der Installation einer neuen Web-Applikation der Fall.

Zu beachten ist, dass bei dem aktuellen Konzept die Neuinstallation einer Komponente bedeutet, dass bei einer Komponente mit mehreren Instanzen alle Instanzen installiert werden. Eine einzelne Instanz ist von der Administrationsschnittstelle aus nicht ansprechbar.

Deaktivierung von Komponenten

Für die Deaktivierung einer Komponente muss deren Build-Properties-Datei aus der Liste Komponente_build_properties_file in der zentralen Konfigurationsdatei gestrichen werden.

<syntaxhighlight lang="xml" enclose="div">gsbinstall deactivateComponent $GSB_ADMIN_HOME/config/build_Komponentennamen.properties</syntaxhighlight>

Die Entfernung einer Komponente aus der Laufzeitumgebung ist in der Regel nur mit einer Neuinstallation der gesamten, verbliebenen Laufzeitumgebung möglich. Daher sollten zuerst alle gewünschten Komponenten deaktiviert werden, bevor man die Installation startet.

Installation des Systems

Wenn alle gewünschten Komponenten wie oben beschrieben aktiviert (und die nicht mehr gewünschten deaktiviert) worden sind, kann die Installation gestartet werden. Dazu werden zuerst die Server-Prozesse beendet.

Anschließend wird eine normale Installation gestartet.

<syntaxhighlight lang="xml" enclose="div">gsbinstall rebuildSystem</syntaxhighlight>

Dabei werden die aktuellen Installationsverzeichnisse umbenannt und alle aktivierten Komponenten neu installiert.

Anzeige der aktiven Komponenten

Folgender Befehl zeigt den Installationsstatus des Systems an, also die Liste der gerade ausgewählten, aktiven Komponenten:

<syntaxhighlight lang="xml" enclose="div">gsbinstall showActiveComponents</syntaxhighlight>

Administration von Mandanten

In GSB-Versionen bis 2.0 musste ein Mandant, der eine mandantenspezifische Komponente benutzen wollte, in der Konfigurationsdatei der Komponente eingetragen werden:

Datei	Property
build_apache_*.properties	apache_customers=standardlsg,test
build_editor_*.properties	editor_customers=standardlsg,test
build_tomcat_*.properties	tomcat_customers=standardlsg,test

Im neuen Installationsschema ist zunächst einmal die zentrale Konfiguration wichtig:

host_specific.properties

active_customers=standardlsg,test

Bei den Mandanten, die in der Liste active_customers enthalten sind, wird zuerst geprüft, ob der Mandant in seinem Basismodul mandantname_basis die Datei

customer.properties

liegen hat, in der die wesentlichen Parameter des Mandanten in seiner Host-Umgebung definiert sind.

Beispiel: Mandant standardlsg

<syntaxhighlight lang="xml" enclose="div"># Global should_configure_apache=true should_configure_tomcat=true should_configure_cae=true should_configure_indexer=true should_configure_solr=true should_configure_webstarteditor=true should_configure_sitebop=true

should_configure_ldap_connection=false

Workflows

customer_specific_workflow_start_roles=standardlsg_wf_start customer_specific_workflow_admin_roles= customer_specific_workflows_to_deploy=

Editor

editor_preview_hostname=preview.standardlsg.domain.example</syntaxhighlight>

Wenn ein Mandant eine solche Datei hat, wird diese bei der Installation als Grundlage für die mandantenspezifischen Installationsteile genommen. Die Installation einer Komponente prüft den Wert der für sie zuständigen Properties (z. B. should_configure_webstarteditor) und benutzt diese Werte für den mandantenspezifischen Anteil der Komponenteninstallation.

Wenn die gewünschte Property nicht vorhanden ist, wird ein Default-Wert angenommen, der komponentenspezifisch ist. Derzeit gilt für should_configure_* ein Wert von false, d. h. der Mandant wird nicht in die Komponente eingebunden.

Komponente	Property	Default-Wert
Apache	should_configure_apache	false
Content-Server	should_configure_ldap_connection	false
Importer	should_configure_importer	false
Indexer	should_configure_indexer	false
Solr	should_configure_solr	false
SiteBOp	should_configure_sitebop	false
Tomcat	should_configure_tomcat	false
Tomcat	should_configure_cae	false
WebStart-Editor	should_configure_webstarteditor	false
WebStart-Editor	editor_preview_hostname	leer
Workflow-Server	customer_specific_workflow_start_roles	leer
Workflow-Server	customer_specific_workflow_admin_roles	leer
Workflow-Server	customer_specific_workflows_to_deploy	leer

Nur wenn diese Datei nicht vorhanden ist, wird für diesen Mandanten auf die alten Properties (apache_customers, editor_customers, usw.) zurückgegriffen.

Es reicht bei der Installation nicht mehr, die Einträge in den Komponenten-Konfigurationsdateien vorzunehmen, man muss jeden Mandanten in die Liste active_customers eintragen.

Aktivierung von Mandanten

Nach dem Auspacken einer Liefereinheit vom Typ „Mandant“ kann der Mandant in die aktuelle GSB-Konfiguration aufgenommen werden. Dazu wird der Name des Mandanten in die Liste der aktiven Mandanten der GSB-Konfiguration eingetragen. Diese Liste ist die Property active_customers in der zentralen Konfigurationsdatei

$GSB_ADMIN_HOME/config/host_specific.properties

Für die eigentliche Installation des Mandanten ist eine Neuinstallation des GSB notwendig, da nur so derzeit die für den neuen Mandanten erforderlichen Parameter in den jeweiligen Komponentenkonfigurationen eingetragen werden. Dazu werden zuerst die Server-Prozesse beendet.

Anschließend wird eine normale Installation gestartet.

<syntaxhighlight lang="xml" enclose="div">gsbinstall rebuildSystem</syntaxhighlight>

Dabei werden die im Mandanten hinterlegten Informationen abgefragt und die zusätzlichen Code- und Datenteile an den zentralen Stellen abgelegt, wo sie gesucht werden.

Version
gewünschte Komponenten
VirtualHosts
Templates
Java-Klassen

Deaktivierung von Mandanten

Für die Deaktivierung eines Mandanten muss dessen Name aus der Liste active_customers in der zentralen Konfigurationsdatei gestrichen und eine Neuinstallation durchgeführt werden.

Anzeige der aktiven Mandanten

Folgender Befehl zeigt den Installationsstatus des Systems an, also die Liste der gerade ausgewählten, aktiven Komponenten:

<syntaxhighlight lang="xml" enclose="div">gsbinstall showActiveCustomers</syntaxhighlight>

Installation des Servers

Die gesamte Anleitung geht von der Annahme aus, dass alle Komponenten auf einem einzigen Server installiert werden. Empfohlen wird, die Datenbank und die optionale Suchmaschine auf eigenen Servern zu installieren.

Für die Installation eines lokalen Java-Editors auf einem Client-Rechner lesen Sie bitte das Kapitel "Installation eines Clients".

Vorbereitungen

Vorhandene Installationen

Falls bereits eine CoreMedia-Installation vorhanden sein sollte, so müssen zunächst alle CoreMedia-Prozesse gestoppt werden. Darüber hinaus ist natürlich empfehlenswert, zunächst ein Backup der vorhandenen Installationen zu erstellen. Die vorhandenen Installationen werden bei einer (Update-)Installation automatisch umbenannt.

Vorbereitung der Systemumgebung

Die unter "Vorbereitung der Systemumgebung" beschriebenen Vorbereitungsschritte müssen auf jeden Fall erledigt sein.

Installationsverzeichnisse

Diese genutzten Verzeichnisse /opt/gsb und /space/gsb sollten zu Beginn der Erstinstallation leer sein, können bei einer Update-Installation bereits Vorversionen enthalten, die die Installation aber nicht stören.

Auspacken der Liefereinheiten

Von dem Installationsmedium müssen alle GSB-Dateien<syntaxhighlight lang="xml" enclose="div"> Software/GSB/GSB_<Release>_<Zeitstempel>.jar

Software/GSB/Admin_basis_<Zeitstempel>.jar

Software/GSB/common_content_<Zeitstempel>.zip

Software/GSB/GSBAdmin_basis_<Zeitstempel>.jar

Software/GSB/GSBAdmin_content_<Zeitstempel>.zip

Software/GSB/standardlsg_basis_<Zeitstempel>.jar

Software/GSB/standardlsg_content_<Zeitstempel>.zip </syntaxhighlight>(wobei derzeit den Wert „R7.1“ hat und das Format YYYYMMDD_HHMM) in das Home-Verzeichnis des Users cmadmin oder ein geeignetes Unterverzeichnis kopiert werden.

Anschließend kann der Benutzer cmadmin die Liefereinheiten in seinem Home-Verzeichnis auspacken. Hierzu stehen – je nach Plattform – beispielsweise Unzip oder Jar zur Verfügung.

Beispielaufruf mit jar:

Bei einem GSB-Release entsteht die folgende Verzeichnisstruktur:

~/gsb/R/basis/       /version.txt

Dieses Verzeichnis ~/gsb/R/basis wird im Folgenden als Basis-Verzeichnis bezeichnet und bildet den Ausgangspunkt für alle Installations-Aufrufe.

Die Mandantenpakete erzeugen die Struktur:

~/gsb/customers/mandantname_basis/~/gsb/customers/mandantname_Content/

Einzelne Mandanten können auch auf das Mandanten-Basis- oder das Content-Modul verzichten.

Da jede Liefereinheit ihr eigenes Verzeichnis enthält, gibt es keine Konflikte bei dem Auspacken verschiedener Liefereinheiten wie Releases und Service-Packs.

Vorbereitung des Administrationsverzeichnisses

Beim Auspacken des GSB-Pakets wird ein Verzeichnis ~/gsb/admin für die Administrations-Infrastruktur erzeugt. Dieses verschiebt man bei der Erstinstallation aus dem Quellverzeichnis heraus an eine zentrale Stelle:

<syntaxhighlight lang="xml" enclose="div">mv ~/gsb/admin ~</syntaxhighlight>

Dieses Verzeichnis bildet die Grundlage der Konfiguration des GSB.

Bei der Erstinstallation muss nun die Konfigurationsdatei

~/gsb/Rnr_Snr/basis/buildProperties/host_specific.properties

in das Verzeichnis

~/admin/config

kopiert werden.

Hinweis: Wird die Datei admin/config/build_webstarteditor_example.properties umbenannt, so muss der Aufruf der Datei in admin/config/build_tomcat_preview_*.properties entsprechend angepaßt werden.

Anpassung der Arbeitsumgebung

Zur Durchführung der Installationstätigkeiten sind zwei Anpassungen bzgl. der Umgebungsvariablen $GSB_ADMIN_HOME, $ANT_OPTS und $PATH notwendig. Diese Anpassungen werden bei allen Aktivitäten vorausgesetzt, ohne dass dies weiter erwähnt wird.

Setzen Sie die Umgebungsvariable $GSB_ADMIN_HOME auf das Administrationsverzeichnis und belegen Sie die Umgebungsvariable $ANT_OPTS mit einem erhöhten Speicherwert:

<syntaxhighlight lang="xml" enclose="div">GSB_ADMIN_HOME=~/admin; export GSB_ADMIN_HOME ANT_OPTS="-Xmx1024m"; export ANT_OPTS</syntaxhighlight>

Nehmen Sie das Verzeichnis ~/gsb/active/basis/bin, das nach einem der nächsten Installationsschritte erreichbar sein wird, in die Umgebungsvariable PATH auf, damit das für die weiteren Installationsschritte benötigte Skript

~/gsb/active/basis/bin/gsbinstall

gefunden wird, ohne dass man den Pfad angeben muss:

<syntaxhighlight lang="xml" enclose="div">PATH=~/gsb/active/basis/bin:$PATH; export PATH</syntaxhighlight>

Des weiteren ist darauf zu achten, dass die Spracheinstellungen korrekt sind, da ansonsten die Umlaute beim Contentimport nicht korrekt behandelt werden. Hierzu sind die Umgebungsvariablen $LANG und $LC_ALL korrekt zu setzen.

<syntaxhighlight lang="xml" enclose="div">LANG=en_US.UTF-8; export LANG LC_ALL=en_US.UTF-8; export LC_ALL</syntaxhighlight>

CoreMedia-Installationsdatei

Jetzt können Sie die Installation des CoreMedia-Installations-Jar vorbereiten. Auf dem Installationsmedium ist im folgenden Verzeichnis eine entsprechende Jar-Datei vorhanden:

Software/CoreMedia

Kopieren Sie das CoreMedia-Installations-Jar (cap-7.1.12-9-artifacts.zip) in das Verzeichnis

$GSB_ADMIN_HOME/extern

Anmerkung:

Bitte beachten Sie dabei, dass Sie tatsächlich die auf dem Installationsmedium für den GSB ausgelieferte Installationsdatei verwenden.

CoreMedia-Lizenzdateien

Auf dem GSB-Installationsmedium sind keine CoreMedia-Lizenzen enthalten. Kopieren Sie Ihre Lizenzdateien, die Sie nach dem Abruf der Software gesondert bekommen haben, in das Verzeichnis $GSB_ADMIN_HOME/licenses. Die Dateien müssen wie folgt heißen:

$GSB_ADMIN_HOME/licenses/ContentLicense.zip$GSB_ADMIN_HOME/licenses/MasterLicense.zip$GSB_ADMIN_HOME/licenses/SlaveLicense.zip

Wenn die Lizenzen einen anderen Namen haben sollen, dann müssen diese Namen in den Build-Property-Dateien der jeweiligen Server geändert werden.

Die Lizenzen sind möglicherweise in ihrer Gültigkeit zeitlich oder auf eine IP-Nummer begrenzt. Bitte achten Sie darauf, dass die von Ihnen genutzten Lizenzen in diesem Sinne gültig sind.

JDBC-Datenbanktreiber

Für den Betrieb eines GSB ist die Nutzung einer Datenbank notwendig. Hierzu ist die Installation eines geeigneten JDBC-Datenbanktreibers notwendig.

Auf dem Installationsmedium ist in folgendem Verzeichnis ein JDBC-Treiber für Oracle 11g (ojdbc6.jar) enthalten:

Software/Sonstige/Oracle/11.1.0.7.0

Bitte kopieren Sie diesen oder einen geeigneten anderen JDBC-Datenbanktreiber in das Verzeichnis

$GSB_ADMIN_HOME/extern

und tragen Sie den Namen des verwendeten Treibers in die zentrale Konfigurationsdatei

$GSB_ADMIN_HOME/config/host_specific.properties

in die Property db_driver_jar_name ein:

<syntaxhighlight lang="xml" enclose="div">db_driver_jar_name=ojdbc6.jar</syntaxhighlight>

Die Einbindung des MySQL-Treibers erfolgt analog. Diesen finden Sie auf ebenfalls auf dem Installationsmedium in folgendem Verzeichnis: Software/Sonstige/MySQL/5.1.14

Aktivierung einer Version

Für alle weiteren Aktivitäten muss zuerst ein Release/Service-Pack als das aktuelle ausgewählt werden. Dazu startet man die Aktivierung, indem man genau das Skript gsbinstall aus dem gewünschten Paket ausführt:

<syntaxhighlight lang="xml" enclose="div">sh ~/gsb/Rnr_Snr/basis/bin/gsbinstall activateRelease</syntaxhighlight>

Damit wird das Verzeichnis

~/gsb/Rnr_Snr

~/gsb/active

umbenannt. Gleichzeitig werden die Skripte in folgendem Verzeichnis mit Ausführungsrechten versehen:

~/gsb/active/basis/bin

Anschließend (und nur bei der Erstinstallation) kopiert man die mitgelieferten Beispiel-Konfigurationsdateien in die Administrations-Infrastruktur:

<syntaxhighlight lang="xml" enclose="div">cp ~/gsb/active/basis/buildProperties/*.properties $GSB_ADMIN_HOME/config</syntaxhighlight>

bzw. für die optionalen Komponenten: <syntaxhighlight lang="xml" enclose="div">cp ~/gsb/active/basis/buildProperties/optional/*.properties $GSB_ADMIN_HOME/config</syntaxhighlight>

Dort werden die Parameter der zu erzeugenden Installation festgelegt. Dabei ist es sinnvoll, den Namensteil example durch den Rechnernamen zu ersetzen und auch nur die Dateien zu kopieren, deren Komponenten installiert werden sollen.

Hinweis: Wird die Datei admin/config/build_webstarteditor_example.properties umbenannt, so muss der Aufruf der Datei in admin/config/build_tomcat_preview_*.properties entsprechend angepaßt werden.

Zugriffsrechte

Stellen Sie sicher, dass die installierten Dateien mit den notwendigen Zugriffsrechten (Ausführbarkeit bei den Skripten) ausgestattet sind.

Sollten die notwendigen Ausführungsrechte trotz des vorangegangenen Schritts der Aktivierung fehlen, führen Sie folgende Befehle aus:

<syntaxhighlight lang="xml" enclose="div">cd ~/gsb/active/basis chmod -R 755 bin</syntaxhighlight>

Anlegen der Datenbank-User

Für jede der zu installierenden Komponenten Content-Server, Master-/Slave-Live-Server, Tomcat-Master/Slave und Tomcat-Content ist ein separater Datenbank-User in der jeweils benutzten Datenbank anzulegen.

Als Vorlage können Sie folgendes (Oracle-spezifische!) SQL-Skript heranziehen. Zur Konfiguration der Datenbank und zur Einrichtung der User ziehen Sie aber auf jeden Fall Ihren Datenbank-Administrator hinzu, der Ihnen die für Ihre Installation notwendigen Einstellungen nennen kann.

Für Oracle 10g:

<syntaxhighlight lang="xml" enclose="div">create user <username>

identified by <password>default tablespace <default_tablespace>temporary tablespace <temp_tablespace>quota unlimited on <default_tablespace>;

grant connect, resource, create view to <username>;</syntaxhighlight>

In den ausgelieferten Build-Dateien sind folgende Datenbankbenutzer konfiguriert:

Server	Datenbank-Benutzer
Content-Server	CMCONTENT
Preview-Tomcat	CMTOMCATCONTENT
Master-Live-Server	CMMASTER
Master-/Slave-Live-Tomcat	CMTOMCATLIVE
Slave-Live-Server	CMSLAVE

Für die in den ausgelieferten Build-Dateien vorkonfigurierten Parameter sind folgende, konkrete Kommandos zum Anlegen der Benutzer notwendig. Für diese Kommandos muss man sich auf dem Datenbankrechner als Benutzer oracle anmelden, die Umgebungsvariable ORACLE_SID auf den Namen der gewünschten Datenbank setzen und das Tool sqlplus der Oracle-Installation starten:

<syntaxhighlight lang="xml" enclose="div">su – oracle ORACLE_SID=Name_der_Datenbank ; export ORACLE_SID sqlplus system/manager</syntaxhighlight>

Dann kann man die notwendigen Oracle-Benutzer in der Datenbank anlegen (hier Oracle 10g):

<syntaxhighlight lang="xml" enclose="div">create user cmcontent

identified by cmcontentdefault tablespace coremediatemporary tablespace tempquota unlimited on coremedia;

grant connect, resource, create view to cmcontent; create user cmmaster

identified by cmmasterdefault tablespace coremediatemporary tablespace tempquota unlimited on coremedia;

grant connect, resource, create view to cmmaster; create user cmslave

identified by cmslavedefault tablespace coremediatemporary tablespace tempquota unlimited on coremedia;

grant connect, resource, create view to cmslave; create user cmtomcatcontent

identified by cmtomcatcontentdefault tablespace coremediatemporary tablespace tempquota unlimited on coremedia;

grant connect, resource, create view to cmtomcatcontent; create user cmtomcatlive

identified by cmtomcatlivedefault tablespace coremediatemporary tablespace tempquota unlimited on coremedia;

grant connect, resource, create view to cmtomcatlive;</syntaxhighlight>

MySQL

Für die Installation der MySQL-Datenbank und das Anlegen der entsprechenden Datenbank-User sind die Hinweise im CoreMedia AdministrationOperationManual zu berücksichtigen.

Konfiguration eines Servers

Dieses Kapitel beschreibt, wie die einzelnen Komponenten des Gesamtsystems zu konfigurieren sind, bevor sie installiert werden.

Content-Server

Erstellen einer Build-Datei

Die im Konfigurationsverzeichnis erstellte Build-Datei (siehe Aktivierung einer Version)

$GSB_ADMIN_HOME/config/build_contentserver_localhost.properties

ist anzupassen (insbesondere die DB-Parameter).

Beispiel für die Datenbankparameter in der Build-Datei:

<syntaxhighlight lang="xml" enclose="div"># DB-Verbindungsdaten sql_store_driver=oracle.jdbc.driver.OracleDriver sql_store_url=jdbc:oracle:thin:@database.domain.example:1521:DBname sql_store_user=CMCONTENT sql_store_password=CMCONTENT sql_store_dbProperties=corem/oracle</syntaxhighlight>

Hier, wie auch in allen anderen Build-Dateien, ist es notwendig, die Datenbank-Benutzer und ihre Passwörter in Großbuchstaben anzugeben.

Die mitgelieferte Build-Datei enthält für die MySQL-Anbindung entsprechend auskommentierte Beispielproperties, die entsprechend angepasst und anstatt der Properties für Oracle-Anbindung verwendet werden können.

Workflow-Server

Erstellen einer Build-Datei

Die im Konfigurationsverzeichnis erstellte Build-Datei (siehe Aktivierung einer Version)

$GSB_ADMIN_HOME/config/build_workflowserver_localhost.properties

ist anzupassen (insbesondere die DB-Parameter).

Beispiel für die Datenbankparameter in der Datei

build_workflowserver_localhost.properties:

<syntaxhighlight lang="xml" enclose="div"># DB-Verbindungsdaten

muessen mit denen des Content-Servers uebereinstimmen

sql_store_driver=oracle.jdbc.driver.OracleDriver sql_store_url=jdbc:oracle:thin:@database.domain.example:1521:DBname sql_store_user=CMCONTENT sql_store_password=CMCONTENT sql_store_dbProperties=corem/oracle</syntaxhighlight>

Anmerkung:

Wenn in der Build-Datei der Parameter

should_apply_unlimited_encryption_policies

den Wert true hat, muss der Installationsbenutzer cmadmin auf dem J2SDK-Verzeichnis jre/lib/security, z. B.

$JAVA_HOME/jre/lib/security

Schreibrechte haben.

Lokaler Java-Editor

Der CoreMedia-Java-Editor kann auf zwei Arten installiert werden: lokal auf jedem Client-Rechner separat oder zentral auf dem Content-Server-Rechner, der die jeweils aktuelle Version per Java-WebStart ausliefert. Beide Arten können gleichzeitig durchgeführt werden.

Erstellen einer Build-Datei

Die im Konfigurationsverzeichnis erstellte Build-Datei (siehe Aktivierung einer Version)

$GSB_ADMIN_HOME/config/build_editor_mandant.properties

ist anzupassen (insbesondere die DB-Parameter):

Hier und in allen weiteren Aufrufen ist mandant durch den Namen des jeweiligen Mandanten zu ersetzen.

Falls die Installation auf der gleichen Hardware erfolgt, muss für jeden Mandanten ein eigenes Installationsverzeichnis (Property editor_home) gewählt werden.

Der zu installierende Mandant wird in die Property editor_customers eingetragen:

editor_customers=standardlsg

Anmerkung:

Für eine Installation unter Windows gilt für die Umgebungsvariablen %BOL_DEV_HOME% und %PATH% etc. das bereits in Abschnitt 2 Gesagte. Zusätzlich ist zu beachten:

Die "\"-Zeichen in Pfadangaben sind in der Build-Datei durch Voranstellen eines "\"-Zeichens zu schützen. Beispiel:

C:\\GSB\\Editor_mandant

Die Property bol_home muss auf C:\\ gesetzt werden.

WebStart-Editor

Erstellen einer Build-Datei

Die im Konfigurationsverzeichnis erstellte Build-Datei (siehe Aktivierung einer Version)

$GSB_ADMIN_HOME/config/build_webstarteditor_localhost.properties

ist anzupassen (insbesondere die DB-Parameter):

Die zu installierenden Mandanten, die nicht über eine eigene Datei customer.properties verfügen, werden als kommaseparierte Liste in die Property editor_customers eingetragen, z. B.:

editor_customers=test1,test2

Die ausgelieferten GSB-Mandanten besitzen eine eigene Datei customer.properties und müssen somit hier nicht eingetragen werden.

Tomcat (Content-Server)

In den Installationsverzeichnissen von Content- und Master-/Slave-Live-Server ist jeweils ein eigener Tomcat zu installieren. In der nachfolgenden Beschreibung wird zunächst auf die Installation des Tomcat für den Content-Server eingegangen.

Anlegen der Datenbanktabellen

Vor der Installation müssen in der Datenbank einige Tabellen angelegt und initialisiert werden, über die die Authentisierung der admin-Seiten, sowohl für den Tomcat als auch für die CAE-Web-Applikation, gesteuert wird.

Für die folgenden Kommandos muss man sich auf dem Datenbank-Rechner als Benutzer oracle anmelden und die Umgebungsvariable ORACLE_SID auf den Namen der gewünschten Datenbank setzen:

<syntaxhighlight lang="xml" enclose="div">su – oracle ORACLE_SID=Name_der_Datenbank ; export ORACLE_SID</syntaxhighlight>

Dann kopieren Sie die beiden SQL-Skripte (die sich bei der Tomcat-Installation auf dem Tomcat-Rechner befinden)

~/cmadmin/gsb/active/basis/src/sql/createBkcmsTables_Oracle.sql~/cmadmin/gsb/active/basis/src/sql/initBkcmsTables_Oracle.sql

von dem Tomcat-Rechner auf den Datenbank-Rechner und führen sie auf der Datenbank als Datenbankbenutzer cmtomcatcontent (der bereits im Kapitel "Anlegen der Datenbank-User" angelegt wurde) aus:

<syntaxhighlight lang="xml" enclose="div">sqlplus cmtomcatcontent/cmtomcatcontent @createBkcmsTables_Oracle.sql sqlplus cmtomcatcontent/cmtomcatcontent @initBkcmsTables_Oracle.sql</syntaxhighlight>

Damit werden folgende Authentisierungsdaten in die Datenbank geladen:

Tomcat-Admin	tomcat/tomcat
Admin der Web-Applikation	admin/admin

Diese Einstellungen können bei Bedarf vorher (als Benutzer cmadmin) in dem Skript

~cmadmin/gsb/active/basis/src/sql/initBkcmsTables_Oracle.sql

modifiziert werden. Insbesondere die verwendeten Standard-Passwörter sollten geändert werden.

An dieser Stelle sollten auch die von den Mandanten mitgelieferten SQL-Skripte nach dem gleichen Muster ausgeführt werden, soweit der Mandant dies vorsieht z. B.:

<syntaxhighlight lang="xml" enclose="div">cd ~cmadmin/gsb/customers/standardlsg_basis/src/sql sqlplus cmtomcatcontent/cmtomcatcontent @initStandardlsgTables_Oracle.sql</syntaxhighlight>

Auf dem Installationsmedium befinden sich analoge Skripte die bei Verwendung einer MySQL-Datenbank für das Anlegen und die Initialisierung der Tabellen verwendet werden können.

Erstellen einer Build-Datei

Die im Konfigurationsverzeichnis erstellte Build-Datei (siehe Aktivierung einer Version)

$GSB_ADMIN_HOME/config/build_tomcat_preview_localhost.properties

ist anzupassen (insbesondere die DB-Parameter):

Beispiel für die Datenbankparameter in der Build-Datei:

<syntaxhighlight lang="xml" enclose="div"># DB-Verbindung fuer Datenbankzugriff aus WebApplikationen

muss fuer ALLE Tomcats einer DMZ (Live, Staging, Produktion) identisch sein!

tomcat_db_user=CMTOMCATCONTENT tomcat_db_password=CMTOMCATCONTENT tomcat_db_driver=oracle.jdbc.driver.OracleDriver tomcat_db_url=jdbc:oracle:thin:@database.domain.example:1521:DBname tomcat_db_connection_pool_max_active=8 tomcat_db_connection_pool_max_idle=4</syntaxhighlight>

Es ist darauf zu achten, dass die angegebenen Ports bei der Installation mehrerer Tomcat-Server auf einer Maschine nicht miteinander kollidieren. Dies ist bei den vorkonfigurierten Properties berücksichtigt.

Bei Nutzung von Solr ist für den Verbindungsparameter zu den Solr-Servern das Kommentarzeichen zu löschen und die Server korrekt anzugeben:

<syntaxhighlight lang="xml" enclose="div"># Verbindungen zu solr-Servern solr_server_connects=solr1:9101,solr2:9101</syntaxhighlight>

Die zu installierenden Mandanten, die nicht über eine eigene Datei customer.properties verfügen, werden als kommaseparierte Liste in die Property tomcat_customers eingetragen, z. B.:

tomcat_customers=test1,test2

Die ausgelieferten GSB-Mandanten besitzen eine eigene Datei customer.properties und müssen somit hier nicht eingetragen werden.

Wenn die Web-Applikation zum Ausliefern des Webstart-Editors mit installiert werden soll, müssen die folgenden Properties verwendet werden: <syntaxhighlight lang="xml" enclose="div">

Deployment der Webstart-Editor-Webapplikation mit dem Common-Teil der Erweiterungen

should_deploy_webstarteditor_webapp=true

Deployment des mandantenspezifischen Teils des Webstart-Editors
should_deploy_webstarteditor_customers=true

webstarteditor_properties_file=${env.GSB_ADMIN_HOME}/config/build_webstarteditor_....properties </syntaxhighlight>

Die Property webstarteditor_properties_file soll den Pfad zur aktuellen build.properties-Datei für Webstart-Editor beinhalten.

Bei Verwendung der motgelieferten build_tomcat_preview_example.properties als Vorlage soll man darauf achten, dass diese Property noch angepasst werden soll.

Apache

Jeder Tomcat benötigt einen lokalen Web-Server, der sämtliche vom Tomcat gelieferten Domains ausliefern kann. In den mitgelieferten Beispieldateien für eine Ein-Server-Installation wird dies realisiert, indem ein Apache-Web-Server installiert und dieser mit unterschiedlichen VirtualHosts für Content-Server (Preview) und Master-Live-Server konfiguriert wird.

Wenn auf mehreren Servern Tomcats installiert werden, so ist auf jedem Server, auf dem ein Tomcat installiert ist, ein eigener Apache zu installieren.

Die ausgelieferten Beispieldateien sind so vorkonfiguriert, dass die Installation in das Verzeichnis /opt/gsb/active erfolgt. Dies sollte nicht geändert werden, da ansonsten weitere wesentliche Umkonfigurationen vorgenommen werden müssten. Insbesondere müsste für eine Pfadänderung der Apache neu compiliert werden.

Anmerkung:

Für den Betrieb von HTTPS wird ein Zertifikat benötigt. Das mitgelieferte Zertifikat ~/gsb/active/basis/config/Apache/conf/certificates/ preview.domain.example-cert.pem ist lediglich ein Beispiel, das in einer Installation durch ein echtes Zertifikat ersetzt werden sollte.

Bei der Erzeugung des Zertifikats ist zu beachten, dass in einer Apache-Installation nur ein Zertifikat pro IP-Nummer enthalten sein kann, auch wenn derselbe Apache Web-Server für den Preview und die Live-Tomcats verwendet wird.

Erstellen einer Build-Datei

Die im Konfigurationsverzeichnis erstellte Build-Datei (siehe Aktivierung einer Version) ist anzupassen.

$GSB_ADMIN_HOME/config/build_apache_localhost.properties

Falls man einen Apache 2.2 benutzen möchte, ist die Property apache_name_virtual_host auf die richtige IP-Adresse des Servers zu setzen. Beispiel:

apache_name_virtual_host=NameVirtualHost 192.168.1.2:80

Für die IP-Adresse 192.168.1.2 ist die IP-Nummer des lokalen Servers einzutragen.

Beim Apache 2.4 entfällt diese Definition.

Je nachdem, ob HTTPS gewünscht ist, muss noch die passende Variante der Property apache_listen_ports ausgewählt werden.

Die zu installierenden Mandanten, die nicht über eine eigene Datei customer.properties verfügen, werden als kommaseparierte Liste in die Property apache_customers eingetragen, z. B.:

apache_customers=test1,test2

Die ausgelieferten GSB-Mandanten besitzen eine eigene Datei customer.properties und müssen somit hier nicht eingetragen werden.

Live-Server (Master und Slave)

Anmerkung:

Sollen neben dem Master-Live-Server auch noch Slave-Live-Server installiert werden, so sind die folgenden Abschnitte für jeden Slave-Live-Server zu wiederholen. Hierbei ist konsequent in den Anleitungen „master“ durch „slave“ zu ersetzen.

Erstellen einer Build-Datei

Die im Konfigurationsverzeichnis erstellte Build-Datei (siehe Aktivierung einer Version) ist anzupassen (insbesondere die DB-Parameter):

$GSB_ADMIN_HOME/config/build_masterliveserver_localhost.properties

Beispiel für die Datenbankparameter in der Build-Datei:

<syntaxhighlight lang="xml" enclose="div"># eigene DB-Verbindungsdaten sql_store_driver=oracle.jdbc.driver.OracleDriver sql_store_url=jdbc:oracle:thin:@database.domain.example:1521:DBname sql_store_user=CMMASTER sql_store_password=CMMASTER sql_store_dbProperties=corem/oracle</syntaxhighlight>

Tomcat (Master-Live-Server)

Anmerkung:

Die Installation des Tomcat (Master-Live-Server) erfolgt analog zu der Installation des Tomcat der Review-/Redaktionsumgebung aus Abschnitt 4.2.5. Jedoch besteht bzgl. der durch die Beispieldateien vorgebenen Konfiguration ein deutlicher Unterschied.

Der vorliegende Abschnitt ist daher trotz seiner Ähnlichkeit zu Abschnitt 4.2.5 entsprechend aufmerksam durchzuarbeiten.

Anlegen der Datenbanktabellen

Für die folgenden Kommandos muss man sich als Benutzer oracle anmelden und die Umgebungsvariable ORACLE_SID auf den Namen der gewünschten Datenbank setzen:

<syntaxhighlight lang="xml" enclose="div">su – oracle ORACLE_SID=Name_der_Datenbank ; export ORACLE_SID</syntaxhighlight>

Kopieren Sie folgende SQL-Skripte (die sich bei der Tomcat-Installation auf dem Tomcat-Rechner befinden) von dem Tomcat-Rechner auf den Datenbank-Rechner:

~cmadmin/gsb/active/basis/src/sql/createBkcmsTables_Oracle.sql

~cmadmin/gsb/active/basis/src/sql/initBkcmsTables_Oracle.sql

und führen Sie auf der Datenbank als Datenbankbenutzer cmtomcatcontent (der bereits im Kapitel "Anlegen der Datenbank-User" angelegt wurde) aus:

<syntaxhighlight lang="xml" enclose="div">sqlplus cmtomcatlive/cmtomcatlive @createBkcmsTables_Oracle.sql sqlplus cmtomcatlive/cmtomcatlive @initBkcmsTables_Oracle.sql</syntaxhighlight>

Damit werden folgende Authentisierungsdaten in die Datenbank geladen:

Tomcat-Admin	tomcat/tomcat
Admin der Web-Applikation	admin/admin

Diese Einstellungen können bei Bedarf vorher (als Benutzer cmadmin) in folgendem Skript modifiziert werden:

~/gsb/active/basis/src/sql/initBkcmsTables_Oracle.sql

Die verwendeten Standard-Passwörter sollten geändert werden.

An dieser Stelle sollten auch die von den Mandanten mitgelieferten SQL-Skripte nach dem gleichen Muster ausgeführt werden, soweit der Mandant dies vorsieht z. B.:

<syntaxhighlight lang="xml" enclose="div">cd ~cmadmin/gsb/customers/standardlsg_basis/src/sql sqlplus cmtomcatlive/cmtomcatlive @initStandardlsgTables_Oracle.sql</syntaxhighlight>

Auf dem Installationsmedium befinden sich analoge Skripte die bei Verwendung einer MySQL-Datenbank für das Anlegen und die Initialisierung der Tabellen verwendet werden können.

Erstellen einer Build-Datei

Die im Konfigurationsverzeichnis erstellte Build-Datei (siehe Aktivierung einer Version) ist anzupassen (insbesondere die DB-Parameter):

$GSB_ADMIN_HOME/config/build_tomcat_masterlive_localhost.properties

Beispiel für die Datenbankparameter in der Build-Datei:

<syntaxhighlight lang="xml" enclose="div"># DB-Verbindung fuer Datenbankzugriff aus Web-Applikationen

muss fuer ALLE Tomcats einer DMZ (Live, Staging, Produktion ) identisch sein!

tomcat_db_user=CMTOMCATLIVE tomcat_db_password=CMTOMCATLIVE tomcat_db_driver=oracle.jdbc.driver.OracleDriver tomcat_db_url=jdbc:oracle:thin:@database.domain.example:1521:DBname tomcat_db_connection_pool_max_active=8 tomcat_db_connection_pool_max_idle=4</syntaxhighlight>

Bei Nutzung von Solr ist für den Verbindungsparameter zu den Solr-Servern das Kommentarzeichen zu löschen und die Server korrekt anzugeben:

<syntaxhighlight lang="xml" enclose="div"># Verbindungen zu solr-Servern solr_server_connects=solr1:9101,solr2:9101</syntaxhighlight>

Die zu installierenden Mandanten, die nicht über eine eigene Datei customer.properties verfügen, werden als kommaseparierte Liste in die Property tomcat_customers eingetragen, z. B.:

tomcat_customers=test1,test2

Die ausgelieferten GSB-Mandanten besitzen eine eigene Datei customer.properties und müssen somit hier nicht eingetragen werden.

Auf dem Installationsmedium befinden sich analoge Skripte die bei Verwendung einer MySQL-Datenbank für das Anlegen und die Initialisierung der Tabellen verwendet werden können.

Importer

Erstellen einer Build-Datei

Die im Konfigurationsverzeichnis erstellte Build-Datei (siehe Aktivierung einer Version) ist anzupassen:

$GSB_ADMIN_HOME/config/build_importer_localhost.properties

Die zu installierenden Mandanten, die nicht über eine eigene Datei customer.properties verfügen, werden als kommaseparierte Liste in die Property importer_customers eingetragen, z. B.:

importer_customers=test1,test2

Die ausgelieferten GSB-Mandanten besitzen eine eigene Datei customer.properties und müssen somit hier nicht eingetragen werden.

Import-Dispatcher

Erstellen einer Build-Datei

Die im Konfigurationsverzeichnis erstellte Build-Datei (siehe Aktivierung einer Version) ist anzupassen:

$GSB_ADMIN_HOME/config/build_importdispatcher_localhost.properties

Indexer

Indexer-Client

Der Indexer kann als Standalone Java-Applikation betrieben werden.

Erstellen einer Build-Datei

Die im Konfigurationsverzeichnis erstellte Build-Datei (siehe 4.1.10 Aktivierung einer Version) ist anzupassen. Hierbei ist zu beachten, dass jeweils eine Property-Datei für Lucene und eine für Solr vorhanden ist und beide Komponenten unabhängig voneinander konfiguriert und installiert werden (s.a. Konfiguration des Indexerclients):

$GSB_ADMIN_HOME/config/build_indexer_lucene_localhost.properties

$GSB_ADMIN_HOME/config/build_indexer_solr_localhost.properties

Indexer-Webapplikation

Der Indexer kann alternativ auch als Webapplikation in einem Service-Tomcat betrieben werden.

Erstellen einer Build-Datei

Die folgenden im Konfigurationsverzeichnis erstellten Build-Dateien (siehe 4.1.10 Aktivierung einer Version) sind anzupassen.

Redaktions-Umgebung

build_cm_tomcat_indexer_solr.properties
build_cm_webapp_indexer_solr.properties

Live-Umgebung

build_ml_tomcat_indexer_solr.properties
build_ml_webapp_indexer_solr.properties

Tomcat (Solr)

Erstellen einer Build-Datei

Die im Konfigurationsverzeichnis erstellte Build-Datei (siehe Aktivierung einer Version) ist anzupassen (s.a. Solr-Tomcatkonfiguration):

$GSB_ADMIN_HOME/config/build_tomcat_solr_localhost.properties

Installation der Komponenten

Zuerst werden die auf dem System zu installierenden Komponenten aktiviert, z. B. alle Komponenten, die in den Konfigurationsdateien beschrieben sind:

<syntaxhighlight lang="xml" enclose="div">gsbinstall activateComponent $GSB_ADMIN_HOME/config/build_*.properties</syntaxhighlight>

Bei diesem Aufruf ist darauf zu achten, dass die Konfigurationsdateien mit absolutem Pfad angegeben sind. Sollten bei diesem Kommando Schwierigkeiten auftreten, wird empfohlen, die dabei erzeugte Datei $GSB_ADMIN_HOME/config/components.properties zu löschen und die gewünschten Komponenten mit dem obigen Kommando neu zu registrieren.

Dann werden die Namen aller Mandanten in die Liste der aktiven Mandanten der GSB-Konfiguration eingetragen. Diese Liste ist die Property active_customers in der zentralen Konfigurationsdatei

$GSB_ADMIN_HOME/config/host_specific.properties

Anschließend werden alle aktivierten Komponenten installiert:

<syntaxhighlight lang="xml" enclose="div">gsbinstall rebuildSystem</syntaxhighlight>

Der Installationsvorgang installiert den GSB-Kern und die Mandanten nach den Vorgaben der Konfigurationsdateien. Wichtige Konfigurationsdaten sind:

aktive Komponenten (auf diesem System)
aktive Mandanten, darin
Version
gewünschte Komponenten
VirtualHosts
Templates
Java-Klassen (derzeit noch keine Schnittstelle)

Der Installationsvorgang durchläuft die Liste der aktiven Komponenten und berücksichtigt bei jeder Komponenteninstallation alle Mandanten, die diese Komponente gewünscht haben.

Anmerkung:

Zu beachten ist, dass der Befehl ein evtl. bereits vorhandenes Installationsverzeichnis /opt/gsb/active dem Inhalt der darin enthaltenen Versionsdatei version.txt entsprechend umbenennen möchte und abbricht, wenn die Datei nicht gefunden wird. Bei wiederholten Installationen desselben Releases, z. B. wegen einer Konfigurationsänderung oder dem Hinzufügen eines neuen Mandanten, wird dem Zielverzeichnisnamen ein Zeitstempel angehängt.

Hostnamen-Auflösung

Vor dem Start müssen den Server-Prozessen alle Namen der Rechner, mit denen die Server-Prozesse kommunizieren, bekannt gemacht werden.

In den Build-Dateien

$GSB_ADMIN_HOME/config/build_apache_localhost.properties

$GSB_ADMIN_HOME/config/build_contentserver_localhost.properties

$GSB_ADMIN_HOME/config/build_importer_localhost.properties

$GSB_ADMIN_HOME/config/build_indexer_lucene_localhost.properties

$GSB_ADMIN_HOME/config/build_indexer_solr_localhost.properties

$GSB_ADMIN_HOME/config/build_masterliveserver_localhost.properties

$GSB_ADMIN_HOME/config/build_slaveliveserver_localhost.properties

$GSB_ADMIN_HOME/config/build_tomcat_masterlive_localhost.properties

$GSB_ADMIN_HOME/config/build_tomcat_preview_localhost.properties

$GSB_ADMIN_HOME/config/build_tomcat_slavelive_localhost.properties

$GSB_ADMIN_HOME/config/build_tomcat_solr_localhost.properties

$GSB_ADMIN_HOME/config/build_webstarteditor_localhost.properties

$GSB_ADMIN_HOME/config/build_workflowserver_localhost.properties

$GSB_ADMIN_HOME/config/optional/build_editor_standardlsg.properties

sind Hostnamen für folgende Server konfiguriert, z. B.:

Server-Komponente	Hostname
Content-Server	content.domain.example
Datenbank	database.domain.example
Preview-Server	preview.domain.example
Workflow-Server	workflow.domain.example
Web-Start-Editor	editor.domain.example
Mail-Server	mail.domain.example
Master-Live-Server	master.domain.example
Slave-Live-Server	slave.domain.example

Tragen Sie die Hostnamen, die tatsächlich in den Dateien benutzt werden, in den Nameservice (DNS) oder die lokale hosts-Datei ein (siehe Kapitel Hostnamen-Auflösung):

<syntaxhighlight lang="xml" enclose="div">192.168.1.2 content.domain.example database.domain.example

workflow.domain.example mail.domain.examplemaster.domain.example slave.domain.example</syntaxhighlight>

Die Hostnamen, die hier eingetragen werden müssen, können am Besten nach der Installation des Apache aus den dort erzeugten Konfigurationsdateien im Konfigurationsverzeichnis /opt/gsb/active/Apache2/conf abgelesen werden.

In den Dateien Customer_mandant_VirtualHosts.conf sind nach der Installation die Aufrufe der Konfigurationen der VirtualHosts der Mandanten abgelegt. Diese Dateien werden per Include-Direktive in die Datei BundOnline.conf und diese in die Datei httpd.conf eingebunden.

Die durch die Mandanten bereitgestellten URLs müssen im DNS eingetragen sein oder in die Datei /etc/hosts eingetragen werden, um eine korrekte Erzeugung der VirtualHosts zu erreichen:

<syntaxhighlight lang="xml" enclose="div">192.168.1.2preview.gsbadmin.domain.example www.gsbadmin.domain.example preview.standardlsg.domain.example www.standardlsg.domain.example</syntaxhighlight>

Die IP-Adresse des Servers 192.168.1.2 ist entsprechend den lokalen Gegebenheiten anzupassen.

Die Lage der hosts-Datei ist abhängig vom Betriebssystem:

UNIX	/etc/hosts
Windows XP	C:\WINDOWS\SYSTEM32\DRIVERS\ETC\HOSTS
Windows 2000	C:\WINNT\SYSTEM32\DRIVERS\ETC\HOSTS

Initialisierung der Komponenten

Einige Komponenten müssen vor ihrer Benutzung initialisiert werden. Bitte führen Sie die Schritte in der hier angegebenen Reihenfolge der Komponenten durch, da manche Komponenten erst nach der Initialisierung anderer Komponenten lauffähig sind.

Content-Server

Die Initialisierung des Content-Servers erfolgt in 3 Schritten:

Start des Servers: Der Server wird erstmalig gestartet (Dies erfordert besondere Aufmerksamkeit).
Content-Import der Mandanten: Der Inhalt der Mandanten wird in die CMS-Datenbank eingefügt.
User- und Gruppen-Import der Mandanten: Die für den Redaktionsbetrieb notwendigen Benutzer und Gruppen der Mandanten werden dem System hinzugefügt.

Anmerkung:

Die Installation des Content-Servers ist der mit Abstand komplexeste Vorgang. Da hierbei das zentrale System des GSB 7.1 installiert wird, ist dieser Schritt mit besonderer Sorgfalt durchzuführen.

Schritt 1: Start des Servers

Starten Sie den Tomcat (Contentmanagement) als User cmadmin über

<syntaxhighlight lang="xml" enclose="div">cd /opt/gsb/active/cms-tomcat; bin/catalina.sh start</syntaxhighlight>

Während des Starts sollten die Log-Dateien des Tomcat auf Fehler geprüft werden:

<syntaxhighlight lang="xml" enclose="div">tail –f logs/catalina.out logs/webapp-capserver.log</syntaxhighlight>

Wenn in der Datei contentserver.log eine Warnmeldung erscheint, die auf einen fehlenden Master-Live-Server hinweist, dann kann diese Meldung ignoriert werden, wenn tatsächlich noch kein Master-Live-Server gestartet wurde.

[Do Dez 22 11:55:32 CET] Error: cap.server.publisher: target null has ior url http://master.domain.example:34441/coremedia/ior, which cannot be dereferenced; will retry

Wenn in der Datei contentserver.log eine Meldung der Form

[Do Dez 22 11:55:32 CET] Info: cap.server.license: enabling service publisher

erscheint, ist der wesentliche Teil des Start-Vorgangs abgeschlossen. Erst nach dieser Meldung sollte mit der Installation vorgefahren werden.

Schritt 2: Content-Import der Mandanten

Um die Mandanten zu aktivieren, ist zunächst der Content dieser Mandanten zu importierten. Dies erfolgt mit Hilfe der folgenden Schritte:

<syntaxhighlight lang="xml" enclose="div">LANG=en_US.ISO8859-15@euro ; export LANG cd /opt/gsb/active/coremedia/contentserver </syntaxhighlight>

Wenn der Content des Mandanten GSBAdmin eingespielt wird, muss der common-Content nicht mehr eingespielt werden, weil dieser bereits im GSBAdmin-Content in einer angepassten Version enthalten ist:

<syntaxhighlight lang="xml" enclose="div">unzip ~/gsb/customers/GSBAdmin_Content/GSBAdmin_content.zip bin/cm serverimport -u admin -p admin -r GSBAdmin_content</syntaxhighlight>

Falls der Mandant standardlsg installiert wird, muss hier der zugehörige Content eingespielt werden:

<syntaxhighlight lang="xml" enclose="div">unzip ~/gsb/customers/standardlsg_Content/standardlsg_content.zip bin/cm serverimport -u admin -p admin -r standardlsg_content</syntaxhighlight>

Prüfen Sie bei jedem dieser Import-Schritte die zugehörige Log-Datei auf Fehler:

<syntaxhighlight lang="xml" enclose="div">tail -f var/logs/contentserver.log tail -f var/logs/serverimport.out</syntaxhighlight>

Anmerkung: Sollte es beim Import zu Fehlern in der Validierung der XML-Dateien kommen, so sollte der Import erneut mit Angabe des Parameters --no-validate-xml erneut durchgeführt werden.

Anschließend ist der Content der Mandanten ins System importiert. Die Importverzeichnisse können nun gelöscht werden:

<syntaxhighlight lang="xml" enclose="div">cd /opt/gsb/active/coremedia/contentserver rm -rf common_content GSBAdmin_content standardlsg_content</syntaxhighlight>

Anmerkungen:

Dieser Schritt sollte vor dem User- und Gruppen-Import und vor dem Hochladen der Workflows durchgeführt werden.

Wenn man den Content in einem anderen Verzeichnis als dem Installationsverzeichnis des Content-Servers auspacken und einspielen will, muss man beim Aufruf des serverimport-Kommandos das Verzeichnis mit absolutem Pfad angeben.

Da der mitgelieferte Content mit der Lokalisierung „LANG=en_US.ISO8859-15@euro“ erzeugt wurde, muss er auch mit der gleichen Lokalisierung importiert werden, sonst kann es zu Interpretationsfehlern in Zeitzonen und damit zu leeren Datumsfeldern kommen.

Schritt 3: User- und Gruppen-Import der Mandanten

Die für die Mandanten eingerichteten Benutzer und Gruppen werden mit folgenden Kommandos importiert. Hierbei wird angenommen, dass als Quellverzeichnis der Installation /home/cmadmin/gsb benutzt wird. Wenn das customers-Verzeichnis an anderer Stelle steht, ist das restoreusers-Kommando entsprechend zu modifizieren:

<syntaxhighlight lang="xml" enclose="div">cd /opt/gsb/active/coremedia/contentserver bin/cm restoreusers –u admin –p admin –f /home/cmadmin/gsb/customers/GSBAdmin_Content/GSBAdmin_user.xml bin/cm restoreusers –u admin –p admin –f /home/cmadmin/gsb/customers/standardlsg_Content/standardlsg_user.xml</syntaxhighlight>

Anschließend sind alle Benutzer und Gruppen für die Mandanten importiert.

Initial bekommen die Benutzer ihren eigenen Namen als Passwort. Wenn diese Initialpasswörter neu gesetzt werden sollen, ruft man für jeden Benutzernamen das folgende Kommando auf:

<syntaxhighlight lang="xml" enclose="div">cd /opt/gsb/active/coremedia/contentserver bin/cm changepassword –u admin –p admin –n name –w passwort</syntaxhighlight>

Anmerkungen:

Dieser Schritt muss in jedem Fall vor dem Hochladen der Workflows durchgeführt werden.

Wenn man die Benutzer und Gruppen aus einem anderen Verzeichnis als dem Installationsverzeichnis des Content-Servers einspielen will, muss man beim Aufruf des restoreusers-Kommandos den Dateinamen, wie oben angegeben, mit absolutem Pfad angeben.

Workflow-Server

Die Initialisierung des Workflow-Servers erfolgt in 2 Schritten:

Start des Servers: Der Server wird initial gestartet
Initialisierung Mandanten-spezifischer Workflows: Die für den Betrieb der Mandanten notwendigen Workflows werden in das System eingefügt

Schritt 1: Start des Servers

Starten Sie den Tomcat (Workflowserver) als User cmadmin über

<syntaxhighlight lang="xml" enclose="div">cd /opt/gsb/active/wfs-tomcat; bin/catalina.sh start</syntaxhighlight>

Während des Starts sollten die Log-Dateien des Tomcat auf Fehler geprüft werden:

<syntaxhighlight lang="xml" enclose="div">tail –f logs/catalina.out logs/webapp-workflowserver.log</syntaxhighlight>

Schritt 2: Initialisierung Mandanten-spezifischer Workflows

Zur Initialisierung der für die Mandanten benötigten Workflows müssen Sie das folgende Kommando aufrufen:

<syntaxhighlight lang="xml" enclose="div">gsbinstall uploadAllConfiguredWorkflows –Dpropertyfile=$GSB_ADMIN_ HOME/config/build_workflowserver_localhost.properties</syntaxhighlight>

Kontrollieren Sie das fehlerfreie Hochladen der Workflows in der Konsolenausgabe des gsbinstall-Aufrufs.

Nach dem Hochladen müssen die Workflows aktiviert werden, bevor sie im Editor benutzt werden können. Der Aktivierungsvorgang wird im Handbuch

Dokumentation/GSB/Konzepte/GSB7/RedStruktur.pdf

im Kapitel „Test- und Upload-Workflow“ beschrieben. Für diesen Vorgang wird ein installierter lokaler Java- oder WebStart-Editor benötigt. Der Test- und Upload-Workflow kann nur ausgeführt werden, wenn man sich als der Benutzer admin anmeldet und dieser auch Mitglied in den entsprechenden mandant_MANDANT-Gruppen ist.

Lokaler Java-Editor

Die lokale Initialisierung erfolgt in 2 Schritten:

Einstellen des Preview-Browsers

Bei der Installation auf einem Linux-System ist die Position eines lokalen Editors zu hinterlegen.

Proxy-Server (optional)

Für den Betrieb durch eine Firewall kann der Editor über einen Proxy-Server betrieben werden.

Schritt 1: Einstellen des Preview-Browsers

Auf Windows-PCs kann man der voreingestellte Browser durch ein anderes Programm ersetzt werden. Beispiele finden sich in der Datei sample-editor.xml im Verzeichnis

Installationsverzeichnis\Editor_mandant\properties\corem

Weitere Informationen finden Sie in der entsprechenden CoreMedia-Java-Editor-Dokumentation.

Nützliche Beispiele finden Sie in der Admin-Editorkonfiguration:

/opt/gsb/active/coremedia/editor_Admin/properties/corem/editor.xml

Schritt 2: Proxy-Server (optional)

Eventuell ist der Zugriff auf den Content-Server nur über einen Proxy-Server möglich. Die in diesem Fall notwendigen Einstellungen im Java-Editor sind in folgendem Dokument auf dem Installationsmedium beschrieben:

Dokumentation/GSB/Konzepte/GSB_Java_Editor_Konfig.pdf

Aktivieren der Workflows

Für die Benutzung der Workflows müssen diese vorher auf dem Workflow-Server für jeden Mandanten einmal aktiviert werden.

Sollten Sie des noch nicht getan haben, dann können Sie die Aktivierung mit dem gerade installierten Editor nachholen (siehe Kapitel Schritt 2: Initialisierung Mandanten-spezifischer Workflows“).

WebStart-Editor

Der Aufruf des Java-Editors mittels Webstart erfolgt über den Link:

http://editor.domain.example:8001/editor-webstart/webstart/ext/mandant/editor.jnlp

wobei mandant durch den Namen eines Mandanten (z. B. standardlsg) zu ersetzen ist.

Diese URL kann in einem Browser oder als Parameter des Java-WebStart-Kommandos angegeben werden:

<syntaxhighlight lang="xml" enclose="div">javaws "http://editor.domain.example:8001/editor-webstart/webstart/ext/${MANDANT}/editor.jnlp"</syntaxhighlight>

Für die Nutzung des Webstart-Editors muss der Preview-Tomcat gestartet sein. Sollte es zu einem Fehler beim Herunterladen kommen, dass die URL nicht zugegriffen werden konnte, muss ggf. die Proxy-Konfiguration von WebStart so angepasst werden, dass auf content.domain.example korrekt zugegriffen werden kann.

Für den Fall, dass es eine Fehlermeldung beim Aktivieren des Links gibt, dass der MIME-Type falsch ist, ist zu prüfen, ob auf dem Client-Rechner Java-WebStart installiert ist.

Für das Signieren des WebStart-Editors wird ein Zertifikat benötigt. Das mitgelieferte Zertifikat

~/gsb/active/basis/config/GsbSampleKeyStore.jks

ist lediglich ein Beispiel, das in einer Installation durch ein echtes Zertifikat ersetzt werden kann.

Wenn das mitgelieferte Zertifikat benutzt wird, erscheint beim ersten Starten des Editors per WebStart eine Warnung, die das Materna-Test-Zertifikat als nicht vertrauenswürdig klassifiziert und deshalb von einer Benutzung des Editors abzuraten ist. Da das Zertifikat nur für Testzwecke erstellt wurde, kann diese Warnung ignoriert werden. Sobald Sie alle Dateien basis-editor-classes.jar und basis-editor-resources.jar mit einem echten Zertifikat signieren, verschwindet diese Warnung.

Ein weiteres Zertifikat wird bei der Apache-Installation benutzt:

Auch bei den WebStart-Editoren kann man in den Editor-Konfigurationen andere Browser für den Preview definieren (siehe Schritt 1: Einstellen des Preview-Browsers“). Da hier aber eine serverseitige Definition vorgenommen wird, sollte man diese Einstellungen besser beim Mandanten (im Verzeichnis ~/gsb/customers/mandant_basis/config/Editor/mandant/properties/corem unter editor-unresolved.xml und */editor*-unresolved.xml) vornehmen und damit festlegen, welche Client-Betriebssysteme direkt oder indirekt unterstützt werden sollen.

Tomcat (Content-Server)

Start des Servers

Starten Sie den Tomcat (Contentmanagement) als User cmadmin über

<syntaxhighlight lang="xml" enclose="div">cd /opt/gsb/active/cms-tomcat; bin/catalina.sh start</syntaxhighlight>

Während des Starts sollten die Log-Dateien des Tomcat auf Fehler geprüft werden:

<syntaxhighlight lang="xml" enclose="div">tail –f logs/catalina.out logs/webapp-capserver.log</syntaxhighlight>

Apache

Anmerkung:

Start des Servers

Starten Sie den Apache-Server als User root über

<syntaxhighlight lang="xml" enclose="div">/opt/gsb/active/Apache2/bin/apachectl start</syntaxhighlight>

Prüfen Sie beim Start die Log-Dateien auf Fehler:

<syntaxhighlight lang="xml" enclose="div">tail -f /space/gsb/active/Apache2/logs/http*_error_log tail -f /space/gsb/active/Apache2/logs/standardlsg/error*_log</syntaxhighlight>

Zudem kann der Status des Apache-Servers folgendermaßen festgestellt werden:

<syntaxhighlight lang="xml" enclose="div">ps –ef | grep httpd</syntaxhighlight>

Zur Überprüfung der korrekten Funktionsweise des Systems kann die Preview-Site über folgende URLs (je nach installierten Mandanten) angesprochen werden:

http://preview.GSBAdmin.domain.example

http://preview.standardlsg.domain.example

Live-Server (Master und Slave)

Die Initialisierung des Master-Live-Servers erfolgt direkt beim ersten Start:

Anmerkung:

Soll neben dem Master-Live-Server auch noch weitere Slave-Live-Server installiert werden, so ist die Abschnitte 4.4.8 und 4.4.9 für jeden Slave-Live-Server zu wiederholen. Hierbei ist konsequent in den Anleitungen „master“ durch „slave“ zu ersetzen.

Schritt 1: Start des Servers

Starten Sie den Master-Live-Server:

Starten Sie den Tomcat (Master-Live) als User cmadmin über

<syntaxhighlight lang="xml" enclose="div">cd /opt/gsb/active/mls-tomcat; bin/catalina.sh start</syntaxhighlight>

Während des Starts sollten die Log-Dateien des Tomcat auf Fehler geprüft werden:

<syntaxhighlight lang="xml" enclose="div">tail –f logs/catalina.out logs/webapp-capserver.log</syntaxhighlight>

Anmerkung:

Beim Start eines Slave-Live-Servers ist eine Besonderheit zu beachten:

Wenn in der Datei contentserver.log eine Warnmeldung erscheint, die auf einen fehlenden Master-Live-Server hinweist, dann kann für die Installation diese Meldung ignoriert werden, wenn tatsächlich noch kein Master-Live-Server gestartet wurde. Sobald dies nachgeholt wurde, muss man manuell des Slave-Live-Server in den Betriebszustand „online“ versetzten. Dies kann man entweder mit dem Beenden und Neustart des Slave-Live-Servers erledigen:

<syntaxhighlight lang="xml" enclose="div">cd /opt/gsb/active/rls-tomcat; bin/catalina.sh start</syntaxhighlight>

Importer

Beim Importer ist keine weitere Initialisierung nötig.

Import-Dispatcher

Beim Import-Dispatcher ist keine weitere Initialisierung nötig.

Indexer-Client

Start des Clients

Starten Sie den Indexer-Client als User cmadmin mit den folgenden Kommandos:

Lucene Indexer-Client

<syntaxhighlight lang="xml" enclose="div">cd /opt/gsb/active/indexer; bin/indexer.sh start</syntaxhighlight>

Solr Indexer-Client

Vor dem Start des Solr Indexer-Clients muss der Solr-Tomcat erfolgreich gestartet worden sein (s.a. folgendes Kapitel).

Beim ersten Start des Indexers ist eine initalie Indizierung für die entsprechenden Mandanten notwendig. Dies wird dem Indexer über eine Datei mitgeteilt. Diese ist für jeden zu inizierenden Mandanten anzulegen:

<syntaxhighlight lang="xml" enclose="div">touch /space/gsb/active/solr-indexer/var/timestamps/mandant_NEW_INDEX.ni</syntaxhighlight>

Anschließend wird der Indexer mit folgendem Kommando gestartet:

<syntaxhighlight lang="xml" enclose="div">cd /opt/gsb/active/solr-indexer; bin/indexer.sh start</syntaxhighlight>

Während des Starts sollten die Log-Dateien des Clients auf Fehler geprüft werden:

<syntaxhighlight lang="xml" enclose="div">tail –f var/logs/indexer.log </syntaxhighlight>

Tomcat (Solr)

Start des Clients

Starten Sie den Tomcat (Solr) als User cmadmin über

<syntaxhighlight lang="xml" enclose="div">cd /opt/gsb/active/solr-tomcat; bin/catalina.sh start</syntaxhighlight>

Während des Starts sollten die Log-Dateien des Tomcat auf Fehler geprüft werden:

<syntaxhighlight lang="xml" enclose="div">tail –f logs/catalina.out logs/solr-indexer.log</syntaxhighlight>

LDAP-Anbindung

Die Verwaltung der Nutzer- und Gruppenstruktur mit Hilfe eines externen LDAP-Servers ist eine optionale Funktionalität des Government Site Builder, die auf dem Installationsmedium im Dokument

Dokumente/GSB/Konzepte/GSB7/LDAP-Anbindung.doc

beschrieben wird.

Ein Beispiel einer jndi_tests.properties-Datei wird in das Installationsverzeichnis des Content-Servers unter

properties/corem

kopiert, allerdings nicht eingebunden.

Installation eines Clients

Systemeinstellungen

Der Rechner, auf dem der Editor benutzt wird, muss die Hostnamen content.domain.example und workflow.domain.example sowie die weiteren Hostnamen der Standardlösung auflösen können. Dies muss entweder im Nameservice oder lokal in einer HOSTS-Datei angepasst werden (siehe Kapitel "Hostnamen-Auflösung"):

192.168.1.2content.domain.example workflow.domain.example

preview.standardlsg.domain.example www.standardlsg.domain.example

Die IP-Adresse des Servers 192.168.1.2 ist entsprechend den lokalen Gegebenheiten anzupassen.

Die Lage der HOSTS-Datei ist abhängig vom Betriebssystem:

UNIX	/etc/hosts
Windows XP	C:\WINDOWS\SYSTEM32\DRIVERS\ETC\HOSTS
Windows 2000	C:\WINNT\SYSTEM32\DRIVERS\ETC\HOSTS

Diese Einstellungen müssen unabhängig davon, ob ein WebStart-Editor benutzt oder ein lokaler Java-Editor installiert wird, durchgeführt werden.

Außerdem muss ein zur GSB-Version passendes Java-Paket installiert sein. Für den lokalen Editor benötigt man ein Java-Entwicklungssystem (J2SDK), für den WebStart-Editor eine Java-Laufzeitumgebung mit Java-WebStart (J2RE).

WebStart-Editor

Der Aufruf des Java-Editors mittels Webstart erfolgt über den Link:

http://content.domain.example:8001/editor-webstart/webstart/ext/mandant/editor.jnlp

wobei mandant durch den Namen eines Mandanten (z. B. standardlsg) zu ersetzen ist.

Diese URL kann in einem Browser oder als Parameter des Java-WebStart-Kommandos angegeben werden:

<syntaxhighlight lang="xml" enclose="div">javaws "http://content.domain.example:8001/editor-webstart/webstart/ext/mandant/editor.jnlp"</syntaxhighlight>

Sollte es zu einem Fehler beim Herunterladen kommen, dass die URL nicht zugegriffen werden konnte, muss ggf. die Proxy-Konfiguration von WebStart so angepasst werden, dass auf content.domain.example korrekt zugegriffen werden kann.

Für den Fall, dass es eine Fehlermeldung beim Aktivieren des Links gibt, dass der MIME-Type falsch ist, ist zu prüfen, ob auf dem Client-Rechner Java-WebStart installiert ist.

Lokaler Java-Editor

Die lokale Installation erfolgt in 5 Schritten:

Vorbereitung der Installation: Wie bei der Installation auf dem Server wird die gelieferte Software ausgepackt und das Release aktiviert.
Erstellen einer Build-Datei: Mit Hilfe der Beispieldateien erstellen Sie eine Build-Datei für den Editor.
Installation des Editors: Anhand der Build-Datei wird der Editor installiert und konfiguriert.
Einstellen des Preview-Browsers: Bei der Installation auf einem Linux-System ist die Position eines lokalen Editors zu hinterlegen.
Proxy-Server (optional): Für den Betrieb durch eine Firewall kann der Editor über einen Proxy-Server betrieben werden.

Schritt 1: Vorbereitungen

Auspacken der Liefereinheiten

Von dem Installationsmedium müssen die GSB-Dateien

Software/GSB/GSB__.jar

und das Basis-Paket des zu installierenden Mandanten, z. B.:

Software/GSB/standardlsg_basis_.jar

(wobei derzeit neben dem eigentlichen Release Kennzeichen „R“ noch ein Zeitstempel im Format YYYYMMDD_HHMM angebeben wird) in das Home-Verzeichnis des Users cmadmin oder ein geeignetes Unterverzeichnis kopiert werden.

Anschließend kann der Benutzer cmadmin die Liefereinheiten in seinem Home-Verzeichnis auspacken. Hierzu stehen – je nach Plattform – beispielsweise Winzip, Unzip oder Jar zur Verfügung.

Beispielaufruf mit jar:

Vorbereitung des Administrationsverzeichnisses

<syntaxhighlight lang="xml" enclose="div">mv ~/gsb/admin ~</syntaxhighlight>

Dieses Verzeichnis bildet die Grundlage der Konfiguration des GSB.

Bei der Erstinstallation muss nun die Konfigurationsdatei

~/gsb/Rnr_Snr/basis/buildProperties/host_specific.properties

in folgendes Verzeichnis kopiert werden:

~/admin/config

Anpassung der Arbeitsumgebung

Bitte setzen Sie die Umgebungsvariable $GSB_ADMIN_HOME auf das Administrationsverzeichnis und belegen Sie die Umgebungsvariable $ANT_OPTS mit einem erhöhten Speicherwert:

<syntaxhighlight lang="xml" enclose="div">GSB_ADMIN_HOME=~/admin; export GSB_ADMIN_HOME ANT_OPTS="-mx256m"; export ANT_OPTS</syntaxhighlight>

<syntaxhighlight lang="xml" enclose="div">PATH=~/gsb/active/basis/bin:$PATH; export PATH</syntaxhighlight>

Unter Windows belegen Sie die Umgebungsvariablen des Benutzers cmadmin in der Systemsteuerung passend zu Ihren Pfaden, z. B. so:

<syntaxhighlight lang="xml" enclose="div">ANT_OPTS-mx256m GSB_ADMIN_HOMEC:\cmadmin\admin PATHC:\cmadmin\gsb\active\basis\bin;...</syntaxhighlight>

Anmerkung:

Für eine Installation unter Windows gilt für die Umgebungsvariablen das bereits in Abschnitt 2 Gesagte.

CoreMedia-Installationsdatei

Jetzt können Sie die Installation des CoreMedia-Installations-Jar vorbereiten. Auf dem Installationsmedium ist im Verzeichnis

[false ] Software/CoreMedia

eine entsprechende Jar-Datei vorhanden.

Kopieren Sie das CoreMedia-Installations-Jar (cap-7.1.12-9-artifacts.zip) in das Verzeichnis

$GSB_ADMIN_HOME/extern

Anmerkung:

Bitte beachten Sie dabei, dass Sie tatsächlich die auf dem Installationsmedium des GSB ausgelieferten Installationsdatei verwenden.

Aktivierung einer Version

<syntaxhighlight lang="xml" enclose="div">sh ~/gsb/Rnr_Snr/basis/bin/gsbinstall activateRelease</syntaxhighlight>

oder unter Windows

<syntaxhighlight lang="xml" enclose="div">gsb/Rnr_Snr/basis/bin/gsbinstall activateRelease</syntaxhighlight>

Damit wird das Verzeichnis ~/gsb/Rnr_Snr in ~/gsb/active umbenannt. Gleichzeitig werden (unter UNIX) die Skripte in folgendem Verzeichnis mit Ausführungsrechten versehen:

~/gsb/active/basis/bin

Schritt 2: Erstellen einer Build-Datei

Im Konfigurationsverzeichnis ist für jeden Mandanten eine entsprechende Build-Datei

$GSB_ADMIN_HOME/config/build_editor_mandant.properties

nach dem Muster der Datei

~/gsb/active/basis/buildProperties/build_editor_example.properties

anzulegen und anzupassen.

<syntaxhighlight lang="xml" enclose="div">cp ~/gsb/active/basis/buildProperties/build_editor_example.properties $GSB_ADMIN_HOME/config/build_editor_mandant.properties</syntaxhighlight>

bzw. in Windows

<syntaxhighlight lang="xml" enclose="div">copy gsb/active/basis\buildProperties\build_editor_example_windows.properties %GSB_ADMIN_HOME%\build_editor_mandant.properties</syntaxhighlight>

Hier und in allen weiteren Aufrufen ist mandant durch den Namen des jeweiligen Mandanten zu ersetzen.

Falls die Installation auf der gleichen Hardware erfolgt, muss für jeden Mandanten ein eigenes Installationsverzeichnis (Property editor_home) gewählt werden.

Der zu installierende Mandant wird in die Property editor_customers eingetragen:

editor_customers=standardlsg

Anmerkung:

Für eine Installation unter Windows ist zu beachten:

Die "\"-Zeichen in Pfadangaben sind in der Build-Datei durch Voranstellen eines "\"-Zeichens zu schützen. Beispiel:

C:\\GSB\\Editor_Mandant

Die Property bol_home muss auf C:\\ gesetzt werden.

Schritt 3: Installation des Editors

Wechseln Sie ins Basis-Verzeichnis und rufen dort die folgenden Kommandos auf:

<syntaxhighlight lang="xml" enclose="div">cd ~/gsb/active/basis gsbinstall installComponent

–Dpropertyfile=$GSB_ADMIN_HOME/config/build_editor_mandant.properties</syntaxhighlight>

[ ... Zeilen gelöscht ...]

BUILD SUCCESSFUL

Total time: 11 seconds

Mit diesem Aufrufen wird der Java-Editor mit den zugehörigen GSB-Softwarekomponenten installiert.

Schritt 4: Einstellen des Preview-Browsers

Auf Windows-PCs kann der voreingestellte Browser durch ein anderes Programm ersetzt werden. Beispiele finden sich in der Datei sample-editor.xml im Verzeichnis

Installationsverzeichnis\Editor_mandant\properties\corem

Weitere Informationen finden Sie in der entsprechenden CoreMedia-Java-Editor-Dokumentation.

Nützliche Beispiele finden Sie in der Admin-Editorkonfiguration in der Server-Installation:

/opt/gsb/active/coremedia/editor_Admin/properties/corem/editor.xml

Schritt 5: Proxy-Server (optional)

Eventuell ist der Zugriff auf den Content-Server nur über einen Proxy-Server möglich. Die in diesem Fall notwendigen Einstellungen im Java-Editor sind auf der Seite Java-Editor Hints beschrieben.

Optionale Komponenten

Der GSB enthält einige neue Komponenten, die als optionale Komponente innerhalb einer GSB-Infrastruktur installiert und betrieben werden können. Die Installationsanleitungen dieser Komponenten finden sich jeweils in einer komponentenspezfischen Anleitung, die über die folgende Liste zugegriffen werden kann.

Adminportal

Installationsanleitung Adminportal

Event Dispatcher

Installationsanleitung EventDispatcher

Maildistributor

Installationsanleitung MailDistributor

GSBEditor/web

Installationsanleitung GSBEditor/web

GSB 7.0 Standardlösung

Suche

Hauptmenü

Über­blick

Unternavigationspunkte

GSB Edi­tor

Unternavigationspunkte

Ad­min­por­tal

Unternavigationspunkte

Stan­dard­lö­sung

Unternavigationspunkte

In­stal­la­ti­on

Unternavigationspunkte

Kon­zep­te

Unternavigationspunkte

Schu­lungs­kon­zept

Unternavigationspunkte

Version: GSB 7Installation

Einleitung

Installationsablauf

Installationsschema

Verzeichnisse

Konfigurationsdateien

Administrations-Skript gsbinstall

Installationsablauf

Zugangsdaten

Installierte Software

Architektur / Hostnamen / Ports

Hostnamen-Auflösung

Vereinfachte Architektur

Port-Nummern und Verzeichnisse

Datenbank-Konfiguration

Konfiguration der GSB-Mandanten

Konfiguration „GSBAdmin“

Konfiguration „Standardlösung“

Verzeichnisstruktur

Quellverzeichnis

Installationsverzeichnis

Variable Daten

Administration

Patch

Erstinstallation

Vorbereitung der Systemumgebung

Update-Installation

Patch-Installation

De-Installation eines Patches

Administration

Administration von Komponenten

Systembeschreibung

Aktivierung von Komponenten

Deaktivierung von Komponenten

Installation des Systems

Anzeige der aktiven Komponenten

Administration von Mandanten

Aktivierung von Mandanten

Deaktivierung von Mandanten

Anzeige der aktiven Mandanten

Vorbereitungen

Vorhandene Installationen

Vorbereitung der Systemumgebung

Installationsverzeichnisse

Auspacken der Liefereinheiten

Vorbereitung des Administrationsverzeichnisses

Anpassung der Arbeitsumgebung

CoreMedia-Installationsdatei

CoreMedia-Lizenzdateien

JDBC-Datenbanktreiber

Aktivierung einer Version

Zugriffsrechte

Anlegen der Datenbank-User

MySQL

Konfiguration eines Servers

Content-Server

Erstellen einer Build-Datei

Workflow-Server

Erstellen einer Build-Datei

Lokaler Java-Editor

Erstellen einer Build-Datei

WebStart-Editor

Erstellen einer Build-Datei

Überblick

GSB Editor

Adminportal

Standardlösung

Installation

Konzepte

Schulungskonzept