Root-Server mit OpenSUSE 11: Unterschied zwischen den Versionen

Aus Debacher-Wiki
Wechseln zu:Navigation, Suche
 
Zeile 420: Zeile 420:
  
  
Es bleibt noch ein kleines (naja letztendlich hat es mich zwei Tage gekostet) Problem zu lösen. Der saslauth entfernt in der Standardeinstellung den Domainteil aus dem Benutzernamen. Aus debacher@lokales-netz.de wird also einfach debacher. Damit ist die Authentifizierung gegen das MySQL nicht mehr korrekt. Man kann ihm das abgewöhnen, indem man ihn mit dem zusätzlichen Schalter -r startet. SuSE hat nun leider in seiner Konfiguration keine direkte Möglichkeit vorgesehen zusätzliche Parameter zu übergeben, deshalb hänge ich den einfach hinter den Standardparameter mit an.
+
Es bleibt noch ein kleines (naja letztendlich hat es mich zwei Tage gekostet) Problem zu lösen. Der saslauth entfernt in der Standardeinstellung den Domainteil aus dem Benutzernamen. Aus debacher@meine-maildomain.de wird also einfach debacher. Damit ist die Authentifizierung gegen das MySQL nicht mehr korrekt. Man kann ihm das abgewöhnen, indem man ihn mit dem zusätzlichen Schalter -r startet. SuSE hat nun leider in seiner Konfiguration keine direkte Möglichkeit vorgesehen zusätzliche Parameter zu übergeben, deshalb hänge ich den einfach hinter den Standardparameter mit an.
 
/etc/sysconfig/saslauthd
 
/etc/sysconfig/saslauthd
  

Aktuelle Version vom 13. Januar 2019, 21:37 Uhr

Nach zwei Jahren ist der bisherige Root-Server nicht mehr aktuell. Ein Rechnerwechsel ist günstiger, als eine einfache Neuinstallation des Rechners. Der HighQ-Server SR5 kostet monatlich nur noch 59€, das bisherige Modell SR3 kostet und über 70€ im Monat. Für die ersten drei Monate kostet der Rechner sogar nur 29€, so dass die Umstellung mit viel Zeit erfolgen kann (Stand Oktober 2008).

Die technischen Daten:

  • Opteron 1212HE mit 2x2,0 GHz (2 x 4022 Bogomips)
  • 2GB RAM
  • 2x250GB HD als Raid1

Auf dem System ist ursprünglich OpenSUSE 10.3 und Plesk installiert, ich habe es sofort neu mit OpenSUSE 11.0 64-Bit eingerichtet, ohne irgendwelchen fremden Verwaltungstools.

Zweite IP

Zu dem Vertrag steht eine zweite IP zur Verfügung. Die kann man einfach im Strato-Konfigurationsmenü anfordern und sie steht nach kurzer Zeit zur Verfügung. Man kann dann die Namensauflösung für beide Adressen in der Oberfläche einstellen.

Leider gibt es keine aktuellen Anleitungen, wie man die zweite Adresse auf dem Rechner aktiviert. Letztendlich ist das aber tierisch einfach. Man erweitert einfach die Datei /etc/sysconfig/network/ifcfg-eth0 um ein paar Zeilen.

BOOTPROTO='dhcp'
STARTMODE='auto'
BROADCAST=
ETHTOOL_OPTIONS=
IPADDR=
MTU=
NAME=
NETMASK=
NETWORK=
REMOTE_IPADDR=
USERCONTROL='no'
IPADDR_1='85.214.xxx.yyy/32'
LABEL_1='1'

Letztendlich beziehen sich nur die beiden letzten Zeilen auf die zweite IP. Ich habe die Konfiguration von YaST erzeugen lassen, das erklärt die sehr kompakte Einstellung. Sicherlich wäre auch die ausführlichere Erweiterung

BROADCAST_1='85.214.xxx.yyy'
IPADDR_1='85.214.xxx.yyy'
NETMASK_1='255.255.255.255'
LABEL_1='1'

weiterhin möglich.


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

Für die folgende Beschreibung wird ein Benutzer vmail (uid 207) und eine Gruppe vmail (gid 207) benutzt. Der Benutzer hat als Homeverzeichnis /var/vmail, wo dann auch die eingehenden Mails liegen.

groupadd -g 207 vmail
mkdir /var/vmail
chmod a+rxw /var/vmail
useradd -d /var/vmail/ -s /bin/false -u 207 -g 207 vmail 

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.

Zur Installation habe ich das Programm als .tgz von [1] geladen und im Ordner /tmp gespeichert. Dann mit

cd /srv/www/htdocs
tar xvfz /tmp/postfixadmin-2.2.1.1.tar.gz
mv postfixadmin-2.2.1.1 postfixadmin

installiert. Es gibt zwar auch eine SUSE rpm-Datei, aber Postfixadmin erwartet eine Reihe von Perl-Paketen. Zwei der Pakete sind nicht bei OpenSUSE dabei, so dass es zu nicht erfüllten Abhängigkeiten käme. Beim Update hat mir YaST dan das rpm wieder deinstalliert. Also habe ich lieber das tar.gz Archiv genutzt. Die zwei nicht vorhandenen Perl-Pakete sind:

  • perl Email::Valid
  • perl MIME::EncWords

Das erste Paket habe ich als RPM finden können und installiert:

Von ftp://ftp5.gwdg.de/pub/opensuse/repositories/devel:/languages:/perl/openSUSE_11.0/x86_64 das Paket perl-Email-Valid-0.174-1.4.x86_64.rpm

Das zweite Paket habe ich dann über CPAN installiert:

perl -MCPAN -e 'install MIME::EncWords'     

Vermutlich wäre das auch für Email::Valid der einfachere Weg gewesen. Die Installation von Perl-Modulen ist recht einfach, zumindest wenn die Pakete zur Porgrammentwcklung, also Compiler und make installiert sind.

Bei ersten Aufruf von Postfixadmin startet das Setup-Programm, welches auch die notwendigen Datenbanktabellen anlegt, bzw.aktualisiert, wenn es sich um ein Update handelt. Es gibt danach folgende Tabellen:

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 default ,
 `goto` text NOT NULL,
 `domain` 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  (`address`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COMMENT='Postfix Admin - Virtual 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  DEFAULT CHARSET=latin1 COMMENT='PostfixAdmin settings' AUTO_INCREMENT=2 ;


CREATE TABLE `domain` (
 `domain` varchar(255) NOT NULL default ,
 `description` varchar(255) character set utf8 collate utf8_unicode_ci NOT NULL,
 `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) default 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 default ,
 `src_server` varchar(255) NOT NULL default ,
 `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 default ,
 `src_password` varchar(255) NOT NULL default ,
 `src_folder` varchar(255) NOT NULL default ,
 `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,
 `extra_options` text,
 `returned_text` text,
 `mda` varchar(255) NOT NULL default ,
 `date` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
 PRIMARY KEY  (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;


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 default ,
 `password` varchar(255) NOT NULL default ,
 `name` varchar(255) character set utf8 collate utf8_unicode_ci NOT NULL,
 `maildir` varchar(255) NOT NULL default ,
 `quota` bigint(20) NOT NULL default '0',
 `domain` 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 Mailboxes';


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`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COMMENT='Postfix Admin - Virtual Vacation Notifications';


ALTER TABLE `vacation_notification`
 ADD CONSTRAINT `vacation_notification_pkey` FOREIGN KEY (`on_vacation`) REFERENCES `vacation` (`email`) ON DELETE CASCADE;

Am Ende der Installationsprozedur wird ein Superadministrator angelegt. Mit diesen Daten kann man sich dann unter http://localhost/postfixadmin/ anmelden, zumindest wenn man vorher die Datei setup.php entfernt oder umbenannt hat.

Postfixadmin1-neu.png

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.


Postfix-yast.jpg

YaST installiert und konfiguriert dann auch gleich den Virenscanner Clamav mit, wobei man den clamd und freshclam eventuell selber noch aktivieren muss.

Damit Postfix MySQL-Tabellen nutzen kann muss man zusätzlich per YaST das Paket postfix-mysql installieren.

Nun müssen in /etc/postfix einige Dateien angelegt werden, die sich direkt auf die entsprechenden Datenbanktabellen beziehen. Im Prinzip wird Postfix hier mitgeteilt, wie die Datenbanktabellen abgefragt werden. Benutzername und Passwort müssen hier an die eigenen Einstellungen angepasst werden.

mysql_relay_domains_maps.cf

user = postfix
password = postfix
hosts = localhost
dbname = postfix
query = SELECT domain FROM domain WHERE domain='%s' AND backupmx = '1' AND active = '1'

mysql_virtual_alias_maps.cf

user = postfix
password = postfix
hosts = localhost
dbname = postfix
query = SELECT goto FROM alias WHERE address='%s' AND active = '1'

mysql_virtual_domains_maps.cf

user = postfix
password = postfix
hosts = localhost
dbname = postfix
query = SELECT description FROM domain WHERE domain='%s' AND active = '1'

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'

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 eine kleine Änderung an der Datei /etc/sysconfig/postfix:

POSTFIX_SMTP_AUTH_SERVER="yes"

Im Idealfall erweitert man dann die Datei /etc/sysconfig/postfix um die notwendigen Zeilen und ruft dann SuSEconfig --module postfix auf. Hier das Ende meiner 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="10240000"

## Type:        yesno
## Default:     yes
## Config:      postfix
#
# Automatically register to slpd, if running?
#
POSTFIX_REGISTER_SLP="yes"

# 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="proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf"

## Type:        string
## Default:     ""
POSTFIX_ADD_VIRTUAL_GID_MAPS="static:207" 

## 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="102400000"

## Type:        string
## Default:     ""
POSTFIX_ADD_VIRTUAL_MAILBOX_MAPS="proxy:mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf"

## Type:        string
## Default:     ""
POSTFIX_ADD_VIRTUAL_MINIMUM_UID="207"

## Type:        string
## Default:     ""
POSTFIX_ADD_VIRTUAL_TRANSPORT="virtual"

## Type:        string
## Default:     ""
POSTFIX_ADD_VIRTUAL_UID_MAPS="static:207"
                                                                   

SuSEconfig hängt dann folgende Zeilen an die main.cf an:

mailbox_size_limit = 0
message_size_limit = 10240000
broken_sasl_auth_clients = yes
smtpd_sasl_local_domain =
smtpd_sasl_security_options = noanonymous
virtual_alias_maps = proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf
virtual_gid_maps = static:207
virtual_mailbox_base = /var/vmail/
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql_virtual_domains_maps.cf
virtual_mailbox_limit = 102400000
virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
virtual_minimum_uid = 207
virtual_transport = virtual
virtual_uid_maps = static:207

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 207 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.

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';


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.

SASL

Soll der Rechner auch Mails von virtuellen Benutzern über das Netz annehmen, so muss man Cyrus-SASL (Simple Authentication and Security Layer) installieren und konfigurieren. Die zugehörige Postfix-Konfiguration erscheint anfangs etwas unübersichtlich, weil der Rechner sowohl als SASL-Client gegenüber anderen Server wirken kann, als auch als Server gegenüber beliebigen Clients. Es gibt also Konfigurationsschalter smtp_xxx für die Client-Seite und Schalter smtpd_xxx für die hier zu betrachtende Server-Seite.

Das Problem bei Cyrus-SASL besteht darin, dass es normalerweise nicht mit verschlüsselten Daten aus einer MySQL-Datenbank umgehen kann. Die meisten Beschreibungen im Web funktionieren nur mit unverschlüsselten Passwörtern (auch wenn das nicht immer erwähnt wird). Für verschlüsselte Passwörter gibt es zwei Möglichkeiten, einerseits eine gepatchte auxprop-Version andererseits den Weg über ein zusätzliches Modul pam_mysql. Mir erscheint der Weg über pam_mysql am einfachsten, er erlaubt dann u.a. auch die Benutzung der MySQL-Datenbank für den VsFTPd.

Für SASL kann man folgende Pakete installieren, vermutlich benötigt man nur die ersten drei davon.

cyrus-sasl-2.1.21-3
cyrus-sasl-saslauthd-2.1.21-3
cyrus-sasl-plain-2.1.21-3
cyrus-sasl-digestmd5-2.1.21-3
cyrus-sasl-otp-2.1.21-3
cyrus-sasl-gssapi-2.1.21-3
cyrus-sasl-crammd5-2.1.21-3
cyrus-sasl-sqlauxprop-2.1.21-3

Nun muss man sich pam_mysql-Quellen von Sourceforge holen (bei mir war die Version 0.7 aktuell) und installieren:

wget http://heanet.dl.sourceforge.net/sourceforge/pam-mysql/pam_mysql-0.7RC1.tar.gz
tar xvfz pam_mysql-0.7RC1.tar.gz
cd pam_mysql-0.7RC1
./configure --with-pam-mods-dir=/lib64/security 
make install

Zum erfolgreichen Übersetzen müssen einige devel-Pakete installiert sein. Also einfach das Übersetzen anstoßen und auf die Fehlermeldungen achten. Lange gesucht habe ich nach dem devel-Paket für mysqlclient und es dann unter libmysqlclient-devel gefunden. In früheren Versionen war es unter mysql_client-devel zu finden.

Dann ist noch die Datei /usr/lib64/sasl2/smtpd.conf zu erzeugen

cp /etc/sasl2/smtpd.conf /usr/lib64/sasl2/

kontrollieren, die Standard-Version sollte aber vollkommen in Ordnung sein.

pwcheck_method: saslauthd
mech_list: plain login

Nun muss man nur noch die entsprechende PAM-Konfiguration anlegen, die Datei /etc/pam.d/smtp

#%PAM-1.0
auth    required pam_mysql.so user=postfix passwd=postfix host=localhost db=postfix table=mailbox usercolumn=username passwdcolumn=password crypt=1 where=active="1"
account required pam_mysql.so user=postfix passwd=postfix host=localhost db=postfix table=mailbox usercolumn=username passwdcolumn=password crypt=1 where=active!="0"

(die Unterschiede am Ende der beiden Zeilen sollen nur eine Zuordnung in den MySQL-Log-Dateien ermöglichen, praktisch sind bei Versionen gleichwertig) Statt der beiden langen Parameterlisten könnte man auch mit einem config_file arbeiten ( auth required pam_mysql.so config_file=/lib/security/pam_mysql.conf). Das hätte dann folgenden Aufbau:

users.host localhost
users.database postix
users.db_user postfix
users.db_passwd postfix
users.table mailbox
users.user_column username
users.password_column password
users.password_crypt 1
users.where_clause active="1"

Will man auch den Unix-Benutzern zusätzlich das Einleifern von Mails gestatten, so muss man die Datei /etc/pam.d/smtp entsprechend anpassen und um die alten Zeile ergänzen:

#%PAM-1.0
auth  sufficient pam_mysql.so user=postfix passwd=postfix host=localhost db=postfix table=mailbox usercolumn=username passwdcolumn=password crypt=1 where=active="1"
account sufficient pam_mysql.so user=postfix passwd=postfix host=localhost db=postfix table=mailbox usercolumn=username passwdcolumn=passwordcrypt=1 where=active!="0"

auth     include        common-auth
account  include        common-account
password include        common-password
session  include        common-session


Es bleibt noch ein kleines (naja letztendlich hat es mich zwei Tage gekostet) Problem zu lösen. Der saslauth entfernt in der Standardeinstellung den Domainteil aus dem Benutzernamen. Aus debacher@meine-maildomain.de wird also einfach debacher. Damit ist die Authentifizierung gegen das MySQL nicht mehr korrekt. Man kann ihm das abgewöhnen, indem man ihn mit dem zusätzlichen Schalter -r startet. SuSE hat nun leider in seiner Konfiguration keine direkte Möglichkeit vorgesehen zusätzliche Parameter zu übergeben, deshalb hänge ich den einfach hinter den Standardparameter mit an. /etc/sysconfig/saslauthd

## Path:           System/Security/SASL
## Type:           list(getpwent,kerberos5,pam,rimap,shadow,ldap)
## Default:        pam
## ServiceRestart: saslauthd
#
# Authentication mechanism to use by saslauthd.
# See man 8 saslauthd for available mechanisms.
#
SASLAUTHD_AUTHMECH="pam -r"

die Anführungsstriche sind dabei auch wichtig, sonst kommt es zu einer Fehlermeldung.

Nun noch vorsichtshalber die Dienste neu starten:

rcsaslauthd restart
rcpostfix restart

Zum Testen kann man eine Telnet-Verbindung nutzen, mann muss nur vorher die Anmeldedaten 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.


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/lib/mysql/mysqld.pid --socket=/var/lib/mysql/mysql.sock --datadir=/var/lib/mysql --log=/var/lib/mysql/sasl-informationen.log --log-long-format &


Bei Problemen mit SASL kann man sich eventuell hilfreiche Informatioen verschaffen mit dem Programm saslfinger http://postfix.state-of-mind.de/patrick.koetter/saslfinger/, welches mittels

saslfinger -s

die Serverseite und mittels

saslfinger -c

die hier nicht weiter beschriebene Clientseite beleuchtet.

Dovecot

Hier gibt es recht massive Änderungen seit die Version 1.0.X verfügbar ist. Die Konfiguration wurde gegenüber 0.99 deutlich verändert, so dass man auf ältere Beschreibungen nur sehr eingeschränkt zurückgreifen kann. Hilfreich bei meinen Experimenten war die Seite http://workaround.org/articles/ispmail-etch/#step-5-deliver-emails-through-the-dovecot-lda

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.

In der Datei /etc/dovecot/dovecot.conf sind dann die folgenden Ergänzungen notwendig:

protocols = imap pop3 imaps pops

nur dann, wenn die Zertifikate erzeugt wurden, sonst die einfach Version:

protocols = imap pop3
disable_plaintext_auth = no
mail_privileged_group = postfix
mail_access_groups = postfix
#mail_extra_groups = postfix in Version 1.05.
first_valid_uid = 207
verbose_proctitle = yes
protocol pop3 {
 ...
 pop3_uidl_format = %08Xu%08Xv
 ...
}
auth default {
  ...
  passdb sql {
   args = /etc/dovecot/dovecot-mysql.conf
  }
  ...
  userdb sql {
     args = /etc/dovecot/dovecot-mysql.conf
  }
  ...
}

Die 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/lib/mysql/mysql.sock dbname=postfix user=dovecot password=assword

password_query = SELECT password FROM mailbox WHERE username = '%u' AND active = '1'
user_query = SELECT concat('maildir:/var/vmail/',maildir) as mail, 207 AS uid, 207 AS gid FROM mailbox WHERE username = '%u' AND active = '1'


Horde - Imp

Ich habe mal wieder einen Anlauf genommen um Horde und Imp zu installieren. Der Funktionsumfang des Paketes erscheint mir nahezu unschlagbar, aber die Installation ist eine Katastrophe. Es handelt sich zwar um eine reine PHP-Lösung, eine wirkliche Installation ist also eigentlich nicht notwendig.

Horde benötigt aber eine Reihe von PEAR-Paketen und damit fangen oft die Probleme an. Die Installation dieser Pakete habe ich noch nie problemlos erlebt. Glücklicherweise diesmal aber einigermaßen erfolgreich.

Die Paketen horde und imp, die OpenSUSE mit ausliefert sind nicht aktuell. Es erschien mir sinnvoller vom integrierten Horde Groupware Webmail Edition auszugehen. Aber egal wie man es macht, leider sind die Konfigurationsschritte nicht überflüssig. Ich habe versucht mich an die Beschreibung zu halten, die im Horde-Verzeichnis in der Datei doc/sINSTALL zu finden ist. Es sind aber manche Abweichungen notwendig.

Im ersten Schritt erfolgt die Installation mehrerer PEAR-Pakete.

pear install -o Log Mail Mail_Mime DB Date File
pear -d preferred_state=beta install -a Services_Weather


Nun noch zwei PECL-Pakete, die ich erst nur über einen Umweg installieren konnte. Der Befehl pecl selber ist bei OpenSUSE im Devel-Paket von php5 enthalten. Alle möglichen pear und pecl Pakete sind aber unter http://download.opensuse.org/repositories/server:/php:/extensions/openSUSE_11.0/x86_64/ verfügbar.

Ich habe von dort also die Pakete

http://download.opensuse.org/repositories/server:/php:/extensions/openSUSE_11.0/x86_64/php5-fileinfo-1.0.4-11.10.x86_64.rpm

und

http://download.opensuse.org/repositories/server:/php:/extensions/openSUSE_11.0/x86_64/php5-pecl-memcache-3.0.2-1.4.x86_64.rpm

bezogen und mit rpm installiert.

Noch einige PEAR-Pakete waren notwendig, die aber als RPM dabei waren.

pear Date
pear Auth_SASL 


Und dann irgendwann natürlich

rcapache2 restart

Im Horde-Paket ist ein setup-Script enthalten. Man wechselt also als root ins Horde-Verzeichnis und gibt ein:

php scripts/setup.php

Es folgt eine textbasierter Dialog:

What is the web root path on your web server for this installation, i.e. the path of the address you use to access Horde Groupware Webmail Edition in your browser? [/horde]

Horde Groupware Webmail Edition Configuration Menu
   (0) Exit
   (1) Configure database settings
   (2) Create database or tables
   (3) Configure administrator settings
   (4) Update from an older Horde Groupware Webmail Edition version

Type your choice:

Im Prinzip folgt man den einzelnen Fragen. Ich hatte die Datenbank horde und den zugehörigen Benutzer schon vorher erzeugt. Im Schritt 1 bekeam ich zwar ein paar Fehlermeldungen, der Rest hat trotzdem funktioniert. Wichtig ist, dass man unter (3) einen Mailaccount angibt, der vorhanden ist, also möglichst im postfixadmin schon erzeugt sein sollte.

Nun ruft man die Seite http://localhost/horde/test.php im Browser auf und installiert solange weitere Pakete nach, wie rote Fehlermeldungen auftauchen. Gelbe Fehlermeldungen kann man notfalls ignorieren.

Das Spannende dabei ist, Horde und IMP laufen dann wirklich. Ich werde mich nun erst einmal mit der Konfiguration und den interessantesten Horde-Modulen beschäftigen, danach erfolgt hier auch eine Beschreibung zur Konfiguration.

Majordomo / Majorcool

Aus alter Gewohnheit arbeite ich immer noch mit Majordomo und Majorcool. Leider lief die bei openSUSE mitgelieferte Majorcool-Version bei mir nicht, es gab immmer eine Fehlermeldung der Art

malformed header from script. Bad header=$* is no longer supported at /: majordomo

Als Ursache stellte sich der Wechsel von Perl 5.8 auf 5.10 heraus. In der Datei

/usr/lib/majordomo/majordomo.pl

finden sich Zeilen der Art

local($save1, $save2) = ($*, $/);

Die Spezialvariable $* ist in Perl 5.10 als Fehler gekennzeichnet, in Perl 5.8 nur als überholt. Hierüber wird ein Multiline-Matching eingestellt. Aktuell kann man das nur über die Suchoption m realisieren. ich habe an der Datei folgende Änderungen vorgenommen und nun scheint es wieder zu funktionieren.

sub main'ParseMailHeader  ## Public
 {
 ## geändert von U.D. am 7.11.2008 Perl erlaubt seit 5.10 $* nicht mehr, ist durch /m ersetzt
 ##    local($save1, $save2) = ($*, $/);
    local($save2) = ($/);
 
    local($FH, *array) =  @_;
    local ($keyw, $val);
 
    %array = ();
 
    # force unqualified filehandles into callers' package
    local($package) = caller;
    $FH =~ s/^[^':]+$/$package'$&/;
 
 ##    ($*, $/) = (1, '');
    ($/) = ('');
    $array = $_ = <$FH>;
    s/\n\s+/ /g;
 
    @array = split('\n');
    foreach $_ (@array)
    {
        ($keyw, $val) = m/^([^:]+):\s*(.*\S)\s*$/gm;
        $keyw =~ y/A-Z/a-z/;
        if (defined($array{$keyw})) {
            $array{$keyw} .= ", $val";
        } else {
            $array{$keyw} = $val;
        }
    }
 ##    ($*, $/) = ($save1, $save2);
    ($/) = ($save2);
 }

Eigentlich ist der Fehler ja in Majordomo, er führt aber zu einem Funktionsausfall in Majorcool.

Software-Aktualisierungen

ein großer Vorteil eines aktuellen Systems ist es, dass es auch halbwegs aktuelle php und mysql-Versionen mit sich bringt. Damit können dann auch Anwendungsprogramme auf den letzten Stand gebracht werden.

Moodle

Ein wichtiger Grund für den neuen Server war die Möglichkeit Moodle von der bisherigen Version 1.6.x auf 1.9.x zu aktualisieren. Tja, das hat mich jetzt knapp 12 Stunden Arbeit gekostet. Ich habe das Update schrittweise vorgenommen:

1.6.x -> 1.8.x -> 1.9.x

Dummerweise konnte man nach der Aktualisierung keinerlei Editor-Funktionen mehr nutzen. Es gab immer eine vollkommen weiße Seite und in den Logs eine Nummer 500 mit 0 Bytes. Seltsamerweise nur in der access_log, nicht in der error_log. nach vielen Experimenten bin ich darauf gekommen, dass es etwas mit der Zeile

php_admin_value include_path  ...

in der Konfiguration des Apache2 zu tun haben muss. Immer wenn eine Include-Pfad angegeben war tauchte das Problem auf, war kein Include-Pfad angegeben, dann funktionierte alles.

Mit dem Wissen ließ sich dann auch eine Erklärung finden. Moodle liefert eigene PEAR-Module mit, die sich im Verzeichnis

lib/pear

finden. Ist dieses Verzeichnis nicht im Include-Pfad, so benutzt der Apache die systemweit installierten PEAR-Module und nicht die mitgelieferten. Systemweit sind wohl nicht alle benötigten Module installiert, was eine Aufnahme des Verzeichnisses in den Include-Pfad notwendig macht.

 php_admin_value include_path "/srv/www/htdocs/moodle/lib/pear:<weitere Verzeichnisse>"

So einfach ist die Lösung.

Mediawiki

Die Aktualisierung von Mediawiki-Paketen ist relativ einfach. Man haut einfach die neuen Dateien über die alten und ruft dann aus dem Verzeichnis maintenance das Script update.php auf:

php maintenance/update.php

Damit das klappt muss man im Hauptverzeichnis eine Datei AdminSettings.php erstellen, in der man den Datenbank-Benutzer und sein Passwort angeben muss, der auch Strukturveränderungen vornehmen darf. Für die AdminSettings.php existiert mit AdminSettings.sample ein Muster, welches man übernehmen kann.

Probleme hatte ich nur einmal, als ich direkt von einer Version 1.4.x auf 1.12.x aktualisieren wollte. Das gab nur Fehlermeldungen, was sicherlich auch damit zusammenhängt, dass hier eine Umstellung auf UTF8 erfolgen muss. Ich habe dann zuerst auf Version 1.5.x aktualisiert, da gibt es ein Script zur Datenbank-Anpassung. Ich musste zuerst in der Konfigurationsdatei

$wgDBmysql5 = true;

setzen und konnte dann die Scripten rufen:

php5  maintenance/upgrade1_5.php
php5  maintenance/update.php

Mit einer Version 1.6.x als weiterem Zwischenschritt hat es dann auch hier geklappt.

Typo3

Die Aktualisierung von Typo3-Installation ist generell recht einfach, da der eigentliche Programmcode über einen Link eingebunden wird. Man muss also nur den Link auf eine neue Version setzen und kann dann im Installationsmenü innerhalb von Typo3 die Datenbank anpassen lassen. Etwas irritiert war ich nach einem Update auf 4.2.2. Hier war plötzlich der Seitenbaum leer und auch nicht zu finden. Man muss dazu im Backend das Installations-Tool aufrufen, dort auf Database Analyser und dann auf Compare gehen. Damit kann man eine Aktualisierung der Datenbank auslösen. Anschließend sollte man noch den Cache löschen, danach geht es dann wieder.

Bei einer nicht update-fähigen Typo3-Installation traten nach dem Update Probleme mit dem tt_news Plugin auf. alle News standen in der verkehrten Reihenfolge, Laut http://www.typo3.net/index.php?id=13&action=list_post&tid=71875 ist ein MySQL-Bug dafür verantwortlich, der in der MySQL-Version 5.0.52 gefixed ist. Bei openSUSE 11.0 ist aber 5.0.51a dabei. Der in dem Artikel beschriebene Weg ein paar zeilen in

typo3conf/ext/tt_news/pi/class.tx_ttnews.php

auszukommentieren hat aber geholfen.

Ein weiteres Problem zeigt sich im Zusammenhang mit dem Update grafischem Text. Immer wenn nixeText=1 gesetzt ist, dann wird der Text nicht mehr erzeugt. Das Problem scheint nicht direkt mit ImageMagick zu tun zu haben. Ich habe es sowohl mit der guten alten 4er Version von ImageMagick probiert, als auch mit GraphicsMagick. Die Probleme sind schwer vorhersehbar. Manchmal hat es gelangt den Pfad zum Fontfile absolut anzugeben, manchmal ging es dann plötulich auch relativ.

Generell scheint es eine Lösung zu sein:

[GFX][gdlib_png]=1

Wenn man das Erzeugen von PNG-Dateien erzwingt. Das kann eventuell im IE6 Probleme geben, der verfügt auch über einen PNG-Bug. Wenn man aber keine Transparenz benutzt scheint es zu klappen.

amavis - clamav - spamassasin

Amavis ist ein sehr nützliches Paket zur Integration von Virenscanner und Spam-Schutz ins Mailsystem. Die als schädlich erkannten Mails legt es im Verzeichnis

/var/spool/amavis/virusmails/

ab, wo man gelegentlich mal Stichproben machen kann. Auf meinem privaten Rechner landen hier pro Monat etwa 2000 Mails.

Ich nutze den Scanner clamav als Dämon für die Virenerkennung. Damit amavis drauf zugreifen kann müssen die socket-Angabe vereinheitlicht werden. Am einfachsten ist es wohl die Änderung an der clamd.conf vorzunehmen:

# Path to a local socket file the daemon will listen on.
# Default: disabled (must be specified by a user)
#LocalSocket /var/lib/clamav/clamd-socket
LocalSocket /var/run/clamav/clamd

Auf dem Rechner läuft natürlich der Spamassasin. Seltsamerweise waren nach der beschriebenen Postfix-Installation nur die Hilfspakete vorhanden, nicht das Hauptpaket. In dem Hauptpaket befindet sich nämlich ein Tool zur Aktualisierung von Spamassasin:

sa-update -D

Beim ersten Update gabe es leider immer Probleme mit gpg-Schlüsseln, was ein Aufruf mittels

sa-update -D --nogpg

umging. Jetzt klappt auch das normale Update.

Was der Vayes-Filter gelernt hat kann man mit

sudo -u vscan -H sa-learn --dump magic

abfragen.