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:
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![[*]](icons/foot_motif.gif){kind=icon}
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.
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:
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. ![[*]](icons/cross_ref_motif.gif){kind=icon}
) zu finden.
Das Einbinden in die Bootsequenz des Systems erfolgt analog zu Kapitel 2.1.1
(S. ).
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:
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.
| 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.
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
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.
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.
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. ).
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. ).
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:
).
)
Ausführliche Beschreibungen aller Kommandos sind als Manpages im Softwarepaket enthalten.
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.
# 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.
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 !!).
Christian Eibisch