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.
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
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
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.
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!
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.
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.
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.
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.
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
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
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:
/etc/hosts
. Ein Nameserver ist dann nicht nötig.
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.
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
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
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.
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.
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.