Unterabschnitte

Der PostgreSQL Server

Ab Version 1.6.0 - Stand 09.05.2009

Allgemeines

PostgreSQL ist ein sehr leistungsfähiges relationales Datenbanksystem das in seiner Funktionsvielfalt kaum Wünsche offen läßt. Dazu gehört eine vollständige Unterstützung von Foreign Keys, Joins, Views, Triggers und Stored Procedures. Es stehen die meisten Datentypen der Standards SQL92 und SQL99 zur Verfügung sowie auch die Speicherung von Daten in Binary Large Objects (BLOBS).

Zur Anbindung von Client-Applikationen sind Programmierschnittstellen für eine Vielzahl von Programmiersprachen vorhanden. Darunter C/C++, Java, Perl, Python, Ruby, Tcl und ODBC. Zudem steht das Programm unter einer sehr liberalen Lizenz (BSD), die den Einsatz auch in kommerziellen Applikationen ermöglicht.

PostgreSQL ist mit einer sehr ausführlichen Dokumentation ausgestattet, die diesem Paket beigefügt wurde. Zu beachten ist dabei, dass die Konfiguration des Datenbankservers auf eisfair über die eisfair Konfigurationsschnittstelle erfolgt und nicht, wie im Kapitel ''Server Administration'' beschrieben, direkt mit den Konfigurationsdateien des Programms gearbeitet werden sollte. Da das Kapitel jedoch eine Menge Hintergrundinformationen liefert, wurde es dennoch in das eisfair-Paket aufgenommen.

Weitere Informationen zu PostgreSQL finden sich auf der offiziellen Web- Seite des Projekts ''http://www.postgresql.org'' oder in deutscher Sprache unter ''http://www.postgresql.de''.

Installation

Das Installationsskript führt die Installation des Datenbankservers aus, ohne dass weitere Angaben nötig sind. Es wird ein Benutzer ''postgres'' in einer Gruppe ''postgres'' angelegt und das Datenverzeichnis ''/var/lib/pgsql'' initialisiert.

Im Falle von Updates werden die Daten unter ''/var/lib/pgsql'' übernommen, solange diese kompatibel zur neuen Version von PostgreSQL sind. Dies ist immer dann der Fall, wenn sich lediglich die unterste Nummer in der internen Version des Datenbankservers ändert.

Beispiel:
8.0.2 -> 8.0.3 kompatibel
7.4.3 -> 8.0.3 nicht kompatibel

Die Versionsnummern des eisfair-Pakets von PostgreSQL werden sich an diesen Zusammenhang anlehnen:

Beispiel:
1.2.0 -> 1.2.1 kompatibel
1.1.0 -> 1.2.0 nicht kompatibel

Im Falle eines Kompatibilitätskonflikts bei Updates wird die Installation abgebrochen. Es muss in diesem Fall ein vollständiges Backup ausgeführt und anschließend das alte Paket deinstalliert werden. Nach der Installation der neuen Version können dann die gesicherten Datenbanken wieder eingespielt werden. Aus Sicherheitsgründen wird dieser Vorgang nicht automatisiert (siehe ''Sicherung und Wiederherstellung'').

Konfiguration

Die Konfiguration von PostgreSQL unter eisfair erfolgt über den Menüpunkt ''Edit configuration'' im Paketmenü. Die vorgenommenen Änderungen werden nach Beenden des Editors automatisch übernommen. Achtung: Dabei wird der Server neu gestartet und alle Client-Verbindungen getrennt.

Allgemeine Einstellungen

START_POSTGRESQL

Wird dieser Wert auf ''yes'' gestellt, dann wird der PostgreSQL Dienst automatisch beim Start des Rechners mitgestartet. Anderenfalls ist das Starten und Beenden des Dienstes über das Paketmenü jederzeit möglich.

Gültige Werte: ''yes'', ''no''

POSTGRESQL_NETWORKING

Hiermit wird festgelegt, ob der Datenbankdienst über das Netzwerk erreichbar sein soll, oder nicht. Steht der Wert auf ''no'', kann nur vom lokalen Rechner aus auf die Datenbanken zugegriffen werden, anderenfalls ist dies auch von anderen Rechnern im Netzwerk oder auch aus dem Internet möglich. Zu beachten ist aber, dass zusätzlich die Zugriffstabelle (Host access table) bestimmt, welche Verbindungen erlaubt sind und welche nicht.

Gültige Werte: ''yes'', ''no''

POSTGRESQL_SERVER_PORT

Für den lokalen Zugriff auf den Datenbankserver können Applikationen Unix-Sockets verwenden. Wird jedoch statt dessen TCP/IP verwendet, was bei Netzwerkzugriffen immer der Fall ist, dann ist die Angabe einer TCP/IP Anschlussnummer (Port) erforderlich. Diese wird hier vorgegeben.

Standard: ''5432''

POSTGRESQL_MAX_CONNECTS

Hiermit wird definiert, wieviele gleichzeitige Zugriffe auf den Datenbankserver möglich sein sollen. Diese Zahl bestimmt den Speicherbedarf des Programms und kann aus ökonomischen Grunden angepasst werden. Dabei ist zu beachten, dass auch der Autovacuum-Dienst und die auto- matische Datensicherung jeweils einen eigenen Zugriff erfordern.

Standard: ''100''

Zugriffstabelle

POSTGRESQL_HOST_N

Anzahl der Einträge in der Zugriffstabelle (Host access table). über die Zugriffstabelle kann vorgegeben werden, wer von wo auf welche Datenbank zugreifen darf und welches Anmeldeverfahren dabei zum Einsatz kommt. Siehe hierzu auch ''PostgreSQL und Sicherheit''

Beispiel: ''2''

POSTGRESQL_HOST_x_TYPE

Legt fest, ob hiermit ein lokaler Zugriff über einen Unix-Domain-Socket (local) oder ein Netzwerkzugriff über TCP/IP (host) beschrieben werden soll.

Gültige Werte: ''local'', ''host''

POSTGRESQL_HOST_x_NETWORK

Ist nur dann anzugeben, wenn ein Netzwerkzugriff beschrieben werden soll. Hier wird angegeben, aus welchem Adressbereich (Quelladresse) ein Rechner kommen darf, damit dieser Eintrag für ihn zutrifft. Der Adressbereich wird in der kombinierten Schreibweise aus IP-Adresse/ Subnetz angegeben.

Beispiel:
''192.168.0.0/16'' = Alle Adressen 192.168.x.x
''192.168.56.3/0'' = Nur der Rechner 192.168.56.3

POSTGRESQL_HOST_x_USERAUTH

Hier wird festgelegt, wie sich der Datenbankanwender bzw. das Client- Programm an dem Datenbankserver anzumelden hat. Dazu gibt es eine Reihe unterschiedlicher Verfahren: ''trust'': Der Client benötigt kein Kennwort - ihm wird immer vertraut.
''reject'': Der Client darf sich nicht anmelden.
''md5'': Der Client und Server tauschen eine md5 Checksumme aus (empfohlen).
''crypt'': Der Client schickt sein Kennwort verschlüsselt an den Server.
''password'': Der Client schickt sein Kennwort unverschlusselt.
''krb4'': Das Kerberos 4 Anmeldeverfahren wird verwendet.
''krb5'': Das Kerberos 5 Anmeldeverfahren wird verwendet.
''ident'': Die Anmeldung erfolgt über Ident.
''pam'': Die Anmeldung erfolgt über PAM.
Siehe hierzu auch ''PostgreSQL und Sicherheit''

POSTGRESQL_HOST_x_DATABASE

Gibt an, für welche Datenbank dieser Eintrag in der Zugriffstabelle gilt. Mit ''all'' werden alle Datenbanken zugleich angegeben.

Beispiel: ''all''

POSTGRESQL_HOST_x_USER

Gibt an, für welchen Datenbankanwender dieser Eintrag in der Zugriffs- tabelle gültig ist. Mit ''all'' werden alle bekannten Anwender zugleich angegeben.

Beispiel: ''all''

Sicherung

POSTGRESQL_BACKUP_SCHEDULE

Zeitvorgabe für den CRON-Dienst. Hier wird angegeben, wann die automatische Sicherung durchgeführt werden soll. Die 5 Werte stehen für: Minute, Stunde, Tag, Monat, Wochentag.

Beispiel:
''30 0 * * *'' -> täglich um 0:30 Uhr
''0 1 */2 * *'' -> Jeden zweiten Tag um 1:00 Uhr

POSTGRESQL_BACKUP_TARGET

Das Verzeichnis, in das die Sicherungsdateien abgelegt werden sollen.

Standard: ''/var/lib/pgsql_backup''

POSTGRESQL_BACKUP_N

Anzahl Datenbanken, die gesichert werden sollen. Jede der angegebenen Datenbanken wird in einer Datei mit folgendem Namen abgelegt:

datenbank_name-datum_iso-zeit.backup

Beispiel: ''2''

POSTGRESQL_BACKUP_x_DBNAME

Name der Datenbank, die gesichert werden soll.

Beispiel: ''mydb''

POSTGRESQL_BACKUP_x_USER

Name des Datenbankanwenders, der ausreichende Zugriffsrechte für die Sicherung der angegebenen Datenbank hat. Da der user ''postgres'' immer existiert, ist dieser immer eine gute Wahl.

Beispiel: ''postgres''

POSTGRESQL_BACKUP_x_MAX

Gibt an, wieviele Kopien der Sicherungsdatei aufgehoben werden sollen.

Beispiel: ''7''

POSTGRESQL_BACKUP_MOUNT

Bevor die Sicherung beginnt, wird das hier angegebene Kommando ausgeführt. Dies kann verwendet werden, um beispielsweise das Sicherungsmedium in das Dateisystem einzubinden. Soll kein Befehl ausgeführt werden bleibt das Feld leer.

Beispiel: ''mount -t udffs /dev/sr0 /mnt''

POSTGRESQL_BACKUP_NOTIFY

Wird hier eine e-mail Adresse angegeben, erfolgt im Falle von Fehlern bei der Datensicherung eine Benachrichtigung an den hier angegebenen Empfänger. Soll keine Benachrichtigung erfolgen bleibt das feld leer. Hinweis: Die Benachrichtigung funktioniert nur dann, wenn das E-mail Paket installiert ist.

Beispiel: ''dbadmin@localhost''

Automatische Optimierung

Mit der Zeit kann es bei Datenbanken zu einer gewissen Fragmentierung kommen, die zum Teil zu spürbaren Einbrüchen in der Leistungsfähigkeit des Servers führen kann. Darum empfiehlt es sich bei PostgreSQL in regelmäßigen Abständen das SQL-Kommando ''VACUUM FULL'' an den Server zu senden. Alternativ dazu kann ein Dienst gestartet werden, der sog. Autovacuum-Dienst, der den Zustand der Datenbank überwacht und die Tabellen ggf. selbstständig optimiert. Dieser Dienst wird wie folgt konfiguriert:

POSTGRESQL_AUTOVACUUM

Gibt an, ob der Autovacuum-Dienst mit dem Datenbankserver gestartet werden soll.

Gültige Werte: ''yes'', ''no''

Leistung und Ressourcenverbrauch

POSTGRESQL_RESOURCE_TUNING

Der PostgreSQL-Server kennt eine Reihe von Konfigurationseinstellungen über die der Ressourcenverbrauch und die Leistungsfähigkeit des Servers beeinflusst werden können. Einige dieser Einstellungen sind auch für PostgreSQL auf eisfair verfügbar und können verwendet werden, wenn RESOURCE_TUNING auf ''yes'' gestellt wurde. Bei ''no'' verwendet der Server die jeweiligen Standardeinstellungen.

Standard: ''no''

POSTGRESQL_SHARED_MEM

Legt die Grösse des Shared-Memory Speichers fest, der vom Datenbankserver verwendet werden soll. Die Standardeinstellung liegt für PostgreSQL auf eisfair typischerweise bei 16MB.

Die angegebene Grösse muss mindestens 128kB betragen und zugleich grösser als MAX_CONNECTIONS * 16kB sein. Allerdings sind üblicherweise deutlich höhere Werte erforderlich, um eine gute Leistung des Servers zu erhalten. Für produktive Systeme werden Werte von einigen tausend Buffern empfohlen.

Bei der Angabe der Speichergrösse können optional die Postfixe ''kB'', ''MB'' und ''GB'' verwendet werden. Achtung: Ohne Postfix wird der Wert in 8kB Blöcken interpretriert.

Standard: ''16MB''

POSTGRESQL_TEMP_MEM

Legt die Grösse des Speichers fest, der von jeder Datenbanksitzung verwendet werden soll. Es handelt sich hierbei um lokale, auf die Sitzung beschränkte Speicherbereiche für den Zugriff auf temporäre Tabellen.

Eine Sitzung allokiert nach Bedarf temporären Speicher bis zum eingestellten Limit in Blockgrössen von 8200 Byte. Der Speicherbedarf für einen grossen TEMP_MEM-Wert bei Sitzungen, die diesen Speicher- bereich nicht nutzen, liegt bei 64 Byte pro allokierbarem Buffer. Erst wenn ein Buffer tatsächlich verwendet wird, kommen dazu nochmal jeweils 8192 Byte hinzu.

Bei der Angabe der Speichergrösse können optional die Postfixe ''kB'', ''MB'' und ''GB'' verwendet werden. Achtung: Ohne Postfix wird der Wert in 8kB Blöcken interpretriert.

Standard: ''8MB''

POSTGRESQL_WORK_MEM

Gibt die Größe des Speichers an, der für interne Sortieroperationen und Hash-Tabellen verwendet wird, bevor Daten in temporäre Dateien ausgelagert werden.

Es ist zu beachten, dass bei komplexen Abfragen mehrere Sortier- oder Hash-Operationen parallel laufen können und damit der hier angegebene Speicher mehrfach angefordert wird. Zudem können mehrere Datenbanksitzungen solche Operationen gleichzeitig durchführen. Darum kann der tatsächliche Speicherbedarf ein vielfaches des in WORK_MEM angegebenen Wertes betragen.

Bei der Angabe der Speichergrösse können optional die Postfixe ''kB'', ''MB'' und ''GB'' verwendet werden. Achtung: Ohne Postfix wird der Wert in 1kB Blöcken interpretriert.

Standard: ''1MB''

POSTGRESQL_MAINTAIN_MEM

Gibt die Grösse des Speichers an, der für interne Verwaltungsaufgaben wie VACUUM, CREATE INDEX oder ALTER TABLE ADD FOREIGN KEY wendet wird.

Da eine Datenbanksitzung immer nur einen solchen Befehl gleichzeitig ausführen kann und solche Operationen üblicherweise selten von mehreren Sitzungen gleichzeitig ausgeführt werden, ist es sicher, diesen Wert höher als WORK_MEM einzustellen.

Bei der Angabe der Speichergrösse können optional die Postfixe ''kB'', ''MB'' und ''GB'' verwendet werden. Achtung: Ohne Postfix wird der Wert in 1kB Blöcken interpretriert.

Standard: ''8MB''

POSTGRESQL_PREP_TRANSACTIONS

Legt die maximale Anzahl von Transaktionen fest, die sich gleichzeitig im Zustand ''prepared'' befinden dürfen. Beim Setzen des Wertes auf 0 wird die Funktionalität der ''prepared''-Transaktionen deaktiviert.

Falls keine ''prepared'' Transaktionen verwendet werden, kann der Wert ebensogut auf Null gestellt weden. Falls doch, ist ein Wert von mindestens MAX_CONNECTIONS sinnvoll, damit ungewollte Fehlschläge beim ''prepare''-Schritt vermieden werden.

Standard: ''5''

Write-Ahead Logging (WAL)

POSTGRESQL_WAL_TUNING

Das Write-Ahead Logging ist ein Mechanismus zur Verbesserung der Serverleistung bei Datenbanktransaktionen. Das Schlüsselkonzept dabei ist, dass modifizierte Daten (bzw. Datenbereiche) nicht sofort nach dem Abschluss eine Transaktion auf die Platte geschrieben werden, sondern erst dann, wenn ein sogenannter Checkpoint erreicht wird. In der Zwischenzeit werden alle durchgeführten Transaktionen in ein WAL-Segment (Datei auf der Festplatte) geschrieben und können im Falle eines Systemabsturzes wiederholt werden.

Es gibt eine Reihe von Einstellungen, die das Verhalten des Write-Ahead Loggings beeinflussen. Einige dieser Einstellungen wurden für PostgreSQL auf eisfair verfügbar gemacht und können verändert werden, wenn POSTGRESQL_WAL_TUNING den Wert ''yes'' erhält. Anderenfalls werden die jeweiligen Standardwerte verwendet.

Standard: ''no''

POSTGRESQL_FSYNC

Steht diese Option auf ''yes'', dann stellt der PostgreSQL Server sicher, dass alle WAL-Updates auch wirklich physikalisch auf die Festplatte geschrieben werden. Dies geschieht durch den Aufruf der Systemfunktion fsync() oder einer vergleichbaren Methode. Das stellt sicher, dass der Datenbank-Cluster nach einem System- oder Hardwareausfall wieder auf einen konsistenten Stand gebracht werden kann.

Allerdings führt der Funktionsaufruf von fsync() zu einem nicht unerheblichen Leistungsengpass, da PostgreSQL nach jedem Abschluss einer Transaktion darauf warten muss, dass das Write-Ahead Log vollständig auf die Festplatte geschrieben wurde. Das Deaktivieren der Option dagegen kann die Systemleistung erheblich verbessern, aber bringt zugleich das Risiko mit sich, dass im Falle eines Sytemabsturzes o.ä. Daten verloren gehen können oder die Datenbank inkonsistent wird.

Wegen des damit verbundenen Risikos gibt es keine universell korrekte Einstellung für diesen Wert.

Standard: ''yes'' (maximale Zuverlässigkeit)

POSTGRESQL_SYNC_METHOD

Die Methode mit der das Schreiben der WAL-Updates auf die Festplatte erzwungen wird. Diese Einstellung ist nur dann relevant, wenn FSYNC auf ''yes'' gestellt wurde, da anderenfalls das physikalische Schreiben nicht erzwungen wird. Für PostgreSQL auf eisfair sind die folgenden Werte zulässig:

''fsync'': Gesamte Dateiinformation auf die Platte schreiben.
''fdatasync'': Nur den Datenbereich (keine Metadaten) auf die Platte schreiben.

Standard: ''fsync''

POSTGRESQL_WAL_DATA_MEM

Grösse des im Shared-Memory Bereich angeforderten Speicherbereichs. Die Einstellung braucht lediglich so gross zu sein, wie die Menge an WAL-Daten die durch eine typische Transaktion erzeugt werden, da nach Abschluss der Transaktion die Daten in die WAL-Datei geschrieben werden.

Bei der Angabe der Speichergrösse können optional die Postfixe ''kB'', ''MB'' und ''GB'' verwendet werden. Achtung: Ohne Postfix wird der Wert in 1kB Blöcken interpretriert.

Standard: ''8''

POSTGRESQL_COMMIT_DELAY

Zeitverzögerung in Mikrosekunden um die der Schreibvorgang in die WAL-Datei verzögert werden kann. Ein Wert ungleich Null kann es ermöglichen, dass mehrere Transaktionen gemeinsam mit einem fsync() Aufruf auskommen. Die dazu erforderliche annäherungsweise Gleichzeitigkeit der Transaktionen ist nur bei sehr hoher Systemlast gegeben, anderenfalls ist die Verzögerung nur verschenkte Zeit.

Darum wird nur dann gewartet, wenn sich COMMIT_SIBLINGS Transaktionen gleichzeitig in der Bearbeitung befinden.

Standard: ''0'' (keine Verzögerung)

POSTGRESQL_COMMIT_SIBLINGS

Minimale Anzahl von gleichzeitigen Transaktionen, die erforderlich sind, damit ein COMMIT_DELAY eingeleitet wird. Ein hoher Wert macht es wahrscheinlicher, dass zumindest eine weitere Transaktion innerhalb der Wartezeit abgeschlossen wird.

Standard: ''5''

POSTGRESQL_CHECKPOINT_SECTIONS

Maximaler Abstand zwischen automatisch erzeugten WAL Checkpoints, der in Log-Dateisegmenten angegeben wird (wovon jedes 16 Megabyte groß ist).

Der Datenbankserver erzeugt immer dann automatisch Checkpoints, wenn entwerder CHECKPOINT_SECTIONS Segmente überschritten wurden oder nach Ablauf von CHECKPOINT_TIMEOUT Sekunden, je nachdem welche Bedingung zuerst eintritt. Ebenfalls kann man einen Checkpoint mit dem SQL-Befehl CHECKPOINT erzwingen.

Werden CHECKPOINT_SECTIONS und/oder CHECKPOINT_TIMEOUT reduziert, dann erfolgen Checkpoints häufiger, wodurch eine Wiederherstellung nach einem Systemausfall beschleunigt wird. Allerdings entsteht durch das häufigere Schreiben veränderter Speicherseiten (das durch einen Checkpoint ausgelöst wird) eine höhere Systemlast.

Die Anzahl der WAL-Segmentdateien auf der Platte liegt zwischen einem und 2 * CHECKPOINT_SECTIONS + 1. Dabei hat jede Datei eine Größe von 16 MB.

Standard: ''3''

POSTGRESQL_CHECKPOINT_TIMEOUT

Maximale Zeit zwischen automatisch erzeugten WAL Checkpoints in Sekunden. Siehe hierzu auch die Erläuterungen in CHECKPOINT_SECTIONS.

Standard: ''300''

POSTGRESQL_CHECKPOINT_WARNING

Es wird eine Warnung in die Log-Datei des Servers geschrieben, wenn der Abstand von automatischen Checkpoints durch das Füllen von WAL-Segmenten näher als CHECKPOINT_WARNING Sekunden beieinander liegt. Das kann bedeuten, dass CHECKPOINT_SECTIONS erhöht werden sollte. Ein Wert von ''0'' deaktiviert die Warnung.

Standard: ''30''

Protokoll-Einstellungen

POSTGRESQL_LOG_SETTINGS

Wird diese Option auf ''yes'' gestellt, dann kann mit den folgenden Optionen die Art und Weise beeinflusst werden, wie PostgreSQL Protokollausgaben durchführt. Anderenfalls werden die jeweiligen Standardwerte verwendet.

Standard: ''no''

POSTGRESQL_CLIENT_LOG_LEVEL

Steuert in welcher Detailtiefe Nachrichten an den Client gesendet werden. Gültige Werte sind: DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, LOG, NOTICE, WARNING, ERROR, FATAL und PANIC. Jede Detailebene enthält alle Ebenen die ihr folgen. Die Werte sind in absteigender Folge dargestellt. Je weiter hinten ein Wert ausgewählt wird, je weniger Nachrichten werden gesendet. Es ist zudem zu beachten, dass LOG hier einen anderen Stellenwert hat, als unter SERVER_LOG_LEVEL.

Standard: ''notice''

POSTGRESQL_SERVER_LOG_LEVEL

Steuert in welcher Detailtiefe Nachrichten in das Server-Logfile geschrieben werden. Gültige Werte sind: DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, NOTICE, WARNING, ERROR, LOG, FATAL und PANIC. Jede Detailebene enthält alle Ebenen die ihr folgen. Die Werte sind in absteigender Folge dargestellt. Je weiter hinten ein Wert ausgewählt wird, je weniger Nachrichten werden geschrieben. Es ist zudem zu beachten, dass LOG hier einen anderen Stellenwert hat, als unter CLIENT_LOG_LEVEL.

Standard: ''notice''

POSTGRESQL_LOG_VERBOSE

Steuert ob Einträge im Server-Logfile ausführlich oder normal erfolgen sollen.

Standard: ''no''

POSTGRESQL_LOG_STATEMENTS

Hiermit können SQL-Statements im Server-Logfile mitgeschrieben werden.

Standard: ''no''

Das Paketmenü

PostgreSQL Administration

Official PostgreSQL Documentation

PostgreSQL Tools

PostgreSQL backup and restore

PostgreSQL und Sicherheit

Um die Installation zu erleichtern, ist die Tabelle für den Zugriff auf den Datenbankserver so voreingestellt, dass vom lokalen Rechner aus keine Kennworteingabe erforderlich ist. Für den Betrieb im produktiven oder sicherheitskritischen Umfeld ist diese Voreinstellung jedoch nicht geeignet, da jeder Anwender, der sich auf dem Server anmelden darf, als User ''postgres'' eine Client-Verbindung zum Server herstellen kann und damit vollen administrativen Zugriff auf die Datenbanken hat.

Um diese Sicherheitslücke zu schließen sind folgende Schritte auszuführen:

Schritt 1: Kennwort für den User ''postgres'' festlegen
Über den SQL-interpreter wird dazu das Kommando ALTER USER... wie folgt abgesetzt, wobei ''password'' gegen ein beliebiges Kennwort zu ersetzen ist:

ALTER USER ''postgres'' WITH PASSWORD 'password';

Der Server bestätigt den Befehl mit ''ALTER USER''.

Schritt 2: Lokales Kennwort festlegen
Damit administrative Dienst, wie die Sicherung oder der Autovacuum-Dienst auch in Zukunft mit dem Server ohne Kennworteingabe kommunizieren können, wird das im Schritt 1 angegebene Kennwort im Heimatverzeichnis des Unix-Anwenders ''root'' gespeichert. Dazu sollte man ungedingt als Anwender ''root'' oder ''eis'' an dem Server angemeldet sein. Zum Festlegen des lokalen Kennworts dient der Menüpunkt ''Set password for local access''.

Schritt 3: Zugriff einschränken
In der Konfiguration werden im Abschnitt ''Host access table'' die Einträge für den lokalen Zugriff von ''trust'' auf z. B. ''md5'' gesetzt, wodurch eine Authentifizierung des Clients erzwungen wird.

Methoden Benutzerauthentifizierung

Die Anmeldung am Datenbankserver kann auf unterschiedliche Art erfolgen. Welche Methode verwendet wird, legt dabei die Zugriffstabelle in der Konfiguration fest. Generell gilt, dass das Anmeldekonto auf dem Server als Login-Rolle existieren muss. Lediglich die Überprüfung des Kennworts erfolgt dann auf unterschiedliche Weise. Dabei ist zu unterscheiden zwischen den Methoden, die das Kennwort des Benutzers gegen das Kennwort der Login-Rolle authentifizieren (md5, password, crypt ...) und den Methoden, die einen externen Passwort-Server dazu verwenden (pam, kerberos).

Die empfohlene Methode ist md5, da hier lediglich ein Hash-Wert, nicht aber das Kennwort selbst ausgetauscht wird. Als Kennwort gilt das Kennwort der Login-Rolle.

Ident Authentifizierung

Bei der Ident-Authentifizierung wird kein Kennwort überprüft. Es wird lediglich ein auf dem Client laufender Ident-Daemon angefragt, unter welchem Benutzernamen die Verbindung initiiert wurde. Dieser User sollte dann auf dem Datenbankserver unter dem gleichen Namen eine entsprechende Login-Rolle besitzen.

PAM Authentifizierung

PAM ist eine sehr flexible Möglichkeit der Benutzerauthentifikation, da hier eine zentrale Abstraktionsschicht (die PAM-Konfiguration) festlegt, wie die Authentifizierung erfolgen soll. So kann beispielsweise gegen die lokalen Systemdateien (/etc/passwd, /etc/shadow, /etc/group) ebenso authentifiziert werden, wie über einen LDAP-Server. Allerdings ist dazu etwas Handarbeit nötig:

Bei der Anmeldung über die Systemdateien (/etc/passwd,/etc/shadow,/etc/group) wird unter /etc/pam.d eine Datei mit dem Namen ''postgresql'' und dem folgenden Inhalt angelegt:

#%PAM-1.0
auth       required     pam_unix.so
account    required     pam_unix.so
session    required     pam_unix.so

Desweiteren benötigt der Unix-Account ''postgres'', unter dessen User-ID der Datenbankserver läuft, einen Lesezugriff auf die Datei /etc/shadow, die normalerweise nur von ''root'' gelesen weden kann. Die wohl eleganteste Methode dazu ist, eine Gruppe für den Lesezugriff einzurichten und den User ''postgres'' darin aufzunehmen. Dann wird die Gruppenzugehörigkeit der Datei /etc/shadow geändert und das Lesebit für die Gruppe gesetzt. Beispiel:

Gruppe: shadowreaders Mitglied: postgres

chown root.shadowreaders /etc/shadow chmod g+r /etc/shadow

Quelle: http://itc.musc.edu/wiki/PostgreSQL Hier findet sich auch eine Anleitung für LDAP über PAM.

Sicherung und Wiederherstellung

Es kann entwerder manuell über das Menü oder automatisch per CRON-Daemon eine Sicherung von Datenbanken vorgenommen werden. Im Falle der manuellen Sicherung wird dazu der Menüpunkt ''Backup database'' im Untermenü ''PostgreSQL Tools'' gewählt und anschließend die Datenbank angegeben, die gesichert werden soll. Die Sicherungsdatei wird in dem Verzeichnis abgelegt, das in der Konfiguration für POSTGRESQL_BACKUP_TARGET angegeben wurde. Die Standardeinstellung ist '/var/lib/pgsql_backup'.

Im Falle der automatischen Sicherung per CRON-Daemon wird in der Paketkonfiguration angegeben, welche Datenbanken zu sichern sind, wieviele Kopien der Sicherungsdatei aufbewahrt werden sollen und wann die Sicherung stattfinden soll. Zudem kann eine E-mail-Adresse angegeben werden, an die im Fehlerfall eine Nachricht verschickt wird.

Der Dateiname wird bei beiden Sicherungsvarianten wie folgt zusammengesetzt:

datenbank_name-datum_iso-zeit.backup

Das ISO-Datumsformat: JJJJ-MM-TT
Zeitformat: HHMMSS

Beispiele:
-rw-r-r- 1 root root 4309287 Oct 29 00:31 testdb-2005-10-29-003003.backup
-rw-r-r- 1 root root 4309287 Oct 30 00:31 testdb-2005-10-30-003004.backup

Zur Wiederherstellung der Daten einer Sicherungsdatei wird zunächst eine leere Datenbank, sowie alle erforderlichen Datenbankanwender angelegt. Anschließend kann die Wiederherstellung über den Menüpunkt ''Restore database'' vorgenommen werden.

Zuerst erfolgt eine Auswahl einer Datei aus dem unter POSTGRESQL_BACKUP_TARGET angegebenen Verzeichnis, dann wird als Ziel der Operation die neu angelegte Datenbank ausgewählt.

Wie üblich gilt auch hier: Es ist besser nicht blind der Sicherung zu vertrauen, sondern die Wiederherstellung der Daten auszuprobieren, bevor es zum GAU kommt.

PostgreSQL Administrator

Die skriptbasierte Datenbankverwaltung wurde durch ein curses-basiertes Administrationsprogramm ersetzt, welches einfacher zu bedienen und in Zukunft leichter zu erweitern ist.

Nach dem Programmstart wird ein Anmeldedialog gezeigt, über den man sich am Datenbankserver anmelden kann. Standardmäßig gibt es keine Zugriffsbegrenzung für den lokalen Zugriff (über Unix-Sockets), sodass der Dialog einfach mit ENTER bestätigt werden kann. Gleiches gilt wenn über ''Set local password'' ein Kennwort für den jeweiligen Anwender hinterlegt wurde.

Das Programm hat ein dreigeteiltes Layout: Auf der linken Seite ist ein Auswahlmenü angebracht, über das die einzelnen Programmbereiche erreicht werden. Im rechten oberen Bereich befindet sich die Übersichtsliste der Datenbankobjekte, die im jeweiligen Programmbereich bearbeitet werden. Im rechten unteren Bereich ist ein Hilfefenster angebracht, das spezifische Hilfe zum jeweiligen Programmbereich enthält.

Der Eingabefocus läßt sich mit der TAB-Taste im gesamten Programm verschieben und die im jeweiligen Programmbereich aktiven Funktionen sind über Funktionstasten direkt zu erreichen. Siehe dazu auch die Hinweise in der Statusleiste des Programms am unteren Rand.

Damit das Programm auch ohne Funktionstasten zu bedienen ist, sind alle Funktionen zusätzlich über ein Menü erreichbar. Dazu bewegt man den Eingabecursor auf die Übersichtsliste und drückt dort die ENTER-Taste. Verlassen kann man das Programm über die F10 Taste oder mit Hilfe der Menüs.

PostgreSQL Module (Information für Paketentwickler)

Um für zukünftige Erweiterungen offen zu sein, sieht PostgreSQL in seiner Menüstruktur eine Schnittstelle vor, die von Erweiterungspaketen verwendet werden kann. Dazu muss lediglich im Menüverzeichnis unter ''/var/install/menu'' eine Datei abgelegt werden, die der folgenden Namenskonvention entspricht:

setup.services.postgresql.modules.<paketname>.menu

Diese Datei wird beim Öffnen dynamisch in das Modulmenü eingebunden. Dazu sollten aber in der Menüdatei unbedingt die Tags <package> und <title> definiert sein.

Der Vorteil der dynamischen Bindung ist, dass Erweiterungsmodule zur Lauf- zeit ermittelt werden und bei einem Update des Datenbankservers nicht mehr verloren gehen können.

In Zukunft wird es weitere Schnittstellen geben, die z. B. Erweiterungen zum PostgreSQL Administrator anbieten. Da hier jedoch die Anforderungen noch nicht bekannt sind, werden diese Schnittstellen erst bei Bedarf implementiert.

eis 2017-05-03