Allerdings waren (zumindest bei mir) nach der Installation noch einige kleine Kniffe notwendig bis der Tunnel vernünftig lief. An dieser Stelle noch kurz der Hinweis, dass als Clients Windows 7 bzw. Windows XP Rechner zum Einsatz kommen.

Problem 1: Clients können sich einwandfrei verbinden, es können jedoch keine Daten empfangen werden.
Lösung: Damit der Server empfangene Daten zu den Clients “weiterrouten” kann ist eine IPTables Regel notwendig. Bei mir brachte folgendes die Lösung:

iptables --table nat --append POSTROUTING  --out-interface eth0 --jump MASQUERADE

Problem 2: Der Tunnel funktioniert grundlegend, die Verbindung “friert jedoch bei gößeren Datenmenegen ein”.
Lösung: Auch hier hilft ein Regeln in den IPTables weiter:

iptables --append FORWARD --protocol tcp --tcp-flags SYN,RST SYN --jump TCPMSS --clamp-mss-to-pmtu

Desweiteren habe ich zur Lösung dieses Problems die MTU und MRU angepasst und auf einen Wert von 1400 eingestellt.
Diese Werte können in der Datei /etc/ppp/pptpd-options angepasst werden.

Problem 3: Clients werden immer wieder vom VPN-Server getrennt.
Lösung: In meinem Fall brachten mich diese Zeilen in den Logfiles auf die Lösung:

No response to 4 echo-requests
Serial link appears to be disconnected.

Offensichtlich antworteten einige Clients nicht (oder nicht zuverlässig) auf die vom Server verschickten LCP-Echo-Requests. Nachdem auch die Erhöhung der maximal nicht beantworteten Requests keine Abhilfe brachte habe ich die Echo-Anfragen schließlich komplett deaktiviert. Dies kann man in der Datei /etc/ppp/options erledigen indem man folgende zwei Werte auf 0 setzt:

lcp-echo-interval 0
lcp-echo-failure 0

Ich hoffe dieser Beitrag kann helfen falls jemand auf die gleichen Probleme stößt, z.B. ich wenn ich in ein paar Monaten mal wieder einen pptpd aufsetze

Aus einem mir unbekannten Grund verabschiedeten sich auf meinem Debian Squeeze Server die PHP-CGI Prozesse mit folgender Meldung im Error-Log:

(mod_fastcgi.c.3001) backend is overloaded; we'll disable it for 1 seconds and send the request to another backend instead

Ich habe zwar eine generelle Lösung für dieses Problem gefunden (Link), diese konnte ich bei meiner Serverkonfiguration aber leider nicht anwenden. Da ich mehrere PHP-CGI-Pools mit verschiedenen UIDs/GIDs starte und diese in der Lighttpd-Config über die Sockets zuordne, konnte ich hier den “var.PID” Teil nicht anhängen. Davon abgesehen hatte es vorher viele Monate ohne diese Änderung funktioniert. Also habe ich mich kurzerhand dazu entschlossen zu PHP-FPM zu wechseln.

Leider gibt es das php-fpm Paket (noch?) nicht im Debian-Squeeze Repository deswegen habe ich die Paketquellen von Dotdeb verwendet. Die Umstellung funktionierte wunderbar einfach, denn man kann PHP-CGI und PHP-FPM problemlos parallel laufen lassen und einen Vhost nach dem anderen umstellen.
Ein recht gutes Tutorial zur Konfiguration von PHP-FPM gibt es hier. Nachdem FPM konfiguriert und gestartet ist kann man in den Vhost-Konfigurationen von Lighttpd einfach den PHP-CGI Teil durch die neue FPM-Konfiguration ersetzen. Das sieht in etwa so aus:

fastcgi.server = ( ".php" =>
      ( "localhost" =>
        (
          "host" => "127.0.0.1",
          "port" => "9001"
        )
      )
    )

Ein enormer Vorteil von PHP-FPM: Man kann mehrere Pools konfigurieren die mit unterschiedlichen UIDs/GIDs laufen, was die Sicherheit auf dem Server ein gutes Stück erhöht.

Mein Fazit: Die Umstellung von PHP-CGI auf PHP-FPM ist relativ leicht zu bewerkstelligen und den Aufwand in jeden Fall wert!

Gearman ist ein Jobserver und ermöglicht es Aufgaben auf verschiedene Prozesse und/oder Maschinen auszulagern. Dabei arbeitet man mit sogenannten “Workern” die auf einem beliebigen Server darauf warten Aufgaben zu erledigen. Besonders schön ist, dass diese Worker ebenfalls in PHP programmiert werden können. Zunächst jedoch ein paar Worte zur Installation.

Auf einem Debian Squeeze System ist die Installation denkbar einfach. Einfach den Jobserver via Aptitude oder apt-get installieren. Das Paket heisst “gearman”. Im init.d Ordner liegt dann auch direkt ein Script mit dem der Server gestartet werden kann:

/etc/init.d/gearman-job-server start

Um den Gearman Server in PHP “ansprechen” zu können benötigt man nun noch die Gearman-Extension welche über PECL installiert werden kann.
Hinweis: Es wird das Paket “php5-dev” benötigt. Falls dieses noch nicht installiert ist sollte man das an dieser Stelle tun.

Dann die PHP-Extenstion über PECL installieren:

pecl install gearman

Hinweis: Falls das Paket hier nicht installiert werden kann weil es eine Beta Version ist, stattdessen folgenden Befehl verwenden:

pecl install gearman-beta

Damit sollte die Extension erstellt sein und kann in der php.ini geladen werden. Dazu einfache folgendes in der php.ini ergänzen:

extension = gearman.so

Hinweis: Da die Worker normalerweise als CLI-Programme laufen, die entsprechende php.ini nicht vergessen.

Nun sollte alles soweit sein, dass Gearman verwendet werden kann.

Zunächst brauchen wir einen Worker welcher im Hintergrund läuft und darauf wartet Aufgaben zu erledigen. Hier ein Beispiel:

<?php
class WorkerExample
{
	private $_GearmanWorker = null;
 
	public function  __construct()
	{
		$this->_GearmanWorker = new GearmanWorker;
		$this->_GearmanWorker->addServer('127.0.0.1', 4730);
 
		$this->_startupWorker();
	}
 
	private function _startupWorker()
	{
		$this->_GearmanWorker->addFunction('foobar', array($this, 'foobar'));
		while($this->_GearmanWorker->work());
	}
 
	public function foobar($Job)
	{
		$params = array();
		$params = unserialize($Job->workload());
 
		// do some work here...
		var_dump($params);
	}
}
 
$Worker = new WorkerExample;

Diesen Worker kann man nun z.B. als worker.php speichern und dann zum testen in einem Screen laufen lassen:

php worker.php

Nun brauchen wir noch ein Script welches diesen Worker aufruft, der sogenannte Client:

<?php
$Client = new GearmanClient();
$Client->addServer('127.0.0.1', 4730);
 
$data = array(
	'foo' => 42,
	'bar' => 1337
);
$data = serialize($data);
$Client->doBackground('foobar', $data);

Wenn nun dieser Client aufgerufen wird sollte man in dem Screen in dem der Worker läuft eine Ausgabe der übergebenen Parameter sehen.
Im Code sieht man sofort dass die IP des Servers auf dem Gearman läuft angegeben wird. Hier kann natürlich auch ein anderer Server als localhost benutzt werden. Mit “doBackground” wird der Worker aufgerufen und das Script läuft direkt weiter ohne auf irgendeine Antwort des Workers zu warten.

Über die vielen weiteren Möglichkeiten des Gearman-Servers kann man sich am besten informieren wenn man einen Blick auf die Methoden der Gearman-Extension auf php.net wirft. Und nun viel Spass beim experimentieren.

Auch ich stand vor diesem Problem bis ich in der mod_rewrite Doku des Lighttpd folgedes entdeckte:

New: For the 1.4.x branch as of 1.4.24 or r2647 from svn:
Rewrites a set of URLs internally in the webserver BEFORE they are handled and checks that files do not exist.

Gute Nachrichten: Ab Version 1.4.24 des Lighty bietet das mod_rewrite Modul die Möglichkeit eine Rewrite-Regel erst anzuwenden nachdem geprüft wurde ob eine Datei existiert. Also genau das Feature was bisher fehlte.
Schlechte Nachricht: Die Lighty Version im stable Repository von Debian ist noch nicht aktuell genug.

Es ist gibt jedoch eine sehr elegante Möglichkeit unter Debian einzelne Pakte aus dem testing Repository zu installieren. Diese ist hier sehr schön beschrieben: Debian mit aktuelleren Paketen – stable und testing

Nachdem man so den Lighty auf eine aktuelle Version gebracht hat ist es relativ einfach htaccess Dateien des Apache zur Verwendung mit Lighttpd zu ändern.

Hier eine kurze Anleitung am Beispiel von WordPress und einem SEO-phpBB:

Zunächst das mod_rewrite Modul in der lighttpd.conf aktivieren:

1
2
3
4
5
6
7
8
9
10

server.modules              = (
            "mod_expire",
            "mod_access",
            "mod_alias",
            "mod_accesslog",
            "mod_compress",
            "mod_fastcgi",
            "mod_auth",
            "mod_rewrite",
)

Dann im entsprechenden Vhost eine Datei mit den Rewrite-Regeln einbinden:

1
2
3
4

$HTTP["host"] =~ "^(lemmingzshadow\.net|www\.lemmingzshadow\.net)$" {
    server.document-root = "/var/www/lemmingzshadow.net/"
    include "/var/www/lemmingzshadow.net/rewrite.conf"
}

Und so sehen Beispielsweise meine Rewrite-Regeln für dieses Blog aus:

1
2
3
4

url.rewrite-if-not-file = (
	"(wp-.+).*/?" => "$0",
	"^/(.+)/?$" => "/index.php/$1"
)

Man sieht direkt, dass die Syntax der einer htaccess Datei sehr ähnlich ist und man seine regulären Ausdrücke nahezu eins zu eins übernehmen kann. Wichtig ist das url.rewrite-if-not-file um wirklich nur dann die Url umzuschreiben wenn die aufgerufene Datei nicht existiert. Die erste Regel dient dazu alle wp-* Verzeichnisse nicht umzuschreiben. Die zweite leitet alle restlichen Anfragen auf die index.php um.

Am Beispiel eines phpBB mit SEO-Urls sieht das ganze z.B. so aus:

1
2
3
4
5
6
7

url.rewrite-if-not-file = (
  "/(.*)-f([0-9]*)/(.*)-t([0-9]*)-s([0-9]*).html"   => "/viewtopic.php?f=$2&t=$4&start=$5",
  "/(.*)-f([0-9]*)/(.*)-t([0-9]*).html"         => "/viewtopic.php?f=$2&t=$4",
  "/(.*)-f([0-9]*)/index-s([0-9]*).html"         => "/viewforum.php?f=$2&start=$3",
  "/(.*)-f([0-9]*)"                        => "/viewforum.php?f=$2",
  "/global/(.*)-t([0-9]*).html"           => "/viewtopic.php?f=1&t=$2"
)

Eine entsprechende htaccess Datei hätte so ausgesehen:

1
2
3
4
5
6
7
8

RewriteEngine on
RewriteBase /
 
RewriteRule ^(.*)-f([0-9]*)/(.*)-t([0-9]*)-s([0-9]*).html viewtopic.php?f=$2&t=$4&start=$5&%{QUERY_STRING} [L]
RewriteRule ^(.*)-f([0-9]*)/(.*)-t([0-9]*).html viewtopic.php?f=$2&t=$4&%{QUERY_STRING} [L]
RewriteRule ^(.*)-f([0-9]*)/index-s([0-9]*).html viewforum.php?f=$2&start=$3&%{QUERY_STRING} [L]
RewriteRule ^(.*)-f([0-9]*)/ viewforum.php?f=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-f([0-9]*) viewforum.php?f=$2&%{QUERY_STRING} [L]

Auch hier können die regeln fast eins zu eins übernommen werden.
Noch ein wichtiger Hinweis zum Schluss: Um Änderungen an den Rewrite-Regeln zu übernehmen muss der Lighttpd neu gestartet werden!

Hoffentlich konnte ich mit diesem kurzem Beitrag dem ein oder anderen die Umstellung von Apache auf Lighttpd erleichtern.

Nachtrag vom 01.06.2010:
lifeofguenter stellte fest, dass das mod_rewrite Modul aktuell wohl nur im 1.4er Trunk entsprechend angepasst ist. Für die 1.5er Versionen des Lighttpd ist die Möglichkeit url.rewrite-if-not-file zu nutzen aktuell wohl noch nicht implementiert.

1

X-policyd-weight:  <strong>DYN_NJABL=ERR</strong> NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 NOT_IN_BL_NJABL=-1.5 CL_IP_EQ_FROM_IP=-2 ...

Die Blacklisten und der entsprechende Score-Wert sind in der Datei /etc/policyd-weight.conf eingetragen. Dort einfacht die veraltete Liste dynablock.njabl.org durch eine gleichwertige aktuelle ersetzen. Ich habe mich für zen.spamhaus.org entschieden.

1
2
3
4
5
6
7
8

<location /myproject_site>
DAV svn
SVNPath /var/svn/myproject
AuthType Basic
AuthName "Subversion Repository"
AuthUserFile /etc/apache2/svn.passwd
Require valid-user
</location>

Damit ist das Repository allerdings unter jeder Domain die auf dem Server läuft erreichbar. (domainname.tld/myproject_site).
Um das Repository nur unter einem Vhost erreichbar zu machen, etwa svn.domain.tld kann man die Zeilen aus der dav_svn.conf in die httpd.conf des Apaches verschieben. Das könnte beispielsweise so ausssehen:

1
2
3
4
5
6
7
8
9
10
11
12
13

<virtualHost 11.22.33.44:80>
        ServerName svn.domain.tld
        DocumentRoot "/var/www/svn.domain.tld/"
        <location />
                DAV svn
                SVNPath /var/svn/myproject
                AuthType Basic
                AuthName "domain.tld Repository"
                AuthUserFile /etc/apache2/svn.passwd
                Require valid-user
                AuthzSVNAccessFile /var/svn/myproject/conf/authz
        </location>
</virtualHost>

Damit ist das Repository dann nur noch unter svn.domain.tld erreichbar.
Eine grundlegende Anleitung zum einrichten eines SVN-Server gibt es z.B. hier: Installing Subversion on Debian Etch Complete…

Ich habe mein System nun so angepasst dass alle Logs von Postfix nur noch in der Datei mail.log gespeichert werden. Dazu müssen in der Datei /etc/syslog.conf einige kleinere Änderungen vorgenommen werden:

Zunächst eine Zeile die etwa so aussieht:

1

*.*;auth,authpriv.none   -/var/log/syslog

ändern in:

1

*.*;auth,authpriv,mail.none    -/var/log/syslog

Mit dieser Änderung erreicht man, dass keine Mail-Logs mehr im syslog auftauchen.

Mit dieser Zeile werden alle Mail-Logs in der Datei mail.log gespeichert:

1

mail.*      -/var/log/mail.log

Dann habe ich noch diese 3 Zeilen auskommentiert, damit keine Informationen mehr in die Dateien mail.info, mail.err und mail.warn geschrieben werden:

1
2
3

#mail.info                      -/var/log/mail.info
#mail.warn                      -/var/log/mail.warn
#mail.err                       /var/log/mail.err

Abschließend muss der Syslog Deamon neu gestartet werden. Das geht mit folgendem Befehl:

1

/etc/init.d/sysklogd restart

Nun werden die Logs von Postfix nur noch in der Datei mail.log gespeichert.
Natürlich ist das nur eine von vielen Möglichkeiten das Logging zu konfigurieren, ich finde diese Lösung allerdings schön einfach und übersichtlich.

Auf einem Debian-Etch System erfolgt die Installation wie folgt:

1
2

wget wget http://ovh.dl.sourceforge.net/sourceforge/mysecureshell/mysecureshell_[versionsnummer]_i386.deb
dpkg -i mysecureshell_[versionsnummer]_i386.deb

Die Config-Datei ist sehr gut dokumentiert und funktioniert eigentlich sofort. Ich habe meine allerdings noch etwas angepasst:

Config-File im Editor öffnen:

1

nano /etc/ssh/sftp_config

und ein paar Parameter anpassen:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# Keine Speedlimits fuer SFTP
GlobalDownload		0
GlobalUpload			0
Download 			0
Upload 			0
 
# FTP-User im Home-Dir einsperren:
StayAtHome		true
VirtualChroot	true
 
#Gleichzeitige Verbindungen pro User etwas erhöhen
LimitConnection		10
LimitConnectionByUser	3
LimitConnectionByIP		3
 
# Wir wollen nicht das gleiche Home-Verzeichnis für alle User, daher wird diese Zeile auskommentiert:
#Home	/home/$USER
 
# Standard Dateirechte nach Bedarf anpassen:
DefaultRights		0664 0755

MySecureShell neu starten:

1

/etc/init.d/mysecureshell restart

Nun kann man z.b. einen User anlegen der per SFTP nur auf einen bestimmten Ordner im Web-Verzeichniss zugreifen kann:

1

useradd -d /var/www/ein_projekt -g www-data -s /bin/MySecureShell marvin

Eine weiteres ausführliches Tutorial zu MySecureShell findet sich unter anderem bei HowtoForge