Crawler: Plage oder Segen?

Jeder von uns, der eine Website hat freut sich wohl, wenn den Google Crawler regelmäßig vorbeischaut und dabei möglichst alle neuen schon nach wenigen Minuten in den Index befördert. Da der Google Crawler dabei auch automatisch auf die Performance einer Website achtet um kleine Seiten nicht zu überlasten, fällt es auch nicht weiter auf, wenn er gerade am Werk ist.

Aber leider gibt es nicht nur den Google Crawler sondern mittlerweile eine unüberschaubar große Anzahl davon. Heute hat sich also ein neuer Crawler ans Werk gemacht und meine Website im Turbogang mit Anfragen beschossen. Das ist für den kleinen V-Server dann doch etwas zu viel geworden und er hatte innerhalb kürzester Zeit eine Auslastung von 4500%!

Aber wie kann man sich nun vor solchen Crawlern schützen und möchte man das auch. Wenn man nämlich einen Crawler blockiert, dann kann der Dienst dahinter die Website nicht mehr indizieren und man verliert eventuell neue Nutzer, die auf die eigene Website über diesen Dienst aufmerksam geworden wären. Daher habe ich bei meiner Website nicht kategorisch alle Crawler außer denen der großen Suchmaschinen ausgeschlossen.

Einzelne Crawler sperren

Um Crawler den Zugriff auf die eigene Website zu verweigern setzt man eine Datei mit dem Namen robots.txt ein. Nachdem ich also den Namen des Crawlers über die Logfiles meines Servers rausgefunden hatte, konnte ich ihn zukünftig ausschließen, indem ich folgende Zeilen zur robots.txt Datei hinzugefügt habe:

User-agent: 008
Disallow: /

Das Problem an der Sache ich nur, dass der Crawler diese Änderung nicht sofort bemerkt. Eventuell prüft er die Datei ja nur einmal pro Stunde oder sogar nur einmal am Tag oder in der Woche. Bis er also aufhört die Website mit Anfragen zu überfluten müssen andere Maßnahmen getroffen werden.

Zugriffe von einer IP-Adresse blockieren

Ich musste also nun den Zugriff durch den Crawler anhand seiner IP-Adresse blockieren. Das geht am einfachsten über die Datei .htaccess die sich meistens im Wurzelverzeichnis der Website befindet. Dort habe ich folgende Zeilen eingefügt:

# block potentially harming clients
order allow,deny
deny from 77.45.136.22
deny from 91.218.229.49
allow from all
# END: block potentially harming clients

Ich habe hier in diesem Beispiel zwei IP-Adressen blockiert. Was es mit der zweiten auf sich hat erkläre ich euch gleich. Ihr könnt hier also auch mehrere IP-Adressen blockieren, müsste aber pro Adresse eine Zeile verwenden. Damit verhindert ihr zwar die Anfrage selbst nicht (was auch nicht möglich ist) aber die Anfrage wird hierbei vom Apache-Server direkt zurückgewiesen, ohne dass beispielsweise WordPress etwas davon mitbekommt und anfängt die angeforderte Seite zu generieren. Wenn der Crawler intelligent ist, hört er auch recht bald auf eure Seite zu lesen und schaut sich vielleicht gleich mein eure veränderte robots.txt Datei an.

Hilfe gegen die bösen Jungs da draußen

Leider ist die robots.txt Datei nur eine Bitte an einen Crawler, was sie mit eurer Website tun soll. Er kann diese Information aber natürlich auch einfach ignorieren und eure Website trotzdem auslesen. Dann sollte das Blockieren mittels .htaccess Datei funktionieren, solange es ein Crawler ist, hinter dem keine bösen Absichten stecken. Denn sobald ihr den Crawler blockiert, bekommt er das natürlich mit. Er könnte dann einfach die IP-Adresse wechseln und erneut eure Seite belagern. Damit er das aber nicht so schnell mitbekommt, könnt ihr einen kleinen Trick anwenden. Oft werden solche Crawler von Programmieren eingesetzt, die den gesamten Inhalt eurer Website lesen wollen. Sie prüfen dabei vermutlich auch, ob die Seite erfolgreich angefordert werden konnte (Status Code 200) oder ob es eine erfolgreiche Weiterleitung gab (Status Code 301/302). Wieso also nicht dem Crawler einfach eine Seite zurückliefern, die Inhalt enthält, nicht aber den, den er wollte. Oder ihn einfach auf eine andere Seite weiterleiten.

Ich leite solche Angreifer gerne auf “Das Ende des Internets” um. Das ist eine witzige Seite, die wie eine typische Internet Explorer-Fehlerseite aussieht und andeutet, dass man das Ende des Internet erreicht hat. Um das zu tun fügt ihr einfach folgende Zeilen in eure .htaccess Datei ein:

# rewrite unwanted clients to the end of the internet
RewriteCond %{REMOTE_ADDR} ^77\.45\.136\.22 [OR]
RewriteCond %{REMOTE_ADDR} ^91\.218\.229\.49
RewriteRule ^(.*)$ http://www.weirdity.com/internet/eoti.html [L]
# END: rewrite unwanted clients to the end of the internet

Wenn ihr hier mehrere IP-Adressen angeben möchtet, dann müsst ihr hinter jeder Zeile, außer der letzten, noch [OR] einfügen. Außerdem müssten die Punkte mit einem vorangestellten Backslash markiert werden.

Wenn ihr zuvor schon den vorherigen Code zum Blockieren einer IP-Adresse eingefügt habt, dann müsst ihr diesen auskommentieren (indem ihr vor jede Zeile ein # Zeichen einfügt), damit die Zugriffe nicht mehr blockiert, sondern stattdessen umgeleitet werden.

Der Nutzer des Crawlers merkt im Optimalfall davon nichts. Wenn er sich dann aber im Nachhinein die gecrawlten Seiten ansieht, wird er sich über deren Inhalt wohl sehr ärgern.

Fazit

Ich habe mit den hier beschriebenen schon eingie Angriffe bzw. unbeabsichtigte Überlastungen durch Crawler abwenden können. Auch mein Server läuft gerade wieder mit gemächlichen 5% Auslastung vor sich hin. Diese Maßnahmen schützen einen zwar nicht vor professionellen oder gut organisierten Angriffen, aber gegen die oft genannten “Script-Kiddies” sollten sie ausreichen. Die suchen sich dann einfach eine Website, die sie einfacher angreifen können.

Ach ja und jetzt noch zu der zweite IP-Adresse. Diese stammt wirklich von einem Angreifer. Der wollte aber nicht meinen Server durch viele Anfragen überlasten, sondern viel schlimmer noch, er wollte Schadcode auf meinen Server laden. Dazu hat er versucht die Sicherheitslücke in der TimThumb Funktion auszunutzen, auf die ich auch weiter unten in meinem Artikel Plugins und Sicherheit: Sicherheitslücke in Filedownload Plugin geschlossen kurz eingegangen bin. Aber zum Glück verwende ich kein Plugin oder Theme, das diese Funktion nutzt bzw. eine unsichere Version von TimThumb verwendet.

Um SOAP nutzen zu können, muss es über die php.ini Datei aktiviert werden oder in das Verzeichnis für die Erweiterungen (z.B. unter /usr/lib64/php5/extensions). Was aber, wenn die SOAP Bibliothek nicht installiert ist? Dann muss man es je nach Betriebssystem nachinstallieren. Unter Linux geht das über die Paketmanager oft am einfachsten.

Für openSUSE könnt ihr hierfür den Paketmanager YAST verwenden. Der Befehl dazu lautet wie folgt:

yast -i php5-soap

Der Vorteil bei der Installation über den Paketmanager: Die Bibliothek wird auch gleich in die bestehende Konfiguration eingetragen. Somit könnt ihr direkt nach der Ausführung des Befehls loslegen. Solltet ihr noch nie mit Webservices gearbeitet haben, dann findet ihr in der PHP Doku die wichtigsten Funktionen von SOAP in PHP.

Jetzt viel Spaß oder auch viel Ärger mit SOAP

Die Grundlegenge Ordnerstruktur

Es gibt keine fest vorgegebene Struktur für ein Repository. Es hat sich aber eine Struktur herausgebildet, die von den meisten Projekten, die Subversion einsetzen benutzt wird. Diese wird auch in der SVN-Referenz (deutsche Übersetzung) beschrieben. Dazu werden im Hauptverzeichnis folgende drei Ordner erstellt:

/
	trunk/
	branches/
	tags/

Solltet ihr mehrere Projekte in einem Repository verwalten, dann macht es Sinn für jeder eine solche Ordnerstruktur anzulegen:

/
	projekt1/
		trunk/
		branches/
		tags/
	projekt2/
		trunk/
		branches/
		tags/

Neues Repository mit dieser Ordnerstruktur erzeugen

Am besten erzeugen wir also gleich zu Beginn eines neuen Projekts eine solche Struktur. Gehen wir einfach mal von einem einfachen Repository mit nur einem Projekt aus. Ich möchte euch kurz die notwendigen Befehle aufzeigen um ein Repository für nur ein Projekt mit einer solchen Ordnerstruktur zu erzeugen.

Zuerst einmal erstellen wir in einem beliebigen Ordner ein neues Repository um dieses anschließend verwenden zu können:

svnadmin create /var/svn/public/myproject

Um nun die notwendigen Verzeichnisse zu erzeugen gibt es zwei Möglichkeiten:

1. Auschecken des Repositories, erzeugen der Ordner und commit der Ordnerstruktur
2. Direktes erzeugen der Ordner im Repository

Die erste Variante bietet sich an, wenn man gleich mehrere Projekte mit der Ordnerstruktur erzeugen möchte. Ich zeige euch hier kurz, welche Befehle dabei in Unix-Systemen notwendig wären:

cd ~
mkdir project
cd project/
svn checkout http://kau-boys.de/svn/myproject
cd myproject/
mkdir trunk tags branches

Jetzt müssen wir die Ordner zum Hinzufügen in das Repository markieren mit dem Befehl svn add:

svn add trunk tags branches

A         trunk
A         tags
A         branches

Jetzt können wir diese Ordnerstruktur in das Repository commiten:

svn commit -m "Import der initialen Ordnerstruktur"

Adding         branches
Adding         tags
Adding         trunk

Committed revision 1.

Die andere Möglichkeit ist wesentlich einfacher und erfordert nur einen einzigen Befehl. Dieser erzeugt die Ordnerstruktur direkt im Repository. Auch hier wäre es möglich die Ordner gleich für mehrere Projekte anzulegen (was ihr am besten mit mehreren Befehlen macht):

svn mkdir -m "Import der initialen Ordnerstruktur" \
	file:///var/svn/myproject/trunk \
	file:///var/svn/myproject/tags \
	file:///var/svn/myproject/branches

Committed revision 1.

Wie ihr seht ist diese Variante sehr viel einfacher. Gerade für den Administrator eines Repositories ist er praktischer. Man könnte den z.B. den gesamten Prozess zur Erzeugung eines Repositories und der Ordnerstruktur in einem Skript zusammenfassen, dass alle notwendigen Befehle automatisch hintereinander ausführt.

Das richtige Verzeichnis auschecken

Ganz wichtig ist es nun aber, dass ihr auch das richtige Verzeichnis benutzt um euer Projekt zu starten. Solltet ihr die Ordnerstruktur wie in der ersten Variante erzeugt haben, wechselt in eure Working Copy und benutzt dort den Befehl svn switch um auf das trunk Verzeichnis zu wechseln:

cd ~/myproject
svn switch http://kau-boys.de/svn/myproject/trunk

D    trunk
D    branches
D    tags

Wie ihr sehen könnt, wurden die Ordner gelöscht, da ihr euch nun “im Ordner trunk” befindet. In diesem könnt ihr nun eure Dateien des Projekts commiten.

Wenn ihr die Ordnerstruktur wie in Variante 2 erzeugt habt, dann müsst ihr lediglich das richtige Verzeichnis auschecken. Gebt also direkt den trunk Ordner bei auschecken an:

cd ~
svn checkout http://kau-boys.de/svn/myproject/trunk myproject

Checked out revision 1.

Damit der Ordner aber dabei nicht trunk heißt geben wir beim checkout Befehl gleich den Namen des Ordners an, den unser Projekt nachher haben soll, also in diesem Fall myproject.

Fazit

Ihr habt nun also gesehen, wie man eine gute Ordnerstruktur für Subversion-Projekte anlegt. Falls ihr euch aber fragt, wieso das so wichtig ist, dann seht euch mal Kapitel 4 der SVN-Referenz (deutsche Übersetzung) an. Ich mal bei einem Projekt zwar einen Ordner trunk erzeugt aber diesen als Root-Verzeichnis meines Repositories benutzt. Als ich dann (ca. 10000 Commits später) dann doch mal branches einsetzen wollte, bekam ich natürlich Probleme, da ich dann erst die Unterverzeichnisse erzeugt habe und alle anderen Order und Dateien per svn move in den Ordner trunk verschieben musste. Dabei bleibt zwar die History aller Dateien erhalten, aber jeder Benutzer musste den Pfad zum Repository aktualisieren und dann in den neuen trunk Ordner wechseln.

Wenn ihr euch also schon immer zu Beginn eines neuen Projekts die Ordner erzeugt spart ihr euch nachher viel Arbeit. Selbst wenn ihr denkt, niemals so komplex zu werden, dann seht mal in der SVN-Referenz unter dem Stichpunkt Feature-Release nach. So etwas könnte auch euch mal passieren. Also spart nicht an dem einen Befehl und den drei Ordnern

Installieren von Subversion

Die Installationshilfen von Ubuntu machen einem diesen Schritt ja sehr einfach. Zuerst einmal müssen bei meinem frisch installierten Server die Paketquellen aktualisiert werden. Das macht man mit folgendem Befehl (solltet ihr nicht als “root” angemeldet sein, müsst ihr eventuell noch “sudo ” vor diesen und weiter Befehl setzen):

apt-get update

Anschließend können wir Subversion und die Erweiterung für den Apache-Server installieren, was mit folgendem Befehl passiert:

apt-get install subversion libapache2-svn

Wenn alles geklappt hat ist Subversion auch schon installiert. Um es zu testen könnt ihr den “svn” Befehl auf der Konsole testen und dabei auch gleich feststellen, ob das WebDAV Modul verfügbar ist:

svn --version

WebDAV Ordner einrichten

Zuerst einmal legen wir ein Verzeichnis an, in dem später all unsere SVN-Repositories abgelegt werden:

mkdir /var/svn

Anschließend erstellen wir einen weiteren Unterordner für alle SVN-Repositories, die wir später per WebDAV freigeben möchten:

mkdir /var/svn/public

Erzeugen des ersten öffentlichen Repository

So, nun sind wir bereit unser erstes Repository zu erzeugen und dieses anschließend freigeben zu können. Zuerst einmal müssen wir das SVN-Repository selbst erzeugen. Dies geschieht mit dem Befehl svnadmin, genauer gesagt mit dem Unterbefehl svnadmin create:

svnadmin create /var/svn/public/myproject

Der Befehl erzeugt keine Ausgabe, lass euch also nicht irritieren, wenn da nicht viel passiert. Um zu kontrollieren, ob das Erstellen des SVN-Repositories geklappt hat, seht euch einfach mal den Inhalt des Ordners an:

cd /var/svn/public/myproject
ls -l

total 24
drwxr-xr-x 2 root root 4096 2011-05-22 13:21 conf
drwxr-sr-x 6 root root 4096 2011-05-22 13:21 db
-r--r--r-- 1 root root    2 2011-05-22 13:21 format
drwxr-xr-x 2 root root 4096 2011-05-22 13:21 hooks
drwxr-xr-x 2 root root 4096 2011-05-22 13:21 locks
-rw-r--r-- 1 root root  229 2011-05-22 13:21 README.txt

Repository über WebDAV freigeben

Nun müssen wir die Konfiguration des WebDAV Moduls anpassen, damit das Repository von außen verfügbar ist. Dazu öffnen wir die Konfigurationsdatei:

vi /etc/apache2/mods-enabled/dav_svn.conf

Hier müsst ihr in ein paar Zeilen die anführenden Kommentarzeichen entfernen. Eure Konfiguration sollte dann mindestens folgende Zeilen (unkommentiert) enthalten:

<Location /svn>
  DAV svn
  SVNParentPath /var/svn/public
  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /etc/apache2/dav_svn.passwd
  <LimitExcept GET PROPFIND OPTIONS REPORT>
    Require valid-user
  </LimitExcept>
</Location>

Nachdem ihr die Konfiguration gespeichert habt können wir den Zugang für euer öffentliches Repository machen. Wir verwenden hier allerdings eine Benutzer-Autorisierung, damit wir den Schreibzugriff auf das Repository einschränken können. Zum Erstellen eines Benutzers wird folgender Befehl verwendet. Gebt dort anschließend zweimal das neue Passwort des Nutzers ein:

htpasswd -cm /etc/apache2/dav_svn.passwd public

New password:
Re-type new password:
Adding password for user public

Damit die Benutzer auch in das Verzeichnis schreiben können, muss es noch auf den Apache-Benutzer übertragen werden, da wir es ja als root erzeugt haben. Das geschieht mit folgendem Befehl:

chown -R www-data /var/svn/public/

Das war es im Grunde auch schon. Was jetzt noch fehlt ist ein Neustart des Apache-Servers, damit die neue Konfiguration auch geladen wird:

/etc/init.d/apache2 restart

Testen des öffentlichen Repositories

Jetzt könnt ihr das neue öffentliche Repository testen. Navigiert dazu einfach in eurem Browser auf eine eurer Domains und dort in den Unterordner /svn/myproject. Ihr solltet dann in etwa folgendes sehen:

Das war es auch schon. Jetzt habt ihr euern eigenen Subversion Server und könnt dort nach Belieben öffentliche Projekte verwalten. Solltet ihr aber mal ein nicht öffentliches Projekt haben, könnte ihr dieses weiterhin über das svn+ssh: Protokoll betreiben. Dazu müsst ihr es einfach nur direkt im /var/svn Ordner ablegen und dann per SSH für bestimmt Benutzer erreichbar machen. Falls Interesse besteht werde ich das in einem separaten Artikel nochmal kurz erklären.

Fragen und Anmerkungen sind wie immer gerne gesehen!

Da ich alle E-Mail-Adressen meiner Domain ohnehin auf eine einzige Adresse umleiten lassen möchte, habe ich noch einer Möglichkeit in Plesk gesucht und schließlich auch gefunden. Man kann recht einfach einen sogenannten Catch-All E-Mail-Account einrichten. Die Einstellung ist allerdings etwas versteckt.

Catch-All einrichten

Zuerst navigiert ihr über die Startseite über Übersicht eure Domain, für die ihr einen Catch-All erstellen möchtet.

Anschließend klickt ihr auf “E-Mail-Accounts”:

Dort könntet ihr nun einen einzelnen E-Mail-Account anlegen, den ihr dann direkt als Postfach z.B. per POP3 abruft oder eine Weiterleitung einrichtet. Wir möchten aber einen Catch-All einrichten und klicken daher auf “E-Mail-Einstellungen”:

Hier findet ihr endlich die Einstellungen für den Catch-All. Bei einem Catch-All werden bekanntlich alle E-Mails, die an unbekannte Adressen geschickt, aufgefangen. Ihr könnt hier nun entweder eine Adresse angeben, die ihr zuvor als echten E-Mail-Account angelegt habt, oder aber ihr leitet sie an eine externe E-Mail-Adresse weiter, so wie ich es getan habe.

Das war es auch schon. Ab sofort könnt ihr jede beliebige E-Mail-Adresse eures Accounts verwenden und die Mails landen automatisch in eurem Postfach. Nur wenn ihr auch mit dieser Adresse antworten möchtet, müsst ihr dann daran denken in eurem E-Mail-Programm auch die Absender-Adresse entsprechen anzupassen.

Ich hoffe der Tipp konnte euch wie immer weiterhelfen. Über Kommentare würde ich mich wie immer sehr freuen.

Statistiken in Plesk aktivieren

Das Ganze in Plesk zu aktivieren ist eigentlich kein allzu großes Problem. Unter “Domain -> Hosting -> Setup” kann man das jeweilige Statistik-Toll recht einfach aktivieren:

Aber leider hat man dadurch nur in Plesk festgelegt, welches Tool man nutzen möchte und wie man auf die Daten zugreifen kann. Beide Dienste beziehen ihre Daten aus den Apache-Logfiles. Diese müssen aber erst aufbereitet werden. Ich dachte, dass dies automatisch passiert, sobald man die Einstellungen in Plesk vorgenommen hat. Dem war aber nicht so.

Apache-Logfiles manuell auswerten lassen

Wenn die Daten noch nie ausgewertet wurden enthält man auf der Seite, die eigentlich die Statistiken enthalten sollten, folgenden Hinweis:

This is the placeholder for Webalizer statistics. If you see this page that means that Webalizer has not run yet on your server. Webalizer is typically set to run once every 24 hours. If you do not see a change to this page in the next 24 hours contact your server administrator for assistance.

This page has been automatically generated by Server Administrator.

Dummerweise ist man selbst Administrator und weiß auch jetzt nicht weiter. Man kann die Daten erstmalig auswerten lassen, indem man folgenden Befehl über die Konsole ausführt:

/usr/local/psa/admin/sbin/statistics

Nun werden die Apache-Logfiles ausgewertet und für AWStats und Webalizer aufbereitet. Selbst wenn ihr beide Varianten für verschiedene Domains verwendet habt, werden die Daten mit diesem einen Befehl ausgewertet. Damit ihr diesen Befehl nicht ständig manuell ausführen müsst, solltet ihr einen Cronjob (bzw. Crontab oder “geplante Aufgabe”) erstellen, die das z.B. jede Nacht um Mitternacht ausführt.

Wie man einen Cronjob anlegt könnte ihr auf meinem Artikel mit dem Titel Plesk Cronjob für ein PHP-Skript mit Parametern einrichten nachlesen, wobei ihr hier anstelle der PHP Skripts den oben beschriebenen Befehl einfügt. Da der Apache Benutzer auch normalerweise keinen Zugriff auf die notwendigen Ordner hat, solltet ihr den Cronjob für den ROOT Benutzer einrichten.

Ich hoffe, der Artikel konnte euch weiterhelfen. Ich wünsche euch noch viel Spaß beim Studieren eurer Statistiken. Anmerkungen und Kommentare sind natürlich wie immer gern gesehen.

In URLs werden Leerzeichen einfach mit der Zeichenkette %20 ersetzt, aber das alleine führt noch nicht zum Erfolg. Da das Prozentzeichen ein spezielles Zeichen in Rewrite Rules darstellt muss es mit einem Backslash escaped werden. Eine funktionierende Rewrite Rule mit einem Leerzeichen könnte also wie folgt aussehen:

RewriteEngine on
RewriteRule ^kurzer-dateiname.pdf$ dateiname\%20mit\%20Leerzeichen\%20.pdf

Wer also den Dateinamen nicht ändern kann um Leerzeichen zu ersetzen (z.B. durch Unterstriche) kann mit dieser Regel trotzdem einen schöneren/kürzeren Dateinamen über die .htaccess anbieten.

Das war es auch schon. Heute gibt es mal nur einen kurzen Artikel, aber viel mehr gibt es auch nicht dazu zu sagen. Außer vielleicht, dass ihr niemals versuchen solltet ein Leerzeichen in der Zieladresse zu verwenden, da sonst die gesamte .htaccess ungültig wird und der Server einen 500 Fehler für jede Seite zurückliefert.

Ich hoffe der Tipp konnte euch weiterhelfe. Kommentare sind wie immer gern gesehen!

An meinem Geburtstag habe ich dann durch Zufall auf der Suche nach einem anderen Problem gesucht habe unter anderem auf der Website debianroot.de eine super einfache Anleitung gefunden, wie man DEFLATE einfach aktivieren kann.

MOD_DEFLATE aktivieren

Ich habe erfahren, dass DEFLATE bereits bei Apache2 installiert ist und man es nur noch aktivieren muss. Dazu ist ein einziger simpler Befehl notwendig:

a2enmod deflate

Das ist alles! Damit DEFLATE aber auch genutzt werden kann und die Dateien ab sofort komprimiert werden ist es zuerst einmal notwendig den Apache2 neu zu starten. Das geht auf den meisten Systemen mit folgendem Befehl:

/etc/init.d/apache2 restart

Der Befehl a2enmod gibt teilweise die Meldung aus man sollte den Befehl /etc/init.d/apache2 force-reload ausführen, aber das alleine hat bei mir nicht geholfen.

Einrichten der Komprimierung

Damit die Seiten und Dateien aber auch komprimiert werden, muss noch die .htaccess Datei angepasst werden. Hier mal meine aktuelle Anpassung:

# Turn on compression
<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/plain text/html text/xml
  AddOutputFilterByType DEFLATE text/css text/javascript text/x-js
  AddOutputFilterByType DEFLATE application/xml application/xhtml+xml
  AddOutputFilterByType DEFLATE application/rss+xml
  AddOutputFilterByType DEFLATE application/javascript application/x-javascript
</IfModule>

Einige JavaScript Dateien wurden interessanterweise mit dem Content-Type text/x-js ausgeliefert, obwohl weder der Standard Content-Type in HEAD noch das Attribut des STYLE Tags diesen Content-Type angaben. Mit Firebug und YSlow kann man sehr gut kontrollieren ob die Dateien komprimiert werden.

Fazit

Ich habe die Installation und Konfiguration so wie hier beschrieben auf einem Strato V-Server mit Ubuntu sowie auf einem 1&1 Root-Server mit OpenSUSE erfolgreich testen können. Solltet ihr also ein anderes Serverbetriebssystem nutzen, dann kann sich der ein oder andere Befehl unterscheiden.

Durch das Komprimieren aller JavaScript, CSS und HTML Daten konnte ich auf einem System das Ladevolumen um über ein Drittel verringern. Ich finde für zwei Befehle und eine kleine Anpassung der .htaccess ist das ein tolles Ergebnis. Es ist eigentlich schade, dass DEFLATE nicht bei allen Apache2 Installationen standardmäßig aktiviert ist. Denn wer keinen ROOT-Zugriff auf den Server hat wird es wohl nicht ohne weiteres aktivieren können.

Ihr könnte aber in der Ausgabe der phpinfo() Funktion auf einem System mit PHP sehr schnell rausfinden, ob DEFLATE schon aktiv ist. Im Abschnitt “apache2handler” findet ihr ganz unten die Zeile “Loaded Modules”, in der mod_deflate aufgeführt sein sollte. Eventuell ist aber auch mod_gzip aufgeführt, was ebenfalls zur Komprimierung eingesetzt werden kann. Sollte beides nicht vorhanden sein und ihr keinen ROOT-Zugriff haben hilft vermutlich nur ein verzweifelter Anruf beim Support eures Hosters.

Ich hoffe, dass dem ein oder anderen von euch der Tipp ebenso weiterhelfen konnte wie mir. Ich habe mir damit zumindest selbst ein sehr schönes Geburtstagsgeschenk gemacht. Falls ihr sonstige Anmerkungen oder Fragen habt würde ich mich wie immer über einen Kommentar freuen.

Da ein Backup der Domain mittlerweile eine Größe von über 20GB hat reichen die 250GB des 1&1 Backup FTP-Servers nur für 10 Backups. Sobald dieser Speicherplatz verbraucht ist, werden die Daten auf dem Webserver abgelegt. Das fatale dabei ist, dass dadurch der gesamte Speicherplatz des Servers langsam aber sich aufgebraucht wird. Wenn der Speicherplatz belegt ist führt es im schlimmsten Fall dazu, dass MySQL keine temporären Tabellen mehr erzeugen kann und euer Server ist somit nicht mehr in der Lage die Anfragen zu bearbeiten. Also im Klartext: Euer Server funktioniert im schlimmsten Fall nicht mehr.

Daher solltet ihr die Anzahl der Backups begrenzen, wobei ihr am besten einen Wert nehmt, der der Größe eures FTP Backup Servers geteilt durch die durchschnittliche Größe eines Backups entspricht. In meinen Fall habe ich also einen Wert von 10 gewählt, da hierbei noch etwas Luft nach oben ist, sollte doch mal ein Backup größer ausfallen. Die Einstellung könnt ihr in der “Einstellungen für geplantes Backup” vornehmen:

Ihr sollte zur Sicherheit von Zeit zu Zeit überprüfen, ob der gewählte Wert noch der Größe der Backups angemessen ist.

Sollte bei euch bereits ein Backup auf dem Webserver selbst gelandet sein, dann habt ihr leider über Plesk keine Möglichkeit die Backups auf den FTP Backup Server zu verschieben, es sei denn ihr traut euch zu das manuell über die Konsole zu tun. Ich würde euch einfach raten abzuwarten bis aktuellere Backups auf dem FTP Backup Server vorliegen und dann die alten Backups auf dem Server einfach zu löschen. Wenn wie bei mir aber schon der Speicher voll ist solltet ihr auf jeden Fall die ältesten Backups vom Webserver entfernen.

Ich hoffe, dass euch der Tipp weiterhelfen konnte. Unverständlich, dass der kleine Hinweis unter dem Textfeld kein Ausrufezeichen enthält mit dem Hinweis was passiert, wenn man keine Begrenzung angibt. Über Anmerkungen würde ich mich wie immer sehr freuen.

Um einen Cronjob anzulegen navigiert ihr im Hauptmenü zum Abschnitt Server und wählt dort “Geplante Aufgaben”. Anschließend bekommt ihr eine Liste mit allen Benutzern angezeigt, die auf eurem Server vorhanden sind. Jedem dieser Benutzer könnt ihr einen Cronjob zuteilen. Um ein PHP-Skript auszuführen solltet ihr den Benutzer wählen, der auf eurem Server den Apache-Server ausführt. Dies ist meistens der Benutzer namens “wwwrun”. Blättert also einfach auf die entsprechende Seite oder sucht nach dem Benutzer:

Nachdem ihr den Benutzer ausgewählt habt klickt auf “Weiter”. Ihr gelangt nun auf die Seite mit den “Crontab-Aufgaben” für den entsprechenden Benutzer. Hier hat sich also die Crontab Einstellung versteckt. Ihr könnt nun oben eine “Neue Aufgabe hinzufügen”:

In die Felder Minute, Stunde und Tag des Monat könnt ihr entweder eine Zahl eingeben oder einen Stern, um den Cronjob für jeden Wert auszuführen. In dem Beispiel wird als der Cronjob an jedem Tag eines Monat um 00:00 Uhr ausgeführt. Wenn ihr den Cronjob auch jeden Monat und an jedem Tag einer Woche ausführen lassen möchtet, dann tragt unten ebenfalls einen Stern ein.

Wenn ihr ein lokales Programm oder ein PHP-Skript ohne Parameter starten möchtet, könnt ihr einfach den Befehlsnamen in der Feld “Befehl” eintragen. Wenn ihr allerdings etwas in der Form “php /srv/www/vhosts/example.com/httpdocs/skript.php?var1=value” eintragt, dann versucht PHP die Datei mit dem Namen “skript.php?var1=value” zu finden, die es natürlich nicht gibt. Ein sehr einfacher Trick dies zu lösen ist die Verwendung von wget. Dieser Befehlt wird normalerweise dazu genutzt eine Datei von einer Website zu laden. Damit aber nicht eine Datei mit dem Namen “skript.php?var1=value” erzeugt wird, nutzen wir den Parameter “–spider”, der den Download unterdrückt. Wir führen also somit einfach nur ein PHP-Skript auf einer beliebigen URL aus. Sobald alle Einstellungen vorgenommen sind, könnt ihr die Einstellungen mit einem Klick auf “OK” speichern.

Ihr solltet nun in der Übersicht euren eben erzeugt Cronjob sehen können. Sobald der Zeitpunkt, den ihr angegeben habt erreicht ist, sollte das Skript ausgeführt werden. Zu den Cronjobs wird ein Bereicht erstellt und an eine E-Mail-Adress verschickt. Diese könnt ihr über “Einstellungen” eintragen:

Bei meinen Cronjobs wurde bisher noch keine E-Mail verschickt. Eventuell wird auch nur im Fehlerfall eine Mail mit der Fehlermeldung verschickt. Oder aber mein Server leitet die Mail nicht korrekt an den externen 1&1 Mailserver weiter, da es sich bei der E-Mail-Adresse um eine Domain handelt, die er selbst verwaltet. Sobald ich das Rätsel gelöst habe werde ich euch natürlich davon berichten.

Ich hoffe der Artikel konnte euch weiterhelfen. Kennt ihr vielleicht auch noch eine tollt versteckte Funktion? Oder sucht ihr eine bestimmte Einstellung? Über Kommentare würde ich mich wie immmer sehr freuen.

Nun, durch das zunehmende Problem von SPAM werden bei den meisten Mailanbeitern alle Mails von Severn abgelehnt, die nicht als vertrauerswürdiger Mailserver in einer Whitelist eingetragen sind. Der eigene Root-Server ist in diesen Listen allerdings fast nie gelistet. Beim Versuch eine Mail an einen Freemailer wie z.B. GMX zu senden resultiert dann in einer Ablehnung seitens GMX. Diese sehen in der Regel wie folgt aus:

Hi. This is the qmail-send program at sXXXXXXXX.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<user@gmx.de>:
XXX.XXX.XX.XXX does not like recipient.
Remote host said: 550-5.7.1 {mx087} Sorry, your helo has been denied.
550 5.7.1 ( http://portal.gmx.net/serverrules ) Giving up on XXX.XXX.XX.XXX.

Die Lösung des Problems ist die Versendung der Mail über den SMTP-Server von 1&1. Hierbei gibt es allerdings ein kleines Problem. Damit der 1&1 Mailserver nicht als SPAM-Verteiler missbraucht werden kann, muss sich das sendende Skript an diesem Server authentifizieren. Dazu ist eine beliebiege E-Mail Adresse eures Servers notwendig. Ich würde euch empfehlen dazu eine spezielle Adresse wie z.B. “websitesend@example.com” anzulegen.

Das wäre soweit auch kein Problem, allerdings unterstützen einigen Skriptsprachen nicht von Hause aus die SMTP-Authentifizierung an einem Server. Auch PHP bietet leider keinerlei Einstellungen für die Authentifizierung. Lediglich der Mailserver kann angegeben werden, über den die Mail versendet werden soll. Die mail() Funktion von 1&1 könnt ihr also nicht verwenden.

Abhilfe schafft hier eine Mail-Klasse, die auch eine SMTP-Authentifizierung anbieten. Ich nutze schon seit längerem in allen Projekte die PHP-Klasse PHPMailer. Diese bietet auch eine SMTP-Authentifizierung. Einfache Beispiele zur Verwendung der SMTP-Authentifizierung mit PHPMailer findest ihr auch auf der Website von PHPMailer. Ein Beispiel für den Versand einer Mail über den SMTP von 1&1 könnte wie folgt aussehen:

require_once('class.phpmailer.php');
$mail = new PHPMailer();
$mail->CharSet = 'utf-8';
$mail->IsSMTP();
$mail->SMTPAuth = true;
$mail->Host = "smtp.1und1.de";
$mail->Username = "websitesend@example.com";
$mail->Password = "password_for_websitesend";
$mail->AddReplyTo('your_mail_address@example.com');
$mail->Subject = 'Subject of the mail';
$mail->AltBody = 'Text for users without a HTML mail viewer';
$mail->MsgHTML('Text for users with a HTML ready mail viewer');
$mail->AddAddress('user@gmx.de');
if(!$mail->Send()) {
	echo "Fehler beim Senden der Mail: " . $mail->ErrorInfo;
} else {
	echo "Mail wurde erfolgreich versandt!";
}

Zugegebenermaßen sind das sehr vielke Zeilen für den Mailversand einer einzelnen Mail. Aber leider ist es nicht sehr viel kürzen möglich. Damit ihr aber nicht in jedem Skript, in dem ihr eine Mail versenden möchtet, alles von neuem schreiben und bei Änderungen in jedem Skript anpassen müsst, empfiehlt es sich die Zeilen 1.8 in eine PHP-Datei zu exporieren und diese per “require” in das Skript zu importieren, in der ihr die Mail verschicken wollt.

Die Verwendung der PHPMailer Klasse bietet aber auch ein paar Vorteile gegenüber der mail() Funktion von PHP. Ihr könnt nämlich sehr einfach weitere Empfänger hinzufügen, indem ihr die “$mail->AddAddress()” mehrfach anwendet. Es gibt auch eine Funktion für Kopien: “$mail->AddCC()” und blinde Kopien: “$mail->AddBCC()” oder auch Anhänge: “$mail->AddAttachment()”. Seht euch dazu einfach mal die Liste der Methoden an.

Ich hoffe, dass euch die kleine Anleitung helfen konnte. Wenn ihr noch Anmerkungen oder Fragen habt, oder auch eine andere gute PHP-Klasse oder eine entsprechende Funktion für andere Skrtipsprachen kennt, würde ich mich über einen Kommentar sehr freuen.

Der 1&1 Server verwendet Plesk in der Version 9.2. Im ersten Schritt müsst ihr euch im Plesk Panel anmelden anschließend gelangt ihr auf die Startseite wo ihr im Abschnitt Server einen Button für den Backup-Manager finden solltet:

Nachdem ihr den Backup-Manager aufgerufen habt bekommt ihr eine Auswahl an Tools angeboten. Der Punkt “Aktualisieren erklärt sich wohl von selbst. Die anderen stelle ich kurz vor.

Mit dem Tool “Backup erstellen” könnt ihr ein einmaliges Backup druchführen, das sofort ausgeführt wird. Mit dem unter “Einstellungen für geplantes Backup” könnt ihr ein tägliches (bzw. wöchentliches, monatliches) Backup einstellen. Mit dem Punkt “Dateien ins Server-Repository hochladen” könnt ihr ein erstelltes Backup wieder auf den Server kopieren um es anschließend eine Wiederherstellung zu starten. Der Punkt der uns zuerst interessiert ist “Einstellungen für persönliches FTP-Repository”:

Hier tragt ihr die Zugangsdaten für den 1&1 Recovery Server ein. Die Daten dazu findet ihr innerhalb des 1&1 Control-Centers im Bereich “Server-Verwaltung” unter dem Punkt “Server-Backup”. Ein Zugriff auf diesen Server direkt per FTP von eurem Rechner aus wird aber nicht funktionieren, was euch also nicht verwundern sollte. Innerhalb des Netzwerks von 1&1 funktioniert die Verbindung. Nachdem ihr also alle Daten eingetragen habt und auf “OK” geklickt habt, kommt ihr wieder ins Menü des “Backup-Managers” zurück. Dort wählt ihr als nächstes “Einstellungen für geplantes Backup”:

Wichtig ist bei den Einstellungen die Auswahl “Persönlichers FTP-Repository” damit die Daten auch auf dem Backup Server landen und bei einem Ausfall des 1&1 ROOT Servers nicht auch verloren gehen. Wann ihr das Backup starten wollt ist euch überlassen, aber wählt am besten einen Zeitpunkt mit wenigen Zugriffen. Ein Zeitpunkt von 1 Uhr nachts ist z.B. auch nicht gut, wenn ihr viele Besucher aus den USA habt. Wählt in diesem Fall vielleicht eher 6 Uhr, da hier viele Amerikaner schon im Bett liegen und viele Deutsche erst aufstehen. Der Prozess braucht zwar nicht viele Ressourcen, aber ihr habt somit alle Daten eines “Tages” im Backup enthalten. Ihr könnt ein Präfix vergeben, falls ihr das wollt. Eine E-Mail-Adresse für Meldungen über fehlgeschlagene Backups solltet ihr in jedem Fall angeben. Zuletzt auf keinen Fall vergessen “Serverkonfiguration und Inhalt” auszuwählen, da ansonsten nicht die Dateien eures Servers mitgesichert werden.

UPDATE: Ihr solltet auch daran denken die Anzahl der Backups auf einen sinnvollen Wert zu begrenzen. Wieso erfahrt ihr in diesem Artikel: Anzahl der Backups im Plesk Backup-Manager begrenzen.

Man könnte meinen, dass jetzt alles glatt läuft. Leider ist dem aber nicht so. Denn standardmäßig werden die Backups im Ordner “/var/lib/psa/dumps” zwischengespeichert, der sich auf der Partition “/dev/sda6″ befindet. Diese Partition ist oft zu klein um ein Backup zu speichern, bevor es dann auf den FTP-Server verschoben wird. Da hier auch die MySQL Tabellen liegen führt es dann dazu, dass die MySQL Datenbank keinen Platz mehr für temporäre Tabellen für Abfragen erstellen kann und den Dienst bei großen Abfragen verweigert. Ihr müsst also den Speicherort verschieben. Am besten verschiebt ihr ihn auf die größte Partition. Welche das ist könnt ihr mit dem Befehl “df” rausfinden (die zusätzlichen Parameter dienen nur der Übersichtlichkeit), nachdem ihr euch per SSH am Server an angemeldet habt:

s12345678:~ # df -h -x tmpfs
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             9.2G  235M  8.5G   3% /
/dev/sda5             9.4G  2.2G  7.3G  23% /usr
/dev/sda6             9.4G  1.9G  7.5G  20% /var
/dev/sda7             436G   21G  416G   5% /srv

In diesem Beipiel ist die größte Partition “/dev/sda7″, auf welcher der Ordner “/srv” gemountet ist. Ihr verschiebt den Ordner dann mit diesen drei Befehlen:

mv /var/lib/psa/dumps /srv/dumps
rm -rf /var/lib/psa/dumps
ln -s /srv/dumps /var/lib/psa/dumps

Der erste Befehl verschiebt den Ordner nach “/srv” welcher sich in diesem Beipsiel auf der größten Partition befindet, da hier auch die Websites gespeichert sind. Der zweite Befehl löscht den Ordner an seinem ursprünglichen Ort (sollte er dort noch vorhanden sein). Am wichtigsten ist der dritte Befehl. Er erzeugt einen sogenanten “Symbolic Link” also einen Link zu dem neuen Verzeichnis. Dadurch ist es nicht notwendig den Speicherpfad in der Konfiguration von Plesk anzupassen, was über das Plesk Panel ohnehin nicht funktioniert.

Nachdem diese Schritte vollzogen sind, müsst ihr nurnoch abwarten, bis der Zeitpunkt des ersten Backups erreicht ist. Ein Backup kann ohne Probleme eine halbe Stunde oder mehr andauern. Ihr könnt auch zu Testzwecken gerne ein Backup manuell über den Punkt “Backup erstellen” ausführen und einfach einmal nur die Serverkonfiguration speichern. Wenn das Backup erfolgreich verlaufen ist, solltet ihr es über den Reiter “Persönliches FTP-Repository” aufgelistet sehen:

Hier könnt ihr auch ein Backup wiederherstellen. Das habe ich aber bisher zum Glück noch nicht machen müssen. Sobald ich es aber mal durchführen musste (hoffentlich nie) gibt es dazu dann auch einen Artikel.

Ich hoffe der Artikel konnte euch weiterhelfen und ihr konntet eine Backup-Routine dadruch einrichten. Es ist aber schade, dass die Server von 1&1 nicht direkt so konfiguriert sind, dass sie die größte Partition für die Backup-Daten nutzt. Wenn euch zusätzlich noch ein Tipp zu dem Thema einfällt oder ihr Fragen oder Anregungen habt, würde ich mich über ein Kommentar sehr freuen.

Zuerst müsst Ihr entscheiden, wo der Blog installiert werden soll. Entweder direkt auf einer eurer Domains oder auf einer Subdomain. Diese müsst ihr eventuell zuerst über Plesk erzeugen und dort die PHP-Unterstützung aktivieren.

Jetzt meldet Ihr euch per SSH am Server an, das geht unter Unix Systemen direkt mit der Konsole (dem Terminal) und unter Windows mit Tools wie PuTTY. Dort navigiert Ihr zu dem httpdocs Ordner eurer Domain bzw. Subdomain, in die ihr den Blog installieren möchtet. Für eine Domain example.com könnte der Ordner wie folgt aussehen:


cd /var/www/vhosts/example.com/httpdocs


Nicht immer steckt der Plesk vhosts Ordner aber in /var, daher müsst ihr eventuell feststellen, wo er auf eurem Server liegt.

Anschließend müsste Ihr euch die aktuelle Version von WordPress runterladen. Ich tue das hier exemplarisch mit der englischen Version, Ihr könnt aber auch die Deutsche Version runterladen und installieren:


wget http://wordpress.org/latest.zip


Nachdem die Zip-Datei runtergeladen wurde, müsst Ihr Sie entpacken.


unzip latest.zip


Dabei wird der Inhalt in einen Unterordner “wordpress” entpackt. Möchtet Ihr den Blog aber unter einem anderen Ordnernamen aufrufbar machen, könnt Ihr den Ordner “wordpress” einfach umbenennen.


mv wordpress/ blog


Damit habt Ihr WordPress installiert. Wenn ihr nun example.com/blog aufruft und versucht die Konfigurationsdatei zu erstellen bekommt Ihr allerdings eine Fehlermeldung. Beim entpacken wurden alle Ordner dem Benutzer und dessen Gruppe zugeordnet (z.B. root). Damit Ihr mit dem Plesk Benutzer per FTP Zugriff auf das Verzeichnis bekommen könnt, müsst ihr zuerst alle Order und Dateien dem Plesk Benutzer zuordnen. Dazu wechselt Ihr zuerst in den Ordner und passt dann den Besitzer an:


cd blog/
chown dein_plesk_username . -R


Anschließend solltet Ihr noch die Gruppe auf die Standardgruppe von Plesk setzen:


chgrp psacln . -R


Aber auch jetzt könnt Ihr die Konfigurationsdatei noch nicht über das WordPress-Setup erzeugen. Damit Ihr die Installation über den WordPress-Setup-Wizzard durchführen könnt, müsst ihr den ROOT Ordner des Blog dem Benutzer zuordnen, der den Apache-Server ausführt. Um festzustellen, welcher Benutzer dies ist, könnt ihr den Befehl “top” verwenden.


Ausgabe (Auszug): 3113 www-data 18 0 45400 25m 4044 S 0.0 0.5 0:18.57 apache2


Diese Zeile zeigt und, dass der Benutzer www-data den Apache-Server ausführt. Mit STRG+C kehrt Ihr wieder zur Konsole zurück.

Jetzt weisen wir den ROOT Ordner des Blogs dem www-data Benutzer zu (der Punkt am Ende des Befehls gehört dazu):


chown www-data .


Nun könnt Ihr den WordPress-Setup-Wizzard durchführen und euch ein erstes Mal am neuen Blog anmelden. Es gibt allerdings noch ein paar andere Ordner, die Ihr anpassen müsst, damit der Blog vollständig über den Adminbereich verwaltet werden kann. Vor Allem die Ordner “cache”, “uploads”, “upgrades” und eventuell die Order “plugins” und “themes” müssen für den Apache-Benutzer schreibbar sein. Diese befinden sich alle im Ordner “wp-content” und können somit gemeinsam schreibar gemacht werden. Damit Ihr auch per FTP auf solche Dateien zugreifen könnt, solltet Ihr dem “wp-content” Order daher die Gruppe des Apache-Benutzers zuordnen:


chgrp www-data wp-content


Damit die Gruppe auch Dateien dort ablegen darf, müsst Ihr zusätzlich die Zugriffsrechte anpassen:


chmod g+w wp-content/ -R


Hiermit sollten alle notwendigen Anpassungen vorgenommen sein. Ihr habt dadruch die Sicherheitseinstellungen bezüglich der Zugriffsrechte von Plesk beibehalten und lediglich einige problematische Ordner auch für die Gruppe des Apache-Benutzers freigegeben. Ihr solltet auf keinen Fall Pauschal allen Ordnern die Schreibberechtigung für die Gruppe setzen oder gar allen Benutzern alle Rechte, wie es manche Plugins gerne hätten.

Die einzige Einschränkung besteht hier beim Installieren oder Aktualisieren von Plugins bzw. Themes und beim Upgrade von WordPress. Da der Benutzer www-data nicht der Besitzer aller Ordner ist, muss bei diesen Vorgängen der FTP-Benutzer und dessen Passwort eingegeben werden. Wenn Ihr allerdings den Benutzer ändert, verliert Ihr den Zugriff auf den Blog per FTP (zumindest den Schreibzugriff). Dies lässt sich leider oft nicht beheben, da der www-data Benutzer nicht per FTP zugreifen darf und Ihr auch vermutlich keine Möglichkeit habt, den Plesk-Benutzer zum ausfüren des Apache-Servers einzustellen.

Solltet Ihr noch ein Problem gefunden haben oder Anmerkungen haben, würde ich mich über einen Kommentar sehr freuen.