Die allererste Version von netpath

Die jetzige, erste Version von netpath ist wirklich nur als Experimentalversion zu bezeichnen. Sie ist relativ langsam, die Datenbankstruktur ist unausgereift, viele Konzepte sind noch nicht verwirklicht.

Netpath besteht aus zwei Programmen:

Der Client/Server-Betrieb ermöglicht, daß jeder Rechner seine Sicht der Dinge in Form eines eigenen Servers nach außen vertritt. Beim Aufruf des Clients kann ein beliebiger Server adressiert werden, als default ist der lokale Server vorgesehen. Weiter unten werden verschiedene Möglichkeiten, die Aufgaben zwischen Servern zu verteilen, diskutiert.

Der Netpath-Server

Um den Server benutzen zu können, müssen im Konfigurationssbschnitt (relativ am Anfang des Tcl-Skriptes) einige Pfade gesetzt werden (...). Und zwar folgende:

Ggf. kann man auch den TCP-Port mittels port einstellen, der für den Server-Socket benutzt werden soll. Als Default ist 2000 eingetragen (ein Phantasiewert).

Um den Server laufen zu lassen, wird Tcl Version 7.6 benötigt, d.h. ich habe selbst diese Version verwendet. Höhere Versionen funktionieren vermutlich auch. Tcl 7.4 geht nicht, da diese Version noch keine Sockets unterstützt. Aufgerufen wird der Server dann mit

tclsh netpath-server
oder direkt netpath-server, sofern die exec-Zeile im Skript angepaßt ist. Der Server benutzt das logger-Programm, um im Syslog Meldungen auszugeben; hier ist darauf zu achten, daß dieses Programm vorhanden und ausführbar ist. Ggf. sind die Einstellungen im Konfigurationsabschnitt zu ändern (man kann z.B. auch alle Meldungen nur auf stderr ausgeben lassen).

Es sollten nun einige Meldungen kommen, daß bestimmte Dateien erfolgreich gelesen werden konnten und schließlich, daß der Server auf dem angegebenen TCP-Socket lauscht. Jetzt kann man auch versuchsweise den Client ausprobieren.

Der Netpath-Client

Der Client sollte problemlos übersetzbar sein, sofern die GNU-C-Library verwendet wird (und diese Bedingung nur aus Faulheit meinerseits; das ganze könnte man auch POSIX-konform hinkriegen). Konfigurierbar ist hier:

Der Client hat, im Gegensatz zum Server, Kommandozeilenargumente. Die Synopsis ist wie folgt:

netpath [-forhost hostname] [-server servername] [-port portnummer] [-aspath] [-aslist] package field

Mit -server und -port wird der Socket des Servers adressiert. Falls diese Parameter weggelassen werden, werden die Standardwerte während der Übersetzung des Clients benutzt. Mit -forhost wird der Rechner bestimmt, dessen Perspektive eingenommen werden soll. Als Standard wird der Rechner genommen, auf dem der Client ausgeführt wird.

Das package bestimmt das Programmpaket, dessen Variablen abgefragt werden sollen. Hier kann man auch '*' übergeben, um alle Pakete, die der Server kennt, auszulesen. (Es ist nur '*' möglich und kein echtes globbing. Man beachte, daß man das Sternchen in Hochkommata setzen muß, damit die Shell nichts expandiert.) In ähnlicher Weise kann das field angegeben werden. Übergibt man für beide Argumente jeweils '*', so wird die komplette Datenbank des Servers ausgelesen.

Die Ausgabe erfolgt standardmäßig in etwa in folgender Form; dabei sind Schlüsselwörter unterstrichen, während der Rest tatsächlich der Datenbank entstammt. Diese Ausgabe könnte durch netpath veryuseful '*' auf apfel entstanden sein:

number 4
package veryuseful field binaries value /usr/local/lib/veryuseful/bin
package veryuseful field ldlibs value /usr/local/lib/veryuseful/lib
package veryuseful field root value /usr/local/lib/veryuseful
package veryuseful field source value /home/hacker/src/veryuseful

Durch die Angabe von -forhost birne wird die Perspektive von birne in jedem Fall eingenommen, auch wenn netpath gar nicht auf birne ausgeführt wird. Man erhielte dann ein anderes Ergebnis:

number 4
package veryuseful field binaries value /net/apfel/usr/local/lib/veryuseful/bin
package veryuseful field ldlibs value /net/apfel/usr/local/lib/veryuseful/lib
package veryuseful field root value /net/apfel/usr/local/lib/veryuseful
package veryuseful field source value /home/hacker/src/veryuseful

Da die Home-Verzeichnisse beider Rechner bereits anderweitig abgeglichen sind (soll mal so sein) und dadurch auf beiden Rechnern identisch verfügbar sind, muß das source-Feld nicht angepaßt werden.

Bei den Optionen -aspath und -aslist handelt es sich um Schalter, die die Art der Ausgabe beeinflussen:

Man denke hier insbesondere an

export PATH=`netpath -aspath '*' binaries`

zum Setzen der PATH-Variable, so daß alle Pfade, die in binaries-Feldern aller Pakete vorkommen, enthalten sind.

Oder:

for p in `netpath -aslist '*' binaries`
do echo "Zum Suchpfad gehört auch: $p"
done

Ein Wort zur Reihenfolge der Ausgaben: Bei Abfragen, bei denen das Paket '*' und das Feld ein Bestimmtes ist, wird eine Reihenfolge eingehalten. Zunächst wird die host order benutzt, die in der Hosts-Datei angegeben ist. Dies heißt z.B., daß alle Pfade des Servers ganz vorne ausgegeben werden. Die weitere Reihenfolge bestimmt sich durch die Reihenfolge in dem Textfile, das die Datenbank speichert. Bei anderen Abfragetypen ist die Reihenfolge nicht spezifiziert.

Die Hosts-Datei

Die Hosts-Datei muß im Konfigurationsabschnitt des Servers angegeben werden. Ein Beispiel für eine Hosts-Datei ist:

localhost in /usr/local/lib/netpath/db-%h
apfel birne in /usr/local/lib/netpath/db-%h

Jede Zeile zählt links eine Reihe von Rechnernamen auf, dann kommt das Schlüsselwort in und dann die Angabe, wo die zugehörige Datenbank zu finden ist.

Die Hosts-Datei bestimmt in erster Linie, welche Rechner der Server überhaupt kennt. In diesem Fall weiß der Server über die Datenbanken (und damit die Installationen) von apfel und birne bescheid. Desweiteren wird natürlich der Ort der Datenbank angegeben. Im Augenblick ist hier nur ein File möglich, das auf dem Rechner, auf dem der Server läuft, erreichbar sein muß. (Eine Erweiterung könnte sein, hier auch forward-Regeln einzufügen, d.h. Zugriffe auf Datenbankfiles werden durch kooperierende Server erledigt.) Man beachte, daß eine Abfrage an den Server stets über alle hier aufgeführten Datenbanken läuft, d.h. in unserer Konfiguration erledigt der Server Anfragen stets so, daß alle Installationen auf apfel und birne berücksichtigt werden. Die Ergebnisse der Anfrage werden aber stets so umgerechnet (mittels directory mapping), daß der in -forhost angegebene Rechner zugreifen kann.

Der Rechner localhost steht symbolisch für den Rechner, auf dem der Server läuft.

Die Dateiangabe darf %h enthalten. Dieser Platzhalter wird durch den Namen des Rechners ersetzt.

Die Namen der Rechner müssen im Augenblick ohne Domain angegeben werden! Dies sollte aber in der Regel kein Problem darstellen.

Die Reihenfolge der Rechner in der Datei bestimmt die host order. In diesem Fall wäre das der Serverrechner, dann apfel (es sei denn dies ist der Server), dann birne (es sei denn dies ist der Server). Die host order spielt für die Reihenfolge bei Abfragen mit unbestimmten Paket und bestimmtem Feld eine Rolle (s.o.).

Die directory map

Die directory map muß im Konfigurationsabschnitt des Servers angegeben werden. Ein Beispiel für diese Datei ist:

apfel:/ = apfel:/
birne:/ = birne:/
apfel:/home = birne:/home
birne:/home = apfel:/home
apfel:/mnt/hosts/birne = birne:/usr
birne:/net/apfel = apfel:/

Die Zeilen dieser Datei werden stets von oben nach unten interpretiert, d.h. es wird die erste passende Umsetzungsregel genommen. Die Zeilen sind so zu interpretieren, daß das Verzeichnis rechts durch das Verzeichnis links zu ersetzen ist. Damit ein Verzeichnis umsetzbar ist, muß genau eine Regel angewendet werden, ansonsten ist das Verzeichnis unsichtbar. (Daher die ersten beiden Zeilen. Würde man sie weglassen, könnte man von den Rechnern nicht auf die eigenen Verzeichnisse zugreifen; jedenfalls würden die eigenen Verzeichnisse aus den Abfrageergebnissen von netpath entfernt.) Ein Verzeichnis ist unsichtbar, wenn nur durch wiederholte Regelanwendung ein Pfad gefunden werden kann.

Beispiele für die Interpretation:

Es ist z.Z. nicht möglich, Wildcards zu benutzen, um die Regeln zu beschreiben (wäre aber sehr sinnvoll).

Das Format der Datenbankfiles

Die Datenbankfiles werden in der Hosts-Datei festgelegt (s.o.). Ein Beispiel für ein Datenbankfile ist:

Das File /usr/local/lib/netpath/db-apfel enthält:
standard /bin binaries
/usr/bin binaries
/usr/local/bin binaries
/lib ldlibs
/usr/lib ldlibs
/usr/local/lib ldlibs
veryuseful /usr/local/lib/veryuseful/bin binaries
/usr/local/lib/veryuseful/lib ldlibs
/usr/local/lib/veryuseful root
/home/hacker/src/veryuseful source

Das File /usr/local/lib/netpath/db-birne enthält:
standard /bin binaries
/usr/bin binaries
/usr/local/bin binaries
/lib ldlibs
/usr/lib ldlibs
/usr/local/lib ldlibs
apackage /usr/local/lib/apackage/bin binaries
/usr/local/lib/apackage/lib ldlibs
/usr/local/lib/apackage root
/home/huhn/src/apackage source

In der linken Spalte steht der Paketname (kann weggelassen werden, dann wird der vorherige Paketname übernommen); in der mittleren Spalte steht der Wert, in der rechten Spalte der Feldname. Wie man sieht, ist es erlaubt, daß pro Paket und Feld mehr als ein Wert angegeben werden kann (z.B. standard/binaries).

Es ist wichtig, daß jedes Datenbankfile seine eigene, lokale Sicht vertritt, d.h. das db-apfel-File enthält die Verzeichnisse so, wie sie apfel selbst sieht.

Eine Beispielsitzung

Die Distribution enthält ein Verzeichnis example, das die in diesem Text erläuterte Beispielkonfiguration zum Inhalt hat. Auf diese Weise kann man recht schnell einen Server starten und mit Anfragen experimentieren.

Für das Beispiel ist es unerheblich, ob die in den Files angegebenen Rechner und Verzeichnisse tatsächlich existieren; netpath macht reine Textersetzung und schaut nicht auf die tatsächlichen Verhältnisse.

Um den Server zu starten, muß zunächst der Konfigurationsabschnitt in netpath-server.tcl so gesetzt werden, daß die Beispielkonfiguration eingelesen wird. Wir gehen der Einfachheit davon aus, daß das example-Verzeichnis nach /tmp kopiert wird. Folgende Zeilen sind zu ändern:

set hosts "/tmp/example/hosts"
set dirmapfile "/tmp/example/dirmap"

Die Verweise in der Hosts-Datei auf die Datenbankfiles sind bereits so gehalten, daß davon ausgegangen wird, daß das example-Verzeichnis in /tmp steht. Es ist daher hier nichts zu ändern. (Bei einer echten Installation von netpath müßte man dies natürlich konfigurieren.)

Nun kann der Server gestartet werden:
tclsh netpath-server.tcl &

Es werden nun einige Meldungen ausgegeben; die letzte davon besagt, daß der Server auf TCP-Port 2000 lauscht. Nun kann man den Client ausprobieren.

Mit netpath -forhost apfel '*' '*' wird die gesamte Datenbank ausgegeben, und zwar so, wie sie von apfel aus aussieht. Entsprechend erhält man durch -forhost birne eine Ausgabe aus Sicht von birne. Andere Beispiele siehe oben im Text. (Ohne -forhost-Parameter würde als default der tatsächliche Rechnername genommen, auf dem der Client gestartet wird.)

Wenn man die Konfigurationsfiles im laufenden Betrieb ändert, so wird die Änderung binnen 10 Sekunden vom Server übernommen (allerdings erst, wenn die nächste Anfrage eintrifft). Es ist daher nicht erforderlich, den Server neu zu starten.

Serverkonfigurationen

Im Augenblick gibt es drei grundsätzliche Möglichkeiten zur Serverkonfiguration:

nächste Seite