| Übersicht |
|
Der vorliegende Abschnitt beschreibt die Syntax der Konfigurationsdateien in /etc mit netzwerkrelevantem Inhalt. Die alphabetische Anordnung unterstreicht unser Ansinnen, diese Darstellung nicht vorrangig als Lehrstoff sondern als Referenz zu verstehen.
So manche Konfigurationsdatei wird von zahlreichen Programmen benötigt. Andere wiederum sind nur für einen einzigen Dienst relevant. Die »allgemeineren« Dateien werden nachfolgend vollständig beschrieben. Wir werden uns bei der Besprechung der Dienste auf die hier getroffenen Aussagen berufen, ohne die Details zu wiederholen. Dem entgegen sollen die Feinheiten der »spezifischen« Konfigurationsdateien erst im Abschnitt zum jeweiligen Dienst die ihnen gebührende Aufmerksamkeit erfahren. Dass wir sie dennoch hier erwähnen, dient der Vollständigkeit der Aufzählung.
| Die Datei /etc/HOSTNAME |   |
In der Startphase des Netzwerks ermitteln einige Programme anhand des Inhalts dieser Datei den Namen des Rechners. Im Unterschied zu SuSE-Linux nennt sich die Datei bei RedHat und Debian /etc/hostname. Hier sollten Sie den Netzwerknamen des Rechners ohne die Domainerweiterung eintragen. Für den Rechner sonne.galaxis.de lautet der Eintrag:
| user@sonne> cat /etc/HOSTNAME sonne |
Genau genommen, weist das Kommando hostname einem Rechner seinen Namen zu. Nahezu alle Distributionen lesen den Inhalt von /etc/hostname bzw. /etc/HOSTNAME während des Bootvorgangs ein und füttern damit hostname.
| Die Datei /etc/exports |
|
Die Datei /etc/exports legt die von einem Network Filesystem Server bereitgestellten Verzeichnisse fest. Zu jedem Verzeichnis wird eine Liste der Rechner angeführt, die dieses importieren dürfen. Des Weiteren regeln verschiedene Optionen die Art des Zugriffs wie auch die Verfahrensweise mit bestimmten Benutzerkennungen (bspw. Root). Ein Eintrag besitzt folgende Gestalt:
| <Verzeichnis> <Rechner>([Option(en)]) [<Rechner>([Option(en)])] |
Rechner kann hierbei sowohl ein konkreter Rechnername ("sonne", "sonne.galaxis.de") sein, als auch ein durch Wildcards angegebenes Muster für Rechnernamen ("*.galaxis.de") oder aber eine Netzgruppe ("@LocalAdmins") sein. Letztere muss in der Datei /etc/netgroup erscheinen.
Die Besprechung der vielfältigen Optionen soll dem Abschnitt zum NFS-Server vorbehalten bleiben, an dieser Stelle dient einzig ein Beispiel der Demonstration des grundsätzlichen Aufbaus dieser Datei:
| user@sonne> cat /etc/exports # Verzeichnis darf von jedem Rechner »nur-lesend« importiert werden /opt/export/ *(ro) # Root bleibt Root auf diesem Verzeichnis /usr/src/linux @developer(no_root_squash,rw) # Einige Home-Verzeichnisse /home/user *.galaxis.de(rw) @outside(rw) /home/tux *.galaxis.de(rw) @outside(rw) # Für »diskless« Clients: /tftpboot/nfsroot *(rw,no_root_squash) |
| Die Dateien /etc/ftpaccess, /etc/ftpconversions, /etc/ftpmsg.dead, /etc/ftpusers |
|
| Die Dateien /etc/gated, /etc/gated.conf, /etc/gated.version | |
| Die Datei /etc/host.conf | |
Die Datei steuert den so genannten Resolver, also den Mechanismus, der für die Auflösung von symbolischen Rechnernamen in IP-Adressen und umgekehrt zuständig ist. Allerdings greifen einzig Programme auf »/etc/host.conf« zurück, die gegen die (veralteten) Bibliotheken »libc4« bzw. »libc5« gelinkt sind. Aktuelle Programme nutzen die »glibc2« (diese Bezeichnung ist gebräuchlicher als »libc6«), wo die durch »/etc/host.conf« bereit gestellte Funktionalität von der Datei /etc/nsswitch.conf übernommen wird.
Um aus einem symbolischen Rechnernamen die zugehörige IP-Adresse zu ermitteln, stehen prinzipiell 3 Möglichkeiten zur Verfügung:
- Nachschauen in der Datei /etc/hosts
- Befragen eines Domain Name Servers
- Befragen eines NIS (oder NIS+) Servers
Damit ergibt sich einmal die Frage, auf welches Vorgehen Sie zurückgreifen möchten und, im Falle der Verwendung mehrerer Schemata, in welcher Reihenfolge eine Auflösung erfolgen soll.
| user@sonne> cat /etc/host.conf order hosts nis bind multi on |
In der Datei »/etc/host.conf« bestimmt die mit order beginnende Zeile die Namensauflösung. »hosts« besagt, dass zunächst in der lokalen Datei /etc/hosts nachgesehen werden soll (die lokale Auflösung sollte immer zuerst stehen), anschließend soll ein NIS-Server befragt werden (nis) und, falls immer noch kein Ergebnis erzielt wurde, soll nun die Adresse über DNS ermittelt werden (»bind«, hier kann auch »dns« stehen). multi on besagt, dass ein Rechner durchaus mehrere IP-Adressen haben kann (Gateways, Router,...), mit »multi off« führt eine Anfrage, die verschiedene IP-Adressen ermittelt, zu einem Fehler.
| Die Datei /etc/hosts |
|
In dieser Datei findet die Zuordnung von Rechnernamen zu entsprechenden IP-Adressen statt. Selbstverständlich kann hier nicht jeder Rechner des Internets aufgeführt werden (in dessen Anfängen war es aber so), weshalb diese Datei nur für die unmittelbaren, »wichtigen« Nachbarrechner (z.B. Nameserver, DNS-Server, Proxy) genutzt wird.
| user@sonne> cat /etc/hosts # Typischer Aufbau einer /etc/hosts # <IP-Adresse> <vollständiger Rechnername> <Rechnername> [<Alias>] # 127.0.0.0 localhost # loopback 192.168.10.101 sonne.galaxis.de sonne mail 192.168.85.1 tuxhausen.outside.all tuxhausen # Darstellung der Adresse in oktaler Form 0340.023.0222.03 vulcan.outsite.org # Darstellung der Adresse in hexadezimaler Form 0xA0.0x77.0x02.0x02 melmac.outsite.com |
| Die Dateien /etc/hosts.allow, /etc/hosts.deny, /etc/hosts.equiv | |
Die Datei hosts.allow dient der Zugangskontrolle von Nutzern/Diensten anderer Rechner. Für bestimmte Hosts/Netzwerke kann hier der Zugriff auf bestimmte lokale Dienste explizit gestattet werden.
| user@sonne> cat /etc/hosts.allow # Aufbau einer /etc/hosts.allow # <service list> : <host list> [: command] # # Mail ist jedem gestattet # in.smtpd: ALL # Telnet und FTP wird nur Hosts derselben Domain und dem Rechner tuxhausen erlaubt. # telnetd, ftpd: LOCAL, tuxhausen.outside.all # Finger ist jedem erlaubt, aber root wird per Mail darüber informiert # fingerd: ALL: (finger @%h | mail -s "finger from %h" root) |
In hosts.deny kann der Zugang zu bestimmten Diensten des Rechners für bestimmte Hosts/Netzwerke explizit untersagt werden.
| user@sonne> cat /etc/hosts.deny # Aufbau von /etc/hosts.deny analog zu /etc/hosts.deny # ALL: outside.all # Die remote-Shell ist eine bekannte Sicherheitslücke # rsh: ALL |
hosts.allow und hosts.deny werden u.a. vom TCP-Wrapper ausgewertet. Dabei wird zuerst die hosts.allow und dann die hosts.deny betrachtet. Es gilt: Wurde etwas in der "hosts.allow" explizit gestattet, darf es in "hosts.deny" nicht mehr verboten werden.. Wenn ein entsprechender Eintrag in "hosts.deny" dennoch steht, wird er ignoriert.
Der Vollständigkeit halber soll auch der Aufbau der Datei hosts.equiv erwähnt werden. Alle von den darin aufgeführten Rechnern zugreifenden Benutzer haben dieselben Rechte wie lokale Nutzer ("trusted hosts") und können ohne explizite Angabe eines Passwortes über entfernte Dienste auf den Rechner zugreifen. Voraussetzung ist - neben einem entsprechenden Eintrag - die Existenz derselben Nutzerkennung auf dem Zielrechner.
Aus Sicherheitsgründen sollte auf die Möglichkeiten dieser Konfiguration verzichtet werden.
| user@sonne> cat /etc/hosts.allow # Aufbau einer /etc/hosts.equiv # [+|-] <Rechnername> [<username>] # # Die Nutzer "user" und "newbie" haben von Rechner "erde" aus Zugang erde.galaxis.de user erde.galaxis.de newbie # alle Nutzer des Rechners tuxhausen tuxhausen.outside.all # Mitglieder dieser Netzgruppe sind vom passwortfreien Zugang ausgeschlossen tuxhausen.outside.all -@LocalAdmins |
Anmerkungen:
- Ein einzelnes + erlaubt den Zugang von sämtlichen Rechnern aus
- Wird ein Rechner oder Nutzer vom Zugang ausgeschlossen (führendes -), so heißt das nur, dass ein Anmelden immer die Angabe des Passwortes erfordert
- Root wird niemals der passwortfreie Zugang gestattet
| Die Datei /etc/hosts.lpd |
|
| Die Datei /etc/inetd.conf |
|
| Die Datei /etc/lmhosts |
|
| Die Datei /etc/named.conf |
|
| Die Datei /etc/netgroup |
|
Bei der Konfiguration der Zugriffsberechtigungen für die Dienste rlogin (Remote Login), rsh (Remote Shell) und dem Export von Verzeichnissen (NFS) möchte man den Zugang häufig ein und derselben Gruppe von Rechern/Nutzern gestatten. Anstatt z.B. jedes zu exportierende NFS-Verzeichnis mit der vollständigen Liste der (nicht) berechtigten Rechner/Nutzer zu versehen, kann durch Definition von Netzgruppen der Schreibaufwand erheblich reduziert werden.
| <Name der Netzgruppe> (<Rechnername>,<Benutzername>,<Domänname>) |
Jede Netzgruppe wird auf einer eigenen Zeile beschrieben. Dabei folgt dem Namen der Netzgruppe eine Liste von (Rechner,Nutzer,Domän)-Einträgen oder der Name einer zugehörigen Netzgruppe. Eine fehlende Angabe steht für "alle", ein Minus (-) bedeutet "kein gültiger Wert". Das Domän-Feld beschreibt nicht die vertrauenswürdigen Rechner, sondern nur den Geltungsbereich der Netzgruppe. Dieses Feld kann entweder leer sein oder es muss den Namen der lokalen Domän enthalten.
| user@sonne> cat /etc/netgroup # /etc/netgroup # LocalAdmins (,root,) NetAdmins (sonne,user1,) (sonne,user2,) LocalAdmins Gateways (rechner1,,) (rechner7,,) |
| Die Datei /etc/networks |
|
Netzwerknamen werden hier in Netzwerkadressen umgesetzt. Diese Informationen dienen manchen Programmen, um anstelle von Nummern aussagekräftige Namen anzuzeigen. Notwendig sind die Angaben jedoch nicht.
| user@sonne> cat /etc/hosts.allow # Aufbau einer /etc/networks # <Netzwerkname> <Netzwerkadresse> # loopback 127.0.0.0 localnet 192.168.10.0 edu-net 192.168.85.0 |
| Die Datei /etc/nntpserver |
|
Diese Datei enthält eine einzige Zeile mit dem Namen eines Newsservers. Einige Newsclients (tin, leafnode) kontaktieren bei Aufruf den eingetragenen Server. Hat man einen lokalen Newsserver konfiguriert, steht hier einfach "localhost":
| user@sonne> cat /etc/nntpserver # bei lokalem Newsserver... # localhost |
Andere Newsserver oder -clients erwarten den Namen des Servers in der Shellvariablen NNTPSERVER. Nahezu jede Distribution belegt diese Variable anhand der Datei /etc/nntpserver.
| Die Datei /etc/nsswitch.conf |
|
| Die Datei /etc/protocols |
|
Die Protokollnummern der Transportprotokolle sind hier so eingetragen, wie sie im IP-Protokollkopf erscheinen. Diese Datei sollte nach der Installation existieren und muss nicht verändert werden.
| # protocols This file describes the various protocols that are # available from the TCP/IP subsystem. It should be # consulted instead of using the numbers in the ARPA # include files, or, worse, just guessing them. # ip 0 IP # internet protocol,pseudo protocol number 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 # WhatsThis? raw 255 RAW # RAW IP interface ... |
| Die Datei /etc/resolv.conf |
|
| search galaxis.de subdomain.galaxis.de nameserver 127.0.0.1 nameserver 192.168.100.3 |
| Die Datei /etc/services |
|
Da mehrere Dienste (»Services«) gleichzeitig auf einem Rechner aktiv sein können, muss ihre Adressierung differenzierter erfolgen, als es allein durch die Rechneradresse möglich wäre. Hier gelangen die Portnummern ins Spiel. Nun gibt es reichlich »Standarddienste«, deren Portnummern fest vorgeschrieben sind (Wie sollte sonst ein Client in Erfahrung bringen, an welchem Port der Webserver auf www.linuxfibel.de wartet?). Genau jene Nummern sind in der Datei /etc/services ausgeführt.
Die Vergabe der Portnummern (und auch der Domainnamen) obliegt der ICANN (Internet Corporation for Assigned Names and Numbers), einer nicht-profit-orientierten Vereinigung, der die Organisation der Namensvergabe im Internet obliegt. Die Portnummern sind in drei Bereiche unterteilt:
- Well Known Ports (0..1023) Sie werden vom ICANN zugewiesen und sollten niemals geändert werden.
- Registered Ports (1024..49151) Sie werden vom ICANN registriert und dienen zumeist »großen« Firmen dazu, um ihren Client-Server-Anwendungen konkrete Ports zu reservieren. Ihre Verwendung zu eigenen Zwecken sollte keine negativen Konsequenzen haben.
- Private Ports (49152..65536) Stehen zur freien Verfügung...
Kurzum: Die /etc/services sollte nur derjenige modifizieren, der eigene Client-Server-Anwendungen entwickelt oder auf solche zugreift.
|
# 0/tcp Reserved # 0/udp Reserved tcpmux 1/tcp # TCP Port Service Multiplexer tcpmux 1/udp # TCP Port Service Multiplexer compressnet 2/tcp # Management Utility compressnet 2/udp # Management Utility compressnet 3/tcp # Compression Process compressnet 3/udp # Compression Process rje 5/tcp # Remote Job Entry rje 5/udp # Remote Job Entry ... |
| Die Datei /etc/xinetd.conf |
|
| Die Dateien /etc/yp.conf und /etc/ypserv.conf |
 |
| root@sonne> cat /etc/yp.conf ypserver sonne.galaxis.de ypserver erde.galaxis.de ypserver 192.168.100.107 |
Korrekturen, Hinweise?