apfel
und birne
. Den gesamten Verzeichnisbaum
von apfel
hat der Systemverwalter von
birne
in einem Verzeichnis /net/apfel
gemountet,
während der Administrator von apfel
ein etwas anderes
Verhältnis zu den Dingen hat und nur den
/usr
-Verzeichnisbaum des anderen Rechners in
/mnt/hosts/birne
zur Verfügung stellt. Beide
respektieren die Entscheidung des anderen; nichts soll umorganisiert
werden, um eine Angleichung zu erreichen, vielmehr soll die Technik
doch selbst damit zurechtkommen. Eine automatische Dienstleistung muß
her, die es ermöglicht, Skripte zu schreiben, die auf beiden Rechnern
laufen und trotzdem die unterschiedliche Struktur berücksichtigen.
Es wäre unglücklich, jedesmal eine Fallunterscheidung zu machen;
spätestens wenn kiwi
ans Netz kommt, müßte
alles umgearbeitet werden, um den neuen Rechner in allen Skripten zu
berücksichtigen.
Die Situation kann man in Gleichungen ausdrücken:
apfel:/
| = | birne:/net/apfel
|
birne:/usr
| = | apfel:/mnt/hosts/birne
|
Ein typisches Skript will nun die Programme, die zum Paket
veryuseful
gehören, benutzen und sollte dazu
die PATH
-Umgebungsvariable so setzen, daß diese
Programme auch gefunden werden. Wir nehmen weiter an, daß dies
bereits ausreicht, also keine weiteren Variablen gesetzt werden müssen.
Die binaries befinden sich auf apfel
im Verzeichnis
/usr/local/lib/veryuseful/bin
. Läuft das Skript auf
apfel
ab, ist also /usr/local/lib/veryuseful/bin
in den PATH
aufzunehmen; ist dagegen birne
die ausführende Maschine, ist dies
/net/apfel/usr/local/lib/veryuseful/bin
.
Im Augenblick wird mit solchen Situationen so umgegangen,
daß jeweils die Login-Skripte jeder Maschine deren besondere
Sicht auf die Dinge kennen und berücksichtigen; was hier
heißen würde, daß global die PATH
-Variable
richtig gesetzt werden würde. Hiergegen spricht aber:
PATH
gestellt werden können. Manchmal muß auch sichergestellt
sein, daß wirklich das richtige Programm unter einem Namen
angesprochen wird und sich Veränderungen des PATH
durch Benutzer nicht auswirken. In diesen Fällen ist es besser,
man setzt Umgebungsvariablen lokal erst in dem Skript, in dem sie
gebraucht werden.
Die Lösung, die netpath ermöglicht, besteht nun darin,
daß beide Rechner, apfel
und birne
,
jeweils eine Datenbank (sich von diesem Wort nicht schrecken lassen!)
aufbauen, die, nach Programmpaketen (und ggf. Versionen oder auch
Installateuren) geordnet, die Werte von Umgebungsvariablen enthält,
wie sie jeweils lokal gesetzt werden müßten. Die Datenbank
von apfel
enthält nun den Eintrag, daß die binaries
von Paket veryuseful
in /usr/local/lib/veryuseful/bin
zu finden sind. Bei der Abfrage der Datenbank, die von apfel
oder von birne
aus erfolgen kann, wird nun das Wissen um
die gemounteten Verzeichnisse herangezogen, um den Eintrag ggf.
so umzuändern, daß auch birne
auf das Verzeichnis
zugreifen kann.
Der Zugriff mittels einer Datenbank auf Pfade ermöglicht nun einerseits, daß der Rechner, der eine Ressource zur Verfügung stellt, auch die Information mitliefert, wo diese Ressource aufzufinden ist; es ist nicht mehr notwendig, daß der Rechner, der die Ressource in Anspruch nimmt, dies (etwa in einem Login-Skript) wissen muß. Andererseits kann die Datenbank überall abgefragt werden; jedes Skript hat Zugriff, muß aber nicht gewartet werden, falls etwa der Ort einer Installation geändert wird (was nur die Datenbank betrifft). Das lokale Setzen von Variablen ist auf diese Weise möglich, hat aber alle Vorteile einer globalen Verwaltung.
Neben dieser Abfrage nach einem einzelnen, bestimmten Wert, sind
natürlich auch andere Typen möglich. So ist es etwa sinnvoll,
alle binary-Werte verketten zu können, um PATH
,
wenn es gewünscht ist, auf seinen "maximalen" Wert zu setzen.