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.