next up previous contents index
Nächste Seite: Das ProFTPD Paket Aufwärts: eisfair-Dokumentation Vorherige Seite: Das phpPgAdmin-Paket   Inhalt   Index

Unterabschnitte


Der PostgreSQL Datenbank Server

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 auf der Homepage des Projekts zu finden ist. 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.

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 notwendig sind.

Zu beachten ist, dass das PostgreSQL-Paket ab der Versio 9.6.5 in versionierter Form angeboten wird. Damit ist gemeint, dass an den Paket- namen zukünftig die Major- und Minor-Nummer der Paketversion angefügt wird. So wird aus ”postgresql” beispielsweise ”postgresql96”.

Dies hat eine Reihe von Konsequenzen:

Nach der Installation ist das Paketmenü unterhalb des Menüpunkts ”Database server administration” zu finden.

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_DATADIR

Die Einstellung legt fest, unterhalb welchem Pfad das Verzeichnis angelegt werden soll, innerhalb dessen die Daten der Datenbanken abgelegt werden sollen. Stellt die Konfigurationsschicht fest, dass das angegebenen Verzeichnis noch nicht existiert, dann wird es automatisch angelegt und es wird ein neuer Datenbank-Cluster initialisiert.

Beispiel: ”/var/lib/pgsql96”

POSTGRESQL_ENCODING

Hier wird die Zeichenkodierung eingestellt, mit der der oben angegebene Speicherort für Datenbanken initialisiert werden soll. Zugleich ist dies die Standardeinstellung für neu erzeugte Datenbanken. Zu beachten ist, dass diese Einstellung nur dann wirksam wird, wenn der Speicherort erstmalig initialisiert wird, was normalerweise nur einmalig nach der Installation und der Aktvierung der Konfiguration der Fall ist. Ebenso findet die Initialisierung statt, wenn ein anderer leerer Speicherort (siehe oben) gewählt wird.

Beispiel: ”LATIN9”

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_CONNECT_PORT

Dies ist die Anschlussnummer, über die der Datenbankserver über das Netzwerk erreichbar ist, sobald POSTGRESQL_NETWORKING dies zulässt. Die Nummer beeinflusst ebenfalls den Namen der benannten Pipe, über die lokal auf den Server zugegriffen werden kann. Bitte unbedingt beachten: Sobald mehrere Versionen von PostgreSQL auf einem Rechner gleichzeitig ausgeführt werden sollen, müssen sich diese Server hinsichtlich der Anschlussnummer unterscheiden! Anderenfalls wird mindestens einer der Dienste nicht lauffähig sein bzw. nicht erreicht werden können.

Standard: ”5432”

POSTGRESQL_CONNECTIONS

Hiermit wird definiert, wieviele gleichzeitige Verbindungen auf den Datenbankserver möglich sein sollen. Diese Zahl bestimmt den Speicherbedarf des Programms und kann aus ökonomischen Gründen angepasst werden. Dabei ist zu beachten, dass auch der ”Autovacuum-Dienst” und die automatische Datensicherung jeweils eine eigene Verbindung erfordern.

Standard: ”10”

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”

Leistung und Resourcen-Verteilung

POSTGRESQL_AUTOVACUUM

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ässigen 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.

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

POSTGRESQL_MEMORY_LAYOUT

Wie bei den meisten Datenbankservern hat auch bei PostgreSQL die Zuteilung von Arbeitsspeicher einen grossen Einfluss auf die Arbeitsgeschwindigkeit des Dienstes. Zugleich sollte die Zuteilung so erfolgen, dass auch für die übrigen Dienste dieses Systems ausreichend Speicher zur Verfügung steht.

Damit die Konfiguration nicht unnötig verkompliziert wird, stehen seitens der eisfair-Konfiguration vier verschiedene Speicherprofile zur Verfügung. Abhängig vom vorhandenen Arbeitsspeicher kann nach der folgenden Tabelle daraus gewählt werden:

”small”: Für Systeme mit bis zu 512MB RAM.
”medium”: Für System mit 512MB bis 2GB RAM.
”large”: Für Systeme mit 2GB bis 4GB RAM.
”huge”: Für Systeme ab 4GB RAM.

Innerhalb der Serverkonfiguration wird der Speicher anschliessend wie folgt aufgeteilt: 

            shared_buffers  temp_buffers  work_mem   maintenance_work_mem
    small   16MB            4MB           1MB        8MB
    medium  128MB           8MB           4MB        64MB
    large   256MB           16MB          8MB        128MB
    huge    512MB           32MB          16MB       256MB

Beispiel: ”medium”

POSTGRESQL_WRITE_MODE

Auch die Art und Weise, wie und wann die Daten auf die Festplatte geschrieben werden, hat einigen Einfluss auf die Arbeitsgeschwindigkeit des Servers. Der Anwender hat dabei die Wahl innerhalb von vier Stufen einen Kompromiss zwischen einer sehr sicheren, aber langsamen oder einer sehr schnellen, dafür aber unsicheren Arbeitsweise zu wählen. Die Sicherheit bezieht sich dabei auf die Konsistenz der Datenbanken im Fall eines plötzlichen unerwarteten Stromausfalls.

”secure” = sehr sicher aber langsam.
”normal” = im Zweifelsfall die beste Wahl.
”fast” = schnelle Betriebsart. Gefahr von gerinfügigem Datenverlust.
”nosync” = sehr schnell. Die Datenbanken können jedoch korrumpieren.

Die Einstellung ”nosync” ist nur in speziellen Anwendungsfällen sinnvoll. 

             fsync  synchronous_commit  commit_delay
    secure   yes    on                  0
    normal   yes    on                  100
    fast     yes    off                 1000
    nosync   no     off                 0

Beispiel: ”normal”

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”

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_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”

POSTGRESQL_BACKUP_CLUSTER

Hiermit wird vorgegeben, ob im Zuge einer Datensicherung der gesamte Datenbank-Cluster in einem einzigen Sicherungsarchiv ausgelagert werden soll. Neben den einzelnen Datenbanken werden damit unter anderem auch Anwender und Gruppen gesichert.

POSTGRESQL_BACKUP_CLUSTER_USER

Name des Datenbankanwenders, der über ausreichende Zugriffsrechte für die Sicherung des gesamten Datenbank-Clusters verfügt. Da der user ”postgres” i.d.R. immer existiert, ist dieser meistens eine gute Wahl.

Beispiel: ”postgres”

POSTGRESQL_BACKUP_CLUSTER_MAX

Gibt an, wie viele Kopien der Sicherungsdatei des Datenbank-Clusters aufgehoben werden sollen.

POSTGRESQL_BACKUP_DATABASES

OSTGRESQLBACKUPDATABASES Zusätzlich (oder alternativ) können neben der Sicherung des gesamten Datenbank-Clusters auch individuelle Datenbanken in separaten Archiven gesichert werden. Dies bietet den Vorteil, dass diese damit auch einzeln wiederhergestellt oder migriert werden können. Diese Option aktiviert die Sicherung von individuellen Datenbanken.

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” i.d.R. immer existiert, ist dieser meistens eine gute Wahl.

Beispiel: ”postgres”

POSTGRESQL_BACKUP_x_MAX

Gibt an, wieviele Kopien der Sicherungsdatei aufgehoben werden sollen.

Beispiel: ”7”

Das Paketmenü

PostgreSQL Administration

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.

Zurück zu: Die Datenbanken

next up previous contents index
Nächste Seite: Das ProFTPD Paket Aufwärts: eisfair-Dokumentation Vorherige Seite: Das phpPgAdmin-Paket   Inhalt   Index