Zurück Weiter Inhalt

11. Die Konfiguration der Netzwerk-Dämonen

Zur Vervollständigung der Netzwerk-Konfiguration sind außer den beiden rc.inet*-Dateien noch weitere Konfigurationsdateien nötig. Diese kontrollieren das Verhalten des Netzwerk-Codes auf einer etwas höheren Ebene, nämlich dasjenige der Netzwerk-Dämonen, die u.a. in rc.inet2 gestartet werden. Die folgenden Unterabschnitte erläutern die wichtigsten davon.

11.1 /etc/rc.d/rc.inet2 (bzw. zweite Hälfte von rc.net)

Wer den Anweisungen des Textes bis zu diesem Punkt gefolgt ist besitzt nun eine rc-Datei, die jedes der vorhandenen Netzwerk-Devices korrekt konfiguriert und alle benötigten Routes zu den erreichbaren Netzwerken deklariert. Nun müssen die eigentlichen, höheren Netzwerk-Programme gestartet werden.

Das wäre genau der richtige Zeitpunkt, den Network Administrators Guide von Olaf Kirch zu lesen, denn er ist das Buch zu diesem Thema schlechthin. Es gibt alle notwendigen Hinweise, was in diese Datei aufgenommen werden sollte, und, fast noch wichtiger, was man hier nicht hineintun sollte. Im Hinblick auf die Systemsicherheit kann man nämlich ganz knapp sagen: Je mehr Netzwerk-Dienste konfiguriert und angeboten werden, desto höher ist das Risiko, ein Sicherheitsloch aufzutun. Also immer nur das konfigurieren, was auch wirklich benötigt wird.

In jedem Fall muß man einiges über die wichtigen Dämonen wissen, das sind Programme, die im Hintergrund ablaufen und viele Dinge automatisch regeln. Die Online-Hilfe mittels man gibt hier genauere Information, hier deshalb nur eine kurze Zusammenfassung:

inetd

inetd verwaltet sämtliche Anfragen zu Internet-Verbindungen und ähnlichem. Der große Vorteil von inetd ist, daß man nicht für alle angebotenen Dienste einen eigenen Serverprozeß laufen lassen muß, auch wenn momentan dieser Dienst gar nicht angefordert ist. Erst wenn eine Anfrage für einen bestimmten Dienst, z.B. telnet, eintrifft, sieht inetd in der Datei /etc/services nach, welches Programm diesen Dienst zur Verfügung stellt. Dieses Programm wird dann gestartet und die Verbindung an es weitergegeben. Man kann sich inetd also als eine Art Internet-Hauptserver vorstellen. Einige Standard-Dienste sind übrigens direkt in inetd implementiert, dies sind echo, discard ud generate, die für diverse Netzwerk-Tests verwendet werden. inetd kann nicht alle Dienste und Server-Programme verwalten, aber doch die am meisten verwendeten. Dienste wie z.B. solche die auf udp basieren, oder solche, die das Multiplexing ihrer Verbindungen selber regeln, wie World Wide Web oder MUDs müssen unabhängig von inetd gestartet werden. Im Normalfall wird in der Dokumentation solcher Pakete ein Hinweis gegeben, ob der jeweilige Dienst über inetd verwaltet werden sollte oder nicht.

syslogd

syslogd verwaltet das System Logging, also all die vielen Meldungen, die die verschiedenen Dämonen und Kernel-Module bei ihrer Arbeit produzieren. syslogd verteilt diese Meldungen gemäß einem Schema, welches in der Datei /etc/syslogd.conf festgelegt wird, entweder auf unterschiedliche Protokoll-Dateien oder verwirft sie. So können z.B. bestimmte Meldungen sowohl auf der Konsole ausgegeben als auch mitprotokolliert werden, andere hingegen nur ein einer Datei gespeichert werden.

11.2 Beispiel für eine rc.inet2 Datei

Das folgende Beispiel wurde von Fred van Kempen erstellt. Es startet eine große Zahl an Servern, es sollte also genau studiert und auf den für den eigenen Bedarf angemessenen Umfang reduziert werden. Die geschieht am besten, indem man die nicht benötigten Abschnitte durch ein Kommentarzeichen # deaktiviert, dann können sie zu einem späteren Zeitpunkt leichter wieder implementiert werden, sollte sich das eigene Anforderungsprofil ändern. Diese einzelnen Abschnitte bestehen jeweils aus einem Aufruf des entsprechenden Programms, welcher in einer if ... fi-Abfrage eingebettet ist. Diese tut nichts anderes als zu prüfen, ob die angegebene Datei auch existiert und ausführbar ist, um Fehlermeldungen zu vermeiden. Weiterhin wird ein kurzer Hinweis über das gestartete Programm ausgegeben. Hinweise zu den hier aufgeführten Dämonen entnimmt man entweder dem Network Administrators Guide oder der Online-Hilfe mittels man.


#! /bin/sh
#
# rc.inet2      This shell script boots up the entire INET system.
#               Note, that when this script is used to also fire
#               up any important remote NFS disks (like the /usr
#               distribution), care must be taken to actually
#               have all the needed binaries online _now_ ...
#
# Version:      @(#)/etc/rc.d/rc.inet2  2.18    05/27/93
#
# Author:       Fred N. van Kempen, <waltje@uwalt.nl.mugnet.org>
#

# Konstanten
NET="/usr/sbin"
IN_SERV="lpd"
LPSPOOL="/var/spool/lpd"

# Jetzt koennen auch NFS-Dateisysteme gemounted werden, das kann
# z.B. auch der gesamte /usr-Verzeichnisbaum sein
echo -e "\nMounting remote file systems ..."
/bin/mount -t nfs -v

echo -e "\nStarting Network daemons ..."
# Als erste wird der SYSLOG Daemon gestartet.  Dies muss der
# erste Server sein, er ist IN JEDEM FALLE notwendig!
echo -n "INET: "
if [ -f ${NET}/syslogd ]
then
echo -n "syslogd "
${NET}/syslogd
fi

# Starte den SUN RPC Portmapper.
if [ -f ${NET}/rpc.portmap ]
then
echo -n "portmap "
${NET}/rpc.portmap
fi

# Starte den INET SuperServer
# Auch dieser ist IMMER NOTWENDIG! 
if [ -f ${NET}/inetd ]
then
echo -n "inetd "
${NET}/inetd
else
echo "no INETD found.  INET cancelled!"
exit 1
fi

# Starte den NAMED/BIND Nameserver.
# HINWEIS: named wird fuer endbenutzer-Rechner meist nicht benoetigt.
#if [ ! -f ${NET}/named ]
#then
#        echo -n "named "
#        ${NET}/named
#fi

# Starte den ROUTEd Server.
# HINWEIS: routed ist veraltet, stattdessen wird gated benutzt.
#if [ -f ${NET}/routed ]
#then
#        echo -n "routed "
#        ${NET}/routed -q #-g -s
#fi

# Starte den GATEd Server.
if [ -f ${NET}/gated ]
then
echo -n "gated "
${NET}/gated
fi

# Starte den RWHO Server.
if [ -f ${NET}/rwhod ]
then
echo -n "rwhod "
${NET}/rwhod -t -s
fi

# Starte den U-MAIL SMTP Server.
if [ -f XXX/usr/lib/umail/umail ]
then
echo -n "umail "
/usr/lib/umail/umail -d7 -bd </dev/null >/dev/null 2>&1 &
fi

# Starte die verschiedenen INET Server.
for server in ${IN_SERV}
do
if [ -f ${NET}/${server} ]
then
                echo -n "${server} "
                ${NET}/${server}
fi
done

# Starte die diversen SUN RPC Server.
if [ -f ${NET}/rpc.portmap ]
then
if [ -f ${NET}/rpc.ugidd ]
then
                echo -n "ugidd "
                ${NET}/rpc.ugidd -d
fi
if [ -f ${NET}/rpc.mountd ]
then
                echo -n "mountd "
                ${NET}/rpc.mountd
fi
if [ -f ${NET}/rpc.nfsd ]
then
                echo -n "nfsd "
                ${NET}/rpc.nfsd
fi

# Starte den/die PC-NFS Daemon(en).
if [ -f ${NET}/rpc.pcnfsd ]
then
                echo -n "pcnfsd "
                ${NET}/rpc.pcnfsd ${LPSPOOL}
fi
if [ -f ${NET}/rpc.bwnfsd ]
then
                echo -n "bwnfsd "
                ${NET}/rpc.bwnfsd ${LPSPOOL}
fi

fi
echo network daemons started.
# Fertig!

11.3 Weitere notwendige Netzwerk-Konfigurationsdateien

Soll es anderen Personen ermöglicht werden, Verbindung mit dem eigenen Rechner aufzunehmen, so sind einige weitere Konfigurationsdateien notwendig. Wer ein Linux-System aus einer zusammengestellten Distribution installiert hat, wird diese Dateien vermutlich schon an den entsprechenden Stellen besitzen. Dann genügt es, diese auf Korrektheit zu überprüfen. Ansonsten sind hier Standardbeispiele aufgeführt.

Beispiel für eine /etc/inetd.conf Datei

In /etc/rc.d/rc.inet2 werden der inetd- und der syslogd-Dämon sowie diverse rpc Server gestartet. Die von inetd verwalteten Dienste müssen in der Datei /etc/inetd.conf konfiguriert werden. Das folgende Beispiel zeigt eine solche einfache Konfiguration:


#
# The internal services.
#
# Authors:      Original taken from BSD UNIX 4.3/TAHOE.
#               Fred N. van Kempen, <waltje@uwalt.nl.mugnet.org>
#
echo    stream tcp nowait root  internal
echo    dgram  udp wait   root  internal
discard stream tcp nowait root  internal
discard dgram  udp wait   root  internal
daytime stream tcp nowait root  internal
daytime dgram  udp wait   root  internal
chargen stream tcp nowait root  internal
chargen dgram  udp wait   root  internal
#
# Standard services.
#
ftp     stream tcp nowait root  /usr/sbin/tcpd in.ftpd ftpd
telnet  stream tcp nowait root  /usr/sbin/tcpd in.telnetd
#
# Shell, login, exec and talk are BSD protocols.
#
shell   stream tcp nowait root  /usr/sbin/tcpd in.rshd
login   stream tcp nowait root  /usr/sbin/tcpd in.rlogind
exec    stream tcp nowait root  /usr/sbin/tcpd in.rexecd
talk    dgram  udp wait   root  /usr/sbin/tcpd in.talkd
ntalk   dgram  udp wait   root  /usr/sbin/tcpd in.talkd
#
# Status and Information services.
#
finger  stream tcp nowait root  /usr/sbin/tcpd in.fingerd
systat  stream tcp nowait guest /usr/sbin/tcpd /usr/bin/ps -auwwx
netstat stream tcp nowait guest /usr/sbin/tcpd /bin/netstat
#
# End of inetd.conf.

Die Online-Hilfe zu inetd beschreibt ausführlich, was jedes dieser Felder darstellt. Kurz gesagt wird für jeden der in der ersten Spalte aufgeführten Dienste angegeben, welches Programm gestartet werden soll, wenn dieser Dienst angefordert wird. Diejenigen Einträge, bei denen im letzten Feld internal steht, werden von inetd selbst zur Verfügung gestellt.

Die Übersetzung vom Namen eines Dienstes (aus der ersten Zeile) und der Socket Nummer, über die dieser Dienst erreichbar ist, wird in der Datei /etc/services festgelegt.

Beispiel für die Datei /etc/services

Die Datei /etc/services ist eine einfache Tabelle der Namen der Internet-Dienste, ihrer Socket-Nummern und des verwendeten Protokolls. Diese Tabelle wird von einigen Programmen verwendet, darunter inetd, telnet und tcpdump. Die Zuordnung von Namen dient dabei übrigens nur dazu, daß man sich die Dienste leichter merken kann. Dem Rechner ist es egal, ob er mit Namen oder Nummern arbeitet.

Eine typische /etc/services Datei sieht so aus:


#
# /etc/services - database of service name, socket number
#                 and protocol.
#
# Original Author:
#     Fred N. van Kempen, <waltje@uwalt.nl.mugnet.org>
#
tcpmux     1/tcp
echo       7/tcp
echo       7/udp
discard    9/tcp   sink null
discard    9/udp   sink null
systat     11/tcp  users
daytime    13/tcp
daytime    13/udp
netstat    15/tcp
chargen    19/tcp  ttytst source
chargen    19/udp  ttytst source
ftp-data   20/tcp
ftp        21/tcp
telnet     23/tcp
smtp       25/tcp  mail
time       37/tcp  timserver
time       37/udp  timserver
name       42/udp  nameserver
whois      43/tcp  nicname    # usually to sri-nic
domain     53/tcp
domain     53/udp
finger     79/tcp
link       87/tcp  ttylink
hostnames  101/tcp hostname   # usually to sri-nic
sunrpc     111/tcp
sunrpc     111/tcp portmapper # RPC 4.0 portmapper TCP
sunrpc     111/udp
sunrpc     111/udp portmapper # RPC 4.0 portmapper UDP
auth       113/tcp authentication
nntp       119/tcp usenet     # Network News Transfer
ntp        123/tcp            # Network Time Protocol
ntp        123/udp            # Network Time Protocol
snmp       161/udp
snmp-trap  162/udp
exec       512/tcp            # BSD rexecd(8)
biff       512/udp comsat
login      513/tcp            # BSD rlogind(8)
who        513/udp whod       # BSD rwhod(8)
shell      514/tcp cmd        # BSD rshd(8)
syslog     514/udp            # BSD syslogd(8)
printer    515/tcp spooler    # BSD lpd(8)
talk       517/udp            # BSD talkd(8)
ntalk      518/udp            # SunOS talkd(8)
route      520/udp routed     # 521/udp too
timed      525/udp timeserver
mount      635/udp            # NFS Mount Service
pcnfs      640/udp            # PC-NFS DOS Authentication
bwnfs      650/udp            # BW-NFS DOS Authentication
listen     1025/tcp listener  # RFS remote_file_sharing
ingreslock 1524/tcp           # ingres lock server
nfs        2049/udp           # NFS File Service
irc        6667/tcp           # Internet Relay Chat
# End of services.

Hier zeigt z.B. der Eintrag bei telnet, daß dieser Dienst Socket 23 und das tcp-Protokoll verwendet, und daß der Domain Name Service domain Socket 52 benutzt und als Protokoll sowohl tcp als auch udp. Wichtig ist in jedem Fall, das für jeden Eintrag in /etc/inetd.conf ein entsprechender in /etc/services vorhanden ist.

Beispiel für die Datei /etc/protocols

Die Datei /etc/protocols enthält eine Tabelle der Protokollnamen und ihrer Protokollnummern. Da es nur recht wenig verwendete Protokolle gibt, ist diese Datei recht kurz und einfach:


#
# /etc/protocols - database of protocols.
#
# Original Author:
#   Fred N. van Kempen, <waltje@uwalt.nl.mugnet.org>
#
ip   0   IP   # internet protocol
icmp 1   ICMP # internet control message protocol
igmp 2   IGMP # internet group multicast protocol
ggp  3   GGP  # gateway-gateway protocol
tcp  6   TCP  # transmission control protocol
pup  12  PUP  # PARC universal packet protocol
udp  17  UDP  # user datagram protocol
idp  22  IDP
raw  255 RAW
#
# End of protocols.

11.4 Name Resolution

Als Name Resolution bezeichnet man den Prozeß, einen Rechnernamen (z.B. tsx-11.mit.edu) in die entsprechende IP-Adresse in punktierter Dezimalschreibweise zu übersetzen, die die Netzwerk-Software benötigt. Hierfür gibt es zwei prinzipielle Möglichkeiten, eine einfache und eine etwas komplexere.

/etc/hosts

/etc/hosts enthält eine Liste von IP-Adressen und der Rechnernamen, die dieser Adresse entsprechen. Auf diese Weise können die dort angegebenen Rechner durch ihre Namen angesprochen werden, anstatt die (Nummern)-Adresse zu verwenden. Die Benutzung eins Nameservers (siehe Abschnitt `named') erlaubt, dasselbe automatisch durchzuführen (mittels named kann man auch seinen eigenen Rechner als Nameserver konfigurieren). /etc/hosts muß mindestens einen Eintrag für die Adresse 127.0.0.1 mit dem Namen localhost enthalten, wer kein Loopback benutzt, muß außerdem die eigene Adresse mit vollem Rechnernamen (also Hostname und Domainname, loomer.vpizza.com) hinzufügen. Ebenfalls empfehlenswert ist es, Einträge für die verwendeten Gateways, Nameserver und evtl. lokale Adressen anzulegen.

Wenn zum Beispiel der Rechner loomer.vpizza.com die IP-Adresse 128.253.154.32 besitzt, sähe ein entsprechender Eintrag in /etc/hosts folgendermassen aus:


# /etc/hosts
# List of hostnames and their ip addresses
127.0.0.1               localhost
128.253.154.32          loomer.vpizza.com loomer
# end of hosts

Diese Datei muß in jedem Fall editiert und den eigenen Bedürfnissen angepaßt werden. Wer Loopback verwendet, benötigt darin aber lediglich einen einzigen Eintrag: 127.0.0.1, wobei sowohl localhost als auch der Rechnername eingetragen sind.

In der zweiten Zeile im obigen Beispiel sind übrigens zwei Namen für die Adresse 128.253.154.32 eingetragen: loomer.vpizza.com und nur loomer. Der erste Eintrag ist der volle Name des Rechners, den man als "Fully Qualified Domain Name" (FQDN) bezeichnet, der zweite Eintrag ist ein alias dafür. Dies erlaubt es, den Rechner unter diesem Namen anzusprechen und z.B. nur rlogin loomer einzugeben, anstatt den vollen Namen zu verwenden. In jedem Fall sollte der FQDN der erste Eintrag nach der IP-Adresse sein.

Named - brauche ich das ?

named ist der Nameserver Dämon in vielen Unix-ähnlichen Betriebssystemen. Er erlaubt es dem Rechner, die Adressen-Namens-Zuordnung nicht nur für sich selbst sondern auch für anderer Rechner im Netzwerk durchzuführen. D.h. wenn ein anderer Rechner z.B. die Adresse des Rechners goober.norelco.com sucht und sich dieser Name in der Datenbasis von named befindet, dann kann der eigene Rechner dem anderen die gesuchte IP-Adresse mitteilen.

Unter früheren Implementationen von TCP/IP unter Linux war es erforderlich, einen named-Server zu installieren, wenn man Aliase für Rechnernamen verwenden wollte, selbst wenn es für den eigenen Rechner war. Das Problem dabei ist, daß named relativ kompliziert zu konfigurieren ist. Hierfür gab es ein Hilfsprogramm mit dem Namen hostcvt.build. Dieses konvertierte die Datei /etc/hosts in die vielen Einzeldateien, die die Datenbasis für named darstellen. Doch selbst mit dieser Vereinfachung verursacht named einiges an zusätzlicher CPU- und Netzwerk-Belastung.

Aus diesem Grund lohnt sich der Einsatz von named nur in folgenden Fällen:

Generell kann man zusammenfassen: named wird nicht benötigt. Er kann deshalb in der Datei rc.inet2 auskommentiert werden. Aliasing von Rechnernamen ist unter den aktuellen Implementationen auch über die Datei /etc/hosts möglich, es müssen lediglich die gewünschten zusätzlichen Namen hinter dem vollen Namen (FQDN) angegeben werden. Solange man Zugriff auf einen Nameserver hat (dessen Adresse kann man vom Netzwerk-Administrator erfahren) gibt es keinen Grund, selber named zu benutzen.

Wer Loopback verwendet kann trotzdem einen Nameserver mittels named konfigurieren, als Adresse für den Nameserver muß man dann 127.0.0.1 verwenden. Allerdings ist das recht bizarr, denn der eigene Rechner ist ja der einzige, mit dem man kommunizieren kann, sodaß eine Anfrage an named nie stattfinden wird.

/etc/networks

Die Datei /etc/networks enthält eine Liste der Namen und Adressen der bekannten Netzwerke, also zumindest diejenige des lokalen Netzwerkes. route benutzt diese Datei, wenn das Netzwerk mit dem Namen anstatt seiner Adresse angegeben wird, um aus diesem Namen eine gültige Adresse zu erfahren.

Es empfiehlt sich, für jedes Netzwerk, zu dem explizit eine Route angelegt werden soll, einen solchen Eintrag in /etc/networks anzufügen. Ist ein Netzwerk nicht in dieser Datei aufgeführt, so muß der Parameter -net mit route-Befehl benutzt werden um anzuzeigen, daß es sich bei der Adresse um ein Netzwerk und nicht einen einzelnen Rechner handelt.

Das Format der Datei ist ganz ähnlich zu demjenigen von /etc/hosts, eine typische Datei sieht folgendermassen aus:


#
# /etc/networks: list all networks that you wish to add route commands
#                for in here
#
default         0.0.0.0         # default route    - recommended
loopnet         127.0.0.0       # loopback network - recommended
mynet           128.253.154.0   # Example network CHANGE to YOURS
#
# end of networks

/etc/host.conf

Das System stellt einige Bibliotheks-Routinen zur Verfügung, die man die Resolver Library nennt. Die Datei /etc/host.conf legt fest, wie das System bei der Übersetzung von Rechnernamen in gültige IP-Adressen vorgeht. Mindestens zwei Einträge sollten vorhanden sein:


order hosts,bind
multi on

Diese beiden Zeilen weisen die Bibliotheksroutinen an, die Rechneradressen zunächst in der Datei /etc/hosts zu suchen und dann, falls die gesuchte Adresse dort nicht gefunden wurde, einen Nameserver zu fragen. Der Eintrag multi erlaubt es dabei, in der Datei /etc/hosts mehrere Adresseinträge für einen bestimmten Rechnernamen zu haben.

Diese Datei entstammt der Implementation der resolv+ bind Library unter Linux. Weitere Informationen dazu enthält die Online-Hilfe zu resolv+(8), allerdings ist sie nicht bei allen Distributionen standardmäßig enthalten. In diesem Fall kann man sie sich hier besorgen:

sunsite.doc.ic.ac.uk:/computing/comms/tcpip/nameserver/resolv+/resolv+2.1.1.tar.Z

/etc/resolv.conf

/etc/resolv.conf konfiguriert den Name-Resolver des Systems, der die Rechnernamen in IP-Adressen übersetzt. Es gibt zwei unterschiedliche Arten von Einträgen in dieser Datei: Die Adressen des oder der Nameserver(s) sowie die Domain-Adresse. Wer auf dem lokalen Rechner selber named als Nameserver betreibt, der muß als Nameserveradresse die Loopbackadresse 127.0.0.1 angeben.

Der Domain Name besteht aus dem vollen Rechnernamen (FQDN) ohne den eigentlichen Namensanteil, also für das Beispiel von vorhin (loomer.vpizza.com) wäre der Domain Name vpizza.com.

Für einen Rechner mit dem (vollen) Namen goober.norelco.com, dessen Nameserver die Adresse 128.253.154.5 besitzt, sähe die Datei /etc/resolv.conf dann folgendermaßen aus:


domain norelco.com
nameserver 128.253.154.5

Es können auch mehrere Nameserver eingetragen werden, dann muß jede Adresse in eine eigene Zeile geschrieben werden, jeweils mit dem Schlüsselwort nameserver am Zeilenanfang.

Wer lediglich im Loopbackbetrieb arbeitet braucht wie bereits erwähnt keinen Nameserver.

Die Festlegung des Rechnernamens - /etc/HOSTNAME

Nachdem nun alles andere konfiguriert ist fehlt nur noch eine Kleinigkeit: der eigene Rechner muß seinen Namen mitgeteilt bekommen. Denn Programme wie sendmail müssen schließlich wissen, für welchen Rechner sie die mail in Empfang nehmen sollen, und sie müssen sich ja auch anderen Rechnern gegenüber identifizieren.

Diese Konfiguration des Namens geschieht über zwei unterschiedliche Programme, hostname und domainname. Leider wird ihre Anwendung manchmal durcheinandergebracht.

Wer eine Version der net-tools älter als 1.1.38 benutzt, kann in seine /etc/rc-Datei folgenden Befehl aufnehmen:

/bin/hostname -S

hostname wird dann die Datei /etc/HOSTNAME lesen, in der der volle Rechnername (FQDN), also Rechnername und Domain-Name, stehen muß. Dieser Name wird dann von hostname in Host- und Domain-Name aufgespalten und zur Konfiguration verwendet.

Die Versionen der net-tools-1.1.38 später sollten in ihrer Datei /etc/rc.d/rc.inet1 folgende Zeilen am Ende einfügen:

/bin/hostname goober.norelco.com

oder, falls man en Upgrade einer früheren Version durchgeführt hat oder einfach den Rechnernamen lieber in /etc/HOSTNAME stehen hat:

/bin/hostname -F /etc/HOSTNAME

Dadurch erreicht man dasselbe Verhalten wie bei der früheren Version.

Der Befehl /bin/domainname dient nicht der Festlegung des DNS Domain Namens, sondern er bestimmt den N.I.S. Domain Namen. Dieser wird aber nur benötigt, wenn auch NIS verwendet werden soll, das später noch kurz beschrieben wird.

11.5 Weitere Dateien

Natürlich gibt es im Verzeichnis noch eine ganze Menge an Dateien, mit denen man sich früher oder später wird befassen müssen. Hier soll aber nur eine Minimalkonfiguration beschrieben werden, um den Rechner netztauglich zu machen. Für weitere Informationen sei nochmals auf den Network Administration Guide von Olaf Kirch verwiesen. Er steigt dort ein, wo dieses HOWTO aufhört.

Nachdem nun alles notwendige konfiguriert ist steht einem Reboot des neuen Kernels nichts mehr entgegen, um nach Herzenslust im Netz zu surfen. In jedem Fall empfiehlt es sich aber, eine Version des alten Kernels aufzubewahren, entweder in Form einer Boot-Diskette oder als zusätzlicher Menüpunkt für LILO. Der sicherste Weg ist in jedem Fall eine Rettungsdiskette mit einem eigenen lauffähigen System, nur für den Fall, daß etwas schiefgeht. Inzwischen gibt es einige solcher Rettungssysteme, z.B. HJLu's `single disk boot disk', die boot/root Disketten einer beliebigen Distribution oder ein mit yard selber zusammengestelltes System.


Zurück Weiter Inhalt