GSB 7.0 Standardlösung

Springe direkt zu:

Zielgruppe BetriebVersion: GSB10.1Betriebliche Aspekte

Starten/Stoppen der Komponenten

Startreihenfolge

Alle Komponenten, die als Beistellung einer GSB 10 Infrastruktur vorausgesetzt weden, müssen vor dem Start des GSB 10 zur Verfügung stehen. D.h. die benötigten Datenbanken und Datenbankinstanzen müssen gestartet und eingerichtet sein. Weiterhin muss die Mailinfrastruktur einen Versand von Mails ermöglichen, damit Newsletter An- bzw. Abmeldungen, der Versand von Kontaktmails, etc. möglich sind.

Die folgenden SW-Komponenten müssen gemäß Installationsanleitung auf den GSB 10 Server abgelegt und infrastrukturspezifisch konfiguriert sein:

  • Java
  • Solr-Server
  • Tomcat-Server
  • Httpd Web-Server
  • Systemd Service-Units für GSB 10 Komponenten
  • Runtime der GSB Service-Instanzen
  • GSB 10 Software
  • Data-, Log- und Temp-Verzeichnisse

Grundsätzlich gibt es natürlich Abhängigkeiten zwischen einzelnen Komponenten, so dass es sich anbietet, eine GSB Komponente erst dann zu starten wenn die benötigten GSB Komponenten erfolgreich gestartet worden sind.

Durch Einhaltung einer definierten Startreihenfolge kann die Startzeit der gesamten GSB Infrastruktur reduziert werden und ggf. die Ausgabe von unnötigen Logausgaben aufgrund der Nichterreichbarkeit von benötigten Komponenten vermieden werden.

  • Adminportal: CAS, EventDispatcher, Repository, Serviceportal, Solr, Userservice, Workflow
  • CAS: Userservice
  • CMIS-Client: Repository
  • CMIS-Server: Repository, Solr, Userservice
  • Editor: CAS, Indexer, Repository, Solr, Userservice, Workflow
  • EventDispatcher: MailDistributor, Repository
  • Httpd: Site, Repository
  • Indexer; Repository, Solr
  • MailDistributor: -
  • Repository: CAS, Userservice
  • Serviceportal: -
  • Site: Repository, Serviceportal, Solr
  • Userservice: -
  • Workflow: Repository

Einrichten der Unit-Files

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

Hinweis:
Die Nutzung von Systemd erfordert entweder Systemadministratorenrechte (root) oder eine entsprechende Sudoers-Konfiguration.

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

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

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

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

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

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

Starten und Stoppen per systemctl

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

Starten und Stoppen von GSB Diensten

Folgende Pfade existieren:

/opt/gsbos/software/<Servicename>
/opt/gsbos/runtime/<Service>

Ein Servicestart mit systemctl ist wie folgt möglich:
sudo systemctl start|stop|status <Servicename>@<Service>.service

Stoppen aller Site-Tomcats

sudo systemctl stop site.target

Beispiele zum Starten und Stoppen von GSB Komponenten

systemctl und dessen Parametrierung bieten vielfältige Möglichkeiten des Startens und Stoppens von GSB-Komponenten auf einem Server. Die folgenden exemplarischen Beispiele skizzieren dies:

  • systemctl start|stop gsbos.target (Start/Stopp aller gsbos-Komponenten)
  • systemctl start|stop site.target (Start/Stopp aller Site ServiceInstanzen)
  • systemctl status site* (Status aller Site ServiceInstanzen)
  • systemctl status *preview* (Status aller Preview-ServiceInstanzen aller ServiceTypen)
Hinweis:

Die meisten Komponenten  können durch Aufruf der URL /actuator/health getestet werden. Die Zugangsdaten für URL's einer Komponente findet man in den Runtime-Properties der jeweiligen Komponente -> https://doku.gsb.bund.de/10.1/Betrieb/GSB_Kern/Runtime/runtime_node.html.

Die vordefinierten, exempalrischen Passwörter sollten aus Sicherheitsgründen nicht-unverändert übernommen werden, sondern geändert werden.

Das Repository (und die meisten anderen Komponente auch) können durch Aufruf der URL /actuator/health getestet werden.
Dies ist in documentation/reference/basis/operations/monitoring.html dokumentiert.

Die Zugangsdaten für URL's einer Komponente findet man i.d.R. in den Runtime-Properties der jeweiligen Komponente.

Loadbalancer Integration

Die folgenden Unterkapitel beschreiben wie eine Loadbalancer Anbindung bzw. Integration einer GSB Infrastruktur erfolgen muss.

Https-Terminierung

Typischerweise wird es in einer Betriebsinfrastruktur einer Hostingplattform einen vorgeschalteten Loadbalancer geben, der das Routing der einkommenden http-Requests vornimmt.

Dabei wird in der Regel der Zugriff per HTTPS auch direkt dort terminiert.

Damit das dahinterliegende Backend Kenntnis davon hat über welches Protokoll der ursprüngliche Request eingetroffen ist, muss diese Information entsprechend weitergegeben werden. Die geschieht über folgende http-Header Information:

HTTP:X-Forwarded-Proto mit dem Wert https

Dieser Header wird dann von den ausliefernden Apache Web bzw. Tomcat-Servern genutzt, um den Site-Instanzen zu signalisieren, dass es sich ursprünglich um einen HTTPS Request gehandelt hat. Detailinformationen zum X-Forwarded-Proto-Header finden sich auf https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Proto.

Handhabung von Sticky Sessions

Für bestimmte Anwendungsfälle, wie beispielweise geschützte Zugriffsbereiche, ist es notwendig, dass ein Benutzer, der sich an der Webseite angemeldet hat, immer mit derselben Site-Instanz kommuniziert. Das heißt alle nach einer Anmeldung angefragten Requests müssen immer an dieselbe Site-Instanz weitergeleitet werden. Dazu müssen alle Komponenten der relevanten und beteiligten Infrastruktur Sticky-Sessions unterstützen. Die Information von welcher Site-Instanz die Requests des aktuellen Benutzers bedient werden findet sich im jvmroute-Parameter der von den ausliefernden Site-Tomcat Instanzen gesetzt wird und von davorliegenden Komponenten (bspw. Loadbalancer) entsprechend genutzt wird. Gesetzt und gespeichert wird dieser in der JSESSIONID (Cookie/ Parameter) des jeweiligen Clients.

Beispiel:

Cookie JSESSIONID Wert 374749A8D2DFE3C98800BC69A3C21387.site1-live

Healtchecks der Site-Instanzen

Die Signalisierung der Site-Instanzen, ob diese für die Auslieferung aktuell genutzt werden können, erfolgt mit Hilfe der bereitgestellten Healthcheck-Requests. Diese liefern den http Response Code „200“, also OK, wenn die angefragte Instanz zur Verfügung steht und alle für die Auslieferung relevante Komponenten erfolgreich eingebunden sind (zum Beispiel die genutzte Repository-Instanz).

Exemplarischer Healthcheck Aufruf:

http://preview.standardlsg.example.com/healthcheck

Kann der Healthcheck nicht erfolgreich durchgeführt werden, wird der Repsonse Code „500“ zurückgeliefert, der eine Einbindung der Instanz in die Auslieferung verhindern soll.

SSL Zertifikate

Für die SSL Terminierung und damit Unterstützung von https-Requests durch den GSB müssen entsprechende SSL Zertifikate in der GSB Auslieferung konfiguriert werden. Hierfür bieten sich verschiedene Ansätze an, die im Folgenden vorgestellt werden.

SSL Terminierung in einer Produktivumgebung

In einer produktiv genutzten Hostinginfrastruktur werden SSL Zertifikate für die dort gehosteten Domains üblicherweise auf zentralen Loadbalancern hinterlegt. Diese sind dann auch für die SSL Terminierung zuständig. Die Loadbalancer werden in der Regel durch Organisationseinheiten betreut, die für das Netzwerk- bzw. die Netzwerkinfrastruktur zuständig sind. In dieser Konstellation sind die zuständigen Organisationseinheiten auch für die Integration der SSL Zertifikate in die zentralen Loadbalancer zuständig.

Nach der SSL Terminierung durch die Loadbalancer werden die Requests dann vom Loadbalancer an die dahinterliegende GSB Infrastruktur per http weitergeleitet. Damit der GSB http von https unterscheiden kann, muss der Loadbalancer den internen (http-)Request um die Information anreichern, welches Protokoll ursprünglich vom Browser angefragt worden ist. Dies wird durch eines der folgenden http-Header Request-Attribute umgesetzt:

  • X-Forwarded-Proto: Dieses Header-Attribut wird bereits im GSB 7 Umfeld genutzt, um das ursprüngliche Protokoll des http(s)-Requests an die GSB Infrastruktur weiterzuleiten. Der GSB 10 unterstützt dieses Header-Attribut ebenfalls. Allgemeine Erläuterungen zu den Forwarded-Headern finden sich bspw. auf https://docs.aws.amazon.com/de_de/elasticloadbalancing/latest/classic/x-forwarded-headers.html
  • Forwarded: Zusätzlich kann auch der Forwarded-Header des RFC 7239 für die Signalisierung des ursprünglichen Protokolls genutzt werden. Details zum RFC finden sich auf https://tools.ietf.org/html/rfc7239

SSL Terminierung in einer Entwicklungs-/Testumgebung

In Entwicklungs- bzw. Testszenarien stehen zentrale Loadbalancer oder sonstige Netzwerkkomponenten für die SSL Terminierung häufig nicht zur Verfügung. In diesem Fall kann der GSB Webserver anstelle der Loadbalancer die SSL Terminierung durchführen. Darüber hinaus sollen in einer solchen Infrastruktur häufig keine (kostenpflichtigen) offiziellen SSL Zertifikate genutzt werden, so dass in dem Fall selbstgenerierte und -signierte Zertifikate eingesetzt werden müssen.

Die Generierung der selbstsignierten Zertifikate kann mit dem im Release enthaltenen Skript infrastructure/runtime/certificates/generateCert.sh durchgeführt werden. Zur Erstellung muss wie folgt vorgegangen werden:

  1. Anpassung der Liste der zu unterstützenden Servernamen in der Datei infrastructure/runtime/certificates/ca-cert.conf.

    • Anpassung der Definitionen in der Sektion [req_distinguished_name] an die Anforderungen der jeweiligen Infrastrutur. Allgemeine Dokumentation hierzu findet sich bspw. auf https://www.phildev.net/ssl/opensslconf.html.
    • Individuelle Anpassung der Liste der externen Servernamen an die jeweilige Infrastruktur. Die Sektion [alt_names] enthält pro Servernamen eine Defintion in der Form DNS.1 = editor.preview.example.com. Die Zahl nach dem Präfix DNS. ist eine fortlaufende und eindeutige Nummer. Der Wert nach dem Gleichheitszeichen entspricht einem Servernamen für den ein entsprechendes SSL Zertifikat generiert werden soll (im Beispiel editor.preview.example.com). Allgemeine Informationen zu AltNames finden sich bspw. auf http://wiki.cacert.org/FAQ/subjectAltName
  2. Löschen der Dateien ca-cert.pem, ca-cert509.pem und keystore.p12 im Verzeichnis infrastructure/runtime/certificates
  3. Aufruf des Skriptes generateCert.sh
  4. Kopie des Ordners infrastructure/runtime/certificates in den Runtime-Ordner /opt/gsbos/runtime

Die exemplarische Runtime im GSB Release bindet den certificates Ordner ein, so dass die wie oben beschriebenen Zertifikate von den relevanten GSB Komponenten gelesen und berücksichtigt werden.

Monitoring und Logging von GSB Applikationen

Apache Webserver

Die Webserver einer GSB Infrastruktur sind alle gleich installiert und konfiguriert, so dass ein Monitoring und das Logging der einzelnen Instanzen immer gleich funktioniert.

Logging

In einer GSB Infrastruktur werden üblicherweise verschiedene Mandanten betrieben. Ein Mandant wird über verschiedenen Domains ausgeliefert, die als Virtual-Host-Definition im Webserver bekannt gegeben werden. Jeder Mandant verfügt über ein mandantenspezifisches Logging und nutzt jeweils dedizierte Logdateien.

Die Webserver Logdateien werden auf dem Server in folgenden Verzeichnissen abgelegt:

<data_dir>/httpd/logs/<customer>/access_log

  • Das Token <data_dir> ist auf einem System jeweils durch das Basisverzeichnis für GSB Bewegungsaten zu ersetzen. Das Standardverzeichnis ist bspw. /space/gsbos/data.
  • Das Token <customer> ist durch einen konkreten Namen eines GSB-Mandanten zu ersetzen. Im Falle der Standardlösung wäre dies bspw. der Name standardlsg.

Wenn auf einem System bspw. zwei Mandanten (CustomerA und CustomerB) installiert sind und das Standardverzeichnis für <data_dir> verwendet werden soll, dann finden sich die Access-Logs der beiden Mandanten in den Verzeichnissen:

  • /space/gsbos/logs/httpd/CustomerA/access_log
  • /space/gsbos/logs/httpd/CustomerB/access_log
Logfile-Format

Das Format der Access-Logs kann individuell angepasst werden, wobei üblicherweise das im GSB etablierte Definition eingesetzt wird. Es handelt sich hier um das "Combined Log Format", welches im gleichnamiggen Kapitel auf https://httpd.apache.org/docs/2.4/logs.html beschrieben wird.

Ein exemplarischer Auszug eines Access-Logs ist damit wie folgt aufgebaut:

  139.2.56.111 - - [05/Jun/2018:11:28:45 +0200] "GET / HTTP/1.1" 302 - "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0"

  10.152.130.139 - - [05/Jun/2018:11:29:11 +0200] "GET /gsbeditor/ HTTP/1.1" 302 261 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0"

  139.2.56.111 - - [05/Jun/2018:11:29:11 +0200] "GET /rest-interface/j_spring_cas_security_check HTTP/1.1" 302 262 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Geck

o/20100101 Firefox/52.0"

Monitoring

Das Monitoring des httpd-Webservers kann am Einfachsten durch Prozessüberwachung der httpd-Prozesse auf dem jeweiligen Server erfolgen. Der folgende Aufruf mit Hilfe des ps-Kommandos verdeutlicht dies exemplarisch.

Exemplarische Ausgabe der Prozessliste (gefiltert nach httpd-Prozessen)

$ ps -ef | grep httpd

gsbos     1808 12064  0 Jan22 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND

gsbos     3981 12064  0 12:43 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND

gsbos     4019 12064  0 12:44 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND

gsbos     4024 12064  0 12:44 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND

gsbos     4643 12064  0 12:54 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND

root     12064     1  0 Jan15 ?        00:00:42 /usr/sbin/httpd -DFOREGROUND

Weiterhin bietet es sich an auf den Servern einen lokalen Abruf der dort gehosteten Webseiten bzw. einiger Seiten an. Der foglende Aufruf skizziert dies exemplarisch für die Domain preview.standardlsg.example.com mittels wget. Wenn der Return-Code des wget Aufrufs 0 ist, dann konnte die betreffende Seite erfolgreich vom Webserver abgerufen werden (http-Head-Reuest).

Exemplarischer Abruf einer Seite per http-Head-Request

wget --spider --tries 1 http://preview.standardlsg.example.com 2>&1

Spring Boot Java-Applikation

Im Folgenden werden die Ansätze und Möglichkeiten für das Logging und Monitoring von GSB Applikationen beschrieben. Für weitere Details wird dann zusätzlich noch auf die Spring-Boot Dokumentation verwiesen, welche als Quelle für vertiefende Fragestellungen genutzt werden kann.

Logging

Die GSB Applikationen nutzen das Logging Framework Logback. Dieses Framework ist das Standard Logging Framework des GSB und ermöglicht eine flexible Logging-Konfiguration. So kann der Umfang der per Logausgabe protokollierten Informationen sehr gut an individuelle Belange angepasst werden, in dem für die einzelnen Java-Klassen oder -Packages individuelle Log-Level festgelegt werden können. Darüber hinaus können bei Bedarf auch verschiedene Log-Dateien geschrieben werden, um z.B. im Rahmen des Log-File Monitorings nur Ausgaben mit dem Log-Leveln ERROR und WARN berücksichtigen zu können.

Einfache Konfiguration

Die exemplarische Konfiguraiton der GSB Applikationen nutzt die in diesem Kapitel beschriebene "eine Konfiguration", um möglichst viele Standarddefinitionen/-konventionen nutzen zu können. Die einfache Logging Konfiguration kann allein über Properties gesteuert werden und sieht 2 Appender vor: Einen ConsoleAppender welcher auf die Konsole/STDOUT loggt und ein FileAppender, welcher in eine Log-Datei schreibt.

Log-Datei

Der Ablageort der Log-Datei kann über die Properties logging.path oder logging.file gesteuert werden.

Hinweis:
Die Werte der Properties logging.path und logging.file können sowohl absolut, als auch relativ zum Arbeitsverzeichnis der Anwendung angegeben werden.

Die Property logging.path wird von den mitgelieferten, exemplarischen SystemD-Servicedefinitionen auf /space/gsbos/logs/<servicename> gesetzt wodurch sich die Log-Datei /space/gsbos/logs/<servicename>/spring.log ergibt.

Die Log-Datei des Repositories im Redaktionssystem findet sich damit bspw. unter /space/gsbos/logs/repository-preview/spring.log

Logfile-Rotation (Roll-Over)

Um Mitternacht erfolgt ein sog. roll-over der Log-Datei bei der eine neue Log-Datei für den neuen Tag begonnen wird. Die "alte" Log-Datei des vorherigen Tages wird dabei umbenannt und komprimiert. Zusätlich dazu erfolgt ein roll-over wenn die Log-Datei eine Größe von 10MB überschreitet. Diese Maximalgröße kann über die Property logging.file.max-size angepasst werden.

Die Anzahl der "alten" Log-Dateien kann mit Hilfe der Property logging.file.max-history gesteuert werden. Der Standardwert für diese Property ist 0 wodurch keine Log-Dateien gelöscht werden und die gesamte Historie erhalten bleibt.

Log-Format (Pattern)

Das Pattern der Log-Meldungen kann über Properties wie folgt konfiguriert werden.

Das Datumsformat der Log-Meldungen kann über logging.pattern.dateformat gesetzt werden. Der Standardwert ist yyyy-MM-dd HH:mm:ss.SSS

Die Angabe des Log-Levels kann über die Property logging.pattern.level eingestellt werden. Der Standartwert ist hierbei %5p.

Falls diese Properties nicht ausreichen kann über logging.pattern.file (und/oder logging.pattern.console), ein komplett eigenes Pattern für die Log-Datei (und/oder die Konsolenausgabe/STDOUT) definiert werden.

Log-Level

Die Log-Level der einzelnen Logger können ebenfalls über Properties gesetzt werden. Das folgende Beispiel setzt die Level des Loggers de.bund.gsb.site auf den Log-Level DEBUG und der Logger-Gruppe web auf WARN.

logging.level.de.bund.gsb.site=debug

logging.level.web=warn

Hinweis:
Weitere Informationen zu den Logging-Funktionen sind in Kapitel 26 der Spring Boot Dokumentation nachlesbar.
Erweiterte Konfiguration

Wenn die im vorherigen Kapitel Konfigurationsmöglichkeiten nicht ausreichen, z.B. weil mehr oder andere Appender genutzt werden sollen, kann auch eine komplett eigene Logging-Konfiguration vorgenommen werden.

Hierfür kann die Property logging.config gesetzt werden, um den Pfad zur Logback XML-Konfiguration anzugeben.

Als Kopiervorlage seien an dieser Stelle noch die Standard-Konfigurationen von Spring Boot erwähnt.

Hinweis:
Weitere Informationen zur erweiterten Logging-Konfiguration sind in Kapitel 26.6 der Spring Boot Dokumentation zu finden.

Logfile-Format

Ein exemplarischer Auszug der Logfile-Ausgabe einer GSB Applikation ist damit wie folgt aufgebaut.

Exemplarischer Auszug Logfile GSB Applikation

2019-01-22 10:31:17.315 DEBUG 12080 --- [http-nio-6521-exec-10] s.w.s.m.m.a.RequestMappingHandlerMapping : Mapped to public org.springframework.http.ResponseEntity<java.util.Map<java.lang.String, java.lang.Object>> org.springframework.boot.autoconfigure.web.servlet.error.BasicErrorController.error(javax.servlet.http.HttpServletRequest)

2019-01-22 10:31:17.316 DEBUG 12080 --- [http-nio-6521-exec-10] o.s.w.s.m.m.a.HttpEntityMethodProcessor  : Using 'application/json', given [application/json, application/x-jackson-smile, application/*+json] and supported [application/json, application/*+json, application/json, application/*+json]

2019-01-22 10:31:17.317 DEBUG 12080 --- [http-nio-6521-exec-10] o.s.w.s.m.m.a.HttpEntityMethodProcessor  : Writing [{timestamp=Tue Jan 22 10:31:17 CET 2019, status=401, error=Unauthorized, message=Unauthorized, path=/users/redakteur%40standardlsg}]

Umfang der Logausgaben

Der Umfang der Logausgaben bzw. nicht erwünschte Logausgaben können durch Anpassung der Logback-Konfiguration gefiltert werden. So kann eine "Bereinigung" der Logausgaben durchgeführt werden, um bspw. ein Monitoring oder eine Überwachung einer Gsb-Komponente zu erleichtern

Eine Einfache Möglichkeit der Filterung von Logausgaben besteht darin den Loglevel einer einzelnen Klasse bzw. eines Java-Packages anzupassen. Durch Änderung eines Loglevels von WARN auf ERROR tauchen bspw. alle Logausgaben die mit dem Level Warning geschrieben werden nicht mehr im Logfile aus.

Durch Änderung des Loglevels des Packages de.bund.gsb.webeditor.server.core auf ERROR gilt der Level für alle enthaltenen Subpackages oder Klassen. D.h. im unten skizzierten Beispiel würden damit auch die Subpackages context und filter nur noch Logmeldungen im Level ERROR ausgegeben.

Eine feingranulare Steuerung kann durch Definition der gewünschten Loglevel auf Klassenebene erzielt werden.

<logger name="de.bund.gsb.webeditor.server.core" level="WARN"/>

<logger name="de.bund.gsb.webeditor.server.core.context" level="WARN"/>

<logger name="de.bund.gsb.webeditor.server.core.filter" level="WARN"/>

Sollen einzelne Meldungen gefiltert werden, dann reichen die oben skizzierten Möglichkeiten nicht aus. Logback bietet mit den sogenannten Filtern eine Möglichkeit der weitergehenden Filterung bzw. Unterdrückung von unerwünschten Logausgaben.

Eine effiziente Möglichkeit einer Filterung auf Basis von regulären Ausdrücken bieten die Standardfilter EvaluatorFilter oder GEventEvaluator.

Der folgende Auszug der Logback Konfiguration des Editors skizziert den Einsatz des EvaluatorFilters. Der Filter verhindert ein Logging von ConnectionLostExceptions.

<filter class="ch.qos.logback.core.filter.EvaluatorFilter">
<evaluator>
<expression>org.springframework.messaging.simp.stomp.ConnectionLostException.class.isInstance(throwable)
</expression>
</evaluator>
<onMatch>DENY</onMatch>
</filter>

Monitoring

Das Monitoring einer Spring Boot basierten GSB Anwendung erfolgt über sogenannte Endpunkte. Ein Endpunkt stellt hierbei Informationen zu einer bestimmten fachlichen Domäne (bspw. Health/-checks, Metriken oder technische Informationen zur Applikation) oder auch für ein bestimmtes Protokoll (bspw. JMX) oder Monitoring-Tool (bspw. Prometheus) bereit.

Der Zugriff auf die einzelnen Endpunkte erfolgt üblicherweise per HTTP, so dass diese leicht in etablierte Monitoring-System integrierbar sind und die bereitgestellten Informatioenn einfach abgerufen werden können.

Konfiguration der Endpunkte

Alle diese Endpunkte können aktiviert bzw. deaktiviert werden und die aktivierten Endpunkte könenn dann entweder über HTTP oder JMX zugreifbar sein.

Die einzelnen Endpunkte können über die Runtime-Property management.endpoint.<endpunkt-id>.enabled aktiviert oder deaktiviert werden.

Hinweis:
In der exemplarischen Konfiguration der GSB Applikationen sind alle Endpunkte außer shutdown aktiviert.

HTTP Zugriff auf die Endpunkte

Welche der aktivierten Endpunkte über HTTP zugreifbar sind, kann über die folgenden Properties konfiguriert werden:

management.endpoints.web.exposure.exclude=

management.endpoints.web.exposure.include=info, health

Wenn der HTTP Zugriff für einen Endpunkt aktiviert wurde, ist dieser unter dem Pfad /actuator/<endpunkt-id> erreichbar.

Hinweise:

Mit der exemplarischen Konfiguration der GSB Applikationen sind über HTTP nur die Enpunkte info und health erreichbar.

Weitere Konfigurationsmöglichkeiten für den HTTP Zugriff werden in Kaptitel 53 der Spring Boot Dokumentation beschrieben. So ist es z.B. möglich die Management-Endpunkte unter einem anderen Port und/oder anderem Pfad verfügbar zu machen.

JMX Zugriff auf die Enpunkte

Welche der aktivierten Endpunkte über JMX zugreifbar sind, kann über die folgenden Properties konfiguriert werden:

management.endpoints.jmx.exposure.exclude=

management.endpoints.jmx.exposure.include=*

Hinweise:
Weitere Konfigurationsmöglichkeiten für den JMX Zugriff werden in Kaptitel 54 der Spring Boot Dokumentation beschrieben. Die komplette Liste aller Endpunkte und deren Konfigurationsmöglichkeitnen kann den Kapiteln 52ff der Spring Boot Dokumentation entnommen werden.
Der health Endpunkt

Über den health Endpunkt (/actuator/health) kann der Status der Anwendung als einfaches UP oder DOWN abgefragt werden. Der Gesamt-Status der Anwedung ergibt sich dabei aus der Aggregation verschiedener Indikatoren, wie z.B dem noch verfügbaren Speicherplatz und der Erreichbarkeit von anderen Systemen/Datenbanken.

Der health Endpunkt ist somit ideal für die Überwachung der Arbeitsfähigkeit/des Health-Status einer GSB Applikation geeignet. Durch zyklische Abfrage des health Endpunktes können Ausfälle oder Probleme einfach ermittelt werden.

Beispiel für den über /actuator/health abgerufenen Status einer Anwendung mit zwei Indikatoren.

{

    "status":"UP",

    "details":{

        "db":{

            "status":"UP",

            "details":{"database":"MySQL","hello":1}

        },

        "diskSpace":{

            "status":"UP",

            "details":{"total":50328035328,"free":13400100864,"threshold":10485760}

        }

    }

}

Der Endpunkt liefert als Ergebnis den Status als JSON-Objekt zurück. Im skizzierten Beispiel ist der Health-Status der Applikation UP. Der Gesamtstatus ergibt sich aus den beiden definierten Checks db und diskSpace, die ebenfalls UP sind. Würde einer der Checks den Status DOWN liefern (bspw. weil die Datenbank nicht erreichbar ist), dann wäre der Gesamtstatus der Applikation ebenfalls DOWN.

Einbindung entfernter Systeme

In den Health-Status einer Applikation können auch die Health-Status anderer Applikationen mit health-Endpunkt integriert werden. So kann die Site beispielsweise die Health-Status des Repositorys und des Maildistributors in ihrem eigenen Health-Status beachten.

Exemplarische Konfiguration der Health-Endpunkte entfernter Systeme.

gsb.remote-health.endpoints.systemA.url=http://system-a.example.com:1234 (1)

gsb.remote-health.endpoints.systemA.context-path=/foo (2)

gsb.remote-health.endpoints.systemA.base-path=/my-actuator (3)

gsb.remote-health.endpoints.systemB.url=http://system-b.example.com:2345 (1)

1Die URL der entfernten Applikation. Für die Standard-Verbindungen ist diese Property bereits vorbelegt. In der site ist bspw. gsb.remote-health.endpoints.repository.url=${site.repository.url} definiert. Diese Property muss aber ggf. überschrieben werden, wenn die HTTP-Endpunkte der entfernten Anwendung mit management.server.port auf eine andere URL verlegt wurde.
2Der Kontextpfad der entfernten Applikation. Der Standardwert ist leer. Diese Property muss nur gesetzt werden, wenn in der entfernten Applikation die Properties server.servlet.context-path oder management.server.servlet.context-path gesetzt wurden.
3Der Basispfad für die HTTP-Endpunkte der entfernten Anwendung. Der Standardwert ist /actuator. Diese Property muss nur gesetzt werden, wenn in der entfernten Anwendung die Property management.endpoints.web.base-path gesetzt wurde.
Der metrics Endpunkt

Der metrics Endpunkt stellt Micrometer basierte Metriken für diverse Monitoring-Systeme bereit. Durch Abruf dieser Werte können einerseits allgemeine Informationen zur JVA/Applikation (Speicherverbrauch, etc.) als auch applikationsspezifische/interne Werte zugreifbar gemacht werden.

Beispiel für die über /actuator/metrics/http.server.requests abgerufene Metrik http.server.requests

{

    "name":"http.server.requests",

    "description":null,

    "baseUnit":"seconds",

    "measurements":[

        {"statistic":"COUNT","value":160.0},

        {"statistic":"TOTAL_TIME","value":7.371277971},

        {"statistic":"MAX","value":0.057932199}

    ],

    "availableTags":[

        {"tag":"exception","values":["None"]},

        {"tag":"method","values":["GET"]},

        {"tag":"uri","values":["/roles","/users/{userId}/roles","/actuator/metrics/{requiredMetricName}","/actuator/loggers","/actuator/metrics","root"]},

        {"tag":"outcome","values":["CLIENT_ERROR","SUCCESS"]},

        {"tag":"status","values":["401","200"]}

    ]

}

Hinweise:
Mehr Informationen dazu in Kapitel 56 der Spring Boot Dokumentation.
Der prometheus Endpunkt

Der prometheus Endpunkt stellt die o.g. Micrometer basierten Metriken in einem für Prometheus optimierten Format zur Verfügung. Dieser Endpunkt wird eingesetzt, wenn Prometheus als Monitoring-Tool in Einsatz ist.

Hinweis:
Mehr Informationen dazu in Kapitel 56.2.13 der Spring Boot Dokumentation.
Der jolokia Endpunkt

Über den jolokia Endpunkt kann über HTTP unter /actuator/jolokia auf beliebige JMX Beans zugegriffen werden. Jolokia stellt eine JMX zu HTTP-Bridge zur Verfügung. D.h. die Daten der metrics und jolokia Endpunkte sind im Wesentlichen identisch. Wenn eiene bestehende Monitoring-Lösung auf Basis von Jolokia arbeitet, dann ist an dieser Stelle ggf. die Verwendung des jolokia Endpunktes einfacher, da die Daten dann im bekannten Jolokia Format bereitgestellt werden.

Hinweis:
Mehr Informationen dazu in Kapitel 54.3 der Spring Boot Dokumentation.
Der loggers Endpunkt

Über den loggers Endpunkt können die konfigurierten Log-Level eingesehen und geändert werden. Dieser Endpunkt ermöglicht so einer seits die Ausgabe der aktullen Logging-Konfiguration (s.a. Beispiel) und andererseits auch die On-The-Fly Anpassung der Loglevel, ohne diese auf dem jeweiligen System in der Logback Konfigurationsdatei der Applikation eintragen zu müssen. Über den Endpunkt stehen alle Konfigurationsmöglichkeiten für Log-Level zur Verfügung, wie dem folgenden Beispiel entnommen werden kann.

Beispiel für den über /actuator/loggers abgerufenen Logging-Status einer Anwendung.

{

    "levels":["OFF","ERROR","WARN","INFO","DEBUG","TRACE"],

    "loggers":{

        "ROOT":{

            "configuredLevel":"INFO",

            "effectiveLevel":"INFO"

        },

        "de":{

            "configuredLevel":null,

            "effectiveLevel":"INFO"

        },

        "de.bund":{

            "configuredLevel":null,

            "effectiveLevel":"INFO"

        },

        "de.bund.gsb":{

            "configuredLevel":null,

            "effectiveLevel":"INFO"

        }

    }

}


Mehr Informationen dazu in Kapitel 55 der Spring Boot Dokumentation.

Der logfile Endpunkt

Der logfile Endpunkt ermöglicht den Abruf der Logdatei einer GSB Applikation und kann so bei Bedarf für spezielle UseCases/Analysen genutzt werden. Ein automatisiertes Monitoring auf Basis der Logfiles sollte direkt auf dem System durch Lesen und Auswerten der Logfiles erfolgen. Der logfile Endpunkt bietet die Möglichkeit einer On-The-Fly Analyse der Logmeldungen.

Beispiel eines über /actuator/logfile abgerufenen Logfile-Auszuges

2019-01-22 10:31:17.315 DEBUG 12080 --- [http-nio-6521-exec-10] s.w.s.m.m.a.RequestMappingHandlerMapping : Mapped to public org.springframework.http.ResponseEntity<java.util.Map<java.lang.String, java.lang.Object>> org.springframework.boot.autoconfigure.web.servlet.error.BasicErrorController.error(javax.servlet.http.HttpServletRequest)

2019-01-22 10:31:17.316 DEBUG 12080 --- [http-nio-6521-exec-10] o.s.w.s.m.m.a.HttpEntityMethodProcessor  : Using 'application/json', given [application/json, application/x-jackson-smile, application/*+json] and supported [application/json, application/*+json, application/json, application/*+json]

2019-01-22 10:31:17.317 DEBUG 12080 --- [http-nio-6521-exec-10] o.s.w.s.m.m.a.HttpEntityMethodProcessor  : Writing [{timestamp=Tue Jan 22 10:31:17 CET 2019, status=401, error=Unauthorized, message=Unauthorized, path=/users/redakteur%40standardlsg}]

2019-01-22 10:31:17.318 DEBUG 12080 --- [http-nio-6521-exec-10] o.s.web.servlet.DispatcherServlet        : Exiting from "ERROR" dispatch, status 401

2019-01-22 10:31:17.675 DEBUG 12080 --- [http-nio-6521-exec-4] o.s.web.servlet.DispatcherServlet        : GET "/users/redakteur%40standardlsg", parameters={}

2019-01-22 10:31:17.676 DEBUG 12080 --- [http-nio-6521-exec-4] s.w.s.m.m.a.RequestMappingHandlerMapping : Mapped to public org.springframework.http.ResponseEntity<de.bund.gsb.userservice.model.UserDTO> de.bund.gsb.userservice.impl.rest.UserController.getUser(java.lang.String)

2019-01-22 10:31:17.680 DEBUG 12080 --- [http-nio-6521-exec-4] o.s.w.s.m.m.a.HttpEntityMethodProcessor  : Using 'application/json', given [application/json, application/x-jackson-smile, application/*+json] and supported [application/json, application/*+json, application/json, application/*+json]

2019-01-22 10:31:17.681 DEBUG 12080 --- [http-nio-6521-exec-4] o.s.w.s.m.m.a.HttpEntityMethodProcessor  : Nothing to write: null body

2019-01-22 10:31:17.681 DEBUG 12080 --- [http-nio-6521-exec-4] o.s.web.servlet.DispatcherServlet        : Completed 404 NOT_FOUND

2019-01-22 10:31:17.686 DEBUG 12080 --- [http-nio-6521-exec-3] o.s.web.servlet.DispatcherServlet        : GET "/roles/redakteur%40standardlsg", parameters={}

2019-01-22 10:31:17.687 DEBUG 12080 --- [http-nio-6521-exec-3] s.w.s.m.m.a.RequestMappingHandlerMapping : Mapped to public org.springframework.http.ResponseEntity<de.bund.gsb.userservice.model.RoleDTO> de.bund.gsb.userservice.impl.rest.RoleController.getByNameAndCustomer(java.lang.String,java.lang.String)

Über den logfile Endpunkt kann der Inhalt der Log-Datei abgerufen werden. Beim Abruf über HTTP kann der Range Header genutzt werden um nur einen Ausschnitt abzurufen.

Hinweis:
Dies funktioniert nur, wenn die Properties logging.file oder logging.path genutzt wurden, um die Log-Datei zu definieren. Siehe dazu auch Einfache Konfiguration.

Tomcat Applikationen

Neben den im vorheringen Kapitel skizzierten Spring Boot basierten GSB Appplikationen werden einige Applikationen als klassische Webapplikation in einem Tomcat-Server betrieben. Art und Umfang der Logging- und Monitoring-Möglichkeiten entsprechen den im CoreMedia basierten GSB etablierten Möglichkeiten, die im Folgenden nochmals zusammengestellt werden.

Logging

Jede Tomcat-Instanz schreibt ein Tomcat spezifisches Logfile mit allgemeinen und in der Regel applikationsunabhängigen Log-Informationen. Darüber hinaus schreiben die in einem Tomcat betriebenen GSB Applikationen ein applikationsspezifisches Logfile mit Meldungen der jeweiligen Applikation.

Die Logdateien einer Tomcat-Instanz (<servicename>) finden sich sich im Arbeitsverzeichnis /space/gsbos/logs/<servicename> und werden wie folgt abgelegt:

  • out enthält die allgemeingültige Logausgaben der jeweiligen Tomcat-Instanz
  • webapp-<application>.log enthält die applikationsspezifischen Ausgaben der GSB Applikation <application>

Exemplarischer Auszug aus catalina.out

10-Jan-2019 17:40:00.929 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version:        Apache Tomcat/9.0.12

10-Jan-2019 17:40:00.944 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server built:          Sep 4 2018 22:13:41 UTC

10-Jan-2019 17:40:00.944 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server number:         9.0.12.0

10-Jan-2019 17:40:00.944 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Name:               Linux

10-Jan-2019 17:40:00.944 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Version:            3.10.0-514.16.1.el7.x86_64

10-Jan-2019 17:40:00.944 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Architecture:          amd64

Exemplarischer Auszug aus applikationsspezifischem Logfile (Editor)

23.01.2019 08:54:54.377 WARN d.b.g.w.s.j.s.JcrUserDetailsService Could not login user with'standardlsgAdmin@standardlsg'

23.01.2019 08:54:54.388 WARN d.b.g.w.s.j.s.JcrUserDetailsService Could not login user with'standardlsgAdmin@standardlsg'

Monitoring

Eine einfache Überwachung einer Tomcat-Instanz kann am besten durch eine zyklische Überwachung des Prozesses durchgeführt werden. Beim Start einer Tomcat-Instanz schreibt diese ihre Prozess-ID (PID) in die Datei /space/gsbos/logs/<servicename>/catalina.pid.

Die PID des Editor-Tomcats findet sich somit in der Datei /space/gsbos/logs/editor-preview/catalina.pid. Die Existenz des entsprechenden Prozesses bspw. mit dem folgenden Kommando geprüft werden:

ps -p `cat /space/gsbos/logs/editor-preview/catalina.pid`

Wenn der Return-Code des Kommandos 0 ist, dann läuft der Editor-Tomcat, bei einem Wert ungleich null dann läuft der Tomcat nicht.

GSB Shell

Mit Hilfe der GSB Shell kann auf die Schnittstellen des Repository zugegriffen werden. Darüber werden eine Reihe von Funktionen bereitgestelt, die insbesondere zum intitialien Einrichten einer Umgebung, bzw. zum Einspielen eines neuen Mandanten verwendet werden können.

Die GSB Shell steht als Java-Programm zur Verfügung.

Kommandos

Die GSB Shell stellt eine Reihe von Kommandos zum Zugriff auf die Schnittstellen im Repository bereit.

  • bulkpublish: Ermöglicht das Publizieren eines ganzen Mandaten
  • bulkdepublish: Ermöglicht das De-Publizieren eines ganzen Mandaten
  • emptyTrash: Leert den Papierkorb
  • exportcontent: Zum pfadbasierten Export von Content
  • exportcontentpatch: Zum Erstellen von Contentpatchen aus Konfigurations-Linklisten
  • importcontent: Zum Import von Content aus einer Zip-Datei heraus
  • importsecurity: Zum Einspielen von Benutzern, Gruppen und Rechten in den GSB
  • versioncleaner: Zum Bereinigen von alten Versionen

Über das Kommando help können alle verfügbaren Kommandos ausgegeben werden. Mittels help Kommando werden ausführliche Informationen zu dem Kommando und allen verfügbaren Parametern ausgegen.

Hinweise:

Damit ohne Anpassungen an der Laufzeitkonfiguration die Verbindung zum Repository oder dem Indexer konfiguriert werden kann, stehen hierfür eine Reihe von Hilfskommandos bereit. Die Kommando dazu sind repositoryUrl und indexerUrl mit denen die Urls zum Repository und Indexer gesetzt werden können.

Über das properties Kommando können alle konfigurierten Werte eingesehen werden.

Tipp:

Der Aufruf der GSB Shell kann auf verschiedene Arten erfolgen:

Die folgenden Beispiele stützen sich auf die Standardpfade für die Installation des GSB 10 und damit auch der GSB Shell. Weiterhin wird angenommen, dass als Shell die Bash-Shell genutzt wird.

  • Wechsel in den bin-Ordner der Gsbshell und anschließendem Aufruf: cd /opt/gsbos/software/gsbshell/bin; ./gsbshell …​
  • Erweiterung der Path-Variable: export PATH=$PATH:/opt/gsbos/software/gsbshell/bin
  • Setzen eines Shell-Alias: alias gsbshell='/opt/gsbos/software/gsbshell/bin/gsbshell'
  • Setzen eines Links im Bin-Ordner des Benutzers: cd ~/bin;ln -s /opt/gsbos/software/gsbshell/bin/gsbshell

Bei den letzten drei Varianten kann die GSB Shell anschließend einfach mit dem Kommando gsbshell …​ aufgerufen werden.

Bulk Publish

Um einen gesamten Mandanten zu publizieren steht ein Bulk Publish Kommando bereit. Das bulkpublish-Kommando kann mit den optionalen Parametern --checkin und --approve versehen werden.

Über den --checkin Parameter kann bestimmt werden, ob ausgeliehene Dokumente in der Publikationsmenge vor der Publikation zurückgeben werden sollen.

Hinweise:

Ausgeliehene Dokumente in der Publikationsmenge führen zu einem Abbruch der Publikation. Durch Nutzung des --checkin Parameters werden die ausgeliehenen Dokumente zurückgegeben und die Publikation kann erfolgreich durchgeführt werden.

Die Linkkonsistenz wird bei der Publikation sichergestellt und durchgesetzt. Verlinkungen müssen nach Publikation auch aufgelöst werden können, d.h. die verlinkten Dokumente müssen ebenfalls mit publiziert werden oder bereits publiziert sein.

Mittels des --approve Parameters wird sichergestellt das noch nicht freigegebene Dokumente in der aktuellsten Version als freigegeben markiert werden.

Der bulkpublish Aufruf setzt den Parameter --paths voraus. Auf diesen Parameter folgt eine Aufzählung alle Pfade die bei der Publikation berücksichtigt werden sollen.

Der vollständige Aufruf eines bulkpublish Aufrufs kann wie folgt aussehen:

bulkpublish --checkin --approve --paths /standardlsg

Das bulkpublish Kommando kann durch folgende Parameter gesteuert werden:

  • checkin: ausgeliehene Dokumente vor dem Publizieren einchecken
  • approve: nicht freigegebene Dokumente in der aktuellen Version freigeben
  • paths: Pfade im Content die publiziert werden sollen. Mehrere Pfade können als kommaseparierte Liste angegeben werden.

Es gibt außerdem noch eine alternative Variante des Bulk Publish. Mittels bulkpublishfile können die zu publizierenden Dokumente in einer Textdatei gesammelt werden. In der Textdatei steht ein Pfad jeweils in einer dedizierten Zeile:

bulkpublishfile --checkin --approve --file <FILENAME>

Das Token <FILENAME> muss beim Aufruf durch den Pfad der Textdatei ersetzt werden.

Bulk Depublish

Eine Depublikation eines gesamten Mandanten bzw. eines größeren Bereichs eines Mandanten kann mit dem Bulk Depublish Kommando durchgeführt werden.

Die Liste der zu depublizierenden Resourcen (Ordner, Dokumente) wird im Parameter --paths als kommaseparierte Liste angegeben.

Der vollständige Aufruf eines bulkdepublish Aufrufs sieht damit wie folgt aus:

bulkdepublish --paths /standardlsg

Das bulkdepublish Kommando kann durch folgenden Parameter gesteuert werden:

--paths: Pfade zu publizierenden Resourcen (Dokumente, Ordner). Mehrere Pfade können als kommaseparierte Liste angegeben werden. Bei Publikation von Ordnern werden alle Dokumente und Unterordner unterhalb des angegebenen Ordners publiziert.

Contentpatch Export

Das exportcontentpatch Kommando wird zum Export eines Contentpatches verwendet. Als Contentpatch kann ein einzelnes Dokument oder über eine Konfiguration-LinkListe zusammengestellte Menge von Dokumenten erstellt werden. Der Contentpatch wird als Zip-Datei im aktuellen Arbeitsverzeichnis abgelegt. Der Aufruf kann über die ID oder den Pfad des zu exportierenden Dokuments erfolgen und kann z.B. so aussehen:

exportcontentpatch --id UUIDexportcontentpatch --file /standardlsg/_patch/contentpatch

Content Export

Über den Aufruf von exportcontent kann ein gesamter Ordner oder Mandant, wahlweise rekursiv, exportiert werden. Der Export wird als Zip-Datei bereitgestellt die im aktuellen Arbeitsverzeichnis der GSB Shell abgelegt wird. Der Aufruf zum Export des Mandanten standardlsg inkl. aller enthaltenen Ordner und Dokumente sieht z.B. so aus:

exportcontent --recursive --path /standardlsg

Content Import

Ein über den Content(-patch) Export erzeugter Content-Abzug kann über das importcontent Kommando in ein GSB Repository eingespielt werden. Über die entsprechenden Parameter approve und publish ist ein direktes Freigeben oder Publizieren möglich.

importcontent --publish --file /space/content.zip

Security Import

Um für einen neuen Mandanten initial Gruppen, Benutzer und Rechte einzuspielen steht der importsecurity Aufruf zur Verfügung. Die in der XML Security Definition enthalten Gruppen und Benutzer werden in den User Service übertragen. Die enthaltenen Rechte für diese Benutzer und Gruppen werden im GSB Repository eingerichtet.

importsecurity --customer standardlsg --file /space/security.xml

Indexer Steuerung

Zum Stoppen des Indexers wird folgendes Kommando verwendet:

stopIndexer

Zum Starten des Indexers wird folgendes Kommando verwendet:

startIndexer

Die Reindexierung eines Mandanten kann dann über folgendes Kommando angestoßen werden:

reindex customer standardlsg

Version Cleaner

Die GSB Shell bietet ein Kommando um ältere, nicht publizierte Versionen von Dokumenten aus dem GSB Repository zu entfernen. Das Kommado dazu lautet versioncleaner und wird z.B. in folgender Form aufgerufen:

versioncleaner sources /standardlsg

Zur Steuerung des Version Cleaners stehen folgende Parameter zur Verfügung:

  • approved: Auch freigegbene Version berücksichtigen
  • doctypes: Nur Dokumente mit bestimmten Dokumenttypen berücksichtigen
  • limit: Maximale Anzahl an Dokumenten deren Versionen bereinigt werden
  • minAge: Mindestalter in Tagen der zu löschenden Versionen
  • minVersions: Anzahl an Version die erhalten bleiben sollen
  • published: Auch ältere, publizierte Versionen berücksichtigen
  • simulate: Den Durchlauf nur simulieren; keine Version werden gelöscht
  • sources: Dokument- oder Ordner- Id, bzw. Pfad die berücksichtigt werden sollen

Shell Skripte

Sollen mehrere Kommandos hintereinander ausgeführt werden, können diese in einem Shell Skript zusammengefasst werden. Ein Shell Skript ist eine einfache Textdatei, in der die einzelnen Kommandos jeweils in einer eigenen Zeile aufgeführt werden. So eine Skript Datei kann z.B. so aussehen:

importcontent -p /space/content.zipimportcontent -p /space/editor.zipquit

Um ein Shell Skript auszuführen muss das Startskript der GSB Shell ausgeführt werden und der Pfad des Shell Skript nach einem '@' angegeben werden. Wie z.B.:

/opt/gsbos/software/gsbshell/bin/gsbshell @/space/beispielskript

Hierbei ist zu beachten, dass das Verzeichnis aus dem die GSB Shell gestartet wurde auch das Basisverzeichnis für alle im Shell Skript aufgeführten Kommandos ist.

Im Infrastructure Artefakt im Ornder scripts werden Shell-Skripte zur Interaktion mit dem Contentrepository im GSB Release bereitgestellt.

Jedes Kommondo wird als eigenständiges Skript zur Verfügung gestellt.

Die folgenden Kommandos stehen zur Verfügung:

  • exportcontent.sh für den Export redaktioneller Inhalte aus dem Contentrepository
  • importsecurity.sh importiert Benutzer, Gruppen und Rechten in den GSB
  • importcontent.sh ermöglicht den Import redaktioneller Inhalte eines Mandanten in das Contentrepository

Parametrierung

Allg. Parametrierung

Die eigentliche Ausführung der Aktion wird per REST-Call (http) gegen den Contentserver ausgeführt. Jedes Skript muss daher mit den "Verbindungsdaten" des jeweiligen Contentrepositories parametriert werden. Hierzu stehen die folgenden Parameter zur Verfügung, die in allen Skripten gleichermaßen genutzt werden können:

  • -h Host-/Servname des GSB Contentrepositories
  • -p http-Portnummer unter dem das Repository läuft
  • -r Adresse des Contentrepositories in der Form Protokoll://Host:Port. Dieser Parameter kann anstelle der beiden Parameter -h und `-p`genutzt werden.

Globale Definition der Parameter

Als Shortcut für die Parametrierung der allgemeinen Parameter kann die Konfigurationsdatei gsb-local.config genutzt werden, um die Parameter für eine Hostingplattform dort einmalig festzulegen.

Folgende Parameter können in der Konfigurationsdatei definiert werden:

  • RepositoryProtocol Protokoll mit dem der REST-Call gegen das Contentrepository ausgeführt wird
  • RepositoryHost Host-/Servername des Contentrepositories
  • RepositoryPort Portnummer auf dem das Repository angesprochen werden kann
  • RepositoryProxy optionale Proxy-Konfiguration für den Zugriff auf das Repository
Komandospezifische Parametrierung

Die spezifischen Parametrierung der einzelnen Kommandos kann der Usage der einzelnen Skripte entnommen werden. Diese wird ausgegeben, wenn das Skript ohne Parameter aufgerufen wird.

nach oben