Administration Kern-Modul

SuperX-Adminstrationshandbuch Kernmodul

• Daniel Quathamer danielq@memtext.de   • Meikel Bisping mbisping@memtext.de

http://www.superx-projekt.de

Sun, Sun Microsystems, Solaris, Java, JavaServer Web Development Kit, JDBC und JavaServer Pages sind eingetragene Warenzeichen von Oracle , Inc. Windows, WindowsNT, Win32, VBScript und Office 2000 sind eingetragene Warenzeichen von Microsoft Corp. Linux ist eingetragenes Warenzeichen von Linus Torvalds. Informix Dynamic Server, Informix Client SDK und Intersolv JDBC Driver sind eingetragene Warenzeichen der IBM Corp. HIS (HISinOne, SOS, POS, SVA, MBS, IVS, BAU, LSF und COB ) sind Produkte der HIS e.G . Alle weiteren Produktnamen sind Warenzeichen der jeweiligen Hersteller.

Dieses Produkt beinhaltet Software, die von der Apache Software Foundation ( http://www.apache.org/ ) entwickelt wurde.

SuperX wird unter der deutschen Variante der GPL-Lizenz von dem Land Nordrhein-Westfalen, vertreten durch die FernUniversität Hagen, diese wiederum vertreten durch die Geschäftsstelle der Initiative CampusSource bei der FernUniversität Hagen, Feithstraße 142, D-58084 Hagen vertrieben ( www.campussource.de ). Details zu den Lizenzbedingungen finden Sie im Kernmodul-Archiv (/lizenz.txt) oder unter http://www.campussource.de/lizenz/ . Ergänzende Hinweise finden Sie auf der Projekthomepage unter http://www.superx-projekt.de .

Inhaltsverzeichnis

1 Einführung

Das Berichtssystem SuperX ist ein sog. Data Warehouse für Bildungseinrichtungen, d.h. beliebig viele Datenquellen werden unter einer einheitlichen Auswertungsschnittstelle zur Verfügung gestellt. Da jede Hochschule unterschiedliche Datenquellen besitzt und in SuperX übernehmen will, bereiten wir für jede Datenquelle ein Modul vor, z.B. ein COB-Modul oder ein SOS-Modul. Bei Bedarf können Anwender auch eigene Module für proprietäre Datenquellen erzeugen und SuperX so erweitern.

Die Module enthalten die wichtigsten Prozeduren, Tabellen und Abfragen für die jeweilige Datenquelle. Der Startpunkt ist das Kernmodul. Eine Kurzanleitung für die Installation ist vorbereitet .

Falls es bei der Implementation des Kernmoduls zu Problemen kommt, können Sie sich unter www.superx-projekt.de informieren. Oder mailen Sie uns direkt: danielq@memtext.de bzw. mbisping@memtext.de .

1.1 Sicherheitsaspekte

Da SuperX für den Einsatz in großen Netzen konzipiert wurde, sind folgende Schutzmechanismen implementiert:

• • Benutzer- und Paßwortkontrolle  

• • SHA-Verschlüsselung von Passwörtern 

• • Zugriffsprotokollierung  

• • Benutzerspezifische Einschränkung des Angebots an Abfragemasken  

• • Benutzerspezifische Einschränkung der einsehbaren Institutionen in Datenbankanfragen  

• • Getrennte Datenhaltung (operative Systeme - SuperX)  

• • Abschottung der Datenbank gegenüber fremden Zugriffen (z.B. mit ODBC) durch 3-Tier-Architektur. Auch Client-Anwendungen wie das Informix Client SDK werden nicht eingesetzt. 

• • Verschlüsselte Verbindung von Client und Servlet (https), Möglichkeit der Zwischenschaltung eines Apache-Webservers (ggf. in der DMZ). 

• • Bei Einsatz des Applets: Zusätzliche Verschlüsselung der in der Anwendung eingebaute Applet/Servlet-Kommunikation  

Nur das SuperX-Servlet auf dem Webserver und die SuperX-Datenbankadministratoren auf der Serverseite haben einen direkten Zugriff auf die SuperX-Datenbank. Alle anderen Zugriffsmöglichkeiten für Benutzer können ausgeschlossen werden, d.h. kein Zugriff mit anderen SQL-Frontend-Programmen wie ISQL, DBACCESS (Unix) oder ODBC (Windows, Mac).

1.2 Erforderliche Hardware

Im Minimalbetrieb ist das gesamte SuperX-System auf einem Desktop-PC   installierbar, z.B. auf einem Linux PC; dies reicht für den Testbetrieb im Intranet mit wenigen Usern vollkommen aus.

Für den Einsatz im Echtbetrieb unterscheiden wir mindestens drei Komponenten:

Die Server lassen sich auch in gängigen Virtualisierungslösungen einrichten.

Für jede Komponente gibt es unterschiedliche Empfehlungen.

1.2.1 Datenbankserver

Wir empfehlen generell Intel-Architektur mit Linux als Betriebssystem, da dies relativ kostengünstig ist und immer weitere Verbreitung findet. SuperX benötigt Java 1. 8 (OpenJDK). und bash-2.x-Scripte auf dem DB-Server einsetzen, beides läuft sicher unter Linux.

Wir empfehlen die Hochleistungsserver aus den aktuellen Produktpaletten von verschiedenen Herstellern, die Firmen Canonical bzw.   Novell/SuSE zertifizieren auch Hardware für Linux.   Für den produktiven Einsatz empfehlen wir einen Mittelklasse-Server mit dem Betriebssystem Linux. SuperX benötigt an einer größeren Hochschule (>10.000 Studierende, viele SuperX-Module) erfahrungsgemäß 2- 3 0 GB Platz für den DB-Server.   Berücksichtigen Sie bitte auch Backup Storage Space.

Wenn DB- und Applikationsserver getrennt betrieben werden und der Applikationsserver unter Linux läuft, ist auch das Betriebssystem Windows für den DB-Server möglich.

1.2.2 Applikationsserver

Wirt empfehlen auch hier Intel-Architektur und Linux als Betriebssystem für Neuanschaffungen.

Der Applikationsserver benötigt wenig Plattenplatz, aber eine leistungsfähige CPU und viel RAM. Der SuperX-Applikationsserver läßt sich auch ideal mit bereits konfigurierten Webservern auf Apache- oder IIS-Basis   (z.B. Homepages von Hochschulverwaltungen) verbinden.

Wenn das XML-Frontend und JasperReports verstärkt eingesetzt werden soll, empfiehlt sich eine etwas leistungsfähigere Architektur, ggf. sogar der Betrieb von zwei Webservern im software-basierten Lastausgleich ("load balancing" via Tomcat).

Generell gilt natürlich die Devise: So viel CPU-Taktfrequenz und RAM wie Sie sich leisten können.

1.3 Erforderliche Software

Die SuperX-Datenbank läuft auf Windows- und Linux-Rechnern. Der SuperX-Client läuft im Browser . Für den Applikationsserver empfehlen wir in jedem Falle einen UNIX bzw LINUX-Server, da alle serverseitigen Scripte als Shellscripte konfiguriert sind. Ubuntu- und SuSE Linux   versteh en sich gut mit Informix, aber alle aktuellen Linux-Distributionen enthalten bereits Java, Tomcat und Postgres.

Beim Informix-Datenbankserver sollten Sie darauf achten, daß SuperX in einem eigenen Online-System läuft.

Die erforderliche Software für den Betrieb des Kernmoduls:

  Noch ein Hinweis zur Zeichen-Codierung: Ab dem Kernmodul 4.0 ist neben der ISO-Codierung auch UTF-8 möglich. Achten Sie darauf, das jeweils passende SuperX-Paket herunterzuladen (im Dateinamen befindet sich entweder "iso" oder "utf8"). Weitere Hinweise siehe Kapitel zur Zeichencodierung .

1.4 Das Kernmodul

Das SuperX-Kernmodul beinhaltet alle zum Betrieb von SuperX unbedingt notwendigen Tabellen, Prozeduren und Abfragen; die wichtigsten Tabellen werden unten näher beschrieben.

Die folgende Tabelle zeigt die Ordnerstruktur des Kernmoduls auf einen Blick:

Die folgenden Abbildungen zeigen die Ordnerstruktur von jeweils Datenbank-Seite und Webserver-Seite.

 

 

Der Datenbankserver kann auf einem anderen Rechner liegen als der Webserver; es ist aber auch möglich, das gesamte SuperX auf einem Rechner zu installieren. Je nach Hardware- oder Softwarevoraussetzungen kann dies ein WinNT/2000- oder Linux-Rechner sein. Unter Windows können Sie z.B. ein Verzeichnis C:\superx erstellen; unter Linux können Sie einen Nutzer superx mit dem Verzeichnis /home/su perx einrichten. Den von Ihnen gewählten Pfad bezeichnen wir als im Folgenden als $SUPERX_DIR , und alle Verzeichnisse des Kernmoduls ( db , doc , webserver ) werden dort hineinkopiert.

ln --symbolic <<Tatsächlicher Entladepfad>> rohdaten

1.5 Ausbaustufen einer SuperX-Implementierung

SuperX liefert eine datenbankbasierten Website zur Präsentation von Inhalten der Hochschule für die öffentliche Nutzung im Internet sowie für die interne Nutzung im Intranet. Nach einer Datenübernahme aus den operativen Systemen gilt es, eine effiziente Berichterstellung zu ermöglichen und Export- und Importschnittstellen zu bieten. Das System wird in mehreren Aufbaustufen realisiert, wichtig ist daher die Skalierbarkeit des Systems vom Prototypen bis zum Echtbetrieb.

Der Prototyp der Erstinstallation ist auf einem einzelnen System möglich:

 

Das zu realisierende System besteht aus drei Komponenten: der Datenbank, der Webanwendung und des Clients (3-tier-Application). Die folgende Abbildung zeigt eine typi s che Beispielarchitektur:

Die Clients im Intranet greifen direkt oder über die Webanwendung auf die Datenbank zu. Die Clients im Internet greifen über den Browser (http oder für Verschlüsselte Zugänge https) auf die Inhalte zu.

Durch diese Architektur wird verhindert, dass WWW-Clients direkten Zugriff zur Datenbank haben. Bei mittlerer Last ist diese Architektur ausreichend.

Falls die Last ansteigt, ist das System wie folgt skalierbar:

Die SuperX-Datenbank wird angebunden an ein oder mehrere operative Vorsysteme. Gleichzeitig, um die Webanwendung zu entlasten, ist es möglich, die Last auf einen zweiten Webserver auszulagern ("Load balancing").

2 Installation

Die Installationsschritte beziehen sich auf die Neuinstallation und das Upgrade. Für die Neuinstallation gibt es eine Kurzanleitung unter Linux.

2.1 Neuinstallation

Bei der Neuinstallation können Sie einfach alle Komponenten in einen Pfad $SUPERX_DIR kopieren und von dort die unten genannten Installationsschritte durchführen. Beim Update können Sie die Patchdatei in $SUPERX_DIR entpacken; die "alten" Dateien werden ersetzt. Wenn Sie die Datenbank und den WWW-Server auf getrennten Systemen betreiben, dann entpacken Sie am besten die Update-Datei in einem temporären Verzeichnis und kopieren dann die Ordner /db und /webserver auf die entsprechenden Rechner.

SuperX ist zwar ein sehr offenes System, aber gewisse Konventionen werden sich in Zukunft als nützlich erweisen, wenn verschiedene Hochschulen Daten und Scripte austauschen wollen. In jedem Fall empfehlen wir Ihnen immer erst dann manuelle Anpassungen, wenn die Anwendung oder das Script funktioniert – eine äußerst sinnvolle Heuristik für die Arbeit mit derart komplexen Systemen wie SuperX.

2.1.1 Übersicht über Installationsschritte

Das Kernmodul wird in drei Arbeitsschritten installiert:

• • Installation und Einrichtung der Datenbank 

• • Installation eines Webservers mit Servlet-Engine 

• • Installation der Java Runtime auf den Clients (nur bei Einsatz des Applets) 

Die folgende Übersicht zeigt das Vorgehen bei der SuperX-Installation, darauf folgt eine Kurzanleitung für die Installationsmaßnahmen :

2.1.2 Besonderheiten für verschiedene Betriebssysteme

Wir empfehlen den Einsatz von SuperX unter Linux. Für andere Betriebssysteme gelten hier und da Besonderheiten.

2.1.2.1 Ubuntu / Debian

Wenn Sie Ubuntu nutzen, können Sie auch den Tomcat und Postgres von Ubuntu nutzen. Dabei ist aber auf einiges zu achten. Bitte schauen Sie dafür bitte unter den Kapiteln für Übertragung der Webapplikation auf einen vorhandenen Tomcat unter Ubuntu und Postgres unter Ubuntu/Debian nach.

Bisher konnten wir auch noch keine Probleme mit OpenJDK von Ubuntu feststellen.

Bitte prüfen Sie ob die Pakete unzip und recode installiert sind.

2.1.2.2 RedHat / CentOS

Bei RedHat bzw. CentOS muss man einige Pakete anders installieren. Bei Red Hat Enterprise Linux Server release 5.11 z.B. muss man das Paket recode von anderer Stelle installieren. Das Apache-Paket lautet "httpd".

2.1.2.3 Noch nicht getestet e Betriebssysteme

Folgende Betriebssysteme wurden bisher noch nicht als Plattfomen für SuperX getestet:

• • Solaris 

• • MacOS X 

2.1.3 Kurzanleitung : Das Vorgehen -kurz und knapp für Linux-Systeme

2.1.4 Installation und Pflege der SuperX-Datenbank

Die SuperX-Datenbank liegt als exportierte Datei in dieser Distribution vor und kann einfach importiert werden. Zunächst muss aber der Datenbankserver eingerichtet werden. Derzeit laufen die Installationsscripte und auch alle Modulscripte nur unter UNIX /Linux.

2.1.4.1 Einrichten des Datenbankservers unter UNIX / LINUX

Der Datenbankserver läuft unter Informix (mind. Version 7.31) und PostgreSQL (mind. Version 8 . 3 ).

2.1.4.1.1 Stopp: welche Zeichencodierung soll es werden?

Bevor Sie das Kernmodul entpacken, sollten Sie sich vergewissern dass die Zeichencodierung des jew. Pakets mit der installierten übereinstimmt.

Die auf Ihrem System installierte Codierung erfahren Sie mit dem Befehl

echo $LANG

Mögliche Ausgaben sind de_DE@euro (oder die jew. Variante mit ISO) und de_DE.utf8 (je nach UNIX gibt es hier unterschiedliche Schreibweisen, z.B. auch de_DE.UTF-8 ). Wenn Sie sich nicht sicher sind, welche Codierung überhaupt installiert ist, können Sie mit

locale -a | grep de

eine Liste der deutschsprachigen Locales anzeigen.

SuperX unterstützte bis Version 3.5 nur die Locale de_DE@euro. Ab Version 4.0 ist auch UTF-8 möglich. Es ist auch ein Mischbetrieb möglich: Der Datenbankserver läuft mit ISO-Codierung, und der Tomcat mit UTF-8-Codierung. Achten Sie nur darauf, dass Sie immer das Paket mit der jeweils richtigen Codierung laden.

Mit dem SuperX-Kernmodul werden Scripte ausgeliefert, mit denen die Codierung von Dateien flexibel geändert werden kann.

Wenn die Fehlermeldung:"psql: FATAL:   conversion between LATIN9 and LATIN1 is not supported" auftritt, unterscheidet sich die in der Shell eingetragene locale mit der in der Datenbank eingetragenen locale. Das Problem lässt sich Lösen mit setzen der Variable LANG auf "de_DE.8859-1". Wenn die Locale nicht verfügbar ist, muss man sie nachinstallieren (s.u.).

2.1.4.1.1.1 Konfiguration der Zeichencodierung unter Suse Linux

Da SuSE Linux "deutsche" Wurzeln hat, die die benötigten Locales d e_DE@euro und de_DE.utf8 in der Standardinstallation bereits installiert. Sie können die Zeichencodierung in der SQL_ENV eintragen und in der $HOME/.bashrc laden.

Hinweis für OpenSuse und Postgres: Die psql- und Java-Shell in OpenSuse 11.4 wertet nicht nur die Variable LANG aus, sondern auch "LC_ALL". Die Ursache dafür haben wir noch nicht gefunden. Im Zweifelsfall setzen Sie LC_ALL auf den gleichen Werte wie LANG.

2.1.4.1.1.2 Konfiguration der Zeichencodierung unter Ubuntu Linux

Mit locale -a | grep de sehen Sie alle deutschen installierten Locales. Wenn die ISO-Codierung fehlt, müssen Sie sie   wie folgt nachinstallieren:

apt-get install language-pack-de-base language-pack-de locales

Danach prüfen Sie in der Datei /usr/share/i18n/SUPPORTED , ob die Locales auswählbar sind:

vi /usr/share/i18n/SUPPORTED

Hier sind nun alle möglichen Sprachen sichtbar. Wir benötigen die locale de_DE@euro ISO-8859-15

Dann muss man sie verfügbar machen:

vi /var/lib/locales/supported.d/de

hat z.B. den Inhalt:

de_DE.UTF-8 UTF-8

de_CH.UTF-8 UTF-8

de_BE.UTF-8 UTF-8

de_LI.UTF-8 UTF-8

de_LU.UTF-8 UTF-8

de_AT.UTF-8 UTF-8

de_DE@euro ISO-8859-15

Danach gibt man ein:

dpkg-reconfigure locales

Wenn Sie dann noch einmal locale -a | grep de   eingeben, sollte die Locale de_DE@euro sichtbar sein.

Tipp: wenn Sie unter Debian/Ubuntu eine root-Shell benötigen, müssen Sie eingeben: sudo -i

Die Datei .bashrc wird unter Ubuntu Linux nicht beim Öffnen einer Login Session durchlaufen, Sie können diese aber in der $HOME/.profile laden:

...

if [ -n "$BASH_VERSION" ]; then

    #   .bashrc laden, wenn vorhanden:

    if [ -f "$HOME/.bashrc" ]; then

        . "$HOME/.bashrc"

    fi

fi

...

2.1.4.1.1.3 Zeichencodierung ändern

Für die tägliche Arbeit ist es nützlich, das Unix-Programm recode zu installieren, dies wird von den Konvertierungsscripten genutzt. Bei OpenSuse ist das standardmäßig installiert, bei Ubuntu muss man es nachinstallieren. Bei Red Hat Enterprise Linux Server   5.* muss man zunächst die Paketquelle angeben:

Datei /etc/yum.repos.d/rpmforge.repo   anlegen mit dem Inhalt:

# Name: RPMforge RPM Repository for Red Hat Enterprise 5 - dag

# URL: http://rpmforge.net/

[rpmforge]

name = Red Hat Enterprise $releasever - RPMforge.net - dag

#baseurl = http://apt.sw.be/redhat/el5/en/$basearch/dag

mirrorlist = http://apt.sw.be/redhat/el5/en/mirrors-rpmforge

#mirrorlist = file:///etc/yum.repos.d/mirrors-rpmforge

enabled = 1

protect = 0

#gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmforge-dag

gpgcheck = 1

Danach gibt man ein

yum --nogpgcheck install recode

Danach ist recode verfügbar.

2.1.4.1.2 User superx - Kernmodul entpacken

Legen Sie einen User superx am einfachsten mit dem home-Verzeichnis /home/superx an.

Wenn wir im Folgenden $SUPERX_DIR sprechen, meinen wir /home/superx . Es ist natürlich auch jedes andere Verzeichnis möglich.

1. Es muss auf Betriebssystemebene sichergestellt werden, dass das Dateisystem Textdateien in der passenden Locale anlegt sind. Bei modernen UNIXen wird die Umgebungsvariable $LANG auf "UTF-8" gesetzt. 

   Setzen Sie die richtige Locale z.B. mit LANG=de_DE.utf8 ; export LANG.  

Entpacken Sie die kernmodul-XX.tar.gz imVerzeichnis $SUPERX_DIR.

Machen Sie eine Kopie der Datei Date $SUPERX_DIR/db/bin/SQL_ENV.sam und nennen Sie sie einfach SQL_ENV . In dieser Datei werden viele allgemeine Konfigurationen der Umgebung vorgenommen. Prüfen Sie, ob die in der SQL_ENV angegebene Locale ( LANG=de_DE... ) existiert.

Geben Sie der Datei ggf. Ausführungsrechte mit chmod +x SQL_ENV .  

2.1.4.1.3 Informix

SuperX unter Informix läuft derzeit unter UNIX und LINUX. Für den Datenbankserver unter Windows NT benötigen Sie in jedem Fall einen UNIX / LINUX-Rechner für die Shellscripte in den Modulen. Das Vorgehen ist im Abschnitt Konfiguration beschrieben..

2.1.4.1.3.1 Systemvoraussetzungen

Da die meisten Hochschulen bereits Informix-Datenbanken einsetzen, sind hier keine Hinweise zur Installation nötig. Da SuperX ein beliebtes System für Linux-basierte Systeme ist, hier nur ein paar kurze Hinweise für Informix 9.x   unter Linux

Informix für Linux lässt sich ab Version 7.3 unter Linux installieren (wir haben SuSE Version 7.3-8.1 und RedHat 8/9 getestet). Gemäß Anleitung von IBM/Informix geht man so vor:

1. 1. Als root anmelden 

2. 2. User und Gruppe informix anlegen (achten Sie darauf, dass die Default-Gruppe des Users "informix" nicht die Gruppe "users" ist, sondern "informix"). 

3. 3. Die Umgebungsvariable z.B. auf /home/informix setzen
   export INFORMIXDIR=/home/informix
   setzen 

4. 4. Dann die Informix- sql-CD einlegen und mounten, bzw. das IDS-Archiv in ein beliebiges Verzeichnis   entpacken 

5. 5. ./ids_install starten (Serverpaket wählen, Seriennummer etc eingeben), und zum Abschluß   auch das Script ./RUN_AS_ROOT.server  

2.1.4.1.3.2 Konfiguration

Die Ko n figuration des IDS geschieht im onmonitor über das Menü Mode->Parameters oder direkt in der Textdatei "onconfig", für unser Beispiel onconfig.superx . Die Pfade zu $INFORMIXDIR müssen ggf. angepaßt werden, die Voreinstellung ist oft "/usr/informix" . Wichtig ist außerdem der DBSpace (zu prüfen mit onstat -d ).

Zum Betrieb von SuperX hier nur einige Angaben zur empfohlenen Größe: Für das Kernmodul selbst würden 100 MB ausreichen, wenn Sie aber als erstes das SOS-Modul installieren möchten, sollten Sie nicht unter 400 MB starten (Parameter ROOTSIZE in onconfig.superx s.u.).  

Wir empfehlen, das Logging auszuschalten, da SuperX keine Dialog-Anwendung ist und durch die Prozeduren sehr viel Logging anfallen würde. Selbst bei ausgeschaltetem Logging entstehen noch sehr viele Eintragungen, deshalb sollten Sie als Log Archive Tape Device LTAPEDEV /dev/null angeben.

Für die Rohdaten aus den operativen Systemen gibt es ein eigenes Verzeichnis, z.B. $SUPERX_DIR/db/module/<<modulname>>/rohdaten . Aus Platzgründen, und um sich den ftp-Transfer zu ersparen, bietet es sich unter UNIX an, hier NFS-Laufwerke einzurichten.

Falls Sie noch keine onconfig Datei für SuperX haben, erstellen Sie eine Kopie von /home/informix/etc/onconfig.std und nennen Sie sie onconfig.superx .

  In der onconfig-Datei für SuperX sind die Parameter DBSERVERNAME   (wir empfehlen superx_host ) und DBSERVERALIAS (wir empfehlen superxdb ) wichtig.

Entsprechend dieser zwei Parameter ergänzen Sie die Datei sqlhosts.

$INFORMIX/etc/sqlhosts	Die Datei mit den Hostnamen für Shared Memory-Zugriff (statt miles geben Sie den in /etc/hosts definierten Rechnernamen an) und für TCP-Zugriff.
Beispiel:
Machen Sie eine Ergänzung in /etc/services
/etc/services	Der SuperX-Service mit Portnummer

Unter Informix für Windows NT befindet sich die onconfig unter %INFORMIXDIR%\etc\onconfig , die sqlhosts wird in der Registry unter HKEY_LOCAL_MACHINE oder besser über das Programm setnet32 geändert.

Wichtig ist die Eintragung eines DBSERVERALIAS, über den das Servlet die Verbindung aufbaut. Der Port des Service in /etc/services wird ebenfalls benötigt.

Diese Parameter werden in der Datei db.properties vom SuperX-Servlet benötigt.

Es muss sichergestellt werden, dass einige Umgebungsvariablen beim Start initialisiert werden. Je nach UNIX-Art geschieht das in der .profile oder. .bashrc im Home-Verzeichnis der Benutzer informix und superx. (Im Zweifelsfall ausprobieren)

Damit man die Umgebungsvariabeln nur an einer Stelle zu pflegen braucht, empfiehlt es sich, dem User Informix Leserechte auf die Datei $SUPERX_DIR /db/bin/SQL_ENV zu geben und diese in der .profile bzw. .bashrc der beiden User aufzurufen.

Eintrag: . $SUPERX_DIR/db/bin/SQL_ENV

Stellen Sie sicher, dass die Zeile #SX_CLIENT=pgsql; mit dem Gatterzaun auskommentiert ist und die Zeile SX_CLIENT=dbaccess nicht ;

In dieser Datei werden auch die Pfade und Parameter für das Laden der Daten aus den operativen System festgelegt. Sie wird von den Entladescripten und von den Cronjobs benutzt.

Für Informix ist es generell günstiger, unter Unix / Linux mit einem ANSI-Terminal zu arbeiten. Beachten Sie allerdings, daß bei dieser Einstellung kein xterm verfügbar ist und Sie somit keine graphischen Java –Anwendungen, z.B. den propadmin , auf dem Datenbankserver starten können.

Die Umgebungsvariablen DBTEMP und PSORT_DBTEMP sind eigentlich nicht mehr notwendig; wenn es Probleme beim Sortieren und Auslagern auf temporäre Datenträger gibt, dann sollte man diesen Pfad ebenfalls setzen. Die onconfig.superx liegt unter $INFORMIXDIR/etc und muss unbedingt als Parameter die Zeile

DBSPACETEMP   dbtemp                   # Default temp dbspaces

enhalten, wobei der Name dbtemp im onmonitor frei gewählt werden kann.

Ist die Umgebung korrekt eingerichtet, dann startet man den IDS mit

Wenn bereits ein Informixserver vorhanden war muss in der onconfig der DBSPACE neu formatiert werden. Setzen Sie dazu die Variable

FULL_DISK_INIT=1

und wiederholen Sie den oninit -ivy .

Weitere nützliche Kommandozeilen-Befehle für Informix

Dann kann man die Datenbank als User superx einspielen (s.u.).

Für den Ablauf der UNIX-Scripte zu den Masken (sx_select_mask, sx_insert_mask etc.) und für Cron-Jobs müssen die Parameter in der Datei $SUPERX_DIR/db/bin/SQL_ENV stimmen.

Hinweis für Datenbankserver unter AIX oder anderen Linux / Unix-Derivaten: Beachten Sie, daß die Scripte nur dann lauffähig sind, wenn auf dem Datenbankserver unter /bin/bash die bash Version 2.x oder höher liegt (bzw. gelinkt ist). Die Scripte von SuperX erwarten die bash-Shell im Verzeichnis /bin ; wenn dies nicht der Fall ist, sollte die Datei sh z.B. von /usr/bin nach /bin kopiert oder gelinkt werden. Unter Ubuntu Linux 6.10 beispielweise ist die Standardshell nach /bin/dash gelinkt, dies müssen Sie für SuperX ändern.

2.1.4.1.3.3 Informix unter Ubuntu

Die ersten Arbeitsschritte machen Sie in der root-Shell:

Unter Ubuntu legen Sie zunächst Gruppe und User informix an:

addgroup informix

adduser --ingroup informix informix

Beispiel Informix Innovator-C Edition als user root :

tar -xvf iif.12.10.FC8IE.linux-x86_64.tar

./ids_install

Es startet eine dialogbasierte Installation. In der typischen Installation wird auch ein DB-Server installiert und direkt gestartet. Der Db-Server hat in der Innovator-C Edition 130 MB Plattenplatz. Mit

ROOTSIZE 2097152

geben Sie dem Server in der onconfig die maximalen 2 GB Plattenplatz.

Er nutzt die Ports 9088 (DNS-Name) und 9090 (localhost).

Es wird im Installationsverzeichnis eine Umgebungsdatei ./ol_informix1210.ksh angelegt, die Sie mit

. ./ol_informix1210.ksh

laden können, und dann den Server starten/beenden können. Die angelegte onconfig lautet

onconfig.ol_informix1210

und liegt im Unterverzeichnis etc

2.1.4.1.4 Installation von PostgreSQL

Lehrfilm zur Installation von Postgres

SuperX ist seit Version 2.1 mit Postgres 7.2 bis 8.2 lauffähig, die neuen Module im Kernmodul 4.0 laufen auch unter Postgres 8.3 und 8.4. Die Distribution von Postgres für Unix findet sich unter www.post gresql.org . Eine Version für Windows befindet sich im Cygwin-Paket, dass Sie von unserem www.cyg win.com beziehen können.

Verschiedene Linux-Distributionen enthalten zwar bereits Postgres und müssen nicht "von Hand" installiert werden. Dies hat den Vorteil dass die Installation leicht ist und Sicherheitsupdates automatisch eingespielt werden können. Aber Vorsicht: die Distribution legt Postgres in anderen Verzeichnissen ab, als das Standardscritp von Postgres.

Im folgenden wird die Installation vom Quellcode beschrieben.

2.1.4.1.4.1 Neuinstallation (am Beispiel derVersion 7.3.4)

Erzeugen Sie zunächst den User postgres mit dem Homeverzeichnis der Postgres-Installation (z.B. unter Linux mit useradd -g users -d /usr/local/pgsql postgres ).

In der Download-Version von Postgres wird Postgres standardmäßig nach /usr/local/pgsql installiert. Als DBSpace muss man ein oder mehrere Verzeichnisse anlegen und mit initdb vorbereiten. Die SuperX-Datenbank läßt sich dann in einem eigenen DBSpace ablegen.

Zunächst müssen Sie sich als root anmelden. Wir gehen im folgenden davon aus, dass die Quellen von Postgres im Verzeichnis
/usr/src/packages/SOURCES

liegen (das Archiv z.B. von postgresql-7.3.4.tar.gz muss hier entpackt werden).

Dann gehen Sie in das Verzeichnis postgresql-7.3.4 , und führen folgende Befehle aus:

Wenn Sie Postgres 7.2.x installieren, müssen beim ./configure der Parameter --enable-multibyte=LATIN1 gesetzt werden, in Postgres 7.3 oder höher ist dies defaultmäßig bereits eingebaut sind.

Wenn Sie SSL Support benötigen, müssen Sie noch den Parameter –with-openssl hinzufügen. Wenn Sie Postgres in einem anderen Verzeichnis als /usr/local/pgsql installieren wollen, müssen Sie den Parameter –prefix=<<Pfadname>> hinzufügen. Weitere Optionen fürs configure gibt die Zeile

./configure --help

Damit sind die Schritte, die als root auszuführen sind, beendet. Wir wechseln nun zur Kennung postgres mit
su - postgres

Vor der Initalisierung des DBSPACE sollte die Sprachumgebung des Users postgres korrekt sein.   Für die bash wird in den meisten Distributionen die Umgebung generell in der Datei .bashrc bzw. .profile im Homeverzeichnis des Users postgres gesetzt; dort geben Sie den Pfad für das data -Verzeichnis an, und legen die Ausführprogramme von Postgres in den Datenpfad. Hier ein Beispiel für den Betrieb mit UTF-8:

und hier ein Beispiel für ISO:

Wenn die Sprachumgebung stimmt, dann wird der DBSPACE vom User postgres initialisiert.

Durch initdb wird der DBSpace erzeugt.   Wenn die Umgebung stimmt, dann wird Postgres für die deutsche Locale vorbereitet (Sortierung von Zeichen, Datums- und Währungsformate etc).

Dann müssen Sie die ip-Nummer des Rechners mit dem SuperX-Webserver (sowie von allen anderen Clients, die direkt auf die Datenbank zugreifen sollen) in die Datei /usr/local/pgsql/data/pg_hba.conf eintragen. In der Datei $PGDATA/pg_hba.conf stehen die Verbindungsberechtigungen für der Server; hier müssen Sie mindestens dem User superx die Verbindungsrechte geben, z.B. mit folgender Zeile:

Die obige Zeile gibt dem User superx Verbindungsrechte für alle Datenbanken auf dem lokalen Rechner 192.168.0.16 .

Die Netzmaske "/32" schränkt die Regel einen Rechner ein (entspricht 255.255.255.255). Wenn Sie "/24" wählen, öffnen Sie die Netzmaske auf 255.255.255.0, d.h. bei obigem Beispiel alle Rechner im Netz 192.168.0.x.

Bitte beachten Sie, dass die Standardvorgabe nach der Installation von Postgres die ist, dass alle User auf dem aktuellen Rechner mit dem Datenbankserver verbinden dürfen. Dies sollten Sie natürlich ändern.

Wenn Sie statt " trust " den Wert " md5 " eingeben, dann erfolgt eine Passwortabfrage. Dies ist für nächtliche Ladejobs nicht praktikabel. In diesem Falle müssen Sie das Passwort per Client übergeben, entweder mit einer Datei " ~/.pgpass " mit dem Inhalt:

<<Servername>>:<<Port>:<<Datenbank>>:<<Kennung>>:<<Passwort>>

z.B.

dbserver.hochschule.de:5432:superx:superx:anfang12

Alternativ kann man auch die Umgebungsvariable PGPASSWORD mit dem Passwort belegen, dies ist allerding "deprecated" und wird in zukünftigen Versionen von Postgres unterbunden.

Weitere Parameter werden in der Konfigurationsdatei postgresql.conf definiert; wichtig ist die Einstellung, dass Postgres einen TCP-IP-Socket öffnet (Parameter tcpip_socket=true bei Postgres 7.x, listen_addresses=<<IP-Nr.>> bei Postgres 8.0 oder höher) sowie der TCP-IP-Port (port = 5432 ist die Standardvorgabe). Die Anzahl der gleichzeitig offnenen Verbindungen muss kleiner sein als die Anzahl, die Sie für das SuperX-Servlet definieren. Weitere Details zur Einrichtung von Postgres-Runtime-Parametern finden Sie im Admin-Handbuch der Postgres-Distribution. Außerdem sollen Sie beim Betriebssystem SuSE 9.1 oder höher den IPV6-Eintrag für "localhost" (::1)   in /etc/hosts auskommentieren.

Danach wird der Datenbankserver gestartet mit dem Befehl postmaster.
/usr/local/pgsql/bin/postmaster -i -D /usr/local/pgsql/data

Wir empfehlen, die Ausgabe von dem Prozeß in eine Logdatei zu schreiben, z.B. nach /var/log/postgresql.log . Legen Sie diese Datei als User root an, und machen Sie dann den User postgres zum Eigentümer. Ein Beispielscript ist folgendes (im Kernmodul zu finden unter $SUPERX_DIR/db/install ):

Um zu testen, ob die Locale richtig ist, gehen Sie als User postgres in die Shell:

Im Verzeichnis $SUPERX_DIR/db/install befindet sich ein Shellscript check_sortierung_pg.x, das prüft, ob die aktuell in der Umgebung festgelegten Variablen zu korrekter Darstellung von Umlauten und Sortierung unter Postgres der gewünschte Ergebnis bringen. Das Script legt einen temporären DBSPACE an, führt darin einen Testselect aus und löscht den DBSPACE wieder, in der Logdatei check_sortierung.log steht dann das Ergebnis. In dem Script muss die Variable PG_HOME korrekt gesetzt sein, der Rest wird automatisch geprüft.

Dann erzeugen Sie den User superx für Postgres:
createuser superx

Wenn der User ein SuperUser sein soll, geben Sie ein:

createuser --superuser superx

ggfs. ALTER USER superx WITH PASSWORD 'new_password';

Bei Änderungen der pg_hba.conf müssen Sie übrigens Postgres nicht neu starten, Sie können die Datei im laufenden   Betrieb auch mit pg_ctl -D $PGDATA reload neu laden.  

SuperX benötigt die Prozedursprache plpgsql . Wenn Sie als SuperUser die Prozedursprache installieren wollen (in Postgres 7.x und 8.x notwendig, in Postgres 9.x nicht mehr), geben Sie in der Shell ein:

createlang plpgsql

Damit ist Postgres installiert und für die SuperX-Installation konfiguriert. Bei dieser Gelegenheit sollten Sie den Datenbankserver gleich als Dienst beim Systemstart einrichten.

Es kann unter Umständen folgende Fehlermeldung in dem Postgres Logfile auftauchen:

FATAL:   could not create shared memory segment: Das Argument ist ungültig

DETAIL:   Failed system call was shmget(key=5433001, size=39149568, 03600).

HINT:   This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter.   You can either reduce the request size or reconfigure the kernel with larger SHMMAX.   To reduce the request size (currently 39149568 bytes), reduce PostgreSQL's shared_buffers parameter (currently 4096) and/or its max_connections parameter (currently 100).

If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter, in which case raising the request size or reconfiguring SHMMIN is called for.

The PostgreSQL documentation contains more information about shared memory configuration.

Lösung:

Als erstes die zu ändernde Datei im Originalzustand sichern.

cp /etc/sysctl.conf /etc/sysctl.conf-orig

Danach mit vi die Datei /etc/sysctl.conf bearbeiten und folgendes am Ende einfügen:

# For postgres

kernel.shmmax = 104857600

Danach dürfte der Start von Postgres kein Problem mehr sein.

Vergl. http://www.postgresql.org/docs/current/static/kernel-resources.html#SYSVIPC

2.1.4.1.4.2 Postgres-Zusätze installieren: pgcrypto

Neben dem Kernsystem von Postgres bietet es sich an, die vielen Zusatzmodule von Postrges zu nutzen. Die Installation erfolgt aus den Quellen der Kerndistribution. Wir zeigen dies am Beispiel von pgcrypto , einem Paket zur Verschlüsselung, das wir für die Verschlüsselung von Passwörtern gebrauchen:

In Postgres9 ist crypto defaultmäßig bereits mitinstalliert.

Nach dem ./configure (s.o.) der gesamten Postgres-Quellen gehen Sie als root in das Verzeichnis contrib/pgcrypto

Geben Sie ein:
gmake all
gmake install

Es werden Bibliotheken in /usr/local/pgsql/lib erzeugt. Das SQL-Script zur Erzeugung der Crypo-Funktionen liegt in /usr/local/pgsql/share/contrib/pgcrypto.sql . Wenn Sie es in der SuperX-Datenbank installieren wollen, geben Sie dort ein:
psql superx < pgcrypto.sql

Wenn Sie es allen Datenbanken zur Verfügung stellen wollen, laden Sie die Funktionen nach template1:
psql template1 < pgcrypto.sql

2.1.4.1.4.3 Postgres mit SSL Support

Wenn die Postgres Binaries mit SSL Support erzeugt wurden, kann man den SSL Support leicht aktivieren:

• • Erzeugen Sie ein öffentliches und ein privates Zertifikat 

• • in der Datei postgresql.conf den Schalter ssl = on setzen 

• • Das öffentliche Server Zertifikat nach $PGDATA/server.crt kopieren 

• • Das private Zertifikat nach $PGDATA/server.key kopieren. 

Wenn Sie die Zertifikate wie Anleitung erzeugt haben lauten die Befehle z.B.:

cp   /root/demoCA/cacert.pem /usr/local/pgsql/data/server.crt

cp /root/demoCA/private/cakey.pem /usr/local/pgsql/data/server.key

Achten Sie beim Kopieren darauf, dass die Dateirechte nur dem Eigentümer Leserecht geben.

Beim Serverstart wird ggf. ein PEM Passwort abgefragt.

Um den Zugriff zum Server per SSL zu steuern, können Sie in der Datei pg_hba.conf statt der Direktive "host" den Namen "hostssl" nutzen. Damit werden SSL Verbindungen erlaubt. Umgekehrt werden keine non-SSL Verbindungen erlaubt, wenn es keine "host" Direktive gibt.

In psql können Sie den Zugang testen, allerdings müssen Sie die Umgebungsvariable

PGSSLMODE=require

setzen und in der SQL_ENV speichern. Im Erfolgsfall bekommen Sie die Meldung:

psql (XXX)

SSL-Verbindung (Verschlüsselungsmethode: DHE-RSA-AES256-SHA, Bits: 256)

Geben Sie »help« für Hilfe ein.

superx=#

Damit die JDBC Klassen und die Shellscripte mit SSL verbinden, muss man das Zertifikat in der Java Runtime bekannt machen in der Datei webapps/superx/WEB-INF/ db.properties den Parameter:

ssl=true

hinzufügen.Mit DOQUERY "..." kann man den Zugriff testen.

2.1.4.1.4.4 Installation von Postgres unter Windows

Für die Installation von Postgres unter Windows existiert seit Postgres 8.0 eine Möglichkeit, Postgres nativ zu betreiben. Dies empfehlen wir. Aus historischen Gründen haben wir auch den Betrieb von Postgres unter Cygwin dokumentiert.

Für den Betrieb von   SuperX wird aber auf jeden Fall die Shell-Umgebung von Cygwin benötigt. Dies wird in einem dritten Abschnitt erläutert.

2.1.4.1.4.5 Native Windows-Version (nur PowerGres, Postgres 8.0 oder höher)

Seit längerem gibt es eine kostenpflichtige Windows-Version von Postgres unter dem Namen PowerGres. Mit der Version 8.0 läuft auch das "normale" Postgres nativ (d.h. ohne die Unix-Emulation Cygwin) unter Windows, allerdings nur unter Win2000 und WinXP (nur XP Professional, nicht XP Home). Dies bietet erheblich mehr Komfort bei der Installation und Stabilität beim Betrieb. Für SuperX müssen Sie aber in jedem Fall cygwin installieren (s.u.), da die SuperX Scripte nur unter Unix / bash laufen.

Laden Sie die neueste Version von Postgres (Win) herunter.

• • Installieren Sie als Administrator das msi-Paket, z.B. im Verzeichnis C:\Programme\PostgreSQL\8.0-beta1 . Achten Sie darauf, daß alle Pakete installiert werden, auch pgadmin III (ältere pgadmins, odbc- oder jdbc-Treiber funktionieren nicht).
   

• • Der User, der postgres startet, muss ein normaler User sein(z.B. "postgres"), kein Administrator; er muss vorher unter Windows angelegt sein. Er ist auch der Eigentümer der Datenbank template1 (der Superuser). 

• • Postgres sollte als Dienst installiert werden 

• • Beim Anlegen des Datenbank-Cluster legen sie die deutsche Locale an, und als Zeichenformat LATIN1 (nicht unicode). Das Dateisystem muss NTFS sein. 

• • psql & co dürfen für den Betrieb von SuperX beim User nicht in den Windows-PATH gesetzt werden (z.B. C:\Programme\PostgreSQL\8.0-x\bin ), stattdessen nehmen wir die Cygwin-Applikationen (s.u.). 

• • in C:\Programme\PostgreSQL\8.0-x\data\postgresql.conf muss man statt
  früher tcpip_socket = true
  den Parameter listen_adress ='IP-Adresse' 

• • In der Datei pg_hba.conf ist die Standardanmeldung anders als unter Unix auf md5 (nicht trust) gesetzt; wenn Sie nicht ständig das User-Passwort eingeben wollen, sollten Sie den entsprechenden Passus auf "trust" setzen. 

Damit ist Postgres konfiguert, Sie können den Dienst jederzeit in der Computerverwaltung über das Applet "Dienste" neu starten. Normalerweise startet Postgres dann auch beim Systemstart automatisch.

2.1.4.1.4.6 Postgres unter Cygwin

Neben der nativen Postgres-Installation (die wir empfehlen) gibt es auch die Möglichkeit, Postgres unter Cygwin zu betrieben. Insgesamt eignet sich eine unter Cygwin kompilierte Postgres-Installation unter nur für den Testbetrieb, denn bei der Sortierung werden Umlaute falsch eingeordnet und es wird sehr großzügig mit der Prozessorlast umgegangen: Wenn Postgres-Prozesse laufen, dann ist die Performance des Rechners für andere Anwendungen weitgehend gesperrt.

Aber auch bei der nativen Postgres-Installation unter Windows benötigen Sie für Postgres und SuperX unter Windows die UNIX-Shell-Emulation cygwin . Cygwin bietet rudimentäre UNIX-Funktionen wie z.B. die "bash", aber keine UNIX-typischen Dateirechte (z.B. Ausführungsrechte für User, Gruppen oder Andere).Außerdem unterstützt Cygwin (unseres Wissens) keine Locales, und unter Win98 haben wir keine stabile Installation hinbekommen. In den Mailinglisten wurden häufiger Probleme mit Win98 berichtet, unter WinME, Win2000 und Windows XP haben wir Cygwin erfolgreich getestet.

Das folgende Beispiel arbeitet mit Postgres 7.4.x. Postgres ist als Paket im Installer von Cygwin auswählbar.

Für die Installation muss man eine Windows-Kennung benutzen, die Rechte für "Standardbenutzer" reichen aus (es sei denn Cygwin soll als Dienst laufen). Außerdem: Wenn Sie planen, Daten bzw. entladene Datenbank-Exporte zwischen verschiedenen Rechnern hin- und herzuschieben, sollten Sie darauf achten, dass Sie immer die gleiche Kennung benutzen. Sie können z.b. superx nehmen. Die Windows Kennung, unter der man Cygwin installiert, wird nämlich nach Cygwin durchgereicht.

Vorgehen:

1. 1) Die setup-Datei setup.exe der Unix-Emulation Cygwin von http://www.cygwin.com herunterladen und starten
   Dann je nach Belieben   direkt aus dem Internet installieren oder zunächst herunterladen und dann install from local directory (alle Komponenten ausgewählt lassen) anklicken (wir empfehlen letzteres Vorgehen, da das Online-Cygwin-Paket ständig aktualisiert wird). 

2. 2) Als Installationspfad sollten Sie unbedingt einen Pfad wählen, der keine Leerzeichen enthält, z.B. c:\cygwin ).  

3. 3) Bei der Frage, für welchen User Cygwin installiert werden soll, wählen Sie "All users", und beim Standard-Dateiformat wählen Sie Unix. 

4. 4) Bei der Auswahl der Pakete sollten Sie wie folgt vorgehen: Bei den Shells mauss auf jeden Fall die bash ausgewählt sein. Zusätzlich zu den Defaults müssen lediglich Base ->   TextUtils, Database -> Postgres, Admin -> cron, net->openssh und Libs -> libint und libint1 manuell ausgewählt werden. Ein Mailprogramm (mutt, mail) sollte auch installiert werden. Wenn Sie Postgres selbst aus den Quellen installieren wollen, dann wählen Sie natürlich nicht Postgres aus.
   Danach einmal starten, das home -Verzeichnis wird angelegt 

5. 5) Das Cygwin-/bin Verzeichnis muss in der Umgebungsvariable PATH vor den Windows Programm-Verzeichnissen liegen, denn die sort.exe von Cygwin muss benutzt werden, nicht die von Windows. Prüfen Sie außerdem im Verzeichnis /bin, ob die bash.exe existiert - dies muss der Fall sein. 

6. 6) Wenn Sie Postgres nativ (d.h. mit dem Windows-Installer von Postgres ab Version 8.x) installiert haben, dann können Sie jetzt aufhören. Der folgende Teil gilt nur für Postgres unter Cygwin:
   IPC-Daemon starten
   ipc-daemon2 &
   Danach ist Postgres bereits installiert. Wenn Sie Postgres selbst aus den Quellen installieren, dann gehen Sie in das Verzeichnis mit den Quellen von postgresql. Die Installationsschritte entsprechen der Linux-Installation, außer dass Sie beim configure auch --enable-odbc eingeben sollten. Wenn entsprechende Fehlermeldungen erscheinen, müssen Sie noch dafür sorgen, dass (am Beispiel einer Installation von Cygwin in c:\cygwin)   C:\cygwin\usr\local\pgsql\lib\pq.dll im PATH ist. 

7. 7) Nach der Installation Cygwin neu starten; danach muss unter cygwin ein User installiert werden. Geben Sie dazu ein
   mkpasswd -d | grep <<Windows-Username>> >> /etc/passwd
   Unter Win95/98/ME muss man das Passwort in /etc/passwd noch verschlüsseln; ersetzen Sie den Passus "use crypt" durch die Ausgabe von dem Befehl
   crypt <<Ihr Passwort>>  

8. 8) Zur Initialisierung von Postgres folgendes eingeben: 

ipc-daemon2 &

initdb -D /usr/local/pgsql/data

in /usr/local/pgsql/data/postgresql.conf   #tcpip_socket=false  
  # wegnehmen und auf true setzen

Zum Start des Postmaster eine Batchdatei z.B. pgsql_start.x anlegen mit dem Inhalt:

Danach gibt man ein:

chmod +x pgsql_start.x

./pgsql_start.x

Der Postmaster startet dann, und die Logdatei /var/log/postgres.log wird gefüllt.

Den erfolgreichen Start von Postgres kann man prüfen, indem man psql template1 eingibt.

Den postmaster beendet man wie unter UNIX mit
pg_ctl stop –D /usr/local/pgsql/data

Die Installation des Kernmoduls kann danach vorgenommen werden; bei der Umgebungsvariable JAVA_HOME müssen Sie die Windows-Installation von Java verwenden (/cgydrive/<<Windows-Laufwerk>>/<<Pfad zum JDK>>).

Noch ein kleiner Hinweis: Wenn Sie sich von entfernten Rechnern auf dem Cygwin-Server anmelden wollen, müssen Sie den ssh-Daemon installieren (s.u.).

2.1.4.1.4.7 Cygwin für SuperX

Für die Modulscripte von SuperX wird die leistungsfähige Scripting-Umgebung Cygwin benötigt (unter Windows / DOS gibt es nichts Vergleichbares!). Gleichzeitig bleiben dadurch SuperX-Distributionen plattformübergreifend, durch geringe Anpassungen erreichen wir, dass Scripte unter Unix auch unter Cygwin laufen. Allerdings können Sie Cygwin nur in Verbindung mit Postgres nutzen, nicht mit Informix, weil der Informix-Client dbaccess (nach unserem Wissen) nicht unter Cygwin läuft.

Die folgenden Ausfürhungen gelten also nur für Postgres-Anwender: Sie installieren also zunächst wie oben beschrieben Cygwin und Postgres, allerdings ohne das Paket IPC-Daemon zu installieren. Bei nati vem Windows-Betrieb muss der oben bei Cygwin genannte cygipc -Dienst nicht installiert und gestartet werden. Im Folgenden ein paar Anpassungen für die Bash unter Cygwin.

Beachten Sie, dass in der Konfigurationsdatei $SUPERX_DIR/db/bin/SQL_ENV die Umgebungsvariable PGHOST gesetzt sein muss, und dass der Pfad für die Binaries von Postgres angepasst werden muss.

Wenn Sie Cygwin und Postgres-Windows auf einem Rechner nutzen, müssen sie darauf achten, dass beim Öffnen der Cygwin-Shell in der Umgebungsvariable "PATH" auf jedne Fall der Pfad zum Cygwin-psql (normalerweise in /bin ) vor dem Eintrag zum DOS-psql (nomalerweise unter C:\Programme\Postgresql<<Version>>\bin ) liegt, denn die SuperX-ETL-Scripte können mit dem DOS-psql nicht arbeiten.

Noch ein Hinweis für ältere SuperX-Versionen (2.x): Der alte jdbc-Treiber pgjdbc2.jar im Verzeichnis %SUPERX_DIR%\webserver\tomcat\webapps\superx\WEB-INF\lib muss gelöscht und durch den mitgelieferten Treiber pg74.214.jdbc3.jar ersetzt werden. Entsprechende Verweise in der Datei   $SUPERX_DIR/db/bin/SQL_ENV (Umgebungsvariable JDBC_CLASSPATH ) müssen entsprechend geändert werden.

Wenn Sie auch einen SSH-Zugriff aus dem Rechner ermöglichen wollen (dies empfehlen wir u.a. wg. der Dateiübertragung mittels rsync ), müssen Sie den SSH-Dämon unter Cygwin starten. Dazu müssen Sie zunächst eine Cygwin-Shell öffnen, und dort eingeben:

ssh-host-config

Es werden einige Dateien generiert, und außerdem werden ein paar Einstellungen abgefragt. Bei dem Fragen zum Account für den SSH-Daemon antworten Sie mit "no", d.h. der aktuelle Cygwin User startet den Dämon (dieser ist ohnehin kein Admin-User). In diesem Falle lässt sich cygwin aber nicht als Dienst einrichten.

Danach startenSie den SSH-Server mit
/usr/sbin/sshd

Danach können Sie sich mit Putty auf dem Server einloggen.

2.1.4.1.4.8 Postgres unter Ubuntu/Debian (Paketverwaltung)

Postgres kann über die normale Paketverwaltung installiert werden. Weiter unten wird beschrieben wie Sie Postgres unter Debian/Ubuntu selbst kompilieren.

Vorbemerkung: Wenn Sie den DB-Server auf einem anderen Rechner betreiben, reicht es die Postgres-Clientpakete zu installieren:

apt-get install postgresql-client-common

apt-get install postgresql-client

Danach sind Kommandos wie psql verfügbar.

Die folgenden Anleitungen gelten nur für den Dienst als Server:

apt-get update

apt-get install postgresql postgresql-contrib

apt-get install policykit-1
(wird für postgresql start/stop benötigt)

Unter Ubuntu finden Sie die Postgresinstallation z.B. unter /etc/postgresql/9.1/main . Achten Sie bitte darauf, dass Sie in der SQL_ENV den Pfad für $PGPATH und $PGDATA in der SQL_ENV Ihrer Postgresinstallation dementsprechend anpassen. $PGDATA ist in meiner Beispielkonfiguration unter Ubuntu gleich dem Verzeichnis von $PGPATH.

Wenn Sie auch den Tomcat von Ubuntu nutzen wollen, empfehlen wir Ihnen den Tomcatuser auch in der Datenbank für die SuperX DB Verbindung zu nutzen.

Postgres starten und stoppen Sie mit dem Befehl:

Starten: /etc/init.d/postgresql start

Stoppen: /etc/init.d/postgresql stop

Neustarten: /etc/init.d/postgresql restart

Achtung: Ubuntu legt beim ersten Start den DBSPACE in der Default-Codierung UTF-8 an. Wenn Sie ISO benutzen wollen, müssen Sie die Zeichencodierung ändern .

Bei Postgres 9 wurde z.B. festgestellt, dass standardmäßig eine Codierung „SQL-ASCII“ verwendet wurde, die nicht mit UTF-8 kompatibel ist.

Kontrolle mit psql -l

Damit der Server UTF-8 nutzt, muss man einen ggf. vorhandenes Cluster zunächst löschen:

[Als user postgres:]

pg_dropcluster 9.5 main
oder nach Version
pg_dropcluster 10 main
ggfs anzeigen
pg_lsclusters

Danach geben Sie ein:

pg_createcluster -e UTF-8 9.5 main   (bzw. 10)

Damit wird ein DBSPACE angelegt in /var/lib/postgresql/9.5/main

für ISO-8859:

initdb --encoding=LATIN 9 --locale=de_DE@euro -D $PGDATA

Danach müssen Sie den Postgres-Dienst neu starten (s.o.).

2.1.4.1.4.9 Postgres unter Ubuntu/Debian (Selbst kompiliert)

Um Postgres zu kompilieren benötigen Sie die folgenden Pakete (Beispiel Ubuntu 19.04):

apt-get install -y gettext libreadline8 libreadline-dev zlib1g zlib1g-dev

Danach gehen Sie vor wie im Kapitel Neuinstallation (am Beispiel derVersion 7.3.4)   beschrieben.

2.1.4.1.4.10 Test der Installation von Postgres unter Ubuntu/Debian

Danach können Sie testen:

psql template1

Die Ausgabe sollte sein:

psql (9.5.12)

Type "help" for help.

template1=# \l

                                  List of databases

    Name     |   Owner   | Encoding |   Collate   |   Ctype     |   Access privileges  

-----------+----------+----------+------------+------------+-----------------------

  postgres   | postgres | UTF8     | de_DE.utf8 | de_DE.utf8 |

  template0 | postgres | UTF8     | de_DE.utf8 | de_DE.utf8 | =c/postgres           +

            |           |           |             |             | postgres=CTc/postgres

  template1 | postgres | UTF8     | de_DE.utf8 | de_DE.utf8 | =c/postgres           +

            |           |           |             |             | postgres=CTc/postgres

(3 rows)

Danach können Sie den Postgres-Superuser einrichten:

createuser - s superx

2.1.4.1.4.11 Postgres unter Redhat

Um Postgres unter Redhat zu installieren muss zuerst ein passendes Repository eingerichtet sein. Die Liste der Repositories geben Sie mit:

yum repolist

aus. Wenn hier Repositories eingetragen sind, suchen Sie als nächstes nach dem Postgres Paket:

yum search postgres

Je nachdem, welche Repositories eingerichtet sind, kann die Postgres Server Version unterschiedlich sein. In dem Beispiel wird die Version:“postgresql84-server.x86_64“ installiert:

yum install postgresql84-server.x86_64

Wenn Postgres installiert wurde, befindet sich das „data“ Verzeichnis unter:

/var/lib/pgsql/data/

Vor data kann auch noch die Versionsnummer von Postgres als Verzeichnis liegen.

Die Datenbank wird initialisiert mit:

service postgresql initdb

Wenn Postgres automatisch mit dem Systemstart mit gestartet werden soll, machen Sie das mit dem folgenden Befehl:

chkconfig postgresql on

Start/Stopp Befehle für Postgres:

service postgresql <command>

für <command> kann folgendes verwendet werden:

start : startet die Datenbank

stop : stoppt die Datenbank

restart : neustart der Datenbank – Nach Änderungen an der Konfiguration

reload : reload pg_hba.conf Datei. Dabei läuft die Datenbank weiter.

2.1.4.1.4.12 Postgres unter Suse Linux

Sie installieren Postgres aus der Distribution mit

zypper -n in -l postgresql

zypper -n in -l postgresql-server

zypper -n in -l postgresql-contrib

Vor dem ersten Start müssen Sie die Sprachumgebung einrichten. Prüfen Sie die installierten Locales mit

locale -a | grep de

Die gewünschte Lolcale, in der Regel de_DE.utf8 , tragen Sie dann in der Datei /etc/sysconfig/postgresql ein, bei der Variable

POSTGRES_LANG="de_DE.utf8"

Danach starten Sie den Server als root mit

rcpostgresql start

Der DBSPACE wird in /var/lib/pgsql/data angelegt, dort liegen dann die Dateien postgresql.conf und pg_hba.conf .    

Damit der Server beim Booten hochfährt, geben Sie ein:

chkconfig --set postgresql on

Dann wechseln Sie in die Shell des Users postgres, und legen den User an mit

createuser --superuser superx

2.1.4.1.4.13 Postgres-Performance-Tipps

Der Optimierer unter Postgres läßt sich uber die Kommandozeile mit

vacuumdb --analyze --verbose -f -d $DBNAME

starten und hilft bei regelmäßiger Anwendung, deshalb empfehlen wir, diesen Befehl als Cronjob jede Nacht oder einmal pro Woche auszuführen.

Wichtige Parameter sind die "Shared buffers" und der "Effective cache size". Shared buffers meinen nicht das gesamte zur Verfügung stehende RAM (das verwaltet das System), sondern den Arbeitsspeicher, der Postgres zum Zwischenspeichern benutzt, bevor Abfragen an den Kernel geschickt werden. Der Wert sollte nicht zu hoch gewählt werden, weil dann die Performance nachlässt. Faustregel: 6-15% des physischen RAM, man sollte aber auch in der Praxis viel probieren.   Generell sollte man auf Datenbankservern mind. die Hälfte des verfügbaren physischen Rams für Postgres reservieren.

Beim Start des Postmasters lassen sich die "Shared buffers" zuweisen mit der Option

postmaster –o "–B 128"

Dabei wird das Shared Memory von (standardmäßig) 64*8192 Bytes auf 128*8192 Bytes erhöht. Man kann den Parameter aber auch in der postgresql.conf setzen.

Die checkpoint segments sollen Sie erhöhen, wenn Sie in den Postgres-Logs folgende Meldung bekommen:

LOG:   Checkpoints passieren zu oft (alle xx Sekunden)

TIPP:   Erhöhen Sie eventuell den Konfigurationsparameter "checkpoint_segments".

In der Postgres-Auslieferung sind checkpoint segments=3 vorgegeben, bei großen Anwendungen sollten Sie großzügig erhöhen, z.B. 24.

Effective Cache Size sollte als Faustregel   25% des physischen RAM betragen.

Diese und weitere Perfomance-Tipps für das jeweilige Betriebssystem finden Sie im PostgreSQL Administrator's Guide im Abschnitt "Run-Time Configuration".

Leider lassen sich Transaktionen für Postgres nicht abschalten, für ein (passives) Berichtssystem wie SuperX wären Transaktionen unbedeutend.

Autovacuum wurde mit Postgres 8 eingeführt. Für SuperX empfehlen wir dies nicht, denn das Vacuum wird in der Laderoutine ohnehin jede Nacht ausgeführt, und Autovacuum-Prozesse stören die Laderoutine, teilweise empfindlich.

2.1.4.1.4.14 Postgres- Nutzerkennungen mit Leserecht

Falls Sie für Testzwecke einen User „ alex “ anlegen wollen, der alle Tabelle n einer DB lesen kann, geht dies mit Postgres so:

Zunächst müssen Sie in der pg_hba.conf sicherstellen, dass Passwort-Anmeldung über IP4 möglich ist:

# TYPE   DATABASE         USER             ADDRESS                 METHOD

host     all             all             <<IP-Nummernkreis>>     md5

Dann starten Sie Postgres neu oder führen einen RELOAD aus, z.B. unter Linux:

/etc/init.d/postgresql reload

Dann gehen Sie als Superuser auf den DB-Server, und führen Sie in der Ziel-Datenbank folgende SQLs aus:

CREATE USER alex WITH   NOSUPERUSER PASSWORD 'password';

GRANT USAGE ON SCHEMA public TO alex ;

GRANT SELECT ON ALL TABLES IN SCHEMA public TO alex ;

ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO alex ;

Der letzte Befehl sorgt dafür, dass auch neue Tabellen Berechtigung erhalten.

Wenn Sie das Passwort später ändern wollen schreiben Sie

alter USER alex WITH   PASSWORD 'anfang12';

2.1.4.1.5 Datenbankverbindung über einen eingeschränkten User für mehr Sicherheit

Zur Erhöhung der Sicherheit ist es möglich, dass die Datenbankverbindung von Tomcat zur Datenbank mit einem eingeschränkten User durchgeführt wird. Richten Sie dazu einen entsprechenden User in Ihrer Datenbank ein und geben Sie diesen beim Propadmin bei eingeschränkter User an.

  Der erste im Propadmin auszufüllende User muss weiterhin umfassende Rechte auf alle Tabellen haben, weil er auch bei Modulinstallationen/-updates verwendet wird. Das Minimum, was der eingeschränkte User haben muss sind select-Rechte auf alle Tabellen, insert-Rechte auf die Tabelle protokoll und update-Rechte auf userinfo .

Sobald Sie Ihre db.properties mit dem Propadmin bearbeitet haben, sieht die db.properties z.B. so aus:

connectionName=superx

restrictedConnectionName=superx_restricted

connectionPassword=sx_des\#8\#-127\...

restrictedConnectionPassword=sx_des\#34\#76...

Nun können Sie auf DB-Ebene die nötigen Rechte vergeben. Zunächst sollten   Sie modulweise die vorgefertigten Scripte von uns aufrufen. Diese sind DBMS-spezifisch, und durch entsprechende Aufrufe könen Sie steuern, daß einzelne Module (z.B. Stellen, Personal) nicht lesbar sind (siehe unten).

Zur Sicherheit sollten Sie zunächst alle Rechte entfernen, und dann explizit vergeben.

Wenn Sie keine modulspezifischen Tabellenrechte benötigen, können Sie praktisch die Leserechte auf alle Tabellen vergeben, in dem Sie einmal das Skript

sx_restrictedconnmanager.x false aufrufen .

Wenn Sie Funktionen wie User/Gruppe/Maske einrichten/löschen etc. im XML-Frontend benutzen wollen, müssen zusätzliche Kernmodultabellen freigeschaltet werden:

sx_restrictedconnmanager.x true

Nach einem Tomcat-Neustart findet sich in der catalina.out nach "Aufbau von Datenbank-ConnectionPool (..) .. OK" ein Hinweis:

eingeschränkter Datenbankuser für Verbindung: true|false

2.1.4.1.5.1 Entfernen und Vergeben von Datenbankrechten unter Informix

Achtung bei Informix: wenn ein Benutzer unter Unix angelegt wurde, hat der automatisch Rechte auf alle Datenbanken, die lokal liegen.

Bei Informix haben standardmäßig alle Datenbankobjekte Rechte für die Gruppe "public", d.h. alle angemeldeten Benutzer. Bei Informix muss man daher alle Objekte der Gruppe "public" entziehen, und dann dem jew. User explizit geben.

Beispiel für "Entfernen von Rechten" unter Informix für den User "superx_restricted":

#!/bin/sh

#das folgende Script nimmt dem User superx_restricted alle Rechte auf SuperX-Tabellen:

#Kernmodul:

install/conf/module_revoke.x "all" public

#nur zur Sicherheit:

install/conf/module_revoke.x "all" superx_restricted

for i in bau cob erfolg fin gang ivs kenn sos zul sva; do

module/$i/conf/module_revoke.x "all" public

#nur zur Sicherheit:

module/$i/conf/module_revoke.x "all" superx_restricted

done

Danach vergeben Sie Rechte gezielt für den User "superx_restricted", hier z.B. für alle Module außer SVA:

#das folgende Script gibt dem User superx_restricted Rechte auf alle Tabellen ausser SVA:

#DOQUERY "GRANT USAGE   ON SCHEMA superx   TO superx_restricted;"

install/conf/module_grant.x "select" superx_restricted

#Recht, temp.Tabellen anzulegen:

DOQUERY "grant resource to $GRANTEE;"

for i in bau cob erfolg fin gang ivs kenn sos zul; do

module/$i/conf/module_grant.x "select" superx_restricted

done

2.1.4.1.5.2 Entfernen und Vergeben von Datenbankrechten unter Postgres

Anders als bei Informix ist der Datenbank-User unabhängig vom Betriebssystem-User, d.h. Man muss den Benutzer in Postgres manuell anlegen und Rechte vergeben.

create user superx_restricted with password 'anfang12';

Wenn der Benutzer kein Superuser ist, hat er zunächst keinerlei Leserechte auf vorhandene Datenbankobjekte, er kann aber neue Objekte,z.B. Tabellen, erzeugen.

Man kann also direkt die "grant"-Befehle absetzen, z.B. Tabellenrechte für alle Module außer SVA:

#das folgende Script gibt dem User superx_restricted Rechte auf alle Tabellen ausser SVA:

install/conf/module_grant.x "select" superx_restricted

for i in bau cob erfolg fin gang ivs kenn sos zul; do

module/$i/conf/module_grant.x "select" superx_restricted

done

2.1.4.1.6 Automatischer Start des Datenbankservers als Dienst

Nach erfolgreicher Installation des Datenbankservers muss der Server als Dienst eingerichtet werden. Wir haben das Vorgehen für die Betriebssysteme RedHat 8.0 und SuSE Linux 7.x-8.x beschrieben (für Debian ebenfalls, aber diese Scripte haben wir noch nicht getestet).

2.1.4.1.6.1 Einrichtung der Dienste

Im Kernmodul befinden sich unter /home/superx/db/etc die Vorlagen für den DB-Server. Die Ordnerstruktur entspricht dem Linux-Rechners auf oberster Ebene. Kopieren Sie die Dateien als root in die entsprechenden Verzeichnisse, z.B. bei Redhat-Linux

$SUPERX_DIR/db/etc/init.d/superx_db.redhat
nach
/etc/init.d/superx_db
Ebenso verfahren Sie mit den Dateien in $SUPERX_DIR/db/etc/sysconfig .

Dann machen Sie die User informix / postgres   zu Eigentümern der Dateien.

Die Variablen, die ggf. angepasst werden müssen, sind

SUPERX_USER

JAVA_HOME und andere Variablen aus $SUPERX_DIR/db/bin/SQL_ENV

(wenn Sie SuperX in einem anderen Verzeichnis als /home/$SUPERX_USER installiert haben, müssen Sie die Pfade zu TOMCAT_START und TOMCAT_STOP entsprechend anpassen).

Dann erzeugen Sie als root die leere Datei
/var/log/superx.log

und machen den User superx zum Eigentümer
chown superx:users /var/log/superx.log

Analog verfahren Sie mit

• • /var/log/informix und machen den user informix zum Eigentümer
  bzw. 

• • /var/log/postgres und machen den user postgres zum Eigentümer 

• •  

Dann

• • kopieren Sie die Datei $SUPERX_DIR/db/etc/home_informix/start.sh in das Homeverzeichnis von Informix ,
  und machen den user informix zum Eigentümer
  bzw.  

• • kopieren Sie die Datei $SUPERX_DIR/db/etc/home_postgres/start.sh in das Homeverzeichnis von postgres ,
  und machen den user postgres zum Eigentümer.  

Kontrollieren Sie, ob die Datei start.sh Ausführungsrechte besitzt.

2.1.4.1.6.2 Aktivierung der Dienste

Zur Aktivierung der Dienste für den Runlevel 3 führen Sie jeweils folgende Schritte durch; erzeugen Sie einen symbolischen Link für das Script superx-db im Runlevel 3 und 5

Redhat/Mandrake:

ln -s /etc/rc.d/init.d/superx_db /etc/rc.d/rc3.d/S90superx_db

ln -s /etc/rc.d/init.d/superx_db /etc/rc.d/rc5.d/S90superx_db

ln -s /etc/rc.d/init.d/superx_db /etc/rc.d/rc3.d/K90superx_db

ln -s /etc/rc.d/init.d/superx_db /etc/rc.d/rc5.d/K90superx_db

SuSE 8.x:

ln -s /etc/init.d/superx_db /etc/init.d/rc3.d/S98superx_db

ln -s /etc/init.d/superx_db /etc/init.d/rc5.d/S98superx_db

ln -s /etc/init.d/superx_db /etc/init.d/rc3.d/K98superx_db

ln -s /etc/init.d/superx_db /etc/init.d/rc5.d/K98superx_db

Debian,LSB:

ln -s /etc/init.d/rc/superx_db /etc/init.d/rc3.d/S98superx_db

ln -s /etc/init.d/rc/superx_db /etc/init.d/rc5.d/S98superx_db

ln -s /etc/init.d/rc/superx_db /etc/init.d/rc3.d/K98superx_db

ln -s /etc/init.d/rc/superx_db /etc/init.d/rc5.d/K98superx_db

Danach können Sie als root testen, ob die Scripte laufen, indem Sie als root
/etc/init.d/superx_db start
zum Starten der Datenbank ausführen, und sowie
/etc/init.d/superx_db stop
zum Stoppen der Datenbank.

Etwaige Fehlermeldungen stehen in Logdatei /var/log/informix.log, postgres.log   bzw.

superx.log

2.1.4.2 Einspielen des Kernmoduls der SuperX-Datenbank

Für die Installation haben wir eine Kurzanleitung vorbereitet. Das Kernmodul der Datenbank liegt exportiert vor und kann in das DBMS übernommen werden. Die nachfolgenden Installationschritte gehen davon aus, daß Sie keinen speziellen DBSpace für SuperX vorgesehen haben.

Das Installationsscript für die Datenbank befindet sich im Verzeichnis
$SUPERX_DIR/db/install/kernmodul_erzeugen.x <<ggf. mit Name des DBSpace>>

Das Script läuft nur, wenn die Parameter in der Datei $SUPERX_DIR/db/bin/SQL_ENV stimmen . Bei erfolgreichem Ablauf kommt eine Erfolgmeldung, im Falle eines Fehlers wird die Fehler-Logdatet create.log angezeigt. Wenn ein Fehler auftritt, müssen sie die Datenbank vor einem erneuten Ablauf des Scriptes droppen.

Wenn Sie bei der Postgres Installation nicht den Parameter --enable-multibyte=LATIN1 angegeben haben müssen Sie eventuell in dem Script   kernmodul_erzeugen.x die Variable ENCODING   auf   LATIN1 setzen.

Danach können Sie mit dbaccess superx (unter Informix) bzw. psql superx (unter Postgres) testen, ob die Datenbank verfügbar ist.

Schließlich sollten Sie die Tabelle hochschulinfo anpassen und die Daten Ihrer Hochschule dort eingeben, insbesondere die Hochschulnummer (apnr-Wert in cifx mit key=36).

2.1.4.3 Update und Sichern der Datenbank

Vor dem Start der Update-Scripte sollte immer eine Sicherung der Datenbank erfolgen. Für Backups ist es notwendig, die Datenbank regelmäßig zu exportieren. Beide Datenbanken bieten entsprechende Werkzeuge.Es bietet sich an, einen cronjob einzurichten, der zuerst das Backup vornimmt, und dann die einzelnen Module nacheinander aktualisiert.

Ein Beispiel-Eintrag der crontab des users superx liegt in $SUPERX_DIR/db/module/crontab.sam . Ein Beispiel-Update-Script   liegt in $SUPERX_DIR/db/module/update.x.sam . Der Eintrag in der crontab, der das Script werktags um 18:00 Uhr startet, sähe dann wie folgt aus:

Ein Beispielinhalt für das Script update.x ist Teil des Kernmoduls:

Ein Beispielscript, das die Datenbank sichert, liegt in $SUPERX_DIR/db/install/dump_it.x . Es erzeugt den Dump im Verzeichnis $SUPERX_DIR/db/install , prüft die erfolgreiche Sicherung und verschickt ggf. eine Fehler-Mail. Wenn Sie das Script in einem Cronjob betreiben wollen, müssen Sie als ersten Parameter $SUPERX_DIR übergeben.

Die Rücksicherung einer Datenbank ist mit dem Script $SUPERX_DIR/db/install/restore_it.x   möglich.

2.1.4.3.1 Ein Dump unter Informix

Die Datenbank lässt sich mit dem Kommando dbexport –o <Pfad> superx exportieren und sichern. Beachten Sie aber, dass durch das Servlet eine (oder mehrere) Verbindungen zur Datenbank geöffnet ist. Deshalb muss das Servlet beendet werden oder die Datenbank muss vom User Informix einmal auf quiescent und dann wieder auf online gesetzt werden, damit eventuell noch ablaufende SuperX-Prozesse beendet werden.

2.1.4.3.2 Ein Dump unter Postgres

Postgres lässt sich auch im laufenden Betrieb sichern.

In unserem Dump-Script wird der Dump mit dem Parameter "--inserts" versehen. Dies ist eine sehr vorsichtige Einstellung, aber der Dump ist dadurch maximal kompatible zu verschiedenen Postgres-Versionen, außerdem tauchen keine Probleme mit Umbrüchen in langen Textfeldern auf.

Wenn Ihnen die resultierenden Dumps zu groß sind, können Sie in einem eigenen Dump auf die Inserts verzichten,z.B. mit

pg_dump -f superx.sql superx

Noch kompakter ist der Dump als Binärfile mit dem Parameter --format=c:

pg _dump -f   $DBNAME.sql --format=c $DBNAME

2.1.4.4 Anpassung der DB-Parameter für Clientanwendungen

Zunächst ist es wichtig, eine Verbindung vom Webserver zum Datenbankserver zu bekommen. Dazu gibt es verschiedene Werkzeuge.

2.1.4.4.1 Unter WIN32 auf den Informix-Server zugreifen: iLogin

superx_server        1542/tcp

hinzufügen.

Nun können Sie Parameter für den Zugang von WIN32-Rechnern auf den Datenbankserver überprüfen. Der beste Weg dafür ist das Werkzeug iLogin, das von Informix in den Client-SDKs mitgeliefert wird. Die folgende Abbildung zeigt ein Beispiel für die Parameter beim iLogin

Die Parameter sind oben bereits erläutert. Ein erfolgreicher iLogin ist Voraussetzung für das weitere Vorgehen!

2.1.4.4.1.1 SuperX (Informix) unter Win32 als ODBC-Datenquelle einrichten

Für den regulären SuperX-Betrieb ist dieser Schritt nicht unbedingt erforderlich. Wenn Sie allerdings unter Win32 direkt auf die Datenbank zugreifen möchten, z.B. um Microsoft Access als Frontend einzusetzen, müssen Sie SuperX als ODBC-Quelle einrichten. Für die Informix-Datenbank gibt es eigene Treiber für den ODBC-Zugriff (für IDS 7.31 gibt es Intersolv 3.10 oder 3.11). Diesen Treiber muss man sich zunächst von www.informix.com besorgen. Meist sind die Treiber Teile des Informix Client SDK; für den reinen ODBC-Zugriff reicht es vollkommen aus, bei der Installation Custom zu wählen und nur den ODBC-Treiber zu installieren.

Zur Installation:

Systemsteuerung -> (Win 2000: Verwaltung)-> Datenquellen (ODBC)->System-DSN   -> Hinzufügen

Für IDS 7.31 kann man als ODBC-Treiber z.B.den Intersolv 3.11-Treiber wählen. Dieser befindet sich im Informix Client SDK 2.40 (der 3.10-Treiber geht auch, der ist im Informix Client SDK 2.02). Für den IDS 9.21 benötigt man den Treiber Informix 3.33, der Teil des Client SDK 2.60 ist. Version 3.34 läuft ebenfalls.
Der Datenquellen-Name ist superx.
Als Datenbank-Name die SuperX-Datenbank angeben. Für die Verbindung die rechten Parameter eingeben (Achtung: Beispielangaben für Duisburg); wichtig sind der Hostname, der Service-Name (s.u.) und der Server.

Get-DB-List from Informix kann man deaktivieren. Manche ODBC-Treiber erlauben es in den erweiterten Optionen (Environment), eine DB-Locale zu definieren; wir empfehlen, diese auf Use Server Database Locale zu setzen.

Beachten Sie ggf., dass diese Installation unter NT/ Win 2000 kennungsabhängig ist.

2.1.4.4.2 Einrichtung des ODBC-Treibers für den Postgres-Server

Der ODBC-Treiber für Postgres ist vom Postgres-Projekt verfügbar ( www.postgresql.org ). Er ist in der 8.0-Distribution von Postgres bereits enthalten. Der Treiber lässt sich leicht installieren, indem Sie in der Systemsteuerung über Verwaltung -> ODBC-Datenquellen eine Datenquelle einrichten, z.B. mit dem Namen superx.

Der Datenquellen-Name ist superx, der Datenbankname ebenfalls. Bei Server geben Sie den Hostnamen oder die IP-Nummer ein, und rechts den Port. Die Kennung ist hier z.B. superx .

Im Dialog "Options-> Datasource" müssen einige Einstellungen vorgenommen werden:

Setzen Sie die Data Type Options wie rechts angezeigt. Das Kreuz bei Bools as Char ist notwendig, weil Access oder andere Frontends sich mit Postgres bei Binären Datentypen nicht vertragen. Boolean-Felder werden mit "1" oder "0" codiert. Bei Max Varchar geben Sie 255 ein (sonst macht Access aus allen VARCHAR(255)-Feldern Memo-Felder), und Max LongVarchar mindestens 30.000. Der Rest ist ok.

Auf der zweiten Seite sind die Defaults korrekt.

Die Linefeed-Umsetzung ist wegen der Scripte in SuperX-Textfeldern notwendig.

2.1.4.4.3 Anbindung des Access-Frontends an die ODBC-Quelle

Wenn Sie die SuperX-Datenbank als ODBC-Quelle unter dem Namen superx eingerichtet haben, dann können Sie das im SuperX-Clientpaket   unter $SUPERX_DIR/tools/access/superx_frontend_sam.mdb enthaltene Access-2000-Frontend benutzen. Bei der Datei handelt es sich um ein Muster, vor dem ersten Gebrauch kopieren Sie sie bitte nach $SUPERX_DIR/db/superx_frontend.mdb und arbeiten Sie nur mit letzterer Datei - so können Sie sichergehen, dass Ihr Access-Frontend nicht bei einem SuperX-Update überschrieben wird.

Beim ersten Öffnen der Datei sind die Tabellen noch nicht verknüpft. Sie müssen zunächst Das Formular Setup aufrufen, den Namen der ODBC-Quelle (s.o.) eintragen, und "Erzeuge Kernmodul-Verknüpfungen" drücken. Wenn der Informix-Treiber dies unterstützt, sollte vorher die Option "Passwort speichern" aktiviert werden, ansonsten muss man für jede Tabellenverknüpfung das Passwort eingeben.

Die Datenquelle wird eingegeben, und die Kernmodul-Tabellen können so verknüpft werden. Die Verknüpfungen haben nach Access-Voreinstellung den Namen "superx_tabellenname" und werden automatisch umbenannt zu "tabellenname".

Falls der Setup so nicht funktioniert, müssen die Tabellen "von Hand" verknüpft und umbenannt werden. Die Funktionalität des Access-Frontends ist dadurch nicht beeinträchtigt. Bei Tabellen ohne Primary Key muss allerdings ein eindeutiger Datensatzbezeichner angegeben werden, sonst ist die Tabelle schreibgeschützt.

2.1.4.4.4 Anpassen der Datenbankparameter für das SuperX-Servlet

Wenn Sie die Verfügbarkeit des Datenbankservers getestet haben (z.B. über das Utility iLogin von Informix), dann müssen die Datenbankparameter in die Datei

$SUPERX_DIR/webserver/tomcat/webapps/superx/web-inf/db.properties

übertragen werden, damit das Servlet eine Verbindung zur Datenbank herstellen kann. Ein Muster für Informix und eines für Postgres ist bereits im Kernmodul enthalten. Kopieren Sie die Datei db-informix.properties bzw. db-postgres.properties nach db.properties . Das voreingestellte Passwort lautet hier "anfang12".

Zur Erstellung und ggfs. Änderung dieser Datei gibt es ein Tool: propadmin.x . Das Shellscript liest aus der Umgebungsvariable $DB_PROPERTIES (oder über den ersten Parameter) den Speicherort der db.properties ein; in der Regel muss das die obige Position sein, damit das Servlet die Datei findet. Ausnahmen gibt es nur, wenn SuperX über den jdbc-Client auf eine andere Datenbank zugreifen soll.

  Starten Sie das Tool von einer Konsole bzw. Eingabeaufforderung das Tool mit dem Befehl
propadmin.bat

bzw.
propadmin.x (unter Linux).

Füllen Sie die Felder entsprechend des folgenden Beispiels (zunächst Postgres, dann Informix):

 

Hinweis für Postgres: Wenn Sie Postgres auf einem anderen Port als dem voreingestellten 5432 betreiben, müssen Sie im jdbc-Treiber als Connection-URL den Port wie folgt angeben:
connectionURL=jdbc:postgresql://localhost:<<Portnumer>>/superx

Bei Informix könnte es beispielsweise so aussehen:

Nehmen wir z.B. für Informix die Parameter beim ILogin (oben erläutert). Wenn die rechte Abbildung eine korrekte Einstellung anzeigt, ....

...dann übernehmen Sie die Parameter wie folgt für die db.properties :

Der Port 1542 ergibt sich aus dem Service für SuperX, der oben bereits beschrieben wurde.

Die Parameter für den LogLevel können auf einer Skala von fünf Stufen gewählt werden: FINEST bis SEVERE. Bei FINEST wird fast alles geloggt, bei SEVERE werden nur Fehler geloggt .

Im Entwicklungsmodus werden alle SQL-Befehle von Abfragen einzeln an die Datenbank geschickt.Das dauert etwas länger, ermöglicht aber bessere Fehlermeldungen. Man kann diese Einstellung auch im laufenden Betrieb ändern.

Die Parameter im Cache legen fest, wie viel Information gecached werden werden sollen. Standardmäßig wird nichts gecached, aber im Produktiveinsatz sollten hier die entsprechenden Parameter gewählt werden.

In den Connection-Pool Angaben wird angegeben, wieviele Verbindungen maximal gleichzeitig vom Servlet zur Datenbank hergestellt werden sollen.

Durch Anklicken von OK wird die Datei db.properties (bzw. der Pfad zum Inhalt der Umgebungsvariable DB_PROPERTIES) erstellt, wobei das Passwort verschlüsselt wird. Vorher sollten Sie mit "Verbindung Testen" prüfen, ob eine Datenbankverbindung hergestellt werden kann. Wenn dies nicht klappt, sollten die Fehlermeldungen weiterhelfen.

Wenn Sie einen UNIX / LINUX-Server für Tomcat betreiben wollen, dann ist es möglich, daß   Sie unter Linux keine graphische Java-Umgebung starten können. In diesem Fall müssen Sie das Kernmodul auf einem Rechner mit installiertem Java und graphischer Umgebung kopieren,   das Programm dort aus der Konsole starten und die Parameter ändern (wichtig: der Rechner muss die gleiche Zeichenkodierung haben, also LATIN1). Danach kopieren sie die Datei db.properties mit scp / WinSCP auf den UNIX-Rechner. Alternativ können Sie die Parameter mit dem vi bearbeiten. Wenn der Propadmin ohne graphische Umgebung gestartet wird, kann lediglich das Passwort eingegeben werden.

Wenn Sie Tomcat auf einem anderen Rechner als dem Datenbankserver betreiben, müssen Sie die Startdateien propadmin.bat bzw. propadmin.x im Verzeichnis
$SUPERX_DIR/webserver/tomcat/webapps/superx/WEB-INF
benutzen (in diesem Falle ist das Verzeichnis $SUPERX_DIR/db nicht notwendig.)

2.1.4.4.4.1 Anpassung der Datenbankparameter für das SuperX-Servlet speziell für Informix

Für den Informix JDBC Treiber kann angegeben werden wo Temporäre und Cache Dateien abgespeichert werden. Im Normalfall wird dafür das aktuelle Verzeichnis verwendet. Wenn der Tomcat als Service gestartet wird, ist es nicht immer ganz klar, wo das nun liegt und ob dort nun die richtigen Berechtigungen vorliegen. Um Problemen vorzubeugen wird empfohlen die Connection Property JDBCTEMP zu setzen. Der angegebene Pfad sollte von Root („/“) aus gehen. Beispiel:

connectionURL=jdbc\:informix-sqli\://superxdb\:1542\:informixserver\=superxdb;database\=superx;JDBCTEMP\=/tmp

Wenn in der catalina.out folgende Fehlermeldungen auftauchen, kann der Parameter JDBCTEMP die Lösung sein:

java.sql.SQLException: Blob not found

java.io.IOException: Permission denied

Der Parameter LOBCACHE steuert wo der Cache abgelegt wird. Positive Zahlen gibt die maximale Anzahl an bytes an, die im Arbeitsspeicher angelegt werden. „0“ bedeutet, alles wird im Dateisystem in Temp Ordner abgelegt. Und bei negativen Zahlen wie -1 wird alles im Arbeitsspeicher abgelegt. Es kommt dann allerdings zu einem Fehler, wenn dieser voll ist.

Weitere Infos hier:

http://www.ibm.com/support/knowledgecenter/SSGU8G_11.50.0/com.ibm.jdbc_pg.doc/ids_jdbc_040.htm

2.1.4.4.5 Datenbankverbindung und Steuerung von DBForms

Neben der normalen Properties-Konfiguration muss außerdem der Verbindungsparameter für die Servlets von DBFORMS gesetzt werden.

Die zentrale Steuerungsdatei heißt dbforms-config.xml und liegt im Verzeichnis SUPERX_DIR/webserver/tomcat/webapps/superx/WEB-INF . Dort liegt bereits ein Muster mit dem Namen kern_dbforms-config_pg.xml für Postgres bzw. kern_dbforms-config_ids.xml für Informix. Diese Datei wird bei der Installation automatisch kopiert nach dbforms-config.xml .

Die Datenbankverbindung wird in der Datei $WEBAPP/META-INF/context.xml konfiguriert .   und am Ende der Datei die Connection-Attribute angeben. Die Parameter sind identisch mit denen, die Sie in der db.properties angeben.

Wenn Sie die DBFORMS-Komponente nicht   benötigen bzw. aus Sicherheitsgründen für eine externe Website abschalten wollen, gehen Sie wie folgt vor:

Durch diese Maßnahme sind der DBFORMS-Komponente keine Datenbankverbindungen mehr möglich, und das Ausspähen geschützter Dateien in Tomcat-Systemverzeichnissen durch das Control-Servlet ist nicht mehr möglich.
Eine Abschaltung der DBFORMS beeinträchtigt in keiner Weise die "normalen" Funktionen zur Berichtserstellung von SuperX.

2.1.4.4.6 Ein SSH-Tunnel für die Datenbank

Mit der oben beschriebenen Installation ist die Datenbankverbindung zwischen Client und Server noch unverschlüsselt. Zur Verschlüsselung kann einerseits die native Verschlüsselung im DBMS eingeschaltet werden. Man kann aber auch Datenbankverbindungen durch einen zusätzlichen ssh-Tunnel verschlüsseln. Zum Tunneln z.B. von Postgres von einem entfernten Rechner über ssh gehen Sie wie folgt vor:

Unter Windows:

• •   Starten Sie den ssh-Client putty (z.B. von http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html ) 

• •   Erzeugen Sie ggf. eine neue Session, indem Sie auf der obersten Seite "Sessions" den Host Name, Port, Protocol=ssh eintragen. 

• •   Geben Sie dann bei saved sessions einen neuen Namen, und drücken Sie sicherheitshalber "Save". 

• •   Geben Sie im Menüpunkt "Connection" bei "Auto-Login username" den Namen "superx" an. 

• •   Geben Sie im Menüpunkt "SSH"->"Tunnels" unten im Menü "Add new forwarded Ports" 

• •   bei "Source Port" z.B. "9998" ein. 

• •   Bei "Destination" geben Sie "localhost:5432" ein (wenn 5432 der Port ist, auf dem Postgres läuft). 

• •   Lassen Sie "Local" angekreuzt, und drücken Sie dann darüber "Add") 

 

• •   Dann speichern Sie die Session auf der obersten Seite "Sessions" 

• •   Dann drücken Sie unten "Open" und loggen sich ein. 

Unter Unix/Linux:

Geben Sie einfach in der Shell ein:
ssh superx@<<IP-Nr. des DB-Servers>> -L 9998:localhost:5432

  In diesem Moment ist der Tunnel eingerichtet. Sie können ihn nun nutzen, wenn Sie mit Ihrem JDBC- oder ODBC-Client auf den Port localhost:9998 zugreifen.

  Z.B. für die sqlWorkbench unter Postgres im Dialog "Connect" die URL

  jdbc:postgresql://localhost:9998/superx

  Der Tunnel wird geschlossen wenn Sie sich ausloggen. Sie müssen übrigens nicht den Hostnamen des Client-Rechners in die pg_hba.conf eintragen, für Postgres verhält sich der Tunnel so, als ob vom Rechner "localhost" auf den Server zugegriffen wird. Auch in der Firewall des DB-Servers muss nur der SSH-Port freigeschaltet sein, nicht der Datenbank-Port.

  Bei Problemen ist ggf. im SSH-Server das Port-Forwarding aus Sicherheitsgründen ausgeschlossen. Für Informix haben wir das obige Vorgehen noch nicht getestet.

2.1.5 Installation und Pflege des Webserver s

Die Servlet-Engine Tomcat verfügt zwar über einen kleinen "eingebauten" Webserver, doch für den Echtbetrieb sollte man aus Performance-Gründen einen der marktgängigen Webserver nutzen (z.B. Apache, IIS), der auch Verschlüsselung bietet. Für den Echtbetrieb empfehlen wird die Installation eines Apache 1.3.x auf Linux-Basis – meist ist dieser in der Linux-Distribution bereits integriert. Der Apache läßt sich sehr gut mit dem Tomcat verbinden (siehe Tomcat User's Guide im Kernmodul unter $SUPERX_DIR/doc/tomcat/doc ). Bei der Linux-Installation gehen wir davon aus, dass alle Maßnahmen unter der Kennung superx erfolgen, und dass der User superx Zugriffsrechte auf die Datenbank hat. Beim Kopieren des Archivs sollten Sie darauf achten, dass der User superx auf die Scriptdateien Ausführungsrechte besitzt.

Die folgenden Anleitungen gehen davon aus, dass Sie als Installationspfade für den Webserver C:\superx\webserver (unter win32) und /home/superx/webserver (unter UNIX / LINUX) gewählt haben. Sie können natürlich auch andere Pfade wählen, müssen dann aber die Pfade in dieser Dokumentation entsprechend umsetzen. Fehlende oder falsche Pfade bzw. Umgebungsvariablen sind in Java- und Datenbankprojekten eine wichtige Fehlerquelle (z.B. unter LINUX die Groß- / Kleinschreibung). Aus diesem Grunde haben wir ins Stammverzeichnis des webservers eine html-Datei erstellt ( $SUPERX_DIR/webserver/index.htm ), von der aus die Parameter und Pfade schrittweise überprüft werden können.

2.1.5.1 Installation von Java und Datenbanktreibern

Der Webserver muss Java-fähig sein, damit er Servlets ausführen kann.

Arbeitsschritte:

1. 1.   OpenJDK 1.8   installieren
    

2. 2. Die Umgebungsvariable JAVA_HOME setzen und das bin-Verzeichnis der Java-Installation in den PATH legen. Die Umgebungsvariable CLASSPATH sollte mindestens "." enthalten, aber auf keinen Fall einen älteren XML-Parser (z.B. xerces 1.0). 

3. 3. Nur für Informix-Anwender: Laden Sie den jdbc-Treiber von Informix (oder das Informix Client SDK) herunter, installieren Sie das Produkt und kopieren Sie die Datei ifxjdbc.jar nach $SUPERX_DIR/webserver/tomcat/webapps/superx/WEB-INF/lib . 

4. 4. Testen Sie die Datenbankverbindung mit dem Werkzeug propadmin . 

5. 5. Ablauf mit einem einfachen java-Servlet testen  

2.1.5.2 Einrichtung der Servlet-Engine

Die Servlet-Engine ermöglicht dem   Webserver das SuperX-Servlet auszuführen. Anders als andere Scriptsprachen (z.B. asp, PHP, Perl) für Webserver ist der Java-Code als Bytecode kompiliert; die Servlets werden normalerweise also nicht auf dem Webserver entwickelt und getestet, sondern auf einem eigenen Entwicklungsrechner.

Im Kernmodul ist der Tomcat 8 . 5 . 4 0   mitgeliefert. Tomcat ist von Oracle als Referenzimplementierung von Webapplikationen anerkannt, d.h. Sie sollten die Konfiguration mühelos auf andere Server übertragen können. Die Web-Applikation von SuperX läuft unter allen Tomcat-Versionen ab 8.*

2.1.5.2.1 Steuerung des Servers: Die server.xml

Editieren Sie zunächst die Konfigurationsdatei $SUPERX_DIR/webserver/tomcat/conf/server.xml .

Hier werden die Ports und Anbindungen der Tomcat-Implementation angepasst. Standardmäßig läuft Tomcat auf dem Port 8080, und die Apache-Anbindung auf dem Port 8009. Weiterhin muss der Port 8005 für den Shutdown frei sein. Die Apache-Anbindung ist weiter unten dokumentiert.

Wichtig beim Betrieb des Tomcat mit UTF-8-Codierung: Der jew. Connector muss das weitere Attribut URIEncoding="UTF-8" aufführen. Wenn z.B. der Connector 8080 genutzt wird, sieht das so aus:

Dies ist wichtig für den Ajax-Client.

Analog bei ISO Installationen:

URIEncoding="ISO-8859-1"

Nach einer Änderung müssen Sie Tomcat neu starten.

2.1.5.2.2 Datenbankverbindung für DBFORMS: die context.xml

In der Datei

$SUPERX_DIR/webserver/tomcat/webapps/superx/META-INF/context.xml

befinden sich ein paar Attribute für die Webanwendung:

<Context reloadable="true" crossContext="true">

          <Logger className="org.apache.catalina.logger.FileLogger"

                      prefix="localhost_superx_log." suffix=".txt"

              timestamp="true"/>

          <Manager pathname="" />

          <Environment name="maxExemptions" type="java.lang.Integer"

                      value="15"/>

</Context>

Diese Datei wird im Kernmodul nicht ausgeliefert, es existiert aber einer Musterdatei context.xml.sam im gleichen Verzeichnis.

Die Datenbank-Verbindung für DBFORMS und Saiku wird in der Datei $SUPERX_DIR/webserver/tomcat/webapps/superx/ WEB-INF / dbforms-config .xml definiert. Am Ende steht:

<dbconnection conClass="org.apache.commons.dbcp.PoolingDriver"

name="jdbc:apache:commons:dbcp:default"

isJndi="false"

default="true"

defaultConnection="true" />

Damit wird der Connection Pool genutzt, der in der db.properties definiert ist. Nach einer Änderung muss man Tomcat neu starten.

2.1.5.2.3 Die Datei conf/web.xml

In der Datei $TOMCAT_HOME/conf/web.xml sie   u.a. die serverweite "Welcome-Page" bzw. deren Reihenfolge., welche wiederum Dateien anzeigen, wenn der Anwender ein Verzeichnis ohne Dateinamen aufruft, z.B. http://servername/superx/ :

Wenn Sie z.B. die Reihenfolge so ändern, dass zuerst die Datei index.jsp angezeigt wird (sofern sie existiert), dann können Sie eigene "Homepages" definieren, die nicht von der SuperX-Distribution (z.B. bei Updates) überschrieben würden. Außerdem ist dies eine sinnvolle Sicherheitsmassnahme, weil so keine Directory Listings angezeigt werden.

Änderungen in der Datei web.xml in der Webanwendung ( <<Webanwendung>>/WEB-INF/web.xml ) überschreiben die Einträge in der serverweiten web.xml .

Weitere Konfigurationsmöglichkeiten (Server Side Includes etc). sind in dieser Datei dokumentiert.

Vergleiche auch den unten folgenden Abschnitt zur Einrichtung der SuperX-Servlets unter Tomcat.

2.1.5.2.4 Administrator und Manager

In der Tomcat Auslieferung gibt es Beispiel-Webanwendungen, bitte löschen Sie diese.

2.1.5.2.5 Einrichten der SuperX-Servlets unter Tomcat

2.1.5.2.5.1 Allgemeines zur web.xml

Die Datei $WEBAPP/WEB-INF/web.xml enthält die Konfiguration der Webanwendung, z.B. maximale Zeilenanzahl bei Berichten. Diese Datei wird initial ausgeliefert, bei Upgrades des Kernmoduls aber nicht automatisch überschrieben. Im Zweifelsfall stellen Sie die Auslieferungsdatei wieder her, es Muster dafür befindet sich in der Datei $WEBAPP/WEB-INF/web.xml. superxonly .

Eine Änderung in der web.xml macht einen Tomcat Neustart erforderlich. Achten Sie auf die wolhgeformte XML Notation, wenn die Datei nicht wohlgeformt ist, startet der Server gar nicht mehr. Nutzen sie daher am Besten einen XML-fähigen Editor.

Ab Kernmodul 4.9 benötigen Sie in der Datei am Ende vor dem ersten "<servlet-mapping>" Eintrag folgende Konfiguration:

    <!--REST -->

    <servlet>

  <servlet-name>Jersey REST Service</servlet-name>

<servlet-class>

  com.sun.jersey.spi.container.servlet.ServletContainer

</servlet-class>

  <init-param>

    <param-name>com.sun.jersey.config.property.packages</param-name>

    <param-value>de.superx.sxrest</param-value>

  </init-param>

  <load-on-startup>1</load-on-startup>

</servlet>

<servlet-mapping>

  <servlet-name>Jersey REST Service</servlet-name>

  <url-pattern>/sxrest/*</url-pattern>

</servlet-mapping>

<!--Ende REST -->

    <servlet-mapping>

      <servlet-name>spring</servlet-name>

      <url-pattern>/oauth/*</url-pattern>

    </servlet-mapping>

Im Zweifelsfall

Für SuperX-Standalone-Betrieb (also unabhängig von HisInOne) ist ab Kernmodul 5.0 der context-Parameter zentral

<web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" version="2.4">

    <display-name>SuperX</display-name>

    <absolute-ordering />

    <description>SuperX</description>

    <context-param>

      <param-name>superxStandalone</param-name>

      <param-value>true</param-value>

    </context-param>

Anpassen der Datei db.properties mit den Datenbank-Zugangsdaten (siehe Anpassen der Datenbankparameter für das SuperX-Servlet ) ist Voraussetzungen dafür, dass der Applikationsserver auf die Datenbank zugreifen kann.

2.1.5.2.5.2 SuperXManager Servlet

In der web.xml werden im SuperXManager Servlet einige wichtige Konfigurationen vorgenommen:

2.1.5.2.5.3 ResponseCompression

Default für Response Compression ist true, dann braucht der init-param auch nicht angegeben zu werden. Die RTWH Aachen nutzt allerdings einen ReverseProxy der mit der gzip-Kompression nicht klar kam, in diesem Fall kann man durch setzen des   ResponseCompression -Initparams mit param-value=false die Kompression ausschalten.

2.1.5.2.5.4 field1Cache

Neu in SuperX3.5rc2 ist die Möglichkeit einen sogenannten field1Cache für Auswahllisten (Feldart 1) zu nutzen.

Wenn ein entsprechender init-param beim SuperXManager definiert ist, lädt sich der webserver beim Start Inhalte für die angegeben Felder der Feldart 1 (aus felderinfo), in denen es keine dynamischen Tags gibt (wie z.B. <<Haushaltsjahr>>) in einen Cache. Dadurch wird der Start des Webservers natürlich etwas langsamer, aber wenn die Benutzer einzelne Maske aufrufen, können diese schneller dargestellt werden, weil weniger Datenbankzugriffe nötig sind.

Als Param-value muss eine where-Bedingung für einen select auf die Tabelle felderinfo angegeben werden. Sie können das Beispiel tid>10000 belassen oder bei Bedarf bestimmte Felder auslassen, z.B.

tid&gt;10000 and name not in ('Haushaltsjahr','Semester').

Der Cache wird aktualisiert, wenn im SuperXManager-Servlet auf den Button “Server-Cache aktualisieren” geklickt wird oder der Webserver neu gestartet wird. Außerdem wird er jeden Morgen einmal automatisch aktualisiert. Felder die sich zusätzlich zu den nächtlichen Updates dynamisch ändern, sollten ausgeschlossen werden, damit sie immer aktuell aus der Datenbank geholt werden.

2.1.5.2.5.5 Session-Timeout

Ein weiterer Parameter für die gesamte Webapplikation, der aber nur im XML-Frontend ausgewertet wird, lautet <session-timeout> (siehe Beispiel-web.xml in unserem Kernmodul, ganz am Ende der webapp-Deklaration). Dieser Wert beschreibt die "Lebenszeit" einer Anmeldung bei Inaktivität des Benutzers (in Minuten). Ein negativer Wert bedeutet, dass die Session nie beendet wird. Ein sinnvoller Wert ist z.B. 180 (3 Stunden). Je länger die Zeit, desto höher die Belastung des Servers.

2.1.5.2.5.6 CSV-Encoding beim Export

Ab Kernmodul 4.7 / HISinOne-BI 2017.12: Der CSV Export von Masken wird standardmäßig in der gleichen Kodierung vollzogen wie die des Servers. Sie können eine abweichende Codierung eingeben, wenn Sie z.B. den Server unter UTF-8 betreiben, aber den CSV Export für die Anwender/innen in ISO ausführen wollen, weil die meisten Anwender/innen unter Windows mit Excel arbeiten. In diesem Falle setzen Sie für das Servlet SuperXManager den init-param "CSV-Encoding" auf den Wert ISO-8859-1:

    <servlet>

      <servlet-name>SuperXManager</servlet-name>

      <servlet-class>de.superx.servlet.SuperXManager</servlet-class>

  ...

  <init-param>

          <param-name>CSV-Encoding</param-name>

          <param-value> ISO-8859-1 </param-value>

      </init-param>

    </servlet>

Nach einer Änderung müssen Sie Tomcat neu starten.

2.1.5.2.5.7 Fehlerseiten

Sie können auch durch spezielle Fehlerseiten die normale Fehlerausgabe des SuperX-Servlets sperren.

Die ist die Voreinstellung bei Neuinstallation von SuperX, ältere Installationen müssen dies ggf. nachholen.

Sie können auf verschiedene Fehler-Codes sowie Exception-Types eigene Fehlerseiten definieren. Details dazu finden Sie in der Dokumentation Ihres Applikationsservers.

2.1.5.2.6 Start des Tomcat

Vor dem Start müssen die Umgebungsvariablen der Datei $SUPERX_DIR/db/bin/SQL_ENV geladen werden.

Die Umgebungsvariable JAVA_HOME muss korrekt gesetzt sein

• • Unter WIN32:
  Das geht unter MS-DOS als Kommandozeile set JAVA_HOME=c:\jdk1.6x oder man macht einen Eintrag als Systemvariable (Systemsteuerung – System – Erweitert – Umgebungsvariablen) neue Systemvariable JAVA_HOME , Wert c:\jdk1.6x
  (wenn nur die Runtime installiert ist, ist das Verzeichnis evtl. c:\programme\javasoft\jre\1.6x) 

• • <tomcat-Basisverzeichnis>\bin\startup.bat ausführen (zum Beenden shutdown.bat) 

• • Falls unter Windows 98/ME eine Meldung kommt, dass der Umgebungsspeicher nicht ausreicht, muss man über start->Ausführen folgende Zeile eingeben: command.com /p /e:4096  

• • Unter UNIX / LINUX:
  Setzen Sie entweder in der /etc/profile oder in der Datei .profile bzw. .bashrc im Heimverzeichnis des Users superx bzw. bei Betrieb von Datebank und Webserver auf einem Rechner in der Datei $SUPERX_DIR/db/bin/SQL_ENV die Zeile ein:
  export JAVA_HOME=/usr/lib/java (als Beispiel für eine Java-Installation unter SUSE Linux 9.1) 

• • Das aktuelle Verzeichnis sollte im PATH sein (ggfs. /etc/profile oder .profile bzw .bashrc PATH=PATH$:.;export PATH  

• • Melden Sie sich ab und wieder an 

• • <tomcat-Basisverzeichnis>\bin\startup.sh ausführen (zum Beenden shutdown.sh ). 

Das Terminal-Fenster zeigt den Port an, auf dem Tomcat läuft, z.B. 8080; um die Engine zu testen, kann man einen Webbrowser (zur Not auch lynx ) starten und die Seite http://localhost:8080/ ... aufrufen.

•  Testen, ob der SuperX-Kontext unter Tomcat verfügbar ist:
  http://localhost:8080/superx/  

•  Testen, ob Sie sich auf der SuperX-Datenbank anmelden können
  http://localhost:8080/superx/xml/  

•  Testen, ob das Applet läuft
  http://localhost:8080/superx/applet/  

Beendet wird Tomcat mit dem Befehl: shutdown.bat für MS-DOS bzw. shutdown.sh für UNIX.

• •  

2.1.5.2.7 Die Übertragung der Web Application

  Wenn Sie die SuperX-Webapplikation auf einem vorhandenen Tomcat installieren wollen, folgen Sie dem Leitfaden auf der Seite

http://www.superx-projekt.de/doku/kern_modul/tomcat/f_TomcatausLinuxDistributionen.htm

2.1.5.2.8 SuperX Webanwendung in 2 Instanzen Ubuntu

Um eine weitere Tomcat-Instanz starten zu können (z.B. für ein Testsystem) müssen folgende Schritte getan werden:

1. 1. mkdir /var/lib/tomcat8-test 

2. 2. cd /var/lib/tomcat8-test 

3. 3. mkdir conf temp webapps work logs 

4. 4. cd .. 

5. 5. chown -R tomcat8:tomcat8 tomcat8-test 

6. 6. ln- s /var/lib/tomcat8/conf/catalina.properties /var/lib/tomcat8-test/conf 

7. 7. ln- s /var/lib/tomcat8/conf/web.xml /var/lib/tomcat8-test/conf 

8. 8. ln- s /var/lib/tomcat8/conf/policy.d/ /var/lib/tomcat8-test/conf 

9. 9. cp /var/lib/tomcat8/conf/server.xml /var/lib/tomcat8-test/conf/ 

10. 10. In der /var/lib/tomcat8-test/conf/server.xml alle Ports ändern. Diese dürfen nicht gleich sein. 

11. 11. cd /etc/init.d/ 

12. 12. cp tomcat8 tomcat8-test 

13. 13. vi tomvat8-test  

14. 14. Ändern nach: # Provides:           tomcat8-test 

15. 15. Ändern nach: NAME=tomcat8-test  

16. 16. Ändern nach: DESC="Tomcat servlet engine SuperX"  

17. 17. Ändern nach: CATALINA_HOME=/usr/share/tomcat8  

18. 18. Abspeichern mit wq 

19. 19. systemctl daemon-reload 

20. 20. Nun kann die neue Tomcat Instanz verwendet werden. 

2.1.5.2.9 Der Webanwendung Manager

Mit dem Webanwendung- Manager kann man verschiedene Einstellungen und Protokolle aufrufen vornehmen.

Es kann bei Administrationsrechten aufgerufen werden im Menü Standardberichte:

 

oder direkt unter der Adresse:

http://rechnername:port/superx/edit/kern/webapp_manager.jsp

Hier ein Screenshot vom Kernmodul 4.9:

 

2.1.5.2.9.1 Server-Cache

SuperX cacht zur Performanceverbesserung einige Dinge im Webserver, dazu gehören Erläuterungen und Übersetzungen und für's   XML-Frontend auch: User, Userrechte und Sichten und auch Abfragen wenn in der db.properties eingetragen.

Falls Sie bei Entwicklungsarbeiten Änderungen an diesen Dingen gemacht haben und im XML-Frontend arbeiten, müssen   Sie einmal den "Server-Cache aktualisieren".

 

Hinweis: Neue Sichten können z.B. auch durch ein Update der KLR -Daten erfolgen, wenn neue alternative Hierarchien dazukommen.

2.1.5.2.9.2 Logging von Maskenaufrufen

Im Webanwendung Manager werden verschiedene SQL/XML-Loginformationen für Support- oder Entwicklungszwecke angezeigt. Dies befindet sich im Menü "Masken":

 

Sie können jeweils den Aufruf der letzten Maske anschauen, oder den SQL-Quellcode der Maske. Wenn die Maske Freemarker nutzt, können Sie zwischen dem Quellcode vor..

 

...und nach der Freemarker Transformation wählen:

 

Außerdem können Sie das XML-Ergebnis der Maske aufrufen, hier allerdings nur max. 30 Zeilen.

 

Den XML können Sie lokal speichern und z.B. mit JasperReports weiterverarbeiten, siehe unser JR-Handbuch .

2.1.5.2.10 Verbesserung der Performance

Die Tomcat-Performance läßt sich durch Zuweisung von mehr RAM steigern. Dazu muss lediglich die Umgebungsvariable JAVA_OPTS gesetzt werden, z.B. mit
JAVA_OPTS= "-Xmx300M -Djava.awt.headless=true"
export JAVA_OPTS

Hierdurch werden 300 MB RAM dem Tomcat zugewiesen. Die Umgebungsvariable wird außerdem auch von diversen SuperX-jdbc-Clients berücksichtigt. Dies ist z.B. sinnvoll, wenn größere Tabellen be- oder entladen werden. Der Passus " -Djava.awt.headless=true" muss immer dabei sein, wenn Tomcat auf einem UNIX-System ohne graphische Konsole aus aufgerufen wird.

Die Performance von Tomcat läßt sich weiterhin durch den Lastausgleich in Kombination mit dem Apache Webserver steigern. Beim Tomcat 3.2.x Die Konfiguration wird in der Datei conf/workers.properties vorgenommen.

Die bereits vorhandenen Beispieleinträge sollten die Konfiguration des Lastausgleich erläutern. Weitere Details zur workers.properties finden Sie in der Anleitung zur Anbindung an den Apache . Die verschiedenen Howtos in der Tomcat-Distribution erläutern Details zur Apache-Anbindung.

2.1.5.2.11 Einrichtung einer SSL-Verbindung in Tomcat

Wenn Tomcat mit einer SSL-Verschlüsselung arbeiten soll, dann sollte von vornherein das JDK 1.4.x oder höher installiert werden, weil dies die notwendigen Bibliotheken dazu enthält.   Es gibt ferner die Möglichkeit, die Verschlüsselung vom Webserver (Apache oder IIS) vornehmen zu lassen (siehe unten oder Tomcat-Dokumentation in tomcat-docs/tomcat-ssl-howto.htm). Im folgenden eine Anleitung, wenn kein öffentlich bekanntes und signiertes Zertifikat genutzt werden soll. Große Teile wurden übernommen aus der Tomcat Dokumentation "ssl-howto.html".

Erzeugen Sie zunächst auf dem Applikationsserver einen Keystore mit dem Befehl

Die Parameter werden erfragt; wichtig ist, dass der erste Eintrag (Vor- und Nachname, COMMON NAME CN) der DNS-Name des Werbservers ist, z.B. superx.verwaltung.uni-duisburg.de . Als Passwort geben Sie beide Male z.B. "changeit" an (das ist nur ein Beispielpasswort für die Dokumentation, natürlich sollten Sie das Passwort ändern). Daraufhin wird ein Zertifikat erzeugt und in der Datei .keystore im Homeverzeichnis des Benutzers angelegt (unter Windows im Profiles-Verzeichnis, unter UNIX im home-Verzeichnis).

Das persönliche Zertifikat können Sie durch einen kommerziellen Zertifizierungsserver publizieren; zu Testzwecken können Sie auch ein selbsterstelltes Zertifikat erzeugen:

keytool -selfcert -alias tomcat -validity <<Anzahl der Tage>>

Danach ändern Sie die Datei $TOMCAT_HOME/conf/server.xml , indem Sie die Passage mit der SSL-Verschlüsselung (z.B. 8443) ent-kommentieren und den normalen Port (8080) auskommentieren.

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"

                maxThreads="150" scheme="https" secure="true"

                clientAuth="false" sslProtocol="TLS"

keystorePass="changeit" keystoreFile="/home/superx/.keystore"

/>

Danach ist die Webanwendung über https://localhost:8443 statt http://localhost:8080 erreichbar. Sie müssen alle Links entsprechend ändern und, wenn Sie auch das Applet nutzen, in der Datei superx.properties die Zeile

Das Zertifikat können Sie löschen, indem Sie auf der Kommandozeile eingeben:

keytool -delete -alias tomcat

2.1.5.2.11.1 Signierung eines Zertifikats in Tomcat

1. 1. public key + private key erzeugen und die im keystore-file ablegen
   (der private key wird dabei mit passwd verschlüsselt):
   keytool -genkey -keyalg RSA -alias tomcat -keystore xxx.jks  

2. 2. certificate request generieren --> Datei server.csr und an die CA schicken:
   keytool -certreq -keyalg RSA -file server.csr -keystore xxx.jks  

3. 3. Den von der CA signierten public key = Serverzertifikat
   zurückbekommen --> Datei server.cer  

4. 4. Zuerst das Zertifikat der CA (z.B. UTN-USERFirst-Network Applications, http://www.usertrust.com) downloaden und in den keystore einspielen:
   keytool -import -file UTN.cer -alias tomcat -keystore xxx.jks  

5. 5. Dann das neue Serverzertifikat in den keystore einspielen:
   keytool -import -file server.cer -alias tomcat -keystore xxx.jks  

6. 6. in der Tomcat-server.xml auf die keystore-Datei verweisen:
   keystoreFile="<<Pfad zur xxx.jks-Datei>>" keystorePass="passwd"
   Wichtig: dasselbe passwd einsetzen wie unter 1. zum Verschlüsseln
   des private key benutzt wurde 

7. 7. Restart Tomcat 

8. 8. https-Verbindung zum Server, Zertifikat überprüfen - vertrauenswürdig? 

2.1.5.2.12 Zusätzliche Verschlüsselung im Applet durch Public-Private-Key-Kontrolle

Zur Erhöhung der Sicherheit im SuperX-Applet ist es möglich, eine DSA-public/private-Key-Kontrolle zu installieren. Dabei wird jeder SQL-Befehl, der vom Applet ans Servlet geschickt wird, mit dem einen Key signiert und im Servlet wird mit Hilfe des anderen, nur dort bekannten Keys kontrolliert, ob der ankommende SQL eine gültige Signatur aufweist.

Zur Installation eines zufällig erzeugten Key-Paars brauchen Sie auf dem Datenbankserver in der Shell nur die SQL_ENV aufzurufen und anschließend das Kommando
sx_keymanager.x install abzuschicken. Mit sx_keymanager.x delete könnten Sie ggfs. das Schlüsselpaar wieder entfernen und mit sx_keymanager.x check prüfen, ob ein Schlüsselpaar installiert ist. Wenn Sie Tomcat auf einem separaten Rechner betreiben, brauchen Sie hier kein Script ausführen, es recht, dort das jeweilige Kernmodul-Paket zu entpacken. Bei mandantenfähigen Installationen müssen Sie das Script sx_keymanager.x install   für jeden Mandanten einzeln ausführen.

Wenn Sie Tomcat neu starten, können Sie in den Logdateien (normalerweise $SUPERX_DIR/webserver/tomcat/logs/catalina.out ) kontrollieren, ob die public/private key Kontrolle aktiv ist oder nicht.

Nach der Meldung zum Aufbau des Datenbank-Connectionpools kommt ein einsprechender Hinweis.

Aufbau des ConnectionPool (....)   .. OK

            public/private key aktiv

Im SuperX-Applet können Sie den Info-Button anklicken, in der erscheinenden Infobox wird angegeben, ob public/private key Kontrolle aktiv ist oder nicht.

2.1.5.2.13 Tomcat als Dienst unter Linux

Die Implementation von Tomcat als Dienst ist unverzichtbar, damit der Serve rbeim Hochfahren automatisch startet. Wir haben Konfigurationsscripte und Startscripte mitgeliefert, die Sie recht leicht anpassen können.

Im Verzeichnis $SUPERX_DIR/webserver/etc befinden sich Musterdateien, um einen Dienst unter SUSE oder RedHat Linux daraus zu machen. Kopieren Sie die Inhalte des Verzeichnisses etc als root auf den Webserver ins Verzeichnis /etc , und passen Sie /etc/sysconfig/superx_webserver entsprechend Ihrer Umgebung an. Schließlich muss ein symbolischer Link von /etc/init.d/superx_webserver nach (usr)/bin/rcsuperx _webserver gelegt werden.:

ln -symbolic /etc/init.d/superx_webserver   /bin/rcsuperx_webserver

Danach kann man den Dienst im Runlevel-Editor des YAST aktivieren (Runlevel 3 und 5). Der Dienst muss vor dem Webserver, aber nach dem Start des Datenbankservers gestartet werden. Der Dienst selbst wird vom User superx gestartet, und kann jederzeit mit
rcsuperx_webserver restart
neu gestartet werden.

Unter RedHat Linux gibt es ebenfalls Werkzeuge für die Einrichtung der Runlevel, ggf. kann man auch manuell symbolische Links einrichten, wie beim Start des Datenbankservers beschrieben . Außerdem muss ggf. die Umgebung vor dem Start des Tomcat geladen werden, z.B. durch Aufruf der SQL_ENV. Wichtig ist, dass beim Start des Tomcat als Dienst die Variable JAVA_HOME korrekt gesetzt ist und die Variable LANG auf eine deutsche Locale zeigt. Letzteres ist bei RedHat nicht standardmäßig vorgesehen.

Die Einrichtung des Tomcat als Dienst ist auch für Windows-Server möglich, wie im folgenden gezeigt wird.

2.1.5.2.14 Tomcat als Dienst unter Windows einrichten (nur WINNT/2000 und Tomcat 3.x)

Tomcat muss auf Windown-NT/2000-Rechnern nicht in einer DOS-Box laufen, sondern kann auch als Dienst laufen. Die Installer von Tomcat 7 sehen unter Windows NT /2000/XP eine Installation als Dienst vor.

Unter NT 4 läuft der Tomcat-Dienst nur mit dem JDK 1.6.x, unter Win2000 sollte man Java JDK 1.6.x oder höher installieren. Die Variable JAVA_HOME zeigt dann auf dieses Verzeichnis. Für die Einrichtung muss man bei Windows folgendes machen:

• • In der   Datei d:\superx\webserver\tomcat\conf\wrapper.properties öffnen und Tomcat_home und   Java_Home auf den richtigen Pfad setzen 

• • Man fügt der Computerverwaltung Tomcat als Dienst hinzu, indem man in einer DosBox vom <tomcat>/bin -Verzeichnis aus " jk_nt_service –I tomcat ..\conf\wrapper.properties " ausführt.  

• • Dann kann man den Dienst über die Systemsteuerung -> Dienste starten (besser: auf automatisch setzen), und theoretisch läuft Tomcat auch dann, wenn kein User auf dem Rechner angemeldet ist. Aus der DOS-Box kann man den Dienst auch mit net start tomcat starten. 

• • Die Deinstallation des Dienstes erfolgt über jk_nt_service –R tomcat  

Der Dienst wird in der Systemsteuerung des Rechners aufgeführt, und das Ergebnis sieht unter Win2000 wie folgt aus:

Rechts sehen Sie die Eigenschaften des tomcat-Dienstes unter NT-Server. Bei dem Starttyp können Sie automatisch wählen, und die weiteren Registerkarten sind nicht gefüllt. Der Dienst lässt sich mit den Start/ Unterbrechungsbuttons manuell neu starten:

2.1.5.2.15 Steuerung für das Applet: Die superx.properties

Das SuperX-Applet greift u.a. auf eine Datei superx.properties zu , um zu erfahren, mit welchem Datenbanksystem gearbeitet wird (Informix/Postgres).

Für diese Datei gibt es im Kernmodul ein Muster

$SUPERX_DIR/webserver/tomcat/webapps/superx/applet/superx.properties.sam

  das Sie nach superx.properties kopieren und wie folgt anpassen:

Die Adresse des Servlets wird normalerweise automatisch ermittelt, bei Netzwerkproblemen kann sie jedoch auch fest angegeben werden, dazu # vor SxServerURL entfernen und localhost ggfs. durch IP-Nummer/Rechnername ersetzen.

In der SuperX-Properties wird außerdem das Datenbanksystem (Variable SxDB ) festgelegt, sowie das Logging (Variable logToKonsole ). Bei der Installation von SuperX sollten Sie das Logging auf "all" setzen, im Echtbetrieb sollten Sie das Logging wie beim Servlet auf "none" setzen.

Wenn der Webserver mehrere Mandanten in unterschiedlichen Datenbank bedient, muss es für jeden Mandanten eine superx.properties geben, die den zusätzlichen Parameter MandantenID enthält, z.B.

MandantenID=7200 (vergl. entsprechendes Kapitel).

Schließlich muss man noch darauf achten, dass ggfs. der Tomcat-Port in der Firewall (standardmäßig Port 8080, evtl. noch 8007 und 8443) freigegeben ist.

Die Homepage von SuperX liegt standardmäßig unter
http://<IP-Nummer des Servers>:8080/superx/

2.1.5.2.16 Steuerung des XML-Frontends : PageComponents

Das XML-Frontend generiert aus XML-Datenströmen die Oberfläche im html-Format. So lässt sich die Oberfläche von SuperX beliebig mit XSLT anpassen, Details dazu finden Sie im SuperX-Entwicklerhandbuch.

Das XML-Frontend mit DHTML-Techniken erlaubt es, wahlweise den Themenbaum als Javascript-"Baum" anzuzeigen (SuperX Kernmodul ab Version 3.0rc7-3.5rc2) oder als normales html-Menü (SuperX Kernmodul bis Version 3.0rc6 oder ab Version 4.0). Wenn der Javascript-Baum nicht genutzt werden soll, kann dieser wie folgt ein/ausgeschaltet werden:

Nach einem Tomcat-Neustart wird das html-Menü angezeigt.

Analog können Sie das Javascript-Menü einschalten:

Aktivierung des Javascript-Baums

Editieren Sie die Datei $SUPERX_DIR/webserver/tomcat/webapps/superx/xml/pageComponents_html_final.xsl und setzen Sie folgende Anweisung aktiv: <xsl:template name="showJavascriptMenue" > <xsl:text>true</xsl:text> </xsl:template>

Aktivierung der Links zu den Masken im   Javascript-Baum

Wenn Sie darüber hinaus auch wollen, dass nicht nur die Themen, sondern auch die Masken im linken Menü angezeigt werden, setzen Sie eine weitere Variable auf "true": <xsl:template name="showThemenbaumMask" > <xsl:text>true</xsl:text> </xsl:template> Damit erscheinen Links auch die Masken.

Viele Hochschulen, die SuperX mit LDAP-Anmeldung nutzen oder anderweitig konfigurieren, wollen weitere Steuerungmöglichkeiten über das Aussehen des Menüframes nutzen. Sie können auch steuern, wie der Fuss des linken Navigationsframes aussehen soll; standardmäßig werden folgende Links angezeigt:

Hyperlinks unter dem Themenbaum

Editieren Sie Ihre Datei " pageComponents_html_final.xsl ":

Fügen Sie die folgenden Einträge in pageComponents_html_final.xsl vor dem Tag am Ende </xsl:stylesheet> ein:

Sie können unter diesem Bereich noch weitere HTML-Elemente einbauen. Dafür gibt es ein in der Auslieferung von SuperX befindliches leeres Template menue_fuss :

Sie können auch weitere Templates bearbeiten und Manipulieren, indem sie ein Template aus einer vorhandenen XSL Datei kopieren und in die pageComponents_html_final.xsl kopieren. Dadurch wird Ihr template bevorzugt. Sie können dann den Inhalt erweitern, kürzen oder ändern. Wenn Sie z.B. den Breadcrumb ausblenden möchten kopieren Sie einfach das template des Breadcrumbs und leeren die Ausgabe:

Dies können Sie in pageComponents_html_final.xsl   mit beliebigen Elementen füllen.

2.1.5.2.17 Einrichtung des Webservers bei mehreren Mandanten.

Wenn die Servlet-Engine mehrere SuperX-Mandanten in unterschiedlichen Datenbanken bedienen soll, muss es unter $SUPERX_DIR/webserver/tomcat/webapps/superx/WEB_INF eine Datei mandanten.cfg geben.

Darin müssen die MandantenIDs (typischerweise Hochschulnummern) der einzelnen Mandanten aufgeführt sein. (Jeweils eine ID pro Zeile). Zusätzlich muss es dann nicht eine db.properties geben, sondern für jeden Mandanten eine nach dem Schema db_XXXX.properties, wobei XXXX für die MandantenID steht.

propadmin.x ./db_XXXX.properties.

Nach dem Start von Tomcat können Sie in den Logdateien (meist catalina.out oder localhost.log) kontrollieren, ob für jeden Mandanten ein Datenbank-ConnectionPool aufgebaut wurde.

Unter $SUPERX_DIR/webserver/tomcat/webapps/superx sollte es für jeden Mandanten ein Unterverzeichnis mit dem Namen der MandantenID geben.

z.B.

$SUPERX_DIR/webserver/tomcat/webapps/superx/7200

$SUPERX_DIR/webserver/tomcat/webapps/superx/7300

$SUPERX_DIR/webserver/tomcat/webapps/superx/7400

In jedes der Mandantenunterverzeichnisse muss eine Datei index.htm reinkopiert werden, die die Mandantid übergibt. Der Inhalt z.B.

<html lang="de" xml:lang="de"><head>

<META http-equiv="Content-Type" content="text/html; charset=UTF-8" />

<meta http-equiv="refresh" content="0; URL=../index.jsp?MandantenID=7200" />

<LINK href="/kompass/style/superx.css" type="text/css" REL="stylesheet" />

</head>

<body>

<p align="center">Diese Seite ist umgezogen. Wenn Sie nicht automatisch weitergeleitet werden, klicken Sie <a href="../index.jsp?MandantenID=7200">hier</a></p>

</body>

</html>

Die einzelnen Mandanten können SuperX dann mit der Url

http://rechnername:8080/superx/MANDANTENID

aufrufen, z.B.

http://www.plgr-bw.de:8080/superx/7200

In der web.xml sollte bei einem Mandantensystem bei SuperXmlAbmeldung der init-param mit alt_redirect_url gelöscht werden.Ansonsten wird der MandantenPfad nicht beachtet. Der Pfad weist dann relativ zum Verzeichnis ohne Mandantenbetrieb.

Wenn bestimmte Mandanten das Upload-Servlet zum Hochladen von Dateien per Browser nutzen sollen, muss die web.xml angepasst werden, siehe dazu im Abschnitt zu Upload-Funktion den Punkt Anpassung der web.xml

2.1.5.2.18 Einrichtung von DBFORMS bei mehreren Mandanten

Im Mandantenbetrieb   müssen die Datenbankverbindungen in zwei Steuerungsdateien eingetragen werden: der db_*.properties für die Datenbankverbindung, und der dbforms-config.xml für die dbforms-Anbindung bzw. Saiku .. Nehmen wir an wir haben zwei Mandanten mit dem Kürzel

Diese Datenquellen müssen dann wie im Abschnitt zu dbforms erläutert in der Datei $SUPERX_DIR/webserver/tomcat/webapps/superx/WEB-INF/dbforms-config.xml beim Tag <dbConnection …/> eingetragen werden:

Wichtig ist, dass die Mandanten-ID mit der in der mandanten.cfg (s.o.) übereinstimmt.

2.1.5.2.19 Einrichtung Saiku bei mehreren Mandanten

Wenn die Konfiguration der Standardberichte wie oben beschrieben erfolgreich war, kann man auch Saiku für den Mandantenbetrieb vorbereiten. Löschen Sie dazu die Datei

$SUPERX_DIR/webserver/tomcat/webapps/superx/WEB-INF/classes/saiku-datasources/edustore

und fügen Sie im gleichen Verzeichnis für jeden Mandanten eine Datei mit beliebigem Dateinamen, z.B. 7200 hinzu, mit folgendem Inhalt:

type=OLAP

name=7200

driver=mondrian.olap4j.MondrianOlap4jDriver

location=jdbc:mondrian:Jdbc=jdbc:apache:commons:dbcp:7200;Catalog=res:edustore/edustore.xml;JdbcDrivers=org.apache.commons.dbcp.PoolingDriver;DynamicSchemaProcessor=de.superx.saiku.schema.SimpleSchemaProcessor

security.enabled=true

security.type=superx

Danach starten Sie Tomcat neu.

2.1.5.3 LDAP Anbindung

Es ist möglich, die Authentifizierung von Usern über eine LDAP-Datenbank laufen zu lassen.

Die User müssen aber auf jeden Fall in SuperX auch existieren und entsprechende Gruppenzugehörigkeiten und Rechteeinstellungen haben (Tabellen userinfo, groupinfo, user_group_bez, user_masken_bez,group_masken_bez,user_sachgeb_bez,group_sachgeb_bez, user_sichten etc).

2.1.5.3.1 ggfs. Zertifikat einspielen

Falls Sie ein eigenes Zertifikat für die Verschlüsselung Ihres LDAP-Servers einsetzen, muss dies

importiert werden in die Java Runtime.

Danach müssen Sie das Zertifikat auch Tomcat bzw. der JVM bekannt machen, die Tomcat startet. Erweitern Sie die Umgebungsvariable CATALINA_OPTS um den Parameter:

-Djavax.net.ssl.trustStore=<<Pfad zu den>>/cacerts

also z.B.

-Djavax.net.ssl.trustStore=/usr/local/tomcat/conf/cacerts

2.1.5.3.2 Anpassen der superx_ldap.properties

Kopieren Sie die Datei superx/WEB-INF/superx _standalone_ ldap.properties.sam nach superx_standalone_ldap.properties und bearbeiten Sie diese – wenn SuperX beim Serverstart diese Datei findet, wird eine neue SuperX-interne LDAP-Passwortkontrolle aktiviert.
Sie finden auch in der catalina.out einen Hinweis „Passwortkontrolle via LDAP wird aktiviert“. D.h. es wird nicht mehr auf die Tomcat eigene LDAP security-Technik gesetzt wie bis Kern4.8, da dies nicht kompatibel mit der neuen Spring-Technik ist.

In der sam-Datei ist eine   Verbindung zu einem öffentlichen LDAP-Testserver vorkonfiguriert. Dort gibt es einen User „einstein“ mit Passwort „password. Wenn Sie in SuperX einen User „einstein“ anlegen und ein anderes Passwort wie „albert“, können Sie sich nach einer Aktivierung von LDAP mit „einstein“ und „password“ anmelden.

# SuperX LDAP Konfiguration für Passwortkontrolle

#Falls SuperX standalone betrieben wird, können hier LDAP Parameter hinterlegt werden

# Beispielparameter verwenden

#     https://www.forumsys.com/tutorials/integration-how-to/ldap/online-ldap-test-server/

# Beispieluser auf diesem System einstein Passwort=password

#   Wenn Sie in Superx einen User mit Kennung einstein anlegen, können Sie die Anmeldung via LDAP # testen

LdapUrl=ldap://ldap.forumsys.com:389

#

#Base Definition für die LDAP Suche, kann ggfs. um Gruppen erweitert werden, wie
# ou=superx_user,dc=example,dc=com

LdapBase=dc=example,dc=com

#

#Falls für den LDAP Zugriff ein ServiceUser (mit eigenem Passwort) benötigt wird, kann dies hier angegeben werden

#LdapServiceUserDN=cn=read-only-admin,dc=example,dc=com

#LdapServiceUserPassword=password

#

#

#

# Identifiying Attribute mit dem ein User mittels seiner Kennung gefunden wird (z.B. uid)

#   z.B. bei Suchstring uid={0} einfach nur uid

# (ein komplexer Suchstring ist derzeit nicht möglich, passen Sie ggfs. die LdapBase-Definition an
#oder kontaktieren Sie uns unter support@superx-projekt.de

LdapIdentifyingAttribute=uid

Die alte Technik findet sich im Anhang im Kapitel „LDAP Konfiguration vor Kern 5.0“.

Passwortänderung : Falls ein Benutzer in SuperX dazu aufgefordert wird sein Passwort zu ändern, muss die Konstante „Passwortgültigkeit (Tage)“ angepasst werden. Diese Konstante dazu einfach auf einen möglichst hohen Wert setzen wie z.B. „1000000“. Danach noch die Tabelle user_pw leeren (alle Datensätze löschen).

2.1.5.4 Integration von Tomcat mit dem Apache

Dieses Kapitel ist umgezogen:

http://www.superx-projekt.de/doku/kern_modul/tomcat/f_ApacheAnbindung.htm

2.1.5.4.1 Einrichten von SSL beim Apache 1.3.x unter Linux

Wenn Sie Apache2 einsetzen, blättern Sie bitte weiter .

  Mit Hilfe des Openssl-Paketes sowie können Schlüssel für den Server erzeugt werden. Im Folgenden erläutern wir das Vorgehen unter SuSE Linux 8-9, für andere Distributionen müssen Sie ggf. die Verzeichnisnamen anpassen. Für die Installation verwenden wir zunächst ein selbst signiertes Zertifikat, was zwar den Nachteil hat, dass die Anwender vor dem Aufruf der Webseite eine Warnung erhalten ("Diese Seite stammt aus einer nicht vertrauenswürdigen Quelle..."), der Vorteil ist aber, dass das Vorgehen relativ einheitlich ist und später bei Bedarf leicht um ein öffentliches Zertifikat erweitert werden kann. Wenn die Verschlüsselung mit einem selbst signierten Zertifikat funktioniert, dann ist der Rest relativ einfach.

Wir führen alle Schritte als user root durch, und gehen z.B. davon aus, dass wir uns im Verzeichnis /root befinden.

Zunächst muss ein Zertifikat erzeugt werden.
Wenn Sie Ihr Zertifikat bei einer Zertifizierungstelle signieren lassen möchten, müssen eine Zertifizierungsanfrage erstellen.

Mit dem oben erstellten CA-Zertifikat können Sie Ihr http-Zertifikat folgendermaßen selbst signieren:

/usr/share/ssl/misc/CA.sh -sign

Es wird eine Datei newcert.pem erzeugt. Nachdem Sie nun ein signiertes Zertifikat für Ihre Anwendung erstellt haben, müssen Sie dieses nur noch in das entsprechende Verzeichnis kopieren und in der Konfigurationsdatei eintragen. Der Apache erwartet den privaten Schlüssel in einer separaten Datei, in solchen Fällen können Sie den privaten Schlüssel wie folgt extrahieren

openssl rsa -in newreq.pem -out newkey.pem

Nun bereiten wir den Neustart des Apache mit ssl-Modul vor. Die Einbindung mit Loadmodule und AddModule muss bei den meisten Distributionen nicht manuell gemacht werden.

Im Apache muss nun in der Steuerungsdatei httpd.conf der Pfad zum privaten und öffentlichen Schlüssel angegeben werden.   Das folgende Beispiel geht davon aus, dass der öffentliche CA-Schlüssel auf der Website des Users superx (Modul public_html des Apache) unter /home/superx/public_html steht, und dass der private Schlüssel des Servers vom User root im Verzeichnis /root/demoCA erzeugt wurde.

Danach müssen Sie in /etc/sysconfig/apache die Systemvariable HTTPD_START_TIMEOUT auf einen sinnvollen Wert setzen, z.B. 10. Sie haben dann beim Start des Apache 10 Sek. Zeit, dass CA-Passwort einzugeben.

Wir geben als root im Verzeichnis /root/demoCA/private ein:

openssl rsa -in cakey.pem -out cakey2.pem

(1x mit der Passphrase bestätigen).

Dann wird ein Schlüssel ohne Passphrase erzeugt. Wenn wir diesen dann wiederum in /etc/httpd/httpd.conf eintragen:

  #SSLCertificateKeyFile /root/demoCA/private/cakey.pem

  SSLCertificateKeyFile /root/demoCA/private/cakey2.pem

Dann startet der Apache ohne Passwortabfrage. In diesem Fall kann man auch die Variable HTTPD_START_TIMEOUT auf 1 zurücksetzen.

Zum Abschluss können Sie bei einem selbst signierten Zertifikat die oben erstellte Datei /root/capub.crt auf den Webserver kopieren und mit folgendem Link auf Ihrer Webseite verfügbar machen:

<a href="capub.crt" type="application/x-x509-ca-cert">CA-Zertifikat</a>

Die Anwender können dann mit Klick auf Link das Zertifikat importieren und somit im Browser speichern, so dass die Warnung, dass die Quelle nicht vertrauenswürdig ist, nicht mehr kommt. Wir haben auch den Eindruck, dass das Applet dann schneller arbeitet.

2.1.5.4.2 Einrichten von SSL beim Apache 2.x unter SuSE Linux

Das Modul ssl ist im Apache 2.x nicht mehr separat zu installieren, sondern bereits im Lieferumfang enthalten, das Modul muss nur in den entsprechenden LoadModule und Include-Abschnitten geladen werden.

Wir führen alle Schritte als user root durch, und gehen z.B. davon aus, dass wir uns im Verzeichnis /root befinden.

Zunächst muss ein Zertifikat erzeugt werden. Das öffentliche CA-Zertifikat liegt z.B. in /root/demoCA/cacert.pem und der private Schlüssel liegt in /root/demoCA/private/cakey.pem ..

Nun werden die Schlüssel dem Apache2 bekannt gemacht. Die einzelnen Konfigurationsparameter werden bei SuSE Linux über die Sysconfig gesetzt:

Bei anderen Linux-Distributionen entfällt die sysconfig .   Auch unabhängig von der Distribution wird beim Apache2   nicht mehr die gesamte Konfiguration in einer großen httpd.conf gesammelt, sondern   in separaten conf -Dateien. Bei virtuellen Hosts zum Beispiel befinden sich die Konfigurationen in Dateien mit der Endung *.conf im Verzeichnis vhosts.d . Der Startpunkt ist aber immer die httpd.conf (standardmäßig in /etc/apache2 ).

Wenn Sie keine Virtual Hosts nutzen, dann können Sie den Abschnitt, der im Konfigurationsbeispiel /etc/apache2/vhosts.d/vhost-ssl.template beschrieben ist auch in der Datei /etc/apache2/default-server.conf einfügen:

Danach müssen Sie in /etc/sysconfig/apache2 die Systemvariable HTTPD_START_TIMEOUT auf einen sinnvollen Wert setzen, z.B. 10. Danach wie immer SuSEconfig ausführen.

Sie haben dann beim Start des Apache 10 Sek. Zeit, dass CA-Passwort einzugeben.

Wir geben als root im Verzeichnis /root/demoCA/private ein:

openssl rsa -in cakey.pem -out cakey2.pem

(1x mit der Passphrase bestätigen).

Dann wird ein Schlüssel ohne Passphrase erzeugt. Wenn wir diesen dann wiederum in /etc/httpd/httpd.conf eintragen:

  #SSLCertificateKeyFile /root/demoCA/private/cakey.pem

  SSLCertificateKeyFile /root/demoCA/private/cakey2.pem

Dann startet der Apache ohne Passwortabfrage. In diesem Fall kann man auch die Variable HTTPD_START_TIMEOUT auf 1 zurücksetzen.

Wenn Sie Ihren Besuchern das öffentliche CA-Zertifikat zum Download anbieten möchten, müssen Sie dieses zuerst in das entsprechende DER-Format konvertieren:

openssl x509 -in demoCA/cacert.pem -out capub.crt -outform DER

Es wird die Datei /root/capub.crt erzeugt. Auf diese Datei wird in der Apache-Variable SSLCertificateFile   verwiesen (statt wie oben auf /root/demoCA/cacert.pem)

Wenn Sie Ihr Zertifikat bei einer Zertifizierungstelle signieren lassen möchten, müssen eine Zertifizierungsanfrage erstellen.

Mit dem oben erstellten CA-Zertifikat können Sie Ihr http-Zertifikat folgendermaßen selbst signieren:

/usr/share/ssl/misc/CA.sh -sign

Es wird eine Datei newcert.pem erzeugt. Nachdem Sie nun ein signiertes Zertifikat für Ihre Anwendung erstellt haben, müssen Sie dieses nur noch in das entsprechende Verzeichnis kopieren und in der Konfigu rationsdatei eintragen. Der Apache erwartet den privaten Schlüssel in einer separaten Datei, in solchen Fällen können Sie den privaten Schlüssel wie folgt extrahieren

openssl rsa -in newreq.pem -out newkey.pem

2.1.5.4.3 Einrichten von SSL beim Apache 2.x unter Ubuntu Linux

Zunächst erzeugen Sie ein Zertifikat :

mkdir /etc/apache2/ssl

openssl req -x509 -nodes -days 1095 -newkey rsa:2048 -out /etc/apache2/ssl/server.crt -keyout /etc/apache2/ssl/server.key

Das Zertifikat binden Sie in der conf-Datei ein, defaultmäßig /etc/apache2/sites-enabled/000-default.conf :

<IfModule mod_ssl.c>

<VirtualHost _default_:443>

ServerAdmin webmaster@localhost

DocumentRoot /var/www/html

ErrorLog ${APACHE_LOG_DIR}/error.log

CustomLog ${APACHE_LOG_DIR}/access.log combined

SSLEngine on

SSLCertificateFile /etc/apache2/ssl/server.crt

SSLCertificateKeyFile /etc/apache2/ssl/server.key

</VirtualHost>

</IfModule>

Danach aktivieren Sie SSL mit

a2enmod ssl

Sie können unter Ubuntu auch den Apache ssl-virtual host aktivieren

a2ensite default-ssl.conf

Dann können Sie den Port 80 auf den Port 443 umleiten:

<VirtualHost *:80>

ServerName superx-cloud.de

ServerAlias   www.superx-cloud.de

Redirect / https://www.superx-cloud.de/

...

</VirtualHost>

<IfModule mod_ssl.c>

<VirtualHost *:443>

ServerAlias   www.superx-cloud.de

ServerName superx-cloud.de

...

  </VirtualHost>

</IfModule>
Und dann starten Sie Apache neu mit

/etc/init.d/apache2 restart

2.1.5.4.4 Zertifikate mit Let's encrypt

Mit ACME unter Linux lassen sich Zertifikate von der Initiative Let's encrypt signieren lassen. Die Zertifikate sind 3 Monate gültig, und haben eine eingebaute automatische Verlängerung implementieren. Gehen Sie dazu wie folgt vor:

Clonen Sie das Projekt von GitHub:

git clone https://github.com/Neilpang/acme.sh.git

Es wird ein Verzeichnis "acme.sh" erzeugt, mit dem Script "acme.sh". Dieses kopieren Sie als User root auf den Server, z.B. nach /root.
apt-get install socat

Dann installieren Sie den cronjob zum Aktualisieren:

./acme.sh --install

Der Cronjob prüft jede Nacht um 0:44 Uhr, ob das Zertifikat abgelaufen ist, wenn nicht wird es erneuert. Danach müssen Sie die Shell neu öffnen, und bei zerossl registrieren:

./acme.sh   --register-account   -m git@superx-cloud.de --server zerossl

Dann erzeugen Sie die Zertifikatsdateien, am Beispiel der Domain "superx-cloud.de" auf einem Ubuntu-Apache, d.h. documentRoot ist /var/www/html :

./acme.sh --issue -d superx-cloud.de -w /var/www/html

Voraussetzung ist das Apache auf Port 80 läuft und die Firewall auf Port 80 frei ist (iptables).

Dann installieren Sie die Dateien in den A p ache, die Beispielverzeichnisse stammen aus der Ubuntu-Apache-Installation. Ggf. müssen Sie das Verzeichnis / etc/apache2/ssl noch erzeugen.

mkdir -p /etc/apache2/ssl

./acme.sh --install-cert -d superx-cloud.de --cert-file /etc/apache2/ssl/server.crt --key-file /etc/apache2/ssl/server.key --fullchain-file /etc/apache2/ssl.crt/server-ca.crt

SSL Aktivieren

a2enmod ssl

Apache ssl-virtual host ggf. aktivieren, u nter Ubuntu:
a2ensite default-ssl.conf

Darin

ServerName   superx-cloud.de
SSLCertificateFile /etc/apache2/ssl/ superx-cloud.de .crt

SSLCertificateKeyFile /etc/apache2/ssl/superx-cloud.de.key

SSLCertificateChainFile /etc/apache2/ssl/superx-cloud.de-fullchain.crt

SSLCACertificateFile /etc/apache2/ssl/superx-cloud.de-intermediate.crt

Danach starten Sie Apache neu.

2.1.5.5 Mailversand

Zum Mailversand von Logmails installieren Sie ein UNIX Mailprogramm. Unter Ubuntu Linux ist dies z.B. s-nail, das ein Binary namens " s-nail " bereitstellt:

apt-get install -y s-nail

Standardmäßig sucht s-nail den SMTP Server auf localhost, typischerweise muss ein externer Mailserver angebunden werden. Dazu legen sie im Homeverzeichnis des Benutzers eine Datei ".mailrc" an. Der Inhalt z.B.

set smtp="smtp://smtp.meinmailserver.de:587"

set from="superx@localhost"

set smtp-auth=login

set smtp-auth-user="meinemailkennung"

set smtp-auth-password=meinpasswort

Hinweis: es gibt auch andere Mailclients wie mutt oder mailx, wir haben s-nail gewählt weil die Syntax der obigen .mailrc-Datei und z.B.   bzgl. den Anfügens von Attachments (z.B. für Logdateien) nach dem klassischen "mailx" orientiert ist. Letzteres wird nicht mehr weiterentwickelt.

Sie können den Mailversand dann testen z.B. mit

echo test | s-nail   -s Testbetreff s upervisor@meinmailserver.de

Sie können auch Mailverteiler einrichten, mit dem Befehl alias:

alias sxadmin supervisor1@meinmailserver.de supervisor2@meinmailserver.de

Sie können den Alias als Adressaten verwenden,   z.B. mit

echo test | s-nail   -s Testbetreff sxadmin

2.1.6 Anpassungen auf den Client-Rechner n

Der Vorteil von browser-basierten Webclients ist es, dass prinzipiell keine Installationen auf den Clients notwendig sind, und dass sie plattformübergreifend arbeiten. Nur für das SuperX-Applet muss man das Java-Plugin installiert haben.

2.1.6.1 Einstellungen für den Ajax-Client

Um mit dem Browser komfortabel arbeiten zu können, sollten wenn möglich die aktuellen, gebräuchlichen Browser eingesetzt werden, z.B. Firefox, Netscape, Seamonkey oder den Internet Explorer:

• • Mozilla Firefox 1.5 oder höher, Mozilla 1.4 oder höher, Seamonkey 1.0 oder höher 

• • Internet Explorer 6.0 oder höher 

Weiterhin ist es notwendig, dass die Anwender mit Bearbeitungszugriff auch Javascript einschalten (beim IE nennt sich dies "Active Scripting"). Man kann dies auch nur für bestimmte Server (bzw. Sicherheitszonen) tun, so dass Sie nur den Superx-Server freischalten müssen. Außerdem sollten Sie hier die Datenübermittlung zwischen Frames erlauben.

2.1.6.2 Installation der Java-Runtime

Das SuperX-Applet wird bei jedem Aufruf (je nach Cacheing des Browsers) neu geladen; der Umstieg auf neue Versionen des Applets ist also ohne lokale Installationen möglich. Eine Bedienungsanleitung zum Java-Client findet sich im Benutzerhandbuch .  
Für die Installation der Java-Runtime reicht es meist aus, zur Aufruf-Seite vom Applet zu surfen. Es wird dann eine Installationsaufforderung inkl. Download von http://java.sun.com gestartet. Bitte nehmen Sie Java von Oracle, für andere Java-Versionen (IBM Java, GNU Java) wurden Probleme berichtet.

Für die Installation der Java Runtime benötigen Sie Administrationsrechte auf Ihrem Rechner.

2.1.6.2.1 Zertifikatswarnung im Applet

Das SuperX- oder Joolap-Applet besitzt ein Zertifikat, damit man drucken kann und in die Zwischenablage kopieren darf. Ab Java Version 1.7.51 muss man dieses Zertifikat zu den vertrauenswürdigen Sites hinzufügen:

• • Windows: Systemsteuerung öffnen, Linux KDE: Systemeinstellungen 

• • Auf das Java-Symbol doppelklicken 

• • Sicherheit wählen 

 

• • Siteliste bearbeiten wählen 

• • Auf Hinzufügen klicken 

• • Die Webadresse https://... eintragen 

 

• • OK wählen 

• • Anschließend startet das Applet bzw. JOOLAP mit normalem Sicherheits-Prompt und wird nicht mehr abgebrochen. 

2.1.6.2.2 Manuelle Anpassungen der Policy

Bei einigen Windows-Umgebungen (z.B. mit Netscape 6.1, ohne IE, oder mit Windows XP) läßt sich die Policy nicht scriptgesteuert installieren. Man muss dann die Policy dialogisch einrichten. Starten Sie dazu die Anwendung policytool , die sich im Lieferumfang der Java-Runtime befindet. Wenn Sie die Anwendung z.B. unter C:\Programme\Java\JRE\1.6.1_02\bin\policytool.exe installiert haben, dann starten Sie die Anwendung mit Doppelklick und gehen wie folgt vor:

Die AWT-Permission "AccessClipboard" muss gesetzt werden.
Die Runtime-Permission "queuePrintJob" muss gesetzt werden.

Danach klicken Sie auf "Done" und speichern die Policy im Home-Verzeichnis Ihrer Windows-Kennung, z.B. c:\dokumente und einstellungen\<<Ihre Kennung>>\.java.policy

2.1.6.2.3 Installation des Applets unter UNIX / Linux

Die Installationssite von SuperX erkennt, ob es sich um einen Linux-Browser handelt. Die Anwender werden zum Download auf die Seiten von Sun verwiesen.

Unter UNIX / Linux werden zunächst die Dateien der Java-Runtime bzw. des JDK der Firma Oracle installiert (s.o.).

Bei erfolgreicher Anmeldung erscheint folgendes Fenster:

 

2.1.6.3 Bei Probleme n mit dem Start des Applets

Wenn es Probleme mit dem Start des Applets gibt, kann dies verschiedene Ursachen haben.

Unter Netscape ist aufgefallen, dass bei verschlüsselter Verbindung auf dem Server die Datei $superxdir/webserver/tomcat/webapps/superx/applet/superx_help/superx.hs im gleichen Verzeichnis auch mit dem Namen superx_de_DE.hs existieren muss.

Eine weitere Ursache können Sicherheitseinstellungen sein. Fügen Sie Ihren SuperX-Server zur Liste der vertrauenswürdigen Sites hinzu.

Hier als Beispiel die Einstellung für den Duisburger SuperX-Server im InternetExplorer.

Im InternetExplorer und Extras / Internetoptionen, Registerkarte „Sicherheit“ Punkt Vertrauenswürdige Sites. Auf „Sites“ klicken.
Danach gibt man wie gezeigt den SuperX-Server ein und klickt auf Hinzufügen und OK.

Im lokalen Netz kann es durch den Proxy zu Problemen kommen. Man sollte daher den Proxy-Server für lokale Adressen umgehen.

Im InternetExplorer geht das folgendermaßen:

Sofern „Proxyserver verwenden“ aktiviert ist, sollte man den Menüpunkt „Proxyserver für lokale Adressen umgehen“ ebenfalls aktivieren.

Auch Addons für WebBrowser wie "NoScript" können hier Probleme machen. Dabei reicht es z.B. bei "NoScript" nicht in den Einstellungen auf "Skripte allgemein erlauben"zu stellen. In dem Fall muss es deaktiviert werden.

Nach Veränderungen der Einstellungen ist es generell sehr sinnvoll den Cache zu leeren .

2.1.6.4 Leeren des Browser-Cache

Wenn ein neues SuperX-Applet auf dem Webserver installiert wird, ist es möglich dass die Clients dies nicht sofort mitbekommen. Je nach Java-Version und Betriebssystem unterscheiden Sie sich Wege, den Browser-Cache zu leeren. Unter Windows mit Java 1.4.x wird der Browser-Cache geleert, bei Windows ab Java 1.5.x oder unter Linux wird der Java-Cache geleert. Im Zweifelsfall löschen Sie beide Caches.

Beim Browser-Cache sind die Einstellungen des Browsers maßgeblich. Beim Internet Explorer gehen Sie in das Menü "Extras"->"Internetoptionen"

In der Registerkarte "Allgemein" sehen Sie im Abschnitt "Temporäre Internetdateien" den Button "Dateien löschen"; klicken Sie darauf, und löschen Sie alle Inhalte. Danach klicken Sie auf "Einstellungen"…

…und markieren Sie den Knopf "Bei jedem Zugriff auf die Seite". Dann drücken Sie "OK".

Starten Sie den Browser dann neu.

Bei Netscape/Mozilla befindet sich die Einstellung im Menü "Edit" (deutsch "Bearbeiten") -> "Preferences" (deutsch "Einstellungen").

Hier drücken Sie den Button "Clear Cache" ("Cache leeren") und kreuzen dann unten den Button "Every time I view the page" ("Bei jedem Zugriff auf die Seite") an.

Starten Sie den Browser dann neu.

2.1.6.5 Leeren des Java - Cache

Unabhängig vom Webbrowser wird ein Java Cache gepflegt. Das Leeren des Browser-Cache bringt da keine Besserung. Man sollte bei neuen Versionen der Software in der Systemsteuerung im Java Control Panel im Abschnitt "temporäre Internetdateien" den Cache leeren (siehe Screenshot):

 

Wenn Sie keine Bandbreiten-Probleme haben, sollten Sie am besten sogar das Häkchen bei "Temporäre Dateien auf Computer belassen" entfernen.

Hinweis für ältere Java Runtimes:

Bei der Java-Runtime Java 1.5.x unter Windows sowie bei der Java Runtime 1.4.x unter Linux wird ein separater, vom Browser unabhängiger Cache genutzt, der manuell geleert werden muss. Löschen Sie also alle Inhalte in den Pfaden:

Unter Windows:
c:\Dokumente und Einstellungen\<<Kennung>>\Anwendungsdaten\
sun\java\deployment\cache\javapi\v.1.0\jar\*

Unter Linux:
/home/<<Kennung>>/.java/deployment/cache/javapi/v1.0/jar/*
Danach starten Sie den Browser neu.

2.1.7 Umgang mit SSL Verschlüsselung

An mehreren Stellen können Sie mit SSL Verschlüsselung in Berührung kommen:

Beim Datenbankzugriff mit SSL

Beim Verschlüsseln im Apache Server

Beim Zugang zu einem SSL-verschlüsselnden LDAP Server

Im folgenden eine Anleitung zum Erzeugen und Bereitstellen von Zertifikaten.

2.1.7.1 Erzeugen eines SSL Zertifikats

Auf dem Rechner, der verschlüsseln soll, muss das Paket Openssl installiert sein. Ist dies der Fall, kann man als User root ein Zertifikat erzeugen.

Wir führen alle Schritte als user root durch, und gehen z.B. davon aus, dass wir uns im Verzeichnis /root befinden.

Zunächst muss ein Zertifikat erzeugt werden:

openssl req -new -nodes -newkey rsa:2048 -keyout mydomain.key -out mydomain.csr

Sie die jeweiligen Angaben (Land, Organisation etc.). Beim "Common Name" muss der DNS-Servername des Servers angegeben werden. Ein Challenge Passwort ist erst einmal nicht notwendig. Der private Schlüssel ist nicht geschützt, sonst müßten Sie den bei der Nutzung (z.B.   Apache Start) manuell eintippen.

Der private Schlüssel liegt in /root/ mydomain.key

Der öffentliche Schlüssel hat das RSA Format. In Java Runtimes und im Browser wird ggf. nur ein X.509 Zeirtifikat erlaubt. Dazu müssen Sie das öffentliche Zertifikat zuerst in das entsprechende DER-Format konvertieren:

openssl x509 -in mydomain.key -out capub.crt -outform DER

Es wird die Datei /root/capub.crt erzeugt.

Alternatives Vorgehen unter Ubuntu mit Ziel Zertifikat für Postgres:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365

Eine passphrase ist nicht hilfreich, wenn Server automatisch neu gebootet werden können soll.
So kann man eine Entfernen:

openssl rsa -in [file1.key] -out [file2.key]

https://knowledge.digicert.com/solution/SO5292.html

2.1.7.2 Erzeugen eines Zertifikat-Request für eine Zertifizierungsstelle

Sie können ein neues Zertifikat erstellen und direkt einen Request für eine Zertifizierungsstelle erzeugen. Der Schlüssel sollte mind. 2048 bit haben. Das geht mit dem Befehl:

openssl req -new -nodes -newkey rsa:2048 -keyout mydomain.key -out mein_request.csr

Es wird ein Request in die Datei ./ mein_request.csr geschrieben.

Letzteren übergeben Sie an die Zertifizierungsstelle. Achten Sie dabei darauf, dass die Angabe bei "Common Name" exakt dem Domainnamen entspricht. Wie u openssl req -new -nodes -newkey rsa:2048 -keyout mydomain.key -out mein_request.csr nd in welchem Format Sie die Anfrage an die von Ihnen ausgewählte Zertifizierungsstelle senden müssen, erfahren Sie von der entsprechenden Zertifizierungsstelle.

2.1.7.3 Importieren des Zertifikats in Java

Wenn Client Programme wie z.B. Java   auf einen SSL verschlüsselten Server zugreifen, der über ein selbst signiertes Zertifikat verfügt, dann muss man das Zertifikat in den TrustStore von Java bzw. Tomcat importieren.

Es gibt einen systemweiten Truststore , wenn Sie das systemweiten TrustStore von Java verwenden, liegt dies in $JAVA_HOME/jre/lib/security/cacerts . Dann würde der Befehl lauten:

sudo keytool -import -alias myssl -file /root/capub.crt -keystore $JAVA_HOME/jre/lib/security/cacerts

Ggf. müssen Sie hier das Passwort des keystore eingeben (Standard wenn nicht verändert: changeit) . Danach kommt die Sicherheitsabfrage

Diesem Zertifikat vertrauen? [Nein]:   Ja

Zertifikat wurde zu Keystore hinzugefügt.

Wenn Sie für Tomcat einen speziellen Truststore definieren, z.B. durch den Tomcat Start Parameter

-Djavax.net.ssl.trustStore=/usr/local/tomcat/conf/cacerts

dann müssen Sie den Zielpfad für den Import entsprechend anpassen:

  sudo keytool -import -alias myssl -file /root/capub.crt -keystore /usr/local/tomcat/conf/cacerts

In der HISinOne-BI kann der TrustStore in der globalen Konfiguration im Parameter KEYSTORE=... gesetzt werden. Das Vorgehen wäre hier analog.

Achtung: Wenn Sie eine eigene Datei als keystore nutzen wollen, gibt es in manchen Tomcat/Java Konstellationen Probleme, z.B. bei Tomcat 7.0.22 und jdk1.7.0_51. Verwenden Sie in diesem Falle besser den Default ($JAVA_HOME/jre/lib/security/cacerts ).

Falls Sie das Zertifikat des Ziel-Server s nicht zur Hand haben, können Sie es auch direkt herunterladen . Gehen Sie im Browser auf die entsprechende URL und klicken Sie vor der URL auf das Schlüsselsymbol. Dort gehen Sie auf "Zertifikat anzeigen" -> Details. Je nach Browser/Version heißen die Menüpunkte unterscheidlich. Bei der Detailansicht des Zertifikats gibt es einen "Exportieren" Button. Hier ein Beispiel für Firefox:

 

  Die Zieldatei bekommt eine Endung "*.crt".

Alternativ geht auch die Linux Kommandozeile:

  openssl s_client -connect meinserver.de:443 -servername meinserver.de:443 < /dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > meinserver.de.crt

Falls Das Zertifikat in x509 format benötigt wird, bitte folgenden Befehl verwenden:

openssl x509 -in <(openssl s_client -connect ads.hs-karlsruhe.de:636 -prexit 2>/dev/null) > my-ca.crt

Danach können Sie das Zertifikat importieren mit

$JAVA_HOME/bin/keytool -importcert -alias myssl -keystore $JAVA_HOME/jre/lib/security/cacerts -trustcacerts -file ./my-ca.crt  

Der Befehl keytool ist recht flexibel, man kann damit auch Zertifikate anschauen ( -list ) oder löschen ( -delete ). Details liefert die Ausgabe von keytool -help .

2.1.8 Test- und Produktivsystem synchronisieren

An einigen Hochschulen gibt es ein Testsystem in dem Entwicklungen getestet werden und ein Produktivsystem in dem die stabilen Entwicklungen dann übertragen werden. Die Schwierigkeit bestand bisher, beide Systeme auf einen vergleichbaren Stand zu halten, damit das Testsystem auch einem reellen Test widerspiegelt. Außerdem gab es keine einfache Möglichkeit größere Änderungen vom Testsystem ins Produktivsystem zu übertragen. Um diese Möglichkeit zu erhalten gibt nun wie in allen anderen Modulen   auch im Kernmodul eine Hauptladeroutine mit unload- und update-Funktion.

Über die Bordmittel der Laderoutinen (Unload / Copy / Upload) können also Konfigurationen übertragen werden.

Details zu den Laderoutinen jeweils für

• • HISinOne-BI: https://wiki.his.de/mediawiki/index.php/Komponentenverwaltung_der_HISinOne-BI  

• • SuperX: Modulverwaltung  

  Im Kontext der Säulenübertragung in HISinOne kann neben der Copy-Funktion auch SVN / Git genutzt werden, Sie müssen dazu nur die Dateien

webapps/superx/WEB-INF/conf/edustore/db/install/rohdaten/unl/*.unl

aus dem SVN-Ignore /GIT-Ignore entfernen, auf dem Entwicklungssystem committen und auf der Zielsäule updaten.

2.1.8.1 Entladeparameter

Über die Entladeparameter können Sie steuern, welche Daten übertragen werden sollen. Hier gibt es default-Werte, die Sie in der KERN_ENV selber anpassen können. Falls Sie keine angaben dazu in der KERN_ENV machen, werden die default-Werte verwendet.

UNLOAD_USERRIGHTS

Hier handelt es sich um die Benutzerrechte aus dem Kernmodul. Es werden also die Benutzer, Gruppen, Sichtenrechte... übertragen. Spezielle Rechte wie die Kameralen Rechte des FIN Moduls sind hier nicht mit inbegriffen.

UNLOAD_FIN_USER_KAM

Hierbei handelt es sich nur im die Kameralne Rechte des FIN Moduls.

UNLOAD_KONSTANTEN

Hierbei handelt es sich um die Konstanten.

UNLOAD_UNLOAD_PARAMS

Hierbei handelt es sich um die Entladeparameter.

UNLOAD_REPOSITORY

Hierbei handelt es sich um die Repository Variablen

UNLOAD_HOCHSCHULINFO

Hierbei handelt es sich um die Tabelle Hochschulinfo mit Informationen wie Name, Anschrift... der Hochschule.

UNLOAD_THEMENBAUM

Hierbei handelt es sich um die Menüstruktur des Informationssystems.

UNLOAD_MASKEN

Hierbei handelt es sich um alle Berichte.

UNLOAD_STYLESHEETS

Hierbei handelt es sich um die Styles der Breichte. Achtung: Es werden nur die Datenbankeinträge übertragen keine Dateien aus dem Dateisystem. Die Stylesheets müssen daher extra kopiert werden.

UNLOAD_MAKROS

Hier werdne die Makros übertragen.

UNLOAD_CAPTIONS

Hierbei handelt es sich um die Beschreibungen von Feldern, Erläuterungstexten ...

UNLOAD_SICHTEN

Heirbei handelt es sich um die Sichten

UNLOAD_MAN_CATALOGUE

Hierbei handelt es sich um den Zahlenkatalog des MAN Moduls.

UNLOAD_MAN_ZAHL_WERT

Hierbei handelt es sich um eigene Werte der Hochschule für das MAN Modul.

UNLOAD_KENN_ZAHL_WERT

Hierbei handelt es sich um eigene Werte der Hochschule für das KENN Modul.

2.1.8.2 Ausführung

Wie üblich muss in der KERN_ENV die DB Verbindung eingerichtet werden und auch die Entladeparameter. Über die Scripte kern_unload.x werden dann die Tabellen aus dem jeweils anderen SuperX entladen und per kern_update.x in das verwendete SuperX eingespielt.

2.2 Upgrade einer bestehenden SuperX-Installation

Der Update eines bestehenden SuperX ist nicht trivial: Es kursieren verschiedene SuperX-Versionen, und das System ist offen für Änderungen durch den Benutzer. Deshalb müssen die Dateien unterhalb von $SUPERX_DIR gesichert werden, und die Datenbank muss vorher exportiert werden. Generell gilt beim Upgrade, dass Sie keinesfalls das normale SuperX-Komplettpaket herunterladen und entpacken sollten, weil dadurch individuelle Konfigurationen überschrieben würden.

Stattdessen sollte Sie immer das passende Upgrade- bzw. "Patch"-Paket herunterladen. Die von Ihnen genutzte Version (zu finden in der Datei $SUPERX_DIR/db/install/VERSION) gibt dazu den besten Anhaltspunkt.

2.2.1 Patch einspielen

Als erstes müssen Sie sich einen Patch von der Seite http://download.superx-projekt.de/ herunterladen. Dabei ist zu beachten welches System und welche Codierung benötigt wird. Informationen über die Änderungen des Patches finden Sie als Link auf der Downloadseite. In dem Patch selber befindet sich auch noch eine patch_xxxx-xx-xx_readme.txt .

Vorbedingung ist, dass das Paket unzip installiert ist.

Legen Sie sich für die Patches ein Verzeichnis auf dem SuperX Server an. Am einfachsten wäre z.B. /home/superx/patches. In dieses Verzeichnis kopieren Sie den Patch.

Um Patches in SuperX einzuspielen gibt es das Script $SUPERX_DIR/db/bin/patch_apply.x . Das Script starten Sie direkt aus dem Patchordner, in dem der zu installierende Patch liegt. Gestartet wird es folgendermaßen:

patch_apply.x <<PatchFile>>

Ein Beispiel:

patch_apply.x patch_2011-06-01_superx_iso.zip

Dabei wird in dem Verzeichnis der Patch entpackt und ausgeführt.

2.2.2 Upgraden des Kernmoduls

2.2.2.1 Standardvorgehen beim Upgrade

Beim Upgrade des Kernmoduls gibt es ab Version 4.0 ein standardisiertes Vorgehen. Hier das Vorgehen für Kernmodul 4.x oder höher "in short":

Beenden Sie Tomcat und machen Sie eine Sicherung der Datenbank mit

cd $SUPERX_DIR/db/install

dump_it.x

Laden Sie das Kern- Patch-Paket für Ihr DBMS (Postgres, Informix) und Codierung (iso, utf-8)   herunter, z.B. kern4.3_superx_iso_POSTGRES_patch.tar.gz ,   und entpacken Sie es in $SUPERX_DIR

  cd $SUPERX_DIR/db/install/upgrade

kern_env_upgrade.x

. ../../bin/SQL_ENV

kern_upgrade.x

Weitere Hinweise:

Um sicher zu gehen empfehlen wir mit dem Script $SUPERX_DIR/db/install/dump_it.x die Datenbank in einer Datei zu sichern und anschließend von dem gesamten $SUPERX_DIR ein Backup anzulegen, bevor Sie mit dem Upgrade beginnen.

2.2.2.2 Upgrade Kernmodul Besonderheiten

Achtung: Fürs Kernmodul 4.9 benötigen Sie Java 1.8 in der aktuellen Version. Java 11 wird derzeit noch nicht unterstützt. Demensprechend benötigen Sie auch Tomcat 8.*.

Bei Oracle gibt es seit 2019 nur noch kommerzielle Pakete vom Java / JDK, mit "Registrierungszwang". Unter Linux installieren Sie OpenJDK 1.8 mit den Paketquellen, also z.B. bei Ubuntu Linux:

apt-get install -y openjdk-8-jdk

Für andere System: der Download der quelloffenen OpenJDK-Pakete befindet sich für die jew. Versionen und Betriebssysteme hier:

http://jdk.java.net/archive/

Beim Umstieg von Kernmodul 4.x auf 4. 9 gibt es noch eine wichtige Änderung: in der Datei $ SUPERX_DIR /db/bin/SQL_ENV muss die Variable CATALINA_OPTS um den Passus " -DSuperX-DB-PROPERTIES-SET=true -DMODULE_PFAD=$SUPERX_DIR/db/module " erweitert werden. Siehe SQL_ENV .

Außerdem müssen Sie beim Umstieg aufs Kernmodul 4.9 die Datei $WEBAPP/WEB-INF/web.xml erweitern um die neue REST-Schnitstelle .

2.2.2.3 Vorbereitungen für Tomcataktualisierung

1. 1. Kern Paket von der Seite http://download.superx-projekt.de/ herunterladen.  

2. 2. Tomcat beenden 

3. 3. Auf dem Tomcat-Server das Verzeichnis $SUPERX_DIR/webserver/tomcat nach $SUPERX_DIR/webserver/tomcat_old kopieren. Dies dient als Backup Verzeichnis und es werden später noch ein paar Dateien davon benötigt. 

4. 4. Verzeichnis $SUPERX_DIR/webserver/tomcat bis auf den Ordner webapps leeren. 

5. 5. Verzeichnis $SUPERX_DIR/webserver/tomcat/webapps/superx/WEB-INF/lib/ leeren. 

2.2.2.4 Tomcat aktualisieren

1. 1. Kernpaket im $SUPERX_DIR entpacken. 

2. 2. (Nur bei Mandantenbetrieb) In der web.xml bei de.superx.servlet.SuperXmlAbmeldung die Parameter init-param löschen. 

3. 3. Wenn Sie Kernmodul 3.x installierten und bisher immer das Kernmodul geupgradet haben, haben Sie noch Tomcat Version 4. Um dies umzustellen müssen Sie die Connections-Angaben in der server.xml   in die Datei webapps/superx/META-INF/context.xml übertragen (.sam-Datei liegt im gleichen Verzeichnis). Dafür gibt es auch ein Script: 

   sx_transform.x -IN:$SUPERX_DIR/webserver/tomcat_old/conf/server.xml -XSL:$SUPERX_DIR/db/conf/server_xml2context_xml.xsl -OUT:$SUPERX_DIR/webserver/tomcat/webapps/superx/META-INF/content.xml -method:xml  

4. 4. Wenn Sie Kernmodul 4. 9 installierten, haben Sie bereits Tomcat 8 und damit auch obige Datei context.xml. Diese muss daher nur aus dem alten Tomcat Verzeichnis in das neue übernommen werden. 

5. 5. Falls Sie UTF-8 Charset benutzen muss in der Datei conf/server.xml bei dem Connector mit dem Port 8080 noch: 

   URIEncoding="UTF-8" 

   ergänzt werden. Es sieht dann folgendermaßen aus: 

   <Connector port="8080" protocol="HTTP/1.1"  

                   connectionTimeout="20000"  

                   redirectPort="8443" URIEncoding="UTF-8" /> 

6. 6. Achten Sie darauf, dass Tomcat die Variable $JRE_HOME benutzt und diese richtig gesetzt ist. Eventuell $JRE_HOME auf $JAVA_HOME/jre setzen. 

7. 7. (Nur bei Mandantenbetrieb) $JDBC_CLASSPATH und $XML_CLASSPATH muss für die Mandanten in der SQL_ENV gesetzt werden. 

8. 8.   Für den Tomcat-Start e rgänzen Sie auch die Umgebungsvariable CATALINA_OPTS um den Parameter   -DSuperX-DB-PROPERTIES-SET=true -DMODULE_PFAD=$SUPERX_DIR/db/module .  

2.2.2.5 Datenbank aktualisieren

Bevor Sie den Upgrade ausführen müssen Sie zunächst in das Verzeichnis $SUPERX_DIR/db/install/upgrade/ wechseln und dort das Script kern_env_upgrade.x starten und danach die SQL_ENV neu laden. Nun muss nur noch das Upgradescript kern_upgrade.x in dem Verzeichnis $SUPERX_DIR/db/install/upgrade/ ausgeführt werden.

Wenn Sie den mitgelieferten Tomcat nutzen ergänzen Sie auch die Umgebungsvariable CATALINA_OPTS um den Parameter   -DSuperX-DB-PROPERTIES-SET=true -DMODULE_PFAD=$SUPERX_DIR/db/module.

2.2.2.6 Webserver aktualisieren

Wenn Sie den Datenbankserver und Webserver getrennt haben, muss das Kernpacket auch auf dem Webserver entpackt und der ENV UpgradeScript kern_env_upgrade.x gestartet werden.

Wenn der Apache mit mod_jk angebunden ist müssen auch die folgenden Dateien aus dem alten Tomcat übernommen werden:

$SUPERX_DIR/webserver/tomcat/conf/superx_mod_jk.conf

$SUPERX_DIR/webserver/tomcat/conf/workers.properties

2.2.2.7 Falls Joolap instaliert ist

Joolap läuft erst ab der Version 1.2 mit dem Kernmodul 4.1 zusammen. Daher prüfen Sie welche Joolap Version Sie einsetzen und aktualisieren diese gegebenenfalls.

Da die web.xml ersetzt wurde, müssen die Einträge für Joolap wieder eingefügt werden. Eine Anleitung finden Sie dazu in dem Joolap-Admin Handbuch .

Wenn Sie nach dem Kernupgrade Joolap nicht aurufen können und in der Datei $SUPERX_HOME/webserver/tomcat/logs/catalina.out steht, dass der ConnectionPool zu der HSQLDB nicht aufgebaut wer den kann, da der Treiber fehlt, muss dieser noch in das Tomcat Verzeichnis koppiert werden. Kopieren Sie dann bitte die Datei $SUPERX_HOME/joolap/lib/joolap.jar nach $SUPERX_HOME/webserver/tomcat/lib .

Danach bitte den Tomcat neu starten.

2.2.2.8 Upgrade von Mondrian / Saiku

Vor der ersten Verwendung von Saiku sollten die Konfigurationen aus dem Kapitel Verwendung von Mondrian / Saiku geprüft werden. Wichtig ist, dass sie die Datei $WEBAPP/WEB-INF/classes/edustore/edustore.xml sichern bzw. sogar versionieren.

Bei dem Upgrade von einem Modul werden die Cubes und Dimensionen des jeweiligen Moduls in Mondrian automatisch mit aktualisiert.

2.2.2.9 Upgrade bei mehreren Mandanten

Wenn Sie einen mandantenfähige SuperX-Installation upgraden, müssen Sie auf einen Schlag alle Mandanten aktualisieren, es ist nicht möglich einzelne Mandanten mit der älteren Version arbeiten zu lassen.

Der Datenbank-Upgrade bei mandantenfähigen Installationen verhält sich genauso wie der Upgrade einer Einzelplatz-Installation - mit einer Ausnahme: Die Umgebung für den Mandanten wird nicht in der Datei $SUPERX_DIR/db/bin/SQL_ENV gespeichert, sondern in einer speziellen Mandaten-Datei, z.B. $SUPERX_DIR/db/bin/SQL_ENV_PHHD .

Da das Upgrade-Script diesen Dateinamen nicht kennt, muss normalerweise eine Änderung manuell vollzogen werden: In der Datei müssen alle Nennungen von der Datei " superx*.jar " geändert werden nach " superx4.2jar " (z.B. in Variable JDBC_CLASSPATH ).

Dafür gibt es aber ein Script kern_env_upgrade.x. Dieses Script nimmt einige Änderungen automatisch vor. Zudem Startet es auch automatisch das Script   upgradeMandantendir.x falls die Variable MANDANTENID gesetzt ist und es einen Ordner mit der MandantenID unter $WEBAPP gibt.

Der Upgrade der Webapplikation entspricht dem Vorgehen wie oben gezeigt, mit einer Ausnahme: Sie müssen wie gehabt über das Script
$SUPERX_DIR/webserver/tomcat/webapps/superx/upgradeMandantendir.x <<MANDANTID>>
jeden einzelnen Mandanten aktualisieren. Im Kernmodul 3.5 wurde korrigiert, dass die der Datei $SUPERX_DIR/webserver/tomcat/webapps/superx/<<MANDANTID>>/xml/anmeldung.htm das versteckte Feld "mandantid" nicht mehr überschrieben wird, Sie können also sofort loslegen.

In dem Ordner $WEBAPP/$MANDANTENID/xml muss bei Mandantensystemen in der index.htm den JSP Seiten die MandantenID übergeben werden. Hier ein Beispiel für die 3 JSP Seiten mit der MandantenID PHHD:

• • header_wiki.jsp?MandantenID=PHHD 

• • anmeldung_wiki.jsp?MandantenID=PHHD 

• • welcome_wiki.jsp?MandantenID=PHHD 

Dies wird bei dem Script upgradeMandantendir.x automatisch gesetzt.

2.3 Datenschutz

Allgemeine Hinweise siehe Datenschutzdokumentation .

2.3.1 Checkliste Sicherheitsmaßnahmen SuperX

2.3.1.1 Keine Verwendung von Standardkennungen

Verwenden Sie nach Möglichkeit nicht die Standardkennungen (superx, admin und testuser), die bei Auslieferung im SuperX-Kernmodul enthalten sind. Richten Sie eine bzw. mehrere neue Administrator-Kennungen an und arbeiten mit diesen. Die Standardkennungen superx, admin, testuser sollten aus der SuperX-Tabelle userinfo gelöscht werden.

2.3.1.2 Applet deaktivieren

Um das logging im Applet abzuschalten, setzen Sie in $WEBAPP/applet/superx.properties „ logToKonsole“ auf „ none“ .

Falls Sie das Applet nicht benötigen löschen Sie das Verzeichnis

$WEBAPP/applet

Außerdem wird die Sicherheit erhöht, wenn ein Zugriff auf das nur vom Applet benutzte Servlet SuperXDBServlet unterbunden wird.

Bearbeiten Sie dazu Ihre Datei $WEBAPP/WEB-INF/web.xml

Starten Sie danach Tomcat neu.

2.3.1.3 Public-Private-Key-Kontrolle von Applet-Befehlen

Das Applet genügt von seiner Anlage her nicht mehr den modernen Sicherheitsanforderungen und wird mit dem Kernmodul 3.5 durch das XML-Frontend ersetzt. Wenn Sie das Applet dennoch einsetzen wollen: Zur Erhöhung der Sicherheit ist es möglich, eine DSA-public/private-Key-Kontrolle zu installieren. Dabei wird jeder Befehl, der vom Applet ans Servlet geschickt wird, mit dem einen Key signiert. Im Servlet wird mit Hilfe des anderen, nur dort bekannten Keys kontrolliert, ob der ankommende Befehl eine gültige Signatur aufweist.

Im Applet können Sie den Info-Button anklicken, in der erscheinenden Infobox wird angegeben, ob public/private key Kontrolle aktiv ist oder nicht.

2.3.1.4 Datenbankverbindung über einen eingeschränkten Datenbank-User

Zur Erhöhung der Sicherheit ist es möglich, dass die Datenbankverbindung von Tomcat zur Datenbank mit einem eingeschränkten User durchgeführt wird. Dies wird von ZENDAS (Zentrale Datenschutzstelle der baden-württembergischen Universitäten) für den Produktivbetrieb nachdrückliche empfohlen.

Richten Sie dazu einen entsprechenden eingeschränkten User in Ihrer Datenbank ein und geben Sie diesen beim Propadmin bei eingeschränkter User an. Details dazu siehe Kapitel Datenbankverbindung über einen eingeschränkten User für mehr Sicherheit .

Exkurs:

Wenn Sie die höchste Sicherheit wollen, aber der Zuständige für die Userverwaltung trotzdem das XML-Frontend benutzen können soll, könnten Sie folgendermaßen vorgehen:

• • Richten Sie für den regulären Betrieb einen eingeschränkten User mit minimalen Rechten ein, wie oben beschrieben und deaktivieren Sie alle Datenbankformulare, indem Sie nach jedem Komponentenupgrade das Verzeichnis $WEBAPP/edit leeren.  

• • Erzeugen Sie einen weiteren eingeschränkten Datenbankuser, der zusätzlich die Kernkomponententabellen bearbeiten darf. 

• • Richten Sie einen zweiten Tomcat ein, der mit diesem zweiten eingeschränkten Datenbankuser arbeitet.  

• • Sorgen Sie (z.B. per Firewall) dafür, dass nur der für die Userverwaltung zuständige Mitarbeit Zugriff auf den zweiten Tomcat hat. 

2.3.1.5 Entfernen von temporären Dateien

Entfernen Sie temporäre Dateien, die sich auf dem Webserver befinden (z.B. mit Endung ~ oder #Untitled#). In $SUPERX_DIR/db/bin steht das Skript remove_tmp.x zur Verfügung. Es entfernt automatisch alle Dateien mit den Endungen ~ , tmp und bak sowie #Untitled#- Dateien aus dem aktuellen Verzeichnis und dessen Unterverzeichnissen. Optional kann auch ein Pfad angegeben werden, in dem die Dateien gelöscht werden sollen, z.B.: remove_tmp.x $WEBAPP

2.3.1.6 IP Adressen aus Logdateien löschen

IP Adressen gelten laut DSGVO als Personenbezogene Daten. Da aus den Logdateien auch Statistiken erstellt werden können müssen die Benutzer diesem zustimmen, ander n falls darf die IP Adresse nicht mit geloggt werden. Leider ist bei Apache und Tomcat bisher noch nichts implementiert, über das die IP Adressen anonymisiert werden können. Hier werden ein paar Beispiele aufgelistet, wie die IP Adressen aus dem Logfile gelöscht werden können:

• • Ein Script von SuperX lautet anonym_ip.x und liegt unterhalb von db/bin/. Als ersten Parameter kann eine Datei oder ein Verzeichnis angegeben werden. Die Datei oder die Dateien in dem Verzeichnis (nicht rekursiv) werden nach IP (v4 und v6) gesucht und mit „*.*.*.*“ ersetzt. Das Script kann somit per Cronjob ausgeführt werden und regelmäßig in den Logdateien die IP Adressen anonymisieren. 

• • Es gibt auch ein Python Script von https://www.privacyfoundation.ch/en/services/anonip.html (GITHub: https://github.com/DigitaleGesellschaft/Anonip ) Das Script ist aber nicht offiziell in Apache oder Tomcat zu verwenden und muss manuell eingepfle werden. Im Internet gibt es dazu diverse Anleitungen, die das Anonymisieren direkt oder erst im nächtlichen Logrotate durchführt. 

• • Mit sed selber ein Script schreiben. Der Befehl ist einfach:
  sed 's/[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}/\*\.\*\.\*\.\*/g' access.log
  Das könnte man per Cronjob regelmäßig ausführen. Um Logeinträge OnTheFly zu bearbeiten wird es komplizierter. 

• • Eine Möglichkeit wäre noch access Log f iles ganz abschalten.  

2.4 Das Clientpaket

Wenn Sie nicht das gesamte Kernmodul inkl. Tomcat benötigen, sondern nur ein kleines Paket, um regelmäßige Administrationsaufgaben zu erledigen, haben wir ein Clientpaket "geschnürt", das die wichtigsten Werkzeuge zur mit dem DWH beinhaltet. Insbesondere Windows-Anwender können dieses Paket benutzen, um mit dem DWH zu arbeiten, z.B. Masken entwickeln, Tabellen entladen etc. Dazu enthält das Paket ein paar Werkzeuge.

Das Client-Paket wird außerdem für das Entladen aus HIS-Systemen unter Windows genutzt.

2.4.1 Installation

Laden Sie das Paket client<<Versionsnummer>>_<<Codierung>>.zip und speichern Sie es lokal auf der Festplatte.

2.4.1.1 Einrichten der Umgebung

Entpacken Sie dieses Archiv in einem separaten Verzeichnis, z.B. c:\Programme\edustore_client ,   und benennen Sie die Dateien um; unter Windows:
bin\client_env_sam.bat nach bin\client_env.bat
bzw. unter Unix:
bin/client_env.x.sam nach bin/client_env.x

Passen Sie die Parameter in der Datei an, und sorgen Sie   bei Bedarf dafür, daß die Datei beim Aufruf der Shell ausgeführt wird (unter DOS autoexec.bat , unter Linux / bash die ~/.bashrc ).

Folgende Parameter müssen Sie wahrscheinlich anpassen:

JAVA_HOME (Der Pfad zur JRE)
CLIENT_DIR (das Verzeichnis, in dem Sie den Client entpackt haben)

Folgende Parameter sind wichtig, aber   meist korrekt vorbelegt:

JDBC_CLASSPATH (der Pfad zu Ihrem jdbc-Treiber)

DB_PROPERTIES   (der Pfad zu den Datenbankparametern)

Wenn die Datei fertig eingerichtet ist, wird sie wie folgt in die aktuelle Shell geladen:

Unter DOS:

client_env.bat

Unter Unix:

. client_env.x

2.4.1.2 Einrichtung einer Datenbankverbindung

Mit dem Clientpaket können Sie u.a. auf die DWH-Datenbank zugreifen. Um dies zu tun, werden die Verbdingsdaten in einer properties-Datei gespeichert, die standardmäßig im Verzeichnis conf gespeichert wird. Starten Sie zunächst den propadmin mit
propadmin.bat (DOS)
bzw.
propadmin.x (Linux)

Dort geben Sie die Parameter für den DB-Zugriff ein. Das Passwort wird verschlüsselt

gespeichert. Danach sind die Kommandozeilen-Werkzeuge verfügbar. Unter Unix sind alle dort genannten Scripte nutzbar, unter DOS nur eine Auswahl (erkennbar daran, dass es eine Datei mit der Endung ".bat" im bin-Verzeichnis gibt).

2.4.2 Weitere Werkzeuge

Im Clientpaket befinden im Ordner tools die Anwendungen Jedit sowie die sqlWorkbench sowie das Access-Frontend . Diese Tools dienen zur Abfragenentwicklung. Details dazu finden Sie im Entwicklerhandbuch.

2.4.3 Download von Berichtsausgaben

Sie können mit dem Clientpaket auch Berichtsausgaben automatisch vom Server herunterladen. Dazu müssen Sie zunächst eine Kennung einrichten, die die entsprechenden Rechte besitzt. Wenn Sie die Kennung in HISinOne pflegen, müssen Sie sich einmalig in den Grunddaten- und Basisberichten anmelden, und danach muss der Administrator dieser Kennung ein "echtes" Passwort zuweisen.

Wenn dies geschehen ist, können Sie sich zunächst im Browser einen Link zusammenbasteln, der den Bericht ohne Login-Dialog anzeigt. Die URL dafür lautet:

http(s)://Servername:Port/superx/servlet/SuperXmlTabelle?tid=<<Maskennummer>>&kennung=<<Kennung>>&passwort=<<Passwort>>&<<ggf. weitere Parameter>>

wobei die Maskennummer für die eindeutige Nummer der Maske steht. Sie erfahren die Maskennummer, indem Sie die jeweilige Modulbeschreibung konsultieren, oder indem Sie einfach die Maus über den Link halten, dann wird die Nummer im Browser unten in der Statusleiste angezeigt.

Neben der Maskennummer muss die Kennung und das Passwort übergeben werden, sowie je nach Maske weitere Felder.

Einfaches Beispiel: Das Prüfprotokoll in der Komponente Stellen, Personal:

http://localhost:8080/superx/servlet/SuperXmlTabelle?tid=19220&kennung=superx&passwort=anfang12

Wenn diese Link im Browser funktioniert, können Sie die Datei wie folgt im Excel-Format herunterladen:

DOS (Achtung: die Zeichen "=" und "&" müssen mit Caret-Zeichen ("^") vorangestellt werden, außerdem muss die URL in Anführungszeichen gesetzt werden, sonst klappt die Parameterübergabe in DOS nicht):

wget.bat "http://solomon:8080/superx/servlet/SuperXmlTabelle^?tid^=19220^&kennung^=superx^&passwort^=anfang12" pruefprotokoll.xls

Unix:

wget.x 'http://localhost:8080/superx/servlet/SuperXmlTabelle?tid=19220&kennung=superx&passwort=anfang12' pruefprotokoll.xls

Die Datei wird im gleichen Verzeichnis gespeichert.

Sicherheitshinweis: wenn Sie   Passworte im Klartext in Browser-Adressleisten oder in Login-Shells eintippen, werden diese an verschiedenen Stellen gespeichert. Im Browser ist es die Chronik bzw. der Cache, in der Shell ist es die Eingabehistorie. Dies macht es anderen Anwendern leicht, die Passworte auszuspähen. Sie sollten daher die Passworte in Shellscripte verlagern, die ohne Login-Shell ablaufen. Diese Shellscripte wiederum dürfen nicht von unbefugten Personen eingesehen werden, stellen Sie die Leserechte im Dateisystem entsprechend her..  

2.4.4 Mailversand von Berichtsausgaben

Im Tandem mit dem obigen Berichtsdownload können Sie auch Berichtsausgaben per Mail versenden. Dafür sind im Pakt Scripte zum Verschicken von Dateien per Email

sendmail.bat   (für Windows)

sendmail.x     (für Linux)

Es sind die folgenden Parameter vorgesehen:

sendmail.bat --to test@test.de --from system@super-ics.de --host smtp.strato.de --ssl (optional wenn SSL verwendet werden soll) --username system --password geheim --subject "COB Prüfprotokoll"   --msg "Hier erhalten Sie Ihre Protokolle" (optional) --msgfile c:\nachricht.txt (optional) --attach c:\protokoll.xls (optional)

Die Parameter sind selbsterklärend. Der Parameter "--subject" kennzeichnet die Betreffzeile, und in den Mailtext selbst kann man "--msg Nachricht" oder mit "--msgfile Dateiname" auch den Inhalt von Textdateien kopieren. Außerdem wird mit dem Parameter "--attach Dateiname" eine Datei angehängt.

3 Administration des Kernmoduls: HowTo

Im folgenden werden zentrale Arbeitsschritte beim Betrieb von SuperX beschrieben. Für einen Blick auf den Hintergrund sollten Sie sich ggf. die Bestandteile anschauen.

Zuächst zeigen wir, wie die Frontends funktionieren, und dann beschreiben wir die Werkzeuge für die Administration von SuperX.

SuperX verfügt über unterschiedliche Benutzeroberflächen, hier "Frontends" genannt. Das SuperX-Applet dient dem allgemeinen Berichtswesen und liefert vordefinierte Ergebnistabellen. Die Installation des Applets auf den Clients ist in der Installationsanleitung beschrieben. Die Funktionsweise des Applets ist ausführlich in dem Benutzerhandbuch dokumentiert.

	Das XML-Frontend liefert komplexe Berichte, die aus mehreren Ergebnistabellen zusammengestellt werden, und die flexibel für verschiedene Ausgabegeräte und –formate aufbereitet werden können. Im Gegensatz zum Applet sind keinerlei Installationsschritte notwendig, es genügt ein html4-fähiger Browser. Derzeit ist das XML-Frontend noch im Betastadium.
	Joolap bietet die Möglichkeit, multidimensionale Auswertungen zu machen und Statistiken flexibel den eigenen Bedürfnissen anzupassen. Joolap wird mit einer eigenen Dokumentation ausgeliefert.

3.1 Die SuperX- Administrationswerkzeuge

Die Verwaltung des Organigramms und des Themenbaums sowie grundlegende User- und Gruppenverwaltung lässt sich mit Hilfe eines graphischen Administrationswerkzeugs SuperXAdmin (Betaversion 1.0)   sowie über ein Access-Frontend erledigen. Es gibt neben der Shell-Zugang über UNIX zwei Administrationswerkzeuge für das Kernmodul: Browser-basierte Formulare im XML-Frontend , die auf die DBFORMS-Technologie zurückgreifen. Außerdem wurde ein Access-Frontend entwickelt, dass über ODBC-Verknüpfung einen direkten Zugriff auf die SuperX-Tabellen liefert. Das Browser-basierte Frontend hat den Vorteil, dass es auch über eine http-Verbindung arbeitet und somit höhere Sicherheitsstandards erfüllt. Das Access-Frontend eignet sich besser für die direkte Bearbeitung einzelner Tabellen und für die Entwicklung von Abfragen. Die Funktionalität ist ansonsten identisch, deshalb wird im folgenden nur die Oberfläche des Browser-Frontends beschrieben. Lediglich die Abfragenbearbeitung mit dem Access-Frontend wird gesondert dargestellt.

3.1.1 Übersicht über Scripte unter UNIX

3.1.1.1 Allgemeine Prozessverwaltung

Mit folgenden UNIX-Kommandos können Sie die Auslastung des Servers feststellen:

3.1.1.2 SuperX-spezifische Scripte: Übersicht

Für die Administration des DataWarehouse sind Shellscripte vorbereitet, die flexible Werkzeuge zur Datenbankadministration bereitstellen. Die Shellscripte werden in den Update-Scripten aufgerufen, können aber auch zur manuellen Administration benutzt werden. Die wichtigsten Bereiche sind die Masken-Verwaltung und die Ladescripte im Umgang mit Tabellen sowie allgemeine Scripte.

Alle Scripte befinden sich unter $SUPERX_DIR/db/bin, deshalb muss dieser Pfad inder Umgebungsvariable PATH enthalten sein. Die Scripte wurden unter UNIX entwickelt (ohne Endung oder Endung .x ), einige davon sind auch nach DOS portiert worden (erkennbar an der Endung .bat ).

Einige Scripte lauten "sx_auto_"..., dies bedeutet, dass die Scripte ohne Sicherheitsabfrage ausgeführt werden.

Voraussetzung für den Ablauf der Scripte ist die Eintragung der korrekten Umgebungsvariablen in $SUPERX_DIR/db/bin/SQL_ENV bzw. $SUPERX_DIR\db\bin\sql_env.bat . Wenn der Client jdbc verwendet wird, muss ausserdem die korrekte DB_PROPERTIES gesetzt sein.

3.1.1.3 Die Umgebungssteuerung: SQL_ENV

Das Script $SUPERX_DIR/db/bin/SQL_ENV steuert die Umgebung und ist für den Betrieb der Scripte unverzichtbar. Einige Variablen sind vorbelegt, Beispiele sind auf Kommentar gesetzt. Da die Umgebung von dem System abhängt, muss jeder Anwender die Werte manuell pflegen. Bei einem Update des SuperX-Kernmoduls wird diese Datei nicht überschrieben, lediglich sein SQL_ENV.sam im gleichen Verzeichnis. Von dort müssen relevante Änderungen dann in die "richtige" SQL_ENV manuell übernommen werden. Informix- und Postgres-spezifische Variablen sind in dem Kapitel zur Installation und Konfiguration der Datenbankserver beschrieben.

Folgende Variablen sind auf jeden Fall zubelegen:

Die Datei sollte unter UNIX in jedem Aufruf der shell "gesourced" werden, z.B. durch den Befehl:
. ~/db/bin/SQL_ENV
(Leerzeichen zwischen Punkt und Tilde!) in der Datei ~/.bashrc .

Wenn Sie unter Windows den jdbc-Client nutzen, dann müssen Sie die Datei als erstes in der DOS-Shell aufrufen, bzw. in definierten Tasks am Anfang aufrufen.

3.1.1.4 Nutzung der SQL_ENV unter HISinOne-BI

Die SuperX Shellscripte lassen sich auch in der HISinOne-BI unter Linux   nutzen. In der Distribution befindet sich eine Beispiel-SQL_ENV für die Nutzung in HISinOne:

webapps/superx/WEB-INF/conf/edustore/db/bin/SQL_ENV_his1.sam

Der Unterschied ist in der Verzeichnisstruktur: Unter SuperX gibt es den Ordner $SUPERX_DIR, der normalerweise ganz oben liegt, z.B. in /home/superx. Unter HISinOne liegt der Ordner unterhalb der Webanwendung, z.B. in

/var/lib/tomcat7/webapps/superx/WEB-INF/conf/edustore

Weiterhin muss man die Umgebungsvariable WEBAPP umsetzen, z.B.:

SuperX: /home/superx/webserver/tomcat/webapps/superx

HISinOne: /var/lib/tomcat7/webapps/superx

3.1.1.5 Allgemeine Scripte

DOSQL

DOQUERY

sx_transform

Propadmin

Zum Absetzen beliebiger SQL-Kommandos werden die Befehle DOSQL und DOQUERY genutzt.

DOSQL

Shellvariablen setzen und SQL-Anweisung(en) in der der Datei (als Parameter) in der SuperX-Datenbank ausfuehren.

Das Ergebnis kann mit Feldüberschriften (header=true) in   eine Datei Ausgabedatei ausgegeben werden.

Wenn FM_DEBUG = true gesetzt wird, werden bei Freemarker Scripten von DOSQL die *.tmp.sql-Dateien nicht gelöscht.

DOQUERY

Shellvariablen setzen und eingegebene SQL-Anweisung (als Parameter) in der SuperX-Datenbank ausfuehren.

Das Ergebnis kann mit Feldüberschriften (header=true) in   eine Datei Ausgabedatei ausgegeben werden.

sx_transform

Transformiert eine xml-Datei mit einer übergebenen XSL-Datei und gibt das Ergebnis in einen Ausgabekanal aus (stdout oder Datei). Dabei wird der in SuperX integrierte XML-Parser Xerces und der   XML-Prozessor Xalan benutzt.

Als Parameter kann ein spezielles Ausgabeformat gewählt werden, z.B. TEXT (siehe Xalan-Doku). Bei rtf wird der RTF-Construktor Jfor auferufen, bei pdf wird FOP aufgerufen. Die *.fo-Datei wird nach tmp.fo geschrieben und dann nach pdf transformiert. Wir gehen also nich davon aus, dass .fo-Dateien die Eingabequellse darstellen.

Propadmin

Der PropAdmin ist ein kleines Werkzeug, um den Zugriff auf jdbc-Datenbanken zu testen und die Verbindungsparameter in einer übergebenen properties-Datei zu sichern. Wenn keine graphische Umgebung eingerichtet ist,   müssen Sie die alle Verbindungsparameter manuell in die db.properties eintragen. Nur das Passwort kann mit dem propadmin bearbeitet werden.

(Musterdateien für Postgres und Inofrmix liegen vor in
$SUPERX_DIR/webserver/tomcat/webapps/superx/WEB-INF/db-postgres.properties bzw. db-informix.properties ). Wenn als weiterer Parameter kein Dateiname übergeben wird, dann wird die Umgebungsvariable DB_PROPERTIES ausgewertet.

Wenn die Default-Dateiencodierung der aktiven Locale für die Passwort-Verschlüsselung nicht ausreicht, wird eine Fehlermeldung ausgegeben. Unter Windows / DOS ist die Vorbelegung Cp1252 bei deutscher Codepage ausreichend, unter Unix wird die deutsche Locale benötigt.

3.1.1.6 Codierung in ISO und UTF-8

sx_show_encoding.x

sx_recode_iso2utf.x

sx_recode_utf2iso.x

sx_list_isofiles.x

sx_recode_isofiles.x

sx_list_utf8files.x

sx_recode_utf8files.x

Ältere Systeme arbeiten in der Regel mit der Zeichencodierung ISO-8859-1 bis ISO-8859-9 . Dieser Zeichensatz wird auch LATIN-1 genannt. Die UNIX-Locale de_DE@euro entspricht z.B. ISO-8859-9 und enthält das EUR-Symbol.

  Mit dem Wechsel von ISO-Codierung zu UTF8 bleibt oft der Bedarf bestehen, Dateien hin- und herzucodieren. Seit es, weil beim Entladen aus einer entfernten Datenbank noch das ISO-System genutzt wird, oder bei der Migration eines Systems. Nach unserer Erfahrung sollten Umlaute in Dateinamen unbedingt vermieden werden.  

SuperX bietet unter UNIX Shellscripte zur Erfassung und Änderung der Zeichencodierung (Verzeichnis $SUPERX_DIR/db/bin). Im Wesentlichen werden dabei die Unix-Kommandos file und recode genutzt, die Shellscripte machen den Umgang mit umfangreichen Dateilisten komfortabler. Bei der Verarbeitung von Dateilisten sollte man die Scripte sehr vorsichtig einsetzen, es finden keine Sicherheitsüberprüfungen statt.

sx_show_encoding.x

Das Script zeigt die Encodierung einer Datei an.

Das Script nutzt verschiedene UNIX-Tools, je nach System kann die Ausgabe variieren. Bei XML-Dateien wird auch der Dateiinhalt (XML-Header) ausgewertet.

sx_recode_iso2utf.x

Das Script ändert die Encodierung einer Datei   von ISO nach UTF-8:

Das Script nutzt das UNIX-Kommando recode . Darüberhinaus werden bei XML-Dateien auch die XML-Header "encoding=..." geändert, so wird z.B. aus

<?xml version="1.0" encoding="ISO-8859-1"?>

der Header

<?xml version="1.0" encoding="UTF-8"?>

Andere   Inhalte der Datei unterhalb der ersten Zeile werden keinesfalls geändert.

sx_recode_utf2iso .x

Das Script ändert die Encodierung einer Datei   von ISO nach UTF-8:

Das Script nutzt das UNIX-Kommando recode . Darüberhinaus werden bei XML-Dateien auch die XML-Header "encoding=..." geändert, so wird z.B. aus

<?xml version="1.0" encoding="UTF-8"?>

der Header

<?xml version="1.0" encoding="ISO-8859-1"?>

Andere   Inhalte der Datei unterhalb der ersten Zeile werden keinesfalls geändert.

sx_list_isofiles .x

Das Script listet alle ISO-Dateien im übergebenen Verzeichnis auf (inkl. Unterverzeichnisse).

Die Ausgabe kann in eine Datei umgeleitet werden, welche wiederum für das Script sx_recode_isofiles.x als Eingabedatei genutzt werden.

sx_list_isofiles.x webserver/tomcat/webapps/superx/WEB-INF >iso.txt

sx_recode_isofiles .x

Das Script konvertiert alle Dateien in der übergebenen Dateiliste von ISO nach UTF-8:

Die Eingabedatei ist in der Regel die Ausgabe des Scriptes sx_list_isofiles.x .

sx_list_utf8files .x

Das Script listet alle UTF-8-Dateien im übergebenen Verzeichnis auf (inkl. Unterverzeichnisse).

Die Ausgabe kann in eine Datei umgeleitet werden, welche wiederum für das Script sx_recode_utf8files.x als Eingabedatei genutzt werden.

sx_list_isofiles.x webserver/tomcat/webapps/superx/WEB-INF >utf.txt

sx_recode_utf8files .x

Das Script konvertiert alle UTF-8 Dateien in der übergebenen Dateiliste von UTF-8 nach ISO:

Die Eingabedatei ist in der Regel die Ausgabe des Scriptes sx_list_utf8files.x .

3.1.1.7 Umgang mit Tabellen

sx_unload_table

sx_upload_table

sx_upload_records

sx_schema

In SuperX werden ständig Tabellen erstellt / geladen / entladen. Zu diesem Zweck wurden Shellscripte entwickelt.

sx_unload_table

Entlädt die Inhalte der Tabelle nach <<Dateiname>>(optional) oder <<name>>.unl

sx_upload_table

Löscht die Inhalte der Tabelle <<name>>, und lädt die Inhalte einer Datei in die Tabelle mit sx_upload_records . Wenn kein Dateiname übergeben wurde, wird als Name <<name>>.unl angenommen.

sx_upload_records

Lädt die Inhalte einer Datei in die Tabelle, ohne vorherige Inhalte zu löschen. Wenn kein Dateiname übergeben wurde, wird als Name <<name>>.unl angenommen.

Bei Postgres als DB-System wird eine Java-Klasse ( de.superx.bin.UnlFileConverter ) aufgerufen, die die Unload-Datei entsprechend einer Spezifikation aufbereitet (siehe $SUPERX_DIR/db/conf/unldescr* ).

Wenn der jdbc-Client benutzt wird, können umfangreiche Parameter übergeben werden (Import mit Spaltenüberschriften, Ausgabe von Fehlerprotokollen). Vergleichen Sie die Kommentare im Script.

sx_schema

Entlädt das Schema einer Tabelle in einem vorgegebenen Format.

3.1.1.8 Modulverwaltung

Bisherige SuperX-Implementationen sind an den Hochschulen entstanden und haben dementsprechend eine große Vielfalt von Update-Scripten, die jeweils die Vorlieben und Bedingungen der jewieligen Hochschule wiederspiegeln. Daraus ergibt sich für "Neulinge" ein sehr verwirrendes Bild. Außerdem gestaltet sich der Entwurf eines Moduls recht aufwändig, weil die ETL-Funktionen (Extraction -> Transformation -> Loading) manuell programmiert werden müssen. Eine weitere Anforderung ist, daß SuperX auf zwei Datenbankplattformen lauffähig sein muss, Informix und Postgres.

Das Ergebnis ist: SuperX ist (auf Datenbankseite) sehr fehleranfällig, schwer wartbar und praktisch nicht updatebar.

Mit SuperX Version 2.1 wurde die Verwaltung der Module (Installieren / Aktualisieren / sichern und die zugehörogen Logdateien) in zentrale Shellscripte verlagert, die sich ebenfalls in $SUPERX_DIR/db/bin befinden. Die Shellscripte sind dabei nur die operativen "Hüllen" um die eigentlichen SQL-Scripte. Diese wiederum werden zum Teil "von Hand" erzeugt (um z.B. hochschulspezifische Erweiterungen oder Anpassungen vorzunehmen), und zum Teil automatisch aus einer zentralen Steuerdatei ($SUPERX_DIR/db/module/<<Modulname>>/conf/<<Modulname>>.xml ) jeweils für Postgres und Informix erzeugt.

3.1.1.8.1 module_scripts_create.x

Das Script erzeugt die Installationsdateien für ein Modul, jeweils für Postgres und Informix, nach dem Schema
<<Modulname>>_<<Scriptaktion>>_<<Kürzel für Datenbanksystem>>.sql

Z.B. wird für das BAU-Modul aus der Datei $BAU_PFAD/conf/bau.xml das Script bau_load_pg.sql erzeugt, das die Rohdaten unter Postgres lädt, oder die Datei bau_trans_ids.sql für das Script, das die Bau-Tabellen unter Informix transformiert

Im Grunde handelt es sich um XML-Transformationen. Die Stylesheets für dieses Script befinden sich im Verzeichnis $SUPERX_DIR/db/conf , und die XML-Datei für das Module in $SUPERX_DIR/db/module/<<Modulname>>/conf . Wenn die Datei nicht gefunden wird, bricht das Script ab.

Die folgende Abbildung zeigt die Arbeitsweise:

Das Script module_scripts_create.x erzeugt eine Reihe von Scripten, die das Modul installieren / aktualisieren / deinstallieren. Außerdem werden html- bzw. rtf-Dokumentationen erzeugt sowie Administrationsformulare für dbforms .

3.1.1.8.2 module_install.x

Installiert ein Modul <<Modulname>> in der Datenbank, wobei die Installationsdateien sich im <<Modulpfad>> befinden.  

3.1.1.8.3 module_drop.x

Löscht die Komponenten eines Moduls <<Modulname>> in der Datenbank, wobei die Installationsdateien sich im <<Modulpfad>> befinden.  

3.1.1.8.4 Entladen

Das Entladescript lautet $SUPERX_DIR/db/module/<<Komponentenname>>/rohdaten/<<Komponentenname>>_unload.x. Die Entladeparameter werden in folgender Datei festgelegt:
$SUPERX_DIR/db/module/<<Komponentenname>>/rohdaten/<<Komponentenname>>_ENV

Entladeroutine bei mandantenfähigen Installationen:

$SUPERX_DIR/db/module/<<Komponentenname>>/rohdaten<<Mandantid>>/<<Komponentenname>>_ENV

Dokumentation zu den jew. Parametern finden Sie in den jeweiligen Administrationshandbüchern der Module. Meist kann man Start-Semester oder -Jahre für das Entladen festlegen. Immer muß man auch das Datenbank-Vorsystem festlegen (Hostname, Kennung etc) sowie, bei HIS-Systemen, die Versionsnummer.

3.1.1.8.5 module_update.x

Installiert eine neue Version eines Moduls <<Modulname>> in der Datenbank, wobei die Installationsdateien sich im <<Modulpfad>> befinden.  

3.1.1.8.6 module_etl.x

Aktualisiert ein Modul <<Modulname>> in der Datenbank, wobei die Installationsdateien sich im <<Modulpfad>> befinden.  

Die folgende Abbildung zeigt, wie die Komponenten zusammenhängen (klicken Sie auf die Grafik, um sie zu vergrößern):

Das Modul wird zunächst nach $MODULPFAD/tmp gesichert, danach werden die Rohdaten geladen, die Daten vorbereitet, transformiert, und nachbereitet. Danach werden die Hilfstabellen erzeugt und, bei erfolgreichem durchlaufen, das Standdatum aktualisiert.

Bei Fehlern im ETL-Prozeß wird die Sicherung wiederhergestellt, und eine Mail an den Administrator verschickt. Außerdem werden die übernommenen Daten überprüft; wenn z.B. Schlüssel fehlen oder Rohdaten falsch zu sein scheinen, wird dies als Attachment an die Log- oder Fehlermail angehängt.

In der Praxis wird dieses Script nicht direkt von Cronjobs ausgeführt, sondern von einem Shellscript, das vorher die Umgebung einrichtet. Das folgende Beispiel zeigt das Update-Script für Bau unter Informix: