HaDiNet-Konfiguration für Unix
Obwohl sich die diversen Versionen und Installationen von Unix stark unterscheiden, läuft die Netzkonfiguration eigentlich immer nach dem gleichen Schema. Unterschiede liegen nur in der Ebene der Hardwaretreiber und darin, in welchen Dateien die entsprechenden Statements zu finden sind. Das sind allerdings recht viele und unter Umständen ist es umständlich, alle aufzufinden...Inhalt
- Hardwaretreiber
- Grundkonfiguration
- Nameservice und Verwandtschaft
- Services
- Abschluß und Überprüfung
- Anwendungen
Hardwaretreiber
Dafür lassen sich keine allgemeinen Aussagen machen. Hardwaretreiber werden normalerweise in den Kernel einkonfiguriert. Bei Maschinen mit standardmäßig vorhandener Netzhardware (z.B. Sun) sollte das kein Problem sein. Bei PCs muß man schon beim Kauf einer Netzkarte darauf achten, daß das eingesetzte Betriebssystem diese unterstützt. (Speziell für Linux: siehe auch Linux-Anleitung vom HaDiNet.) Wenn die Netzhardware erfolgreich eingebunden ist, sollte sie unter
einem Devicenamen wie "eth0" verfügbar sein. Beachte, daß nicht
alle Unix-Varianten Einträge in /dev
dafür haben bzw.
benötigen, mitunter (z.B. bei Linux) wird dieser Name nur intern
von den Konfigurationsprogrammen wie ifconfig
benutzt.
Grundkonfiguration
Beim Booten führt Unix typischerweise eine Reihe von Skripts aus, die allgemeine Systemparameter setzen, Daemons starten etc. Wo diese Dateien liegen, wie sie heißen und in welcher Reihenfolge sie gestartet werden, ist bei jeder Installation anders. Als gemeinsamer Nenner sind sie in/etc
zu finden. Prüfe, ob die
folgenden Dateien oder Verzeichnisse vorhanden sind:
/etc/init.d, /etc/rc.d, /etc/rc, /etc/bcheckrc, /etc/bootrc,
/etc/rc.local, /sbin/init.d
. Am besten sucht man die im folgenden
aufgeführten Befehle mit grep
darin. Die Befehle,
die darin ausgeführt werden, stehen praktisch immer in
/bin, /sbin
oder /etc
.
Hostname
Dieser wird normalerweise mit dem Befehlhostname
irgendwann
früh in der Bootsequenz gesetzt. Entweder steht der Name im Bootskript
oder wird aus einer Datei gelesen. An dieser Stelle ist der
zugewiesene Hostname einzutragen. Manche Systeme wollen diesen Namen
einschließlich des Domainnamens haben, andere nicht. Ausprobieren!
Beispiel: hostname hadig116.hadiko.uni-karlsruhe.de
Domainname
Der Befehldomainname
, der üblicherweise dem
hostname
folgt, setzt in der Regel nicht den
DNS-Domainnamen (bei uns hadiko.uni-karlsruhe.de
),
sondern den NIS-(YP-)Domainnamen! Damit ist dieser in der Regel leer
zu lassen. Wenn ein Befehl dnsdomainname
existiert,
sollte der DNS-Domainname mit diesem auf
hadiko.uni-karlsruhe.de
gesetzt werden.
IP-Adresse etc.
Irgendwo in den Bootskripts sollten sich die Befehleifconfig
und route
finden. Damit werden die Hardware-Interfaces
konfiguriert und dem Kernel die Routen (welche Adressen auf welchem
Interface liegen) beigebracht. Hiervon gibt es viele verschiedene
Varianten. Manchmal sind die Parameter als Variablen am Anfang des
Skripts einzutragen, mitunter müssen Kommentarzeichen entfernt werden
etc.
Egal wie die Skripts genau aussehen, letztlich sollten beim Booten folgende Befehle ausgeführt werden: (NEU ab 14.12.1998)
ifconfig eth0 172.20.40.256 netmask 255.255.224.0 route add -net 172.20.32.0 netmask 255.255.224.0 dev eth0 route add default gw 172.20.63.254(wobei die erste IP-Adresse durch die eigene IP-Adresse zu ersetzen ist). Alles, was auf SLIP oder PPP hinweist, entfernen.
Zusätzlich sollte das Loopback-Device auf die Adresse
127.0.0.1
konfiguriert werden. Das ist hoffentlich in jeder
Installation standardmäßig vorhanden. Wenn nicht: ifconfig lo 127.0.0.1 route add -net 127.0.0.0(manchmal heißt es auch
lo0
statt lo
).
Nameservice und Verwandtschaft
Die Zuordnung zwischen Rechnernamen und IP-Adressen geschieht durch eine Datei/etc/hosts
, und für Namen oder Adressen, die da
nicht drinstehen, durch einen Nameserver. Mehrere
Konfigurationsdateien in /etc
sagen den Anwendungsprogrammen,
wie das zu geschehen hat.
/etc/hosts
Hier reichen normalerweise zwei Einträge der folgenden Form: 127.0.0.1 localhost localhost.hadiko.uni-karlsruhe.de 172.20.40.256 hadig116 hadig116.hadiko.uni-karlsruhe.de(Die zweite Zeile enthält wiederum den eigenen Namen, der sich aus der Zimmernummer ableitet, und die eigene Adresse, die vom Netzmanagement mitgeteilt wird.) Die Angabe der Namen sowohl mit als auch ohne Domain hat den Zweck, in weiteren Konfigurationsdateien evtl. Tipparbeit zu sparen und Nameserveranfragen auf ungültige (weil undomainisierte) Adressen zu vermeiden. Häufig gebrauchte Adressen können hier zwar auch eingetragen werden, dann müssen diese aber später u.U. aktualisiert werden.
Die spezielle Adresse 127.0.0.1
mit dem Namen "localhost"
dient auf jedem Rechner dazu, den eigenen Rechner selber anzusprechen.
/etc/resolv.conf
Adressen, die nicht im /etc/hosts
stehen, werden durch den
Nameserver ermittelt. Dessen IP-Adresse wird meistens in eine Datei
/etc/resolv.conf
eingetragen. Diese sollte so aussehen:domain hadiko.uni-karlsruhe.de nameserver 172.20.32.1 nameserver 129.13.64.5Die erste der beiden Nameserver-Adressen ist der HaDiKo-Server. Für den Fall, daß dieser ausfällt, ist als zweite Adresse der Hauptnameserver der Uni angegeben. (Wenn der auch ausfällt, geht sowieso nichts mehr.)
Wenn die Systemlibraries das Statement "search" unterstützen, kann man auch folgendes in
/etc/resolv.conf
schreiben:search hadiko.uni-karlsruhe.de rz.uni-karlsruhe.de ira.uka.de nameserver 172.20.32.1 nameserver 129.13.64.5Ob das funktioniert, ausprobieren oder in den Manpages resolv(3) und resolv(5) nachsehen. Damit wird jeder Rechnername, den Du irgendwo als Parameter angibst, in den eingetragenen Domains gesucht. Das kann enorm Tipparbeit sparen, kostet dann aber mehr Zeit beim Lookup.
/etc/nsswitch.conf
Bei manchen Systemen (Solaris, Linux mit libc5 oder libc6) muß in der Datei
/etc/nsswitch.conf
festgelegt werden, daß der Nameserver
benutzt werden soll. Dazu muß die Zeile, die mit hosts
beginnt, so aussehen:hosts: files dnsIn dieser Datei alle Verweise auf "nis" oder "nisplus" u.ä. entfernen.
Services
Ein Unix-Rechner am Netz bietet standardmäßig eine Reihe von Diensten im Netz an. Leider sind die meisten Installationen nach dem Prinzip "was geht" statt nach dem Prinzip "was ist sinnvoll und wird gebraucht" konfiguriert. Es ist daher unbedingt notwendig, zu überprüfen, welche Dienste auf dem eigenen Rechner laufen und ob sie korrekt aufgesetzt sind. Ansonsten läufst Du Gefahr, daß jeder im ganzen Uninetz auf Deinen Rechner und dessen Daten zugreifen kann...Der wohl grundlegendste und bekannteste Dienst ist telnet, der es erlaubt, sich von überall her auf dem Rechner einzuloggen. Aus dessen Existenz folgt unmittelbar: auf einem Rechner, der am Netz hängt, darf es keine Accounts ohne Passwort geben! Auch wenn es umständlich erscheint, sich auf seinem eigenen Rechner immer erst einloggen zu müssen, es ist unbedingt notwendig. Es sei denn, man sperrt telnet, ftp und alles andere, was Einloggen oder Zugriff auf Daten ermöglicht.
/etc/inetd.conf
Die meisten Netzdienste werden in der Datei /etc/inetd.conf
eingetragen.
Eine Zeile darin beginnt mit dem Namen des Dienstes, es
folgen drei Parameter, die dem inetd
-Prozess sagen, wie er
den Dienst zu handhaben hat, dann der Username, unter dem der Dienst
gestartet wird, anschließend der Name des Programms, das den Dienst
bereitstellt und etwaige Parameter. Ein Beispiel:ftp stream tcp nowait root /usr/sbin/tcpd in.ftpdInteressant sind eigentlich nur die erste und letzte Spalte: für "ftp" ist "in.ftpd" zuständig.
tcpd
überprüft, von welcher Netzadresse der Zugriff kommt, und
kann ihn davon abhängig ablehnen. Nähere Informationen
liefert die Manpage hosts_access(5)
. Es muß jedoch
dringend davor gewarnt werden, sich auf diesen Mechanismus zu
verlassen! Unsere Netzstruktur bietet keinen ausreichenden Schutz
gegen falsche IP-Adressen.
Das Grundprinzip bei der Konfiguration von Netzdiensten ist: nur das aktivieren, was man kennt und braucht. I.e. wer keine X-Terminals vom eigenen Rechner aus booten will, braucht kein tftp, wer keinen Newsserver am Laufen hat, braucht kein nntp, und so weiter. Solange man kein richtig konfiguriertes Mailsystem hat (siehe unten), sollte man auch kein smtp eintragen. Alles, was man nicht kennt oder nicht braucht, sollte man mit einem "#" am Zeilenanfang ungültig machen. Auf jeden Fall gebraucht wird "ident". Obwohl es auf Single-User-Systemen sinnlos ist, bestehen viele Server auf seinem Vorhandensein. Nach Möglichkeit nicht verwenden sollte man folgende Dienste: login (rlogind), shell (rshd), exec (rexecd) und rexec (rexd). Diese sind unsicher und es gibt ssh als bessere Alternative.
Nach jeder Änderung an inetd.conf
muß dem
Prozeß inetd
ein Signal 1 geschickt werden
(kill -1
).
Sonstige Daemons
Eine Reihe von Diensten wird nicht ininetd.conf
eingetragen,
sondern von einem eigenen Daemon-Prozess bedient, der immer läuft.
Das betrifft insbesondere NFS und ssh.
NFS (Network File System) erlaubt es anderen Rechnern, eine Platte
über das Netz zu "mounten" und wie eine eigene Platte anzusprechen.
Das kann sehr praktisch sein, der Einsatz sollte aber extrem gut
überlegt werden. Die Berechtigung für andere Rechner, die eigenen
Platten anzusprechen, wird in der Datei /etc/exports
anhand
von deren IP-Adressen festgelegt. Das bedeutet, daß dieses System
nicht sicher gegen falsche Adressen ist und unter bestimmten Umständen
ein unberechtigter Zugriff relativ einfach ist. Ich empfehle daher,
auf NFS zu verzichten. NFS besteht aus zwei Daemonen: mountd
und nfsd
, manchmal auch rpc.mountd
und
rpc.nfsd
genannt. Diese werden in irgendeinem Bootskript
gestartet (Auffinden siehe oben). Wer kein NFS verwendet, sollte die
entsprechenden Statements unbedingt mit Kommentarzeichen ungültig
machen. (Gilt für alle Daemons, die man nicht braucht.)
Im Gegensatz dazu ist ssh unbedingt zu empfehlen. Das ersetzt rlogin und ähnliches zum Einloggen und Datentransfer. Dabei werden aber sämtliche Daten verschlüsselt übertragen und ein Abhören des Netzes liefert keine brauchbare Information, außerdem erfolgt die Authentifizierung (Prüfung der Zugangsberechtigung) ebenfalls mit sicheren kryptographischen Mitteln. ssh ist in den meisten älteren Unix-Installation nicht enthalten und muß daher oft selbst compiliert werden. Neuere Pakete wie die diversen Linux-Distributionen enthalten ssh mitunter in einem speziellen Verzeichnis, da es aufgrund sinnloser Gesetze in den USA nicht frei vertrieben werden darf.
Wer schreibt was über Samba etc.? Damit kenne ich mich nicht aus.
Abschluß und Überprüfung
Nachdem alles konfiguriert ist, empfiehlt es sich, die Maschine neu zu booten, um zu sehen, ob die Bootskripts etc. laufen. Dann kann man mitnetstat
nachsehen, ob alles so initialisiert ist, wie man es
haben will:
netstat -i
zeigt die aktiven Netzinterfaces an, hier sollte
eth0
oder wie immer die Netzkarte heißt, zu finden sein;
netstat -r
zeigt die Routen;
netstat -atu
listet alle aktiven Verbindungen und Dienste.
Nachprüfen, ob wirklich nur diejenigen laufen, die man haben will.
Weiterhin prüft man Funktionsfähigkeit von Netz und
Nameserver mit ping 172.20.32.1
. Das testet, ob der
Nameserver (der immer läft) erreichbar ist. Ein ping
nce1
fragt den Nameserver auf seinen eigenen Namen ab und prüft
damit die Funktion des Nameservice. Wenn alles geht, probiere man
ssh rzstud1.rz.uni-karlsruhe.de.
Anwendungen
Für viele Anwendungen reicht eine Konfiguration durch Environment-Variablen, die je nach Shell in verschiedenen Initialisierungsdateien gesetzt werden.- News
NNTPSERVER=news.rz.uni-karlsruhe.de
(s.u.)- IRC
IRCSERVER=irc.rz.uni-karlsruhe.de
- WWW
http_proxy="http://proxy.hadiko.de:3128/"
ftp_proxy="http://proxy.hadiko.de:3128/"
gopher_proxy="http://proxy.hadiko.de:3128/"
no_proxy="uni-karlsruhe.de,uka.de,hadiko.de"
hadiko.uni-karlsruhe.de
oder
hadiko.de
haben. Natürlich muß auch der
Username stimmen.
Der MTA dagegen muß sorgfältig (und leider ziemlich umständlich) konfiguriert werden. Testen nicht vergessen und die erzeugten Headerzeilen auf Inkonsistenzen prüfen! Auch zu beachten: laut Internet-Standard muß die Adresse "postmaster" auf jedem Rechner existieren (kann natürlich auch ein Alias auf den normalen Usernamen sein).
Die Wahl zwischen sendmail und anderen MTAs gilt von der Konfiguration her heutzutage als Geschmackssache, man sollte aber auf jeden Fall darauf achten, die neuesten Versionen zu benutzen. sendmail ist mittlerweile auf Version 8.9.1; sämtliche älteren Versionen von sendmail enthalten so kritische Fehler, die die Sicherheit des eigenen Rechners bedrohen, daß man von ihrem Einsatz nur abraten kann. Und niemand weiß, wann der nächste gefunden wird. Ich empfehle aus diesem Grund, sendmail nicht zu verwenden. Für Neuinstallationen ist entweder exim oder das einfachere, aber konzeptuell andere qmail zu empfehlen. Wer bereits smail kennt, sollte sich einen Umstieg auf exim überlegen, dieser ist smail sehr ähnlich, aber moderner.
smail
smail hat ein Konfigurationsverzeichnis (traditionell oft/usr/lib/smail
, bei neuen Systemen
/etc/smail
), in dem sich mehrere Dateien befinden.
Notwendig sind auf jeden Fall die folgenden: config, directors,
routers, transports
. Die Files haben ein für Menschen
leicht lesbares Format, sind aber anfällig gegen Syntaxfehler:
insbesondere ist der Unterschied zwischen Komma und Semikolon vital.
File config
:
Diese Datei enthält allgemeine Parameter. Der eigene Name in der
ersten Zeile ist das einzige in der ganzen smail-Konfiguration, was
unbedingt angepaßt werden muß. Der Parameter auf der
rechten Seite von "nobody=" sollte ein Accountname mit
geringstmöglichen Privilegien sein (meist "nobody").
hostname=g116.hadiko.de more_hostnames=hadig116.hadiko.uni-karlsruhe.de domains=hadiko.uni-karlsruhe.de:hadiko.de smart_path=mailhost.hadiko.de smart_transport=smtp +error_copy_postmaster postmaster=root nobody=nobody smtp_accept_max=3 -smtp_debug
File directors
:
Hier wird festgelegt, wie Mail auf dem eigenen Rechner ausgeliefert
oder weitergeleitet werden soll. Die folgenden Definitionen stellen
folgende Standard-Features bereit: systemweite Aliasliste in
/etc/aliases, userspezifische Forwards in ~/.forward und die normale
Auslieferung an einen auf der Maschine existierenden Usernamen.
aliasinclude: driver=aliasinclude, nobody; copysecure, copyowners forwardinclude: driver=forwardinclude, nobody; copysecure, copyowners aliases: driver=aliasfile, -nobody, sender_okay, owner=postmaster; file=/etc/aliases, modemask=002, proto=lsearch dotforward: driver=forwardfile, owner=postmaster, nobody, sender_okay; file=~/.forward, checkowner, owners=root, modemask=002, caution=root, unsecure="/tmp:/usr/tmp:/var/tmp" user: driver=user; transport=local real_user: driver=user; transport=local, prefix="real-"
File routers
:
Hier wird bestimmt, wie ausgehende Mail verarbeitet werden soll. In
unserem Fall wird einfach alles an den HaDiKo-Mailserver geschickt.
Als Sonderfall ist die Adressierung "user@[ip-nummer]" möglich.
Ein Eintrag mit "gethostbyname"- oder "bind"-Treiber wie in den
Beispielkonfigurationen sollte hier nicht vorhanden sein!
match-inet-addrs: driver=gethostbyaddr, tramsport=smtp; fail_if_error, check_for_local smart_host: driver=smarthost; -path
File transports
:
Dieses File schreibt vor, wie Mail an ihr Ziel ausgeliefert wird. In
diesem Fall gibt es prinzipiell drei Möglichkeiten: in ein File
schreiben, an ein Programm übergeben oder per SMTP an einen anderen
Rechner schicken. Die Beispiele im smail-Source enthalten eine Reihe
Spezialfälle für UUCP-Systeme, die hier nicht interessieren.
"local", "pipe" und "file" müssen vorhanden sein.
local: driver=appendfile, return_path, local, from, unix_from_hack; file="/var/spool/mail/${lc:user}", group=mail, mode=0660, suffix="\n", append_as_user, check_user, notify_comsat pipe: driver=pipe, return_path, local, from, unix_from_hack; cmd="/bin/sh -c $user", parent_env, pipe_as_user, umask=0022, -log_output, ignore_status, ignore_write_errors file: driver=appendfile, return_path, local, from, unix_from_hack; file=$user, expand_user, mode=0660, suffix="\n", append_as_user smtp: driver=smtp, max_addrs=100, -max_chars; defnames, defer_no_connectBitte bei mir melden, wenn jemand diese Konfiguration verwendet und sie nicht funktioniert!
sendmail
Wer sich auskennt, kann es selber konfigurieren, ansonsten sendmail.cf vom HaDiKo-Server benutzen.exim
Die Konfiguration von exim sieht smail sehr ähnlich, befindet sich aber nur in einer einzigen Datei (z.B./etc/exim.conf
).
Ein Beispiel:
# Exim configuration G116=g116:g116.hadiko.de:hadig116:hadig116.hadiko.uni-karlsruhe.de primary_hostname = g116.hadiko.de local_domains = G116 local_domains_include_host = true local_domains_include_host_literals = true never_users = root trusted_users = root:mail:uucp gecos_pattern = ^([^,:]*) gecos_name = $1 accept_8bitmime remote_max_parallel = 5 rfc1413_query_timeout = 0s strip_excess_angle_brackets message_size_limit = 0 delay_warning = 0s relay_domains = G116:localhost sender_host_accept_relay = G116:localhost deliver_load_max=3.0 queue_only_load=2.0 queue_run_max=2 check_spool_space=10M check_spool_inodes=1000 received_header_text = "Received: \ ${if def:sender_host_name \ {from \ ${if def:sender_helo_name \ {${sender_helo_name} (\ ${if def:sender_ident {${sender_ident}@}{}}\ ${sender_host_name} \ ${if def:sender_host_address {[${sender_host_address}]}{}}\ )\n\t}\ {${sender_host_name} \ ${if def:sender_host_address \ {(${if def:sender_ident {${sender_ident}@}{}}\ [${sender_host_address}])}{}}\n\t}}}\ {${if def:sender_helo_name \ {from ${sender_helo_name} (\ ${if def:sender_ident {${sender_ident}@}{}}\ ${if def:sender_host_address {[${sender_host_address}]}{}}\ )\n\t}\ {${if def:sender_host_address \ {from UNRESOLVED_HOSTNAME (\ ${if def:sender_ident {${sender_ident}@}{}}\ [${sender_host_address}])\n\t}\ {${if def:sender_ident \ {from localhost (${sender_ident}@[127.0.0.1])\n\t}\ {}}}}}}}}\ by ${primary_hostname} \ ${if def:received_protocol {with ${received_protocol}}} \n\t\ id ${message_id}" end # TRANSPORTS local_delivery: driver = appendfile; group = mail mode = 0660 file = /var/spool/mail/${local_part} address_pipe: driver = pipe address_file: driver = appendfile address_reply: driver = autoreply remote_smtp: driver = smtp end # DIRECTORS system_aliases: driver = aliasfile; file = /etc/aliases, search_type = lsearch user = nobody userforward: no_verify, driver = forwardfile; file = .forward, modemask = 002, filter localuser: driver = localuser, transport = local_delivery; end # ROUTERS ipliteral: driver = ipliteral, transport = remote_smtp; smtproutes: driver = domainlist, transport = remote_smtp; route_list = "* mailhost.hadiko.de byname" end # RETRY * * F,7d,15m end # REWRITE # (empty) # End of Exim configuration fileAuch hier gilt: bitte meldet mir Fehler.
qmail
qmail ist ein neuer MTA, der eine hochinteressante Alternative zu sendmail oder smail ist. Wer bisher noch nichts mit MTAs zu tun hatte, sollte ihn auf jeden Fall ausprobieren (für smail-Kenner wirkt qmail etwas ungewöhnlich). Vor allem in einem reinen SMTP-Netz, wie es hier vorliegt, ist qmail deutlich einfacher zu konfigurieren als die Vorgenannten.qmail hat mehrere Konfigurationsdateien in
/var/qmail/control
, die meistens nur aus ein oder zwei
Zeilen bestehen. Als Minimalkonfiguration reichen schon drei:
- me
- Hier steht der eigene Hostname, also z.B.
g116.hadiko.de
- locals
- Alle Namen, unter denen dieser Rechner sonst noch
erreichbar sein soll, also z.B.:
g116 hadig116 hadig116.hadiko.uni-karlsruhe.de
- smtppaths
- Was wohin geschickt werden soll. Vor dem Doppelpunkt
Ziel, danach Relayhost:
.hadiko.de: .hadiko.uni-karlsruhe.de: hadiko.de: hadiko.uni-karlsruhe.de: :mailhost.hadiko.uni-karlsruhe.de
Die ersten vier Zeilen sagen: alles innerhalb der HaDiKo-Domain direkt ans Ziel zustellen (Relayhost ist leer, die ersten beiden sind Domain-Wildcard). Die letzte Zeile sagt: alles andere (Zielhost leer = Wildcard) über das angegebene Relay leiten.
FTP- oder WWW-Server
FTP- und WWW-Server sind mit Unix verführerisch leicht aufzusetzen, manche Installationen kommen mit vorkonfigurierter Software dafür. Wegen der erheblichen Sicherheitsprobleme sollte man diese Installationen aber auf keinen Fall unbesehen benutzen. Für FTP-Server gibt es ein ausführliches FAQ (ftp.uni-stuttgart.de:/pub/doc/faq/comp/security.unix
,
Achtung der Pfad ändert sich manchmal), für WWW-Server lies
die Dokumentation des Servers.