Problemsuche und -behebung

Transkript

1 487 B Problemsuche und -behebung Dieses Kapitel enthält Tipps für verschiedenste Probleme, die beim Betrieb von Postfix auftauchen können, u.a. syslogd, Konfigurationsprobleme, Seltsamkeiten im Netz und generelle Probleme des Betriebssystems. Wie bei jeder Fehlersuche gilt auch bei Postfix: Sie sollten grob wissen, wo das Problem ist, bevor Sie versuchen, es zu beheben. Das gilt ganz besonders für Postfix, das aus mehreren Subsystemen besteht. B.1 Betrieb Wenn Postfix nicht läuft, dann wird auch keine Mail versendet. Sie können zwar, ohne dass Postfix gestartet ist, mit dem sendmail-kommando in die Mail- Queue stellen lassen, aber der Transport passiert erst, wenn das ganze Postfix-System in Betrieb ist. Die einfachste Methode herauszufinden, ob Postfix läuft, ist es zu starten: # postfix start postfix/postfix-script: starting the Postfix mail system Wenn Sie diese Ausgabe sehen, war Postfix außer Betrieb. Im Log manifestiert sich ein Start von Postfix in etwa so: May 14 14:44:43 mail postfix/postfix-script: starting the Postfix mail system May 14 14:44:43 mail postfix/master[21852]: daemon started -- version 2.2.3, configuration /etc/postfix Wir sehen hier nicht nur, welche Postfix-Version gestartet wurde, sondern auch welches Konfigurationsverzeichnis verwendet wurde. Wenn die Ausgabe folgendermaßen aussieht, dann lief Postfix bereits: # postfix start postfix/postfix-script: fatal: the Postfix mail system is already running B.1.1 Logging geht nicht Wenn Sie im Log gar nichts sehen, sollten Sie schleunigst die Konfiguration Ihres syslog-daemons prüfen. Sie brauchen alle Logs der mail-facility (mail.*); vollständige Logs sind für die Fehlersuche unerlässlich!

2 488 B Problemsuche und -behebung Wir empfehlen alle Meldungen der Facility mail (oder welche Facility Postfix benutzt, standardmäßig syslog_facility = mail) in ein Log schreiben zu lassen. Einige Distributionen (z.b. Debian GNU/Linux) spalten das Log in mehrere Log-Dateien auf, was die Fehlersuche wirklich lästig macht. Um alle Log-Einträge in einer Datei zu haben, sollte die /etc/syslog.conf folgende Zeile enthalten: # Alles von Facility mail in eine Datei! mail.* -/var/log/maillog Vergessen Sie nach Änderungen der /etc/syslog.conf nicht, syslogd neu zu starten! Wenn Sie nun die Meldungen über einen erfolgreichen Start im Log und auf der Konsole sehen, könnte Postfix in einigen esoterischen Fällen unmittelbar nach dem Start dahingeschieden sein was auf ein wirklich ernsthaftes Problem Ihrer Maschine hinweist. Mit ps und grep sollten Sie daher prüfen, ob die einzelnen Dämonen tatsächlich laufen: $ ps aux grep postfix root ? Ss 14:45 0:00 /usr/lib/postfix/master postfix ? S 14:45 0:00 pickup -l -t fifo -u -c postfix ? S 14:45 0:00 qmgr -l -t fifo -u -c Anhand dieser Ausgabe können Sie sehen, dass Postfix' master-daemon als root läuft; der Queue-Manager qmgr- und pickup-daemon laufen beide als Benutzer postfix Postfix läuft also. B.1.2 qmgr-logs Ein sehr weit verbreitetes Problem ist das Fehlen von Log-Einträgen des qmgr-daemon. Normalerweise generiert der Queue-Manager Log-Einträge in folgender Form: Aug 5 17:05:26 hostname postfix/qmgr[308]: A44F828C71: \ from=<bamm@example.com>, size=153136, nrcpt=1 (queue active) Wenn diese fehlen, kann dies zwei verschiedene Gründe haben: libc-probleme Die libc-implementierung ist fehlerhaft. Der syslog-client verbindet sich in diesem Fall nicht erneut mit dem syslog-server, wenn der Server neugestartet wird. Wenn das der Fall ist, müssen Sie die libc reparieren. qmgr läuft im chroot Der qmgr läuft im chroot (sehen Sie in die master.cf), aber es gibt keinen syslog-socket innerhalb des chroot-verzeichnisses. In dem Manual von syslog (8) steht, wie Sie zusätzliche Sockets konfigurieren können unter Linux ist das z.b. mit /sbin/syslogd -a /var/spool/postfix/dev/log der Fall.

3 B.1 Betrieb 489 B.1.3 Detaillierteres Logging Wenn Ihnen das Log nicht detailliert genug ist, können Sie für jeden einzelnen Daemon das Logging verfeinern. Dies geschiegt durch Anfügen des Parameters -v an den jeweiligen Eintrag in master.cf. Den smtpd-daemon machen Sie beispielsweise so gesprächiger: # ========================================================================== # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (50) # ========================================================================== smtp inet n smtpd -v Anschließend ist wieder ein postfix reload nötig. Das Logging der betroffenen Dämonen ist jetzt wesentlich detaillierter. Durch Anfügen weiterer -v-parameter kann dies noch gesteigert werden. Vergessen Sie aber nicht, dies wieder für den Normalbetrieb rückgängig zu machen, denn die raue Menge an Log-Information, die auf Platte geschrieben werden muss, senkt natürlich die Performance. Detaillierteres Logging für ausgewählte Clients Wenn Sie einen sehr aktiven Mailserver haben ist das globale Anheben des Log-Level sei es auch nur für einige wenige Dämonen fatal für die Performance. Postfix bietet eine selektive Anhebung des Log-Levels des smtpd-loggings für einzelne Clients oder ganze Netze über den debug_peer_list-parameter. Im folgenden Beispiel wird das smtpd-logging für die Clients und angehoben: debug_peer_list = , Sie können einen oder mehrere Hostnamen, Domains, IP-Adressen und Netzwerke als Wert für diesen Parameter angeben. Zum Aktivieren auch hier postfix reload nicht vergessen. B.1.4 Zu viele Verbindungen Wenn Sie Ihren Mailserver aufsetzen, sollten Sie immer nur ein Problem gleichzeitig angehen und lösen. Dies ist insbesondere wichtig, wenn Sie LDAP oder SQL benutzen wollen. Gehen Sie wenn möglich immer so vor: 1. Bauen Sie Ihr System ohne LDAP-Maps auf (benutzen Sie hash-, btree- oder dbm- Maps). 2. Benutzen Sie die richtigen ldapsearch-aufrufe, um die notwendigen Daten aus Ihrem LDAP-Server zu extrahieren. Mit einem Skript bringen Sie diese dann in die richtige Form für eine Postfix-Map.

4 490 B Problemsuche und -behebung 3. Wenn Ihr System dann auf dieser Datenbasis korrekt funktioniert, tauschen Sie systematisch eine Map nach der anderen durch eine direkte Abfrage des LDAP- Servers aus. Testen Sie jede LDAP-Map als User postfix, z.b. so: $ postmap -q - ldap:mapname < keyfile 4. Um zu verhindern, dass Ihr LDAP-Server unter der Last und Zahl paralleler Anfragen zusammenbricht, konsolidieren Sie die Anzahl der gleichzeitigen Anfragen, indem Sie diese gebündelt über den proxymap-daemon abwickeln lassen (siehe Kapitel 6). B.1.5 Probleme mit dem Dateisystem Die meisten modernen Unixe bieten Ihnen ein Journaling Filesystem; es schützt Sie aber nicht vor einer Korruption des Dateisystems durch Fehler im Kernel (z.b. weil Sie ein noch unausgereiftes Dateisystem nutzen) oder der Hardware. Wenn Sie also seltsame Dinge beobachten, wie z.b. die spontane Verwandlung von Dateien in Verzeichnisse oder umgekehrt, dann sollten Sie auf jeden Fall Ihr System neu starten und einen vollständigen Filesystemcheck erzwingen. Unter Red Hat und Debian geht dies wie folgt: # touch /forcefsck # sync # reboot B.2 Netzwerk Wenn Postfix sauber startet, aber dennoch nicht wie erwartet funktioniert, prüfen Sie mal, ob Verbindungen auf Port 25 angenommen werden: $ telnet localhost mail.example.com ESMTP Postfix QUIT 221 Bye Eine Verbindung auf localhost ist möglich. Das bedeutet aber nicht automatisch, dass Postfix auch auf allen Netzwerkinterfaces und IP-Adressen Ihres Servers horcht. Wenn die IP-Adresse Ihres Servers z.b ist, versuchen Sie, eine Verbindung dorthin aufzubauen: # telnet mail.example.com ESMTP Postfix QUIT 221 Bye Wenn das nicht funktioniert, sollten Sie in der main.cf nachsehen, ob der inet_interfaces-parameter modifiziert wurde denn standardmäßig horcht Postfix auf allen verfügbaren Interfaces.

5 B.2 Netzwerk 491 # postconf -d inet_interfaces inet_interfaces = all B.2.1 Blockt die Firewall? Wenn die Konfiguration so weit in Ordnung zu sein scheint und Postfix läuft, Sie aber trotzdem keine Verbindungen aufbauen können vielleicht haben Sie eine Firewall! Möglicherweise wird Port 25 durch den Internetprovider geblockt. Es gibt verschiedene Stellen, an denen man nachsehen muss, denn die Filterung von IP-Paketen kann durch eine Firewall auf dem Server selbst geschehen (z.b. durch ein Skript, das iptables oder ipf aufruft) oder außerhalb der Maschine durch Router, Firewall- Appliances. Man muss überall nachsehen. Wenn die lokale Konfiguration soweit korrekt aussieht, müssen Sie außerhalb Ihres Einflussbereiches suchen. So könnte z.b. Ihr Internetprovider Verkehr aus dem Internet zu Ihrer Maschine auf TCP-Port 25 blocken (oder auch ausgehenden Verkehr von Ihrer Maschine). Wenn das der Fall ist und Ihr ISP keine Ausnahme gewährt, so können Sie nur Ihren ISP wechseln. Um zu sehen, ob man Sie von außerhalb auf Port 25 erreichen kann, führen Sie auf Ihrem Server das folgende Kommando aus: $ telnet relay-test.mail-abuse.org Wenn Sie diese Verbindung aufbauen, führt relay-test.mail-abuse.org einen Live- Test auf Relaying der Maschine aus, die die Verbindung initiiert hat. Wenn Port 25 für eingehende Verbindungen frei ist, sollten Sie jede Menge Relay-Versuche in Ihrem Log sehen: May 14 16:51:48 mail postfix/smtpd[24469]: \ connect from Cygnus.Mail-Abuse.ORG[ ] May 14 16:51:49 mail postfix/smtpd[24469]: NOQUEUE: reject: RCPT from \ Cygnus.Mail-Abuse.ORG[ ]: 554 <nobody@mail-abuse.org>: \ Relay access denied; from=<spamtest@port dynamic.qsc.de> \ to=<nobody@mail-abuse.org> proto=smtp helo=<cygnus.mail-abuse.org> May 14 16:51:50 mail postfix/smtpd[24469]: NOQUEUE: reject: RCPT from \ Cygnus.Mail-Abuse.ORG[ ]: 554 <nobody@mail-abuse.org>: \ Relay access denied; from=<nobody@mail-abuse.org> to=<nobody@mail-abuse.org> \ proto=smtp helo=<cygnus.mail-abuse.org> May 14 16:51:50 mail postfix/smtpd[24469]: NOQUEUE: reject: RCPT from \ Cygnus.Mail-Abuse.ORG[ ]: 554 <nobody@mail-abuse.org>: \ Relay access denied; from=<spamtest@maps1.pa.vix.com> to=<nobody@mail-abuse.org> \ proto=smtp helo=<cygnus.mail-abuse.org> Wenn Sie obigen Test nicht durchführen können, haben Sie vielleicht Probleme mit der Namensauflösung. Testen Sie dies mit folgendem host-kommando: $ host relay-test.mail-abuse.org relay-test.mail-abuse.org CNAME cygnus.mail-abuse.org cygnus.mail-abuse.org A

6 492 B Problemsuche und -behebung Sie sollten in etwa die Ausgabe wie oben erhalten. Wenn nicht, hat Ihr Server Probleme mit der Namensauflösung. Ihre /etc/resolv.conf oder /etc/nsswitch.conf (oder gar beide) könnten fehlerhafte Einträge enthalten. Oder es ist noch schlimmer: Ihre Internetverbindung funktioniert nicht. Versuchen Sie also mal, eine Maschine im Internet mit einem ping zu erreichen. Ein erfolgreicher Test sieht so aus (mit STRG+C können Sie den Test abbrechen): $ ping PING ( ): 56 data bytes 64 bytes from : icmp_seq=0 ttl=54 time=12.1 ms 64 bytes from : icmp_seq=1 ttl=54 time=12.1 ms 64 bytes from : icmp_seq=2 ttl=54 time=12.1 ms ping statistics packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 12.1/12.1/12.1 ms B.2.2 Ist Postfix der Server? Wenn Postfix läuft und nichts Port 25 blockt, aber die Verbindungsversuche dennoch fehlschlagen, sollten Sie prüfen, ob Postfix überhaupt auf Port 25 lauscht: # netstat -t -a grep LISTEN tcp 0 0 *:printer *:* LISTEN tcp 0 0 localhost:domain *:* LISTEN tcp 0 0 *:ssh *:* LISTEN tcp 0 0 *:smtp *:* LISTEN Diese Ausgabe von netstat zeigt, dass es Dämonen gibt, die auf den printer, domain, SSH und SMTP-Ports lauschen (mit einem Blick in /etc/services finden Sie die Portnummern heraus). Die nächste Frage ist, was lauscht denn auf Port 25? Ist es Postfix oder irgendein anderes Programm? Mit lsof können Sie sich anzeigen lassen, welches Programm auf welchem Port lauscht: # lsof -i tcp:25 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME sendmail root 4u IPv TCP mail.example.com:smtp (LISTEN) Bingo! Hier läuft noch ein altes Sendmail auf Port 25. Töten Sie diesen Prozess und ändern Sie die INIT-Skripts dahingehend ab, dass Sendmail nicht wieder beim nächsten Reboot gestartet wird. Hinweis lsof ist ein wirklich mächtiges Werkzeug, das alle offenen Dateien (und die sie offen haltenden Prozesse) anzeigen kann. Allerdings ist es eng an den Kernel gebunden. Stellen Sie also sicher, dass lsof aktuell ist und auch mit Ihrem Kernel zurechtkommt. Ein altes lsof zeigt ggf. nicht alle verfügbare Information an. Wenn Postfix tatsächlich läuft, so sollte Postfix' master-daemon auf Port 25 lauschen:

7 B.3 Konfiguration 493 # lsof -i tcp:25 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME master root 11u IPv TCP *:smtp (LISTEN) B.3 Konfiguration Es gibt drei Fehler, die typischerweise auftreten: Falsche oder fehlerhafte Referenzen Wenn Postfix ein Problem beim Öffnen einer Datei oder Map hat, die Ihrer Meinung nach existiert, sollten Sie sicherheitshalber prüfen, wo und wie diese Datei in der main.cf referenziert wird und ob die Pfade und Dateiendungen auch wirklich stimmen. Oft handelt es sich dabei um einen Map-Typ, der vorher noch mit postmap aus einer Textdatei umgewandelt werden muss (hash, btree, dbm, cdb). Mangelhafte Zugriffsrechte Wenn Sie ein Rechteproblem haben, können Sie erstmal versuchen, das Problem von Postfix selbst beseitigen zu lassen. Vorher machen Sie sicherheitshalber ein Backup Ihrer Konfiguration und führen dann das folgende Kommando aus: # /etc/postfix/post-install set-permissions upgrade-configuration Dieser Befehl passt main.cf und master.cf an und repariert Rechte und Besitzer von Dateien und Verzeichnissen, die Postfix benutzt. Fehlerhafte Kommentare Jede Zeile, deren erstes Nicht-Leerzeichen ein Hash»#«ist, gilt als Kommentar. Postfix akzeptiert keine andere Syntax für Kommentare. Wenn postconf einen Parameter anzeigt, der Ihrer Meinung nach nicht konfiguriert ist oder anders konfiguriert sein sollte, dann haben Sie vielleicht einen Kommentar falsch gesetzt. B.3.1 Steht das wirklich in der Konfiguration? Die Datei main.cf ist lang und mit Kommentaren nur so gespickt, d.h., man kann leicht den Überblick verlieren und findet auch Tippfehler nicht so leicht. Wenn ein Parameter mehrfach darin vorkommt, wird nur die Einstellung der letzten Zeile aktiv. Mit postconf können Sie sich die Konfiguration anzeigen lassen, wie Postfix sie eingelesen hat (bzw. einlesen würde). Allein schon anhand der Anzahl der Zeilen lassen sich massive Unterschiede erkennen: # cd /etc/postfix # wc -l main.cf # postconf -n wc -l

8 494 B Problemsuche und -behebung Die Ausgabe von postconf -n listet alle explizit in main.cf gesetzten Werte auch jene, die Sie mit Standardwerten angeben. Nach Änderungen an main.cf sollten Sie immer mit postconf überprüfen, ob die Änderung auch korrekt erkannt wird. Hinweis postconf bietet mit der Option -e die Möglichkeit, Parameter zu ändern: postconf -e parameter=value. Dies erlaubt es Ihnen, aus Skripts oder cronjobs die Konfiguration dynamisch anzupassen. Wenn alle Stricke reißen, hilft vielleicht ein Blick ins Manual von postconf (5). B.3.2 Fehlende Bibliotheken Es gibt zahlreiche Gründe, warum Postfix nicht startet, aber der häufigste Grund ist eine fehlende Bibliothek (shared library). Um dieses Problem anzugehen, finden Sie zuerst heraus, in welchem Verzeichnis sich Postfix' Dämonen befinden: $ postconf daemon_directory daemon_directory = /usr/lib/postfix Dort finden Sie alle Dämonen versammelt: $ cd /usr/lib/postfix $ ls -l total 640 -rwxr-xr-x 1 root root 9844 May 4 22:45 anvil -rwxr-xr-x 1 root root May 4 22:45 bounce -rwxr-xr-x 1 root root May 4 22:45 cleanup -rwxr-xr-x 1 root root 4628 May 4 22:45 discard -rwxr-xr-x 1 root root 4628 May 4 22:45 error -rwxr-xr-x 1 root root May 4 22:45 flush -rwxr-xr-x 1 root root May 4 22:45 lmtp -rwxr-xr-x 1 root root May 4 22:45 local -rwxr-xr-x 1 root root May 4 22:45 master -rwxr-xr-x 1 root root May 4 22:45 oqmgr -rwxr-xr-x 1 root root 8660 May 4 22:45 pickup -rwxr-xr-x 1 root root May 4 22:45 pipe -rwxr-xr-x 1 root root 7844 May 4 22:45 proxymap -rwxr-xr-x 1 root root May 4 22:45 qmgr -rwxr-xr-x 1 root root May 4 22:45 qmqpd -rwxr-xr-x 1 root root 8272 May 4 22:45 scache -rwxr-xr-x 1 root root 8584 May 4 22:45 showq -rwxr-xr-x 1 root root May 4 22:45 smtp -rwxr-xr-x 1 root root May 4 22:45 smtpd -rwxr-xr-x 1 root root 6072 May 4 22:45 spawn -rwxr-xr-x 1 root root May 4 22:45 tlsmgr -rwxr-xr-x 1 root root May 4 22:45 trivial-rewrite -rwxr-xr-x 1 root root 8472 May 4 22:45 verify -rwxr-xr-x 1 root root May 4 22:45 virtual

9 B.3 Konfiguration 495 Postfix' Dämonen Sie kennen sie aus der Spalte command der /etc/postfix/ master.cf befinden sich in diesem Verzeichnis. Sie können nun die Abhängigkeit dieser Programme von shared libraries mit dem ldd-kommando bestimmen (das funktioniert auf Linux, Solaris und anderen Unix-Varianten; auf Mac OS X und HP-UX ist alles anders...): $ ldd smtpd libpostfix-master.so.1 => /usr/lib/libpostfix-master.so.1 (0xb7fb2000) libpostfix-tls.so.1 => /usr/lib/libpostfix-tls.so.1 (0xb7fa5000) libpostfix-dns.so.1 => /usr/lib/libpostfix-dns.so.1 (0xb7fa0000) libpostfix-global.so.1 => /usr/lib/libpostfix-global.so.1 (0xb7f78000) libpostfix-util.so.1 => /usr/lib/libpostfix-util.so.1 (0xb7f51000) libssl.so => /usr/lib/i686/cmov/libssl.so (0xb7f20000) libcrypto.so => /usr/lib/i686/cmov/libcrypto.so (0xb7e1e000) libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0xb7e08000) libdb-4.2.so => /usr/lib/libdb-4.2.so (0xb7d32000) libnsl.so.1 => /lib/tls/libnsl.so.1 (0xb7d1e000) libresolv.so.2 => /lib/tls/libresolv.so.2 (0xb7d0c000) libc.so.6 => /lib/tls/libc.so.6 (0xb7bd7000) libdl.so.2 => /lib/tls/libdl.so.2 (0xb7bd4000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7fce000) Die obige Ausgabe für den smtpd-daemon zeigt keinerlei Probleme, denn jede Abhängigkeit wird durch eine tatsächlich existente Datei erfüllt. Das ist leider nicht immer so und kann insbesondere passieren, wenn Sie ein Binärpaket installieren, welches nicht für Ihre Distribution gemacht wurde: $ ldd smtpd libpostfix-master.so.1 => /usr/lib/libpostfix-master.so.1 (0xb7ee2000) libpostfix-tls.so.1 => /usr/lib/libpostfix-tls.so.1 (0xb7ed5000) libpostfix-dns.so.1 => /usr/lib/libpostfix-dns.so.1 (0xb7ed0000) libpostfix-global.so.1 => /usr/lib/libpostfix-global.so.1 (0xb7ea8000) libpostfix-util.so.1 => /usr/lib/libpostfix-util.so.1 (0xb7e81000) libssl.so => /usr/lib/i686/cmov/libssl.so (0xb7e50000) libcrypto.so => /usr/lib/i686/cmov/libcrypto.so (0xb7d4e000) libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0xb7d38000) libdb-4.2.so => not found libnsl.so.1 => /lib/tls/libnsl.so.1 (0xb7d24000) libresolv.so.2 => /lib/tls/libresolv.so.2 (0xb7d12000) libc.so.6 => /lib/tls/libc.so.6 (0xb7bdd000) libdb-4.2.so => not found libdb-4.2.so => not found libdb-4.2.so => not found libdb-4.2.so => not found libdl.so.2 => /lib/tls/libdl.so.2 (0xb7bd9000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7efe000) libdb-4.2.so => not found In diesem Falle kann libdb-4.2.so (BerkeleyDB Version 4.2.x) nicht gefunden werden und ein Programm, das nicht alle seine benötigten Bibliotheken laden kann, wird nicht laufen.

10 496 B Problemsuche und -behebung Wenn dieses Problem wie zuvor beschrieben durch die Installation eines nicht geeigneten Binärpakets zustande gekommen ist, müssen Sie eine Entscheidung treffen: Entweder Sie finden ein Binärpaket, das wirklich für genau Ihre Distribution erstellt wurde, oder Sie bauen Postfix aus den Quellen (siehe Anhang A). Wenn Sie nun aber wirklich darauf bestehen, die aktuelle Installation lauffähig zu machen, müssen Sie (in diesem Fall) libdb-4.2.so finden: $ find / -type f -name libdb-4.2.so /usr/lib/libdb-4.2.so Dieser Befehl braucht ewig (da das ganze Dateisystem durchsucht wird), aber wenn Sie Glück haben und die verschollene Bibliothek finden, können Sie das Verzeichnis, in dem Sie sich befindet, in /etc/ld.so.conf ergänzen und anschließend das ldconfig-kommando laufen lassen. Das kann dann aber wieder zu Bibliotheks- oder Symbolkollisionen führen: Mit shared libraries rumzuspielen, ohne zu wissen, was man tut, führt eigentlich fast immer zu einer Katastrophe ;-) Hinweis Der o.g. find-befehl hilft evtl. auch nicht, da die Bibliothek gar nicht installiert sein könnte. In solch einem Fall sollten Sie nach dem Paket suchen, welches die Bibliothek bereitstellt. B.3.3 Böse Fallen mit chroot Allzu oft sorgt die sorglose Aktivierung von Postfix' chroot-feature für Probleme. Eine Postfix-Standardinstallation nutzt aus gutem Grund das chroot-feature nicht: Ein chroot fügt zusätzliche Komplexität hinzu, und zu viele Dinge können schief gehen. Daher hat Wietse Venema chroot nicht standardmäßig aktiviert. Unglücklicherweise ignorieren einige Paketbetreuer diese Maßgabe, die auch in den Anleitungen für Paketbetreuer dokumentiert ist, und aktivieren in ihren Paketen chroot entweder für alle oder einige Dämonen. Das produziert nicht nur Verwirrung und Unzufriedenheit, sondern auch das Gefühl von (Pseudo-)Sicherheit. Das chroot-feature bringt nur etwas, wenn Sie das restliche System vorher»gehärtet«haben. Alle Postfix-Dämonen öffnen die von ihnen benötigten Maps, bevor sie chroot () ausführen. Postfix erwartet vom chroot, dass Systemdateien für DNS-Anfragen, Bestimmung der Zeitzone und andere Dateien, die Systembibliotheken evtl. benötigen, dort vorhanden sind. Wenn Sie das chroot-feature nutzen möchten, müssen Sie dazu die chroot-umgebung einrichten. Ein Paketbetreuer stellt Ihnen hoffentlich Skripte bereit, die im Falle der Aktivierung des chroot-features diese benötigten Dateien in das chroot- Verzeichnis kopieren.

11 B.4 Inkompatibilitäten 497 Üblicherweise benötigen Sie /etc/resolv.conf und /etc/nsswitch.conf. Die Postfix-Quellen enthalten ein Unterverzeichnis examples/chroot-setup, das Skripte zum Aufsetzen des chroot-verzeichnisses für verschiedenste Betriebssysteme bereitstellt. Wenn Sie nun also gerade erst anfangen, sich mit Postfix zu beschäftigen, sollten Sie erst einmal vom chroot-betrieb absehen. Sie sollten sogar sicherstellen, dass es nicht aktiviert ist. Öffnen Sie /etc/postfix/master.cf im Editor und sehen Sie sich jede Zeile an: # ========================================================================== # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) # ========================================================================== smtp inet n smtpd Ein Bindestrich»-«oder»y«in der Spalte chroot aktiviert chroot für den dort gelisteten Daemon. Setzen Sie die Spalte auf»n«und stoppen und starten Sie Postfix, um diesen Daemon vom chroot-betrieb auszunehmen. Bedenken Sie außerdem, dass nicht alle Postfix-Dämonen das chroot-feature (siehe Kapitel 22) nutzen können. B.4 Inkompatibilitäten Installationen, Upgrades, Patches auf einem Server ist im Laufe seines Lebens eine Menge los. Und wie immer steckt der Teufel im Detail. B.4.1 Inkonsistente Dämonen Wenn ein Upgrade von Postfix fehlschlägt oder wenn Sie abenteuerliche Aktionen vornehmen (wie z.b. die Installation aus Quellen über ein RPM, ohne vorher das RPM-Paket zu deinstallieren), können seltsame Dinge geschehen. In so einem Fall kann es passieren, dass Dämonen verschiedener Postfix-Versionen vermischt laufen und untereinander nicht kommunizieren können. Um herauszufinden, zu welcher Postfix-Version ein Daemon gehört, können Sie das strings-kommando nutzen: $ cd /usr/libexec/postfix $ strings * grep "\-200" sort uniq -c Hier stimmt alles! Alle 25 Dämonen in dem Verzeichnis haben dieselbe Versionskennung (in Form von Versionsnummer und Datum). Für die Stable-Releases von Postfix ist ein anderer regulärer Ausdruck erforderlich: $ cd /usr/libexec/postfix $ strings * grep "^[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]$" sort uniq -c

12 498 B Problemsuche und -behebung tlsmgr-daemon Das Problem vermischter Dämonen verschiedener Postfix-Versionen ist uns besonders durch Probleme mit dem durch den TLS-Patch hinzugefügten tlsmgr-daemon bekannt. Ob Sie davon betroffen sind, können Sie daran erkennen, dass die Last unglaublich hoch ist und die Prozess-IDs sich sehr schnell ändern. Gleichzeitig können Sie aber feststellen, dass es kaum Mailverkehr gibt oder in der Mail-Queue abgelegt ist. Typischerweise tritt diese Situation auf, wenn Sie Postfix erneuert, aber den alten tlsmgr-daemon und die alte master.cf-datei beibehalten haben, die den tlsmgr-daemon noch immer aufruft. Postfix ruft den alten tlsmgr weiterhin auf, dieser terminiert aber sofort mit Status 0, weil er nicht mit der neuen Postfix-Version zusammenarbeiten kann. Postfix loggt nichts, denn Status 0 bedeutet»erfolg«. Weil aber der tlsmgr-daemon beendet wurde, startet Postfix den tlsmgr-daemon sofort erneut und alles beginnt von vorne. Wenn dies bei Ihnen tatsächlich der Fall ist, kommentieren Sie den tlsmgr-eintrag in master.cf einfach aus und überprüfen Sie anschließend die Systemlast. Wenn Sie den tlsmgr-daemon benötigen, hilft es nur, eine neue Postfix-Version zu installieren dabei sollte der alte tlsmgr-daemon durch einen neuen ersetzt werden. B.4.2 BerkeleyDB-Probleme Postfix nutzt, neben vielen anderen shared libraries, die BerkeleyDB. Diese Bibliothek sorgt immer wieder für Probleme, denn es gibt unzählige, verschiedene Versionen, die sich untereinander nicht vertragen die Datenformate für die auf der Platte befindlichen Datenbanken sind untereinander nicht kompatibel! In der Praxis bedeutet dies, dass Daten, die von einem Programm geschrieben werden, vom nächsten mit einer anderen Version der BerkeleyDB eventuell nicht gelesen werden können. Alle Komponenten Ihres Mailservers, also Postfix, POP-before-SMTP, dracd, postgrey und andere Programme, die die Map-Typen hash oder btree nutzen, müssen untereinander kompatible BerkeleyDB-Bibliotheken verwenden. Um zu sehen, welche Bibliotheken ein Postfix-Daemon benutzt, können Sie den Befehl ldd wie in Anhang B, Sek. 3.2 beschrieben nutzen: $ ldd smtpd libpostfix-master.so.1 => /usr/lib/libpostfix-master.so.1 (0xb7fb2000) libpostfix-tls.so.1 => /usr/lib/libpostfix-tls.so.1 (0xb7fa5000) libpostfix-dns.so.1 => /usr/lib/libpostfix-dns.so.1 (0xb7fa0000) libpostfix-global.so.1 => /usr/lib/libpostfix-global.so.1 (0xb7f78000) libpostfix-util.so.1 => /usr/lib/libpostfix-util.so.1 (0xb7f51000) libssl.so => /usr/lib/i686/cmov/libssl.so (0xb7f20000) libcrypto.so => /usr/lib/i686/cmov/libcrypto.so (0xb7e1e000) libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0xb7e08000) libdb-4.2.so => /usr/lib/libdb-4.2.so (0xb7d32000) libnsl.so.1 => /lib/tls/libnsl.so.1 (0xb7d1e000) libresolv.so.2 => /lib/tls/libresolv.so.2 (0xb7d0c000)

13 B.5 Hardware 499 libc.so.6 => /lib/tls/libc.so.6 (0xb7bd7000) libdl.so.2 => /lib/tls/libdl.so.2 (0xb7bd4000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7fce000) Dieser smtpd-daemon wurde gegen BerkeleyDB-4.2.x gelinkt. Alle Programme, die mit Postfix eine Map des Typs hash oder btree gemeinsam nutzen, müssen dieselbe BerkeleyDB-Version nutzen. B.5 Hardware Während Sie einen Belastungstest durchführen, können Sie mit Sicherheit große Lastspitzen auf Ihrem Server beobachten. Wenn Sie für einen Moment ignorieren, dass Sie vielleicht noch einen content_filter oder smtpd_proxy_filter einsetzen und Postfix damit ausbremsen, dann ist Postfix' Geschwindigkeit meist nur durch die I/O-Geschwindigkeit Ihrer Platten begrenzt. Ein Belastungstest kann die Grenzen der Platten ausloten. Wenn die Ausgabe von top eine hohe Last (z.b. 10.7) zeigt, aber keiner der Prozesse signifikant viel CPU verschlingt, dann kommt die Last von der Zeit, die der Kernel damit zubringt, auf I/O-Operationen zu warten. Während dieser Zeit kann der Kernel keine anderen Prozesse laufen lassen alle Prozesse warten gleichermaßen auf I/O. Hinweis Linux-2.6-Kernel unterstützen eine Anzeige des iowait-status mit dem top-kommando; in Kernel 2.4 ist das noch nicht der Fall. Folgende Lösungsansätze kennen wir für solche Fälle: Platten I/O Dem Problem an sich können Sie nur mit schnelleren Festplatten, einer SSD (Solid State Disk, so etwas wie eine batteriegepufferte RAM-Disk) oder einem RAID-10-System (mirrored & striped) zu Leibe rücken. Auf diese Geräte lagern Sie das queue_directory aus. Kapitel 24 gibt Ihnen mehr Informationen dazu. Dateisystem Eine andere, vielleicht nur vorübergehende Lösung kann sein, synchrone Updates für das Queue-Verzeichnis zu deaktivieren. Wenn sich Ihr Queue-Verzeichnis auf einem ext2- oder ext3-dateisystem befindet, lassen Sie folgendes Kommando laufen: # chattr -R -S /var/spool/postfix/ Bei aktuellen Postfix-Installationen ist dies bereits die Standardkonfiguration.

14 500 B Problemsuche und -behebung B.6 Last-Tests Wenn Sie herausfinden wollen, wie viel Mailverkehr Ihre Postfix-Installation bewältigen kann, führen Sie einen Belastungstest durch. Um eine angemessene Last zu erzeugen, brauchen Sie einen schnellen Mailgenerator Postfix enthält bereits einen Satz Programme, die genau für diesen Zweck geschrieben worden sind: smtp-source und smtp-sink. smtp-source Dieses Programm verbindet sich per TCP mit einem Port auf einem Server (standardmäßig Port 25) und sendet eine oder mehrere Mails, entweder hintereinander oder parallel. Das Programm beherrscht sowohl SMTP (standard) als auch LMTP. smtp-sink Dieses Programm ist ein SMTP-Server, der auf dem angegebenen Host und Port lauscht. Er empfängt Mails aus dem Netz und wirft sie weg. Sie können hiermit die Performance eines Mailclients bzw. des Netzwerkes messen. Wir fangen mit smtp-source an und setzen unser Postfix-System richtig unter Last. Beispiel: Last mit smtp-source generieren Der folgende Beispielaufruf schickt 100 Mails, jeweils 5 KB groß, in 20 parallelen Verbindungen an einen (Postfix-)Server auf localhost, Port 25. Weil Sie auch wissen wollen, wie lange das dauert, benutzen wir auch noch zusätzlich den time- Befehl: $ time./smtp-source -s 20 -l m 100 -c -t recipient@example.com \ -f sender@example.com localhost: real 0m4.294s user 0m0.060s sys 0m0.030s 20 parallel sessions 5KB message size 100 total messages Display a counter Envelope sender Envelope recipient Target SMTP server In diesem Beispiel dauerte die Annahme dieser Mails 4,294 Sekunden. Wenn Sie wissen wollen, wie lange die tatsächliche Zustellung all dieser Mails gedauert hat, müssen Sie in Ihrem Log nach dem ersten und letzten Log-Eintrag für diese Kombination von Sender und Empfänger suchen (und natürlich sicherstellen, dass keine dieser Mails mehr in der Queue ist).

15 B.7 Community zur Hilfe holen 501 Beispiel: Wie viele s kann der Mailinglisten-Manager pro Sekunde herstellen? Nun wollen wir uns smtp-sink zuwenden und herausfinden, wie viele Mails pro Sekunde Ihr eigener Mailinglisten-Manager produzieren kann. Postfix muss jede Mail bearbeiten, auch wenn der Server auf der anderen Seite die s einfach nur verwerfen wird (d.h., Sie können diesen Test nicht nutzen, um die rohen Leistungsdaten Ihres Mailinglisten-Managers zu bestimmen, außer wenn Sie diesen direkt an smtp-sink ausliefern lassen). Das folgende Beispiel lässt smtp-sink auf localhost, Port 25 lauschen: #./smtp-sink -c localhost: Jetzt können Sie die Tests mit dem Client durchführen. Beispiel: Wie viel Overhead bringt das Netzwerk mit ein? Wenn Sie eine Vorstellung davon gewinnen wollen, wie viel Overhead das Netzwerk bedingt, können Sie auch ein kontrolliertes Experiment durchführen, um den maximalen Durchsatz Ihres Netzwerks zu bestimmen: Lassen Sie smtp-source und smtp-sink miteinander reden! Öffnen Sie zwei Fenster, und starten Sie im ersten den smtp-sink Prozess: #./smtp-sink -c localhost: Sobald der Mailserver läuft, beschießen Sie ihn mit Mails, die smtp-source im zweiten Fenster generiert: $ time./smtp-source -s 20 -l m 100 -c \ -f sender@example.com -t recipient@example.com localhost: real 0m0.239s user 0m0.000s sys 0m0.040s Diese Ausgabe zeigt, dass smtp-sink Mail ca. 18-mal schneller annimmt als Postfix, denn derselbe Test mit Postfix dauerte zuvor 4,294 Sekunden. Kein Wunder, Mail einfach wegzuwerfen ist natürlich schneller, als sie auf die Festplatte zu schreiben. B.7 Community zur Hilfe holen Wenn Sie die postfix-users-mailingliste abonnieren, erhalten Sie in der Begrüßungs- Informationen, die Ihnen zeigen, wie Sie ein Problem so melden können, dass die Community Ihnen auch gut und schnell helfen kann. Sie tun gut daran, diese Information zu liefern; andernfalls kann es Ihnen passieren, dass Ihre Frage einfach ignoriert wird, denn keiner der Helfer hat Lust, eine Glaskugel zu befragen, um Ihrem Problem auf die Spur zu kommen. Sollten Sie diese

16 502 B Problemsuche und -behebung gelöscht haben, finden Sie dieselben Informationen im Postfix Debugging Howto ( Einfach und bequem können Sie einen Großteil der relevanten Fragen beantworten, indem Sie postfinger ( herunterladen und ausführen. Es wurde von Simon J. Mudd geschrieben und extrahiert relevante Debug-Informationen. Wenn Ihr Problem allerdings mit SMTP-AUTH und damit SASL zu tun hat, benutzen Sie stattdessen Patricks Skript saslfinger ( patrick.koetter/saslfinger). saslfinger ist ein BASH-Skript, das verschiedenste Informationen über Cyrus SASL und Postfix auf Ihrem System sammelt und auf der Standardausgabe ausgibt. Der mitgelieferten Dokumentation entnehmen Sie, mit welchem Parameter Sie saslfinger starten müssen, damit es die richtigen Informationen sammelt.