fetchmail Integration in postfixadmin

Viele Benutzer haben auch Mailboxen bei anderen Anbietern, z.B. bei gmx oder web.de. Damit diese Benutzer ihre E-Mails aggregieren können, wird fetchmail eingerichtet. fetchmail ist bereits in postfixadmin integriert, somit können fetchmail-Einträge über postfixadmin verwaltet werden (derzeit leider nur von Administratoren). Über das mitgelieferte fetchmail.pl-Skript werden die Daten aus der Datenbank ausgelesen, fetchmail aufgerufen, die Mails durch amavisd-new überprüft und an die Mailboxen der Benutzer ausgeliefert. Das perl-Skript wurde etwas angepasst, damit es mit postgres interagieren kann. Des Weiteren wurden die Dateinamen etwas angepasst.

Installation:

aptitude install fetchmail
aptitude install liblockfile-simple-perl

Nötige Verzeichnisse für das Skript anlegen:

mkdir /var/run/fetchmail
touch /var/run/fetchmail/fetchmail-all.lock

Das Skript:

fetchmail.pl

#!/usr/bin/perl
 
use DBI;
use MIME::Base64;
# use Data::Dumper;
use File::Temp qw/ mkstemp /;
use Sys::Syslog;
# require liblockfile-simple-perl
use LockFile::Simple qw(lock trylock unlock);
 
openlog("fetchmail-all", "pid", "mail");
 
sub log_and_die {
        my($message) = @_;
  syslog("err", $message);
  die $message;
}
 
# read options and arguments
 
$configfile = "/etc/fetchmail/config";
 
@ARGS1 = @ARGV;
 
while ($_ = shift @ARGS1) {
    if (/^-/) {
        if (/^--config$/) {
            $configfile = shift @ARGS1
        }
    }
}
 
# postgres settings
$database="postfix";
$hostname="127.0.0.1";
$user="postfix";
$password="XXXXXX";
 
$run_dir="/var/run/fetchmail";
 
# use specified config file
if (-e $configfile) {
    do $configfile;
}
 
$dsn = "DBI:Pg:database=$database;host=$hostname";
$lock_file=$run_dir . "/fetchmail-all.lock";
 
$lockmgr = LockFile::Simple->make(-autoclean => 1, -max => 1);
$lockmgr->lock($lock_file) || log_and_die "can't lock ${lock_file}";
 
#postgres connect
$dbh = DBI->connect($dsn, $user, $password) || log_and_die "cannot connect the database";
 
$sql=<<SQL;
SELECT id,mailbox,src_server,src_auth,src_user,src_password,src_folder,fetchall,keep,protocol,mda,extra_options,usessl 
FROM fetchmail
WHERE date_part('epoch',now())-date_part('epoch',date) > poll_time*60
SQL
 
my (%config);
map{
        my ($id,$mailbox,$src_server,$src_auth,$src_user,$src_password,$src_folder,$fetchall,$keep,$protocol,$mda,$extra_options,$usessl)=@$_;
 
  syslog("info","fetch ${src_user}@${src_server} for ${mailbox}");
 
        $cmd="user '${src_user}' there with password '".decode_base64($src_password)."'";
        $cmd.=" folder '${src_folder}'" if ($src_folder);
        $cmd.=" mda ".$mda if ($mda);
 
#       $cmd.=" mda \"/usr/local/libexec/dovecot/deliver -m ${mailbox}\"";
        $cmd.=" is '${mailbox}' here";
 
        $cmd.=" keep" if ($keep);
        $cmd.=" fetchall" if ($fetchall);
        $cmd.=" ssl" if ($usessl);
        $cmd.=" ".$extra_options if ($extra_options);
 
        $text=<<TXT;
set postmaster "postmaster"
set nobouncemail
set no spambounce
set properties ""
set syslog
 
poll ${src_server} with proto ${protocol}
        $cmd
 
TXT
 
  ($file_handler, $filename) = mkstemp( "/tmp/fetchmail-all-XXXXX" ) or log_and_die "cannot open/create fetchmail temp file";
  print $file_handler $text;
  close $file_handler;
 
  $ret=`/usr/bin/fetchmail -f $filename -i $run_dir/fetchmail.pid`;
 
  unlink $filename;
 
  $sql="UPDATE fetchmail SET returned_text=".$dbh->quote($ret).", date=now() WHERE id=".$id;
  $dbh->do($sql);
}@{$dbh->selectall_arrayref($sql)};
 
$lockmgr->unlock($lock_file);
closelog();

Damit das Skript regelmäßig ausgeführt wird, legen wir einen Cronjob dafür an (als Benutzer root). In der hier gezeigten Konfiguration wird das Skript alle 5 Minuten ausgeführt.

crontab -e:

*/5 * * * * /PFAD/ZU/fetchmail.pl &> /dev/null

Der neue Server: Teil 8 Monitoring mit munin

Munin ist ein Tool zum System-Monitoring, ist einfach in der Konfiguration, bietet eine Vielfalt an Plugins und stellt die Ergebnisse über ein Webinterface grafisch dar. Im folgenden wird die Installation und eine beispielhafte Basiskonfiguration geschildert. Munin hat die Möglichkeit Daten von mehreren Systemen zu sammeln und diese alle zentral zugänglich zu machen. Hier wird nur darauf eingegangen Server und Client auf dem gleichen System zu installieren, doch die Erweiterung gestaltet sich sehr einfach und die Projekthomepage bietet mit ihrem Wiki eine gute Anlaufstelle für Fragen.

Installation:

aptitude install munin munin-node munin-plugins-extra

Konfiguration:
/etc/munin/munin.conf:

[domain.tld]
    address 127.0.0.1
    use_node_name yes

Evtl. muss man auch die Variable “htmldir” anpassen.

/etc/munin/munin.conf:

#host *
host 127.0.0.1

Munin aktualisiert die Daten in der Standardkonfiguration alle 5 Minuten, d.h. man muss evtl. etwas warten, bis die ersten Daten über die Weboberfläche verfügbar sind. Die Weboberfläche kann über die Adresse, die man in “htmldir” in der Datei munin.conf definiert hat, aufgerufen werden. Man kann/sollte dieses Verzeichnis passwortschützen, damit nicht jeder darauf zugreifen kann.

Falls man Ausschau nach weiteren Plugins hält, dann ist http://muninexchange.projects.linpro.no/?about eine gute Anlaufstelle. Des Weiteren liegen unter “/usr/share/munin/plugins/” weitere Plugins, die man einfach nach “/etc/munin/plugins” linken kann und danach noch in “/etc/munin/plugin-conf.d/munin-node” konfigurieren kann.

apache Plugin

Damit das apache-Plugin funktioniert, muss mod_status aktiviert werden:

a2enmod status

Danach muss der Zugriff auf die Status-Seite aktiviert und geregelt werden:
/etc/apache2/mods-enabled/status.conf:

<IfModule mod_status.c>
#
# Allow server status reports generated by mod_status,
# with the URL of http://servername/server-status
# Uncomment and change the ".example.com" to allow
# access from other hosts.
#
<Location /server-status>
    SetHandler server-status
    Order deny,allow
    Deny from all
    Allow from localhost ip6-localhost
#    Allow from .example.com
</Location>
 
</IfModule>

Quellen:

http://www.debuntu.org/how-to-monitoring-a-server-with-munin

http://munin.projects.linpro.no/wiki/plugin-conf.d

Der neue Server: Teil 7 roundcube

Oft hat man nicht die Möglichkeit mit einen E-Mail Client – wie z.B. Evolution oder Thunderbird – arbeiten zu können, deshalb wird hier darauf eingegangen wie man einen Webmailer – in diesem Fall roundcube – inkl. postfixadmin-Integration und Sieve-Plugin installiert.

imapproxy

Da http ein “stateless”-Protokoll ist, kann es – anders als IMAP-Clients – keine Verbindungen offen halten und stellt deshalb sehr viele unnötige “LOGIN”-Anfragen. Um dies zu verhindern wird ein imapproxy installiert. Dieser wird dem Webmailer vorgeschaltet und hält die Verbindungen geöffnet. Stellt der Webmailer nun eine Anfrage an den Proxy, sucht dieser die Verbindung raus und benutzt die bestehende Verbindung anstatt eine neue aufzubauen. Der Proxy hält die Verbindung nicht für eine unbestimmte Zeit offen, sondern schließt sie nachdem ein Timeout abgelaufen ist.

Installation:

aptitude install imapproxy

Konfiguration:

listen_address 127.0.0.1

Wir ändern nur die oben genannte Zeile, den Rest belassen wir wie er ist. Da der IMAP-Proxy auf dem gleichen System wie der Mailserver läuft, lassen wir nur lokale Verbindungen zu.
Wenn nun ein Programm/Skript den IMAP-Proxy nutzen soll, gibt man Port 1143 an, anstatt Port 143.

roundcube

Für roundcube brauchen wir zunächst einen vHost. Im Weiteren wird davon ausgegangen, dass roundcube unter https://webmail.domain.tld/ verfügbar ist.
Zunächst muss die neueste roundcube Version von http://roundcube.net/ heruntergeladen und in den vHost entpackt werden, damit es über https://webmail.domain.tld/ verfügbar ist.
Nun legen wir eine Datenbank inkl. Benutzer für roundcube an und importieren das postgres-Schema:

su - postgres
psql template1
CREATE USER roundcube WITH PASSWORD 'password';
CREATE DATABASE roundcube WITH OWNER roundcube ENCODING 'UNICODE';
\c - roundcube
\i /PFAD/ZU/ROUNDCUBE/SQL/postgres.initial.sql
\q

Nun rufen wir im Browser roundcube auf, hängen der URL aber noch “/installer” an und folgen danach den Anweisungen. Nachden wir die Konfigurationsdateien kopiert und am aufgeforderten Ort gespeichert haben, können wir roundcube über den Browser aufrufen und uns mit unserem IMAP-Benutzernamen und -passwort anmelden. Jedoch sollte man damit noch warten, bis postfixadmin-bridge installiert ist, denn dann wird automatisch der vollständige Name aus den postfixadmin-Tabellen übernommen.

postfixadmin-bridge

Zur Installation von rcpfa (= postfixadmin-bridge) wird patch benötigt:

aptitude install patch

Danach entpackt man rcpfa in den roundcube Ordner, wechselt in das neue Unterverzeichnis und führt folgenden Befehl aus:

sh INSTALL.TXT

Sollten während des Patch-Vorgangs Probleme auftreten, kann man sich die *.rej-Dateien anschauen und die Probleme ggf. händisch lösen. Nach der Installation muss noch die roundcube-Konfiguration angepasst werden (beim Patchen wurden neue Variablen in der Konfiguration hinzugefügt) und danach kann man im Einstellungs-Tab von roundcube Einstellungen aus postfixadmin ändern.

sieve rules

Das sieve-Plugin für roundcube kann man hier herunterladen: http://www.tehinterweb.co.uk/roundcube/#ptsieverules und anschließend mit

patch -ul -d /PFAD/ZU/ROUNDCUBE/ -p1 < /PFAD/ZUM/PATCH

installieren.
Die parallele Installation von rcpfa und sieve rules ist problematisch, da der Patch-Vorgang sehr wahrscheinlich an einer Stelle fehlschlägt und man selbst Hand anlegen muss.
Auch dieses Plugin hat Variablen zur roundcube-Konfiguration hinzugefügt, die angepasst werden müssen, bevor das Plugin benutzt werden kann.

mutt

Um auch über die Konsole auf E-Mails zugreifen kann, installieren wir zusätzlich noch mutt. Manche Leute fragen sich vielleicht, wozu man einen Konsolenmailer braucht, bzw. brauchen könnte. Ein interessanter Punkt ist, dass mutt einen weitaus größeren Funktionsumfang als ein Webmailer bietet und außerdem sieht es auch schick aus, wenn man seine Mails auf der Konsole liest.

Installation:

aptitude install mutt

Eine einfache Konfiguration (“~/.muttrc“):

set folder="imap://localhost"
set spoolfile="imap://localhost/INBOX"
set imap_authenticators="LOGIN"
set imap_user="username"
set imap_pass="password"
set move=no
 
set editor='vim -c "set t_Co=8" -c "syntax on" -c "/^$" -c "set tw=72" -c "set number"'
set header_cache=~/.mutt_header

Die mutt-Konfiguration ist sehr rudimentär und sollte zusätzlich noch an die eigenen Bedürfnisse angepasst werden, z.B. Sent-Ordner definieren, GPG-Schlüssel definieren, …

Quellen:

http://roundcube.net/

http://nejc.skoberne.net/projects/rcpfa/

http://www.tehinterweb.co.uk/roundcube/#ptsieverules

Der neue Server: Teil 6 Spambekämpfung

Nachfolgend wird erklärt, wie man policyd-weight, amavisd-new, clamav, spamassassin, dspam installiert, konfiguriert und in das bestehende Setup integriert.

policyd-weight

policyd-weight ist ein effektives Tool zur Spambekämpfung schon vor der Annahme einer E-Mail. Es überprüft das “Envelope” und gleicht die Absenderadresse gegen mehrere DNS-Blacklists ab.

aptitude install policyd-weight

Danach erstellen wir noch eine Standardkonfiguration für policyd-weight:

policyd-weight defaults > /etc/policyd-weight.conf

Folgende Zeile in “/etc/postfix/main.cf” ändern:

###  check_policy_service inet:127.0.0.1:12525,

… zu:

check_policy_service inet:127.0.0.1:12525,

Jetzt muss die postfix-Konfiguration neu geladen werden und policyd-weight neu gestartet werden:

/etc/init.d/policyd-weight restart
postfix reload

amavisd-new

Amavisd-new ist ein Content-Filter, der sich in fast jeden MTA integrieren lässt. Über amavisd-new lassen sich viele verschiedene Tools, wie z.B. ClamAV zur Virenprüfung, Spamassassin zur Spamfilterung oder dspam – ebenfalls zu Spamfilterung – integrieren.
Wenn eine E-Mail in postfix ankommt, wird diese an amavis weitergeleitet, überprüft und wieder – mit zusätzlichen Headern – an postfix zur Auslieferung zurückgesendet. Natürlich kann man amavis auch so konfigurieren, dass bestimmte Nachrichtentypen, z.B. Virusmails oder Spammails, sofort geblockt werden. Sobald die Nachricht von amavis an postfix zurückgegeben wurde, kann eine automatische Einsortierung in Ordner über sieve folgen (z.B. Spam-Mails nach Junk).

Installation:
Zu “/etc/apt/sources.list” hinzufügen:

# volatile repository (e.g. for clamav)
deb http://volatile.debian.org/debian-volatile lenny/volatile main contrib non-free
aptitude install amavisd-new spamassassin clamav clamav-daemon clamav-freshclam pax lha arj bzip2 unrar zoo nomarch cpio lzop cabextract apt-listchanges libauthen-sasl-perl libdbi-perl dspam libmail-dkim-perl razor pyzor dcc-client libdbd-pg-perl

Nun folgt die Konfiguration von amavis (Konfigurationsdateien sind unter “/etc/amavis/conf.d/” zu finden). Ich führe jeweils nur geänderte Zeilen auf:

01-debian:

$unrar      = ['rar', 'unrar']; #disabled (non-free, no security support)
#$unrar         = undef;
$lha    = 'lha'; #disabled (non-free, no security support)
#$lha   = undef;

05-domain_id:

@local_domains_acl = ( "." );

05-node_id:

$myhostname = "mail.domain.tld";

15-content_filter_mode:

@bypass_virus_checks_maps = ( 
   \%bypass_virus_checks, \@bypass_virus_checks_acl, \$bypass_virus_checks_re);
@bypass_spam_checks_maps = (
   \%bypass_spam_checks, \@bypass_spam_checks_acl, \$bypass_spam_checks_re);

20-debian_defaults:

$final_virus_destiny      = D_DISCARD;  # (data not lost, see virus quarantine)
$final_banned_destiny     = D_PASS;   # D_REJECT when front-end MTA
$final_spam_destiny       = D_PASS;
$final_bad_header_destiny = D_PASS;     # False-positive prone (for spam)
 
# $sa_spam_subject_tag = '***SPAM*** ';
$sa_tag_level_deflt  = undef;

50-user:

$max_servers = 2;
 
$policy_bank{'MYNETS'} = {   # mail originating from @mynetworks
  originating => 1,  # is true in MYNETS by default, but let's make it explicit
  os_fingerprint_method => undef,  # don't query p0f for internal clients
};
 
$recipient_delimiter = '+';
 
$warnvirusrecip = 1;
 
$mailfrom_notify_admin = "postmaster\@$mydomain";
$mailfrom_notify_recip = "postmaster\@$mydomain";
$mailfrom_notify_spamadmin = "postmaster\@$mydomain";

Jetzt fügen wir noch den clamav-Nutzer der amavis-Gruppe hinzu:

adduser clamav amavis

Danach müssen wir Änderungen an der postfix-Konfiguration vornehmen:

Zu main.cf hinzufügen:

content_filter = amavis:[127.0.0.1]:10024
receive_override_options = no_address_mappings

Zu master.cf hinzufügen:

amavis       unix  -       -       n       -       2       lmtp 
    -o lmtp_data_done_timeout=1200
    -o lmtp_send_xforward_command=yes
    -o disable_dns_lookups=yes
    -o max_use=20
127.0.0.1:10025 inet n  -       n       -       -       smtpd
    -o content_filter=
    -o local_recipient_maps=
    -o relay_recipient_maps=
    -o smtpd_delay_reject=no
    -o smtpd_restriction_classes=
    -o smtpd_client_restrictions=
    -o smtpd_helo_restrictions=
    -o smtpd_sender_restrictions=
    -o smtpd_recipient_restrictions=permit_mynetworks,reject
    -o smtpd_data_restrictions=reject_unauth_pipelining
    -o smtpd_end_of_data_restrictions=
    -o mynetworks=127.0.0.0/8    -o smtpd_error_sleep_time=0
    -o smtpd_soft_error_limit=1001
    -o smtpd_hard_error_limit=1000
    -o smtpd_client_connection_count_limit=0
    -o smtpd_client_connection_rate_limit=0
    -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks

Zuletzt werden postfix, amavis und clamav neu gestartet:

/etc/init.d/postfix restart
/etc/init.d/amavis restart
/etc/init.d/clamav-daemon restart

Testen der Konfiguration

Zum Testen genügt es eine Mail an den Mailserver zu schicken und sich danach die Header-Informationen anzuschauen. Finden sich ähnliche Header wie die folgenden in der Mail wieder, so wird amavis aufgerufen.

X-virus-scanned: Debian amavisd-new at domain.tld
X-spam-flag: NO
X-spam-score: 2.898
X-spam-level: **
X-spam-status: No, score=2.898 required=6.31 tests=[SPF_PASS=-0.001, TVD_SPACE_RATIO=2.899]

Des Weiteren kann man mit folgendem Befehl testen, ob Spam erkannt wird:

sendmail john@example.com < /usr/share/doc/spamassassin/examples/sample-spam.txt

… oder Viren:

telnet localhost 25
HELO localhost
MAIL FROM: <user@change_to_my_domain.tld>
RCPT TO: <user@change_to_my_domain.tld>
DATA
From: virus-tester
To: undisclosed-recipients:;
Subject: amavisd test - simple - spam test pattern
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
.
 
quit

Spamassassin Konfiguration

Ans Ende der Datei “/etc/spamassassin/local.cf” anfügen:

use_bayes 1
use_bayes_rules 1
bayes_auto_learn 1
bayes_auto_expire 0
 
# pyzor
use_pyzor 1
pyzor_path /usr/bin/pyzor
 
# razor
use_razor2 1
razor_config /etc/razor/razor-agent.conf

/etc/spamassassin/v312.pre:

loadplugin Mail::SpamAssassin::Plugin::DKIM

/etc/spamassassin/v320.pre:

loadplugin Mail::SpamAssassin::Plugin::Shortcircuit
loadplugin Mail::SpamAssassin::Plugin::Rule2XSBody

Razor konfigurieren:

su - amavis
razor-admin -create

Spamassassin-Regeln neu laden:

sa-update

Automatische Updates

Um spamassassin voll auszureizen, richten wir einen cronjob ein über welchen jede Nacht die Regeln auf den neuesten Stand gebracht werden (als root ausführen!):

/usr/local/sbin/updateSpamassassin:

#!/bin/bash
 
sa-update &> /dev/null
sa-compile &> /dev/null
 
exit 0
crontab -e
42 3 * * * /usr/local/sbin/updateSpamassassin &> /dev/null

Ham/Spam aus /var/vmail lernen

Nun erstellen wir noch ein Skript, welches Spam, bzw. Ham aus den Mailboxen der Benutzer lernt (aus den Ordnern “INBOX” und “Junk”). Dieses Skript rufen wir wöchentlich über einen Cronjob auf.

/usr/local/sbin/trainSpamassassin:

#!/bin/bash
 
VMAILDIR="/var/vmail"
SADIR="/var/lib/amavis/.spamassassin"
DBPATH="/var/lib/amavis/.spamassassin/bayes"
 
cd $VMAILDIR
for domain in $(find ./ -maxdepth 1 -not -name "." -type d); do
        domaindir="$VMAILDIR/$domain"
        cd $domaindir
        for user in $(find ./ -maxdepth 1 -not -name "." -type d); do
                maildir="$domaindir/$user/maildir"
                inbox="$maildir/cur"
                junk="$maildir/.Junk/cur"
 
                echo "Learning ham from $inbox"
                sa-learn --ham --showdots --dbpath $DBPATH $inbox
                echo "Learning junk from $junk"
                sa-learn --spam --showdots --dbpath $DBPATH $junk
        done
done
 
chown -R amavis:amavis $SADIR

Nun noch das Skript in die crontab aufnehmen (als root ausführen!):

crontab -e
33 4 * * 0 /usr/local/sbin/trainSpamassassin &> /dev/null

Globale sieve-Regeln

Um dem Benutzer das Erstellen von sieve-Regeln für Spam zu ersparen, fügen wir in die Datei “/var/vmail/default.sieve” folgende Zeile ein, um Spam-Mails automatisch in den Ordner “Junk” zu verschieben (sieve wurde schon in Teil 5 dieser Serie konfiguriert):

require ["fileinto"];
# Move spam to spam folder
if header :contains "X-Spam-Flag" ["YES"] {
  fileinto "Junk";
  stop;
}

dspam

Die Konfiguration von dspam wird nachgereicht.

Quellen:

http://workaround.org/articles/ispmail-etch/#step-5-deliver-emails-through-the-dovecot-lda

http://www200.pair.com/mecham/spam/spamfilter20090215.html#amavisconfig

http://wiki.rootforum.de/mailserver/postfix/clamav_amavisd

http://www.howtoforge.com/virtual-users-domains-postfix-courier-mysql-squirrelmail-debian-lenny-p3

http://www.tuxj0b.de/HOWTO_Mailserver_mit_Postfix_Dovecot_Antispam_und_PostgreSQL_Backend

Der neue Server: Teil 4 apache

Nachfolgend stelle ich vor, wie man apache2 inkl. php, sowie ruby über fastcgi installiert. php, bzw. ruby über fastcgi einzubinden bietet den Vorteil, dass die Skripts immer mit Benutzerrechten und nicht mit den rechten des Webserver ausgeführt werden. Zudem kann man so für jeden vHost eine eigene php.ini anlegen.

Installation und Konfiguration

aptitude install apache2 apache2-suexec libapache2-mod-fcgid php5-cgi

Dieser Befehl installiert das apache2- und php5-Grundsystem. Ruby werden wir später installieren, sobald apache und php funktionieren.
Nun aktivieren wir einige apache2-mods:

a2enmod ssl
a2enmod rewrite
a2enmod suexec
a2enmod fcgid
/etc/init.d/apache2 force-reload

Nun legen wir noch einen Benutzer an, unter dem Skripts ausgeführt werden, die nicht direkt einem bestimmten Benutzer zugeordnet werden können (wichtig ist, dass dieser Benutzer eine GID>100 hat):

adduser --system --group --no-create-home www-user

Jetzt ist es an der Zeit die vHost-Strukturen unter “/var/www/” anzulegen. Für jeden vHost wird ein eigener Ordner erstellt und enthält mehrere Unterordner:

  • conf – enthält die php.ini, sowie die fcgi-Konfiguration
  • docs – das Webroot
  • log – enthält die Log-Dateien
  • tmp – für temporäre Dateien
mkdir /var/www/example.com
cd /var/www/example.com/
mkdir conf
mkdir docs
mkdir logs
mkdir tmp
cd /var/www/
chmod 755 -R example.com

Als Nächstes legen wir unter “/var/www/example.com/conf” einen Symlink auf “/etc/php5/cgi/php.ini” an:

ln -s /etc/php5/cgi/php.ini /var/www/example.com/conf/php.ini

Das hat den Vorteil, dass alle vHosts standardmäßig die gleiche php.ini benutzen, man diese aber sehr leicht austauschen kann, falls man bestimmte vHost-spezifische Anpassungen vornehmen muss.
Dann legen wir noch einen fcgi-Starter an:

/var/www/example.com/conf/php-fcgi.conf:

#!/bin/sh
PHPRC="/var/www/example.com/conf"
export PHPRC
#PHP_FCGI_CHILDREN=3
#export PHP_FCGI_CHILDREN
exec /usr/bin/php5-cgi
chmod 755 /var/www/example.com/conf/php-fcgi.conf

Wenn man nun einen neuen vHost erstellt, muss nur dieser komplette Ordner kopiert werden, die Zeile “PHPRC=”/var/www/example.com/conf” angepasst werden, sowie das immutable-bit für die Datei php-fcgi.conf, bzw. php.ini gesetzt werden.

chattr +i /var/www/<ORDNERNAME>/conf/php-fcgi.conf
chattr +i /var/www/<ORDNERNAME>/conf/php.ini

Jetzt muss nur noch eine vHost-Konfiguration für apache angelegt werden. Hierfür legen wir unter “/etc/apache2/sites-available/example.com” ein Template an, welches dann kopiert und angepasst werden kann:

<VirtualHost *:80>
        SuExecUserGroup {USER} {GROUP}
 
        ServerName {SRV_NAME}
#       ServerAlias {SRV_ALIAS}
        ServerAdmin {SRV_ADMIN}
 
        DocumentRoot {DOC_ROOT}
        AddHandler fcgid-script .php
        <Directory {DOC_ROOT}>
                FCGIWrapper {CONF_ROOT}/php-fcgi.conf .php
                Options +SymLinksIfOwnerMatch +MultiViews +ExecCGI -Indexes
                AllowOverride FileInfo
                Order allow,deny
                allow from all
        </Directory>
 
        ErrorLog {LOG_ROOT}/error.log
        CustomLog {LOG_ROOT}/access.log combined
        LogLevel warn
        ServerSignature Off
</VirtualHost>

Um den vHost zu aktivieren, muss man noch folgenden Befehl absetzen:

a2ensite <VHOST_NAME>

Danach noch die apache-Konfiguration neu einlesen und der vHost ist einsatzbereit.

Quellen:
http://wiki.hetzner.de/index.php/Apache_PHP5_fcgi_und_SuExec

php-Addons

aptitude install php5-gd php5-imagick php5-mcrypt php5-mysql php5-pgsql php5-imap php5-suhosin

gd und imagick sind hierbei Bibliotheken zur Bildmanipulation, mcrypt bietet Verschlüsselungsfunktionen, mysql und pgsql sind für den Datenbankzugriff, imap bietet Funktionen zur Interaktion mit einem IMAP-Server und suhosin ist eine Sicherheitserweiterung für php.

ruby

Nun folgt noch die Installation von ruby und ruby on rails – ebenfalls als fastcgi:

 aptitude install ruby rdoc irb rubygems libfcgi-ruby1.8 libmysql-ruby libpgsql-ruby rails libopenssl-ruby1.8

Da fastcgi schon konfiguriert ist, funktioniert ruby, bzw. RoR ohne weitere Konfiguration.

rails über gem installieren

Alternativ kann man rails auch über gem, anstatt über aptitude installieren. Dazu führt man diesen Befehl aus:

gem install rails

Und ändert anschließend “/etc/profile” und nimmt “/var/lib/gems/1.8/bin” in $PATH mit auf (vor “export PATH” hinzufügen):

# add rails to path
PATH="$PATH:/var/lib/gems/1.8/bin"

Quellen:
http://howtoforge.net/ruby_on_rails_debian_etch

Der neue Server: Teil 3 svn, mysql, postgres

Mit diesem Beitrag beginnt nun eine kleine Reihe, wie man verschiedene Serverdienste installiert und konfiguriert. Angefangen wird mit dem Versionskontrollsystem svn (auch unter dem Namen subversion bekannt) und zwei verschiedenen Datenbanksystemen: mysql und postgreSQL.

subversion

SVN wird über den Internet-Superserver xinetd betrieben und hört standardmäßig auf Port 3690. Die Repositories samt ihrer Konfigurationsdateien werden später unter “/var/svn” liegen und der Server wird unter dem Benutzer “svn” laufen.

Zunächst installieren wir xinetd und svn:

aptitude install xinetd subversion

Danach erstellen wir den svn-Benutzer:

adduser --system --group --no-create-home svn

Jetzt registrieren wir Port 3690 für svn:

/etc/services:

# Local services
svn 3690/tcp # subversion
svn 3690/udp # subversion

… erstellen den Ordner “/var/svn”:

mkdir /var/svn/
chown svn: /var/svn/
chmod 755 /var/svn/

… und konfigurieren xinetd, damit er auf Port 3690 Verbindungen für svn entgegennimmt und sie an den svnserve-Server weitergibt:

/etc/xinetd.d/svn

# default: on
# description: Subversion server process
service svn
{
    disable             = no
    socket_type         = stream
    protocol            = tcp
    user                = svn
    wait                = no
    port                = 3690
    server              = /usr/bin/svnserve
    server_args         = -i -r /var/svn/
}

Nun kann man mit dem telnet-Befehl von einem anderen Rechner aus testen, ob svn auf Port 3690 lauscht:

telnet SERVER_IP 3690

Die Ausgabe sollte dann so aussehn:

Trying SERVER_IP...
Connected to SERVER_IP.
Escape character is '^]'.
( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries commit-revprops depth log-revprops partial-replay ) ) ) Connection closed by foreign host.

Mittels des svnadmin-Tools kann man nun Repositories anlegen, verändern, löschen, …

svnadmin create --fs-type fsfs /var/svn/testRepo

Was man mit svn alles anstellen kann, wird hier sehr ausführlich beschrieben: http://svnbook.red-bean.com/. Dieses Buch ist wohl das Standardwerk, wenn es um svn geht und ein weiterer Stern am O’Reilly-Himmel und das Tollste ist: die Online-Version kostet nicht einmal was.

mysql

Man mag von mysql halten, was man will, doch es ist (leider) das Standard-Datenbanksystem für Web-Anwendungen (ein paar Gedanken zu mysql kann man hier finden). Der Vorteil von mysql ist, dass es sehr einfach in der Installation und Handhabung ist, die Nachteile…. naja, findets selbst heraus.

aptitude install mysql-server

Während der Installation wird man nach einem Passwort für den mysql-root Benutzer gefragt. Danach kann man ggf. noch die Konfiguration anpassen (liegt unter “/etc/mysql/my.cnf“). Ein gutes Beispiel für eine mysql-Konfiguration kann man hier finden: http://forum.rootforum.de/viewtopic.php?f=104&t=36343. Eine Anmerkung: wenn man die empfohlene Konfiguration auf rootforum.de benutzt und über phpMyAdmin auf die Datenbank zugreifen will, sollte man die Zeile “skip_show_database” auskommentieren, ansonsten sehen die Benutzer (root ausgenommen) ihre Datenbanken nicht.

Da wir nicht nur eine optimierte Installation, sondern auch eine sichere wollen, führen wir nun noch das “mysql_secure_installation”-Skript aus und beantworten alle Fragen, abgesehen von der über das mysql-root Passwort, mit der Standardantwort.

Quellen:

http://forum.rootforum.de/viewtopic.php?f=104&t=36343

postgres

Kommen wir zu einem richtigen Datenbanksystem: postgres. postgres ist ein freies, quelloffenes (open-source auf “Neudeutsch”) Datenbanksystem, welches komplett ANSI-SQL92 konform ist (das kann manch kommerzielles Datenbanksystem nicht einmal von sich behaupten), unterstützt unter anderem ACID-Transaktionen und Stored Procedures und weitere fortgeschrittene Datenbank-Konzepte. Es erfreut sich einer immer größer werdenden Beliebtheit und löst mysql in vielen Gebieten ab. Dennoch will ich hier nicht zu viel Werbung machen. Jeder sollte sich selbst Gedanken über das Datenbanksystem machen, das er einsetzt und warum er es einsetzt. Doch wenn man ein Projekt hochziehen will, bei dem man auf fortschrittliche Datenbank-Konzepte zurückgreift, bleiben im open-source Umfeld nicht viele Lösungen übrig.
Die Installation gestaltet sich ähnlich einfach wie bei mysql:

aptitude install postgresql-8.3

Die Konfiguration gestaltet sich etwas anders als die von mysql. Sie ist im wesentlichen mehr an Oracle angelehnt. Über die Datei “pg_hba.conf” kann man Zugriffsrechte vergeben. Wenn man einen Benutzer anlegt, wird standardmäßig auch eine Datenbank mit dem selben Namen erstellt, autoincrement-Werte werden etwas anders definiert als bei mysql, des Weiteren heißen einige Datentypen geringfügig anders, doch die postgres-Dokumentation hilft hier weiter: http://www.postgresql.org/docs/current/static/.
Beispielhaft hier noch Code, wie man einen Benutzer anlegen kann:

su - postgres
createuser -P

Danach wird man nach dem Passwort und der Benutzerrolle gefragt und man kann mit folgendem Code auf die postgres-Konsole zugreifen:

psql -W <Tabellenname>

In einem weiteren Teil gehe ich dann darauf ein, wie man phpMyAdmin und phpPgAdmin einrichtet.