Content
Dateianzeige für postgresql84 (2.0.0)
usr/share/doc/postgresql84/postgresql84.txtPostgreSQL 8.4 fuer eisfair Documentation
Erstellt: 2009-04-11 Daniel Vogel
Letzte Aenderung: $Id: postgresql.txt 24511 2010-06-12 21:17:03Z dv $
------------------------------------------------------------------------------
PostgreSQL
Inhalt
------
1 Allgemein
2 Installation
3 Konfiguration
3.1 Allgemeine Einstellungen
3.2 Zugriffstabelle
3.3 Sicherung
3.4 Automatische Optimierung
3.5 Leistung und Resourcenverbrauch
3.6 Write-Ahead Logging (WAL)
3.7 Protokoll-Einstellungen
4 Das Paketmenue
4.1 PostgreSQL administration
4.2 Official PostgreSQL documentation
4.3 PostgreSQL tools
4.4 PostgreSQL backup and restore
5 PostgreSQL und Sicherheit
6 Methoden Benutzerauthentifizierung
6.1 Ident Authentifizierung
6.2 PAM Authentifizierung
7 Sicherung und Wiederherstellung
8 PostgreSQL Administrator
9 PostgreSQL Module
1 Allgemein
-----------
PostgreSQL ist ein sehr leistungsfaehiges relationales Datenbanksystem
das in seiner Funktionsvielfalt kaum Wuensche offen laesst. Dazu gehoert
eine vollstaendige Unterstuetzung von Foreign Keys, Joins, Views, Triggers
und Stored Procedures. Es stehen die meisten Datentypen der Standards SQL92
und SQL99 zur Verfuegung sowie auch die Speicherung von Daten in Binary
Large Objects (BLOBS).
Zur Anbindung von Client-Applikationen sind Programmierschnittstellen
fuer 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
ermoeglicht.
PostgreSQL ist mit einer sehr ausfuehrlichen Dokumentation ausgestattet,
die diesem Paket beigefuegt wurde. Zu beachten ist dabei, dass die
Konfiguration des Datenbankservers auf eisfair ueber die eisfair
Konfigurationsschnittstelle erfolgt und nicht, wie im Kapitel "Server
Administration" beschrieben, direkt mit den Konfigurationsdateien des
Programms gearbeitet werden sollte. Da das Kapitel aber 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".
2 Installation
--------------
Das Installationsskript fuehrt die Installation des Datenbankservers aus,
ohne dass weitere Angaben noetig 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 uebernommen,
solange diese kompatibel zur neuen Version von PostgreSQL sind. Dies ist
immer dann der Fall, wenn sich die unterste Versionsnummer des Datenbank-
servers aendert.
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 Fall eines Kompatibilitaetskonflikts wird die Installation abgebrochen.
Es muss in diesem Fall ein vollstaendiges Backup ausgefuehrt und anschliessend
das alte Paket deinstalliert werden. Nach der Installation der neuen Version
koennen dann die gesicherten Datenbanken wieder eingespielt werden. Aus
Sicherheitsgruenden wird dieser Vorgang nicht automatisiert (siehe "Sicherung
und Wiederherstellung")
3 Konfiguration
---------------
Die Konfiguration von PostgreSQL unter eisfair erfolgt ueber den Menuepunkt
"Edit configuration" im Paketmenue. Die vorgenommenen Aenderungen werden nach
Beenden des Editors automatisch uebernommen. Achtung: Dabei wird der Server
neu gestartet und alle Client-Verbindungen getrennt.
3.1 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 ueber das Paketmenue jederzeit moeglich.
Gueltige Werte: "yes", "no"
POSTGRESQL_NETWORKING
Hiermit wird festgelegt, ob der Datenbankdienst ueber das Netzwerk er-
reichbar 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
moeglich. Zu beachten ist aber, dass zusaetzlich die Zugriffstabelle
(Host access table) bestimmt, welche Verbindungen erlaubt sind und welche
nicht.
Gueltige Werte: "yes", "no"
POSTGRESQL_SERVER_PORT
Fuer den lokalen Zugriff auf den Datenbankserver koennen 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 Daten-
bankserver moeglich sein sollen. Diese Zahl bestimmt den Speicherbedarf
des Programms und kann aus oekonomischen Grunden angepasst werden.
Dabei ist zu beachten, dass auch der "Autovacuum-Dienst" und die auto-
matische Datensicherung jeweils einen eigenen Zugriff erfordern.
Standard: "100"
3.2 Zugriffstabelle
-------------------
POSTGRESQL_HOST_N
Anzahl der Eintraege in der Zugriffstabelle (Host access table).
Ueber 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 ueber einen Unix-Domain-Socket
(local) oder ein Netzwerkzugriff ueber TCP/IP (host) beschrieben werden
soll.
Gueltige 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 fuer 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 benoetigt kein Kennwort - ihm wird immer vertraut.
"reject": Der Client darf sich nicht anmelden.
"md5": Der Client tauscht sein Kennwort mit dem Server ueber eine
md5 Checksumme aus (empfohlen).
"crypt": Der Client schickt sein Kennwort verschluesselt 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 ueber Ident.
"pam": Die Anmeldung erfolgt ueber PAM.
Siehe hierzu auch "PostgreSQL und Sicherheit"
POSTGRESQL_HOST_x_DATABASE
Gibt an, fuer welche Datenbank dieser Eintrag in der Zugriffstabelle gilt.
Mit "all" werden alle Datenbanken zugleich angegeben.
Beispiel: "all"
POSTGRESQL_HOST_x_USER
Gibt an, fuer welchen Datenbankanwender dieser Eintrag in der Zugriffs-
tabelle gueltig ist. Mit "all" werden alle bekannten Anwender zugleich
angegeben.
Beispiel: "all"
3.3 Sicherung
-------------
POSTGRESQL_BACKUP_SCHEDULE
Zeitvorgabe fuer den CRON-Dienst. Hier wird angegeben, wann die auto-
matische Sicherung durchgefuehrt werden soll. Die 5 Werte stehen fuer:
Minute, Stunde, Tag, Monat, Wochentag.
Beispiel: "30 0 * * *" --> taeglich 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:
--.backup
Beispiel: "2"
POSTGRESQL_BACKUP_x_DBNAME
Name der Datenbank, die gesichert werden soll.
POSTGRESQL_BACKUP_x_USER
Name des Datenbankanwenders, der ausreichende Zugriffsrechte fuer 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 ausge-
fuehrt. Dies kann verwendet werden, um beispielsweise das Sicherungs-
medium in das Dateisystem einzubinden.
Soll kein Befehl ausgefuehrt 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
Empfaenger. Soll keine Benachrichtigung erfolgen bleibt das feld leer.
Hinweis: Die Benachrichtigung funktioniert nur dann, wenn das E-mail
Paket installiert ist.
Beispiel: "dbadmin@localhost"
3.4 Automatische Optimierung
----------------------------
Mit der Zeit kann es bei Datenbanken zu einer gewissen Fragmentierung
kommen, die zum Teil zu spuerbaren Einbruechen in der Leistungsfaehigkeit des
Servers fuehren kann. Darum empfiehlt es sich bei PostgreSQL in regel-
maessigen Abstaenden 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 ueberwacht und die Tabellen ggf. selbststaendig
optimiert. Dieser wird wie folgt konfiguriert:
POSTGRESQL_AUTOVACUUM
Gibt an, ob der Autovacuum-Dienst mit dem Datenbankserver gestartet
werden soll.
Gueltige Werte: "yes" "no"
3.5 Leistung und Resourcenverbrauch
-----------------------------------
POSTGRESQL_RESOURCE_TUNING
Der PostgreSQL-Server kennt eine Reihe von Konfigurationseinstellungen
ueber die der Resourcenverbrauch und die Leistungsfaehigkeit des Servers
beeinflusst werden koennen. Einige dieser Einstellungen sind auch fuer
PostgreSQL auf eisfair verfuegbar und koennen verwendet werden, wenn
RESOURCE_TUNING auf "yes" gestellt wurde. Bei "no" verwendet der
Server die jeweiligen Standardeinstellungen.
Standard: "no"
POSTGRESQL_SHARED_MEM
Legt die Groesse des Shared-Memory Speichers fest, der vom Datenbank-
server verwendet werden soll. Die Standardeinstellung liegt fuer
PostgreSQL auf eisfair typischerweise bei 16MB.
Die angegebene Groesse muss mindestens 128kB betragen und zugleich
groesser als MAX_CONNECTIONS * 16kB sein. Allerdings sind ueblicher-
weise deutlich hoehere Werte erforderlich, um eine gute Leistung
des Servers zu erhalten.
Fuer produktive Systeme werden Werte von einigen tausend Buffern
empfohlen.
Bei der Angabe der Speichergroesse koennen optional die Postfixe
"kB" und "MB" verwendet werden. Achtung: Ohne Postfix wird der Wert in
8kB Bloecken interpretriert.
Standard: "16MB"
POSTGRESQL_TEMP_MEM
Legt die Groesse des Speichers fest, der von jeder Datenbank-
sitzung verwendet werden soll. Es handelt sich hierbei um
lokale, auf die Sitzung beschraenkte Speicherbereiche fuer den
Zugriff auf temporaere Tabellen.
Eine Sitzung allokiert nach Bedarf temporaeren Speicher bis zum
eingestellten Limit in Blockgroessen von 8200 Byte. Der Speicherbedarf
fuer einen grossen TEMP_MEM-Wert bei Sitzungen, die diesen Speicher-
bereich nicht nutzen, liegt bei 64 Byte pro allokierbarem Buffer.
Erst wenn ein Buffer tatsaechlich verwendet wird, kommen dazu nochmal
jeweils 8192 Byte hinzu.
Bei der Angabe der Speichergroesse koennen optional die Postfixe
"kB" und "MB" verwendet werden. Achtung: Ohne Postfix wird der Wert in
8kB Bloecken interpretriert.
Standard: "8MB"
POSTGRESQL_WORK_MEM
Gibt die Groesse des Speichers an, der fuer interne Sortieroperationen
und Hash-Tabellen verwendet wird, bevor Daten in temporaere Dateien
ausgelagert werden.
Es ist zu beachten, dass bei komplexen Abfragen mehrere Sortier-
oder Hash-Operationen parallel laufen koennen und damit der hier
angegebene Speicher mehrfach angefordert wird. Zudem koennen
mehrere Datenbanksitzungen solche Operationen gleichzeitig durch-
fuehren. Darum kann der tatsaechliche Speicherbedarf ein ein viel-
faches des in WORK_MEM angegebenen Wertes betragen.
Bei der Angabe der Speichergroesse koennen optional die Postfixe
"kB" und "MB" verwendet werden. Achtung: Ohne Postfix wird der Wert in
1kB Bloecken interpretriert.
Standard: "1MB"
POSTGRESQL_MAINTAIN_MEM
Gibt die Groesse des Speichers an, der fuer interne Verwaltungsaufgaben
wie VACUUM, CREATE INDEX oder ALTER TABLE ADD FOREIGN KEY wendet wird.
Da eine Datenbanksitzung immer nur einen solchen Befehl gleichzeitig
ausfuehren kann und solche Operationen ueblicherweise selten von mehreren
Sitzungen gleichzeitig ausgefuehrt werden, ist es sicher, diesen Wert
hoeher als WORK_MEM einzustellen.
Bei der Angabe der Speichergroesse koennen optional die Postfixe
"kB" und "MB" verwendet werden. Achtung: Ohne Postfix wird der Wert in
1kB Bloecken interpretriert.
Standard: "8MB"
POSTGRESQL_PREP_TRANSACTIONS
Legt die maximale Anzahl von Transaktionen fest, die sich gleich-
zeitig im Zustand "prepared" befinden duerfen. Beim Setzen des
Wertes auf 0 wird die Funktionalitaet 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
Fehlschlaege beim "prepare"-Schritt vermieden werden.
Falls der von PostgreSQL hierbei angeforderte Speicher ueber dem
vom Betriebsystem vorgegebenen Limit fuer System V Shared-
Memory liegt, ist wie unter SHARED_BUFFERS beschrieben vorzu-
gehen, um den Engpass zu beheben.
Standard: "5"
3.6 Write-Ahead Logging (WAL)
-----------------------------
POSTGRESQL_WAL_TUNING
Das Write-Ahead Logging ist ein Mechanismus zur Verbesserung der
Serverleistung bei Datenbanktransaktionen. Das Schluesselkonzept
dabei ist, dass modifizierte Daten (bzw. Datenbereiche) nicht so-
fort nach dem Abschluss eine Transaktion auf die Platte geschrieben
werden, sondern erst dann, wenn ein sogenannter Checkpoint erreicht
wird. In der Zwischenzeit werden alle durchgefuehrten Transaktionen
in ein WAL-Segment (Datei auf der Festplatte) geschrieben und koennen
im Falle eines Systemabsturzes wiederholt werden.
Es gibt eine Reihe von Einstellungen, die das Verhalten des Write-
Ahead Loggings beeinflussen. Einige dieser Einstellungen wurden
fuer PostgreSQL auf eisfair verfuegbar gemacht und koennen veraendert
werden, wenn POSTGRESQL_WAL_TUNING den Wert "yes" erhaelt. Anderen-
falls 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 fuehrt der Funktionsaufruf von fsync() zu einem nicht
unerheblichen Leistungsengpass, da PostgreSQL nach jedem Abschluss
einer Transaktion darauf warten muss, dass das Write-Ahead Log
vollstaendig 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.ae. Daten verloren gehen koennen oder die Datenbank
inkonsistent wird.
Wegen des damit verbundenen Risikos gibt es keine universell korrekte
Einstellung fuer diesen Wert.
Standard: "yes" (maximale Zuverlaessigkeit)
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. Fuer PostgreSQL auf eisfair sind die folgenden
Werte zulaessig:
fsync: Gesamte Dateiinformation auf die Platte schreiben.
fdatasync: Nur den Datenbereich (keine Metadaten) auf die Platte
schreiben.
Standard: "fsync"
POSTGRESQL_WAL_DATA_MEM
Groesse 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 ge-
schrieben werden.
Bei der Angabe der Speichergroesse koennen optional die Postfixe
"kB" und "MB" verwendet werden. Achtung: Ohne Postfix wird der Wert in
8kB Bloecken interpretriert.
Standard: "64kB"
POSTGRESQL_COMMIT_DELAY
Zeitverzoegerung in Mikrosekunden um die der Schreibvorgang in die
WAL-Datei verzoegert werden kann. Ein Wert ungleich Null kann es
ermoeglichen, dass mehrere Transaktionen gemeinsam mit einem fsync()
Aufruf auskommen. Die dazu erforderliche annaeherungsweise Gleich-
zeitigkeit der Transaktionen ist nur bei sehr hoher Systemlast
gegeben, anderenfalls ist die Verzoegerung nur verschenkte Zeit.
Darum wird nur dann gewartet, wenn sich COMMIT_SIBLINGS Transaktio-
nen gleichzeitig in der Bearbeitung befinden.
Standard: "0" (keine Verzoegerung)
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 gross ist).
Der Datenbankserver erzeugt immer dann automatisch Checkpoints, wenn
entwerder CHECKPOINT_SECTIONS Segmente ueberschritten 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 haeufiger, wodurch eine Wiederherstellung nach
einem Systemausfall beschleunigt wird. Allerdings entsteht durch das
haeufigere Schreiben veraenderter Speicherseiten (das durch einen Check-
point ausgeloest wird) eine hoehere Systemlast.
Die Anzahl der WAL-Segmentdateien auf der Platte liegt zwischen einem
und 2 * CHECKPOINT_SECTIONS + 1. Dabei hat jede Datei eine Groesse von
16 MB.
Standard: "3"
POSTGRESQL_CHECKPOINT_TIMEOUT
Maximale Zeit zwischen automatisch erzeugten WAL Checkpoints in
Sekunden. Siehe hierzu auch die Erlaeuterungen 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 Fuellen von WAL-
Segmenten naeher als CHECKPOINT_WARNING Sekunden beieinander liegt.
Das kann bedeuten, dass CHECKPOINT_SECTIONS erhoeht werden sollte.
Ein Wert von "0" deaktiviert die Warnung.
Standard: "30"
3.7 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 Protokoll-
ausgaben durchfuehrt. Anderenfalls werden die jeweiligen Standardwerte
verwendet.
Standard: "no"
POSTGRESQL_CLIENT_LOG_LEVEL
Steuert in welcher Detailtiefe Nachrichten an den Client gesendet wer-
den. Gueltige Werte sind: DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, LOG,
NOTICE, WARNING, ERROR, FATAL und PANIC. Jede Detailebene enthaelt
alle Ebenen die ihr folgen. Die Werte sind in absteigender Folge dar-
gestellt. Je weiter hinten ein Wert ausgewaehlt wird, je weniger Nach-
richten werden gesendet. Es ist zudem zu beachten, das 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 ge-
schrieben werden.
Gueltige Werte sind: DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, NOTICE,
WARNING, ERROR, LOG, FATAL und PANIC. Jede Detailebene enthaelt
alle Ebenen die ihr folgen. Die Werte sind in absteigender Folge dar-
gestellt. Je weiter hinten ein Wert ausgewaehlt wird, je weniger Nach-
richten werden geschrieben. Es ist zudem zu beachten, das LOG hier einen
anderen Stellenwert hat, als unter CLIENT_LOG_LEVEL.
Standard: "notice"
POSTGRESQL_LOG_VERBOSE
Steuert ob Eintraege im Server-Logfile ausfuehrlich oder normal erfolgen
sollen.
Standard: "no"
POSTGRESQL_LOG_STATEMENTS
Hiermit koennen SQL-Statements im Server-Logfile mitgeschrieben werden.
Standard: "no"
4 Das Paketmenue
----------------
4.1 PostgreSQL administration
-----------------------------
* View eisfair documentation
Dokumentation zum Paket PostgreSQL auf eisfair anzeigen.
* View project documentation
Untermenue: Die Dokumentation von PostgreSQL in mehreren Kapiteln.
* Edit configuration
Konfiguration des Datenbankservers ueber die eisfair-Konfigurations-
ebene bearbeiten.
* Advanced configuration file handling
Versionsverwaltung der Konfiguration des Datenbankservers.
* Start PostgreSQL server
Den Datenbankdienst starten.
* Stop PostgreSQL server
Den Datenbankdienst beenden.
* Show status and connects
Den aktuellen Status des Servers und die aktiven Client Verbindungen zu
diesem anzeigen.
* PostgreSQL tools
Untermenue: Eine Sammlung von Werkzeugen zur Verwaltung von Datenbanken.
4.2 Official PostgreSQL documentation
-------------------------------------
* Preface
Einleitendes Kapitel, das die grundlegenden Konzepte und die Historie
von PostgreSQL erlaeutert (englisch).
* Tutorial
Eine einfache Einfuehrung in den Umgang mit dem Datenbankserver (englisch).
* The SQL Language
Eine umfassende Beschreibung der Abfragesprache SQL wie sie von PostgreSQL
verarbeitet wird (englisch).
* Server Administration
Administration des Datenbankservers. Dieses Kapitel soll lediglich Hinter-
grundinformationen liefern. Die Administration des Servers wird weitest-
gehend ueber die eisfair-Schnittstelle vorgenommen (englisch).
* Client Interfaces
Fuehrt in die verfuegbaren Programmierschnittstellen fuer Datenbank-Client-
Anwendungen ein. Fuer eisfair muss dazu das Paket postgresql-dev installiert
sein, damit die notwendigen Header- und Bibliotheksdateien auf dem Rechner
vorhanden sind (englisch).
* Server Programming
Fuehrt in die Programmierung von Stored-Procedures in unterschiedlichen
Sprachen ein (englisch).
* Reference
Eine Referenz alle SQL-Schluesselworte und Befehle (englisch).
* Internals
Eine Einfuehrung in die interne Struktur von PostgreSQL (englisch).
* Appendixes
Einige Anhaenge (englisch).
4.3 PostgreSQL tools
--------------------
* Database Administrator
Start des curses basierten Programms fuer die Verwaltung von Datenbanken,
Anmelderollen und Gruppenrollen. Siehe Kapitel 7 fuer weitere Einzelheiten.
* Database Administrator (remote)
Start des curses basierten Programms fuer die Verwaltung von Datenbanken,
Anmelderollen und Gruppenrollen. Siehe Kapitel 7 fuer weitere Einzelheiten.
Mit der "remote"-Option ist ein Zugriff ueber das Netzwerk auf entfernte
Datenbankserver moeglich.
* Backup and restore
Untermenue: Hier koennen Datenbanken gesichert und wiederhergestellt
werden.
* Set local password
Hier kann ein Kennwort fuer den loklen Zugriff von administrativen Diensten
(z. B. Sicherung, Autovacuum ...) festgelegt werden.
* Start SQL interpreter
Start eines Programms zur direkten Eingabe von SQL-Befehlen.
4.4 PostgreSQL backup and restore
---------------------------------
* Backup database
Hiermit kann eine einzelne Datenbank in eine Datei im Sicherungsverzeichnis
manuell gesichert werden.
* Restore database
Hier wird die Wiederherstellung einer Datenbank aus einer Sicherung vorge-
nommen. Zuvor muessen eine leere Datenbak und alle erforderlichen Datenbank-
anwender angelegt sein!
* List backup files
Auflistung aller Sicherungsdateien im Sicherungsverzeichnis in chronologischer
Reihenfolge.
5 PostgreSQL und Sicherheit
---------------------------
Um die Installation zu erleichtern, ist die Tabelle fuer den Zugriff auf den
Datenbankserver so voreingestellt, dass vom lokalen Rechner aus keine
Kennworteingabe erforderlich ist. Fuer 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 Sicherheitsluecke zu schliessen sind folgende Schritte auszufuehren:
Schritt 1: Kennwort fuer den User 'postgres' festlegen
Ueber den SQL-interpreter wird dazu das Kommando ALTER USER... wie folgt
abgesetzt, wobei 'password' gegen ein beliebiges Kennwort zu ersetzen
ist:
template1=# ALTER USER "postgres" WITH PASSWORD 'password';
Der Server bestaetigt 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 koennen,
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 Menuepunkt "Set password for
local access".
Schritt 3: Zugriff einschraenken
In der Konfiguration werden im Abschnitt "Host access table" die Eintraege
fuer den lokalen Zugriff von "trust" auf z. B. "md5" gesetzt, wodurch eine
Authentifizierung des Clients erzwungen wird.
6 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 Ueberpruefung des
Kennworts erfolgt dann auf unterschiedliche Weise. Dabei ist zu unter-
scheiden 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.
6.1 Ident Authentifizierung
===========================
Bei der Ident-Authetifizierung wird kein Kennwort ueberprueft. Es wird lediglich
ein auf dem Client laufender Ident-Daemon angefragt, unter welchem Benutzer-
namen die Verbindung initiiert wurde. Dieser User sollte dann auf dem
Datenbankserver unter dem gleichen Namen eine entsprechende Login-Rolle
besitzen.
6.2 PAM Authentifizierung
=========================
PAM ist eine sehr flexible Moeglichkeit 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 ueber einen LDAP-Server. Allerdings ist dazu etwas Handarbeit
noetig:
Bei der Anmeldung ueber die Systemdateien (/etc/passwd,/etc/shadow,/etc/group)
wird unter /etc/pam.d eine Datei mit dem Namen "postgresql" und dem folgen-
den Inhalt angelegt:
#%PAM-1.0
auth required pam_unix.so
account required pam_unix.so
session required pam_unix.so
Desweiteren benoetigt der Unix-Account "postgres", unter dessen User-ID der
Datenbankserver laeuft, einen Lesezugriff auf die Datei /etc/shadow, die
normalerweise nur von "root" gelesen weden kann. Die wohl eleganteste
Methode dazu ist, eine Gruppe fuer den Lesezugriff einzurichten und den
User "postgres" darin aufzunehmen. Dann wird die Gruppenzugehoerigkeit der
Datei /etc/shadow geaendert und das Lesebit fuer die Gruppe gesetzt. Beispiel:
Gruppe: shadow
Mitglied: postgres
chown root.shadow /etc/shadow
chmod g+r /etc/shadow
Quelle: http://itc.musc.edu/wiki/PostgreSQL
Hier findet sich auch eine Anleitung fuer LDAP ueber PAM.
WICHTIG: Auf eisfair-1 ist ab der Version 1.6.6 des Basissystems die Gruppe
shadow bereits eingerichtet und auch die Berechtigungen auf die Datei
/etc/shadow sind bereits gesetzt. Es genuegt hier, den User postgres in
die Gruppe shadow aufzunehmen.
7 Sicherung und Wiederherstellung
=================================
Es kann entwerder manuell ueber das Menue oder automatisch per CRON-Daemon
eine Sicherung von Datenbanken vorgenommen werden. Im Falle der manuellen
Sicherung wird dazu der Menuepunkt "Backup database" im Untermenue "Post-
greSQL Tools" gewaehlt und anschliessend die Datenbank angegeben, die ge-
sichert werden soll. Die Sicherungsdatei wird in dem Verzeichnis abgelegt,
das in der Konfiguration fuer POSTGRESQL_BACKUP_TARGET angegeben wurde. Die
Standardeinstellung ist '/var/lib/pgsql_backup'.
Im Falle der automatischen Sicherung per CRON-Daemon wird in der Paket-
konfiguration 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 Dateinamen wird bei beiden Sicherungsvarianten wie folgt zusammen-
gesetzt:
--.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 zunaechst eine
leere Datenbank, sowie alle erforderlichen Datenbankanwender angelegt.
Anschliessend kann die Wiederherstellung ueber den Menuepunkt "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 ausgewaehlt.
Wie ueblich gilt auch hier: Es ist besser nicht blind der Sicherung zu ver-
trauen, sondern die Wiederherstellung der Daten auszuprobieren, bevor es
zum GAU kommt.
8 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, ueber den man sich
am Datenbankserver anmelden kann. Standardmaessig gibt es keine Zugriffsbe-
grenzung fuer den lokalen Zugriff (ueber Unix-Sockets), so dass der Dialog
einfach mit ENTER bestaetigt werden kann. Gleiches gilt wenn ueber "Set local
password" ein Kennwort fuer den jeweiligen Anwender hinterlegt wurde.
Das Programm hat ein dreigeteiltes Layout: Auf der linken Seite ist ein
Auswahlmenue angebracht, ueber das die einzelnen Programmbereiche erreicht
werden. Im rechten oberen Bereich befindet sich die Uebersichtsliste der
Datenbankobjekte, die im jeweiligen Programmbereich bearbeitet werden. Im
rechten unteren Bereich ist ein Hilfefenster angebracht, das spezifische
Hilfe zum jeweiligen Programmbereich enthaelt.
Der Eingabefocus laesst sich mit der TAB-Taste im gesamten Programm ver-
schieben und die im jeweiligen Programmbereich aktiven Funktionen sind ueber
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 zusaetzlich ueber ein Menue erreichbar. Dazu bewegt man den Eingabe-
cursor auf die Uebersichtsliste und drueckt dort die ENTER-Taste. Verlassen
kann man das Programm ueber die F10 Taste oder mit Hilfe der Menues.
9 PostgreSQL Module (Information fuer Paketentwickler)
=====================================================
Um fuer zukuenftige Erweiterungen offen zu sein, sieht PostgreSQL in seiner
Menuestruktur eine Schnittstelle vor, die von Erweiterungspaketen verwendet
werden kann. Dazu muss lediglich im Menueverzeichnis unter "/var/install/menu"
eine Datei abgelegt werden, die der folgenden Namenskonvention entspricht:
setup.services.postgresql.modules..menu
Diese Datei wird beim Oeffnen dynamisch in das Modulmenue eingebunden. Dazu
sollten aber in der Menuedatei unbedingt die Tags und
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 koennen.
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.