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.

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.

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.