Keywords: main

Subsections

- 3.1 Mini SQL 2.0
  - 3.1.1 Installation
    - Installation zum Sart des Datenbank-Servers beim Booten
  - 3.1.2 Konfiguration
    - 3.1.2.1 Die Datei ./msql.conf
    - 3.1.2.2 Die Datei ./msql.acl
- 3.2 PostgreSQL
  - 3.2.1 Installation
    - Installation zum Start des Datenbank-Servers beim Booten
  - 3.2.2 Konfiguration / Administration
    - 3.2.2.1 Die Datei ./pg_hba.conf
    - Aufbau der Datei ./pg_hba.conf
    - 3.2.2.2 Die Passwortdateien

# 3 Datenbank-Systeme

Auf der Suche nach einer kostengünstigen Datenbankanbindung an das Internet fiel die Wahl auf Datenbanken die im Source-Code frei verfügbar sind. Da sie in den meisten Fällen den Ansprüchen der Anwender genüge tragen, stellen sie eine echte Alternative zu den teueren kommerziellen Datenbanksystemen dar. Teilweise verfügen diese auch schon über ein eigenes Web-Interface.

Für die Untersuchungen wurden die nun folgenden Datenbanksysteme gewählt:

- Mini SQL 2.0
- PostgreSQL

# 3.1 Mini SQL 2.0

Die Gründe für die Wahl von Mini SQL, oder mSQL wie es oft genannt wird, sind schnell erklärt. Erstens ist mSQL für Testzwecke (an Universitäten und Schulen) frei verfügbar und auch der Preis für eine Lizenz hält sich in Grenzen, zweitens kann mSQL als Source-Code unter der bei Kapitel 3.1.1 angegebenen Internetadresse downgeladen werden und läuft somit auf den meisten UNIX-Systemen und drittens besitzt mSQL ein eigenes WWW-Interface das es ermöglicht, einfach und schnell SQL-Abfragen in HTML-Seiten einzubinden.

Sicherlich bietet mSQL noch weitere nützliche Dinge, wie eine eigene API zur C Programmierung und eine eigene mSQL Skript Sprache an, auf die hier nicht weiter eingegangen wird, da sie hier nicht benötigt wird. Im Benutzerhandbuch[6] von mSQL ist sie sehr gut beschrieben.

## 3.1.1 Installation

Source-Quellen: http://www.Hughes.com.au
Damit Mini SQL 2.0 auf den verschiedensten UNIX-Plattformen läuft, gestaltet sich die Installation etwas anders als die üblichen Installationen von GNU-Sourcen. Einfaches eingeben von ``make'' im src Directory von mSQL wird hierbei zu Problemen führen. Deshalb muß zur Installation wie folgt vorgegangen werden:

- Entpacken der Sourcen mit:
  `tar xvfz msql-2_0_1_tar.gz`
  Daraufhin wird ein neues Directory mit dem Namen ./msql-2.0.1/ angelegt, in dem sich nun die Quellen befinden.
- Wechseln in das Verzeichnis ./msql-2.0.1/ mittels:
  `cd msql2.0.1`
- jetzt erfolgt eine systemabhängige Aufbereitung der Sourcen durch das Kommando:
  `make target`
  Hierbei wird das System gescannt, und ein neues Directory namens ./target/ angelegt. In diesem Directory wiederum befindet sich ein weiteres mit dem Namen der verwendeten UNIX-Plattform .
- zum weiteren Kompilieren muß in dieses Verzeichnis gewechselt werden:
  `cd targets/Linux-2.0.29-i586/`
- danach kann die Konfiguration von Mini SQL 2.0 mit
  `./setup`
  gestartet werden. Das System wird jetzt auf alle benötigten Sourcen überprüft.
- Nach erfolgreichem Setup, kann dann in der Datei ./site.mm das Installations-Directory geändert werden. In unserem Beispiel wie folgt:
  von `INST_DIR= /usr/local/Hughes`
  nach `INST_DIR= /soft/msql-2.0.1`
- Jetzt kann die Software wie gewohnt mit :
  `make all`
  kompiliert werden, und mit
  `make install`
  installiert werden.

### Installation zum Sart des Datenbank-Servers beim Booten

Genau wie beim Web-Server ist es ratsam mSQL bereits beim Booten zu starten. Das hierzu verwendetet Shell-Skript ist im Anhang A.5 (S. ) zu finden.

Das Einbinden in die Bootsequenz des Systems erfolgt analog zu Kapitel 2.1.1 (S. ).

## 3.1.2 Konfiguration

### 3.1.2.1 Die Datei ./msql.conf

Nach erfolgreicher Installation von mSQL ist dieses prinzipiell schon lauffähig. Es sollte jedoch ein kurzer Blick auf die Konfigurationsdatei ./msql.conf geworfen werden.

Diese Datei besteht aus drei Abschnitten, die wie folgt eingeleitet werden:

- [general]
- [w3-msql]
- [system]

Unser besonderes Augenmerk gilt hier dem Abschnitt [general], in dem die in Tabelle 3.1 (S. ) beschriebenen Laufzeitvariablen gesetzt werden können. Auf den Abschnitt [w3-msql] wird später im Kapitel 4.1.4 (S. ) näher eingegangen. Für den Abschnitt [system] kann im Benutzerhandbuch[6] von mSQL nachgelesen werden.

Tabelle 3.1: Laufzeitvariablen in der Datei ./msql.conf (Abschnitt [general])
Parameter | default Wert | Beschreibung
Inst_Dir | /usr/local/Hughes | Der volle Pfad des Installations-Directory. Also
|  | das Verzeichnis, in dem alle mSQL Dateien
|  | gefunden werden. (in unserem Fall steht hier
|  | /soft/msql-2.0.1)
mSQL_User | msql | Gibt an, unter welchem Benutzer der mSQL-
|  | Server laufen soll. Wenn ein anderer Benutzer
|  | als der hier angegebene den Server startet,
|  | wird versucht, die UID so zu ändern, daß der
|  | Server als der hier angegeben läuft
Admin_User | root | Bezeichnet den Benutzer, dem es erlaubt ist
|  | administrative Operationen durchzuführen
|  | (z.B. Server shutdown, create database, etc ...)

Eine kleine, jedoch sehr wichtige Anmerkung sei hierbei noch gemacht; damit die Datenbank mSQL unter dem in ./msql.conf angegebenen Benutzer einwandfrei läuft, müssen diesem Benutzer alle Rechte am Installations-Directory (incl. aller Unterverzeichnisse) von mSQL gegeben werden. Dies geschieht mit dem Befehl
`chown -R msql /soft/msql-2.0.1` .

mSQL kann jetzt mit `msql2d` gestartet werden.

### 3.1.2.2 Die Datei ./msql.acl

Leider wird die Funktion dieser Datei im Benutzerhandbuch von Mini SQL nicht beschrieben, obwohl sie für den Betrieb sehr wichtig ist.

Sie stellt eine einfache und primitive Zugriffsverwaltung für die Tabellen der Datenbank dar, ist aber für den Einsatz mit dem W3-mSQL Interface nicht von Bedeutung und wird deshalb auch nicht weiter beleuchtet.
Wegen der Vollständigkeit ist nachstehend die bei der hier verwendeten Konfiguration eingesetzte Datei abgebildet.

> `database=*
> read=*
> write=*
> host=local
> access=local`

# 3.2 PostgreSQL

Für die zweite zu testende Datenbank fiel die Wahl auf PostgreSQL in der zu diesem Zeitpunkt aktuellen Version 6.2.

PostgreSQL ist im Source Code frei verfügbar und kann auf nahezu allen UNIX Systemen kompiliert werden. Es unterstützt in einer leichten Variation SQL-3 Befehle und hat somit einen größeren Funktionsumfang wie mSQL. Außerdem besitzt es zwei Bibliotheken ( libpg bzw. libpgtcl) zur Datenbankunterstützung für C-Programme bzw. Tcl basierende Clients.

Wichtigster Gesichtspunkt für die Wahl von PostgreSQL war jedoch, daß sich die einzelnen Datenbanken - im Gegensatz zu mSQL - mit einem Passwort schützen lassen und somit nur autorisierten Benutzern den Zugriff gestatten.
Es sei jedoch noch bemerkt, daß das mitgelieferte Benutzerhandbuch[7] etwas zu wünschen übrig läßt, da es noch von der Vorgängerversion stammt. Die Manpages zu den einzelnen Themen jedoch sind ausführlich und auf dem aktuellen Stand.

## 3.2.1 Installation

Source-Quellen: http://www.postgresql.org
Während der Arbeit mit PostgreSQL wurden zwei Installationen vorgenommen. Die eine erfolgte unter S.u.S.E. LINUX, die andere unter einer RED HAT LINUX Distribution. Während sich PostgreSQL unter RED HAT problemlos installieren ließ, wollten sich die Sourcen unter S.u.S.E. nicht kompilieren lassen. Immer wieder traten Linkerfehler in Zusammenhang mit den ncurses und readline Libraries auf. Aus diesem Grund mußten in der von `.configure` erzeugten Datei ../src/include/config.h alle diese Libraries betreffenden #define 's händisch auskommentiert werden.

Ansonsten machte die Installation von PostgreSQL keine weiteren Probleme. Eine komplette Neuinstallation von PostgreSQL zeigen die nachstehenden Schritte.

- entpacken der Sourcen mit
  `tar xfvz postgresql-6.2.tar.gz`
  Danach kann in das entsprechende Verzeichnis gewechselt werden.
- Nach einem weiteren Verzeichniswechel nach ./src kann das Configure Skript ausgeführt werden
  `./configure -prefix=/soft/postgresql-6.2`
- Anschließend wird die Software mit
  `make all`
  kompiliert und mit
  `make install`
  fertig installiert.

Als nächstes sollte aus Sicherheitsgründen ein neuer Benutzer angelegt werden, unter dem der Datenbank-Server später läuft. Weiter sollte das komplette Installationsverzeichnis von PostgreSQL dem neuen Benutzer gehören. Dazu werden die Rechte z.B. wie folgt geändert
`chown -R postgres /soft/postgres-6.2/`

Jetzt kann unter der Kennung des neuen PostgreSQL-Users das Datenbank Initialisierungs-Programm initdb ausgeführt werden. Dabei kann es nötig sein, noch folgende zwei Parameter mit zu übergeben; z.B.
`initdb -pglib=/soft/lib -pgdata/soft/postgresql-6.2/data`
Es werden nun die benötigten Verzeichnisse und Dateien angelegt, und als Datenbankadministrator der Benutzer postgres festgelegt. Dieser ist nun als einziger dazu berechtigt, Datenbanken und Datenbankbenutzer anzulegen bzw. zu löschen (Kapitel 3.2.2, S. ).

### Installation zum Start des Datenbank-Servers beim Booten

Wie auch in den vorangegangenen Kapiteln ist das beim Booten verwendete Shell-Skript im Anhang A.6 (S. ) zu finden.

Das Einbinden in die Bootsequenz des Systems erfolgt ebenso analog zu Kapitel 2.1.1 (S. ).

## 3.2.2 Konfiguration / Administration

Nach erfolgter Installation und nachdem der Datenbank-Server postmaster läuft, kann PostgreSQL konfiguriert - eigentlich administriert - werden. Dabei erfolgt die erste Konfiguration durch den Benutzer postgres. Dieser sollte jedoch nicht als Datenbankadministrator verwendet werden; deshalb richtet er nur einen PostgreSQL Benutzer ein, welcher die Funktion des Datenbankadministrators übernimmt. z.B.
`createuser
Enter name of user to add --> ceibisch
Enter user's postgres ID or RETURN to use unix user ID: 500 ->
Is user "ceibisch" allowed to create databases (y/n) y
Is user "ceibisch" allowed to add users? (y/n) y
createuser: ceibisch was successfully added`
Es können zwar mehrere Systembenutzer als Datenbankadministratoren fungieren, jedoch sollte deren Anzahl überschaubar bleiben. Alle anderen PostgreSQL Benutzer sollten daher nicht berechtigt sein, Datenbanken anzulegen. Ebenso ist ihnen das Anlegen von weiteren Benutzern zu verwehren.

Die weitere Administration wird jetzt durch den Administrator (in diesem Beispiel ceibisch) von PostgreSQL vorgenommen. Hierzu stehen ihm folgende Kommandos zur Verfügung:

- createuser
  Erzeugt einen neuen PostgreSQL Benutzer. Hierbei müssen die Benutzernamen mit denen des Systems übereinstimmen. Außerdem muß hier für gewöhnliche Benutzer das Anlegen bzw. Löschen von Datenbanken und weiteren Benutzern untersagt werden.
  Nur mittels createuser angelegte Benutzer können auf eine Datenbank zugreifen !
- destroyuser
  Löscht einen PostgreSQL Benutzer inklusive aller Datenbanken für die dieser Administrator ist.
- createdb
  Legt eine neue Datenbank an.
- destroydb
  Löscht eine bestehende Datenbank.
- cleardbdir
  Löscht alle Datenbanken. Dazu darf der Datenbank-Server-Prozeß postmaster allerdings nicht laufen. Danach ist eine Neuinitialisierung des Datenbank Server notwendig ( initdb Kapitel 3.2.1, S. ).
- pg_dump
  Lagert eine komplette Datenbank in eine Textdatei aus. Dabei werden alle zur Wiederherstellung benötigten Abfragen sowie Daten in die Datei geschrieben.
- pg_dumpall
  Macht das gleiche wie pg_dump nur mit allen Datenbanken.
- pg_passwd
  Erstellt, bzw. ändert die übergebene Passwortdatei für PostgreSQL. (siehe auch Kapitel 3.2.2.2, S. )
- psql
  Interaktive Datenbank-Shell, über welche alle Datenbankaktionen ausgeführt werden können.

Ausführliche Beschreibungen aller Kommandos sind als Manpages im Softwarepaket enthalten.

### 3.2.2.1 Die Datei ./pg_hba.conf

Was wäre ein gutes Datenbankmanagement System, wenn man nicht die einzelnen Datenbanken mit einem Passwortschutz versehen könnte. PostgreSQL bietet diese Möglichkeit über die Datei ./data/pg_hba.conf im Installationsverzeichnis des Servers.

Die einzelnen Konfigurationsmöglichkeiten zur Zugriffsbeschränkung von Datenbanken sind in dieser Datei ausführlich beschrieben. Die Methode der Zugriffsteuerung mittels Passwörtern ist dort leider nicht beschrieben, jedoch ganz einfach wie folgt zu erreichen.

### Aufbau der Datei ./pg_hba.conf

`# TYPE DATABASE IP_ADDRESS MASK USERAUTH MAP
host all 127.0.0.1 255.255.255.255 password bababa`

Das obige Beispiel zeigt den Aufbau der Datei. Dabei kann diese Datei für jede Datenbank einen eigenen Eintrag haben. Jeder dieser Einträge (Records) beginnt mit dem Record-Type host, gefolgt von der zu schützenden Datenbank (all := alle Datenbanken). Hierbei sollte man für jede Datenbank einen eigenen Record anlegen. Über den Parameter IP_ADDRESS und MASK kann dann der Zugriff auf bestimmte IP-Adressen beschränkt werden (für Web-Anwendungen sollte hier der Zugriff nur dem Host des Web-Servers gestattet werden).

Die eigentliche Zugriffsteuerung legt jedoch der Parameter USERAUTH und MAP fest. Für Web-Anwendungen von großer Bedeutung ist hier der undokumentierte Parameterwert password. Er weist den Datenbank-Server an, beim Öffnen der entsprechenden Datenbank nach einem Passwort zu fragen, welches er in der unter MAP angegebenen Datei findet.

### 3.2.2.2 Die Passwortdateien

Alle Passwortdateien befinden sich im Verzeichnis ./data und sind nur für root oder den User des Datenbank Servers lesbar bzw. mittels pg_passwd editierbar. Ihr Aufbau ist dabei ähnlich der Passwortdatei des Systems.
Beispieleintrag:
`ceibisch:YIKwGCR.hNn5c`

Zu beachten ist, daß für jede passwortgeschützte Datenbank eine eigene Passwortdatei angelegt wird. Dadurch wird sichergestellt, daß nur in der Datei eingetragene Benutzer auf die Datenbank zugreifen können. Ebenfalls muß der Benutzername in der Passwortdatei ein im System bekannter Benutzername sein.

Wollen mehrere Systembenutzer auf eine Datenbank Zugriff haben, so genügt es durchaus, für einen dieser Benutzer ein Passwort festzulegen. Alle anderen können den gleichen Benutzernamen und Passwort verwenden (ABER !! - sie müssen mittels createuser zum Gebrauch von PostgreSQL berechtigt werden !!).