Die oben beschriebene Konfiguration hat gezeigt wie eine typische Linux-Workstation für den normalen Endbenutzer-Betrieb konfiguriert wird. Einige werden aber besondere Wünsche und Bedürfnisse haben, die eine etwas fortgeschrittenere Konfiguration benötigt. Einige der gängigsten sollen in den kommenden Abschnitten beschrieben werden.
Die Details zu AX.25, Ottawa PI und den generischen SCC Treibern wurden
aus diesem Text herausgenommen, ihnen widmet sich ein eigenes HOWTO, das
HAM-HOWTO (http://sunsite.unc.edu/mdw/HOWTO/HAM-HOWTO.html
).
Das Point to Point Protocol ist ein modernes und effizientes Protokoll das mehrere verschiedene Protokolle zur Verbindung über serielle Leitungen in sich vereint. Es wird von vielen anstelle von SLIP verwendet, dem es erweiterte Funktionalität, Fehlererkennung und Sicherheitsoptionen voraushat. Es behebt einige SLIP-typische Nachteile und kann sowohl über synchrone wie auch über asynchrone Verbindungen benutzt werden.
Einer der großen Vorteile von PPP ist die Tatsache, daß die
Übermittelung von solchen Daten wie der IP-Adresse im Protokoll
implementiert ist, und von dieser Möglichkeit machen die meisten Server
auch Gebrauch. Dabei sendet der Klient zunächst ein speziell
formatiertes Datagramm an den Server und bekommt daraufhin die
gewünschte Information - in diesem Falle z.B. die IP-Adresse - zurück,
ebenfalls in einer genau festgelegten Form. Dies erleichtern natürlich
deutlich den automatischen Aufbau einer dynamischen Verbindung gegenüber
SLIP, bei dem man - außerhalb des Protokolls - auf eine `schlaue'
Software wie dip
zurückgreifen muß, um diese Aufgabe zu
erfüllen.
Die Autoren der Linux-Portierung von PPP sind Michael Callahan,
(callahan@maths.ox.ac.uk>
) und Al Longyear,
(longyear@netcom.com>
),
Linux-PPP basiert auf Paul Mackerras's free PPP für BSD-ähnliche
Systeme. Der Großteil der hier gegebenen Informationen entstammt der
Dokumentation der PPP-Software. Sie ist sehr vollständig und geht über
das hier gesagte weit hinaus.
Es gibt mehrere Gründe, warum man PPP anstelle von SLIP verwenden sollte, wenn man die Wahl hat:
In diesem Falle hat mein natürlich keine Wahl sondern muß PPP verwenden. Dies ist aber sicherlich kein Nachteil ;-)
Im Gegensatz zu SLIP bietet PPP eine Fehlerüberprüfung für jedes einzelne Datenpaket. Deshalb muß unter SLIP die Überprüfung der Daten zwischen Sender und Empfänger eines Datenpaketes erfolgen während unter PPP dies zwischen dem eigenen Rechner und dem PPP-Server erfolgt. Insbesondere wenn zwischen dem PPP/SLIP-Server und dem eigentlichen Sender/Empfänger noch weitere Router im Netz zwischengeschaltet sind erlaubt PPP dadurch eine schnellere Reaktion auf fehlerhafte Datagramme.
PPP bietet einige Dinge, die mit SLIP nicht möglich sind. So können z.B. nicht nur IP-Datagramme über die serielle Leitung übermittelt werden sondern auch andere wie DECNET, oder AppleTalk.
sunsite.unc.edu:/pub/Linux/system/Networking/serial/ppp-2.1.2d.tar.gz
sunsite.unc.edu:/pub/Linux/system/Networking/serial/ppp-2.2.0f.tar.gz
Diese Dateien enthalten Kernel Quelltexte sowie Quellen und das
ausführbare Programm von pppd
. Wer noch einen Kernel 1.2.x
verwendet benötigt die Version 2.1.2d, die andere Version 2.2.0f ist für
die neuen 2.0.x-Kernels gedacht.
Das PPP-HOWTO beschreibt ausführlich alle Schritte die notwendig sind um die PPP-Software richtig zu installieren, den Rechner über eine PPP-Verbindung mit dem Internet zu verbinden oder selber einen PPP-Server aufzubauen. Auch das PPP-HOWTO gibt es in einer deutschen Übersetzung.
Es gibt drei verschiedene Möglichkeiten, wie man einen Linux-Rechner als
SLIP-Server konfigurieren kann und es so anderen ermöglicht sich über
Modem einzuwählen und Netzwerk-Dienste in Anspruch zu nehmen. Die
erste, über sliplogin
, ist wohl am ehesten zu empfehlen, da sie
sehr einsichtig und leicht zu konfigurieren ist.
sliplogin
kann anstelle der normalen Login-Shell dazu
verwendet werden, die Terminalverbindung für SLIP-Benutzer in den
benötigten SLIP-Modus umzuschalten. Dabei kann der Linux-Rechner sowohl
als statischer Server arbeiten, der den Nutzern, basierend auf
ihrer ID, jedesmal dieselbe IP-Adresse zuweist, oder auch als
dynamischer Server, wobei eine gerade freie Adresse aus einem
vorgegebenen Adressbereich vergeben wird.
Der SLIP-Benutzer führt dann zunächst einen ganz normalen Login-Prozeß
durch, d.h. er meldet sich mit seinem Benutzernamen an und gibt sein
Paßwort ein. Normalerweise würde jetzt die Login-Shell gestartet, die
den Benutzer durch ihren Prompt zur Eingabe von Befehlen auffordert.
Stattdessen wird für den SLIP-Benutzer nun sliplogin
ausgeführt. Dieses Programm sucht in seiner Konfigurationsdatei
(/etc/slip.hosts
) nach einem Eintrag, der dem Login-Namen des
Benutzers entspricht. Wird dieser gefunden so wird die serielle
Verbindung für 8-bit konfiguriert und der Modus durch einen
entsprechenden ioctl
auf SLIP umgesetzt. Als letzten Schritt
der Konfiguration führt sliplogin
dann ein Shellscript aus,
welches die SLIP-Schnittstelle mit den entsprechenden Werten für
IP-Adresse, Netzwerk-Maske und den dazugehörenden Routing-befehlen
konfiguriert. Dieses Script heißt normalerweise
/etc/slip.login
, aber ähnlich wie bei getty
können
benutzerspezifische Scripts mit dem Namen
/etc/slip.login.loginname
angelegt werden, um für jeden Benutzer
ein eigens Konfigurationsscript zu haben. Dieses wird dann anstelle des
Standardscripts ausgeführt.
Damit sliplogin
richtig arbeitet müssen drei oder vier Dateien
die richtigen Einträge enthalten. Dies sind:
/etc/passwd
, zur Verwaltung der Accounts./etc/slip.hosts
, hierin stehen Informationen für jeden
registrierten SLIP-Benutzer./etc/slip.login
, Konfiguration des Routing für jeden Benutzer./etc/slip.tty
, diese Datei wird benötigt, wenn der
Linux-Rechner als dynamischer SLIP-Server arbeiten soll, sie
enthält eine Liste der möglichen zu vergebenden Adressen./etc/slip.logout
, dies sind die Befehle, die zur
Beendigung einer SLIP-Verbindung auf der Server-Seite notwendig sind,
wenn der Benutzer die Verbindung beendet.Die aktuelle Version ist
sunsite.unc.edu:/pub/Linux/system/Network/serial/sliplogin-2.0.1.tar.gz
Die TAR-Datei enthält die Quellen, vorkompilierte Binärdateien und die
Online-Hilfetexte für man
.
Um sicherzustellen, daß nur autorisierte Benutzer das Programm
sliplogin
ausführen können empfiehlt es sich, dafür eine eigene
Gruppe anzulegen, indem in der Datei /etc/group
ein
entsprechender Eintrag eingefügt wird, der ungefähr so aussehen sollte:
..
SLIP::13:radio,fred
..
Bei der Installation des sliplogin
Paketes wird das
Makefile
dann automatisch die Gruppenzugehörigkeit von
sliplogin
auf SLIP
setzen und die Permissions so
einstellen, daß nur Benutzer dieses Programm starten können, die der
Gruppe SLIP
zugehören, im obigen Beispiel als die Benutzer fred
und radio.
Die Installation (Programme in /sbin
, Online-Hilfetexte in
Sektion 8) ist Standard:
% cd /usr/src
% gzip -dc .../sliplogin-2.0.tar.gz | tar xvf -
<..editieren des Makefile je nachdem ob Shadow
Passwoerter verwendet werden oder nicht...>
% cd sliplogin
% make install
Damit werden die mitgelieferten Binärdateien installiert. Wer sie
lieber selbst kompiliert, muß vor dem make install
noch ein
make clean
ausführen.
Weitere Informationen enthält die README-Datei.
Für die Login-Namen der SLIP-Benutzer, die in /etc/passwd
festgelegt werden, gibt es eine Konvention, die meist eingehalten wird:
Der Name setzt sich zusammen aus dem Namen des einwählenden Rechners, dem
ein großes `S' vorangestellt wird. Der Eintrag für einen Rechner mit
dem Namen radio
sähe dann also folgendermaßen aus:
Sradio:FvKurok73:1427:1:radio SLIP login:/tmp:/sbin/sliplogin
Hinweis: Als Heimatverzeichnis für diesen Benutzer ist /tmp
eingetragen, er hat also kein eigenes Verzeichnis. Dieses ist aber für
SLIP-Nutzer auch nicht nötig, da anstelle der normalen Login-Shell
sliplogin
ausgeführt wird und es so nie zu einem Dialogbetrieb
kommen kann.
Wenn sliplogin
bei einem erfolgreichen Einwählversuch gestartet
wurde so durchsucht es die Datei /etc/slip.hosts
nach einem
Eintrag der dem Login-Namen des Anrufers entspricht, um die Einzelheiten
der Konfiguration für diesen Rechner zu erfahren. Hier können also
für statische Accounts IP-Adresse und Netz-Maske festgelegt werden,
sowie einige weitere Eigenschaften der SLIP-Verbindung. Das folgende
Beispiel zeigt zwei typische Einträge in der Datei
/etc/slip.hosts
:
#
Sradio 44.136.8.99 44.136.8.100 0xffffff00 normal
Salbert 44.136.8.99 DYNAMIC 0xffffff00 compressed
#
Es treten der Reihe nach folgende Einträge auf:
DYNAMIC
dann wird die
IP-Adresse entsprechend den Informationen in der Datei
/etc/slip.tty
vergeben, dies wird später
behandelt. Wichtig: Das funktioniert erst ab Version 1.3 von
sliplogin
!0xffffff00
=255.255.255.0
.Hinweis: Im 2. und 3. Feld können sowohl IP-Adressen in der
üblichen punktierten Dezimalschreibweise (wie im Beispiel) als auch die
Rechnernamen verwendet werden. Voraussetzung ist dann aber, daß diese
Namen auf dem eigenen Rechner auch aufgelöst werden können
(d.h. entsprechende Einträge in /etc/hosts
vorhanden sind), da
dem anderen Rechner sonst keine gültige IP-Adresse zugewiesen werden
kann und der Login-Versuch fehlschlägt. Zur richtigen Konfiguration
dieser Namensauflösung siehe das Kapitel `Name Resolution'.
Häufig verwendete Einträge für die optionalen Einstellungen sind:
verwendet das `normale', unkomprimierte SLIP.
schaltet die van Jacobsen Header-Komprimierung ein (cSLIP).
Diese beiden Einträge schließen sich gegenseitig aus, es darf also nur
eine davon eingetragen werden. Näheres dazu steht in den entsprechenden
Abschnitten der man
-Online-Hilfe.
Wenn sliplogin
in der Datei /etc/slip.hosts
einen
passenden Eintrag für den einwählenden Rechner gefunden hat versucht es
als Nächstes, die Datei /etc/slip.login
auszuführen, um die
endgültige Konfiguration des SLIP Device mit IP-Adresse und Netz-Maske
durchzuführen. Das sliplogin
-Paket enthält ein Beispiel für
diese Datei:
#!/bin/sh - # # @(#)slip.login 5.1 (Berkeley) 7/1/90 # # Generische Login-Datei fuer eine SLIP-Verbindung. Sie wird von # sliplogin mit folgenden Parametern aufgerufen: # $1 $2 $3 $4 $5 $6 $7-n # SLIPunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig $1 $4 pointopoint $5 mtu 1500 -trailers up /sbin/route add $5 arp -s $5 <hw_addr> pub exit 0 #
Dieses Script macht also nichts anderes als die ifconfig
und
route
Befehle mit den übergebenen Parametern auszuführen um das
Device richtig zu konfigurieren und eine Route für den neu
hinzugekommenen Rechner über das SLIP-Device anzulegen.
Außerdem wird noch Proxy ARP verwendet um den anderen Rechnern
im lokalen Ethernet des Servers mitzuteilen daß der neue Rechner unter
derselben Hardware-Adresse wie der Server erreicht werden kann. Hierzu
muß <hw_addr>
im obigen Beispiel durch die Hardware-Adresse
der Ethernet-Karte des Servers ersetzt werden. Diese kann durch ein
ifconfig eth0
angezeigt werden.
Wer keine Ethernet-Karte in seinem Rechner hat sollte die gesamte Zeile auskommentieren.
Nach Beendigung der Verbindung muß die serielle Schnittstelle wieder in
ihren Normalzustand zurückgesetzt werden, damit der nächste Anrufer
wieder einen definierten Zustand vorfindet und ein Login möglich ist.
Dies wird in der Script-Datei /etc/slip.logout
durchgeführt:
#!/bin/sh - # # slip.logout # /sbin/ifconfig $1 down /sbin/route del $5 arp -d $5 exit 0 #
Es wird lediglich das SLIP-Interface als `down' konfiguriert und die
angelegte statische Route wieder aus der Routing-Tabelle gelöscht.
Besitzer von Ethernet-Karten müssen weiterhin die Proxy ARPs
für diesen Rechner wieder löschen, dies geschieht mit dem arp
Befehl. Wer keine Ethernet-Karte hat sollte diese Zeile wiederum
auskommentieren.
Soll eine dynamische Adressvergabe für SLIP-Benutzer stattfinden
(angezeigt durch das Schlüsselwort DYNAMIC
in der Adress-Spalte
der Datei /etc/slip.hosts
) so muß in der Datei
/etc/slip.tty
eine Liste aufgeführt sein, welchem seriellen Port
welche IP-Adresse zugeordnet werden soll. Wer ausschließlich statische
Adressen vergeben will benötigt diese Datei nicht.
In /etc/slip.tty
sind diejenigen seriellen Devices aufgeführt,
über die ein SLIP-Login möglich ist, sowie die IP-Adresse, die einem
Anrufer, der sich über diese Schnittstelle einwählt, zugewiesen werden
soll. Das Format dieser Datei ist wie folgt:
# slip.tty tty -> IP Adressenzuweisung fuer dynamisches SLIP # Format: /dev/tty?? xxx.xxx.xxx.xxx # /dev/ttyS0 192.168.0.100 /dev/ttyS1 192.168.0.101 #
Diese Tabelle legt also fest daß ein Anrufer, der sich über die
Schnittstelle /dev/ttyS0
einwählt und in der Datei
/etc/slip.hosts
einen DYNAMIC
Eintrag hat, die Adresse
192.168.0.100
zugewiesen bekommt.
Es muß also nur eine Adresse je Schnittstelle angegeben werden, unabhängig von der Anzahl der Benutzer des dynamischen SLIP. Dadurch kann die Anzahl der verwendeten Adressen gering gehalten werden.
Einige der Informationen aus diesem Kapitel stammen aus der man
Online-Hilfe zu dip
, in der ebenfalls beschrieben wird, wie
mittels dip
ein Linux SLIP-Server konfiguriert werden kann.
Ausgangspunkt ist die Version dip337o-uri.tgz
, wer eine andere
Version verwendet sollte sicherheitshalber auch in der originalen
Anleitung nachlesen.
dip
besitzt auch einen speziellen Empfangsmodus, bei dem es
automatisch anhand des Benutzernamens desjenigen, der dip
gestartet hat, die serielle Leitung als SLIP-Verbindung konfiguriert,
und zwar basierend auf den Informationen in der Datei
/etc/diphosts
. Dieser spezielle Modus von dip
wird
aktiviert, indem man es unter dem Namen diplogin
startet. Zu
diesem Zweck legt man einen symbolischen Link an:
% ln -sf /usr/sbin/dip /usr/sbin/diplogin
Um nun mit dip
einen SLIP-Server zu konfigurieren müssen auch
wieder spezielle Accounts angelegt werden, wobei diplogin
als
Login-Shell verwendet wird. Dies geschieht durch entsprechende Einträge
in der Datei /etc/passwd
. Als Benutzernamen für SLIP-Accounts
sollte wieder die übliche Form `S'+Rechnername verwendet werden, sodaß
ein typischer Eintrag so aussehen könnte:
Sfredm:ij/SMxiTlGVCo:1004:10:Fred:/tmp:/usr/sbin/diplogin
^^ ^^ ^^ ^^ ^^ ^^ ^^
| | | | | | \__ diplogin als Login Shell
| | | | | \_______ Home directory
| | | | \____________ Voller Benutzername
| | | \_________________ User Group ID
| | \_____________________ User ID
| \_______________________________ Verschluesseltes Passwort
\__________________________________________ SLIP User Login Name
Wenn sich nun ein Benutzer mit dem Namen Sfredm
einlogged und
das korrekte Paßwort eingibt, wird der login(1)
-Prozeß den
Benutzer als rechtmäßig anerkennen und die die Login-Shell, also das
Programm diplogin
, starten. Dadurch daß dip
über dem
Umweg eines symbolischen Links unter dem Namen diplogin
gestartet wird weiß das Programm automatisch, daß es als Login-Shell
aufgerufen wurde. Als erstes ruft es dann die Unix-Funktion
getuid()
auf um die User-ID (UID) des Aufrufenden herauszufinden.
Danach durchsucht es die Datei /etc/diphosts
nach dem ersten
Eintrag, der entweder dieser UID oder aber dem Namen des tty
entspricht, über das die Verbindung läuft. Entsprechend den darin
gegebenen Parametern wird dann die Verbindung konfiguriert.
Einfach anhand der Entscheidung, ob für einen Benutzer ein Eintrag in
diphosts
angelegt wird, oder ob die Standard-Behandlung anhand
der ttys zum tragen kommt, kann ein gemischter Server aus statischen und
dynamischen Adressen zusammengestellt werden.
dip
führt weiterhin automatisch einen Proxy-ARP
Eintrag durch, sodaß man sich darum nicht selbst kümmern muß.
In der Datei /etc/diphosts
sind die Konfigurationsparameter für
die Klienten-Rechner zusammengestellt, dip
verwendet sie, um
die SLIP-Devices richtig zu konfigurieren. Das generelle Format dieser
Datei sieht so aus:
..
Suwalt::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:CSLIP,1006
ttyS1::145.71.34.3:145.71.34.2:255.255.255.0:Dynamic ttyS1:CSLIP,296
..
Die Felder bedeuten im Einzelnen:
Login Name
: Entsprechend dem Ergebnis von
getpwuid(getuid()) oder tty Name.unbenutzt
: Zur Kompatibilität mit passwdRemote Adresse
: IP Adress des einwählenden Rechners,
entweder numerisch oder als Name.Lokale Adresse
: IP Adress des eigenen Rechners, ebenfalls
numerisch oder als Name.Netz-Maske
: in punktierter Dezimalschreibweise.Kommentar
: Beliebig.Protokoll
: SLIP, cSLIP usw.MTU
: Dezimaler Wert.Für alle diejenigen Benutzer, für die eine statische Adresse verwendet
werden soll, muß ein solcher Eintrag in /etc/diphosts
angefügt
werden. Erlaubte SLIP-Benutzer, die ihre IP-Adresse dynamisch
zugewiesen bekommen sollen werden hier nicht eingetragen,
dadurch wird dann automatisch der Eintrag des verwendeten tty
benutzt. Aus diesem Grund sollte man für jedes tty
, über das
sich Benutzer in das System einwählen können, ein solcher Eintrag
angefügt werden um sicherzustellen, daß immer eine adäquate
Konfiguration durchgeführt werden kann.
Ein Benutzer der sich in ein so konfiguriertes System einwählt sollte zunächst einen ganz normalen Login-Promt sehen. Er muß dann seinen SLIP-Benutzernamen sowie sein Paßwort eingeben. Wenn alles glatt geht bekommt er keine weitere Meldung und muß nun auf seiner Seite nur noch die Verbindung in den SLIP-Modus schalten, und die Verbindung steht.
Matt Dillon (dillon@apollo.west.oic.com
) hat ein Paket von kleinen
Programmen und Shell-Scripts geschrieben, mit denen SLIP sowohl im
Dial-in wie im Dial-out betrieben werden kann. Allerdings muß die Shell
tcsh
installiert sein, da mindestens eines der Scripts auf
deren Syntax angewiesen ist. Jedoch ist dies keine große Einschränkung,
da die tcsh
bei den meisten Distributionen mitgeliefert wird.
Außerdem gehört zu Matts Paket auch eine ausführbare Kopie des
Programmes expect
, das ebenfalls an einigen Stellen benötigt
wird. Es ist von Vorteil wenn man sich mit expect
bereits
auskennt, da andernfalls bei der Konfiguration leicht Fehler gemacht
werden können. Aus diesem Grunde empfiehlt sich das Paket mehr für die
bereits mit Unix vertrauten, man sollte sich aber trotzdem nicht davon
abhalten lassen, sich das Programm einmal anzusehen, zumal Matt eine
sehr gute Installationsanleitung im README gibt.
Das dSLIP Paket bekommt man von:
apollo.west.oic.com:/pub/linux/dillon_src/dSLIP203.tgz
oder
sunsite.unc.edu:/pub/Linux/system/Network/serial/dSLIP203.tgz
Wichtig ist, das README aufmerksam zu lesen und vor allem die dort
angegebenen Einträge in den Dateien /etc/passwd
und
/etc/group
einzufügen, bevor ein make install
ausgeführt wird.
Dieser Abschnitt basiert auf einem Text, den Mitch DSouza zusammengestellt hat.
Ein Automounter stellt ein übliches Mittel dar um ein Dateisystem (meist über NFS) nur bei Bedarf zu mounten (der Fachausdruck hierfür ist on demand). Dadurch wird die Belastung sowohl des Servers wie auch des Klienten verringert, außerdem bietet dieses Vorgehen ein größtes Maß an Flexibilität, auch dann, wenn es sich nicht um NFS-Dateisysteme handelt. Er bietet sogar ein Sicherheitsmechanismus an durch den ein Dateisystem von einem anderen Server angefordert und gemounted werden kann, wenn der ursprüngliche Server nicht erreicht werden kann. Durch eine besonders nützliche Art des mounts, einen sogenannten union mount, können sogar die Inhalte unterschiedlicher Verzeichnisse in einem einzelnen Verzeichnis zusammengefaßt werden. Um diese hochentwickelten Optionen auszunutzen ist es aber auf jeden Fall nötig, die Dokumentationen sehr ausführlich und genau zu lesen.
Auf einige Dinge muß besonders geachtet werden:
amd
sind nicht kompatibel zu denen
von Sun, diese wiederum inkompatibel zu HP usw. Der Vorteil ist aber,
daß amd
ein frei erhältliches Programm ist, welches auf den
angegebenen und vielen weiteren Systemen installiert werden kann. Dann
fallen die Kompatibilitätsprobleme weg, und maps können auch in
heterogenen Systemen gemeinsam benutzt werden. Es gibt inzwischen schon
viele Beispiele von solchen gemischten Linux/Dec/NeXt/Sun
usw. Netzwerken.
contrib
ein perl
Script
mit dem Namen automount2amd.pl
, mit dem die vom Sun automounter
verwendeten Maps in das amd
-Format konvertiert werden können.
portmapper
muß unbedingt vor
amd
gestartet werden.
opts
-Option angesprochen werden:
..., opts:=type=msdos,conv=auto
direct
Option.
amd
mit der Option -x all
aktivieren. Ebenfalls
hilfreich ist oft auch die Information die der Befehl
% amq -ms
liefert. Dadurch werden alle auftretenden Probleme sofort gemeldet.
getopt()
von GNU ist manchmal etwas zu schlau.
Sicherheitshalber sollte deshalb `--' zwischen den amd
-Optionen
und den Parametern eingefügt werden, also z.B. so:
% /etc/amd -x all -l syslog -a /amd -- /net /etc/amd.net
sunsite.unc.edu:/pub/Linux/system/Misc/mount/amd920824upl67.tar.gz
Das Paket enthält sowohl Quelltexte und die vollständige Dokumentation im texinfo-Format als auch bereits kompilierte Binärdateien, die sofort installiert werden können.
Der Automounter wird nicht über die Datei /etc/fstab
konfiguriert, die in einem gewöhnlichen System die Informationen über
die Dateisysteme enthält. Vielmehr wird er über die Kommandozeile
gesteuert.
Nehmen wir folgendes Beispiel: In der Datei /etc/fstab
sind
zwei nfs
Dateisysteme eingetragen,
server-1:/export/disk /nfs/server-1 nfs defaults
server-2:/export/disk /nfs/server-2 nfs defaults
es werden also immer die Verzeichnisse /nfs/server-1
und
/nfs/server-2
von den beiden Servern server-1
und
server-2
via nfs
gemountet. Genausogut könnte man
diese beiden Einträge auskommentieren und amd
mit dem folgenden
Befehl starten:
/etc/amd -x all -l syslog -a /amd -- /nfs /etc/amd.server
| | | | | | | | | | | | |
| | | | | | | | | | | | |
`------' `----' `-------' `-----' -' `--' `-------------'
| | | | | | |
(1) (2) (3) (4) (5) (6) (7)
Die Einzelnen Komponenten bedeuten dabei
amd
.
Befindet sich amd
in einem Verzeichnis, das in der Variable
$PATH
enthalten ist genügt auch einfach nur amd
.
-x all
' schaltet die volle Protokollierung ein, um Fehler
leichter verfolgen zu können.
-l syslog
bewirkt, das die Protokollierung über den
syslog
Dämon erfolgt. Dadurch kann man getrennt entscheiden,
was mit diesen Informationen geschieht, ob sie in eine freie Konsole
geschrieben werden oder dauerhaft in einer Datei gespeichert werden.
Anstelle von syslog
kann auch ein Dateiname angegeben werden,
dort werden dann alle Meldungen abgelegt.
-a /amd
weist amd
an, das Verzeichnis
/amd
als temporären Platz für die automounts zu verwenden. Es
wird von amd
automatisch angelegt und sollte vor dem Start von
amd
in den /etc/rc.d/rc*
Scripts gelöscht werden.
--
dient wieder dazu, der getopt()
Funktion das
Ende der Kommandozeilenoptionen mitzuteilen. Dies ist insbesondere
nötig wenn man die Option type:=
verwendet, da
getopt()
diese falsch interpretieren würde.
/nfs
ist der wahre Mount Punkt. Auch dieser
wird automatisch angelegt und sollte normalerweise keine
Unterverzeichnisse aufweisen, wenn nicht die Option
type:=direct
verwendet wird.
amd
ist eine Datei, hier
/etc/amd.server
, die - für dieses Beispiel - folgende Zeilen
enthält:
# /etc/amd.server /defaults opts:=rw;type:=nfs server-1 rhost:=server-1;rfs:=/export/disk server-2 rhost:=server-2;rfs:=/export/disk
Ist der amd
Prozeß gestartet und läuft zufriedenstellend, kann
der Zustand der Mount-Tabelle abgefragt werden:
% amq -ms
Ein einfaches
% ls /nfs
wird keine Dateien anzeigen. Jedoch wird ein
% ls /nfs/server-1
bewirken, daß automatisch das gesuchte Verzeichnis von dem Rechner
`server-1' über nfs
gemountet wird, sodaß dessen Inhalt
angezeigt wird! Nachdem eine einstellbare Zeit vorüber ist, innerhalb
der nicht auf das Verzeichnis zugegriffen wurde, wird das Dateisystem
automatisch wieder ent-mounted.
Linux als Router in einem Netzwerk zu verwenden ist problemlos. Für
gewöhnlich verwendet man zu diesem Zweck gated
oder einen
ähnlichen Router-Dämon, für kleinere Netzwerke können aber auch einfache
statische Routes verwendet werden. Auf jeden Fall ist es aber wichtig,
die folgende Frage bei der Konfiguration des Kernels zu bejahen:
...
IP forwarding/gatewaying (CONFIG_IP_FORWARD) [y] y
...
Wer selber ein Netzwerk zu betreiben gedenkt sollte sich in jedem Fall den Network Administrators Guide von Olaf Kirch zulegen, dort sind auch zum Thema Routing alle notwendigen Details fachkundig zusammengefaßt.
Zu diesem Thema gibt es ein eigenes HOWTO, das NIS-HOWTO
(http://sunsite.unc.edu/mdw/HOWTO/NIS-HOWTO.html
). Wer
beabsichtigt, NIS auf seinem Rechner zu verwenden wird darin über alles
Notwendige informiert.