Um \u00c4nderungen an der Konfiguration und den Dateien meines Blogs gefahrlos testen zu k\u00f6nnen, m\u00f6chte ich eine Testinstanz meines Blogs einrichten. Die dazu erforderlichen Schritte werde ich in diesem Artikel dokumentieren.<\/p>\n
Dieser Artikel ist keine<\/strong> Schritt-f\u00fcr-Schritt-Anleitung und kein<\/strong> Tutorial, welches man blind befolgen kann. So gehe ich hier z.B. nicht auf die allgemeine Webserverkonfiguration ein. Falls ihr hierzu Hilfe ben\u00f6tigt, schaut bitte in der offiziellen Dokumentation zu eurem Webserver nach.<\/p>\n Ich betreibe meinen Blog bei einem deutschen Webhosting-Provider. Bei diesem habe ich \u00fcber ein Kundencenter via FTP-Zugang Zugriff auf die Konfiguration und die Dateien meines Blogs.<\/p>\n Bei einem anderen deutschen Unternehmen betreibe ich noch einen Linux-Root-Server, welcher sich hervorragend eignet, um darauf eine Testinstanz einzurichten.<\/p>\n Um die sp\u00e4tere Testinstanz mit den Daten des Live-Blogs f\u00fcttern zu k\u00f6nnen, werden die Daten aus dem aktuellen Blog zuerst einmal gesichert.<\/p>\n Die Sicherung umfasst die Datenbank und das DocumentRoot des Blogs.<\/p>\n Zur Sicherung der Datenbank verwende ich das Tool MySQLDumper.[1. http:\/\/www.mysqldumper.de\/<\/a>] Mit diesem Werkzeug kann man \u00fcber eine einfach zu bedienende Weboberfl\u00e4che ein Backup seiner Datenbank erstellen. Dieses Backup wird anschlie\u00dfend zur weiteren Verwendung auf den lokalen Rechner heruntergeladen.<\/p>\n Im zweiten Schritt wird das DocumentRoot-Verzeichnis des Blogs gesichert. Hierzu nutze ich den FTP-Client FileZilla.[2. http:\/\/www.filezilla.de\/]<\/p>\n Auf dem Linux-Root-Server laufen Ubuntu Server 14.04 LTS und der Webserver NGINX<\/a>.[3. http:\/\/nginx.org\/<\/a>]<\/p>\n F\u00fcr meine Webseiten verwende ich eine einheitliche Verzeichnisstruktur:<\/p>\n So wird f\u00fcr jede Webseite in separate Log-Dateien geschrieben, was eine Fehleranalyse deutlich erleichtern kann. Die Dateien der Webseite liegen im Verzeichnis public<\/em>. Die Datei index.html<\/em> stellt dabei aktuell nur einen Platzhalter dar, bis die gesicherten Daten des Live-Blogs eingespielt werden.<\/p>\n Den Platzhalter kann man nutzen, um zu testen, ob der Webserver korrekt konfiguriert ist und die im Verzeichnis public<\/em> abgelegte Seite auch ausliefert.<\/p>\n Um die sp\u00e4tere Testinstanz \u00fcber die gleiche URL aufrufen zu k\u00f6nnen, wie den Live-Blog, wird ein Eintrag in die \/etc\/hosts<\/em> eingef\u00fcgt. So erreicht man, dass die URL des Live-Blogs nun auf die IP-Adresse des Servers mit der Testinstanz zeigt.<\/p>\n Hat man alles richtig konfiguriert, wird man vom Webserver mit einem „Hallo Welt!“ begr\u00fc\u00dft.<\/p>\n W\u00e4hrend man eine neue Konfiguration testet, k\u00f6nnen Fehler passieren. Diese k\u00f6nnen zu Folge haben, dass der Blog nicht korrekt ausgeliefert wird. F\u00fcr gew\u00f6hnlich ist nicht gew\u00fcnscht, dass ein Benutzer dies sieht. Evtl. m\u00f6chte man auch einfach nicht, dass Neuerungen zuf\u00e4llig schon von Besuchern entdeckt werden, bevor sie in den Live-Blog \u00fcberf\u00fchrt wurden.<\/p>\n Daher scheint es sinnvoll den Zugriff auf die Testinstanz einzuschr\u00e4nken und einen Aufruf der Testinstanz erst nach erfolgreicher Authentifizierung mit Benutzername und Passwort zu erlauben.<\/p>\n Dazu eignet sich f\u00fcr NGINX-Benutzer das Modul ngx_http_auth_basic_module<\/em>.[4. http:\/\/nginx.org\/en\/docs\/http\/ngx_http_auth_basic_module.html<\/a>] Nutzer von Apache k\u00f6nnen .htaccess<\/strong>-Dateien[5. .htaccess – Wikipedia<\/a>] verwenden. Da ich selbst einen NGINX betreibe, gehe ich im Folgenden auf das zuerst genannte Modul ein.<\/p>\n Zuerst wird die .htpasswd<\/strong>-Datei erstellt, welche Benutzernamen und Passwort f\u00fcr die Authentifizierung enth\u00e4lt.<\/p>\n Um das Passwort in verschl\u00fcsselter Form speichern zu k\u00f6nnen wird das Paket apache2-utils<\/strong> ben\u00f6tigt. Dieses enth\u00e4lt das Programm htpasswd<\/em>, mit welchem Benutzername und Passwort erzeugt werden.<\/p>\n Der Benutzer, unter dessen Kontext der Webserver (NGINX) l\u00e4uft, muss Zugriff auf die .htpasswd<\/strong> erhalten.<\/p>\n Nun \u00f6ffnet man die Konfigurationsdatei f\u00fcr die Testseite, welche f\u00fcr gew\u00f6hnlich unterhalb von \/etc\/nginx\/sites-available\/<\/em> liegt. Hier ist folgende Konfiguration zu integrieren:<\/p>\n auth_basic<\/em> aktiviert die \u00dcberpr\u00fcfung von Benutzername und Passwort. auth_basic_user_file<\/em> gibt den Pfad an, wo die .htpasswd<\/strong>-Datei liegt, gegen die gepr\u00fcft wird.<\/p>\n Mit einem „configtest“ kann man seine Konfiguration auf syntaktische Fehler \u00fcberpr\u00fcfen und bei Bestehen der Pr\u00fcfung die Konfiguration neu laden.<\/p>\n Ab jetzt fragt NGINX nach einem Benutzernamen und Passwort, bevor er die Webseite mit dem „Hallo Welt.“-Slogan ausliefert.<\/p>\n Wenn der Webserver prinzipiell mit dem weiter oben erstellten vHost funktioniert und die „Hallo Welt.“-Seite ausliefert, werden als n\u00e4chstes die Daten aus dem Live-Blog eingespielt.<\/p>\n Dazu werden der Datenbank-Dump und das im ersten Schritt gesicherte Verzeichnis auf den Linux-Root-Server hochgeladen. Ich habe dazu wieder FileZilla und das SFTP-Protokoll<\/a> genutzt.<\/p>\n Die gesicherten Dateien und Verzeichnisse, m\u00fcssen in das DocumentRoot-Verzeichnis der Testinstanz kopiert werden. In meinem Beispiel ist das das Verzeichnis \/var\/www\/example.org\/public\/<\/em>. Mit folgendem Befehl wird sichergestellt, dass der Webserver auch alle Dateien lesen kann.<\/p>\n Bevor die Datenbanksicherung eingespielt werden kann, muss eine Datenbank und ein Datenbankbenutzer angelegt werden.<\/p>\n Wer hierbei Hilfe zur Syntax ben\u00f6tigt, kann im Artikel „H\u00e4ufig verwendete MySQL-Befele“<\/a> nachlesen.<\/p>\n Ist dies erledigt, kann die Datenbanksicherung mit folgendem Befehl eingespielt werden.<\/p>\n Ober der angelegte Benutzer auch wirklich Zugriff auf die Datenbank hat, kann man mit dem folgenden Befehl \u00fcberpr\u00fcfen. Wenn alles stimmt, kann man sich so an der Datenbank anmelden.<\/p>\n Fertig. Mein Testblog l\u00e4uft und ich kann mich jetzt daran machen, mit der WordPress-Konfiguration zu experimentieren. :-)<\/p>\n Bei der gestrigen Aktualisierung der Testinstanz musste ich feststellen, dass zwar die Startseite des Blogs geladen wird, jedoch alle Artikelaufrufe in einen 404-Fehler laufen.<\/p>\n Die Ursache f\u00fcr diese Fehler liegt darin begr\u00fcndet, dass ich mit Nginx einen anderen Webserver verwendet, als mein Webhoster. Dieser behandelt die Permalinks von WordPress anders, als z.B. ein Apache-Webserver mit dem Modul Eine L\u00f6sung f\u00fcr dieses Problem habe ich ziemlich schnell in der Nginx Library[6. Nginx Library - WordPress Permalinks<\/a> {en}] gefunden. Es wird die Die Einrichtung ist relativ einfach. Das Vorgehen unterscheidet sich, je nach dem ob WordPress direkt im Wurzelverzeichnis einer Domain oder in einem Unterverzeichnis installiert ist. Im Folgenden werden beide F\u00e4lle betrachtet.<\/p>\n Liegt die WordPress-Installation im Wurzelverzeichnis der Domain z.B. unter Der vollst\u00e4ndige Block sollte anschlie\u00dfend wie folgt aussehen:<\/p>\n Abschie\u00dfend muss die Konfiguration von Nginx neu geladen werden. Nun sollten auch die 404-Fehler behoben sein.<\/p>\n Liegt die WordPress-Installation in einem Unterverzeichnis der Domain z.B. unter Abschie\u00dfend muss die Konfiguration von Nginx neu geladen werden. Nun sollten auch die 404-Fehler behoben sein.<\/p>\n","protected":false},"excerpt":{"rendered":" Um \u00c4nderungen an der Konfiguration und den Dateien meines Blogs gefahrlos testen zu k\u00f6nnen, m\u00f6chte ich eine Testinstanz meines Blogs einrichten. Die dazu erforderlichen Schritte werde ich in diesem Artikel dokumentieren. Dieser Artikel ist keine Schritt-f\u00fcr-Schritt-Anleitung und kein Tutorial, welches man blind befolgen kann. So gehe ich hier z.B. nicht auf die allgemeine Webserverkonfiguration ein. [Weiterlesen…]<\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_metis_text_type":"","_metis_text_length":0,"_post_count":0,"footnotes":""},"categories":[67],"tags":[58,304,430,305,35,46,60,303,338],"class_list":["post-1042","post","type-post","status-publish","format-standard","hentry","category-wordpress","tag-linux","tag-nginx","tag-osbn","tag-planet","tag-server","tag-tutorial","tag-ubuntu","tag-webserver","tag-wordpress"],"_links":{"self":[{"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/posts\/1042","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/comments?post=1042"}],"version-history":[{"count":14,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/posts\/1042\/revisions"}],"predecessor-version":[{"id":2477,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/posts\/1042\/revisions\/2477"}],"wp:attachment":[{"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/media?parent=1042"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/categories?post=1042"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/tags?post=1042"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Voraussetzungen<\/h2>\n
Daten sichern<\/h2>\n
Serverkonfiguration<\/h2>\n
example.org\/\r\n\u251c\u2500\u2500 logs\r\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 access.log\r\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 error.log\r\n\u2514\u2500\u2500 public\r\n \u2514\u2500\u2500 index.html\r\n\r\n2 directories, 3 files\r\n<\/pre>\n
Zugriff beschr\u00e4nken<\/h3>\n
sudo touch \/etc\/nginx\/conf.d\/.htpasswd\r\n<\/pre>\n
:~$ sudo htpasswd -c \/etc\/nginx\/conf.d\/.htpasswd BENUTZERNAME\r\nNew password: \r\nRe-type new password: \r\nAdding password for user BENUTZERNAME\r\n<\/pre>\n
:~$ sudo chown www-data:www-data \/etc\/nginx\/conf.d\/.htpasswd\r\n<\/pre>\n
location \/ {\r\n auth_basic \"Authentifizierung erforderlich!\";\r\n auth_basic_user_file conf.d\/.htpasswd;\r\n}\r\n<\/pre>\n:~$ sudo service nginx configtest \r\n * Testing nginx configuration [ OK ] \r\njkastning@rs212997:~$ sudo service nginx reload\r\n * Reloading nginx configuration nginx [ OK ]\r\n<\/pre>\n
Daten einspielen<\/h2>\n
DocumentRoot<\/h3>\n
sudo chgrp -R www-data \/var\/www\/example.org\/public\r\n<\/pre>\n
Die Datenbank<\/h3>\n
mysql -u root -p db_name < db_sicherung.sql\r\n<\/pre>\n
mysql -u db_benutzer -p db_name\r\n<\/pre>\n
Update vom 24.12.2016<\/h2>\n
mod_rewrite<\/code>.<\/p>\ntry_files<\/code>-Direktive[7. Nginx try_files directive<\/a> {en}] verwendet, um aufgerufene URLs zur weiteren Behandlung an die index.php von WordPress weiterzuleiten.<\/p>\nWordPress im Wurzelverzeichnis<\/h3>\n
http:\/\/www.example.com<\/code>, sucht man in der Konfigurationsdatei der Seite nach dem Block location \/<\/code>. Diesem Block wird folgende Zeile hinzugef\u00fcgt:<\/p>\n\r\ntry_files $uri $uri\/ \/index.php?$args;\r\n<\/pre>\n
\r\nlocation \/ {\r\n index index.php index.html index.htm;\r\n try_files $uri $uri\/ \/index.php?$args;\r\n}\r\n<\/pre>\nWordPress in einem Unterverzeichnis<\/h3>\n
http:\/\/www.example.com\/wordpress<\/code>, muss der Konfigurationsdatei ein Block nach dem Muster location \/wordpress\/<\/code> hinzugef\u00fcgt werden, welcher wie folgt aussieht:<\/p>\n\r\nlocation \/wordpress\/ {\r\n try_files $uri $uri\/ \/wordpress\/index.php?$args;\r\n}\r\n<\/pre>\n