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: