Root-Server mit OpenSuSE 12.2/12.3
Der Teufel steckt immer im Detail. Ich hoffe jedes mal, bei der Neueinrichtung eines Servers, dass ich die Beschreibung von der vorigen Version direkt übernehmen kann. Leider gibt es auch bei kleinen Versionsunterschieden teilweise mühsame Unterschiede, Probleme wie das mit pam_mysql kosten manchmal Tage, bis ich eine Lösung gefunden habe.
Daher auch für diese Version eine komplette Beschreibung zu Installation. Nachdem ich mit der Beschreibung für 12.2 fertig war habe ich den Server neu bespielen lassen, um die Beschreibung zu überprüfen. Da dann auch schon 12.3 verfügbar war habe ich natürlich dieses System benutzt. Die neuen Probleme habe ich dann mit in diesen Text integriert.
Root Server Linux Level 2
Inzwischen reicht der bisherige Root-Server nicht mehr aus. Ein zusätzlicher Server muss her, um auch für Hardware-Probleme vorgesorgt zu haben. Aktuell (Februar 2013) sind die Strato-Server noch günstiger geworden, wir zahlen 39€ im Monat und das ohne Einrichtungsgebühr und ohne Mindestlaufzeit. Dafür sind aber in dem Paket keine Domains mehr enthalten.
Die technischen Daten:
Opteron 1381 mit 4x2,5 GHz (4 x 5000 Bogomips) 4 GB RAM 2x500 GB HD als Raid1
Strato installiert anscheinend nicht mehr ein Standard-System auf Verdacht vor, sondern man muss über den Kundenservicebereich ein System auswählen, ich habe das Gerät mit OpenSUSE 12.2/12.3 64-Bit eingerichtet.
Serverausfall vom 30.07.2013
Der Server ist jetzt leider schon 36 Stunden down. Das ist bei Strato-Servern leider dann nicht schnell gelöst. Gestern am Nachmittag konnte ich ihn weder rebooten noch das Rettungssystem starten. Als Defekt kommt dann z.B. die Netzwerkkarte oder das Netzteil in Frage. Der Support hat trotzdem darauf bestanden, dass ich den Hardware-Test starte. Also den kurzen Test für 2 Stunden aktiviert. Nach knapp 20 Stunden stand dann im System, dass die Hardware defekt ist und ich einen Austausch veranlassen soll, dann ist natürlich die komplette Installation und Konfiguration weg. Der Support konnte mir dann am Telefon sagen, dass das Netzteil defekt ist und damit ein Chassis-Tausch in Frage kommt. Ich habe darum gebeten, weil dann die Daten hoffentlich erhalten bleiben. Mal sehen, wann der Server nun wieder erreichbar ist.
31.07.2013
Seit etwas 15.00h soll der Rechner wieder erreichbar sein, der Chassis-Tausch ist erfolgt. Nur ist der Rechner leider nicht erreichbar. Wieder lange 2 Minuten (hähä) in der Telefon-Warteschleife. Wieder ein Ticket aufgemacht. Aber wenn man mir schreibt, dass der Rechner in Ordnung ist, dann ist er in Ordnung. Mal sehen, wie es weitergeht.
So, gegen 19.00h konnte ich plötzlich auf den Server zugreifen, auf das Rescue-System. Dort musste ich an die Festplatte heran, um die Datei /etc/udev/rules.d/70-persistent-net.rules zu löschen, in der die Macadressen der Netzwerkkarten den Devices zugeordnet werden. Die Macadressen haben sich durch den Tausch verändert. Löscht man die Datei, so wird sie beim nächsten ordentlichen Boot neu angelegt. Etwas gewöhnungsbedürftig und nirgends so beschrieben ist die Tatsache, dass die Partitionen unter /dev/md123 bis /dev/md127 erreichbar waren. Ansonsten hat alles geklappt, Datei gelöscht, im Webinterface auf normalen Boot umgestellt und nach ein paar Minuten im Recue-System den Reboot ausgelöst.
Dauer von der ersten Störungsmeldung an den Support bis zur Lösung etwa 50 Stunden.
01.08.2013
Um 09.46 teilt mir Strato mit, dass mein Server wieder läuft, schön.
Serverausfall von November 2013
Es hat den Server schon wieder erwischt. Am 15.11. und am 20.11. ist der Server hängen geblieben, jeweils beim Sichern der Daten. Als Ursache tippe ich auf einen Schaden der ersten Festplatte. Die ist nämlich immer 5 Grad wärmer als die Zweite und meldet 65 reallocierte Sektoren. Ich habe dann begonnen die Domains zu verschieben und den Sicherungsprozess zu verlangsamen. Am späten 27.11. ist der Rechner dann doch wieder hängen geblieben.
28.11.2013
Ich habe dann abends am 28.11. den kurzen Hardwaretest ausgelöst und wirklich, nach knapp 2h kam die Meldung, dass der Prozessor defekt sei (wie kommt das Tool auf so etwas??).
Nach zwei Fehlversuchen (alle Plätze belegt) und dann 20 Minuten in der Warteschleife habe ich dann einen Mitarbeiter erreicht, der mir den Defekt bestätigen konnte und mir versprach den Hardware-Austausch zu veranlassen.
Mal sehen, wie lange ich diesmal warten muss.
29.11.2013
Gestern war alles klar. Heute morgen bekomme ich plötzlich eine Mail, dass ich den Server-Austausch online veranlassen soll. In der Mail stand schon drin, dass man es ggf. mit einem alternativen Browser versuchen soll "Sollten Sie bei dieser Aktion eine Fehlermeldung im Browser angezeigt bekommen, so überprüfen Sie bitte, ob sich dieses Verhalten durch die Nutzung eines alternativen Browsers beheben lässt". Nun ja, es geht (meistens) soweit gut, bis das Fensterchen mit dem letzten Ja auftaucht.
Leider kann ich hier nicht das Ja aktivieren. Eigentlich kann ich hier nur abbrechen. Versucht habe ich Firefox, IE, Chrome und Midori. Was soll ich den sonst noch nehmen????
Also wieder angerufen, diesmal kaum mehr als 10 Minuten in der Warteschleife. Der Ansprechpartner verspricht mein Anliegen Serveraustausch mit höchster Dringlichkeit weiter zu geben. Mal sehen, immerhin fragte er mich auch, welche Betriebssystem-Version ich installiert haben wollte.
Klasse, am frühen Nachmittag war dann plötzlich der neue Server da, mit der richtigen Installation, keine 24 Stunden nach der Fehlermeldung. Inzwischen laufen die meisten Webseiten wieder, morgen gehe ich dann ans Mailsystem.
Grundinstallation
Strato bietet bei der Installation mehrere Auswahlmöglichkeiten an. Einerseits kann man das Linux-System auswählen, idealerweise die aktuellste OpenSUSE-Version, andererseits auch die Partitionierung beeinflussen. Ich nehme die Variante, bei der /var, /srv und /home eigene Partitionen bekommen. Die Partitionsgrößen kann man nicht weiter beeinflussen, das ist etwas schade, da /home in der Regel viel zu groß eingestellt ist. Aber bisher habe ich trotzdem noch nie Platzprobleme bekommen.
Gleich nach der Installation sollte man in Yast2 bei den Firewall-Einstellungen eth0 als externes Device einstellen, damit SUSEFirewall vernünftig funktioniert. Wenn man das nicht macht und die Firewall startet, dann ist man aus dem Rechner ausgesperrt.
In den aktuellen OpenSUSE-Versionen läuft das Starten und Stoppen der Netzwerkdienste etwas anders, der klassische Runlevel-Editor funktioniert da nicht mehr vollständig.
systemctl status|start|stop <daemon>.service systemctl enable|disable <daemon>.service
Weitere Hinweise zur Grundinstallation finden sich ggf. auf den Seiten zu ISPConfig.
Zur Information, OPENSuSE 12.3 kommt mit apache 2.2.29, php 5.3.17, MySQL 5.5.33, dovecot 2.1.13 und postfix 2.9.6
Apache-Webserver
Die notwendigen Pakete installiert man am bequemsten von der Konsole aus mittels
yast2 -i apache2 apache2-example-pages apache2-prefork apache2-mod_perl apache2-mod_dnssd apache2-utils apache2-mod_php5
Dabei erscheint in Yast eine Fehlermeldung, man muss dann dort das Paket patterns-openSUSE-minimal_base-conflicts abwählen. Dann einige php Komponenten dazu:
yast2 -i php5-pear-Net_URL php5-json php5-mysql php5-pear-Date php5-openssl php5-xsl php5-pspell php5-iconv php5-calendar yast2 -i php5-pear-Net_Sieve php5-pear-HTTP_Request php5-ftp php5-tidy php5-mbstring php5-dom php5-sqlite php5-pear-Net_Socket yast2 -i php5-pear-Net_SMTP php5-pear-Date_Holidays_Germany php5-zip php5-pdo php5-gettext apache2-mod_php5 php5-pear-DB yast2 -i php5-pear-Net_URL php5-pear-cache_lite php5-pear php5-pear-MDB2_Driver_mysqli php5 php5-sockets php5-imap php5-ctype yast2 -i php5-ldap php5-pear-XML_Serializer php5-pear-HTTP_Request php5-mcrypt php5-xmlreader
Einige Pakete sind hierbei durch die Abhängigkeiten doppelt erwähnt, das stört aber nicht weiter. Etwas Perl braucht man auch immer
yast2 -i perl-HTTP-Cookies perl-Digest-HMAC perl-MailTools perl-SQL-Statement perl-Authen-SASL perl-Bootloader perl-IO-stringy yast2 -i perl-XML-Parser perl-Encode-Locale perl-GDTextUtil perl-Net-Daemon perl-Error perl-Convert-TNEF perl-Sys-Hostname-Long yast2 -i perl-Digest-SHA1 perl-razor-agents perl-TimeDate perl-GD-Graph3d perl-Socket6 perl-WWW-RobotRules perl perl-Mail-Sender yast2 -i perl-Params-Util perl-Email-Valid perl-Convert-ASN1 perl-Convert-BinHex perl-NetAddr-IP perl-Crypt-OpenSSL-RSA yast2 -i perl-X500-DN perl-Net-DBus perl-GDGraph perl-URI perl-Tie-IxHash apache2-mod_perl perl-IO-Socket-INET6 perl-MIME-Charset yast2 -i perl-DBI perl-Net-IP perl-MIME-EncWords perl-Log-Log4perl perl-Archive-Zip perl-Net-Ident perl-BerkeleyDB yast2 -i perl-Crypt-OpenSSL-Random perl-IP-Country perl-X11-Protocol perl-Config-Crontab perl-ldap perl-Mail-SPF yast2 -i perl-XML-Simple perl-Data-Dump yast2-perl-bindings perl-LWP-MediaTypes perl-GD perl-Net-LibIDN perl-HTML-Parser yast2 -i perl-base perl-Clone perl-Net-CIDR-Lite perl-Convert-UUlib perl-Unix-Syslog perl-MIME-tools perl-XML-Twig yast2 -i perl-Net-HTTP perl-Net-SSLeay perl-File-Listing perl-HTTP-Message perl-HTTP-Daemon yast2 -i perl-MLDBM perl-Net-DNS perl-HTML-SimpleParse perl-gettext limal-perl perl-Mail-SpamAssassin perl-HTML-Tagset yast2 -i perl-IO-Socket-SSL perl-HTTP-Negotiate perl-libwww-perl perl-LockFile-Simple perl-PlRPC perl-NetxAP perl-Net-Server yast2 -i perl-Encode-Detect perl-Parse-RecDescent perl-Mail-DKIM perl-HTTP-Date
Ich habe dann noch das Paket apache2-itk installiert, damit bekommt man eine Apache-Version, die mit unterschiedlichen Benutzern arbeiten kann. Zum Aktivieren des Modules muss dann noch in der Datei /etc/sysconfig/apache2 das Modul in der Zeile 151 ergänzt werden:
APACHE_MPM="itk"
Sollte man einmal PHP-Pakete benötigen, die in bei OpenSUSE 12.3 nicht mitgeliefert werden, so ist http://download.opensuse.org/repositories/server:/php:/extensions/openSUSE_12.3/x86_64/ eine gute Quelle für zusätzliche Pakete.
Datenbank
yast2 -i libmysqlclient_r18 mysql-community-server-client libqt4-sql-mysql postfix-mysql mysql-community-server libmysqlclient18 php5-mysql libmysqlclient-devel phpMyAdmin
In den bisherigen OpenSUSE-Version war das Binary-Logging für die Datenbank immer aktiviert. Dann gab es in /var/lib/mysql Dateien nach dem Muster mysql-bin.000001. Das hat mir bei der Fehlersuche schon mal sehr geholfen hier die SQL-Kommandos verfolgen zu können. In der aktuellen Version 12.3 ist das Logging neuerdings standardmäßig abgeschaltet, vermutlich seit einem Update (der letzte Eintrag war vom 15. August und an diesem Tag gab es auch ein MySQL-Update per Yast).
Nun das Logging lässt sich über die Datei /etc/my.cnf wieder aktivieren (Auszug ab Zeile 49).
# Replication Master Server (default) # binary logging is required for replication log-bin=mysql-bin # binary logging format - mixed recommended binlog_format=mixed
Man muss hier nur in den beiden Zeilen die Rauten entfernen und dann den MySQL-Server neu starten.
Man muss sich natürlich klar sein, dass diese Log-Dateien auch eine gewisse Menge Speicherplatz belegen.
Mailsystem
Auch hier wird eine Reihe von Paketen erst einmal benötigt.
yast2 -i postfix postfixadmin postfix-mysql dovecot21 dovecot21-backend-mysql dovecot21-backend-pgsql dovecot21-backend-sqlite
Exim abwählen
Yast
yast2 -i yast2-online-update-frontend yast2-mail yast2-runlevel
Sonstiges
yast2 -i man man-pages gcc make pam-devel mailx ImageMagick GraphicsMagick whois spamassassin smartmontools webalizer mailman
Mail mit Postfix und virtuellen Benutzern
Auf diesem Server soll es möglichst wenig Systembenutzer geben. Alle Mailadressen sollen also virtuell sein. Das System besteht aus folgenden Komponenten:
- Postfix
- Dovecot
- PostfixAdmin
Vorweg noch ein paar Informationen, die für das Testen ganz nützlich sind, man kann Mails in der Warteschlange (Abfrage mittels mailq) einzeln oder alle auf einen Schlag löschen.
postsuper -d ALL postsuper -d 52DBF19F51 (die komische Zeichenkette ist die Queue-ID die mailq mit ausgibt)
Den Inhalt der Mail findet man in
/var/spool/postfix/deferred/5/52DBF19F51
Zustellinformationen bzw. Fehlermeldungen in
/var/spool/postfix/defer/5/52DBF19F51
Für die folgende Beschreibung wird ein Benutzer vmail (uid 303) und eine Gruppe vmail (gid 303) benutzt, gemäß SuSe Voreinstellung. Der Benutzer hat als Homeverzeichnis /var/vmail, wo dann auch die eingehenden Mails liegen.
Falls Gruppe oder Benutzer nicht vorhanden sind, so legt man sie neu an:
groupadd -g 303 vmail mkdir /var/vmail chmod a+rxw /var/vmail useradd -d /var/vmail/ -s /bin/false -u 303 -g 303 vmail
Hinweis, bei openSUSE 12.2 ist eigentlich das Homeverzeichnis /srv/maildirs voreingestellt, ich habe aber gern Webserver-Daten und Mail-Daten auf unterschiedlichen Partitionen.
PostfixAdmin
Die Beschreibung geht aus von dem Programmpaket PostfixAdmin, welches die Verwaltung der virtuellen Mail-Adressen über ein kleines nettes Webfrontend erlaubt. Die Homepage dieses Programmes ist http://postfixadmin.sourceforge.net/. Das Programmpaket greift nur auf eine MySQL-Datenbank zu und nicht direkt in das Mailsystem ein.
Das Programm lässt sich ganz einfach über Yast installieren und liegt in der Version 2.3.5. vor (aktuell verfügbar ist 2.3.6: http://sourceforge.net/projects/postfixadmin/files/latest/download?source=files).
Bei ersten Aufruf von Postfixadmin startet das Setup-Programm, welches auch die notwendigen Datenbanktabellen anlegt, bzw.aktualisiert, wenn es sich um ein Update handelt.
Datenbanken
Nach dem Lauf des Setup-Programmes gibt es folgende Tabellen in der Datenbank postfix:
CREATE TABLE `admin` ( `username` varchar(255) NOT NULL default , `password` varchar(255) NOT NULL default , `created` datetime NOT NULL default '0000-00-00 00:00:00', `modified` datetime NOT NULL default '0000-00-00 00:00:00', `active` tinyint(1) NOT NULL default '1', PRIMARY KEY (`username`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COMMENT='Postfix Admin - Virtual Admins';
CREATE TABLE `alias` ( `address` varchar(255) NOT NULL, `goto` text NOT NULL, `domain` varchar(255) NOT NULL, `created` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', `modified` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', `active` tinyint(1) NOT NULL DEFAULT '1', PRIMARY KEY (`address`), KEY `domain` (`domain`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COMMENT='Postfix Admin - Virtual Aliases';
CREATE TABLE `alias_domain` ( `alias_domain` varchar(255) NOT NULL, `target_domain` varchar(255) NOT NULL, `created` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', `modified` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', `active` tinyint(1) NOT NULL DEFAULT '1', PRIMARY KEY (`alias_domain`), KEY `active` (`active`), KEY `target_domain` (`target_domain`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COMMENT='Postfix Admin - Domain Aliases';
CREATE TABLE `config` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(20) NOT NULL DEFAULT , `value` varchar(20) NOT NULL DEFAULT , PRIMARY KEY (`id`), UNIQUE KEY `name` (`name`) ) ENGINE=MyISAM AUTO_INCREMENT=2 DEFAULT CHARSET=latin1 COMMENT='PostfixAdmin settings';
CREATE TABLE `domain` ( `domain` varchar(255) NOT NULL, `description` varchar(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT 'Keine Beschreibung', `aliases` int(10) NOT NULL DEFAULT '0', `mailboxes` int(10) NOT NULL DEFAULT '0', `maxquota` bigint(20) NOT NULL DEFAULT '0', `quota` bigint(20) NOT NULL DEFAULT '0', `transport` varchar(255) NOT NULL, `backupmx` tinyint(1) NOT NULL DEFAULT '0', `created` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', `modified` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', `active` tinyint(1) NOT NULL DEFAULT '1', PRIMARY KEY (`domain`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COMMENT='Postfix Admin - Virtual Domains';
CREATE TABLE `domain_admins` ( `username` varchar(255) NOT NULL default , `domain` varchar(255) NOT NULL default , `created` datetime NOT NULL default '0000-00-00 00:00:00', `active` tinyint(1) NOT NULL default '1', KEY `username` (`username`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COMMENT='Postfix Admin - Domain Admins';
CREATE TABLE `fetchmail` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`mailbox` varchar(255) NOT NULL,
`src_server` varchar(255) NOT NULL,
`src_auth` enum('password','kerberos_v5','kerberos','kerberos_v4','gssapi','cram-md5','otp','ntlm','msn','ssh','any') DEFAULT NULL,
`src_user` varchar(255) NOT NULL,
`src_password` varchar(255) NOT NULL,
`src_folder` varchar(255) NOT NULL,
`poll_time` int(11) unsigned NOT NULL DEFAULT '10',
`fetchall` tinyint(1) unsigned NOT NULL DEFAULT '0',
`keep` tinyint(1) unsigned NOT NULL DEFAULT '0',
`protocol` enum('POP3','IMAP','POP2','ETRN','AUTO') DEFAULT NULL,
`usessl` tinyint(1) unsigned NOT NULL DEFAULT '0',
`extra_options` text,
`returned_text` text,
`mda` varchar(255) NOT NULL,
`date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
CREATE TABLE `log` ( `timestamp` datetime NOT NULL default '0000-00-00 00:00:00', `username` varchar(255) NOT NULL default , `domain` varchar(255) NOT NULL default , `action` varchar(255) NOT NULL default , `data` varchar(255) NOT NULL default , KEY `timestamp` (`timestamp`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COMMENT='Postfix Admin - Log';
CREATE TABLE `mailbox` ( `username` varchar(255) NOT NULL, `password` varchar(255) NOT NULL, `name` varchar(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL, `maildir` varchar(255) NOT NULL, `quota` bigint(20) NOT NULL DEFAULT '0', `local_part` varchar(255) NOT NULL, `domain` varchar(255) NOT NULL, `created` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', `modified` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', `active` tinyint(1) NOT NULL DEFAULT '1', PRIMARY KEY (`username`), KEY `domain` (`domain`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COMMENT='Postfix Admin - Virtual Mailboxes';
CREATE TABLE `quota` ( `username` varchar(255) CHARACTER SET latin1 NOT NULL, `path` varchar(100) CHARACTER SET latin1 NOT NULL, `current` bigint(20) DEFAULT NULL, PRIMARY KEY (`username`,`path`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8;
CREATE TABLE `quota2` ( `username` varchar(100) CHARACTER SET latin1 NOT NULL, `bytes` bigint(20) NOT NULL DEFAULT '0', `messages` int(11) NOT NULL DEFAULT '0', PRIMARY KEY (`username`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8;
CREATE TABLE `vacation` ( `email` varchar(255) NOT NULL, `subject` varchar(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL, `body` text CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL, `cache` text NOT NULL, `domain` varchar(255) NOT NULL, `created` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', `active` tinyint(1) NOT NULL DEFAULT '1', PRIMARY KEY (`email`), KEY `email` (`email`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 COMMENT='Postfix Admin - Virtual Vacation';
CREATE TABLE `vacation_notification` ( `on_vacation` varchar(255) NOT NULL, `notified` varchar(255) NOT NULL, `notified_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`on_vacation`,`notified`), CONSTRAINT `vacation_notification_pkey` FOREIGN KEY (`on_vacation`) REFERENCES `vacation` (`email`) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=latin1 COMMENT='Postfix Admin - Virtual Vacation Notifications';
Superadministrator
Am Ende der Installationsprozedur wird ein Superadministrator angelegt. Mit diesen Daten kann man sich dann unter http://localhost/postfixadmin/ anmelden.
Damit ist der PostfixAdmin Teil vollständig abgeschlossen. Das Programm übernimmt nur die Verwaltung der angegebenen Datenbanktabellen, mehr macht es nicht. Die Nutzung dieser Datenbanktabellen für das Mailsystem muss über die jeweiligen Programme konfiguriert werden.
Postfix
Postfix ist bei jedem SuSE-System dabei und normalerweise auch installiert. Im Zweifelsfall installiert man Postfix einfach von den Datenträgern nach und konfiguriert es soweit, dass es im normalen Betrieb läuft, also auch Mails von anderen Rechnern annimmt. Wenn man Postfix über YaST konfiguriert (Netzwerkdienste -> Mail Transfer Agent) dann kann man auch gleich AMaVis zur Absicherung des Mailverkehres mit installieren.
Man installiert und konfiguriert dann auch gleich den Virenscanner Clamav mit, wobei man den clamd und freshclam eventuell noch aktivieren muss.
Sollte der clamd nicht starten wollen und die Fehlermeldung
LibClamAV Error: cli_loaddb(): No supported database files found in /var/lib/clamav
liefern, so hilf es als root aufzurufen.
freshclam -v
AMaVis muss nach der Installation noch konfiguriert werden. Dazu muss mindestens in der /etc/amavisd.conf in der vorletzten Zeile die Variable $myhostname gesetzt werden.
Dann gibt es noch ein kleines Problem. AMaVis muss mit dem Clamd kommunizieren können, dazu dienen Sockets. Leider haben beide Programme unterschiedliche Vorgaben in der Konfiguration. Beim Clamd steht in Zeile 76
LocalSocket /var/run/clamav/clamd-socket
Bei Amavis steht
/var/lib/clamav/clamd-socket.sock
An einfachsten ist es die Einstellung beim Clamd zu ändern und ihn dann neu zu starten.
Dummerweise muss man dann die gleich Änderung noch einmal für clamav-milter vornehmen und in der Datei /etc/clamav-milter.conf in Zeile 88 schreiben
ClamdSocket unix:/var/lib/clamav/clamd-socket.sock
Damit Postfix MySQL-Tabellen nutzen kann muss man zusätzlich per YaST das Paket postfix-mysql installieren. Das Paket beinhaltet folgende Dateien:
/etc/postfix/main.cf-mysql /etc/postfix/mysql_relay_domains_maps.cf /etc/postfix/mysql_virtual_alias_maps.cf /etc/postfix/mysql_virtual_domains_maps.cf /etc/postfix/mysql_virtual_mailbox_limit_maps.cf /etc/postfix/mysql_virtual_mailbox_maps.cf /usr/lib/postfix/dict_mysql.so /usr/share/doc/packages/postfix-mysql /usr/share/doc/packages/postfix-mysql/postfix-mysql.sql
Die 5 mysql-Dateien im Verzeichnis /etc/postfix muss man anpassen und weitere Dateien ergänzen, die sich direkt auf die entsprechenden Datenbanktabellen beziehen. Muster dazu finden sich in der Datei /usr/share/doc/packages/postfixadmin/POSTFIX_CONF.txt. Im Prinzip wird Postfix hier mitgeteilt, wie die Datenbanktabellen abgefragt werden. Benutzername und Passwort müssen hier an die eigenen Einstellungen angepasst werden.
mysql_virtual_alias_maps.cf
Die von SuSE mitgelieferten Dateien haben einen Aufbau, der von älteren Beschreibungen abweicht. Die MySQL-Anfrage taucht hier nicht auf, wohl aber ihre Bestandteile:
user = postfix password = postfix hosts = localhost #hosts = 127.0.0.1 dbname = postfix table = alias select_field = goto where_field = address
Die sonst übliche Datei sieht folgendermaßen aus, hier ist direkt die Datenbank-query abgelegt:
user = postfix password = postfix hosts = localhost dbname = postfix query = SELECT goto FROM alias WHERE address='%s' AND active = '1'
mysql_virtual_domains_maps.cf
SuSE-Version
user = postfix password = postfix hosts = localhost #hosts = 127.0.0.1 dbname = postfix table = domain select_field = domain where_field = domain additional_conditions = and backupmx = '0' and active = '1'
Alternative Version.
user = postfix password = postfix hosts = localhost dbname = postfix query = SELECT domain FROM domain WHERE domain='%s' AND active = '1'
Man sieht, dass die SuSE-Version etwas erweitert wurde.
mysql_virtual_mailbox_limit_maps.cf
user = postfix password = postfix hosts = localhost dbname = postfix query = SELECT quota FROM mailbox WHERE username='%s' AND active = '1'
mysql_virtual_mailbox_maps.cf
user = postfix password = postfix hosts = localhost dbname = postfix query = SELECT maildir FROM mailbox WHERE username='%s' AND active = '1'
Die Datei mysql_relay_domains_maps.cf wird in der vorliegenden Konfiguration nicht benutzt.
Dazu kommen die folgenden Maps:
mysql_virtual_alias_domain_maps.cf
user = postfix
password = password
hosts = localhost
dbname = postfix
query = SELECT goto FROM alias,alias_domain WHERE alias_domain.alias_domain = '%d' and alias.address = CONCAT('%u', '@', alias_domain.target_domain) AND alias.active = 1 AND alias_domain.active='1'
mysql_virtual_alias_domain_catchall_maps.cf:
# handles catch-all settings of target-domain
user = postfix
password = password
hosts = localhost
dbname = postfix
query = SELECT goto FROM alias,alias_domain WHERE alias_domain.alias_domain = '%d' and alias.address = CONCAT('@', alias_domain.target_domain) AND alias.active = 1 AND alias_domain.active='1'
mysql_virtual_alias_domain_mailbox_maps.cf:
user = postfix
password = password
hosts = localhost
dbname = postfix
query = SELECT maildir FROM mailbox,alias_domain WHERE alias_domain.alias_domain = '%d' and mailbox.username = CONCAT('%u', '@', alias_domain.target_domain) AND mailbox.active = 1 AND alias_domain.active='1'
main.cf
Nun muss noch die main.cf von Postfix erweitert werden, damit die Tabellen auch benutzt werden. Mit dieser Erweiterung erfolgt der erste Eingriff ins System. Zuerst zwei kleine Änderung an der Datei /etc/sysconfig/postfix:
POSTFIX_MYHOSTNAME="server.netthelp.de" (Zeile 44)
Hier sollte man nicht den von Strato zugeteilten Namen angeben, da man dann leicht für ein System mit dynamischer IP-Adresse gehalten wird. Man sollte hier einen Namen aus einer eigenen Domain angeben und dann in der Strato-Konfiguration den auch als Namen für die IP-Adresse einstellen lassen.
POSTFIX_SMTP_AUTH_SERVER="yes" (Zeile 338)
Die folgenden zwei Zeilen sollte man anpassen, wenn die Testphase vorbei ist, damit Spammern das Leben erschwert wird.
POSTFIX_RBL_HOSTS="cbl.abuseat.org, dnsbl.sorbs.net, dnsbl.ahbl.org, bl.spamcop.net " (Zeile 198)
POSTFIX_BASIC_SPAM_PREVENTION="hard" (zeile 231)
Im Idealfall erweitert man dann die Datei /etc/sysconfig/postfix um die notwendigen Zeilen und ruft dann SuSEconfig auf. Früher ging das per SuSeconfig --module auf, bei OpenSuSE 12.2 liegt das entsprechende Modul nicht mehr in /sbin/conf.d, man muss es also direkt aufrufen per SuSEconfig.postfix oder /usr/sbin/SuSEconfig.postfix.
Ab OpenSUSE 12.3 ist das Tool unter /usr/sbin/config.postfix zu finden.
Hier das Ende meiner /etc/sysconfig/postfix Datei, die ersten Zeilen waren schon vorhanden:
## Type: string ## Default: 0 POSTFIX_ADD_MAILBOX_SIZE_LIMIT="0" ## Type: string ## Default: 10240000 POSTFIX_ADD_MESSAGE_SIZE_LIMIT="0" ## Type: yesno ## Default: yes ## Config: postfix # # Automatically register to slpd, if running? # POSTFIX_REGISTER_SLP="yes" ## Type: list(subnet,host,class) ## Default: subnet ## Config: postfix # # # The postfix default for this setting is "subnet" # for security reasons you should use host # otherwise every user in the same subnet as you, can use # your postfix server as a mail relay for spam. # If you set POSTFIX_DIALUP to "yes" mynetworks_style # will be set to "host" by SuSEconfig. # POSTFIX_ADD_MYNETWORKS_STYLE="subnet" POSTFIX_NODAEMON="no" # Ab hier Konfiguration fuer virtuelle Domains ## Type: string ## Default: "noanonymous" POSTFIX_ADD_SMTPD_SASL_SECURITY_OPTIONS="noanonymous" ## Type: string ## Default: "yes" POSTFIX_ADD_BROKEN_SASL_AUTH_CLIENTS="yes" ## Type: string ## Default: "\$myhostname" POSTFIX_ADD_SMTPD_SASL_LOCAL_DOMAIN="" ## Type: string ## Default: "" POSTFIX_ADD_VIRTUAL_ALIAS_MAPS="hash:/etc/postfix/virtual, proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf, proxy:mysql:/etc/postfix/mysql_virtual_alias_domain_maps.cf, proxy:mysql:/etc/postfix/mysql_virtual_alias_domain_catchall_maps.cf" ## Type: string ## Default: "" POSTFIX_ADD_VIRTUAL_GID_MAPS="static:303" ## Type: string ## Default: "" POSTFIX_ADD_VIRTUAL_MAILBOX_BASE="/var/vmail/" ## Type: string ## Default: "" POSTFIX_ADD_VIRTUAL_MAILBOX_DOMAINS="proxy:mysql:/etc/postfix/mysql_virtual_domains_maps.cf" ## Type: string ## Default: "" POSTFIX_ADD_VIRTUAL_MAILBOX_LIMIT="0" ## Type: string ## Default: "" POSTFIX_ADD_VIRTUAL_MAILBOX_MAPS="proxy:mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf, proxy:mysql:/etc/postfix/mysql_virtual_alias_domain_mailbox_maps.cf" ## Type: string ## Default: "" POSTFIX_ADD_VIRTUAL_MINIMUM_UID="303" ## Type: string ## Default: "" POSTFIX_ADD_VIRTUAL_TRANSPORT="virtual" ## Type: string ## Default: "" POSTFIX_ADD_VIRTUAL_UID_MAPS="static:303" ## Type: string ## Default: "" POSTFIX_ADD_SMTPD_SASL_TYPE="dovecot" ## Type: string ## Default: "" POSTFIX_ADD_SMTPD_SASL_PATH="private/auth"
Die letzten beiden Schalter sind wichtig, wenn man die SASL-Authentifikation mittels Dovecot durchführen will.
SuSEconfig hängt dann folgende Zeilen an die main.cf an:
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks,reject_unauth_destination smtp_sasl_auth_enable = no smtpd_sasl_auth_enable = yes smtpd_use_tls = no smtp_use_tls = no smtp_enforce_tls = no alias_maps = hash:/etc/aliases broken_sasl_auth_clients = yes mailbox_size_limit = 0 message_size_limit = 0 smtpd_sasl_local_domain = smtpd_sasl_security_options = noanonymous virtual_alias_maps = hash:/etc/postfix/virtual, proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf, proxy:mysql:/etc/postfix/mysql_virtual_alias_domain_maps.cf, proxy:mysql:/etc/postfix/mysql_virtual_alias_domain_catchall_maps.cf virtual_gid_maps = static:303 virtual_mailbox_base = /var/vmail/ virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql_virtual_domains_maps.cf virtual_mailbox_limit = 0 virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf, proxy:mysql:/etc/postfix/mysql_virtual_alias_domain_mailbox_maps.cf virtual_minimum_uid = 303 virtual_transport = virtual virtual_uid_maps = static:303 smtpd_sasl_type = dovecot smtpd_sasl_path = private/auth
Kontrollieren muss man dann noch, ob auch folgende Zeile in der main.cf auftaucht:
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination,
Die Zahlen 303 stehen hier übrigens für uid und gid des Vmail-Eigentümers. Die meisten Beschreibungen gehen davon aus, dass man sich einen User vmail mit den entsprchenden Daten anlegt. Die Zahlen sind beliebig, tauchen aber auch später immer wieder auf.
Hinweis: Es gibt noch ein kleines Problem. Das Script /usr/sbin/SuSEconfig.postfix bzw. /usr/sbin/config.postfix (eine Mischung aus Shell- und Perl-Code) hat auch in der aktuellen Version eine blöde Macke, ab Zeile 669 findet sich eine Schleife, mit der die bereits erzeugt Konfigurationsdatei noch einmal bearbeitet wird.
while( <MNCF> ) {
chomp;
if( /\#?(virtual_alias_maps\s=\s).*/ ) {
if ($with_mysql ne "yes" && $with_ldap ne "yes") {
$line = $1."hash:/etc/postfix/virtual";
} elsif ($with_ldap eq "yes" && $with_mysql ne "yes") {
$line = $1."hash:/etc/postfix/virtual ldap:/etc/postfix/ldap_aliases.cf";
} elsif ($with_mysql eq "yes" && $with_ldap ne "yes") {
$line = $1."hash:/etc/postfix/virtual mysql:/etc/postfix/mysql_virtual_alias_maps.cf";
} elsif ($with_mysql eq "yes" && $with_ldap eq "yes") {
$line = $1."hash:/etc/postfix/virtual ldap:/etc/postfix/ldap_aliases.cf mysql:/etc/postfix/mysql_virtual_alias_maps.cf";
}
} elsif( /\#?(virtual_uid_maps\s=.*)/ ) {
if ($with_mysql ne "yes") {
$line = "#".$1;
} else {
$line = $1;
}
...
} else {
$line = $_;
}
if( $line =~ /^\#/ ) {
print $line."\n";
next;
}
print $line."\n";
Leider hat der erste Teil den Effekt, dass die Einstellungen aus /etc/sysconfig/postfix für virtual_alias_maps verloren gehen. Ich habe dafür keine saubere Lösung gefunden. Entweder korrigiert man die erzeugte main.cf per Hand, oder man verändert das erwähnte Script. Im Prinzip kann der ganze Teil wegfallen, es geht immer nur um die virtual_... Einstellungen, die wir sowieso unabhängig machen.
Entweder ändere ich im oberen Bereich die Zuweisung, oder hinter dem else-Fall ergänze ich einfach $line = $_; dann wird das Ergebnis der Überarbeitung ignoriert. Die zweite Lösung erscheint mir am einfachsten. Dann endet der Abschnitt auf:
...
} else {
$line = $_;
}
# geändert von Uwe Debacher am 9.10.2011
$line = $_;
if( $line =~ /^\#/ ) {
print $line."\n";
next;
}
print $line."\n";
SuSEconfig meutert, wenn man selber an der main.cf Hand angelegt hat und erstellt eine eigene Datei mit der neuen Version. Die kopiert man über die main.cf und löscht dann die zusätzliche Datei.
cp main.cf.SuSEconfig main.cf rm main.cf.SuSEconfig
Nun sollte SuSEconfig in Zukunft sauber durchlaufen.
/usr/sbin/SuSEconfig.postfix
bzw.
/usr/sbin/config.postfix
Nach einem Neustart von Postfix sollte es möglich sein Mails für die virtuellen Benutzer zu schicken, die in der Datenbank eingetragen sind.
Die virtuellen Postfächer liegen alle unterhalb von /var/vmail.
Wo genau sie liegen stellt man über die Konfigurationsdatei des PostfixAdmin ein. Entscheidend sind hier die Zeilen:
// Mailboxes // If you want to store the mailboxes per domain set this to 'YES'. // Example: /usr/local/virtual/domain.tld/username@domain.tld $CONF['domain_path'] = 'NO'; // If you don't want to have the domain in your mailbox set this to 'NO'. // Example: /usr/local/virtual/domain.tld/username $CONF['domain_in_mailbox'] = 'YES';
Es macht Sinn diese beiden Vorgaben zu ändern, wenn man mit mehreren Domains arbeitet.
Damit ist die Postfix-Konfiguration erst einmal abgeschlossen und sowohl Systembenutzer, als auch virtuelle Benutzer können Mails empfangen. Weitere Schritte sind erst notwendig, wenn auch Mailman aktiviert werden soll.
Hinweis: In der Datei /etc/sysconfig/postfix sollte man nicht die Einstellung
POSTFIX_MDA="local"
auf dovecot verändern. Dann werden Mails für lokale Benutzer nicht mehr zugestellt, z.B. für root und die Mailinglisten.
Dovecot
Bei Konfigurationsbeschreibungen für Dovecot muss man immer aufpassen, auf welche Version sie sich beziehen. Es gibt erhebliche Unterschiede zwischen den Konfigurationen von 1.x und 2.x. Die folgenden Texte beziehen sich auf Version 2.1.7.
Die Angabe einer mail_location hat anscheinend nur für die Systembenutzer eine Funktion, nicht für die virtuellen Benutzer. Insofern kann es unterbleiben hier überhaupt eine Angabe zu machen, dann sucht Dovecot für die Systembenutzer den richtigen Ort heraus.
An die von SuSE mitgelieferten Dateien soll man ja nicht unnötig herangehen, damit Änderungen bei Updates nicht verloren gehen. In der dovecot.conf wird genau für die eigenen Änderungen am Ende eine Datei local.conf gesucht und falls vorhanden mit eingelesen. Hier kann man seine eigenen Elemente dann risikolos unterbringen.
Wenn keine Zertifikate erzeugt wurden, also verschlüsselte Verbindungen nicht möglich sind, dann funktioniert folgende einfach Version von /etc/dovecot/local.conf.
disable_plaintext_auth = no
first_valid_uid = 303
mail_access_groups = postfix
mail_privileged_group = postfix
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date
passdb {
args = /etc/dovecot/dovecot-mysql.conf
driver = sql
}
passdb {
driver = pam
}
plugin {
sieve = ~/.dovecot.sieve
sieve_dir = ~/sieve
}
protocols = imap pop3
ssl = no
userdb {
args = /etc/dovecot/dovecot-mysql.conf
driver = sql
}
userdb {
driver = passwd
}
verbose_proctitle = yes
protocol pop3 {
pop3_uidl_format = %08Xu%08Xv
}
Die zugehörige Datei /etc/dovecot/dovecot-mysql.conf besitzt folgenden Inhalt:
# Database driver: mysql, pgsql
driver = mysql
# Currently supported schemes include PLAIN, PLAIN-MD5, DIGEST-MD5, and CRYPT.
default_pass_scheme = CRYPT
# Database options
#db_unix_socket = /var/lib/mysql/mysql.sock
connect = host=/var/run/mysql/mysql.sock dbname=postfix user=postfix password=assword
password_query = SELECT password FROM mailbox WHERE username = '%u' AND active = '1'
user_query = SELECT concat('maildir:/var/vmail/',maildir) as mail, 303 AS uid, 303 AS gid FROM mailbox WHERE username = '%u' AND active = '1'
Dovecot mit SSL
Will man mit Dovecot auch SSl-Verbindungen nutzen, so sind mehrere Schritte notwendig. Zuerst braucht man ein Zertifikat, wenn man dafür keinen Anbieter hat, dann kann man ein Zertifikat selbst erstellen, mit den dabei anfallenden Einschränkungen und Problemen.
Im Ordner /usr/share/doc/packages/dovecot/ findet man die dafür notwendigen Dateien. Zuerst muss man die Konfigurationsdatei dovecot-openssl.cnf anpassen. Dann kann man die Zertifikate erzeugen mittels
sh mkcert.sh
Nun muss noch die Dovecot-Konfiguration in /etc/dovecot/local.conf angepasst werden.
disable_plaintext_auth = no
first_valid_uid = 303
mail_access_groups = postfix
mail_privileged_group = postfix
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date
passdb {
args = /etc/dovecot/dovecot-mysql.conf
driver = sql
}
passdb {
driver = pam
}
plugin {
sieve = ~/.dovecot.sieve
sieve_dir = ~/sieve
}
protocols = imap pop3
ssl = yes
ssl_cert = </etc/ssl/certs/dovecot.pem
ssl_key = </etc/ssl/private/dovecot.pem
userdb {
args = /etc/dovecot/dovecot-mysql.conf
driver = sql
}
userdb {
driver = passwd
}
verbose_proctitle = yes
protocol pop3 {
pop3_uidl_format = %08Xu%08Xv
}
Nach einem Dovecot-Neustart kann man mittels
openssl s_client -connect imap.debacher.com:pop3s
testen, ob die Einstellungen funktionieren.
Nun muss der Client aber auch noch dieses Zertifikat akzeptieren, das hängt aber von der jeweiligen Anwendung ab. Bei fetchmail muss man sich den Fingerprint des Zertifikates holen. Dazu muss man fetchmail mit dem Parameter -v (Verbose) starten. Dann findet man in der /var/log/mail.info eine Zeile wie:
Feb 5 17:13:59 acer-server fetchmail[17975]: imap.debacher.de-Schlüssel-Fingerabdruck: 59:51:61:89:CD:DD:B2:35:94:BB:44:97:A0:39:D5:B4
Die Zeichenkette am Ende wird benötigt und in die /etc/fetchmailrc aufgenommen:
poll imap.debacher.com with proto POP3 user 'uwe@meine-maildomain.de' there with password 'assword' ssl sslfingerprint "59:51:61:89:CD:DD:B2:35:94:BB:44:97:A0:39:D5:B4" is debacher here
Jetzt ist eine gesicherte Verbindung möglich, ohne dass Fetchmail meckert.
Dovecot und Apparmor
Ein Problem gibt es beim Start von Dovecot. Das vorinstallierte Apparmor ist anscheinend nicht passen konfiguriert und Dovecot liefert eine Fehlermeldung wie
Starting dovecot Fatal: execv(/usr/bin/doveconf) failed: No such file or directory
Erst ein Deaktivieren von apparmor lässt den Start von Dovecot zu. Danach kann man dann apparmor auch wieder starten.
Anpassung der Dovecot.conf
Aktuell habe ich ein paar Änderungen an der Konfiguration vorgenommen.
disable_plaintext_auth = no
first_valid_uid = 303
mail_access_groups = postfix
mail_privileged_group = postfix
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date
passdb {
args = /etc/dovecot/dovecot-mysql.conf
driver = sql
}
#passdb {
# driver = pam
#}
plugin {
sieve = ~/.dovecot.sieve
sieve_dir = ~/sieve
}
protocols = imap pop3
ssl = yes
ssl_cert = </etc/ssl/certs/dovecot.pem
ssl_key = </etc/ssl/private/dovecot.pem
userdb {
args = /etc/dovecot/dovecot-mysql.conf
driver = sql
}
#userdb {
# driver = passwd
#}
verbose_proctitle = yes
protocol pop3 {
pop3_uidl_format = %08Xu%08Xv
mail_max_userip_connections = 5
}
protocol imap {
mail_max_userip_connections = 5
}
Ich habe hier vor allem die normale Authentifizierung gegenüber der Passwort-Datenbank entfernt, da ich keine lokalen Benutzer habe. Das erspart Fehlermeldungen, da ansonsten auch für die virtuellen User immer noch einmal die lokale Authentifizierung probiert wird, was jeweils zu einer Fehlermeldung führen muss.
Zusätzlich hatte ich Probleme damit, das vor allem jüngere Nutzer, z.T. große Anzahlen von gleichzeitigen Verbindungen zum IMAP-Server aufbauen. Das betrifft vor allem die Geräte mit dem angebissenen Apfel. Ich habe also die Zahl der erlaubten parallelen Verbindungen pro IP-Adresse auf 5 reduziert.
SASL
Soll der Rechner auch Mails von virtuellen Benutzern über das Netz annehmen, so muss der Benutzer eine Möglichkeit haben sich beim Abliefern der Mails zu authentifizieren. Dazu dient in der Regel der Simple Authentication and Security Layer (SASL). Für die Konfiguration gibt es mehrere Möglichkeiten.
Die einfachste Möglichkeit ist die Nutzung des SASL-Moduls von Dovecot. Dann muss man den Datenbankzugriff nur an einer einzigen Stelle konfigurieren, nämlich bei Dovecot.
Für die SASL-Nutzung ergänzt man einfach die /etc/dovecot/local.conf um die folgenden Zeilen.
service auth {
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0660
user = postfix
}
}
auth_mechanisms = plain login
Über das Netz kann man eine Telnet-Verbindung nutzen um zu testen, mann muss nur vorher die Anmeldedaten Base64 kodieren mit:
perl -MMIME::Base64 -e 'print encode_base64("benutzer\@virt.domain\0benutzer\@virt.domain\0passwort");'
Dann kann man einen Telnet auf Port 25 machen, nach
EHLO <Absender-Domain>
gibt man in der nächsten Zeile an:
auth plain <codiertes Passwort>
SuSEconfig meckert übrigens, wenn der saslauthd nicht läuft.
You are using saslauthd as pwcheck_method in /etc/sasl2/smtpd.conf, but saslauthd is not running.
das ist ein Fehler im Script /usr/sbin/SuSEconfig.postfix, das schaut nur nach, ob es die Datei /etc/sasl2/smtpd.conf oder /usr/lib64/sasl2/smtpd.conf gibt und wenn ja, ob da die Zeichenkette saslauthd zu finden ist. Wenn es die findet und der Dämon nicht läuft, dann erzeugt es die Fehlermeldung. Ein Auskommentieren hilft also nichts, wohl aber ein Leerzeichen im Wort s aslauthd
Sollte die SASL-Anmeldung fehlschlagen und die Logdateien nichts hergeben, so kann man auch die MySQL-Datenbank mit zusätzlichen Informationen starten. Zuerst beendet man sie und startet sie dann direkt mit zusätzlichem Parameter:
rcmysql stop /bin/sh /usr/bin/mysqld_safe --user=mysql --pid-file=/var/run/mysql/mysqld.pid --socket=/var/run/mysql/mysql.sock --datadir=/var/lib/mysql --log=/var/lib/mysql/sasl-informationen.log --log-long-format &
Roundcube
Hierbei handelt es sich um ein nettes Webinterface für das Mailsystem. Man muss nur das Paket roudcubemail mittels YaST nachinstallieren.
yast2 -i roundcubemail
Die Webkonfiguration sollte man dann etwas anpassen, wie oben bereits beschrieben, damit andere Programme nicht in Schwierigkeiten kommen.
Ansonsten ist die Konfiguration recht einfach. Man legt eine Datenbank roundcubemail an und einen passenden Benutzer, z.B. roundcube mit dem Password assword.
mysql roundcubemail -u roundcube -p < /usr/share/doc/packages/roundcubemail/SQL/mysql.initial.sql
Bei OpenSUSE 12.3 ist der Pfad geändert
mysql roundcubemail -u roundcube -p < /srv/www/roundcubemail/SQL/mysql.initial.sql
Anschließend müssen noch ein paar Einstellungen an den Dateien in /etc/roundcubemail vorgenommen werden.
db.inc.php
$rcmail_config['db_dsnw'] = 'mysql://roundcube:assword@localhost/roundcubemail';
db.inc.php.dist
$rcmail_config['db_dsnw'] = 'mysql://roundcube:assword@localhost/roundcubemail';
main.inc.php (dann verschindet die Server-Zeile im Anmeldefenster)
$rcmail_config['default_host'] = 'localhost';
Neuerdings gibt es etwas Probleme bei der Installation von Roundcube. Im Suse-Rpository ist jetzt die Version 0.8.6-3.12.1. Dies Version ist abhängig vom Modul php5-intl, das auch mitinstalliert wird. Leider ist das Modul nicht in Ordnung und muss deaktiviert werden, damit der Apache ohne Fehlermeldungen startet. Eine saubere Lösung, ohne das komplette PHP-System zu aktualisieren habe ich bisher nicht gefunden.
Group-Office
Group-Office ist ein sehr umfangreiches Webinterface für das Mailsystem und bietet vom Kalender über das Adressbuch nahezu alles, was man so haben möchte. Zur Installation lädt man sich das tar-Archiv: http://downloads.sourceforge.net/project/group-office/4.1/groupoffice-com-4.1.73.tar.gz oder auch aktueller http://sourceforge.net/projects/group-office/files/5.0/groupoffice-com-5.0.26.tar.gz und entpackt es in das Verzeichnis /srv/www/htdocs und benennt es anschließend in groupoffice um:
cd /srv/www/htdocs tar xvfz /tmp/groupoffice-com-4.1.73.tar.gz mv groupoffice-com-4.1.73 groupoffice
Danach muss man dann noch eine leere config.php anlegen
cd groupoffice touch config.php chown wwwrun.www config.php
Nun noch mittels z.B. phpMyAdmin eine Datenbank und den zugehörigen Benutzer anlegen, dann kann die Installation starten. Dazu ruft man groupoffice im Browser auf, wodurch das Installations-Script startet.
Groupoffice benötigt normalerweise die zusätzlichen Pakete libwbxml2, zip und tnef.
Wenn alle Erfordernisse erfüllt sind, dann kann man sich Schritt für Schritt durch die Installation hangeln. Am Ende des Prozesses wird ein Administrator-Zugang angelegt.
Danach erfolgt dann noch eine Auswahl der Module, die für Benutzer zur Verfügung stehen sollen. Diese Auswahl kann man aber auch später noch verändern. Wichtig ist jetzt, dass man sich einmal als Administrator anmeldet, um die IMAP-Authentifizierung nachinstallieren zu können.
Danach muss man dann noch die Konfigurationsdatei in das groupoffice-Verzeichnis kopieren
cd groupoffice cp modules/imapauth/imapauth.config.php.example imapauth.config.php
Danach erfolgt dann die Benutzer-Authentifizierung gegen den IMAP-Server, so dass keine zusätzliche Benutzerverwaltung notwendig ist. Jeder Benutzer, der sich per IMAP anmelden kann wird automatisch auch als Group-Office Benutzer eingerichtet.
Etwas aufpassen muss man mit den Eingaben in die Datei imapauth.config.php. Leerzeichen haben hier unerwünschte Effekte.
'imapauth_combo_domains' => 'debacher.de,debacher.name,debacher.com'
setzt man hier nach dem Komma Leerzeichen, so stehen die später auch nach dem Klammeraffen, mit unerwünschten Effekten.
VsFTPd und virtuelle Nutzer
Installation des Dienstes mittels:
yast2 -i vsftpd
Der VsFTPd kann prinzipiell mit virtuellen Nutzern arbeiten, er kann aber nicht direkt auf eine MySQL-Datenbank zugreifen. Das geht nur indirekt über ein entsprechendes PAM-Modul.
Das pam_mysql mit dem Quelltext von Sourceforge (bei mir war die Version 0.7 aktuell) ist leider nicht mehr brauchbar. Mit der aktuellen OpenSUSE-Version habe ich das Problem, dass das Modul nicht fehlerfrei funktioniert. Ich kann es zwar compilieren und installieren, es gibt bei Anmeldeversuchen immer
libgcc_s.so.1 must be installed..
In der /var/log/messages ist dann eine Fehlermeldung zu finden wie
general protection ip:7f571a1b3287 sp:7f57161fa590 error:0 in libc-2.15.so
Mit der Datei von der vorherigen Version klappt alles. Es hat anscheinend mit den pthreads zu tun.
Die Probleme tauchten auch mit den diversen vorcompilierten Versionen auf. Zum Glück ist das Modul für die Nutzung von virtuellen Nutzern nicht mehr wesentlich, da Dovecot die notwendigen Funktionen mitbringt.
Ich habe lange Zeit überlegt auf FTP-Server auszuweichen, die eine Datenbankanbindung mitbringen wir ProFTPD oder PureFTPD, doch der Mensch ist ein Gewohnheitstier.
Eine Ausweichmöglichkeit ist die Authentifikation gegen gegen IMAP oder POP3 mittels PAM. Das Modul pam_pop3 ließ sich nicht übersetzen, es ist ja auch recht alt. Auch nicht viel neuer, aber compilierbar und funktionsfähig ist das Paket pam_imap von http://downloads.sourceforge.net/project/pam-imap/pam-imap/pam_imap-0.3.8/pam_imap-0.3.8.tar.bz2.
Anfangs wollte sich auch dieses Paket nicht übersetzen lassen, es gab immer Fehlermeldungen mit PIC. Um dies zu unterbinden muss man einfach die Umgebungsvariablen CC und CXX passend setzen und dann erst die Installation starten:
export CC="gcc -fPIC" export CXX="g++ -fPIC" make distclean; make clean ./configure make cp pam_imap.so /lib64/security/
Jetzt muss nur noch die Datei /etc/pam.d/vsftp angepasst werden.
#%PAM-1.0 # ergaenzt am 28.5.2013 auth sufficient pam_imap.so conf=/etc/pam.d/pam_imap.conf account sufficient pam_imap.so conf=/etc/pam.d/pam_imap.conf # Uncomment this to achieve what used to be ftpd -A. # auth required pam_listfile.so item=user sense=allow file=/etc/ftpchroot onerr=fail auth required pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed # Uncomment the following line for anonymous ftp. #auth sufficient pam_ftp.so auth required pam_shells.so auth include common-auth account include common-account password include common-password session required pam_loginuid.so session include common-session
Neu sind hier nur die Zeilen 2 bis 4, der Rest ist die Standardkonfiguration.
Zusätzlich muss noch aus dem Verzeichnis conf die Datei pam_imap.conf nach /etc/pam.d/ kopiert werden. In dieser Datei habe ich dann auch noch den Port angepasst:
#PAM_Server0 = imaps:localhost:993 PAM_Server0 = localhost:143
bei lokaler Authentifizierung kann ich auf die Verschlüsselung verzichten.
Neue vsftpd Probleme bei OpenSUSE 12.3
Beim Anmelden erscheint die Fehlermeldung
500 OOPS: vsftpd: refusing to run with writable root inside chroot()
oder
500 OOPS: priv_sock_get_cmd
Ich konnte dann finden, dass an neuen Sicherheitseinstellungen liegt und sich mit einer Erweiterung der /etc/vsftpd.conf lösen lässt
allow_writeable_chroot=YES seccomp_sandbox=NO
apache
In der Datei /etc/sysconfig/apache muss noch das Modul rewrite eventuell aktiviert werden. Entweder mittels
a2enmod rewrite
oder direkt mit einem Editor.
# EXAMPLES: # # fairly minimal # APACHE_MODULES="authz_host alias auth dir log_config mime setenvif" # # apache's default installation # APACHE_MODULES="authz_host actions alias asis auth autoindex cgi dir imap include log_config mime negotiation setenvif status userdir" # your settings APACHE_MODULES="authz_host actions alias auth_basic authz_groupfile authn_file authz_user autoindex cgi dir include log_config mime negotiation setenvif status userdir asis imagemap php5 authz_default rewrite"
nach einem Neustart des Apache steht dann auch dieses Modul zur Verfügung.
Die weitere Konfiguration für virtuelle Server basiert auf mehreren Dateien.
In der Datei /etc/apache2/listen.conf sollten die folgenden Zeilen aktiv sein.
Listen 80
<IfDefine SSL>
<IfDefine !NOSSL>
<IfModule mod_ssl.c>
Listen 443
NameVirtualHost *:443
</IfModule>
</IfDefine>
</IfDefine>
NameVirtualHost *:80
Im Verzeichnis /etc/apache2/vhosts.d legt man sich eine Datei _default.conf an, die die Voreinstellungen für die virtuellen Domains beinhaltet und dann für jeden der virtuellen Server eine eigene Konfigurationsdatei.
squirrelmail
Dieses Webmail-Programm wirkt etwas hausbacken, ist aber sehr gutmütig und läuft sofort.
yast2 -i squirrelmail-beta squirrelmail-beta-lang
Man kann kann noch etwas an den Einstellungen drehen, vor allem an den Spracheinstellungen. Dazu gibt es zwei Dateien im Unterverzeichnis config nämlich
- config.php für die allgemeinen Einstellungen
- config_default.php für die Vorgaben für neue Benutzer
Die Datei config.php muss man nicht direkt bearbeiten, dafür ist im gleichen Verzeichnis das Script conf.pl zuständig.
majordomo - approve
Bei OpenSUSE 12.2 ist das Paket majordomo nicht mehr dabei. Man kann aber problemlos das Paket von 12.1 installieren, das es z.B. unter ftp://bo.mirror.garr.it/pub/1/opensuse/distribution/12.1/repo/oss/suse/x86_64/majordomo-1.94.5-469.1.2.x86_64.rpm gibt.
In den aktuellen Perl-Versionen läuft die Majordomo-Komponente approve nicht mehr. Das liegt an den Eigenschaften von split:
sub read_config {
local($l);
local($p);
local($m);
local($s);
open(CONF, $opt_f) || die("open(CONF, \"$opt_f\"): $!");
while (<CONF>) {
s/\n$//;
s/#.*//;
if (/^$/) { next; }
split;
$l = $_[0]; $l =~ tr/A-Z/a-z/; # list
$p = $_[1]; # password
$m = $_[2]; $m =~ tr/A-Z/a-z/; # majordomo@site
split(/\@/, $m);
$s = $_[1]; $s =~ tr/A-Z/a-z/; # site
$passwd{$l} = $p;
$passwd{"$l\@$m"} = $p;
$passwd{"$l\@$s"} = $p;
if (defined($site{$l})) {
# if it's already defined, there's more than one list by this name
$site{$l} = "MULTIPLE";
} else {
$site{$l} = $s;
}
}
close(CONF);
}
Hier wird mehrfach split in einem Void-Kontext benutzt und davon ausgegangen, dass das Ergebnis dann in @_ untergebracht wird. Das ist leider nicht mehr der Fall. Ändert man die Funktion entsprechend klappt approve auch wieder:
sub read_config {
local($l);
local($p);
local($m);
local($s);
open(CONF, $opt_f) || die("open(CONF, \"$opt_f\"): $!");
while (<CONF>) {
s/\n$//;
s/#.*//;
if (/^$/) { next; }
@sp=split;
$l = $sp[0]; $l =~ tr/A-Z/a-z/; # list
$p = $sp[1]; # password
$m = $sp[2]; $m =~ tr/A-Z/a-z/; # majordomo@site
@sp=split(/\@/, $m);
$s = $sp[1]; $s =~ tr/A-Z/a-z/; # site
$passwd{$l} = $p;
$passwd{"$l\@$m"} = $p;
$passwd{"$l\@$s"} = $p;
if (defined($site{$l})) {
# if it's already defined, there's more than one list by this name
$site{$l} = "MULTIPLE";
} else {
$site{$l} = $s;
}
}
close(CONF);
}
mailman
Mich hat überrascht, wie mühsam es ist eine Beschreibung zu finden, wie man mailman mit virtuellen Postfix-Mail verknüpft. Die hier beschriebene Konfiguration lässt einen Mailinglisten-Namen nur einmalig über alle Domains zu. Wenn es also eine Liste info@virtual1.tld gibt, dann ist es nicht möglich ebenfalls info@virtual2.tld einzurichten.
Weitere Informationen unter:
- http://list.org/mailman-install/postfix-virtual.html
- http://hilfedatenbank.de/2009/01/28/mailman-einrichten/
- http://www.gentoo.org/doc/de/virt-mail-howto.xml#doc_chap12
- https://wiki.archlinux.org/index.php/Mailman
Zuerst muss man den Mailman installieren, per
yast2 -i mailman
dann muss man ihn in der Apache-Konfiguration aktivieren:
In der Datei /etc/sysconfig/apache2 muss der Parameter MAILMAN den APACHE_SERVER_FLAGS hinzugefügt werden, zum Beispiel so:
APACHE_SERVER_FLAGS="SSL MAILMAN"
oder einfacher mittels:
a2enflag MAILMAN
damit wird der Eintrag ebenfalls erstellt. Danach den Apache neu starten.
Eine Änderung erfolgt in der Datei /etc/postfix/main.cf dort muss die Zeile
alias_maps = hash:/etc/aliases
erweitert werden zu
alias_maps = hash:/etc/aliases, hash:/var/lib/mailman/data/aliases
damit die Alias-Einträge vom Mailman berücksichtigt werden. Zusätzlich muss für die virtuellen Domains der Eintrag virtual_alias_maps erweitert werden zu
virtual_alias_maps = hash:/etc/postfix/virtual, hash:/var/lib/mailman/data/virtual-mailman, proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf, proxy:mysql:/etc/postfix/mysql_virtual_alias_domain_maps.cf, proxy:mysql:/etc/postfix/mysql_virtual_alias_domain_catchall_maps.cf
Der Eintrag kann über eine Erweiterung der Datei /etc/sysconfig/postfix realisiert werden:
POSTFIX_ADD_ALIAS_MAPS="hash:/etc/aliases, hash:/var/lib/mailman/data/aliases"
und
POSTFIX_ADD_VIRTUAL_ALIAS_MAPS="hash:/etc/postfix/virtual, hash:/var/lib/mailman/data/virtual-mailman, proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf, proxy:mysql:/etc/postfix/mysql_virtual_alias_domain_maps.cf, proxy:mysql:/etc/postfix/mysql_virtual_alias_domain_catchall_maps.cf"
Natürlich muss man dann mittels /usr/sbin/config.postfix die main.cf neu erzeugen lassen.
Nun legt man das Site-Kennwort fest mit
/usr/lib/mailman/bin/mmsitepass
In der Datei /usr/lib/mailman/Mailman/mm_cfg.py finden sich einige Grundeinstellungen für den Mailman, die man mit einem Texteditor vornehmen kann, weitere Standardvorgaben findet man in der Datei /usr/lib/mailman/Mailman/Defaults.py.
Also ergänzen wir ein paar Zeilen in der Datei /usr/lib/mailman/Mailman/mm_cfg.py:
##################################################
# Put YOUR site-specific settings below this line.
DEFAULT_SERVER_LANGUAGE = 'de'
DEFAULT_ARCHIVE = Off
DEFAULT_ARCHIVE_PRIVATE = 1
SMTP_MAX_RCPTS = 500
DEFAULT_URL_HOST = 'myserver.tld'
DEFAULT_EMAIL_HOST = 'myserver.tld'
add_virtualhost('virtual1.tld', 'virtual2.tld')
add_virtualhost('virtual2.tld', 'virtual2.tld')
MTA = 'Postfix'
POSTFIX_STYLE_VIRTUAL_DOMAINS = ['virtual1.tld', 'virtual2.tld']
DEFAULT_REQUIRE_EXPLICIT_DESTINATION = No
Jetzt legt man noch die notwendige Standard-Mailingliste "mailman" an mittels
/usr/lib/mailman/bin/newlist -l de mailman postmaster@myserver.tld passwort
Dann kann man den Dienst starten:
systemctl start mailman.service
und dann auch veranlassen, dass er zukünftig automatisch gestartet wird
systemctl enable mailman.service
Wichtig ist jetzt und beim Neuanlegen einer Mailingliste immer ein Blick in das Verzeichnis /var/lib/mailman/data, hier müssen vier Dateien mit aktuellem Zeitstempel auftauchen:
-rw-rw-r-- 1 mailman mailman 2576 14. Jul 12:00 aliases -rw-rw-r-- 1 mailman mailman 12288 14. Jul 12:00 aliases.db -rw-rw---- 1 root mailman 1654 14. Jul 12:00 virtual-mailman -rw-r----- 1 root mailman 12288 14. Jul 12:00 virtual-mailman.db
Diese Dateien werden automatisch erzeugt vom Programm /usr/lib/mailman/bin/genaliases . Manchmal dauert es etwas, bis die Dateien auftauchen, man kann das Programm auch von Hand aufrufen.
Hinweis: Die Dateien virtual-mailman und virtual-mailman.db werden natürlich erst angelegt, wenn für eine virtuelle Domain eine Mailingliste erzeugt wird. Solange bis die Dateien existieren ist die Postfix-Konfiguration nicht in Ordnung: Das hat mich mal wieder etwas Zeit gekostet.
Hier einmal ein Inhalt der Datei virtual-mailman
# This file is generated by Mailman, and is kept in sync with the binary hash # file virtual-mailman.db. YOU SHOULD NOT MANUALLY EDIT THIS FILE unless you # know what you're doing, and can keep the two files properly in sync. If you # screw it up, you're on your own. # # Note that you should already have this virtual domain set up properly in # your Postfix installation. See README.POSTFIX for details. # LOOP ADDRESSES START mailman-loop@diskless-client.de mailman-loop # LOOP ADDRESSES END # STANZA START: test # CREATED: Sun Jul 14 12:00:33 2013 test@diskless-client.de test test-admin@diskless-client.de test-admin test-bounces@diskless-client.de test-bounces test-confirm@diskless-client.de test-confirm test-join@diskless-client.de test-join test-leave@diskless-client.de test-leave test-owner@diskless-client.de test-owner test-request@diskless-client.de test-request test-subscribe@diskless-client.de test-subscribe test-unsubscribe@diskless-client.de test-unsubscribe # STANZA END: test
Dazu gehört dann folgend aliases-Datei:
# This file is generated by Mailman, and is kept in sync with the # binary hash file aliases.db. YOU SHOULD NOT MANUALLY EDIT THIS FILE # unless you know what you're doing, and can keep the two files properly # in sync. If you screw it up, you're on your own. # The ultimate loop stopper address mailman-loop: /var/lib/mailman/data/owner-bounces.mbox # STANZA START: mailman # CREATED: Sun Jul 14 12:00:33 2013 mailman: "|/usr/lib/mailman/mail/mailman post mailman" mailman-admin: "|/usr/lib/mailman/mail/mailman admin mailman" mailman-bounces: "|/usr/lib/mailman/mail/mailman bounces mailman" mailman-confirm: "|/usr/lib/mailman/mail/mailman confirm mailman" mailman-join: "|/usr/lib/mailman/mail/mailman join mailman" mailman-leave: "|/usr/lib/mailman/mail/mailman leave mailman" mailman-owner: "|/usr/lib/mailman/mail/mailman owner mailman" mailman-request: "|/usr/lib/mailman/mail/mailman request mailman" mailman-subscribe: "|/usr/lib/mailman/mail/mailman subscribe mailman" mailman-unsubscribe: "|/usr/lib/mailman/mail/mailman unsubscribe mailman" # STANZA END: mailman # STANZA START: test # CREATED: Sun Jul 14 12:00:33 2013 test: "|/usr/lib/mailman/mail/mailman post test" test-admin: "|/usr/lib/mailman/mail/mailman admin test" test-bounces: "|/usr/lib/mailman/mail/mailman bounces test" test-confirm: "|/usr/lib/mailman/mail/mailman confirm test" test-join: "|/usr/lib/mailman/mail/mailman join test" test-leave: "|/usr/lib/mailman/mail/mailman leave test" test-owner: "|/usr/lib/mailman/mail/mailman owner test" test-request: "|/usr/lib/mailman/mail/mailman request test" test-subscribe: "|/usr/lib/mailman/mail/mailman subscribe test" test-unsubscribe: "|/usr/lib/mailman/mail/mailman unsubscribe test" # STANZA END: test
Die Dateien mit der Endung .db sind jeweils gehashte Versionen der Klartext-Dateien.
Will man eine neue Mailingliste erstellen, so ist das kein Problem, sofern es für die betreffende Domain schon eine Liste gibt. Dann kann man die einfach über http://server.tld/mailman/create anlegen. Wichtig ist aber, dass man anschließend noch einmal in die Konfiguration der Liste geht Allgemeine Optionen und dort unter Bevorzugter Hostname für E-Mail an diese Liste die zugehörige Domain angibt.
Gibt es für die Domain noch keine Mailingliste, so muss man darauf achten, dass die Domain per postfixadmin eingetragen ist, sonst nimmt das System keinerlei Mails für die Domain an. Dann mauss man in der Datei /usr/lib/mailman/Mailman/mm_cfg.py eine add_virtualhost() Zeile ergänzen und die Domain auch bei POSTFIX_STYLE_VIRTUAL_DOMAINS mit eintragen. Erst danach kann man dann die Liste sinnvoll anlegen.
Nachtrag: Beim Kopieren der Mailinglisten auf einen neuen Server ist mir ein Problem mit cron aufgefallen. Es scheint so, dass folgender Schritt noch erfolgen muss:
cp /usr/lib/mailman/cron/crontab /etc/cron.d/mailman
Mir ist nicht ganz klar, wann das ursprünglich erfolgt ist. Online findet man etwas wie:
cd /usr/lib/mailman/cron/ crontab -u mailman crontab.in
Nachtrag2: Das Startscript legt die Datei an und beendet sie auch wieder. Das Script testet aber vorher, ob mailman-Prozesse laufen. Bei mir lief ein Prozess, der sich nur killen ließ. Das war wohl die Ursache.
