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.

Heute musste ich dann leider feststellen, dass der Server erneut down war. Da das Monitoring über Pingdom mir leider keine Nachricht auf mein Handy schickte, bemerkte ich es erst nach über 7 Stunden! Hiermit möchte ich mich auch bei allen Entschuldigen, die in dieser Zeit vergeblich versucht haben meinen Blog zu erreichen.

Ich weiß leider noch immer nicht, was genau zu den beiden Ausfällen geführt hat. Die einzige größere Änderung der letzten Tage war die Installation des WP Super Cache Plugins. Falls jemand von euch weiß, ob es damit zu Abstürzen des Apache Prozesses kommen kann, dann wäre ich ihm für einen Kommentar sehr dankbar.

Ich werde jetzt meinen Server ein bisschen besser im Auge behalten. Sobald ich den Fehler gefunden habe, werde ich euch natürlich sofort berichten, woran es lag. In diesem Sinne noch ein schönes Wochenende!

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.

Auf einem dieser Server ist aber die Syntax Hervorhebung des Vim Editors deaktiviert. Man kann diese im Vim aktivieren, indem man “:syntax enable” eingibt. Diese Einstellung geht aber nach dem Beenden des Editors wieder verloren. Wer das Syntax Highlighting dauerhaft aktivieren möchte, muss die Datei “vimrc” anpassen. Entweder ihr bearbeitet dabei nur die vimrc Datei in eurem Home-Verzeichnis, oder mit dem Administrator die systemweite vimrc Datei. Diese findet ihr in der Regel unter /etc/vim/vimrc. Dort solltet ihr folgende Zeile finden:

"syntax on

Mit dem doppelten Anführungszeichen zu Beginn der Zeile wird der Befehl auskommentiert. Wenn ihr das doppelte Anführungsuzeichen entfernt und dann die Datei speichert, solltet ihr nach einem erneuten Öffnen der Datei (oder eine anderen Datei mit Quellcode) das Syntax Highlighting sehen können. In der Dokumentation zum Vim Editor findet ihr bestimmt auch einige weitere hilfreiche Tipps.

Ich hoffe der Beitrag konnte euch weiterhelfen. Ich wollte mir schon lange mal das Buch “vi-Editor. Kurz und gut” kaufen um ein bisschen mehr über den Editor zu erfahren. Aber laut Buchbeschreibung handelt nur ein Kapitel vom Vim und da es mein Buchladen nicht hat konnte ich es mir bisher noch nicht ansehen. Aber ich habe es auf meinen Wunschzettel gesetzt. Vielleicht findet sich ja jemand, der es mir schenken möchte

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.

Manch einer wird sich eventuell darüber freuen, da er irgendwo ein kostenloses Hosting mit einer sehr langen URL hat und durch die Frameweiterleitung den Besuchern immer eine kurze Domain präsentieren kann. Doch die Sache hat auch ihre Haken.

Das Lesezeichen-Problem

Das navigieren innerhalb der Seite gestaltet sich für den Besucher, wie er es erwartet. Er kann alle Links anklicken und der Hauptframe öffnet daraufhin die richtige Seite. Auch das Navigieren mit den “Vor” und “Zurück” Buttons funktioniert tadellos. Aber sobald der Benutzer eine Seite gefunden hat, die er seinen Favoriten hinzufügen möchte fängt der Ärger an. Nicht nur, dass der Name des Lesezeichens oft nur die Domain enthält, viel schlimmer ist, dass das Lesezeichen auch auf die selbige zeigt. Wenn der Besucher also später das Lesezeichen aufruft kommt er nicht auf die gewünschte Seite, sondern auf die Startseite und muss von dort aus erst wieder mühsam auf die richtige Seite navigieren.

Das Suchmaschinen-Problem

Die meisten Suchmaschinen (Google eingeschlossen) haben Probleme mit framebasierten Seiten. Sie sehen oft nur das Frameset-Konstrukt und nicht die Inhalte der einzelnen Frames. Das bedeutet in den meisten Fällen, das eure Internet-Seiten, die tausende von Seiten haben können, bei Suchmaschinen genau EINE Seite als Eintrag enthalten. Und das ist die Startseite oder genauer gesagt das Frameset der Domain. Eine Möglichkeit den Suchmaschinen doch die anderen Seiten mitzuteilen ist das Erstellen einer Sitemap. Diese solltet ihr dann aber manuell den Suchmaschinen mitteilen, da sie die Datei unter umständen auch nicht finden können. Dabei könnt ihr entweder die Domain um die Seitennamen erweitern, oder aber die URL eures Webspace verwenden und um die Seitennamen erweitern.

Die Lösung

Beide Probleme zeigen also, dass Frame-Weiterleitungen ein Relikt aus alten Zeiten sind und nicht mehr verwendet werden sollten. Aber was kann man tun, wenn der Hoster keine HTTP-Weiterleitung bietet, oder dafür einen Aufpreis verlangt? Ganz einfach, man bedient sich eines recht simplen Tricks. Dazu legt man zuerst einen Ordner mit beliebigen Namen auf dem Server an. Dann stellt man die Domain so ein, dass sie als Ziel den Ordner enthält. In diesem Ordner erzeugt man dann eine index.php (oder eine Index-Datei einer andern Scriptsprache) mit folgendem Inhalt:

<script type="text/javascript">
	top.location.href = "http://example.com";
</script>

Dieser einfache JavaScript Snippet ändert die URL des Top-Frame auf einen neuen Wert. Wenn der Besucher also eure Domain aufruft, die lediglich eine Frame-Weiterleitung untersützt, sorgt der Code dafür, dass das oberste Frameset auf eine andere URL umgeleitet wird. Hierbei müsste ihr natrülich “example.com” durch eure eigene Domain ersetzen (das “http://” dabei nicht vergessen). Für alle Besucher, die keine JavaScript Unterstützung aktiviert haben solltet ihr zusätzlich einen NOSCRIPT Tag einfügen der einen Link enthält:

<noscript>
	Sollten Sie nicht weitergeleitet werden, klicken Sie auf den folgenden Link:
	<a href="http://example.com" target="top">http://example.com</a>
</noscript>

Der Link bekommt dabei das Attribut “traget” mit dem Wert “top”. Somit wird auch hier der Link im obersren Frameset aufgerufen. Um Benutzern, die ein Lesezeichen auf eure umzuleitende Domain haben, könntet ihr auch noch den Request an die Domain anhängen. Somit wird der Besucher dann auf die richtige Zielseite auf der anderen Domain umgeleitet. Zusammengesetzt sieht das ganze Beispiel dann wie folgt aus (oder ähnlich in einer anderen Skriptsprache):

<script type="text/javascript">
	top.location.href = "http://example.com"<?php echo $_SERVER['REQUEST_URI']; >
</script>
<noscript>
	Sollten Sie nicht weitergeleitet werden, klicken Sie auf den folgenden Link:
	<?php echo '<a href="http://example.com'.$_SERVER['REQUEST_URI'].'" target="top">http://example.com'.$_SERVER['REQUEST_URI'].'</a>'; ?>
</noscript>

Diesen Codeblock platziert Ihr einfach im BODY Tag der Index-Seite. Dabei solltet ihr aber Besuchern ohne JavaScript eine schönere Seite präsentieren, als eine die nur den Link auf weißem Untergrund enthält.

Da ich selbst noch eine Domain besitze, die ich leider zur Zeit noch nicht auf ein aktuelles Hostingpaket umziehen kann, könnt ihr euch das ganze in einem kleinen Beispiel auch ansehen. Die Domain ist mittlerweile endlich umgezogen und daher habe ich nun das Beispiel auf die alte Subdomain abgeändert. Dazu solltet ihr einfach JavaScript vorübergehen deaktivieren, damit ihr auch die Seite und den Quelltext betrachten könnt. Wenn ihr dann JavaScript wieder aktiviert und die Seite aktualisiert, solltet ihr auf meinen Blog umgeleitet werden.

Beispiel

Mit diesem Trick könnt ihr also die Frame-Weiterleitung umgehen, aber ihr präsentiert dann dem Besucher die entsprechend andere URL, als sie aufgerufen haben. Dies sollte aber einer schönen URL aber dafür der eingeschränkten Suchmaschinenfreundlichkeit und der Verhinderung von Lesezeichen bevorzugt werden. Ihr könnt weiterhin die schöne URL in Mails verbreiten und den Besucher trotzdem umleiten. Wenn ihr die Domain vollständig nutzen möchtet bleibt euch leider nichts anderes Möglich, als diese in das Webhosting-Paket zu übertragen oder zu einem reinen Domain-Anbieter zu wechseln, der auch eine HTTP-Weiterleitung anbietet, auch wenn das eventuell einen Aufpreis bedeutet.

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.