Das Szenario A, in dem netpath nützlich sein soll

Nehmen wir einmal an, wir haben ein kleines Netzwerk aus zwei Rechnern 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:

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.

nächste Seite