VServer
Hier will ich versuchen zu dokumentieren, was ich bei meinem Strato-VServer zu beachten hatte.
Postfix statt Sendmail
Im Auslieferungszustand des Servers ist Sendmail als MTA installiert. Da auf allen anderen Servern die ich betreue Postfix läuft wollte ich das auch hier realisieren. Also habe ich Sendmail deinstalliert und Postfix, Amavis und Antivir installiert.
Die Konfiguration von Postfix ist ja auch kein Problem, YaST hilft im Zweifelsfall dabei. Als Problem erwis sich Amavis, das starb immer wieder ab und hinterließ folgende Fehlermeldung
Feb 11 16:30:46 h791114 amavis[10492]: TROUBLE in pre_loop_hook: BDB bad db env. at /var/spool/amavis/db: Das Argument ist ung\303\274ltig, Datei oder Verzeichnis nicht gefunden. at (eval 50) line 230.
Als Ursache dieses Problems lässt sich die BerkleyDB identifizieren. Auch der Aufruf
db_stat -c -h /var/spool/amavis/db/
führt zu einer ähnlichen Fehlermeldung.
db_stat: Berkeley DB library configured to support only private environments db_stat: DB_ENV->open: /var/spool/amavis/db/: Invalid argument
Vermutlich kommen die Programmkomponenten mit dem Dateisystems des VServers nicht klar, eventuell weil es reiserfs ohne XATTR ist. An dem virtuellen System ist da aber nichts zu ändern.
Glücklicherweise kann man in der /etc/amavisd.conf die Datenbanknutzung deaktivieren (Zeile 47):
$enable_db = 0; # enable use of BerkeleyDB/libdb (SNMP and nanny) $enable_global_cache = 1; # enable use of libdb-based cache if $enable_db=1
danach startet amavis und das Mailsystem ist einsatzbereit.
Das Problem mit der BerkleyDB soll sich durch ein Neucompilieren der Pakete lösen lassen (http://archive.netbsd.se/?ml=amavis-user&a=2005-07&t=1089675), momentan besteht aber kein Handlungsdruck.
Noch ein kleines Problem taucht mit Postfix auf. Es arbeitet sowohl mit ipv4, als auch mit ipv6. Der virtuelle Server verfügt aber über kein ipv6. Dadurch gibt es ständig Fehlermeldungen der Art
Feb 11 16:12:28 h791114 postfix[8407]: warning: inet_protocols: IPv6 support is disabled: Address family not supported by protocol Feb 11 16:12:28 h791114 postfix[8407]: warning: inet_protocols: configuring for IPv4 support only
Zum Vermeiden der Fehlermeldung habe ich die Datei /etc/syconfig/postfix um die folgenden Zeilen ergänzt:
## Type: string ## Default: all POSTFIX_ADD_INET_PROTOCOLS="ipv4";
Ein Vorteil des eigenen Root-Servers besteht darin, dass ich selber entscheiden kann, was mit Spam passiert. Ich habe bei mir die mittlere Spam-Abwehr aktiviert und einige RBL-Listen:
## Type: string ## Default: "" ## Config: postfix # # A comma seperated list of hosts that blacklist client IP addresses # Note: This only has effect, if POSTFIX_BASIC_SPAM_PREVENTION is set # to either "medium" or "hard". If left empty, no RBL checks will take place. # # Example: POSTFIX_RBL_HOSTS="rbl1.example.com, rbl2.example.com" # POSTFIX_RBL_HOSTS="dul.dnsbl.sorbs.net, bl.spamcop.net, blackholes.mail-abuse.org, whois.rfc-ignorant.org" ## Type: string(off,medium,hard) ## Default: off ## Config: postfix # # POSTFIX_BASIC_SPAM_PREVENTION possible values: # off : postfix default configuration # medium : medium UCE policy checks # hard : hard UCE policy checks # # Setting this to medium or hard will activate some basic UCE controls # supported by postfix. This may lead to mails which are undeliverable # to your mailserver! USE THAT ON YOUR OWN RISC!!! # See http://www.postfix.org/uce.html for more details ! # POSTFIX_BASIC_SPAM_PREVENTION="medium"
Die Einstellung hard an dieser Stelle blockt auch manche Firmen ab, die ihre Mailserver nicht ordentlich konfiguriert haben. Oft findet man nämlich keine Auflösung der IP zu einem Hostnamen und dann würde Postfix von solch einem Rechner keine Mail annehmen. Die Strato-Nameservereinträge sind da wirklich sehr ordentlich.
Lokaler Nameserver
Zusätzlich habe ich mir für meine domains einen lokalen Nameserver konfiguriert. Das ist notwendig, wenn man komische Fehlermeldungen vermeiden möchte. Die Nameserver von Strato leiten nämlich alle Subdomais auf den Server weiter. Also auch etwa wie quatsch.debacher.com. Mails an derartige Domaisn soll der Rechner nicht annehmen. Er bekommt sie aber und merkt dann, dass er sich nicht zuständig fühlt, aber laut Nameserver zuständig ist. Die daraus resultierende Fehlermeldung ist recht verwirrend.
Ein lokaler Nameserver hat nun den Vorteil, dass Postfix auch laut (lokalem) Nameserver nicht zuständig ist und eine nachvollziehbare Fehlermeldung liefert.
POP und IMAP mit Dovecot
Bei der Grundinstallation des Servers ist als POP-Daemon ein popa3d vorhanden. Dieses Programm beherrscht zwar auch verschlüsselte Verbindungen (POP3s), gefiel mir aber von den Funktionen her nicht.
Ein sehr flexibler Server für diesen Zweck ist Dovecot aus dem gleichnamigen Paket.
Nach der Installation von Dovecot muss nur der bisherige POP-Server deaktiviert werden, entweder über YaST und die Konfiguration des xinetd oder direkt in den Dateien /etc/xinetd.d/pop3d und /etc/xinetd.d/pop3d. Dort muss einfach nur die Zeile
disable = no
auf
disable = yes
verändert werden. Nach einem Neustart des xinetd ist der popa deaktioviert.
Bei Dovecot ist erst einmal nicht viel zu machen. Einfach
rcdovecot start
und
insserv dovecot
damit ist das geregelt.
Ich wollte aber neben POP3 und IMAP auch unbedingt die gesichrten Varianten aktivieren. Die notwendigen Einstallungen dafür finden sich am anfang der Konfigurationsdatei:
## Dovecot 1.0 configuration file
# Default values are shown after each value, it's not required to uncomment # any of the lines. Exception to this are paths, they're just examples # with real defaults being based on configure options. The paths listed here # are for configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var # --with-ssldir=/etc/ssl # Base directory where to store runtime data. #base_dir = /var/run/dovecot/ # Protocols we want to be serving: # imap imaps pop3 pop3s protocols = imap pop3 imaps pop3s
Diese Änderung alleine langt noch nicht. Für eine gesicherte Verbindung ist ein Server-Zertifikat notwendig. Das notwendige Rüstzeug zum Erstellen eines derartigen Zertifikates bringt Dovecot auch mit.
Im Verzeichnis /usr/share/doc/packages/dovecot/ befindet sich alles was man braucht. Zuerst habe ich dort die Datei dovecot-openssl.cnf an meine Bedürfnisse angepasst:
[ req ] default_bits = 1024 encrypt_key = yes distinguished_name = req_dn x509_extensions = cert_type prompt = no [ req_dn ] # country (2 letter code) C=DE # State or Province Name (full name) #ST= # Locality Name (eg. city) #L=Helsinki # Organization (eg. company) #O=Dovecot # Organizational Unit Name (eg. section) OU=IMAP server # Common Name (*.example.com is also possible) CN=imap.debacher.com # E-mail contact emailAddress=postmaster@meine-maildomain.de [ cert_type ] nsCertType = server
und damm mit
bash mkcert.sh
das Zertifikat erstellt.
Nach einem Neustart von Dovecot sollte auch eine gesicherte Verbindung möglich sein.
SMTP-Auth
Wenn schon ein Server mit fester IP-Adresse vorhanden ist, dann sollte der auch in der Lage sein von meinen Arbeitsplatzrechnern die Mails anzunehmen. Da meine Arbeitsplatzrechner nicht im gleichen Netz sind wäre dies also ein klassisches Relay. Das kann man nicht ohne Absicherung machen. Zum Abliefern der Mails muss dher Benutzername und Passwort mit angegeben werden.
Postfix beherrscht grundsätzlich SMTP-AUTH im Zusammenspiel mir dem Paket Cyrus-SASL.
Wenn der saslauthd aus dem Paket Cyrus-SASL läuft
rcsaslauthd status
dann ist nur noch in Zeile 175 von /etc/sysconfig/postfix eine kleine Änderung fällig:
## Type: yesno ## Default: no ## Config: postfix # # Configure postfix to enable users to auth against postfix # to be able to relay mail independent of being within # the local network/domain. # You may want to edit /usr/lib/sasl2/smtpd.conf to fit # your needs. # See /usr/share/doc/packages/postfix/README_FILES/SASL_README # for more details. # POSTFIX_SMTP_AUTH_SERVER="yes"
Normalerweise steht in der letzten Zeile ein "no", welches durch ein "yes" ersetzt werden muss. Jetzt muss noch die Konfiguration von Postfix aktualisiert werden:
SuSEconfig --module postfix
und dann Postfix aufgefordert werden die Datei neu zu laden
postfix reload
Leider war es so, dass die Anmeldung noch nicht klappte, es tauchte folgende Fehlermeldung auf:
Feb 14 17:50:29 h791114 PAM-warn[26987]: function=[pam_sm_authenticate] service=[smtp] terminal=[<unknown>] user=[debacher] ruser=[<unknown>] rhost=[<unknown>] Feb 14 17:50:29 h791114 saslauthd[26987]: DEBUG: auth_pam: pam_authenticate failed: Authentication failure Feb 14 17:50:29 h791114 saslauthd[26987]: do_auth : auth failure: [user=debacher] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]
Ursache für das Problem war PAM. Das kannte den Dienst nicht und hat gemäß Voreinstellung dann die Anmeldung blockiert. Eine Datei /etc/pam.d/smtp mit folgendem Inhalt:
#%PAM-1.0 auth include common-auth account include common-account password include common-password session include common-session
löst das Problem.
