Root-Server

Aus Debacher-Wiki
Zur Navigation springenZur Suche springen

Die folgende Beschreibung bezieht sich auf ein System mit SuSE 10.0, inzwischen gibt es eine aktualisierte Version für OpenSUSE 11.0.

Für Netthelp muss ich seit September 2006 auch einen Root-Server verwalten. Entschieden habe ich mich für einen Strato Highend-Server MR3. Der Server stand wenige Stunden nach der Bestellung bereits zur Verfügung. Installiert war aber eine SuSE9.3. Also habe ich gleich einmal eine neuinstallation ausgelöst, ich wollte unbedingt mindestens SuSE 10.0 haben. Ich habe das Image mit Plesk ausgewählt. Eigentlich mag ich solche Oberflächen nicht, ich will aber mal ein paar Tage testen, ob eventuell der Nutzen überwiegt, sonst gibt es noch einmal eine Neuinstallation. Die Installation hat nur etwa 30 min gedauert.

Serverausfall 1

Das Gerät verfügt über zwei Festplatten im Raid1. So ganz geheuer ist mir das nicht, verdoppelt es doch das Ausfallrisiko. Der neue Rechner hatte dann auch gleich am 12. September einen Festplattenausfall, deshalb wurde das Gerät komplett ausgetauscht. Die Problemlösung hat relativ lange gedauert, da Strato erst einen Hardwaretest laufen ließ (kann 8 Stunden dauern) und dann auch recht kompliziert den Auftrag haben wollte das Gerät zu tauschen. Nachdem der Hardwaretest einen Fehler bestätigt hat, bekommt man eine Mail mit einem PDF-Formular, welches man ausfüllen und mit einer Ausweiskopie per Fax an Strato schicken muss. Dieses Fax war erst nicht auffindbar, dann nicht lesbar, nach erneuter Intervention dann doch. Letztendlich hat der Austausch dann aber geklappt und bis dahin war das Gerät ja auch noch nicht im Einsatz.

Serverausfall 2

Am Samstag 18. November ist auch beim zweiten Server wieder ein Fesplattendefekt aufgetreten. Wieder auf der zweiten Platte des Verbundes. Da jetzt aber Domains auf dem Server lagen war das Problem für mich dramatischer. Zum Glück liefen noch alle Dienste, außer Plesk und auch YaST war nicht mehr richtig nutzbar. Um Ausfälle zu vermeiden habe ich am Montag dann einen Reserve-Rechner aufgesetzt und konfiguriert. Dazu habe ich mir schon am Wochenende sehr viel Gedanken über eine Konfiguration ohne Plesk gemacht. Nachdem auch das Mailsystem mit Postfix und virtuellen Nutzern vernünftig lief habe ich dann alle Domains auf den Reserve-Rechner transferiert. Am Dienstag war ich mit den Vorbereitungen fast fertig und habe beim Strato-Service angerufen um den weiteren Ablauf zu klären. Mir wurde ein unkompliziertes Verfahren in Aussicht gestellt und eine Mail-Adresse genannt an die ich die Log-Auszüge schicken sollte. Etwa eine halbe Stunde später hat der Strato-Mitarbeiter schon versucht mich anzurufen, er wollte nur noch einen Blick auf die mdesg werfen. Leider war ich da schon zur Arbeit und habe seine Mail erst abends gesehen. Am nächsten Tag habe ich dann gleich um 08.00h bei der Hotline angerufen und den Austausch angeleiert. Der Mitarbeiter war mit einem direkten Einblick in die dmesg zufrieden und hat direkt das Ticket ausgelöst. Das Verfahren mit dem Fax kannte ich ja bereits und konnte damit das vorbereitete Fax absenden. Um 08.15 rief dann der Mitarbeiter vom Vortag an und teilte mir mit, dass nun der Austausch in Gang käme, alles wäre ok. Bereits um 11.40 war der Austauschserver einsatzbereit. Ich habe ihn dann noch einmal neu installieren lassen, mit einem System ohne Plesk. Um 12.40h hatte ich dann den Server endgültig einsatzbereit und konnte mit der Installation und Konfiguration beginnen, hatte aber nicht mehr viel Zeit. Achja, auch der Mitarbeiter vom Vortag rief noch einmal bei mir an, um mir mitzuteilen, dass der Server ausgetaucht ist. Am Donnerstag konnte ich die Konfiguration abschließen und mit der Rückführung der Domains beginnen.

Mit dem Strato-Service war ich in diesem Fall sehr zufrieden, schneller hätte es nicht gehen können und die Betreuung war kompetent und hilfsbereit.

Da mein System nun ohne Plesk arbeitet lagere ich die zu Plesk gehörigen Beschreibungen in eine extra Seite aus, die ich nicht mehr weiter pflegen werde.


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-eth-id-xxxxxx um ein paar Zeilen.

BOOTPROTO='dhcp'
BROADCAST=
IPADDR=
MTU=
NETMASK='255.255.255.0'
NETWORK=
REMOTE_IPADDR=
STARTMODE='auto'
UNIQUE='rBUF.b40ojmoWMqF'
USERCONTROL='no'
_nm_name='bus-pci-0000:02:06.0'
BROADCAST_1='81.169.xxx.yyy'
IPADDR_1='81.169.xxx.yyy'
NETMASK_1='255.255.255.255'
LABEL_1='1'

Statt xxx und yyy muss natürlich jeweils die Adresse eingetragen werden.

Mail mit Postfix und virtuellen Benutzern

Auf dem System war Plesk installiert. Das Plesk hat aus meiner Sicht zwei Funktionen, einerseits die Konfiguration des Webspace, andererseit die Konfiguration der virtuellen Mailboxen.

Die Apache-Konfiguration ist nicht wirklich schwierig, das kann ich problemlos auch ohne Plesk realisieren, wobei mir die Art und Weise wie Plesk das löst sogar gefällt.

Das Mailsystem gefällt mir aber weniger und zwar an folgenden Stellen:

  • qmail finde ich mühsam, außerdem bekomme ich viel zu wenige Informationen bei Problemen
  • Spamassasin ist zwar einzubinden, aber irgendwie nicht direkt im Zugriff
  • der Virenscanner schützt maximal 15 Mailboxen und sendet ständig irgendwelche komischen Fehlermeldungen. Außerdem landen bei jedem Viren-Update nicht zustellbare Mails in der Warteschlange.

Leider ist es nicht trivial die Plesk-Funktionalität mit anderen Programmen nachzubauen. Zum Glück gibt es inzwischen eine Reihe von Anleitungen zu diesem Thema.


Die Alternative besteht aus folgenden Komponenten:

  • Postfix statt qmail
  • Dovecot als Alternative zu Courier
  • PostfixAdmin als Alternative zu Plesk.

Für die folgende Beschreibung wird ein Benutzer vmail (uid 207) und eine Gruppe vmail (gid 207) benutzt.

groupadd -g 207 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 [1]. Das Programmpaket greift nur auf eine MySQL-Datenbank zu und nicht direkt in das Mailsystem ein.

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

cd /srv/www/htdocs
tar xvfz /tmp/postfixadmin-2.1.0.tgz

im Verzeichnisbaum des Webservers entpackt. Nun noch

cd /srv/www/htdocs/
mv postfixadmin-2.1.0  postfixadmin
chown -R wwwrun.www postfixadmin
cd /srv/www/htdocs/postfixadmin
chmod 640 *.php *.css
cd /srv/www/htdocs/postfixadmin/admin/
chmod 640 *.php .ht*
cd /srv/www/htdocs/postfixadmin/images/
chmod 640 *.png
cd /srv/www/htdocs/postfixadmin/languages/
chmod 640 *.lang
cd /srv/www/htdocs/postfixadmin/templates/
chmod 640 *.tpl
cd /srv/www/htdocs/postfixadmin/users/
chmod 640 *.php

Im Ordner /srv/www/htdocs/postfixadmin findet sich eine Datei DATABASE_MYSQL.TXT mit der Datenbankstruktur, die ich mittels

mysql -u root -p < /srv/www/htdocs/postfixadmin/DATABASE_MYSQL.TXT

eingelesen habe, MySQL fragt nach dem Kommando noch nach dem Passwort für den Benutzer root. Sollte kein Passwort gesetzt sein, so lässt man das -p einfach weg. Natürlich muss dazu der MySQL-Server auch installiert sein und laufen. Danach gibt es in der Datenbank postfix eine Reihe von Tabellen:

#
# Table structure for table admin
#
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),
 KEY username (username)
) TYPE=MyISAM COMMENT='Postfix Admin - Virtual Admins';
#
# Table structure for table alias
#
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),
 KEY address (address)
) TYPE=MyISAM COMMENT='Postfix Admin - Virtual Aliases';
#
# Table structure for table domain
#
CREATE TABLE domain (
 domain varchar(255) NOT NULL default ,
 description varchar(255) NOT NULL default ,
 aliases int(10) NOT NULL default '0',
 mailboxes int(10) NOT NULL default '0',
 maxquota int(10) 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),
 KEY domain (domain)
) TYPE=MyISAM COMMENT='Postfix Admin - Virtual Domains';
#
# Table structure for table domain_admins
#
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)
) TYPE=MyISAM COMMENT='Postfix Admin - Domain Admins';
#
# Table structure for table log
#
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)
) TYPE=MyISAM COMMENT='Postfix Admin - Log';
#
# Table structure for table mailbox
#
CREATE TABLE mailbox (
 username varchar(255) NOT NULL default ,
 password varchar(255) NOT NULL default ,
 name varchar(255) NOT NULL default ,
 maildir varchar(255) NOT NULL default ,
 quota int(10) 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),
 KEY username (username)
) TYPE=MyISAM COMMENT='Postfix Admin - Virtual Mailboxes';
#
# Table structure for table vacation
#
CREATE TABLE vacation (
 email varchar(255) NOT NULL default ,
 subject varchar(255) NOT NULL default ,
 body text NOT NULL,
 cache text NOT NULL,
 domain varchar(255) NOT NULL default ,
 created datetime NOT NULL default '0000-00-00 00:00:00',
 active tinyint(1) NOT NULL default '1',
 PRIMARY KEY  (email),
 KEY email (email)
) TYPE=MyISAM COMMENT='Postfix Admin - Virtual Vacation';


Da die Konfigurationsdatei angepasst werden muss, liegt sie nur mit der Endung.sample vor. Diese Datei kopiert man sich:

cp /srv/www/htdocs/postfixadmin/config.inc.php.sample  /srv/www/htdocs/postfixadmin/config.inc.php

Nun muss man in der gut kommentierten Datei /srv/www/htdocs/postfixadmin/config.inc.php noch ein paar Einstellungen vornehmen. Wichtig ist, dass die Zugangsdaten für die Datenbank mit denen übereinstimmen, die in der Datei DATABASE_MYSQL.TXT stehen. Hier kann man auch gleich die deutsche Sprache für die Benutzerführung einstellen.

Einen kleinen Fehler muss man noch beseitigen. Die deutsche Beschriftung der Menü-Buttons ist wohl etwas länger, dadurch wird im Auslieferungszustand die Leiste umgebrochen und ein Button überlagert zwei andere. Das lässt sich durch eine kleine Änderung in der Datei /srv/www/htdocs/postfixadmin/stylesheet.css lösen. Ab Zeile 76 findet sich folgende Eisntellung:

#menu {
   width: 750px;
   margin: 0 auto;
   padding-top: 10px;
   white-space: nowrap;
}

hier wird einfach die Zeile mit dem white-space ergänzt. Eventuell könnte man auch die Texte auf den Buttons etwas verkürzen.

Nun noch eine kleine Anpassung in der Datei /srv/www/htdocs/postfixadmin/admin/.htaccess, hier sollte in der ersten Zeile der Pfan angepasst werden:

AuthUserFile /srv/www/htdocs/postfixadmin/admin/.htpasswd
AuthGroupFile /dev/null
AuthName "Postfix Admin"
AuthType Basic

<limit GET POST>
require valid-user
</limit>

Die .htpasswd selber kann man mit den üblichen apache-Tools anpassen. Voreingestellt ist der Benutzer: admin mit dem Passwort: admin.

Nun sollte die Admin-Oberfläche im Browser starten http://localhost/postfixadmin/admin/

Postfixadmin1.jpg

Die Konfiguration ist sehr übersichtlich. Viele Einstellungen, z.B. die Lage der Mailverzeichniss, werden global in der Datei config.inc.php vorgenommen und dann auch mit in die Datenbank übernommen.

Zum Abschluss muss man noch die Datei setup.php entfernen oder umbenennen, damit PostfixAdmin auch für normale Benutzer funktioniert.

Die Konfiguration von PostfixAdmin ist damit abgeschlossen.

Ein kleiner Fehler

In der Version 2.1.0 von PostfixAdmin gibt es einen kleinen Fehler. Ein normaler Administrator kann leider keine Alias-Einträge ändern. Der Fehler liegt in der Datei edit-alias.php, von der es insgesamt drei Versionen gibt. Jeweils eine in den Ordnern:

  • postfixadmin/users/
  • postfixadmin/admin/
  • postfixadmin/

mir ist noch nicht ganz klar, warum es so viele Versionen gibt. Das Problem liegt in der Datei im Wurzelverzeichnis. Ab Zeile 79 steht da:

  $goto = preg_replace ('/\\\r\\\n/', ',', $fGoto);
       $goto = preg_replace ('/\r\n/', ',', $fGoto);
       $goto = preg_replace ('/[\s]+/i', , $goto);
       $goto = preg_replace ('/\,*$/', , $goto);
       $array = preg_split ('/,/', $goto);

Wie man leicht sieht müsste es in der zweiten Zeile (Nummer 80) richtig heißen:

       $goto = preg_replace ('/\r\n/', ',', $goto);

Der gleiche Fehler findet sich übrigens in der Datei users/edit-alias.php in der Zeile 64.

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.

Im Idealfall erweitert man dazu 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="102400000"

## 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 = 102400000
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=/lib/security 
make install

Dann ist noch die Datei /usr/lib/sasl2/smtpd.conf zu 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@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. /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. Der erste Versuch den zu starten schlug mit der Meldung could not chdir to: /var/run/sasl2/. Nachdem ich das Verzeichnis per Hand angelegt hatte startete er.


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.

Courier

Nur der Vollständigkeit halber auch etwas zum Thema Courier. Die meisten Beschreibungen beziehen sich auf auf diesen Imap-Server. Die Version, die bei SuSE bis einschließlich 10.1 mitgeliefert wird ist für diesen Zweck leider nicht brauchbar, weil das MySQL-Modul fehlt.

Man kann aber unter http://software.opensuse.org/download/home:/cboltz/SUSE_Linux_10.1/i586/courier-authlib-mysql-0.58-14.1.i586.rpm bzw. http://software.opensuse.org/download/home:/cboltz/SUSE_Linux_10.0/i586/courier-authlib-mysql-0.58-14.1.i586.rpm

eine Version bekommen, die auch über das Datenbankmodul verfügt. Zur Installation muss man aber das gesamte Courier-Paket aktualisieren.

Änderungen sind vor allem in der Programmkomponente authlib vorzunehmen, deren Konfigurationsdateien sich im Verzeichnis /etc/authlib befinden.

In der Datei /etc/authlib/authdaemonrc ist ab Zeile 20 zu finden

##NAME: authmodulelist:2
#
# The authentication modules that are linked into authdaemond.  The
# default list is installed.  You may selectively disable modules simply
# by removing them from the following list.  The available modules you
# can use are: authuserdb authpam authldap authmysql authcustom authpipe
#
# DEFAULT SETTING from /etc/authlib/authdaemonrc.dist:
#
#authmodulelist="authuserdb authpam authldap authmysql authcustom authpipe"
#

authmodulelist="authmysql authuserdb authpam authldap authcustom authpipe"

hier muss auf alle Fälle authmysql ergänzt werden.

Dann muss dieses Modul konfiguriert werden.

/etc/authlib/authmysqlrc

MYSQL_CRYPT_PWFIELD     password
MYSQL_DATABASE          postfix
MYSQL_GID_FIELD         '207'
MYSQL_HOME_FIELD        '/var/vmail'
MYSQL_LOGIN_FIELD       username
MYSQL_MAILDIR_FIELD     maildir
MYSQL_NAME_FIELD        name
MYSQL_OPT               0
MYSQL_PASSWORD          postfix
# Uncomment below if you want quota support.
#MYSQL_QUOTA_FIELD      quota
MYSQL_SERVER            localhost
MYSQL_UID_FIELD         '207'
MYSQL_USERNAME          postfix
MYSQL_USER_TABLE        mailbox

Nach einem Neustart von Authlib und Courier sollte es möglich sein die Mails auch abzurufen.

Dovecot

Dovecot ist eine stabile und flexible Alternative zu Courier. Etwas nervig ist es, dass wir zur Zeit am Wechsel von Version 0.99 zu 1.0 stehen und sich dabei die Konfigurationsdatei deutlich verändert. Da bei SuSE die Version 0.99 dabei ist und von 1.0 bisher nur ein Release-Candidate vorliegt bleibt die Beschreibung bei der älteren Version.

An die Datei /etc/dovecot/dovecot.conf habe ich ein paar Zeilen angehängt:


default_mail_env = maildir:/var/vmail/%d/%n
#default_mail_env = maildir:/var/vmail/%u #je nach Einstellung in PostfixAdmin
# %u: Full username.
# %n: User part in user@domain, same as %u if there's no domain.
# %d: Domain part in user@domain, empty if there's no domain.
# %h: Home directory. 

mail_extra_groups = postfix
verbose_proctitle = yes
first_valid_uid = 207
first_valid_gid = 207
auth_userdb = mysql /etc/dovecot/dovecot-mysql.conf
auth_passdb = mysql /etc/dovecot/dovecot-mysql.conf


Und auch am Ende der Datei /etc/dovecot/dovecot-mysql.conf kann man einfach die folgenden Zeilen anhängen

# Database driver: mysql, pgsql
#driver = mysql

# Currently supported schemes include PLAIN, PLAIN-MD5, DIGEST-MD5, and CRYPT.
default_pass_scheme = CRYPT

# Database options
db     = postfix
db_host = 127.0.0.1
db_user = dovecot
db_passwd = assword
db_port = 3306
db_client_flags = 0

db_unix_socket = /var/lib/mysql/mysql.sock

password_query = SELECT password FROM mailbox WHERE username = '%u' AND active = '1'
user_query = SELECT maildir, 207 AS uid, 207 AS gid FROM mailbox WHERE username = '%u' AND active = '1'

Hier tauch ein Datenbank-Benutzer dovecot auf. Anlass für diesen zusätzlichen Benutzer ist die Schilderung (http://postfix.wiki.xs4all.nl/index.php?title=Virtual_Users_and_Domains_with_Courier-IMAP_and_MySQL), dass es ein Problem mit Dovecot und der Passwort-Verschlüsselung der aktuellen MySQL-Versionen gibt. Ich habe das bisher nicht verifiziert, sondern den Benutzer mit folgenden MySQL-Kommandos eingerichtet:

grant select on postfix.* to 'dovecot'@'localhost' identified by 'assword';  
set password for 'dovecot'@'localhost' = old_password('assword');

Ein Problem kann es noch bei Neustart des Rechners geben. Dovecot startet in der Standardeinstellung vor MySQL, was natürlich zu einer Fehlermeldung führt, da er nicht auf eine Datenbank zugreifen kann. Um dieses Verhalten habe ich die Zeile

# Required-Start:    $syslog $network mysql

in der /etc/init.d/dovecot um den Dienst mysql erweitert. Nach einem

insserv dovecot

ist die Reihenfolge korrekt eingestellt.

Mailman

Das Einrichten von Mailman unter SuSE-Linux erfolgt in wenigen gut dokumentierten Schritten. Zuerst muss natürlich das entsprechende Paket mailman installiert sein. Dann findet sich eine recht ausführliche Beschreibung in /usr/share/doc/packages/mailman/README.SuSE.

Die hier beschriebene Konfiguration benutzt keine virtuellen Domains.

1) In der /etc/sysconfig/mailman sind die folgenden Parameter zu überprüfen, bei mir waren keine Änderungen notwendig.

  MAILMAN_SMTPHOST
  MAILMAN_DEFAULT_NNTP_HOST
  MAILMAN_DEFAULT_EMAIL_HOST
  MAILMAN_DEFAULT_URL_HOST
  MAILMAN_VIRTUAL_HOSTS

dann startet man an der Konsole

SuSEconfig -module mailman


2) Rufe als root das folgende Programm an der Konsole auf um das Master-Passwort zu setzen:

  /usr/lib/mailman/bin/mmsitepass


3) Ergänze den alias_maps Eintrag in /etc/postfix/main.cf:

  alias_maps = hash:/etc/aliases, hash:/var/lib/mailman/data/aliases

Danach dann muss Postfix seine Daten neu einlesen mittels:

postfix reload

4) Nun noch als root folgendes Kommando aufrufen

  /usr/lib/mailman/bin/newlist mailman 

Damit wird die Master-Liste angelegt.

5) In der Datei /etc/sysconfig/apache2, "MAILMAN" zu den APACHE_SERVER_FLAGS hinzufügen und apache2 restarten.

6) mailman neu starten.

Majordomo

Mit Majordomo ist es nicht besonders schwierig Mailinglisten auf virtuellen Domains aufzusetzen. Das Verfahren benutze ich schon immer, um bei mehreren realen Domains auf einem Server saubere Adressen zu haben. Ein paar Manipulationen sind notwendig.

Im Beispiel soll eine Mailingliste einkauf@class-on-one-box.de aufgesetzt werden, wobei dies eine virtuelle Postfix-Domain ist. Die reale Adresse des Servers ist lokale-adresse.de

Im ersten Schritt benörige ich eine angepasste majordomo.cf Datei. Also

cp /stc/majordomo.cf  /etc/majordomo_ciob.cf

In dieser neuen Datei wird der Hostname fest eingetragen:

#
# A sample configuration file for majordomo.  You must read through this and
# edit it accordingly!
#


# $whereami -- What machine am I running on?
#
$whereami = "class-in-one-box.de";
#chop($whereami = `hostname -f`);

# $whoami -- Who do users send requests to me as?
#
...

Normalerweise würde Majordomo den Hostnamen abfragen, was aber nicht passt.

Nun noch das Script createlist (siehe http://www.linuxbu.ch) entsprechend anpassen:

#!/usr/bin/perl

print "Majordomo Mailinglist Creator, v1.1\n";

if(@ARGV eq 0) {
 print "Aufruf mit:   createlist name passwort owner\n";
 print "Beispiel:     createlist diskussions-l !hallo! olaf\@linuxbu.ch\n\n";
 print "Achtung: Xndern Sie ggf. die Einstellungen in createlist\n";
 exit;
}

$LUSER="mdom";
$LGROUP="mdom";
$LPATH="/var/lib/majordomo";
$LLIST=@ARGV[0];
$LPASSWD=@ARGV[1];
$LOWNER=@ARGV[2];
#$LHOST=`hostname`;
#chop($LHOST);
$LHOST="class-in-one-box.de";

Auch hier muss der Domainname wieder fest vorgegeben werden. Nun kann mit createlist die Mailingliste einkauf (ohne Domainangabe) erzeugt werden. Das Script nimmt die Einträge in der Datei /etc/aliases vor. Einen Eintrag muss man davo selber anlegen, damit der Majordomo auch passt.

majordomo_ciob: "| /usr/lib/majordomo/wrapper majordomo -C /etc/majordomo_ciob.cf"

einkauf: "|/usr/lib/majordomo/wrapper resend -l einkauf -f einkauf-owner -R -h class-in-one-box.de -s einkauf-outgoing"
einkauf-outgoing: :include:/var/lib/majordomo/lists/einkauf, einkauf-archive
einkauf-archive: "|/usr/lib/majordomo/wrapper archive2.pl -a -m -f /var/lib/majordomo/lists/einkauf.archive/einkauf"
einkauf-request: "|/usr/lib/majordomo/wrapper request-answer einkauf"
einkauf-approval: einkauf-owner,
owner-einkauf: einkauf-owner,
einkauf-owner: uwe-at-Debacher.de,

Nun noch ein paar Alias-Einträge mit Postfixadmin erstellen und zwar:

einkauf-archive@class-in-one-box.de  	einkauf-archive@lokale-adresse.de
einkauf-outgoing@class-in-one-box.de 	einkauf-outgoing@lokale-adresse.de
einkauf-request@class-in-one-box.de 	einkauf-request@lokale-adresse.de 
einkauf@class-in-one-box.de 	        einkauf@lokale-adresse.de 	
majordomo@class-in-one-box.de 	        majordomo_ciob@lokale-adresse.de

Horde - Imp

Was habe ich mir da angetan. 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.

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

Ausgegangen bin ich von einem Download der aktuellen Pakete von http://www.horde.org. SuSE liefert zwar ein Horde-Paket mit aus, das besitzt aber verschiedene Abhängigkeiten gegenüber php4 und ich will php5 nutzen. Außerdem hilft das SuSE-Paket in keinster Weise bei den PEAR-Problemen. Ich habe versucht mich an die Beschreibung zu halten, die im Horde-Verzeichnis in der Datei doc/INSTALL zu finden ist. Es sind aber erhebliche Abweichungen notwendig.

Relativ harmlos ist noch, dass man auf einen SuSE-System immer php5 ... statt wie in der Anleitung angegeben php ... aufrufen muss.

Im ersten Schritt wird nach Anleitung die Datenbank eingerichtet und die Konfigurationsdateien erzeugt:

mysql -u root -p < scripts/sql/create.mysql.sql
for f in *.dist; do cp $f `basename $f .dist`; done  

Nun folgt die Installation mehrerer PEAR-Pakete. Das lief erst einigermaßen sinnvoll durch, nachdem PEAR selber aktualisiert war.

pear5 install -o Log Mail Mail_Mime DB Date File 
pear5 install Log Mail Mail_Mime 
pear5 install DB
pear5 upgrade-all
pear5 upgrade PEAR Archive_Tar 

Irgendwann tauchte dann mal plötzlich die Meldung auf, ich sollte die Channels aktualisieren, was sich dann auch bewährt hat.

pear5 channel-update pear.php.net     
pear5 install HTTP_Request 
pear5 install --alldeps Services_Weather  
pear5 install --force Services_Weather 

Nun noch zwei PECL-Pakete, die ich nur über einen Umweg installieren konnte. Der einfache Weg über pecl install <Paketname> führte immer zu Fehlermeldungen. Auch der hier beschriebene Weg funktioniert nur, wenn mittels YaST die folgenden Pakete installiert sind (das aus den Fehlermeldungen herauszulesen ist nicht ganz einfach):

autoconf
automake
gcc
zlib-devel
file-devel

Zuerst auch hier die Channels aktualisieren, sonst kommen nur defekte Pakete (ich hatte das mit dem Channel-Update einfach mals ausprobiert):

pecl channel-update pecl.php.net

Dann die Pakete jeweils herunterladen, auspacken, konfigurieren, compilieren und installieren:

pecl download memcache   
tar xvf memcache-2.1.0.tar    
cd memcache-2.1.0/      
phpize 
./configure 
make  
make install

pecl download fileinfo  
tar xvf Fileinfo-1.0.4.tar    
cd Fileinfo-1.0.4/ 
phpize 
./configure
make 
make install

Nun muss man nach Beschreibung noch die PHP-Ini um die beiden PECL-Module erweitern.

joe /etc/php5/apache2/php.ini    

Noch einige PEAR-Pakete waren notwendig

pear install Date
pear install Auth_SASL 
pear install Net_SMTP

Un dann irgendwann natürlich

rcapache2 restart

Das Spannende dabei ist, Horde und IMP laufen nun 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.

VsFTPd und virtuelle Nutzer

Hat man einmal die Authentifizierung mit pam_mysql eingerichtet, so kann man auch den FTP-Server mit virtuellen Benutzern betreiben. Die entsprechende Konfiguration besteht aus zwei Teilen, einerseits der normalen /etc/vsftpd.conf und der /etc/pam.d/vsftpd


In der /etc/vsftpd.conf muss generell der Zugriff erlaubt sein und es müssen folgende Zeilen auftauchen:

pam_service_name=vsftpd
guest_enable=YES
guest_username=ftp
user_config_dir=/etc/vsftpd/

Die Authentifizierung erfolgt dann mittels /etc/pamd.vsftpd, hier gleich in der Version für virtuelle und reale Benutzer:

#%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=password crypt=1 where=active="1"

auth     required       pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed
auth     required       pam_unix2.so
auth     required       pam_shells.so
account  required       pam_unix2.so
password required       pam_unix2.so
session  required       pam_unix2.so


Besonders interessant wird die vsfpd-Konfiguration mittels user_config_dir. Gibt man hier ein Verzeichnis an, so sucht der vsftpd hier nach der Anmeldung nach einer benutzerspezifischen Konfigurationsdatei. Bei einem lokalen Benutzer debacher also nach der Datei

/etc/vsftpd/debacher

und für den virtuellen benutzer debacher@lokales-netz.de

/etc/vsftpd/debacher@lokales-netz.de

Die normale Konfigurationsdatei kann also sehr allgemein und restriktiv gehalten werden, die notwendigen Einstellungen lassen sich dann jeweils in den spezifischen Dateien vornehmen. Sehr schön kann man Unterschiede sehen, wenn die Dateien unterschiedliche

local_root=Pfad 

Einstellungen besitzen. Auf alle Fälle lassen sich damit vielfach lokale Benutzer vermeiden. Damit muss ich sicher noch mehr experimentieren.


Cron-Jobs

Irgendwie hatte ich immer erwartet, dass die täglichen Jobs, z.B. logrotate, in der Nacht erledigt werden. Darauf waren auch die Zeitpunkte für die Statistik mit webalizer ausgelegt. Leider ist das nicht so, sondern der Zeitpunkt der täglichen Jobs hängt vom Installationszeitpunkt ab.

Die Cron-Jobs laufen über folgende Einstellungen:

  • in /var/spool/cron/tabs finden sich die persönlichen Crontabs der benutzer und von root
  • in /etc/crontab findet sich eine Tabelle für die Steuerung der cron.daily, cron.weekly, ...

In der /etc/crontab findet folgender Aufruf statt:

-*/15 * * * *   root  test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1

Alle 15 Minuten wird nachgeschaut, ob in den Verzeichnissen:

  • /etc/cron.d
  • /etc/cron.daily
  • /etc/cron.weekly
  • /etc/cron.monthly

eine auszuführende Datei liegt. Falls ja wird unter /var/spool/cron/lastrun nachgeschaut, ob bzw. wann die entsprechenden Jobs ausgeführt wurden. Mit jedem Lauf von cron.daily z.B. wird die Datei /var/spool/cron/lastrum/cron.daily aktualisiert. Die Datei selber ist leer, lediglich der Zeitpunkt für die Erstellung der Datei ist wichtig. Erst wenn 1440 Minuten abgelaufen sind (24 Stunden), dann wird cron.daily erhenut aufgerufen.

Will man den Zeitpunkt für cron.daily verändern, so muss man also die Datei /var/spool/cron/lastrum/cron.daily bzw. ihre Zeitangabe manipulieren.


Umlautdomains

Um eine Domain wie Schülernetzhilfe.de im Apache konfigureiren zu können muss sie IDNA konvertiert werden. In die Apache-Konfiguration muss man also stattdessen

 xn--schlernetzhilfe-1vb.de

eintragen.

Einen Konverter zum Erzeugen des Strings findet man unter http://www.secnetix.de/tools/idna.cgi

Eine whois-Anfrage funktioniert auch nur, wenn man

whois -h whois.denic.de -- -C UTF-8 schülernetzhilfe.de

eingibt.