Dieses Kapitel soll eine Einführung in die Netzwerkgrundlagen sein. Hier geht es darum, eine Maschine mit einem LAN und dem Internet zu verbinden. Die Verbindung zweier Computer mittels eines seriellen Kabels wird hier ebenfalls beschrieben.
Wenn zwei Computer Daten austauschen wollen, müssen sie auf irgendeinem Weg miteinander verbunden werden. Beispiel: Es können zwei Maschinen mit Netzwerkkarten versehen werden; möglicherweise benutzen sie auch noch einen Hub oder Switch. Diese Art der Verbindung wird gewöhnlich als LAN (Local Area Network) bezeichnet.
Im Gegensatz dazu ist das Internet ein WAN (Wide Area Network): Wenn Du mit dem Internet verbunden bist, kannst Du auf Computer zugreifen, die physikalisch sehr weit von Dir entfernt sind; und das, ohne die näheren Details über die Verbindung zwischen den beiden Maschinen zu kennen.
Das, was jetzt kommt, ist eine Liste mit den Dateien, die benutzt werden, um das Netzwerk zu konfigurieren. Einige dieser Dateien, die schon in ersten Kapiteln benutzt wurden, werden hier und in den folgenden Absätzen detaillierter beschrieben.
hosts: files dns
Es gibt viele Arten einer Internetverbindung: In dieser Sektion steht, wie eine Verbindung zu einem Provider mit einem Modem über die Telefonleitung aufgebaut wird. Dazu wird das »PPP«- Protokoll benutzt. Damit wir eine funktionierende Verbindung herstellen können, sind diese Schritte hier nötig:
Die nötigen Informationen vom Provider
»/etc/resolv.conf« und »/etc/nsswitch.conf« müssen überarbeitet oder geprüft werden
Die Verzeichnisse »/etc/ppp« und »/etc/ppp/peers« müssen erstellt werden, wenn es sie noch nicht gibt.
Das Verbindungsscript, die »chat«- und die »options«- Datei müssen erstellt werden.
Ausserdem brauchen wir noch eine Datei, in der der Username und das Passwort stehen.
Wenn man sich die Liste so ansieht, erscheint einem das als viel Arbeit, die vorausgesetzt wird. Zur Zeit sind die einzelnen Schritte aber recht einfach: Man muss nur ein paar kleinere Textdateien erstellen, modifizieren oder auch nur überprüfen. In unserem Beispiel wird davon ausgegangen, dass das Modem an den zweiten seriellen Anschluss (»/dev/tty01«) gestöpselt ist (COM2 in DOS).
|
Nebenbei bemerkt: Es können diese Modems benutzt werden: »/dev/tty0[012]« auf i386, »/dev/tty[ab] auf Sparcs, USB- Modems (»/dev/ttyU*«) und pcmcia/cardbus- Modems (»/dev/tty0[12]«). |
Als erstes brauchst Du vom Provider die nötigen Informationen für die Verbindung; was heisst:
Die Telefonnummer für den nächsten POP.
Die benutzte Authentisierungsmethode.
Benutzername un Passwort für die Verbindung.
Die IP- Adresse des Nameservers.
Die »/etc/resolv.conf« muss mit den Daten vom Provider konfiguriert werden, besonders, was die IP-Adressen des DNS angeht. In diesem Beispiel sind die Adressen des DNS 194.109.123.2 und 191.200.4.52 .
nameserver 194.109.123.2
nameserver 191.200.4.52
#lookup file bind
Anmerkung: Die letzte Zeile (»lookup file bind«) besagt, dass die Nameserver nur für die Namen benutzt werden, die in »/etc/hosts« nicht eingetragen sind. Diese Zeile ist auskommentiert, weil sei seit NetBSD 1.4 nicht mehr benötigt wird. Diese Information wird seitdem in »/etc/nsswitch.conf« definiert. Der neue Name-Service-Switch ändert den Zugriff auf die Datenbanken, die von Programmen benutzt werden, um die Systemkonfiguration zu ermitteln.
Hier ist ein Beispiel für eine »/etc/nsswitch.conf«-Datei..
# /etc/nsswitch.conf
group: compat
group_compat: nis
hosts: files dns
netgroup: files [notfound=return] nis
networks: files
passwd: compat
passwd_compat: nis
Notiz: Nur eine Zeile wurde geändert; und zwar die mit dem Wort »hosts«: Wenn ein Hostname aufgelöst wird, wird die lokale »hosts«- Datei zuerst durchsucht, bevor das DNS gefragt wird.
In den Verzeichnissen »/etc/ppp« und »/etc/ppp/peers« wird die Konfiguration der PPP- Verbindung gespeichert. Nach einer NetBSD- Neuinstallation gibt es sie noch nicht. Sie müssen erst erstellt werden (chmod 700).
Das Verbindungsscript wird als ein Parameter für die pppd- Kommandozeile benutzt; es liegt in »/etc/ppp/peers« und beinhaltet normalerweise den Namen des Providers. Beispiel: Wenn der Name des Providers »BigNet« und der Verbindungsname »alan« ist könnte ein Verbindungsscript so aussehen:
Beispiel 9-3: Verbindungsscript
# /etc/ppp/peers/bignet
connect '/usr/sbin/chat -v -f /etc/ppp/peers/bignet.chat'
noauth
user alan
remotename bignet.it
In diesem Beispiel beschreibt das Script eine »chat«- Datei, die bei der Verbindung benutzt werden soll. Die Details im Script werden in der ppp(8)- Manpage beschrieben.
Hinweis: Wenn Probleme mit der Verbindung auftreten sollten, hänge diese beiden Zeilen an das Verbindungsscript an:
debug
kdebug 4
Du bekommst dann eine Aufzeichnung der ausgeführten Operationen, wenn das System versucht, eine Verbindung aufzubauen. Siehe auch pppd(8) und syslog.conf(5).
Das Verbindungsscript ruft die »chat«- Applikation auf, die an der physikalischen Verbindung arbeitet (Modemstart, Einwahl...). Die Parameter können im Verbindungsscript angegeben werden; es ist aber besser, das in einer separaten Datei zu tun. Wenn die Telefonnummer der POP 02 999999999 ist, kann ein Beispielscript so aussehen:
# /etc/ppp/peers/bignet.chat
ABORT BUSY
ABORT "NO CARRIER"
ABORT "NO DIALTONE"
'' ATDT0299999999
CONNECT ''
Hinweis: Wenn Problem mit dem Chatscript auftauchen sollten, kannst Du versuchen, mit »cu« manuell eine Verbindung zum POP aufzubauen und die exakten Strings, die Du bekommst überprüfen. Siehe auch cu(1)
Während der Authentisierung ermittelt jedes System die Identität des anderen; praktisch bedeutet das, dass Du den Provider nicht authentisieren muss. Du wirst nur von ihm überprüft, und zwar mit diesen Methoden:
login
PAP/CHAP
Üblich ist bei den meisten Providern die PAP/CHAP- Authentisierung.
nach oben
Die Informationen zur Authentisierung liegen in »/etc/ppp/pap-secrets« für PAP und in »/etc/ppp/chao-secret« für CHAP. Die Zeilen darin benutzen dieses Format:
user * password
Beispiel:
alan * pZY9o
Hinweis: Aus Sicherheitsgründen sollten »pap-secrets uns »chap-secrets« immer zu root gehören und nur für diesen les- und schreibbar sein (chmod 600).
Diese Art der Authentisierung ist heute nicht so weit verbreitet. Wenn der Provider die Login- Authentisierung verwendet, müssen Username und Passwort in der Chat- Datei abgelegt werden; nicht in den PAP/CHAP- Dateien. In diesem Fall setzte die Zugriffsrechte auf die Dateien entsprechend.
Dieses ist ein Beispiel für eine Chat- Datei mit einer Login- Authentisierung:
Beispiel 9-5. Chatdatei mit Login
# /etc/ppp/peers/bignet.chat
ABORT BUSY
ABORT "NO CARRIER"
ABORT "NO DIALTONE"
'' ATDT0299999999
CONNECT ''
TIMEOUT 50
ogin: alan
ssword: pZY9o
Das einzige, was noch fehlt, ist die »options«- Datei, die »/etc/ppp/options« (chmod 644) genannt wird.
Beispiel 9-6. /etc/ppp/options
/dev/tty01
lock
crtscts
57600
modem
defaultroute
noipdefault
Was die Optionen bedeuten, steht in der »pppd(8)«- Manpage.
nach oben
Bevor der Link aktiviert wird, sollte ein schneller Modemtest gefahren werden, um die physikalische Verbindung und die Kommunikation, mit der das Modem arbeitet, zu testen. Für den Test kann das »cu«- Programm benutzt werden. Beispiel:
Erstelle die Datei »/etc/uucp/port« mit folgenden Zeilen:
type modem
port modem
device /dev/tty01
speed 115200
(Trage bitte das richtige Gerät an der Stelle von »/dev/tty01« ein).
Mit dem Kommando »cu -p modem« wird begonnen, einige Kommandos an das Modem zu schicken. Beispiel:
# cu -p modem
Connected.
ATZ
OK
~.
Disconnected.
#
In diesem Beispiel wurde das ATZ- Kommando an das Modem geschickt, das mit einem OK antwortete: Die Kommunikation funktioniert. Um »cu« zu verlassen, gib ein »~«(Tilde), gefolgt von einem Punkt ein; wie im Beispiel.
Wenn das Modem nicht funktioniert, kontrolliere, ob das Modem am richtigen Anschluss hängt (Wenn Du mit »cu« den richtigen Anschluss benützt). Auch die Kabel können schon mal die Übeltäter sein.
Hinweis: Wenn Du »cu« startest, und die Ausgabe auf dem Schirm »Permission denied« ist, prüfe nach, wer der Eigentümer der »/dev/tty**«- Geräte ist: uucp wäre korrekt. Beispiel:
$ ls -l /dev/tty00
crw------- 1 uucp wheel 8, 0 Mar 22 20:39 /dev/tty00
Wenn der Eigentümer root ist, passiert folgendes:
$ ls -l /dev/tty00
crw------- 1 root wheel 8, 0 Mar 22 20:39 /dev/tty00
$ cu -p modem
cu: open (/dev/tty00): Permission denied
cu: All matching ports in use
|
Ein paar Worte zum Unterschied zwischen »com«, »COM« und »tty«: In NetBSD ist »com« der Name des Treibers für die seriellen Anschlüsse (der, der von »dmesg« angezeigt wird). Und »tty« ist der Name des Anschlusses. Seit die Numerierung bei 0 beginnt, ist com0 der Treiber für den ersten seriellen Anschluss; genannt wird er tty00. In DOS ist statt dessen COM1 der erste serielle Anschluss (Liegt meistens auf 0x3f8), COM2 der zweite usw. Daher entspricht COM1 tty00 in NetBSD. |
Jetzt ist alles fertig, um sich mit diesem Kommando mit dem Provider zu verbinden:
# pppd call bignet
»bignet« ist der Name im schon beschriebenen Verbindungsscript. Um die Informationen, die »pppd« für Dich hat, zu lesen, tue das hier:
# tail -f /var/log/messages
Um die Verbindung abzubrechen mache ein »kill -HUP« für »pppd«
nach oben
Wenn die Verbindung funktioniert, ist es Zeit ein paar Scripts zu schreiben, um das dauernde Wiederholen der Kommandos zu verhindern. Diese beiden Script können beliebig benannt werden; wir benutzen hier »ppp-up« und »ppp-down«.
Ppp-up ist für die Aufnahme der Verbindung zuständig.
#!/bin/sh
MODEM=tty01
POP=bignet
if [ -f /var/spool/lock/LCK..$MODEM ]; then
echo ppp is already running...
else
pppd call $POP
tail -f /var/log/messages
fi
ppp-down bricht die Verbindung ab:
#!/bin/sh
MODEM=tty01
if [ -f /var/spool/lock/LCK..$MODEM ]; then
echo -f killing pppd...
kill -HUP `cat /var/spool/lock/LCK..$MODEM`
echo done
else
echo ppp is not active
fi
Die beiden Scripte gehen davon aus, dass »pppd« aktiv ist; es erstellt die Datei »LCK..tty01« im »/var/spool/lock«- Verzeichnis. In dieser Datei steht die »pid« des Prozesses.
Beide Scripte müssen ausführbar sein:
# chmod u+x ppp-up ppp-down
Das Networking ist eine der Hauptstärken von Unix und NetBSD macht da keine Ausnahme: Es ist billig zu haben, einfach zu installieren und leistungsfähig, weil man keine zusätzliche Software kaufen muss, um einen Server zu bauen oder mit diesem zu kommunizieren. In Sektion 9.4 steht, wie eine NetBSD- Maschine als Gateway für eine Netzwerk funktioniert: Mit IPNAT können alle Hosts im Netz über eine einzige Verbindung auf dem Gateway- Rechner mit einem Provider das Internet erreichen. Das einzige, was Du tun musst, ist, ein paar Netzwerkkarten zu kaufen, die von NetBSD unterstützt werden (In der INSTALL- Datei soll es eine Liste mit den unterstützten Karten geben).
Als Erstes müssen die Karten in die Maschinen eingebaut werden und mit einem Hub oder direkt verbunden werden (Siehe Bild 9-1).
Dann schau im »dmesg«- Output nach, ob die Karten vom Kernel erkannt werden. Im Beispiel handelt es sich um einen korrekt erkannten NE2000- Klon:
...
ne0 at isa0 port 0x280-0x29f irq 9
ne0: NE2000 Ethernet
ne0: Ethernet address 00:c2:dd:c1:d1:21
...
Wenn die Karte nicht erkannt wird, musst Du prüfen, ob die Karte in der Konfiguration eingeschaltet ist und die IRQs da gesetzt sind, wo der Kernel sie erwartet. Das hier ist eine NE2000- Karte für den ISA- Bus, die der Kernel auf Interrupt 9 erwartet.
...
ne0 at isa? port 0x280 irq 9 # NE[12]000 ethernet cards
...
Wenn die Konfiguration der Karte anders ist, wird sie wahrscheinlich beim Booten nicht gefunden. In diesem Fall hat Du zwei Möglichkeiten: Die entsprechende Zeile in der Konfigurationsdatei zu ändern und einen neuen Kernel zu backen oder die Einstellungen der Karte zu ändern (meistens mit einer Setup- Diskette oder, bei alten Karten, ein Jumper auf der Karte).
Das folgende Kommando zeigt die aktuelle Konfiguration der Karte:
# ifconfig ne0
ne0: flags=8822<BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500
media: Ethernet 10base2
Dir Softwarekonfiguration der Netzwerkkarte ist sehr leicht. Die IP- Adresse »192.168.1.1« (reserviert für interne Netze) wird der Karte zugewiesen.
# ifconfig ne0 inet 192.168.1.1 netmask 0xffffff00
Wenn Du das Kommando wiederholst, gibt es ein anderes Ergebnis:
# ifconfig ne0
ne0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
media: Ethernet 10base2
inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
Der Output von »ifconfig« hat sich geändert: Die IP- Adresse wird jetzt angezeigt; Ausserdem zwei neue Flags: »UP« und »RUNNIG«. Wenn das interface nicht »UP« ist, wird das System es nicht zu Verschicken von Paketen benutzen.
Der Host bekam die Adresse 192.168.1.1, die zu einem Satz von Adresse gehört, die für lokale Netze reserviert und nicht aus dem Internet erreichbar sind. Die Konfiguration ist nun fertig und muss getestet werden. Wenn ein anderer Host im Netz aktiv ist, kann ein »ping« versucht werden. Im Beispiel ist 192.168.1.2 der andere aktive Host:
# ping 192.168.1.2
PING ape (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: icmp_seq=0 ttl=255 time=1.286 ms
64 bytes from 192.168.1.2: icmp_seq=1 ttl=255 time=0.649 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=255 time=0.681 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=255 time=0.656 ms
^C
----ape PING Statistics----
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.649/0.818/1.286/0.312 ms
Mit der aktuellen Installation muss die Konfiguration nach einem Reboot wiederholt werden. Um das zu verhindern, müssen zwei Dinge getan werden: Erstens: Die Datei »/etc/ifconfig.ne0« mit dieser Zeile als Inhalt:
inet 192.168.1.1 netmask 0xffffff00
In »/etc/rc.conf« muss die folgende Option gesetzt werden:
auto_ifconfig=YES
Ab dem nächsten Boot wird die Netzwerkkarte automatisch konfiguriert.
»/etc/hosts« ist eine Datenbank mit IP- Adressen und den dazugehörigen Aliases: Sie sollte die Adressen aller Hosts enthalten, die zum lokalen Netzwerk gehören. Beispiel:
# $NetBSD: hosts,v 1.4 1997/01/09 05:33:14 mikel Exp $
#
# Host Database
# This file should contain the addresses and aliases
# for local hosts that share this file.
# It is used only for "ifconfig" and other operations
# before the nameserver is started.
#
#
127.0.0.1 localhost
#
# RFC 1918 specifies that these networks are "internal".
# 10.0.0.0 10.255.255.255
# 172.16.0.0 172.31.255.255
# 192.168.0.0 192.168.255.255
192.168.1.1 ape.insetti.net ape
192.168.1.2 vespa.insetti.net vespa
»/etc/nsswitch.conf« sollte modifiziert werden wie in Beispiel 9-2 beschrieben.
Hinweis: In diesem Beispiel wurde die Datei »/etc/ifconfig.ne0« erstellt, weil der Kernel die Netzwerkkarte als »ne0« erkannt hat. Wenn du eine andere Karte benützt, ersetze den Namen durch den für Dich richtigen.
Summasummarum: Um ein Netzwerk einzurichten, muss das hier getan werden: Die Netzwerkkarten müssen eingebaut und physikalisch verbunden werden. Dann muss man sie konfigurieren (mit »ifconfig«). Und zu guter Letzt müssen »/etc/hosts« und »/etc/nsswitch.conf« angepaßt werden. Diese Art des Netzwerkmanagements stark vereinfacht und für Netze ohne besondere Bedürfnisse passend.
nach oben
Die mysteriöse Abkürzung IPNAT steht für Internet Protocol Network Address Translation, womit man von einem internen Netzwerk in ein reales Netz routen kann (Gemeint ist das Internet). Das bedeutet: Mi nur einer »realen« IP- Adresse, egal ob statisch oder dynamisch, ist es möglich, für alle Hosts im internen Netzwerk simultane Verbindungen ins Internet aufzubauen.
Ein paar Beispiele, wie IPNAT benutzt wird, finden sich im Unterverzeichnis »/usr/share/examples/ipf: Schau Dir die Dateien »BASIC.NAT und »nat-setup« an.
Das Aufsetzen des in dieser Sektion beschriebenen Beispiels wird in Bild 9-1 detailliert gezeigt: Host 1 kann sich über ein Modem mit einem Provider verbinden und bezieht von diesem eine dynamische IP- Adresse. Host 2 und Host 3 können nicht direkt mit dem Internet kommunizieren: Host 1 dient in diesem Fall als Gateway für die anderen.
Bild 9-1. Netzwerk und Gateway
Um IPNAT benutzen zu können, muss das »Pseudo-Device Ipfilter« im Kernel vohanden sein. Stelle bitte fest, ob das der Fall ist:
# sysctl net.inet.ip.forwarding
net.inet.ip.forwarding = 1
Wenn das Ergebnis »1« ist, wie oben gezeigt, ist es im Kernel vorhanden. Wenn nicht ist die Ausgabe »0«. Dann kannst Du zwei Sachen machen:
Einen neuen Kernel kompilieren, in dem die GATEWAY- Option als Standard vorhanden ist
...oder die Option mit diesem Kommando im aktuellen Kernel einschalten:
# sysctl -w net.inet.ip.forwarding=1
Wenn Du diese Option in ein Bootscript einsetzst (Bsp: »/etc/rc.local«), passiert das künftig automatisch beim Booten.
Der Rest dieser Sektion beschreibt, wie eine IPNAT- Konfiguration aussieht, die immer dann automatisch gestartet wird, wenn mittels PPP eine Verbindung zum Provider aufgebaut wird. Mit dieser Konfiguration können sich alle Hosts im heimischen Netz durch einen Gateway- Rechner mit dem Internet verbinden, besonders, wenn sie mit NetBSD laufen.
Als Erstes brauchst Du eine leere »/etc/ipf.conf«:
# touch /etc/ipf.conf
Als nächstes brauchst Du die »/etc/ipnat.conf« mit diesen Regeln:
map ppp0 192.168.1.1/24 -> 0/32 proxy port ftp ftp/tcp
map ppp0 192.168.1.1/24 -> 0/32 portmap tcp/udp 40000:60000
map ppp0 192.168.1.1/24 -> 0/32
192.168.1.1/24 sind die Netzwerkadressen, die gemappt werden sollen (in diesem Fall geht das auch mit 192.168.1.0/24). Die erste Zeile in der Konfigurationsdatei ist optional: Sie erlaubt FTP- Verbindungen über den Gateway. Die zweite Zeile wird benutzt. Um icp und udp- Pakete korrekt zu händeln; Das Portmapping ist wegen des Verhältnisses Viele zu eins nötig. Die dritte Zeile erlaubt ICMP- Verbindungen für Ping usw.
In »/etc/rc.conf« muss das Portmapping eingeschaltet sein (Ipfilter ist nicht nötig).
Erstelle die »/etc/ppp/ip-up«-Datei, die automatisch aufgerufen wird, wenn der PPP- Link aktiviert wird.
#!/bin/sh
# /etc/ppp/ip-up
/usr/sbin/ipnat -F
/usr/sbin/ipnat -C
/sbin/ipf -E
/usr/sbin/ipnat -f /etc/ipnat.conf
Du brauchst dann noch »/etc/ppp/ip-down«, die aufgerufen wird, wen die Internetverbindung abgebrochen wird.
#!/bin/sh
# /etc/ppp/ip-down
/sbin/ipf -D
/usr/sbin/ipnat -C
Beide Dateien müssen ausführbar sein.
# chmod u+x ip-up ip-down
Der Gateway ist jetzt fertig.
nach oben
Erstelle eine »/etc/resolv.conf« wie auf dem Gateway.
Dann schreibst Du das Kommando hier:
# route add default 192.168.1.1
192.168.1.1 ist die Adresse des Gateways, den wir vorhin konfiguriert haben.
Natürlich wirst Du dieses Kommando nicht nach jedem Systemstart neu eingeben wollen; es ist besser, die Defaultroute in »/etc/rc.conf« einzutragen oder, was denselben Effekt hat, eine »/etc/mygate«- Datei anzulegen: Die Defaultroute wird beim Systemstart automatisch gesetzt, indem die Inhalte von »/etc/mygate« (oder die »defaultroute«- Option) als Argumente des »route add default«- Kommandos benutzt werden.
Wenn die Clients nicht mit NetBSD laufen, wird die Konfiguration anders sein. Auf Windows- PCs setzt Du den Gateway des TCP/IP- Protokolls auf die IP- Adresse des NetBSD- Gateways.
Das ist alles, was bei den Clients zu tun ist.
nach oben
Dieses Kommando ist nützlich, um Probleme zu diagnostizieren:
Wenn Du Dateien zwischen zwei nicht vernetzten PCs verschieben willst, gibt es eine einfache Lösung, wenn das Kopieren auf Disketten nicht praktikabel ist: Die beiden Maschinen können mit einem seriellen Kabel verbunden werden (Ein sog. Null- Modem- Kabel). In den folgenden Sektionen werden einige Konfigurationen beschrieben.
nach oben
Am einfachsten ist es, wenn auf beiden Maschinen NetBSD läuft: Eine Verbindung mit dem SLIP- Protokoll ist sehr einfach. Auf der ersten Maschine gibst Du diese Kommandos ein:
# slattach /dev/tty00
# ifconfig sl0 inet 192.168.1.1 192.168.1.2
Auf Maschine zwo das hier:
# slattach /dev/tty00
# ifconfig sl0 inet 192.168.1.2 192.168.1.1
Jetzt kannst Du die Verbindung mit einem »ping« vom zweiten PC aus testen:
# ping 192.168.1.1
Wenn alles funktioniert, gibt es jetzt eine aktive Verbindung zwischen den beiden Maschinen. FTP, telnet und Ähnliches können ausgeführt werden. Die Aliase und Adressen können in »/etc/hosts« abgelegt werden.
Im Beispiel benutzten beide PCs den ersten seriellen Anschluss (/dev/tty00). Passe das bitte an, wenn Du einen anderen Anschluss benutzen willst.
IP- Adressen wie 192.168.X.X sind für »interne« Netze reserviert. Der erste PC hat die Adresse 192.168.1.1 und der zweite 192.168.1.2
Um eine schnellere Verbindung zu erreichen, kann die Geschwindigkeit mit »-s speed« als Option zu »slattach« festgelegt werden.
ftp kann nur benutzt werden, wenn »inetd« aktiviert und der FTPD- Server eingeschaltet ist.
Linux: Wenn auf einer Maschine Linux läuft, sind die Kommandos etwas anders (nur auf der Linux- Maschine). Wenn die Linuxmaschine die Adresse 192.168.1.2 bekommt werden diese Kommandos gebraucht:
# slattach -p slip -s 115200 /dev/ttyS0 &
# ifconfig sl0 192.168.1.2 pointopoint 192.168.1.1 up
# route add 192.168.1.1 dev sl0
Vergiß das »&« im ersten Kommando nicht!
NetBSD und Windows NT können (meistens) einfach mit einem Nullmodemkabel verbunden werden. Was wir dazu brauchen, ist eine »Remote Access«- Verbindung und ein pppd auf NetBSD.
Starte pppd, sobald Du eine ».ppprc«- Datei in »/root« erstellt hast. Hier ist ein Beispiel, das als Schablone dienen kann:
connect '/usr/sbin/chat -v CLIENT CLIENTSERVER'
local
tty00
115200
crtscts
lock
noauth
nodefaultroute
:192.168.1.2
Was die erste Zeile bedeutet, wird später in dieser Sektion beschrieben. 192.168.1.2 ist die Adresse des NT- Rechners, die von NetBSD dem NT- Rechner zugeordnet wird. »tty00« ist der serielle Port, der für die Verbindung verwendet wird (der erste serielle Port).
Auf der NT- Seite muss ein Nullmodem- Gerät vom Modem- Kontrollfeld aus installiert werden. Ausserdem wir eine Remote-Access- Verbindung gebraucht. Der Nullmodemtreiber, der unter NT 4 Standard ist, ist kein 100%iger Nullmodemtreiber. Wenn die Verbindung aktiviert wird, sendet NT den String CLIENT und erwartet als Antwort CLIENTSERVER. Das besagt die erste Zeile von ».ppprc«: »chat« muss NT antworten, ansonsten klappt's nicht mit dem Nachbarn.
In der Konfiguration der Remote-Access-Verbindung muss folgendes festgelegt werden: das Nullmodem, Telefonnummer »1«(wird aber nicht benutzt) und die Nameserver des Servers (In diesem Fall NetBSD). Benutze Hardware-Flow und setze den Port auf 115200 8N1.
Jetzt kann die Verbindung aktiviert werden:
Verbinde die beiden Maschinen mit dem Nullmodemkabel.
Starte den pppd auf der NetBSD- Maschine
Aktiviere die Remote-Access- Verbindung auf Windows NT.
Das Setup für Windows 95 ähnelt dem für Windows NT: Remote-Access auf Windows 95 und der PPP- server auf NetBSD werden benutzt. Die meisten (nicht alle) Versionen von Windows 95 haben keinen Nullmodemtreiber, was diese Dinge ein bißchen komplizierter macht. Die einfachste Lösung ist es, sich einen Treiber aus dem Internet zu beschaffen (ist eine kleine ».inf«- Datei) und dieselben Schritte wie unter NT auszuführen. Der einzige unterschied ist, dass auf die erste Zeile in ».ppprc« (die, die »chat« aufruft) verzichtet werden kann.
Wenn Du so einen Treiber nicht im Internet finden kannst, geht es immer noch mit einem kleinen Trick:
Erstelle eine Remote-Access- Verbindung über das »Standardmodem«
In ».ppprc« muss die Zeile, mit der »chat« aufgerufen wird so aussehen:
connect '/usr/sbin/chat -v ATH OK AT OK ATE0V1 OK AT OK ATDT CONNECT'
Aktiviere die Verbindung wie in Sektion 9.5.2 beschrieben.
Auf diesem Weg schickt das »chat«- Programm dieselben Antworten an Windows 95, wie es in Standardmodem tut, sobald die Verbindung aktiv ist. Wenn Windows 95 ein Kommandostring sendet, schickt »chat« ein »ok« zurück.
nach oben
Jetzt, wo das Netzwerk funktioniert, kann man mit NFS Dateien und Verzeichnisse über das Netzwerk teilen. Aus dem Gesichtspunkt des Filesharings ist der Computer, der Zugriff auf seine Verzeichnisse und Dateien erlaubt; der Server und der andere, der auf diese Sachen zugreift, der Client. Ein Computer kann gleichzeitig Server un Client sein.
Ein Kernel mit den nötigen Optionen für Client und Server muss kompiliert werden (Die Optionen sind in der Kernel- Konfigurationsdatei leicht zu finden).
Der Server muss RPC- Dienste über »/etc/inetd.conf« anbieten.
In »/etc/rc.conf« müssen inetd, portmap und die nfs_server- Option aktiviert sein.
In der »/etc/rc.conf« des Clients müssen inetd und nfs_client aktiviert sein.
Im Server müssen die zu exportierenden Verzeichnisse gelistet sein und das Kommando kill -HUP `cat /var/run/mountd.pid muss anschliessend ausgeführt werden.
Ein Client kann auf ein entferntes Verzeichnis via NFS zugreifen, wenn...
der Server das Verzeichnis exportiert;
...und der Client das Verzeichnis mit dem Kommando »mount server:/xx/yy /mnt« mountet.
Das »mount«- Kommando kommt mit einer grossen Anzahl von Optionen für entfernte Dateisysteme, die nicht sehr intuitiv sind (um das wenigste zu sagen).
Warnung: Dieses ziemlich komplizierte Beispiel stammt von einer Mailingliste und ich habe es nicht getestet; aber es sollte Dir eine Ahnung verschaffen, wie NFS funktioniert.
Das Szenario ist das: Wir haben fünf Clients (cli1, ... ,cli5), die sich ein paar Verzeichnisse auf einem Server teilen sollen. Einige der exportierten Verzeichnisse sollen für einen bestimmten Client reserviert bleiben; auf die anderen Verzeichnisse dürfen alle Maschinen zugreifen. Alle Clients booten vom Server und müssen die Verzeichnisse mounten.
Die Verzeichnisse auf dem Server sehen so aus:
Dies ist das Dateisystem auf dem Server:
/dev/ra0a on /
/dev/ra0f on /usr
/dev/ra1a on /usr/src
/dev/ra2a on /export
Jeder Client braucht diese Dateisysteme:
buzz:/export/cli?/root on /
buzz:/export/common/usr on /usr
buzz:/usr/src on /usr/src
Der Server wird folgendermaßen konfiguriert:
# /etc/exports /usr/src -network 123.45.67.0 -mask 255.255.255.0 /export -alldirs -maproot=root -network 123.45.67.0 -mask 255.255.255.0
Die /etc/fstab auf den Clients sieht so aus:
buzz:/export/cli?/root / nfs rw
buzz:/export/common/usr /usr nfs rw,nodev,nosuid
buzz:/usr/src /usr/src rw,nodev,nosuid
Jeder Client hat seine Nummer, die mit den »?« in der ersten Zeile des Beispiels dargestellt wird.
nach oben