Server Administration

Kürzlich gab es auf einem Debian 3.1 / Confixx 3.3.1 Server mit Exim4 Probleme mit den Mailinglisten. Das Einrichten von Mailinglisten sowie das Anmelden mittels Majorcool Weboberfläche klappte zwar problemlos, jedoch wurde jeglicher Versuch, an majordomo@domain oder an mailingliste@domain zu senden, mit folgender Fehlermeldung geblockt :

Fehler beim Sender der Nachricht. Der Mail Server antwortet: unknown user. Bitte überprüfen Sie die E-Mail Adressen der Empfänger und wiederholen Sie den Vorgang

exim4 -bt -d mailingliste@domain
terminierte mit rc=2 und bestätigte, dass Exim offenbar der User mailingliste@domain gar nicht bekannt war.

Es stellte sich heraus, dass in der von Confixx generierten /etc/exim4/confixx/confixx-aliases keinerlei Einträge für Majordomo vorgenommen waren. Diese befanden sich zwar in /etc/exim4/confixx/virtusertable - wurden aber beim Ausführen von makemap nicht herangezogen, da diese Datei dazu die /root/confixx/safe/virtusertable.tmp verwendete, die keine Einträge für die Mailinglisten Aliase enthielt.

Als temporäre Zwischenlösung wurde makemap so angepasst, dass es /etc/exim4/confixx/virtusertable zur Generierung der Confixx Aliases Datei verwendet:

/etc/exim4/confixx/makemap:
#!/bin/sh
# create exim4 compatible files from confixx.
perl /etc/exim4/confixx/makemail.pl --aliases < /etc/exim4/confixx/virtusertable > /etc/exim4/confixx/confixx-aliases
cp /etc/exim4/confixx/domains-template /etc/exim4/confixx/confixx-domains
perl /etc/exim4/confixx/makemail.pl --domains < /etc/exim4/confixx/virtusertable >> /etc/exim4/confixx/confixx-domains
chmod 644 /etc/aliases
/etc/exim4/confixx/maildir.pl
chown root.Debian-exim /usr/bin/autoresponder.pl
/etc/init.d/exim4 reload

Damit war das user unknown Problem behoben, da Exim4 nun die Majordomo Alias Einträge zuordnen und über den Router confixx_aliases zustellen konnte:

# router for the confixx aliases
confixx_aliases:
driver = redirect
data = ${lookup{$local_part@$domain}lsearch*@{/etc/exim4/confixx/confixx-aliases}}
debug_print = "R: virtual for $local_part@$domain"
pipe_transport = address_pipe
condition = ${if and { {!match {$local_part}{^web(.*)p(.*)}} {!match {$local_part}{^confixx-du-(.*)}}} {1}{0}}

Soweit so gut, auf zum nächsten Problem

Nun generierte ein Versand von Mails an majordomo@domain folgende Fehlermeldung:

Eine Nachricht die Sie versendet haben konnte nicht zu allen Empfängern gesendet werden.
Der Versand zu folgender/folgenden Adresse/n schlug fehl:

pipe to |/usr/bin/confixxevent.pl -ot 3 -oi 2943 -et 110
generated by majordomo-2943@domain
(ultimately generated from majordomo@domain)
local delivery failed

Die Log-Einträge waren noch etwas umfangreicher:

/var/log/exim4/mainlog.3:2008-02-07 01:06:58 1JXQ70-0007Wc-A4 ** |/usr/bin/confixxevent.pl -ot 3 -oi 2943 -et 110 (majordomo-2943@domain) R=system_aliases T=address_pipe: Child process of address_pipe transport returned 127 (could mean unable to exec or command does not exist) from command: /usr/bin/confixxevent.pl

Und bestätigten die Vermutung, dass die Rechte der Datei /usr/bin/confixxevent.pl Exim4 nicht erlauben, diese auszuführen.

chown root.Debian-exim /usr/bin/confixxevent.pl
chmod 550 /usr/bin/confixxevent.pl
# falls das nicht funktioniert:
chmod 555 /usr/bin/confixxevent.pl

sollte Abhilfe schaffen. Falls danach immer noch Fehler auftreten, lohnt sich ein Blick in die /usr/bin/confixxevent.pl. Im oberen Bereich stehen nämlich die Zugangsdaten zur Confixx DB und diese sollten natürlich mit den Daten in /root/confixx/confixx_main.conf übereinstimmen…

$db_address = 'DBI:mysql:confixx:localhost;mysql_socket=/var/run/mysqld/mysqld.sock';
$dbUser = 'confixx';
$dbPw = 'xxxxxxx';
$ServerID = 'xxxxxxxxxxxxxxxxx';

Nach diesen Änderungen funktionierte der Mailversand an majordomo@domain inklusive aller Mailinglisten Befehle (lists, subscribe, auth usw.) - also das An- und Abmelden bei Mailinglisten - problemlos,  allerdings war es nach wie vor unmöglich, an mailingliste@domain direkt zu senden:

Eine Nachricht die Sie versendet haben konnte nicht zu allen Empfängern gesendet werden.
Der Versand zu folgender/folgenden Adresse/n schlug fehl:

pipe to |”/usr/local/majordomo/wrapper resend -C /usr/local/majordomo/2943/majordomo.cf -M 10000 -R -l mailingliste -f owner-mailingliste -h domain -s mailingliste-2943-outgoing”
generated by news-2943@domain
(ultimately generated from mailingliste@domain)
local delivery failed

Die Log Einträge deuteten zunächst wieder auf ein Rechteproblem hin:

2008-02-09 12:58:52 1JYKB1-0006kr-WE ** |”/usr/local/majordomo/wrapper resend -C /usr/local/majordomo/2943/majordomo.cf -M 10000 -R -l mailingliste -f owner-mailingliste -h domain -s mailingliste-2943-outgoing” (mailingliste-2943@domain) R=system_aliases T=address_pipe: Child process of address_pipe transport returned 127 (could mean unable to exec or command does not exist) from command: “/usr/local/majordomo/wrapper resend -C /usr/local/majordomo/2943/majordomo.cf -M 10000 -R -l mailingliste -f owner-mailingliste -h domain -s mailingliste-2943-outgoing”

Allerdings waren die Rechte des wrappers in Ordnung:

-rwsr-xr-x 1 root majordomo 14703 Oct 20 2007 /usr/local/majordomo/wrapper

Letztendlich stellte sich heraus, dass nicht die Rechte des Wrappers, sondern die Schreibweise des Pipe Kommandos in der /etc/aliases Ursache des Problems war:

Nicht funktionierender Original Eintrag:
# Majordomo support for domain
majordomo-872: |"/usr/local/majordomo/wrapper majordomo -C /usr/local/majordomo/872/majordomo.cf" , "|/usr/bin/confixxevent.pl -ot 3 -oi 872 -et 110"
# mailingliste @ domain mailing list
mailingliste-872: |"/usr/local/majordomo/wrapper resend -C /usr/local/majordomo/872/majordomo.cf -M 10000 -R -l mailingliste -f owner-mailingliste -h domain -s mailingliste-872-outgoing"
mailingliste-872-outgoing: :include:/usr/local/majordomo/872/lists/mailingliste, mailingliste-872-archive
mailingliste-872-archive: |"/usr/local/majordomo/wrapper archive2.pl -C /usr/local/majordomo/872/majordomo.cf -m -a -f /usr/local/majordomo/872/lists/mailingliste.archive/t$
mailingliste-872-request: |"/usr/local/majordomo/wrapper request-answer -C /usr/local/majordomo/872/majordomo.cf mailingliste-872"
owner-mailingliste-872: mailingliste@domain2

Auf http://wiki.exim.org/FAQ/General_Debugging/Q0026 gab es den Hinweis, dass falls ein Pipe Kommando nicht funktioniert, wenn der Alias Eintrag so geschrieben ist:
alias: |"/some/command some parameters"

man versuchen soll, den Eintrag so zu schreiben:
alias: "|/some/command some parameters"

Und siehe da, mit dem folgenden Eintrag in der /etc/aliases arbeiteten die Mailinglisten wunderbar

# Majordomo support for domain
majordomo-872: "|/usr/local/majordomo/wrapper majordomo -C /usr/local/majordomo/872/majordomo.cf" , "|/usr/bin/confixxevent.pl -ot 3 -oi 872 -et 110"
# mailingliste @ domain mailing list
mailingliste-872: "|/usr/local/majordomo/wrapper resend -C /usr/local/majordomo/872/majordomo.cf -M 10000 -R -l mailingliste -f owner-mailingliste -h domain -s mailingliste-872-outgoing"
mailingliste-872-outgoing: :include:/usr/local/majordomo/872/lists/mailingliste, mailingliste-872-archive
mailingliste-872-archive: "|/usr/local/majordomo/wrapper archive2.pl -C /usr/local/majordomo/872/majordomo.cf -m -a -f /usr/local/majordomo/872/lists/mailingliste.archive/t$
mailingliste-872-request: "|/usr/local/majordomo/wrapper request-answer -C /usr/local/majordomo/872/majordomo.cf mailingliste-872"
owner-mailingliste-872: mailingliste@domain2

Auf einem vServer tauchte nach einem Confixx Update folgende Fehlermeldung auf:

Warning: include(/var/www/confixx/events.inc.php) [function.include]: failed to open stream: Permission denied in /var/www/confixx/html/events.inc.php on line 2
Warning: include() [function.include]: Failed opening '/var/www/confixx/events.inc.php' for inclusion (include_path='.:/var/www/confixx/html/include:/var/www/confixx/html:/var/www/confixx/html/PEAR') in /var/www/confixx/html/events.inc.php on line 2

Ursache:

Die Rechte der Confixx events.inc.php Datei sind falsch:
server11:~# ls -la /var/www/confixx/events.inc.php
-r--r----- 1 confixx confixx 802 Dec 28 01:42 /var/www/confixx/events.inc.php

Lösung:

/var/www/confixx/events.inc.php muss von allen lesbar sein:

server11:~# chmod 444 /var/www/confixx/events.inc.php

Wenn beim Ausführen des DNS Administrations Tools eazydns folgende Fehlermeldung angezeigt wird…

server:~# /root/eazydns/eazydns
Can't load '/tmp/DBI.so' for module DBI: /tmp/DBI.so: failed to map segment from shared object: Operation not permitted at PERL2EXE_STORAGE/DynaLoader.pm line 229.
at PERL2EXE_STORAGE/DBI.pm line 250
BEGIN failed--compilation aborted at PERL2EXE_STORAGE/DBI.pm line 250.
Compilation failed in require at /root/eazydns/eazydns line 24.
BEGIN failed--compilation aborted at /root/eazydns/eazydns line 24.


… hat dies zumeist als Ursache, dass die /tmp Partition des Webservers auf noexec gemountet ist und somit keine Scripte im temporären Verzeichnis ausgeführt werden können. Nun erfolgt das Mounten von /tmp auf noexec nicht von ungefähr,
(more…)

Diese Fehlermeldungen ist insbesondere bei vServern anzutreffen und ist i.d.R. mit dem (unregelmäßigen) Ausfall von einzelnen Diensten (z.B. Mail) verbunden.

Im Log sieht es z.B. wie folgt aus:

Oct 12 10:09:59 server master[21679]: fatal: master_spawn: exec /usr/lib/postfix/bounce: Resource temporarily unavailable
Oct 12 10:09:59 server master[21680]: fatal: master_spawn: exec /usr/lib/postfix/smtp: Resource temporarily unavailable
Oct 12 10:09:59 server postfix/qmgr[3212]: fatal: qmgr_active_defer: rename 0C57D1EC31026 from active to deferred: Cannot allocate memory
Oct 12 13:01:03 server postfix/qmgr[14244]: fatal: socket: Cannot allocate memory
Oct 12 13:01:03 server postfix/smtp[32170]: fatal: accept connection: Cannot allocate memory
Oct 12 13:01:45 server master[7680]: fatal: master_spawn: exec /usr/lib/postfix/cleanup: Resource temporarily unavailable
Oct 12 13:01:45 server postfix/master[3203]: fatal: event_loop: select: Cannot allocate memory
Oct 12 13:01:46 server postfix/smtpd[7652]: fatal: unable to connect to the public cleanup service
Oct 12 13:03:27 server postfix/smtpd[7651]: fatal: connect #11 to subsystem public/cleanup: Connection refused
Oct 12 13:03:27 server postfix/smtpd[7653]: fatal: connect #11 to subsystem public/cleanup: Connection refused
Oct 12 15:08:23 server postfix/smtp[5599]: fatal: open active 966EA1EC3004C: Too many open files in system
(more…)

Fehler:

Login per FTP ist nur sporadisch oder gar nicht möglich.

In den Logfiles taucht folgende Meldung auf:

mod_delay/0.4: delaying for 27 usecs

Lösung:

editieren von /etc/proftpd.conf
server:~# pico /etc/proftpd.conf

folgende Config anhängen:
DelayEngine off

proftpd neu starten:
server:~# /etc/init.d/proftpd restart

Damit ist die DelayEngine ausgeschaltet, die u.a. dazu führt, dass auf einem Multi-User Server der Login zum Teil derartig verzögert wird bzw. unmöglich wird.