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

Ein Schritt zur Absicherung eines Servers (egal ob vServer, vds oder dedizierter Server) ist es, regelmäßig Tools laufen zu lassen, die nach s.g. Rootkits suchen. Wir möchten hier die Installation und Konfiguration von 2 bekannten Vertretern dieser “Rootkit-Hunter” vorstellen:

2. RKhunter installieren

# ggf. alte Dateien entfernen
cd /usr/local/src
rm -fR rkhunter*

# rkhunter herunterladen + entpacken
wget http://ovh.dl.sourceforge.net/sourceforge/rkhunter/rkhunter-1.2.9.tar.gz
tar zxfv rkhunter-1.2.9.tar.gz

# Rechte auf root ändern
chown -R root.root rkhunter-1.2.9

# rkhunter installieren
cd rkhunter-1.2.9
./installer.sh

# Update ausführen, um ggf. die aktuellste Version zu laden
rkhunter --update

# RKhunter das erste Mal ausführen
/usr/local/bin/rkhunter -c --nocolors --createlogfile --skip-keypress

Auf einem “jungfräulichen” System sollte rkhunter keine Probleme oder Infektionen finden!

Es ist empfehlenswert, rkhunter regelmäßig laufen zu lassen, am besten als Cronjob einrichten:

# crontab editieren
crontab -e

# ganz unten eine neue Zeile einfügen und folgendes einfügen:
@hourly rkhunter --update; /usr/local/bin/rkhunter -c --cronjob --nocolors --report-mode --createlogfile --skip-keypress | mail -s "[servername] rkhunter output" mail@serveradmin

# speichern und beenden
[esc] :wq [enter]

Ein Schritt zur Absicherung eines Servers (egal ob vServer, vds oder dedizierter Server) ist es, regelmäßig Tools laufen zu lassen, die nach s.g. Rootkits suchen. Wir möchten hier die Installation und Konfiguration von 2 bekannten Vertretern dieser “Rootkit-Hunter” vorstellen:

1. chkrootkit installieren

# Verzeichnis zum Download erstellen
mkdir -p /usr/local/src
cd /usr/local/src

# ggf. vorhandenes älteres Archiv löschen
rm -f chkrootkit.tar.gz

# download chkrootkit und entpacken
wget ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.tar.gz
tar zxfv chkrootkit.tar.gz

# Dateirechte einstellen auf root
chown -R root.root chkrootkit-0.48

# chkrootkit installieren
cd chkrootkit-0.48
make sense

# alten symlink entfernen + neuen setzen
cd ..
rm -f chkrootkit
ln -s chkrootkit-0.48 chkrootkit

# alte Versions Dateien und Archiv löschen, wird nicht mehr benötigt
rm -rf chkrootkit-0.47
rm -f chkrootkit.tar.gz

# chkrootkit zum ersten Mal ausführen
cd chkrootkit
./chkrootkit

Auf einem “jungfräulichen” System sollte chkrootkit keine Probleme oder Infektionen finden!

Es ist empfehlenswert, chkrootkit regelmäßig laufen zu lassen, am besten als Cronjob einrichten:

# crontab editieren
crontab -e

# ganz unten eine neue Zeile einfügen und folgendes einfügen:
@hourly cd /usr/local/src/chkrootkit; ./chkrootkit | mail -s "[servername] chkrootkit output" mail@serveradmin

# speichern und beenden
[esc] :wq [enter]

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

Wer kennt es nicht, das lästige Problem: Ständig müssen Updates von Software Komponenten eingespielt werden und die Schritte sind immer wieder die selben. So auch bei phpMyAdmin. Es muss das Archiv geladen, entpackt, die Config editiert sowie ggf. Symlinks gesetzt werden…

Gut, nun kann man sagen, ich nehme einfach das fertige .deb Paket und installiere es per Apt

apt-get install phpmyadmin

und mache die Updates dann automatisch per

apt-get update
apt-get upgrade

Nur leider sind häufig die Debian Pakete nicht die neuesten, weshalb sich eine manuelle Installation empfiehlt. Das folgende kleine Shell Script soll die müßigen Arbeitsschritte für faule (bzw. effieziente!) Admins etwas erleichtern. Das Script ist für Confixx Server gedacht, daher wird phpMyAdmin in /var/www/confixx/html installiert. Dies kann natürlich an die eigenen Bedürfnisse angepasst werden… (more…)