Die folgende Beschreibung geht davon aus, dass die IP des Servers die 10.32.1.1 ist.

Als erster Schritt wird PostgreSQL 8.2 bzw. 8.4 parallel zur vorhandenen Version installiert. Parallel deshalb, weil zum einen diverse Dienste der LML die Postgres-Datenbank verwenden, und so gibt es dabei keine Konflikte; zum anderen, weil SVP zwingend diese Version verlangt.

Man erstellt eine neue Datei postgresql.list im Verzeichnis /etc/apt/sources.list.d mit folgendem Inhalt:

# Repository für den Etch-Backport von PostgreSQL 8.2
# Datei /etc/apt/sources.list.d/postgresql.list
deb http://www.bluegap.ch/debian etch-backports main contrib non-free

Die eigentliche Installation geschieht durch die folgenden Kommandos:

aptitude update
aptitude install -t etch-backports postgresql-8.2

Dabei gibt es die eine oder andere Warnung wegen eines fehlenden Schlüssels, die man aber ignorieren bzw. bestätigen kann.

Damit es bei den normalen Upgrades keine Versionskonflikte gibt, sollte man das Repository wieder deaktivieren, indem man ein Kommentarzeichen vor die entsprechende Zeile setzt:

# Repository für den Etch-Backport von PostgreSQL 8.2
# Datei /etc/apt/sources.list.d/postgresql.list
# deb http://www.bluegap.ch/debian etch-backports main contrib non-free

Bei der LML 5 installiert man gleich PostgreSQL 8.4, für das es ein Installationspaket in den Backports gibt. Das muss jedoch zuerst aktiviert werden. Dazu legt man im Verzeichnis /etc/apt/sources.list.d eine neue Datel namens lenny-backports.list an, die lediglich folgende Zeilen enthält:

# Datei /etc/apt/sources.list.d/lenny-backports.list
# deb http://backports.debian.org/debian-backports lenny-backports main
# Achtung, ab Februar 2012 wird lenny nicht mehr offiziell unterstützt, weshalb einzutragen ist:
deb http://archive.debian.org/debian-backports lenny-backports main

Nun kann man PostgreSQL 8.4 installieren:

aptitude update
aptitude install -t lenny-backports postgresql-8.4

Im Auslieferungszustand wird die geforderte Latin1-Kodierung für Datenbanken nicht unterstützt. Man legt deshalb den Datenbankcluster mit den entsprechenden Einstellungen neu an:

pg_dropcluster --stop 8.4 main
pg_createcluster -p 15432 --locale=C -e latin1 8.4 main

Nun fehlt noch das Start-Script:

cd /etc/init.d
cp -a postgresql-8.3 postgresql-8.4
update-rc.d postgresql-8.4 defaults

In der Datei /etc/init.d/postgresql-8.4 ersetzt man noch an mehreren Stellen die Versionsnummer 8.3 durch 8.4, sonst musss man daran nichts verändern.

Die Konfiguration ist bei der Version 8.2 und 8.4 fast identisch. Bei den angegebenen Pfaden erstzt man 8.X jeweils durch 8.2 bzw. 8.4.

Folgende Konfigurationseinstellungen regeln den Zugang zur PostgreSQL-Datenbank:

In der Datei /etc/postgresql/8.X/main/pg_hba.conf modifiziert man die Zeile für den PostgreSQL-Superuser-Zugang:

# Vorher
# local all postgres ident

# Version 8.2 ändern zu:
local all postgres ident postgres

# Version 8.4 ändern zu:
local all postgres ident map=postgres

In derselben Datei erlaubt man durch die folgende neue Zeile unter IPv4 dem User svpuser den Zugriff auf die Datenbank svpbw10db aus dem Intranet (User und Datenbank werden später angelegt):

host svpbw10db svpuser 10.32.1.1 255.240.0.0 md5

Ganz am Ende der Datei /etc/postgresql/8.X/main/pg_ident.conf fügt man folgende Zeilen an:

postgres     root         postgres
postgres     postgres     postgres

Nun muss man noch in der Datei /etc/postgresql/8.X/main/postgresql.conf die Option listen_addresses suchen. Man entfernt das Kommentarzeichen und erlaubt den Zugang aus allen Netzen:

listen_addresses = '*'

Wenige Zeilen darunter ändert man gegebenenfalls den Port so ab, dass es mit Updates keine Probleme gibt:

port = 15432

Damit ist PostgreSQL 8.X vollständig konfiguriert und wird neu gestaret:

/etc/init.d/postgresql-8.2 restart

bzw.

/etc/init.d/postgresql-8.4 restart

Allerdings blockiert noch die interne Firewall jeden Zugriff auf die Datenbank aus dem Intranet. Um dies zu ändern, sucht man in der Datei /etc/linuxmuster/allowed-ports die Zeile, die mit tcp beginnt, und hängt den Port 15432 an. Die Zeile könnte danach etwa so ausehen:

tcp domain,ldap,ldaps,ipp,auth,sunrpc,netbios-ssn,microsoft-ds,1095:1125,webcache,15432

Anschließend wird die Firewall neu gestartet:

/etc/init.d/linuxmuster-base restart

Im PostgreSQL-Cluster erzeugt man eine neue Datenbank svpbw10db und einen User svpuser, der diese Datenbank verwaltet. Dies leisten die folgenden Kommandos:

psql -p 15432 -U postgres

CREATE USER svpuser PASSWORD '12345';

CREATE DATABASE svpbw10db OWNER svpuser ENCODING 'latin1';

\q

(Man darf natürlich ein besseres Kennwort nehemen, Achtung Strichpunkte!)

Den Erfolg kann man mit den Befehlen \l und \du kontrollieren (bevor man mit \q das Programm verlässt).

Selbstverständlich wird man im Verwaltugsnetz ein regelmäßiges Backup erstellen. Bei der LML wird dazu normalerweise Mondorescue verwendet. Dabei werden auch alle Dateien, die zum PostgreSQL-Datenbanksystem gehören, mitgesichert. Um jegliches Risiko etwaiger Datenbank-Inkonsistenzen zu vermeiden, ist es empfehlenswert, zusätzlich die SVP-Datenbank in einer Textdatei zu sichern.

Dazu legt man zum Beispiel folgendes Skript als Datei /usr/local/sbin/svp_backup an (für die Version 8.2 muss man wieder den Pfad für pg_dump anpassen):

# Datei /usr/local/sbin/svp_backup
OUTFILE=/home/backup/postgres/svpbw10db_dump_$(date +%Y%m%d.%H:%M)

/usr/lib/postgresql/8.4/bin/pg_dump -p 15432 -U postgres svpbw10db > $OUTFILE

chown root:root $OUTFILE
chmod 0600 $OUTFILE

Diese Datei muss ausführbar sein. Außerdem muss der Pfad /home/backup/postgres existieren. Die zugehörigen Linux-Befehle sind:

chmod 0600 /usr/local/sbin/svp_backup
mkdir -p /home/backup/postgres
chmod 0700 /home/backup/postgres

Nun richtet man noch ein tägliches Backup ein, zum Beispiel um 23:17 Uhr. Dazu genügt es, folgende Datei /etc/cron.d/svp_backup anzulegen:

# Cronjob für SVP-Backup
# Datei /etc/cron.d/svp_backup
17 23   * * *   root   /usr/local/sbin/svp_backup > /dev/null 2>&1

Ein Backup nützt natürlich nur etwas, wenn man es auch wieder zurückspielen kann. Man löscht dazu zunächst die gesamte Datenbank und legt sie dann neu leer an. Anschließend liest man das Backup in die leere Datenbank ein. Im Einzelnen:

psql -p 15432 -U postgres 
DROP DATABASE svpbw10db;
CREATE DATABASE svpbw10db OWNER svpuser ENCODING 'latin1';
\q

cd /home/backup/postgres
psql -p 15432 -U postgres -f svpbw10db_dump_20100224.23:17 svpbw10db

Wenn auch das nichts hilft, dann löscht man den gesamten Datenbankcluster und legt ihn neu an:

# Version 8.2:
pg_dropcluster --stop 8.2 main
pg_createcluster -p 15432 8.2 main

# Version 8.4:
pg_dropcluster --stop 8.4 main
pg_createcluster -p 15432 --locale=C -e latin1 8.4 main

Nun wiederholt man die gesamte PostgreSQL-Konfiguration und spielt dann das Backup zurück

Beim Upgrade der Musterlösung auf die Version 5 ist folgende Vorgehensweise zu empfehlen:

Das folgende Kommando erstellt eine komplette Sicherung der SVP-Datenbank:

mkdir -p /home/backup/postgresql
/usr/lib/postgresql/8.2/bin/pg_dump -p 15432 -U postgres svpbw10db > /home/backup/postgresql/svpbw10db_dump

Um Konflikte beim Upgrade zu vermeiden, deinstalliert man PostgreSQL komplett:

aptitude purge postgresql-8.2
rm /etc/init.d/postgresql-8.2
rm -r /etc/postgresql/8.2
rm -r /var/lib/postgresql/8.2

Nun kann man ohne Kollisionen das Upgrade auf die LML 5 durchführen.

Als nächstes installiert man PostgreSQL 8.4 nach obiger Anleitung für die LML 5. Auch die Konfiguration wiederholt man komplett.

Bleibt noch, die Daten aus dem Backup zurückzuspielen:

psql -p 15432 -U postgres -f /home/backup/postgresql/svpbw10db_dump svpbw10db

Auf den Clients installiert man das SVP-Client-Programm (man kann es, wie auch die Updates, im BWL-Intranet herunterladen). Beim ersten Start wird die Datenbank auf dem Server neu eingerichtet. Man sollte danach ein paarmal starten. Anschließend spielt man der Reihe nach die Updates ein. Nach jedem Update startet man mehrmals das Programm, bis sich das Verhalten beim Programmstart stabilisiert. (So ein Verhalten schafft natürlich großes Vertrauen in die Zuverlässigkeit von SVP).

Das Client-Programm sollte man nicht auf einem Netzlaufwerk, sondern lokal nach C:\Programme installieren.

Beim ersten Start muss man angeben, wie die PostgreSQL-Datenbank auf dem Server erreichbar ist:

• Server: 10.32.1.1
• Port: 15432
• Datenbank: svpbw10db
• User: svpuser
• Kennwort: 12345