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.
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 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 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.
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 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
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,,) |
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 |
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 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
... |
search galaxis.de subdomain.galaxis.de
nameserver 127.0.0.1
nameserver 192.168.100.3 |
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
... |
root@sonne> cat /etc/yp.conf
ypserver sonne.galaxis.de
ypserver erde.galaxis.de
ypserver 192.168.100.107 |
|