Die allererste Version von netpath

Netpath besteht aus zwei Programmen:

• Dem netpath-Server: Hierbei handelt es sich um ein Tcl-Skript, das auf einem Socket lauscht und Anfragen beantwortet. Die Datenbank besteht im Augenblick aus einigen Textfiles, die von diesem Skript eingelesen werden.
• Dem netpath-Client: Das ist ein klitzekleines C-Programm, das in der Lage ist, die Kommandoparameter zu einer Abfrage zusammenzustellen, an den Socket zu reichen und die Antwort wohlformatiert auszugeben.

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

• hosts ist der Ort der Hosts-Datei. Hier wird festgelegt, welche Rechner überhaupt an dem Spielchen beteiligt sind (apfel, birne,...) und wo die rechnerspezifischen Datenbankfiles (im engeren Sinne) zu finden sind. Das genaue Format der Hosts-Datei wird unten angegeben.
• dirmapfile ist der Ort der directory map. Diese Datei gibt an, welches Verzeichnis auf Rechner A unter welchem Verzeichnis auf Rechner B zu finden ist. Auch hier ist das genaue Format unten zu finden.

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

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

• DEFAULT_PORT: Der TCP-Port, der als default verwendet wird. Diese Einstellung kann durch das -port-Argument beim Aufruf geändert werden.
• DEFAULT_SERVER: Der Server, der per default angesprochen wird. Hier kann man, und das ist im Augenblich auch so, einfach "localhost" eintragen. Diese Einstellung kann durch das -server-Argument beim Aufruf geändert werden.

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:

• -aspath bewirkt, daß alle value-Abfrageergebnisse in einer einzelnen Zeile getrennt durch Doppelpunkte ausgegeben werden. Doppelte Angaben werden vermieden. Es gibt keine Schlüsselwörter in der Ausgabe.
• -aslist wirkt genauso, trennt jedoch durch Leerzeichen.

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

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

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:

• Für apfel soll das Verzeichnis apfel:/bin umgesetzt werden. Die erste Regel wird benutzt, die aussagt, daß alle Verzeichnisse von apfel für apfel identisch sichtbar sind. Für apfel ist das Verzeichnis daher unter /bin sichtbar.
• Für apfel soll das Verzeichnis birne:/usr/bin umgesetzt werden. Um birne-Verzeichnisse auf apfel sichtbar zu machen, kommen die dritte und die fünfte Regel in frage. Die dritte Regel paßt nicht, weil das angefragte Verzeichnis nicht im /home-Verzeichnisbaum liegt. Die fünfte Regel paßt aber und besagt, daß /usr auf birne in /mnt/hosts/birne auf apfel erscheint. Das /usr/bin-Verzeichnis wird daher in /mnt/hosts/birne/bin umgesetzt.
• Für apfel soll das Verzeichnis birne:/etc umgesetzt werden. Es gibt keine passende Regel, daher wird davon ausgegangen, daß das Verzeichnis nicht sichtbar ist. Im Ergebnis einer Anfrage erscheint dieses Verzeichnis daher nicht.

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

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

• Nur auf einem Rechner im Netz läuft ein Server, über den alle Anfragen laufen. Nur auf diesem Rechner befinden sich die Konfigurationsfiles.

  Hat den Vorteil, daß zusätzliche Komplexität vermieden wird. Hat den Nachteil, daß der Serverrechner stets laufen muß, um den Betrieb der anderen Rechner zu ermöglichen.

• Auf jedem Rechner im Netz läuft ein Server; alle Anfragen laufen stets über den jeweils lokalen Server. Auf jedem Rechner befindet sich das Datenbankfile, das zum eigenen Rechner gehört, sowie symbolic links zu den Datenbankfiles der anderen Rechner.

  Hat den Vorteil, daß bei Ausfall eines Rechners die anderen Rechner nicht zwangsläufig betroffen sind. Hat den Nachteil, daß manche Anfragen, die dummerweise im falschen Augenblick gestellt werden, nur die augenblickliche Rechnersituation berücksichtigen. Bei Anfragen etwa aus einem /etc/profile kann dies problematisch sein.

• Auf jedem Rechner im Netz läuft ein Server; alle Anfragen laufen stets über den jeweils lokalen Server. Auf jedem Rechner befinden sich Kopien aller Datenbankfiles.

  Hat den Vorteil, daß jede Anfrage auch die gerade ausgefallenen Rechner berücksichtigt. Hat den Nachteil von größerem Administrationsaufwand.

nächste Seite