Sie befinden sich hier: eisfair / Pack-Eis
News News News

Navigation

Content

Dateianzeige für postgresql84 (2.0.0)

usr/share/doc/postgresql84/postgresql84.txt
PostgreSQL 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. </div> </div> </div> </div> <div id='footer'> <a href='mailto:team@eisfair.org'> © eisfair-Team 2024 </a></div> </div> </div> </div> </body> </html>