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

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 Befehl hostname 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 Befehl domainname, 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 Befehle ifconfig 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.5

Die 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.5

Ob 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 dns

In 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.ftpd

Interessant 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 in inetd.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.

Ebenfalls sollte man zum Einloggen auf Uni-Rechnern unbedingt ssh statt telnet verwenden, wo immer das möglich ist (vom RZ wird ssh unterstützt), um das Abhören von Passwörtern zu unterbinden.

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 mit netstat 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"

Anmerkung: auf meinem Rechner läuft ein Newsserver, der anstelle des RZ-Servers benutzt werden kann. Dazu gibt es separate Informationen.

Mail

Um Mail auf dem eigenen Rechner verschicken und empfangen zu können, brauchst Du einen Mail Transport Agent (MTA) wie "smail" oder "sendmail" und einen Mail User Agent wie "elm". Letzterer läuft aus der Installation und braucht meist nicht konfiguriert zu werden. Falls er definitiv vorhandene Mail nicht findet, stimmt die Environment-Variable MAIL nicht mit dem überein, wo der MTA die Mail ausliefert. Es ist darauf zu achten, daß der MUA korrekte Absenderzeilen erzeugt. Korrekt heißt in diesem Zusammenhang: der Rechnername muß stimmen und das richtige Domainsuffix 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_connect

Bitte 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 file

Auch 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.

Ein Nachteil von qmail gegenüber smail ist, daß es zum Funktionieren unbedingt einen laufenden Nameserver mit korrekten MX-Records braucht (das sollte aber durch die HaDiNet-Gruppe sichergestellt sein). Ein weiterer Nachteil ist, daß man es selber aus dem Source installieren muß. Source gibt es bei ftp://ftp.inka.de/pub/comp/Unix/mail/qmail.

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.

HaDiNet-Konfiguration für Unix

Inhalt

File config:

File directors:

File routers:

File transports:

File `config`:

File `directors`:

File `routers`:

File `transports`: