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.
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
tclsh netpath-server
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.
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:
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:
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.
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.).
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:
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.
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.
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).
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.
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.
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.
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.
Hat den Vorteil, daß jede Anfrage auch die gerade ausgefallenen Rechner berücksichtigt. Hat den Nachteil von größerem Administrationsaufwand.