Zweite Web-Anwendung neben ownCloud/Nextcloud einrichten (am Beispiel WordPress)
Der Artikel über ownCloud auf nginx, MariaDB und PHP hat mittlerweile sehr viel Zuspruch gefunden. Hier wurde die Konfiguration des Webservers darauf ausgelegt, dass der Administrator neben ownCloud bzw. Nextcloud auch noch andere Web-Anwendungen auf dem gleichen Server betreiben kann. Hierzu gibt es immer wieder Fragen, wie dies am besten realisiert werden kann. Im folgenden Artikel soll daher exemplarisch die Vorgehensweise zur Einrichtung von WordPress neben ownCloud/Nextcloud gezeigt werden.
WordPress dient dazu lediglich als Beispiel für eine PHP-Anwendung, daher wird hier nicht weiter auf die Details der Konfiguration und Absicherung des Content-Management-Systems eingegangen. Das gezeigte Konzept sollte allerdings auch auf andere Web-Applikationen übertragbar sein. Wenn es mal nicht klappen sollte, liefert der Artikel Tipps und Tricks zur Fehlersuche.
Kein WordPress? Hinweise für andere Web-AnwendungenAndere Anwendungen haben im Vergleich zu WordPress evtl. andere Anforderungen an den Webserver. Daher kann es notwendig sein, dass für andere Applikationen eine leicht geänderte Herangehensweise bzw. zusätzliche Schritte notwendig sind. (Allgemeine) Hinweise hierzu gibt es immer in einem separaten Dropdown-Text wie diesem hier.
Update-Historie (letztes Update: 16.06.2018)
- 07.10.2017:
- Einrichtung für FHEM hinzugefügt.
- 09.10.2017:
- Genauere Beschreibung, wo die Anpassungen an der wp-config.php vorgenommen werden müssen
- location-Block für WordPress angepasst (location ^~ /wordpress > location ^~ /wordpress/).
- 26.10.2017:
- open_basedir im virtuellen Host für WordPress angepasst, so dass auch ein Upload von Dateien möglich ist.
- 07.11.2017:
- Virtuellen Host für WordPress angepasst, so dass nun auch anders aufgebaute Permalinks für WordPress möglich sind.
- 19.05.2018:
- Einrichtung für Moodle hinzugefügt.
- 16.06.2018:
- Einrichtung für Pi-hole hinzugefügt.
- 09.07.2018:
- Das Setzen der Verzeichnisrechte darf erst nach Anlegen der Datei wp-config.php erfolgen.
Ausgangssituation
Als Basis dient die Konfiguration, die im Artikel ownCloud 9 auf Ubuntu Server 16.04 LTS mit nginx, MariaDB, PHP 7 und Let’s Encrypt gezeigt wird. Daher sollte der Artikel bereits bekannt sein, weil nicht mehr auf spezielle Details der Konfiguration eingegangen wird.
Folgende Programmversionen kommen hier zum Einsatz:
- Ubuntu Server 16.04.1 LTS („Xenial Xerus“)
- nginx 1.11.3
- MariaDB 10.1.17
- PHP 7
Das Tutorial zu ownCloud weist dabei mehrere Besonderheiten auf, welche die Flexibilität des Webservers erhöhen, leider aber auch die Komplexität:
- Zunächst sollen die einzelnen Anwendungen in einem Unterverzeichnis des Webroots (https://owncloud9tutorial.goip.de) liegen. So erfolgt der Aufruf von ownCloud beispielsweise über https://owncloud9tutorial.goip.de/owncloud.
- Zum anderen werden alle Client-Anfragen zunächst von einem zentralen Gateway-Host entgegengenommen – über die Standard-Ports 80 (HTTP) und 443 (HTTPS). Neben diesem Gateway-Host gibt es darüber hinaus für jede Web-Anwendung (z.B. ownCloud/Nextcloud) einen einzelnen virtuellen Host, der sich exklusiv um diese Applikation kümmert. Der Gateway-Host nutzt nun die Reverse-Proxy-Fähigkeiten von nginx (proxy_pass), um die Anfragen der Clients an die jeweiligen (Anwendungs-)Hosts weiter zu leiten.
- Die gesamte Kommunikation soll dabei nur über gesicherte SSL-Verbindungen möglich sein (HTTPS). Alle HTTP-Anfragen werden daher zu HTTPS weitergeleitet. Für die Kommunikation mittels HTTPS kommt dabei ein Zertifikat von Let’s Encrypt zum Einsatz.
Im Folgenden werden Dateinamen, URLs, o.ä. analog zum ownCloud-Tutorial benannt. Auf diese Weise können die Zusammenhänge am besten dargestellt werden.
Virtuellen Host für WordPress anlegen
Für WordPress soll (wie schon für ownCloud) ein eigener virtueller Host zuständig sein. Angelegt wird dieser über folgenden Befehl. Der Dateiname ist an dieser Stelle egal, er muss nur auf .conf enden, damit diese Konfiguration von nginx geladen werden kann.
1 | nano /etc/nginx/conf.d/owncloud9tutorial.goip.de_wordpress.conf |
Hier wird nun die (minimale) Konfiguration des Webservers für WordPress hinzugefügt:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 | server { server_name 127.0.0.1; listen 127.0.0.1:83; root /var/www/; location ^~ /wordpress { index index.php; location /wordpress { try_files $uri $uri/ /wordpress/index.php$args; } location = /wordpress/favicon.ico { log_not_found off; access_log off; } location = /wordpress/robots.txt { allow all; log_not_found off; access_log off; } location ~ \.php$ { try_files $uri =404; fastcgi_split_path_info ^(.+\.php)(/.+)$; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_pass php-handler; fastcgi_connect_timeout 60; fastcgi_index index.php; fastcgi_param PHP_VALUE "open_basedir=/var/www/wordpress:/tmp/ upload_max_filesize = 1G post_max_size = 1G max_execution_time = 3600"; } location ~* /wordpress/\.(js|css|png|jpg|jpeg|gif|ico)$ { expires max; log_not_found off; } } } |
Wichtig: Für diesen virtuellen Host sind folgende Punkte zu beachten:
- Der server Block behandelt nur HTTP-Anfragen, also kein HTTPS. Wovon allerorts abgeraten wird, macht hier Sinn, da sich der Gateway-Host (und nur dieser!) um die HTTPS-Kommunikation kümmert. Nach außen hin wird auch WordPress später ausschließlich mittels HTTPS zu erreichen sein.
- listen 127.0.0.1:83 und server_name 127.0.0.1: Damit wird angegeben, dass dieser Host nur über die Loopback-Adresse (127.0.0.1) angesprochen werden kann. Dadurch ist es nicht möglich, diesen „von außen“, d.h. ohne den Gateway-Host passiert zu haben, zu erreichen.
Ebenfalls von Bedeutung ist die Port-Angabe (83): Jeder virtuelle Host muss hier seinen eigenen Port bekommen. Da der ownCloud-Host in der Beispiel-Konfiguration bereits auf Port 82 lauscht, nehmen wir hier einfach die nächste Port-Nummer. - Es gibt einen umgebene location Block (location ^~ /wordpress {…}). Innerhalb dieses Blocks sind alle anwendungsspezifischen Anweisungen enthalten. Diese sind dann analog zu einer Standalone-Installation, d.h. wenn WordPress über eine Domain (ohne Unterverzeichnis) als einzige Webanwendung auf dem Server laufen würde (diese Konfiguration findet man in zahlreichen Online-Tutorials). Der einzige Unterschied ist hierbei, dass alle enthaltenen location Blöcke mit der Pfadangabe /wordpress ergänzt werden müssen.
- Der für PHP-Dateien zuständige location Block setzt mit fastcgi_param PHP_VALUE explizit die Variable open_basedir. Dadurch kann der Host für WordPress (bzw. die dazugehörenden PHP-Skripte) nur auf das eigene Verzeichnis zugreifen. Andere PHP-Anwendungen haben hier im Vergleich ihre eigene Definition von open_basedir mit jeweils eigenen Verzeichnissen.
Der gezeigte virtuelle Host stellt eine minimale Konfiguration für WordPress dar. Andere Web-Applikationen benötigen hier u.U. andere und/oder zusätzliche Anweisungen. Dies wird besonders klar, wenn man sich dagegen den virtuellen Host für ownCloud ansieht.
Leider ist diese Konfiguration von Applikation zu Applikation verschieden. Einen guten Anhaltspunkt erhält man dabei meist über eine Google-Suche (<Name der Anwendung> nginx, z.B. Koken nginx).
Erweiterung des Gateway-Hosts
Damit die Weiterleitung vom Gateway-Host zum WordPress-Host funktionieren kann, muss der Gateway-Host noch bearbeitet werden:
1 | nano /etc/nginx/conf.d/owncloud9tutorial.goip.de.conf |
Die WordPress-Installation soll später unter der URL https://owncloud9tutorial.goip.de/wordpress erreichbar sein. Dazu muss an dieser Stelle ein separater location Block eingefügt werden (direkt unter dem Block für ownCloud):
1 2 3 4 5 6 7 8 9 | location ^~ /wordpress/ { proxy_set_header Host $host; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_pass http://127.0.0.1:83; proxy_redirect off; } |
Diese Anweisungen sorgen dafür, dass sämtliche Anfragen an https://owncloud9tutorial.goip.de/wordpress an den virtuellen Host für WordPress weitergeleitet werden.
Wichtig: Die eigentliche Weiterleitung verbirgt sich hinter dem proxy_pass. Hier gibt es drei Dinge zu beachten:
- Die Weiterleitung erfolgt auf die Loopback-Adresse 127.0.0.1. Auf dieser Adresse lauscht der virtuelle Host für WordPress.
- Der Port (hier 83) muss mit der Port-Angabe des virtuellen Hosts für WordPress übereinstimmen.
- Die Weiterleitung erfolgt über HTTP (nicht HTTPS). Der Gateway-Host übernimmt das HTTPS-Handling, die Hosts für die einzelnen Web-Anwendungen laufen (intern) über HTTP.
Wenn man den Gateway-Host bearbeitet, sollte man auch gleich kontrollieren, ob hier der Handler für PHP zu finden ist. Folgende Zeilen sollten in der Datei ganz oben stehen:
1 2 3 | upstream php-handler { server unix:/run/php/php7.0-fpm.sock; } |
Falls nicht, ist der Handler vermutlich in der Config-Datei für ownCloud zu finden (owncloud9tutorial.goip.de_owncloud.conf). In diesem Fall muss der Handler im ownCloud-Host gelöscht werden und im Gateway-Host neu hinzugefügt werden. Er darf auch nicht mehrfach in unterschiedlichen virtuellen Hosts enthalten sein.
Hinweise für andere Web-AnwendungenWie schon im virtuellen Host der Web-Applikation kann es sein, dass eine andere Anwendung abweichende oder zusätzliche Angaben für die Weiterleitung benötigen. Trotzdem sollte die hier gezeigte Weiterleitung in den meisten Fällen funktionieren bzw. einen guten Ansatzpunkt bieten.
Installation WordPress
Nachdem der Webserver nun für die neue Anwendung vorbereitet wurde, ist es nun an der Zeit, WordPress zu installieren.
Anlegen der Datenbank
WordPress ist ein Datenbank-gestütztes Content-Management-System und so sollte die Datenbank bereits vor dem ersten Aufruf angelegt werden. Dazu wird die Verwaltung für MariaDB/MySQL aufgerufen:
1 | mysql -u root -p |
Nach der Eingabe des Root-Passworts kann die Datenbank mit folgenden Befehlen angelegt werden:
1 2 3 4 5 | create database wordpress_db; create user wordpress_db_user@localhost identified by 'MeInPasSw0rT'; grant all privileges on wordpress_db.* to wordpress_db_user@localhost; flush privileges; exit; |
Dabei sorgt die Angabe localhost dafür, dass der Zugriff auf die Datenbank nur vom lokalen Rechner aus möglich ist.
WordPress Dateien herunterladen und Anpassen der Verzeichnisrechte
Als nächstes besorgen wir uns die aktuelle Version von WordPress und entpacken diese in das Verzeichnis /var/www/wordpress. Die Pfadangabe hinter /var/www muss dabei identisch zur Pfadangabe im entsprechenden virtuellen Host sein. Siehe umgebener location Block (location ^~ /wordpress {…}) im Host für WordPress.
1 2 3 | cd ~ wget https://wordpress.org/latest.tar.gz tar xzvf latest.tar.gz -C /var/www |
Anpassen der wp-config.php
Das Blog-System speichert die grundlegenden Einstellungen in der Datei wp-config.php im WordPress-Verzeichnis. Dazu muss erst einmal die Beispiel-Konfiguration kopiert und angepasst werden:
1 2 3 | cd /var/www/wordpress cp wp-config-sample.php wp-config.php nano wp-config.php |
Hier muss zunächst einmal die bereits angelegte Datenbank bekannt gemacht werden (Name der Datenbank, Benutzername und dazugehöriges Passwort):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | // ** MySQL settings - You can get this info from your web host ** // /** The name of the database for WordPress */ define('DB_NAME', 'wordpress_db'); /** MySQL database username */ define('DB_USER', 'wordpress_db_user'); /** MySQL database password */ define('DB_PASSWORD', 'MeInPasSw0rT'); /** MySQL hostname */ define('DB_HOST', 'localhost'); /** Database Charset to use in creating database tables. */ define('DB_CHARSET', 'utf8'); /** The Database Collate type. Don't change this if in doubt. */ define('DB_COLLATE', ''); |
Wenn wir schon mal in der Config von WordPress sind, dann können wir gleich noch zwei Sicherheits-relevante Änderungen vornehmen. Dazu gehört zum einen die Anpassung der Authentifizierungs-Keys. Dazu ruft man zunächst den Key-Generator im Browser seiner Wahl auf (WordPress-Key-Generator) und übernimmt diese Inhalte einfach per Copy & Paste in den Bereich Authentication Unique Keys and Salts in die wp-config.php.
Zum anderen kann man an dieser Stelle den Tabellen-Prefix für WordPress ändern. Standard ist hier wp_. Dies sollte nach Möglichkeit gleich geändert werden, am Besten in eine Bezeichnung, die keine Rückschlüsse auf WordPress zulässt:
1 2 3 4 5 6 7 | /** * WordPress Database Table prefix. * * You can have multiple installations in one database if you give each * a unique prefix. Only numbers, letters, and underscores please! */ $table_prefix = 'ow5n6_'; |
An dieser Stelle bitte nicht einfach den Code übernehmen, sondern ein eigenes Prefix vergeben.
Nun werden noch die benötigten Verzeichnisrecht gesetzt:
1 2 3 | find /var/www/wordpress/ -type f -print0 | xargs -0 chmod 0640 find /var/www/wordpress/ -type d -print0 | xargs -0 chmod 0750 chown -R www-data:www-data /var/www/wordpress |
WordPress: Aufruf und Setup
Nachdem WordPress nun mitsamt Datenbank und Konfiguration eingerichtet ist, sollte das Content-Management-System einsatzbereit sein. Bitte diesen Abschnitt vorher komplett lesen, da es hier nochmal einige Fallstricke gibt, die im weiteren Verlauf aufgelöst werden können. Mit diesen Erkenntnissen muss man dann nicht mehr den „Umweg“ per Trial & Error gehen.
WordPress-Setup: erster Versuch
Weil Änderungen an den virtuellen Hosts vorgenommen wurden, muss der Webserver zunächst einmal neu gestartet werden:
1 | service nginx restart |
Wenn man danach allerdings in freudiger Erwartung die WordPress-URL aufruft (https://owncloud9tutorial.goip.de/wordpress), erlebt man einen herben Rückschlag:
Das WordPress-Setup wird zwar angezeigt, allerdings sieht die Seite komisch aus – sämtliche Formatierungen und Bilder scheinen zu fehlen. Offensichtlich werden die CSS-Dateien für die Formatierung von Text und Seite nicht korrekt geladen. Ein Blick in die Log-Datei von nginx (/var/log/nginx/error.log) liefert jedoch keinen Hinweis darauf, dass es beim Aufruf dieser Dateien zu Problemen kommt. Dies ist schon mal ein Hinweis darauf, dass es nicht an der Struktur des virtuellen Hosts für WordPress liegt.
Ein weiteres Indiz: Wenn man einen Blick auf den Seitenquelltext wirft (z.B. in Chrome: Rechtsklick auf freien Bereich der Website > Seitenquelltext anzeigen) und die URL einer konkreten CSS-Datei kopiert, lässt sich diese im Browser eingeben und der Dateiinhalt wird anschließend korrekt geladen. Die Dateien werden also vom Webserver definitiv richtig ausgeliefert.
Den entscheidenden Hinweis liefert erst die Developer-Konsole von Chrome (Shortcut: F12): Der Browser hat Mixed Content erkannt (HTTP/HTTPS) und den vermeintlich unsicheren (HTTP-)Inhalt blockiert.
Chrome: Fehlerhafte Anzeige wegen Mixed Content
Wie sich (nach langer Web-Recherche) herausstellt, handelt es sich hier um ein Problem von WordPress selbst: URLs von CSS- oder auch JavaScript-Dateien (*.js) werden hier absolut mittels einer Basis-URL angegeben. Durch das Konstrukt von Gateway-Host und Anwendungs-Host (letzterer wird intern nur über HTTP aufgerufen) ergibt sich hier die Problematik mit Mixed Content. Besser wäre es, wenn WordPress die URLs relativ angeben würde…
Die Lösung
Nun wollen wir natürlich nicht den Quellcode von WordPress direkt anpassen. Das Problem lässt sich aber zum Glück auch anderweitig in den Griff bekommen: Mit einem Zusatz in der wp-config.php weisen wir WordPress an, dass sämtliche Anfragen, die per HTTPS kommen, auch über HTTPS beantwortet werden. Dazu fügen wir in der wp-config.php ganz am Anfang, aber nach dem <?php (wichtig!) – also am besten nach dem großen Kommentar-Block ganz am Anfang – folgende Zeilen hinzu:
1 2 3 4 5 6 7 8 | if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false) $_SERVER['HTTPS']='on'; if(isset($_SERVER['HTTP_X_FORWARDED_HOST'])) $_SERVER['HTTP_HOST'] = $_SERVER['HTTP_X_FORWARDED_HOST']; define('WP_HOME', 'https://owncloud9tutorial.goip.de/wordpress'); define('WP_SITEURL', 'https://owncloud9tutorial.goip.de/wordpress'); |
Nach dem Speichern der Datei kann die URL im Browser aktualisiert werden und wird nun korrekt angezeigt:
WordPress-Setup – komplett mit Formatierungen und JavaScript
Wozu der Umweg?
Den Umweg (erster Aufruf, Nachbesserung und zweiter Versuch) kann man sich natürlich sparen, wenn man weiß, wo hier die Probleme liegen. Die geschilderten Ausführungen zeigen jedoch bewusst den Weg, den man bei der Einrichtung einer weiteren Web-Applikation gehen würde. Dies soll ein deutlicher Hinweis darauf sein, dass man schnell mit Problemen konfrontiert wird, die bei einer Standalone-Installation so nicht auftreten sollten und man ein wenig rumprobieren muss, bis man letzten Endes zum Ziel kommt. Gerade wenn das Problem zunächst einmal nichts mit der Konfiguration des Webservers bzw. der virtuellen Hosts zu tun hat (z.B. falsch angegebene location Blöcke), muss man ggf. die Anwendung selbst bzw. deren Konfiguration anpassen.
Hinweise für andere Web-AnwendungenDie notwendigen Änderungen sind dabei ganz individuell von der jeweiligen Applikation abhängig! Manchmal funktioniert es out-of-the-box und es sind keine weiteren Anpassungen nötig, manchmal aber eben nicht. Daher gibt es hier leider keine allgemeingültige Lösung, die für jede Anwendung passt.
Weitere Schritte in WordPress
Auch wenn WordPress nun soweit funktioniert, sollte man sich um die Sicherheit des Blog-Systems kümmern. In diesem Artikel wurden nur grundlegende Anpassungen bzw. der Sicherheit durchgeführt (z.B. Erzeugen der Authentication Keys oder auch das Ändern des Prefixes für WordPress-Tabellen).
Eine komplette Beschreibung der Optimierung und Absicherung von WordPress würde den Rahmen des Artikels sprengen. Hier liefert folgende Artikel-Serie eine Menge Infos und Anregungen: WordPress absichern.
Prinzipiell sollte man sich grundlegend mit der gehosteten Applikation vertraut machen und gezielte Optimierungen vornehmen.
Tipps & Tricks
Die in diesem Artikel gezeigten Schritte gelten (zumindest grundlegend) auch für andere Web-Anwendungen.
Wenn es dabei mal hakt, sollten folgende Tipps dabei helfen, das Problem schnell zu erkennen und zu beseitigen:
Neustart Webserver/PHP-FPM
Wenn gemachte Änderungen anscheinend keinerlei Auswirkungen zu haben scheinen, dann fehlt vermutlich ein Neustart bestimmter Dienste:
Nach Anpassungen an virtuellen Hosts sollte nginx immer neu gestartet werden:
1 | service nginx restart |
Wenn es hierbei bereits zu Fehlern kommt (erfahrungsgemäß sind dies dann einfache Tippfehler in einem der Hosts), hilft ein Testen der Konfiguration mit:
1 | nginx -t |
Der Befehl zeigt die betroffene Datei und die genaue Stelle, an dem das Problem aufgetreten ist.
Falls Änderungen an der PHP-Konfiguration durchgeführt werden müssen (eher unwahrscheinlich), dann sollte auch der Dienst für PHP neu gestartet werden:
1 | service php-fpm restart |
Log-Dateien kontrollieren
Bei auftretenden Problemen lohnt meist ein Blick in die Log-Dateien. Gerade bei HTTP-Statusfehlern (z.B. Fehler 403) sollte hier ein erster Ansatzpunkt zu finden sein. Dies liegt meistens an einer falschen Webserver-Konfiguration (virtuelle Hosts). Die zu prüfenden Logs sind dabei:
- nginx Fehler-Log: /var/log/nginx/error.log
- Log der Web-Anwendung: Wo dieser zu finden ist, hängt von der jeweiligen Anwendung ab
Developer-Konsole (Browser)
Falls keine Hinwiese in den Log-Dateien zu finden sind, hilft (wie in diesem konkreten Beispiel mit WordPress) ein Blick in die Developer-Konsole des verwendeten Browsers. Diese wird meistens über den Shortcut F12 gestartet (Chrome, Firefox, Internet Explorer). Die Vorgänge beim Laden einer Seite findet man meistens in einem Tab Konsole bzw. Console.
Web-Suche
Dieser Tipp ist zwar offensichtlich, soll aber trotzdem nicht unerwähnt bleiben: Die Konfiguration unter nginx mit einem Gateway-Host ist recht ungewöhnlich und unterscheidet sich z.T. erheblich von einer Standalone-Konfiguration (oftmals beschreiben Tutorials lediglich die Einrichtung unter nginx unter dem Webroot, bzw. als Subdomain). Eine Web-Suche nach <Anwendung> nginx SSL Proxy sollte Ergebnisse liefern, die zumindest die grobe Richtung des Unterfangens weisen.
Vorgehenswiese für andere Web-Applikationen
Nun seid ihr gefragt: Habt ihr andere Anwendungen mit der Konfiguration mit einem Gateway-Host und einzelnen (spezialisierten) virtuellen Hosts zum Laufen bekommen? Dann hinterlasst doch einen Kommentar oder schreibt mir besser noch eine E-Mail mit detaillierten Anweisungen. Ggf. wird der Artikel dann um konkrete Anweisungen für weitere Web-Applikationen erweitert.
FHEM
FHEM ist eine Software zur Heimautomatisierung, mit der verschiedenste Geräte/Protokolle verwaltet werden können. Damit wird klar, dass man hier besondere Vorsicht walten lassen muss, wenn die eigene Heimautomatisierung über das Internet erreichbar sein soll – es soll ja schließlich nicht jeder Zugriff auf die IT in den eigenen vier Wänden haben.
Die Installation der Software ist auf der FHEM-Homepage recht gut beschrieben. Hier geht es zwar um ein Paket für Debian, dies ist aber auch für andere Linux-Distributionen zu verwenden.
Daher wird dringend empfohlen, den Zugriff auf FHEM per Basic Authentication abzusichern. Dies kann direkt in FHEM erledigt werden, dennoch bevorzuge ich die Absicherung über den Webserver selbst.
Um die Basic Authentication einzurichten, muss zunächst einmal ein Paket installiert werden (ja, es ist ein Apache-Modul, aber dies wird auch für nginx verwendet):
1 | apt-get install apache2-utils |
Als nächstes wird eine .htpasswd-Datei generiert:
1 | htpasswd -c /etc/nginx/.htpasswd MeinBenutzer |
Für MeinBenutzer sollte der Benutzer angegeben werden, der später Zugriff auf FHEM haben soll. Anschließend wird nach einem Passwort gefragt, welches nochmals bestätigt werden muss.
Nach der Installation von FHEM kann die Heimautomatisierung auf drei verschiedenen Wegen aufgerufen werden:
- serverhostnameoderIP:8083: Optimierte Oberfläche für Desktop-PCs.
- serverhostnameoderIP:8084: Optimierte Version für Smartphones.
- serverhostnameoderIP:8085: Optimierte Darstellung für Tablets.
Diese drei Möglichkeiten sollen nun auch über nginx abgebildet werden. Da der Webserver von außen nur über die Ports 80 und 443 erreichbar ist, soll für jede Darstellung ein eigenes Verzeichnis auf dem Webserver dienen.
Dazu wird zunächst ein virtueller Host für FHEM angelegt:
1 | nano /etc/nginx/conf.d/owncloud.goip.de_fhem.conf |
Der Inhalt der Datei sieht folgendermaßen aus (wie immer muss der Port bei listen sich von allen anderen Ports der virtuellen Hosts unterscheiden):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 | server { listen 83; server_name 127.0.0.1; location /fhem { set $my_http_upgrade ""; set $my_connection "Connection"; if ($http_upgrade = "websocket") { set $my_http_upgrade $http_upgrade; set $my_connection "upgrade"; } proxy_set_header Upgrade $my_http_upgrade; proxy_set_header Connection $my_connection; proxy_read_timeout 3600; proxy_pass http://127.0.0.1:8083; proxy_redirect off; proxy_buffering off; } location /fhemphone{ proxy_pass http://127.0.0.1:8084; proxy_redirect off; proxy_buffering off; } location /fhemtablet { proxy_pass http://127.0.0.1:8085; proxy_redirect off; proxy_buffering off; } } |
Die if-Anweisung im location-Block für fhem ist zwar etwas unschön, wird aber für den Zugriff per Websocket benötigt. Dies muss im Prinzip nur eingestellt werden, wenn die Oberfläche von FHEM ständig aktuell gehalten werden soll (siehe FHEMWEB). Wenn Websockets auch für den Zugriff über Smartphone/Tablets verwendet werden sollen, sind diese Zeilen auch in die anderen location-Blöcke zu übernehmen.
Als nächstes folgt der Gateway-Host:
1 | nano /etc/nginx/conf.d/owncloud.goip.de.conf |
Hier fügen wir am Ende die Anweisungen für FHEM hinzu:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | # # FHEM # location ~* /(fhem|fhemphone|fhemtablet) { auth_basic "Restricted"; auth_basic_user_file /etc/nginx/htpasswd/.htpasswd; set $my_http_upgrade ""; set $my_connection "Connection"; if ($http_upgrade = "websocket") { set $my_http_upgrade $http_upgrade; set $my_connection "upgrade"; } proxy_set_header Upgrade $my_http_upgrade; proxy_set_header Connection $my_connection; proxy_read_timeout 3600; proxy_pass http://127.0.0.1:83; proxy_redirect off; proxy_buffering off; } |
Hier kommt auch die zuvor angelegte .htpasswd-Datei zum Einsatz, die den kompletten Zugriff auf FHEM begrenzt. Wie schon für den vHost für FHEM ist hier eine „Spezialbehandlung“ für Websockets notwendig.
Nun wird der Webserver noch neu gestartet, damit die Änderungen übernommen werden:
1 | service nginx restart |
Anschließend kann FHEM über die drei URLs aufgerufen werden:
- https://owncloud9tutorial.goip.de/fhem: Version für Desktop-Rechner.
- https://owncloud9tutorial.goip.de/fhemphone: Darstellung für Smartphones.
- https://owncloud9tutorial.goip.de/fhemtablet: Optimierte Version für Tablets.
Moodle
Moodle ist ein freies Kursmanagement und eine Lernplattform. Die Software bietet Möglichkeiten zur Unterstützung kooperativer Lern- und Lehrmethoden.
Um Moodle zu installieren, wird zunächst einmal die aktuellste Version heruntergeladen und in das entsprechende Verzeichnis verschoben:
1 2 3 | wget https://download.moodle.org/download.php/direct/stable33/moodle-latest-33.tgz tar -zxvf moodle-latest-33.tgz mv moodle /var/www/moodle |
Anschließend werden die benötigten Verzeichnisse erstellt und die Rechte vergeben:
1 2 3 | mkdir -p /var/moodledata chown -R www-data:www-data /var/www/moodle chown -R www-data:www-data /var/moodledata |
Moodle braucht zum Verwalten der Daten eine Datenbank. Diese wird zunächst mit der MySQL-Kommandozeile angelegt:
1 | mysql -u root -p |
Nach der Anmeldung als Root-User kann die Datenbank angelegt werden:
1 2 3 4 5 | CREATE DATABASE moodle; REATE USER 'moodleuser'@'localhost' IDENTIFIED BY 'pAsSw0rT'; GRANT ALL ON moodle.* TO 'moodleuser'@'localhost' IDENTIFIED BY 'pAsSw0rT' WITH GRANT OPTION; FLUSH PRIVILEGES; EXIT; |
Nun wird der Gateway-Host für Moodle erweitert:
1 | nano /etc/nginx/conf.d/nextcloudtutorial.goip.de.conf |
Hier wird folgender Block am Ende des Server-Blocks für SSL hinzugefügt. Wichtig ist dabei, dass der verwendete Port (proxy_pass) von sonst keiner anderen Webanwendung belegt ist:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | location ^~ /moodle/ { client_max_body_size 10G; proxy_buffering off; proxy_request_buffering off; proxy_max_temp_file_size 10240m; proxy_set_header Host $host; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_pass http://127.0.0.1:82; proxy_redirect off; } |
Nun wird ein neuer vHost für Moodle angelegt:
1 | nano /etc/nginx/conf.d/nextcloudtutorial.goip.de_moodle.conf |
Hier muss wieder der Port entsprechend der Weiterleitung im Gateway-Host angegeben werden:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | server { listen 82; server_name 127.0.0.1; root /var/www; rewrite ^/(.*.php)(/)(.*)$ /$1?file=/$3 last; index index.php index.html index.htm; client_max_body_size 10G; location ~ [^/]\.php(/|$) { try_files $uri =404; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_index index.php; fastcgi_pass php-handler; fastcgi_param PHP_VALUE "open_basedir=/var/www:/tmp/:/var/moodledata"; include fastcgi_params; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } } |
Damit die Änderungen an den virtuellen Host geladen werden, muss der Webserver noch neu gestartet werden:
1 | service nginx restart |
Nun kann es mit der Einrichtung von Moodle weiter gehen. Dazu einfach im Browser die URL https://nextcloudtutorial.goip.de/moodle aufrufen.
Wichtig: Die Website sieht nun etwas seltsam aus, da keine CSS-Styles geladen werden. Dies liegt daran, dass Moodle durch den Proxy nicht die richtige Root-URL ermitteln kann.
Trotzdem wird das Setup nun bis nach der Einrichtung der Datenbank-Verbindung durchgearbeitet. Nach der Einrichtung der Datenbank wird eine falsche Weiterleitung auf http://nextcloudtutorial.goip.de:82/moodle durchgeführt und es wird eine Fehlermeldung im Browser erscheinen.
An dieser Stelle wird das Setup kurz unterbrochen (Browser kann geöffnet bleiben) und wir modifizieren die Konfigurations-Datei von Moodle:
1 | nano /var/www/moodle/config.php |
Folgende Zeilen müssen hier hinzugefügt bzw. modifiziert werden:
1 2 | $CFG->wwwroot = 'https://nextcloudtutorial.goip.de/moodle'; $CFG->sslproxy=1; |
Nun kann das Moodle-Setup fortgeführt werden, indem der falsch angegebene Port aus der URL entfernt und die Seite neu geladen wird. Die Website sollte nun korrekt angezeigt werden.
Nach dem Durcharbeiten des Setups kann Moodle nun verwendet werden.
Netdata
Netdata ist eine Monitoring-Anwendung, die es erlaubt, Daten (wie z.B. Auslastung, Zugriffe auf einen Webserver, etc.) von einem Server übersichtlich darzustellen und auszuwerten. Demo-Anwendungen zu Netdata sind hier zu finden.
Um Netdata als Web-Applikation zu installieren, muss es neben den benötigten Paketen die Anwendung selbst zunächst einmal installiert werden:
1 2 3 4 5 | apt-get update apt-get install zlib1g-dev uuid-dev libmnl-dev gcc make autoconf autoconf-archive autogen automake pkg-config curl git clone https://github.com/firehol/netdata.git --depth=1 ~/netdata cd ~/netdata ./netdata-installer.sh |
Nach der Installation kann Netdata konfiguriert werden:
1 | nano /etc/netdata/netdata.conf |
Beispielsweise kann hier in der [global] Sektion festgelegt werden, wie umfangreich die History der erfassten Daten sein soll. Dazu den Kommentar bei der folgenden Zeile entfernen:
1 | history = 14400 |
Um das sog. Kernel Samepage Merging zu aktivieren, sind dann folgende Schritte notwendig: In der Datei /etc/rc.local sind diese Zeilen zu ergänzen:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | #!/bin/sh -e # # rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other # value on error. # # In order to enable or disable this script just change the execution # bits. # # By default this script does nothing. echo 1 > /sys/kernel/mm/ksm/run echo 1000 > /sys/kernel/mm/ksm/sleep_millisecs exit 0 |
Um Netdata nun in der Konfiguration mit einem nginx Gateway-Host zum Laufen zu bekommen, muss zunächst einmal der Gateway-Host ergänzt werden:
1 | nano /etc/nginx/conf.d/owncloud9tutorial.goip.de.conf |
Hier wird wie gewohnt eine Weiterleitung an einen nicht belegten Port des Webservers hinzugefügt:
1 2 3 4 | # netdata configuration location ^~ /netdata { proxy_pass http://127.0.0.1:84; } |
Die eigentliche Arbeit übernimmt ein spezieller vHost für Netdata:
1 | nano /etc/nginx/conf.d/owncloud.goip.de_netdata.conf |
Dabei sieht der Inhalt der Datei wie folgt aus:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 | upstream netdata { server 127.0.0.1:19999; keepalive 64; } server { listen 84; # the virtual host name of this subfolder should be exposed server_name 127.0.0.1; location /netdata { return 301 /netdata/; } location ~ /netdata/(?<ndpath>.*) { proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_http_version 1.1; proxy_pass_request_headers on; proxy_set_header Connection "keep-alive"; proxy_store off; proxy_pass http://netdata/$ndpath$is_args$args; gzip on; gzip_proxied any; gzip_types *; } } |
Zum Abschluss der Installation sollte sowohl Netdata, als auch nginx neu gestartet werden:
1 2 | systemctl restart netdata service nginx restart |
Der Aufruf erfolgt dann über ein Unterverzeichnis des Webservers: http://owncloud9tutorial.goip.de.conf/netdata
Zu guter letzt kann Netdata auch über Skripte upgedated (oder sogar deinstalliert werden):
1 2 | ./netdata-uninstaller.sh ./netdata-updater.sh |
Um ein Update vollautomatisch per Cronjob erledigen zu lassen, ist dieser wie folgt anzulegen:
1 | sudo ln -s /home/[BENUTZER]/netdata/netdate-update.sh /etc/cron.daily/netdata-update |
Vielen Dank an Hans für die umfangreiche Anleitung!
Pi-hole
Pi-hole ist ein Dienst, mit dem im LAN zentral Werbung und Tracker blockiert werden können. Man kann sich dies Ähnlich wie einen Hardware-Werbeblocker vorstellen.
Voraussetzung für den reibungslosen Betrieb ist eine statische IP-Adresse des Servers im lokalen Netzwerk.
Pi-hole wird durch folgenden Befehl installiert:
1 2 | sudo -s curl -sSL https://install.pi-hole.net | bash |
Dies startet einen interaktiven Installer, der erkennt, auf welcher Hardware Pi-hole laufen soll. Einige Einstellungen müssen hier jedoch noch konfiguriert werden:
- Upstream DNS-Provider: Hier wird ein DNS-Provider angegeben. Dieser wird benötigt, damit eine Anfrage an eine URL auf eine IP-Adresse im Internet gemappt werden kann. Hier kann man Custom wählen und einen DNS-Server seiner Wahl angeben. Empfehlenswert sind hier:
- Google: 8.8.8.8, 8.8.4.4
- 1.1.1.1 (performanter DNS-Service): 1.1.1.1, 1.0.0.1
- Der eigene Router: z.B. 192.168.178.1
- Protocols: Hier sollte man IPv4 und IPv6 (sofern vorhanden) wählen.
- Static IP Address: Der Installer sollte erkennen, dass bereits eine statische IP-Adresse konfiguriert wurde.
- Web admin interface: Hier sollte man On (Recommended) wählen, da man Pi-hole später ansonsten nur umständlich über die Kommandozeile bedienen kann.
- Log queries: Auch diese Option sollte man anschalten.
Nach einer kurzen Wartezeit ist Pi-hole installiert. Am Ende bekommt man nochmals eine Zusammenfassung gezeigt. Ganz unten in der Meldung wird das Passwort für den Admin-Zugang gezeigt, welches man sich merken sollte.
Pi-hole bringt den alternativen Webserver lighttpd mit. Da unser eigentlicher Webserver nginx ist, muss an der Konfiguration noch etwas geändert werden:
1 | nano /etc/lighttpd/lighttpd.conf |
Hier wird der Port des Webservers geändert:
1 | server.port = 90 |
Wichtig ist hier nur, dass der angegebene Port nicht schon von einem virtuellen Host von nginx belegt ist.
Danach wird lighttpd in den Autostart eingetragen und gestartet:
1 | systemctl enable lighttpd.service && service lighttpd restart |
Damit Pi-hole über den nginx Gateway-Host erreichbar ist, muss der Gateway-vHost noch angepasst werden.
Vorher sollte man aber noch ein Passwort für HTTP-Basic-Auth setzen, damit nicht jeder auf die Pi-hole Admin-Seite zugreifen kann.
1 2 3 4 | mkdir -p /etc/nginx/htpasswd apt-get update apt-get install apache2-utils htpasswd -c /etc/nginx/htpasswd/.htpasswd_pihole <User> |
Für den User kann man hier einen beliebigen Benutzernamen eingeben.
Nun passen wir noch den nginx Gateway-Host an:
1 | nano /etc/nginx/conf.d/meinedomain.de.conf |
Hier fügt man ganz unten (aber vor der letzten schließenden Klammer) folgende Anweisungen hinzu:
1 2 3 4 5 6 7 8 9 | location ^~ /pihole { auth_basic "Restricted"; auth_basic_user_file /etc/nginx/htpasswd/.htpasswd_pihole; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://127.0.0.1:90/admin; proxy_read_timeout 90; } |
Nach einem Neustart von nginx ist Pi-hole nun fertig eingerichtet und die Verwaltung kann über die URL https://meindomain.de/pihole/ aufgerufen werden.
Als DNS-Server sollte man nun noch im Router die IP des Rechners angeben, auf dem Pi-hole läuft. Auf diese Weise wird der DNS-Server einmal zentral im LAN umgestellt und es muss nicht bei jedem Gerät ein abweichender DNS-Server eingetragen werden.
Wenn ein Update für Pi-hole verfügbar ist, kann man dies einfach mit folgendem Befehl installieren:
1 | pihole -up |
Vielen Dank an Tino für die umfangreiche Anleitung!
Roundcube
Roundcube ist eine Anwendung für Webmail über IMAP. Leser Adrian K. hat dazu eine Konfiguration entwickelt, die es erlaubt, Roundcube neben ownCloud/Nextcloud auf dem gleichen Server laufen zu lassen.
Der Gateway-vHost wird dazu analog zu ownCloud/Nextcloud erweitert (hier wird z.B. der freie Port 83 für die Weiterleitung verwendet):
1 2 3 4 5 6 7 8 9 | location ^~ /mail { proxy_set_header Host $host; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto https; proxy_pass http://127.0.0.1:83; proxy_redirect off; } |
Für Roundcube wird anschließend ein eigenständiger vHost verwendet:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 | server { server_name 127.0.0.1; listen 127.0.0.1:83; root /var/www/; location ^~ /mail { index index.php; location ~ ^/favicon.ico$ { root /var/www/mail/skins/default/images; log_not_found off; access_log off; expires max; } location = /mail/robots.txt { allow all; log_not_found off; access_log off; } location ~ \.php$ { try_files $uri =404; fastcgi_split_path_info ^(.+\.php)(/.+)$; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_pass php-handler; fastcgi_connect_timeout 60; fastcgi_index index.php; fastcgi_param PHP_VALUE "open_basedir=/var/www/mail:/tmp/ upload_max_filesize = 1G post_max_size = 1G max_execution_time = 3600"; } location ~* /mail/\.(js|css|png|jpg|jpeg|gif|ico)$ { expires max; log_not_found off; } } } |
Vielen Dank an Adrian für die Konfiguration.
shellinabox
shellinabox ist ein Terminal, welches über eine Weboberfläche aufgerufen werden kann.
Um shellinabox mit einen Gateway-Host laufen zu lassen, ist erstmal eine Anpassung in der Konfiguration von shellinabox notwendig (nano /etc/default/shellinabox):
1 | SHELLINABOX_ARGS="--no-beep --localhost-only --disable-ssl" |
Besonders der letzte Parameter (–disable-ssl) ist hier wichtig, da der proxy_pass vom Gateway-Host an shellinabox unverschlüsselt über HTTP läuft. Dies ist aber kein Sicherheitsrisiko, da die Verschlüsselung „eine Ebene höher“ vom Gateway-Host übernommen wird.
Darüber hinaus sind folgende Erweiterungen im Gateway-vHost notwendig (angenommen, Port 83 ist noch nicht belegt):
1 2 3 4 | location ^~ /shellinabox { proxy_pass http://127.0.0.1:83; proxy_read_timeout 90; } |
1 2 3 4 5 6 7 8 9 10 | server { listen 83; server_name 127.0.0.1; location /shellinabox/ { rewrite ^/shellinabox/(.*) /$1 break; proxy_pass http://127.0.0.1:4200; proxy_read_timeout 90; } } |
Weiterführende Artikel
- Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban
- ownCloud 9 auf Ubuntu Server 16.04 LTS mit nginx, MariaDB, PHP 7 und Let’s Encrypt
- Ubuntu Server als Hyper-V Gastsystem installieren und optimal einrichten
- HTTPS für alle: SSL-Zertifikate mit Let’s Encrypt und nginx
Links
- WordPress
- Let’s Encrypt
- WordPress-Key-Generator
- Cascading Style Sheets (Wikipedia)
- HTTP-Statuscode (Wikipedia)
- WordPress absichern (Artikel-Serie von Kuketz IT-Security)
- FHEM
- Roundcube
- shellinabox
- Moodle
- Pi-hole
Ähnliche Artikel:
Nextcloud auf Ubuntu Server mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban 
ownCloud 9 auf Ubuntu Server 16.04 LTS mit nginx, MariaDB, PHP 7 und Let’s Encrypt ownCloud auf Ubuntu Server mit nginx, MariaDB und PHPWindows Server Advanced Power Management: Version 1.5.3 Windows Server Advanced Power Management: Version 1.5.4
Beliebt
-
Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban -
Nextcloud – Tipps & Tricks für Admins (und Benutzer) -
Nextcloud: Backups erstellen und wiederherstellen – manuell oder per Skript -
Nie mehr Werbung – Pi-hole auf Ubuntu Server 18.04 -
Ubuntu Server 18.04 LTS als Hyper-V Gastsystem installieren und optimal einrichten -
Nextcloud: Online-Office mit Collabora -
Nextcloud: Updates richtig durchführen -
Nextcloud auf Ubuntu Server mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban -
Nextcloud: Online-Office mit ONLYOFFICE (mit eigener Subdomain) -
Linux: Einfach E-Mails senden mit sSMTP
Hay Jan,
Danke für die Rückmeldung.
Habe es hinbekommen.
Falles wer wissen möchte wie man seinen Admin-/Benutzernamen ändern kann hier eine „Mini-Anleitung“ anhand der Daten aus der Anleitung von Jan. Natürlich lassen sich auch andere Nutzernamen dort ändern indem man die jeweilige ID anpasst.
sudo mysql -u root -p
MeInPasSw0rT
use wordpress_db
show tables;
SELECT ID, user_login, user_pass FROM ow5n6_users;
UPDATE ow5n6_users SET user_login = „wordpress_db_new_user_name“ WHERE ID = 1;
SELECT ID, user_login, user_pass FROM ow5n6_users;
exit
Grüße
Hi,
hey super, danke für die Anleitung. Ist vielleicht auch für andere interessant.
Gruß,
Jan
Hallo Jan,
echt toll deine Anleitungen! Habe nun zum ersten Mal einen Linux Server am Laufen. Mit Nextcloud und WordPress parallel im Betrieb.
Jetzt komme ich allerdings nicht weiter. Ich möchte den WordPress Admin Bereich und das Login durch auth_basic sichern. Die Datei htpasswd habe ich erzeugt und mit generierten Daten gefüllt. Aber wie sieht mein location Eintrag aus? Und wo genau kommt der hin?
Danke dir!
Meiko
Hi Meiko,
ein Basic-Auth nachträglich hinzuzufügen ist prinzipiell kein Problem. Allerdings ist der Admin-Bereich in WP ja bereits durch ein Passwort geschützt. Man hätte dann immer eine zweimalige Passwort-Abfrage.
Erst einmal brauchst du dazu folgendes Paket:
apt-get install apache2-utils
Danach lässt du eine htaccess-Datei generieren (wenn dein User z.B. „Admin“ heißt):
sudo htpasswd -c /etc/nginx/htpasswd/.htpasswd_wpadmin Admin
Hier wirst du dann zwei mal nach einem Passwort gefragt.
Zum Schluss wird die Datei noch in den WP-vHost eingebunden. Dazu eine neue Location anlegen:
location /wordpress/wp-admin/ {auth_basic "Authorization Required";
auth_basic_user_file /etc/nginx/htpasswd/.htpasswd_wpadmin;
}
Den Webserver anschließend neu starten und nun sollte der Admin-Bereich zusätzlich durch Basic-Auth gesichert sein.
Gruß,
Jan
Großartig! Das hat jetzt geklappt. Ich hatte es zuvor mit einem online-generierten Inhalt der htpasswd nicht hinbekommen. Dann muss es daran gelegen haben. Vielen Dank.
Hallo Jan,
hättest du Lust eine Erweiterung für den RSS-Reader miniflux hinzuzufügen? :-)
Viele Grüße
Kai
Hallo Kai,
hast du denn miniflux schon zum Laufen bekommen? Dann kann ich die Konfiguration gern in den Artikel mit aufnehmen.
Gruß,
Jan
Hallo Jan,
danke für deine Antwort. Leider nein. Ich habe es in einer Test-VM leider nicht zum Laufen bekommen. Die Installation bekomme ich über das Debian-Package zwar noch hin, aber der Connect zur Datenbank und später die Einrichtung mit Nginx klappt nicht bzw. soweit komme ich noch nicht einmal. Ich persönlich würde mich natürlich sehr freuen, wenn dies nicht viel Arbeit für dich bedeutet. Vielleicht gibt es noch weitere RSS-Leser, die einen selbstgehosteten RSS-Dienst wünschen?!
Viele Grüße
Kai
Hi Kai,
im Moment habe ich leider nicht so viel Zeit für „Computer-Krams“, deshalb kann ich auch nichts genaues versprechen. Ich nehme das Thema aber mal mit auf die Todo-Liste.
Gruß,
Jan
Hallo Jan,
wie schaut es eigentlich mit phpmyadmin aus, gibt es hierfür ne gute Anleitung
hierzu?
Ich bekomme es über apt-get install phpmyadmin und sudo ln -s /usr/share/phpmyadmin /var/www/html so nicht hin.
Möchte ne WP-Seite auf meinem Test-Server installieren und benötige für die Datenbank Bereinigung und übernahme hierzu phpmyadmin.
Vielen Dank
Gruß Hans
Hi Hans,
eine Erweiterung des Artikels für phpMyAdmin ist sicherlich sinnvoll. Ich werde das mal einplanen, wird aber evtl. eine Weile dauern.
Gruß,
Jan
Hallo Jan,
vielen Dank.
Gruß Hans
Hi Hans,
ich habe momentan leider sehr wenig Zeit, daher habe ich das nur mal eben auf die Schnelle ausprobiert.
Ich denke über die Einrichtung von phpMyAdmin müsste ich ein wenig mehr schreiben, da es doch etwas komplizierter ist. Wenn du phpMyAdmin allerdings schon installiert und konfiguriert hast, dann probier doch mal folgendes aus:
Einfach im Gateway-Host (unter dem Nextcloud-location-Block):
location /phpmyadmin {root /usr/share/;
index index.php index.html index.htm;
location ~ ^/phpmyadmin/(.+\.php)$ {
try_files $uri =404;
root /usr/share/;
fastcgi_pass php-handler;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include /etc/nginx/fastcgi_params;
fastcgi_param PHP_VALUE "open_basedir=/var/www:/tmp/:/usr/share/phpmyadmin:/usr/share/php:/etc/phpmyadmin/";
}
location ~* ^/phpmyadmin/(.+\.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt))$ {
root /usr/share/;
}
}
location /phpMyAdmin {
rewrite ^/* /phpmyadmin last;
}
Das hat zumindest bei einem schnellen Test bei mir gut funktioniert.
Gruß,
Jan
Hallo Jan,
Danke für die Anleitung, beschreibt exakt was mir neben meiner NextCloud noch fehlt. Gemäß deiner *NextCloud 9x. auf Ubuntu18.04* Anleitung hab ich diese erfolgreich auf Debian9 (PHP7.2) installiert bekommen, und kann nur feststellen, dass sie stabil und ausgehärtet gemäß deiner Instruktionen ihren Dienst verrichtet.
Beim Versuch WordPress gemäß diesem Beitrag hinzuzufügen bekomme ich allerdings beim Aufruf im Browser das Konfig-File im Browserfenster präsentiert, zum Setup komme ich (noch) nicht.
Die gelistete IP 192.168.x.3 ist die meines Servers auf dem alles installiert ist.
die Zeilen
if (strpos($_SERVER[‚HTTP_X_FORWARDED_PROTO‘], ‚https‘) !== false)
$_SERVER[‚HTTPS‘]=’on‘;
if(isset($_SERVER[‚HTTP_X_FORWARDED_HOST‘]))
$_SERVER[‚HTTP_HOST‘] = $_SERVER[‚HTTP_X_FORWARDED_HOST‘];
sind direkt nach _?php + Kommentarblock_ und dem define _(‚WP_HOME’_ eingefügt.
Ich bin beim NGinx im Log fündig geworden.
2018/07/08 17:26:54 [error] 865#865: send() failed (111: Connection refused) while resolving, resolver: 192.168.x.3:53
2018/07/08 17:26:54 [error] 865#865: *73 FastCGI sent in stderr: „PHP message: PHP Fatal error: Uncaught Error: Call to undefined function wp() in /var/www/wordpress/wp-blog-header.php:16
Stack trace:
#0 /var/www/wordpress/index.php(17): require()
#1 {main}
thrown in /var/www/wordpress/wp-blog-header.php on line 16“ while reading upstream, client: 127.0.0.1, server: 127.0.0.1, request: „GET /wordpress/ HTTP/1.0“, upstream: „fastcgi://unix:/run/php/php7.2-fpm.sock:“, host: „meinhost.goip.de“
in der meinhost.goip.de.conf sind folgende Einträge drin:
[…]
upstream php-handler {
server unix:/run/php/php7.2-fpm.sock;
}
[…]
# This should be chain.pem
# See here: https://certbot.eff.org/docs/using.html
ssl_trusted_certificate /etc/letsencrypt/live/meinhost.goip.de/chain.pem;
resolver 192.168.x.3;
[…]
Verhindern hier die Aushärtungsfeatures aus der NextcloudConf, eine Zugriff, muss ich noch was zulassen ?
Habe gemäß deiner NextCloud-Installdoku die Fail2Ban, UFW, eMail per SSMTP konfiguriert, mehr nicht.
Was mache ich falsch, habe ich übersehen, muss ich ggf wegen php7.2 noch hinzufügen ?
Danke – wie immer – für Deine Unterstützung.
Gruß
Christian
Hi Christian,
ich habe gerade mal versucht, dein Problem nachzuvollziehen. Ich konnte WordPress zwar auch nicht auf Anhieb zum Laufen bekommen, aber mein Fehler sah etwas anders aus.
Wie dem auch sein, versuch doch nochmals folgendes – auch wenn du es eigentlich schon gemacht hast:
find /var/www/wordpress/ -type f -print0 | xargs -0 chmod 0640find /var/www/wordpress/ -type d -print0 | xargs -0 chmod 0750
chown -R www-data:www-data /var/www/wordpress
Danach hat das bei mir auf Anhieb geklappt.
Ansonsten: Wenn dir eine PHP-Seite als Download angeboten wird, dann stimmt meist etwas nicht beim Zusammenspiel zwischen Webserver und PHP. Daher kontrolliere doch mal bitte, ob der PHP-Handler (upstream php-handler {…) in deinem Gateway-vHost definiert ist (und nicht z.B. im Nextcloud-vHost).
Gruß,
Jan
Hallo Jan,
die Berechtigungen hab ich schon gesetzt. Passiert daher, wenn das wp…conf erst nach der Berechtigungsvergabe angelegt wird, dann hat es root Rechte. Habe ich bereits herausgefunden und fixen können.
Zum zweiten Teil deiner Antwort, ich dachte das habe ich oben gepostet:
In der
meinhost.goip.de.conf
sind folgende Einträge drin:
[…]
upstream php-handler {
server unix:/run/php/php7.2-fpm.sock;
}
[…]
# This should be chain.pem
# See here: https://certbot.eff.org/docs/using.html
ssl_trusted_certificate /etc/letsencrypt/live/meinhost.goip.de/chain.pem;
resolver 192.168.x.3;
[…]
ich hoffe das ist die richtige conf Datei (meinhost.goip.de.conf) für den vhost ???
Wenn ich die Fehlermeldung richtig interpretiere, dann hat er ein Problem den resolver unter 192.168.x.3:53, Connection refused, 1. Zeile nginx log.
Hab ich die richtige vhost (meinhost.goip.de.conf)?
wieso kann nginx nicht auf die resolver ip zugreifen ? (hab gerade mal den port 53 in der ufw geadded, durchgebootet, aber keine Änderung))
denke das Problem ist jetzt erstmal nicht WordPress, sondern das vhost Setup. irgendeine Kleinigkeit übersehe ich.
Gruß
Christian
Hi Christian,
nein, das ist bei dir schon alles in der richtigen conf-Datei von nginx.
Das Problem liegt hier denke ich gar nicht an der Umgebung (Webserver, etc), sondern in WP selbst. Das sagt ja schon die Fehlermeldung: Eine Funktion wird aufgerufen und kann nicht gefunden werden (vermutlich weil diese nicht definiert ist).
Wenn man nach der Fehlermeldung sucht, dann findet man hier und da Hinweise, dass bei der Installation von WP etwas schief gelaufen ist und man einfach nochmal das WP-Verzeichnis löschen sollte und die Installation von vorn begeinnen soll.
Hast du WP durch wget https://wordpress.org/latest.tar.gz installiert, oder z.B. über FTP auf den Server übertragen?
Gruß,
Jan
Hallo Jan,
ich hab die wordpress_db + user gelöscht, neu angelegt, das wordpress Verzeichnis gelöscht. nochmal wie von dir beschrieben mit wget ins /var/www Verzeichnis runtergeladen, die config neu editiert, neue Schlüssel von WordPress geholt, Rechte neu zugewiesen. im Browser wird mir daraufhin mein wp-config.php im Browser angezeigt ???…
Im error.log von nginx folgendes
2018/07/09 19:54:03 [error] 758#758: send() failed (111: Connection refused) while resolving, resolver: 192.168.x.3:53
2018/07/09 19:54:03 [error] 758#758: *4 FastCGI sent in stderr: „PHP message: PHP Fatal error: Uncaught Error: Call to undefined function wp() in /var/www/wordpress/wp-blog-header.php:16
Stack trace:
#0 /var/www/wordpress/index.php(17): require()
#1 {main}
thrown in /var/www/wordpress/wp-blog-header.php on line 16“ while reading upstream, client: 127.0.0.1, server: 127.0.0.1, request: „GET /wordpress/ HTTP/1.0“, upstream: „fastcgi://unix:/run/php/php7.2-fpm.sock:“, host: „meinhost.goip.de“
…sagt wieder, dass der Resolver nicht gestartet werden kann (UFW ist im Moment deaktiviert). Im angemoserten .php (/var/www/wordpress/wp-blog-header.php:16) steht in Zeile 16: wp();
denke mal das ist der eigentliche Start von WordPress.
Hat das Problem was mit PHP 7.2 zu tun ? von 7.2 ist alles installiert was du für die NextCloud definiert hast. Fehlt da noch was ? Mich verwundert die Anzeige meines wp_config.phps im Browser. Das sagt mir wenigstens irgendwie, dass die ganze vHost Konfiguration in Ordnung sein muss, oder?
Die ganzen Host-Konfig Files sind alle doublechecked, entsprechen alle deinen Vorgaben.
Idee?
Gruß
Christian
Hi Christian,
OK, versuchen wir was anderes.
Ich kann mir zwar nicht vorstellen, dass es an der Fehlermeldung mit dem resolver liegt, aber du schreibst in einem anderen Kommentar, dass du hier die IP des Servers eingetragen hast, auf dem alles läuft. Ich würde als resolver eher einen DNS-Server eingeben (also z.B. die IP deines Routers, 1.1.1.1, 8.8.8.8, etc.), da ich nicht denke, dass auf deinem Server ein DNS-Server läuft, oder?
Probier das doch nochmal aus. Wenn das auch nichts bringt, dann schick mir doch mal bitte deine vHosts, die wp-config.php und die beiden php.ini-Dateien per Mail. Dann schaue ich da mal drüber.
Gruß,
Jan
Hay, hab mal wieder eine Frage.
Wie kann ich in:
define(‚WP_HOME‘, ‚https://owncloud9tutorial.goip.de/wordpress‘);
define(‚WP_SITEURL‘, ‚https://owncloud9tutorial.goip.de/wordpress‘);
Noch eine Domain bzw die Lokale Netzwerk Adresse Hinzufügen?
Hab es so versucht:
define(‚WP_HOME‘, ‚https://domain1.goip.de/wordpress‘);
define(‚WP_HOME‘, ‚https://domain2.goip.de/wordpress‘);
define(‚WP_SITEURL‘, ‚https://domain1.goip.de/wordpress‘);
define(‚WP_SITEURL‘, ‚https://domain2.goip.de/wordpress‘);
Leider klappt dies nicht.
Danke, schon mal für die Hilfe. :)
Hi,
mit dem jeweils zweiten „define…“ wird das erste überschrieben, daher wird das bei dir nicht so recht funktionieren.
Wenn der Webserver richtig konfiguriert ist, so dass die Domains über den Request hinweg „erhalten bleiben“, dann würde ich mal probieren, die beiden Variablen folgendermaßen zu definieren (mittels PHP-Variablen):
define('WP_SITEURL', 'https://' . $_SERVER['HTTP_HOST']);define('WP_HOME', 'https://' . $_SERVER['HTTP_HOST']);
Ein anderer Ansatz wäre vermutlich:
define('WP_HOME','https://'. $_SERVER['SERVER_NAME']);define('WP_SITEURL','https://'. $_SERVER['SERVER_NAME']);
Einer der beiden Ansätze sollte allerdings funktionieren.
Gruß,
Jan
Hay,
funktioniert beides leider nicht aber durch die Ansätze von dir habe ich was mit Google auf die schnelle gefunden was Funktioniert.
if ($_SERVER[‚HTTP_HOST‘] == ‚domain1.goip.de‘) {
define(‚WP_SITEURL‘, ‚https://domain1.goip.de/wordpress‘);
define(‚WP_HOME‘, ‚https://domain1.goip.de/wordpress‘);
} else {
define(‚WP_SITEURL‘, ‚https://domain2.goip.de/wordpress‘);
define(‚WP_HOME‘, ‚https://domain2.goip.de/wordpress‘);
}
Hi,
wir sind ja in einem Unterverzeichnis des Webservers. Sorry, hatte ich ganz vergessen.
Dann sollte das aber auf jeden Fall klappen:
define('WP_SITEURL', 'https://' . $_SERVER['HTTP_HOST'] . '/wordpress');define('WP_HOME', 'https://' . $_SERVER['HTTP_HOST'] . '/wordpress');
Gruß,
Jan
Hay,
jetzt habe ich zwei Wege die zum selben Ergebnis führen.
Ich glaube ich nutze deinen weg da er kürzer ist und das ganze somit weniger Fehler anfällig sein sollte. Danke dir! :)
Grüße
Servus Jan,
vielen Dank für die guten, ausführlichen Anleitungen! Habe so LEMP + NC zum laufen bekommen.
Würde jetzt gerne noch meine Home Page, die mir mal ein Freund gebastelt hatte, von einem 1u1 Server auf meinen Server umziehen. Ich bin aber leider totaler Anfänger in Sachen Linux.
Auf dem 1u1 Server ist Folgendes:
– website
— index.html
— bootstrap
— css
— fonts
— js
— css
— fonts
— images
— js
— plugins
— isotope
Könntest du mir bitte erklären wie ich das machen kann?
Freundliche Grüße,
Sebastian
oh sorry, sehe gerade das die Verzeichnisstruktur durcheinander geraten ist.
Hier nochmal:
website/index.html
website/bootstrap/css
website/bootstrap/fonts
website/bootstrap/js
website/css
website/fonts
website/images
website/js
website/plugins
website/plugins/isotope
Freundliche Grüße,
Sebastian
Hi Sebastian,
ist etwas schwer, hier pauschal eine AUssage zu treffen, aber vielleicht kann ich dir den einen oder anderen Hinweis liefern.
Zunächst muss das gesamte Verzeichnis „website“ nach /var/www/ kopiert werden.
Anschließend wird der Gateway-Host wie schon bei NC erweitert, z.B.:
location ^~ /website/ {client_max_body_size 10G;
proxy_connect_timeout 3600;
proxy_send_timeout 3600;
proxy_read_timeout 3600;
send_timeout 3600;
proxy_buffering off;
proxy_request_buffering off;
proxy_max_temp_file_size 10240m;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://127.0.0.1:83;
proxy_redirect off;
}
Zu guter letzt kommt noch ein spezieller vHost für deine Website zum Einsatz, der dann Ziel des proxy_pass ist. Im einfachsten Fall ist dies dann:
server {server_name 127.0.0.1;
listen 127.0.0.1:83;
root /var/www/;
location ^~ /website {
index index.php;
location /website {
try_files $uri $uri/ /website/index.html;
}
}
}
Mehr kann ich dir allerdings nicht sagen, da ich nicht weiß, welchen Technologien diese Website benötigt (PHP, Node, etc.). Hier würde ich mal bei deinem Freund nachfragen, der kann dir dann sicher auch mit dem vHost etwas unter die Arme greifen.
Gruß,
Jan
Vielen Dank. So hat es auf Anhieb geklappt.
Freundliche Grüße,
Sebastian
Hallo,
erstmal vielen Dank für die Anleitung! Hat funktioniert.
Ich habe aber eine Frage:
Wie bekomme ich es hin das anstelle von https://meinedomain.de/worpress
z.B. https://meinedomain.de/webseite als url funktioniert?
Hallo Moritz,
dazu müsstest du sämtliche vorkommmnisse von „wordpress“ durch „website“ ersetzen:
Gruß,
Jan
Hallo Jan,
ich habe auf meinem OpenSuse LEap 15 auch die zweite Anwendung (WordPress) nach Deinem Tutorial durchgeführt (auch da wieder mit ein/zwei kleinen lokalen Anpassungen).
Es läuft soweit eigentlich, ich habe aber zwei Probleme:
– Wenn ich die Seite von einem neuen Rechner erstmalig aufrufe, dann scheit das CSS nicht geladen zu werden (siehe die Anpassung zum Ausliefern via HTTPS). Diese Anpassung habe ich gemacht. Wenn ich die Seite dann noch einmal neu lade (refresh), passt auch das Design.
Woran kann das liegen?
– Wenn ich Bilder in die MEdiensammlung hoch laden will (um zum Beispiel das Header Foto des Designs zu tauschen), dann erhalte ich einen upload failed: HTTP-Fehler. Irgendeine Idee, wie ich das näher eingrenzen kann? VErschiedene Filetypen (jpg, png, gif) habe ich bereits erfolglos versucht.
Danke und Gruß,
Martin
Kurzes Update: Ich habe gesehen, dass ich im nginx-Log eine Menge authorization issues habe wie zum Beispiel das hier:
2018/09/04 19:03:29 [crit] 18612#18612: *1 open() „/var/lib/nginx/proxy//1/00/0000000001“ failed (13: Permission denied) while reading upstream, client: 91.67.16.103, server: soltauhome.dyndns.org, request: „GET /Travelblog/wp-content/themes/twentyfifteen/style.css?ver=4.9.8 HTTP/2.0“, upstream: „http://127.0.0.1:83/Travelblog/wp-content/themes/twentyfifteen/style.css?ver=4.9.8“, host: „soltauhome.dyndns.org“, referrer: „https://soltauhome.dyndns.org/Travelblog/“
Alle Files im htdocs Verzeichnis gehören dem User, mit dem nginx läuft, das ist bei mir wwwrun.
Woran kann das liegen?
Hi Martin,
die Fehler mit CSS und beim Upload sagen mir nun nichts. Wenn das mit dem Fehler im nginx-Log zu tun hat, dann probier mal folgendes:
chown -R wwwrun:wwwrun /var/lib/nginxVielleicht werden damit ja auch die anderen Probleme gelöst.
Gruß,
Jan
Hallo Jan,
DAS WAR’s. Du bist unglaublich :-)
Danke für die schnelle Hilfe.
Gruß,
Martin
Hay Jan,
habe mal wieder ein kleines Problem und hoffe du kannst mir da weiterhelfen.
Also ich habe mir jetzt noch Pi-hole eingerichtet. Das ganze läuft auch soweit so gut. Nur ich lande mit der lokalen Domain und IP (http://pi.hole/admin/) immer auf meine Externe DynDNS. Wie kann ich das beheben? Alternativ funktioniert zwar auch http://pi.hole:90/admin/ aber das finde etwas unschön gelöst jedes mal Domain + Port. Danke, schon mal für die Hilfe.
Gruß
Murderhead
Hi,
die Domain pi.hole löst auf dem Server auf, auf dem neben Pi-hole auch deine normale Domain (mit z.B. Nextcloud) läuft.
Der Gateway-Host ist vermutlich als „default server“ definiert, so dass er prinzipiell alle Anfragen entgegennimmt, die er nicht auf eine ihm zugeordnete Domain mappen kann. So gelangst du dann ganz normal auf deinen Webserver, der dann einfach nur die erste Seite deiner DynDNS-Domain ausliefert.
Wenn dich das stört, dann könntest du einfach neben dem Gateway-Host noch einen zusätzlichen vHost einrichten (server_name pi.hole;), der aber einfach leer bleibt oder ein „deny all“ enthält.
Wenn es dir nur um den Aufruf geht, dann sollte wie in dieser Anleitung gezeigt auch meinedomain.de/pihole funktionieren.
Gruß,
Jan
Hallo Jan,
ich bräuchte nochmal deine Hilfe.
Vielleicht hilft es ja auch anderen Anfängern weiter.
Ich würde gerne den Plex Media Server über Nginx mit „meinedomain.de/plex“ verschlüsselt ansprechen.
Habe schon viel Code dazu gelesen. Bekomme es aber nicht hin. Ich verstehe nicht was im Gateway-Host „meinedomain.de.conf“ einzutragen ist und was in die Virtual-Host „meinedomain.de_plex.conf“ einzutragen ist.
Habe hier mal ein Code-Beispiel rasukopiert:
# Configuration for Plex Media Server.
server {
listen 443 ssl;
server_name ;
ssl on;
send_timeout 100m;
ssl_stapling on;
ssl_stapling_verify on;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $server_addr;
proxy_set_header Referer $server_addr;
proxy_set_header Origin $server_addr;
gzip on;
gzip_vary on;
gzip_min_length 1000;
gzip_proxied any;
gzip_types text/plain text/css text/xml application/xml text/javascript application/x-javascript image/svg+xml;
gzip_disable „MSIE [1-6]\.“;
client_max_body_size 100M;
proxy_set_header X-Plex-Client-Identifier $http_x_plex_client_identifier;
proxy_set_header X-Plex-Device $http_x_plex_device;
proxy_set_header X-Plex-Device-Name $http_x_plex_device_name;
proxy_set_header X-Plex-Platform $http_x_plex_platform;
proxy_set_header X-Plex-Platform-Version $http_x_plex_platform_version;
proxy_set_header X-Plex-Product $http_x_plex_product;
proxy_set_header X-Plex-Token $http_x_plex_token;
proxy_set_header X-Plex-Version $http_x_plex_version;
proxy_set_header X-Plex-Nocache $http_x_plex_nocache;
proxy_set_header X-Plex-Provides $http_x_plex_provides;
proxy_set_header X-Plex-Device-Vendor $http_x_plex_device_vendor;
proxy_set_header X-Plex-Model $http_x_plex_model;
# Web Sockets
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection „upgrade“;
proxy_redirect off;
proxy_buffering off;
location / {
proxy_pass http://:32400/;
}
} #Quelle http://www.xed.ca
Kannst du mir bitte sagen wie ich den Code für den Server verändern muss, damit er mit deiner super Anleitung „Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban“ konform ist?
Vielen Dank
Freundliche Grüße,
Sebastian
Hi Sebastian,
so wie ich das sehe, wird nginx in deinem Beispiel einfach genutzt, um den Request an Plex weiterzuleiten.
Daher sollte eine Anpassung im Gateway-Host ausreichen. Unter dem location-Block für Nextcloud/ownCloud fügst du einfach einen weiteren location-Block für Plex ein:
location ^~ /plex/ {proxy_set_header X-Plex-Client-Identifier $http_x_plex_client_identifier;
proxy_set_header X-Plex-Device $http_x_plex_device;
proxy_set_header X-Plex-Device-Name $http_x_plex_device_name;
proxy_set_header X-Plex-Platform $http_x_plex_platform;
proxy_set_header X-Plex-Platform-Version $http_x_plex_platform_version;
proxy_set_header X-Plex-Product $http_x_plex_product;
proxy_set_header X-Plex-Token $http_x_plex_token;
proxy_set_header X-Plex-Version $http_x_plex_version;
proxy_set_header X-Plex-Nocache $http_x_plex_nocache;
proxy_set_header X-Plex-Provides $http_x_plex_provides;
proxy_set_header X-Plex-Device-Vendor $http_x_plex_device_vendor;
proxy_set_header X-Plex-Model $http_x_plex_model;
# Web Sockets
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection „upgrade“;
proxy_redirect off;
proxy_buffering off;
proxy_pass http://:32400/;
}
Das sollte für den Anfang erst einmal ausreichen. Evtl. muss man hier noch Timeouts, etc. erhöhen, aber das solltest du erst tun, wenn es im laufenden Betrieb zu Problemen kommt.
Gruß,
Jan
Vielen Dank für die Antwort. Du hast wieder mal Licht ins Dunkle gebracht ;)
Hatte nicht verstanden, dass es sich hier nur um Einstellungen im Gateway-Host handelt.
Der obige Code funktioniert so aber leider nicht, weil – so verstehe ich es – Plex mit „meinedomain.de:32400/web“ gestartet wird und „meinedomain.de/plex“ erst auf „meinedomain.de:32400/web“ weitergeleitet werden muss.
So hat es bei mir dann funktioniert:
location /web {
proxy_pass http://127.0.0.1:32400;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location /plex {
proxy_pass http://127.0.0.1/web;
}
Also vielen Dank nochmal für deine Unterstützung!
Freundliche Grüße,
Sebastian
Hay Jan,
mir ist gerade aufgefallen das der Pi-hole ja auch eine Block-Seite anzeigen sollte aber mit dieser Konfiguration kommt nichts außer „Diese Website ist nicht erreichbar“. Das liegt wahrscheinlich dadran das die interne Domain pi.hole immer nach WordPress weiterleitet was zum „502 Bad Gateway“ führt. Wie könnte man dieses Problem lösen? Eine Idee? :D
Gruß
Murderhead
Hi,
also ich denke, das ist das ganz normale Verhalten. pi.hole zeigt auf die lokale IP deines Webservers (über den noch mehr Webanwendungen laufen). Der Webserver wird wohl auf den Namen deiner DynDNS-Domain und die lokale IP hören (server_name meinedomain.de 192.168.178.60;). Nun kommt ein Request mit pi.hole als Ziel an. Dieser Request ist für nginx erst einmal unspezifisch, da er die Domain nicht kennt. Nun wird dieser Request ganz normal abgearbeitet. Wenn z.B. nach /ad/banner.htm gefragt wird, dann versucht nginx, diese location aufzulösen. Dies ist aber nicht möglich.
Um das zu umgehen, musst du Pi-hole wohl auf einer zweiten Maschine installieren, auf der zumindest kein Webserver nebenbei läuft. In so einer Konstellation betreibe ich meine Pi-hole-Instanz. Dennoch habe ich auch noch nie eine solche „Pi-hole-Blockseite“ zu sehen bekommen. Wenn ich z.B. Google Analytics aufrufe, dann bekomme ich in Chrome immer nur die Fehlermeldung „DNS_PROBE_FINISHED_NXDOMAIN“.
Gruß,
Jan
Hay Jan,
Ich habe jetzt auch herausgefunden wie man die Block-Seite zuschalten kann. Nur ich kriege es trotzdem nicht zum Laufen. Außer das ich jedes mal mein Pi-hole schrotte und ihn Reparieren darf. Vielleicht hast du sofern du lust auf eine Block-Seite hast vor es mit deiner Konstellation mal auszuprobieren.
Hier die Dokumentation dazu:
https://docs.pi-hole.net/ftldns/blockingmode/
Gruß,
Murderhead
Hi,
ja, es gibt beim Pi-hole mehrere Blocking-Modi. Ich empfehle jedoch den Standard-Modus (
BLOCKINGMODE=NULL), weil dieser darauf optimiert ist, die beste Performance zu bieten. Bei allen anderen Modi kann es passieren, dass HTTPS-Verbindungen in einem Timeout laufen, da die Verbindung nicht sofort Server-seitig gerschlossen wird. Das sorgt dann dafür, dass die allgemeine Performance beim Surfen gefühlt etwas langsamer wird. Hier müsste man dann mit persistenten Einträgen in den iptables nachhelfen (siehe hier).Trotzdem kann ich den Block-Modus einfach umstellen. Habe das mal mit
BLOCKINGMODE=IP-NODATA-AAAAgetestet: Einfach diesen Inhalt in die Datei /etc/pihole/pihole-FTL.conf einfügen und dann einen Befehl, um die Änderungen zu übernehmen (sudo killall -SIGHUP pihole-FTL). Nun werden diese Pi-hole-Blockseiten angezeigt. Pi-hole läuft bei mit allerdings auf einer eigenständigen Maschine.Was meinst du nun damit, dass du dir den Pi-hole schrottest und du danach reparieren darfst? Wie äußert sich das Problem bei dir? Pi-hole ist die aktuelle Version 4.0?
Gruß,
Jan
Hay Jan,
Ich habe sogar die aktuelle vDev Build drauf. Mit schrotten meine ich das ich danach keine Webseite mehr aufrufen kann weil immer sowas wie DNS_PROBE_FINISHED_BAD_CONFIG usw kommt. Das selbe Problem habe ich lustigerweise auch wenn ich meinen Raspberry Pi neustarte. Dann beginnt der ganze Spaß mit pihole -r danach direkt cd /etc/pihole und dort dann cp adlists.list.old adlists.list und zu guter letzt noch pihole -f und pihole -g um den Spaß wieder ans laufen zu bekommen. Ich hoffe du hast eine Idee woran das liegen könnte. Weil auf dauer nervt das schon etwas.
Gruß,
Murderhead
Hi,
welche Version von Pi-hole wird bei dir in der Admin-UI angezeigt?
Die Sache mit dem Umstellen des Blocking-Mode wird meines Wissens erst mit Pi-hole 4.0 unterstützt.
Aber wenn bei dir der Pi-hole nach dem Reboot des Raspis auch nicht mehr funktioniert, dann scheint hier irgendwas grundsätzliches nicht zu stimmen.
Steht hier irgendwas im syslog oder unter /var/log/pihole.log? Hast du Pi-hole schonmal komplett entfernt und neu installiert?
Ohne zu wissen, was hier schief läuft, fällt es mit etwas schwer, einen konkreten Tipp zu geben. Du könntest hier aber auch mal im Pi-hole-Forum nachfragen.
Gruß,
Jan
Hey Jan,
Laut Admin Webinterface:
Pi-hole Version vDev (development, v3.3.1-467-ga896153)
Web Interface Version vDev (devel, v3.3-319-gaea7d1aa)
FTL Version vDev (development, vDev-7700e95)
Laut pihole -v:
Pi-hole version is v3.3.1-467-ga896153 (Latest: v4.0)
AdminLTE version is v3.3-319-gaea7d1aa (Latest: v4.0)
FTL version is vDev-7700e95 (Latest: v4.0)
pihole -up gibt aus:
[i] Checking for updates…
[i] Pi-hole Core: up to date
[i] Web Interface: up to date
[i] FTL: up to date
[✓] Everything is up to date!
Beim nächsten neustart wenn Pi-hole sich selbst dadruch wieder schrottet werde ich mal die Logs kontrollieren.
Neuinstallieren? Habe Pi-hole vielleicht gerade mal 1 Woche Installiert. Bin dann von Stabel auf vDev geswitcht in der Hoffnung das sich das Problem dadurch löst. Na ja, leider nicht.
Gruß,
Murderhead
Hi,
ok, das ist seltsam. Pi-hole sollte meinen Recherchen nach auf auf dem Raspi in der Version 4 verfügbar sein. Durch den Befehl curl -sSL https://install.pi-hole.net | bash sollte diese eigentlich auch installiert werden.
Wie hast du die vDev-Version installiert? Direkt über Git gecloned?
„Holzhammer-Methode“ wäre hier dann sicherlich das Clonen des Branches für Version 4.0.
Gruß,
Jan
Moin!
Ich versuche den Login wie bei Nextcloud mit Fail2Ban abzusichern, habe aber keine Ahnung wie der Regex aussehen muss. WP gibt bei nicht erfolgreichen Versuchen eine 200er Antwort, bei erfolgreichen eine 304er.
Durch googlen habe ich diese Definition gefunden:
failregex = ^.*POST.*wp-login\.php.* 200
Wenn ich jetzt die Prüfung mache findet er leider nichts.
fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/wordpress.local
Die Log Einträge sehen so aus:
x.x.x.x – – [07/Oct/2018:19:49:42 +0000] „POST /wordpress/wp-admin/admin-ajax.php HTTP/2.0“ 200 47 „-“ „Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0“ „-“
127.0.0.1 – – [07/Oct/2018:19:49:42 +0000] „POST /wordpress/wp-admin/admin-ajax.php HTTP/1.0“ 200 47 „-“ „Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0“ „x.x.x.x“
Grüße und danke für die super Tutorials.
Ok ich vermute mal dass es wp-admin anstatt wp-login heißen muss. Ist es ansonsten ok oder sollte der Regex generell anders aussehen wegen Performance oder ähnlichem?
Grüße
Hallo Jansen,
wenn der Regex bei dir klappt, dann wird es passen. Ich denke mal nicht, dass hier sonderlich großes Optimierungs-Potential besteht.
Allerdings verwende ich fail2ban nicht zur Absicherung von WP. Viel einfacher erreichst du das mit einem WP-Plugin (z.B. Limit Login Attempts).
Gruß,
Jan
Hallo Jan,
deine super Beschreibung und deine Hilfe für die Nextcloud hat mich nun auf diese Seite gebracht. Es ist wirklich unglaublich was du hier für Aufwand in „uns“ steckst. Echt TOP!
Leider funktioniert WordPress bei mir nicht tadellos.
Ich bekomme eine Blank-Page:
https://smuehl.de/wordpress/
Der Nginx Error Log spuckt folgendes aus:
2018/10/21 20:33:19 [error] 28824#28824: *48 FastCGI sent in stderr: „PHP message: PHP Parse error: syntax error, unexpected ‚_‘ (T_STRING) in /var/www/wordpress/wp-config.php on line 67“ while reading response header from upstream, client: 127.0.0.1, server: 127.0.0.1, request: „GET /wordpress/index.php HTTP/1.0“, upstream: „fastcgi://unix:/run/php/php7.2-fpm.sock:“, host: „smuehl.de“
Die Zeile 67 hat aber nur ein Kommentar inne (/**#@-*/)
Kannst du mir einen Ansatz geben?
Viele Grüße Sascha
Hi Sascha,
was passiert denn, wenn du die Zeile, die eh auskommentiert ist, einfach aus der Datei entfernst? Kann aber auch sein, dass die angegebene Zeile nicht korrekt ist und der Fehler eine Zeile davor oder danach auftritt. Hast du hier irgendwas per Copy&Paste übernommen? Hier könnte es sein, dass irgendwelche falschen Zeichen mit reingerutscht sind.
Gruß,
Jan
Hey Jan, ich habe jetzt die wp_config.php nocheinmal neu erstellt.
Jetzt spuckt mir der Browser: „Error establishing a database connection“
https://smuehl.de/wordpress/
Nun habe ich folgendes gemacht:
1. ich habe die wordpress_db mit show databases; gesucht
2. diese habe ich dann mit tables öffnen wollen.
3. siehe da, es steht kein User drin
4. nun habe ich versucht selbst deinen Vorschlag einzutragen:
create user wordpress_db_user@localhost identified by ‚MeInPasSw0rT‘; zu erstellen, da ich dachte es gab mal wieder einen Tippfehler (die wp-config.php habe ich dann wieder auf deine Vorgabe angepasst)
–>selber Fehler
5. dann habe ich mit select * from mysql.user; mal alle user anzeigen lassen. Mein User und „dein User“ stehen in der Auflistung
Warum sehe ich die User nicht in den Tables, wenn ich die wordpress_db* öffne? Was ich nicht verstehe, dass ich bei der Erstellung er wordpress_db, bei der User-Erstellung und den Setzen der Privilegien ein: Query OK, 0 rows affected (0.002 sec) bekomme. Das sollte doch so nicht sein oder?
Ngnix-Error.log:
2018/10/22 20:31:24 [error] 20492#20492: ocsp.int-x3.letsencrypt.org could not be resolved (110: Operation timed out) while requesting certificate status, responder: ocsp.int-x3.letsencrypt.org, certificate: „/etc/letsencrypt/live/smuehl.de/fullchain.pem“
2018/10/22 20:43:18 [error] 20492#20492: *11 access forbidden by rule, client: 94.177.249.166, server: smuehl.de, request: „GET https://smuehl.de/ HTTP/1.1″, host: „smuehl.de“
Ps. frag mich bitte nicht, wo aufeinmal der letsencrypt-Fehler herkommt…
Danke ersteinmal.
Hi Sascha,
also ich denke mal nicht, dass ein Fehler in der DB vorliegt, sondern dass lediglich (von PHP-Seite) keine Verbindung aufgebaut werden kann. Die DB-User stehen übrigens auch nicht in den Tabellen der Anwendung, sondern werden so abgefragt:
select * from mysql.user;An deiner Stelle würde ich alles löschen (WP-Dateien, Datenbank für WP und WP-DB-User) und nochmal von vorn mit einem sauberen Stand beginnen. Das ist meistens schneller, als wenn man sich lange auf Fehlersuche begibt, zumal du WP ja wohl noch nicht produktiv verwendet hast (es gehen also keine Daten verloren).
Gruß,
Jan
Hallo Jan,
Wordpress läuft nun ohne Probleme. Vielen Dank.
Jetzt bin ich dabei FHEM (baue mir auch gerade eine eigene Homeautomation Webpage) zu erstellen.
Nun setzt mir glaube die Basic Authentication einen Strich durch die Rechung.
Ich habe die .htwpasswd erstellt (zeigt auch meinen Nutzernamen und das cryptisierte psw an).
Nach dem Aufruf der FHEM-Seite meines Servers auf den Browsern Mozilla und Firefox wurde ich auch nach der Verifizierung gefragt. Nach Eingebe des Nutzernamens und des Passworts, welche definitiv richtig eingegeben wurden, verwehrt mir nginx (403 Forbidden) den Zugriff.
An was kann das liegen?
Danke schonmal für deine Hilfe(n!)
Hi Sascha,
sind denn im nginx error.log Einträge der folgender Art vorhanden, nachdem du dich versucht hast einzuloggen:
[error] 1451#1451: *7592 user „admin“ was not found in „/etc/nginx/.htpasswd“, client: xxx.xxx.xxx.xxx, server: meinedomain.de, request: „GET / HTTP/1.1“
Falls nicht, dann ist die htpasswd-Datei nicht richtig erzeugt, bzw. nicht richtig eingebunden. Den Befehl zum Erzeugen der htpasswd-Datei würde ich auf jeden Fall manuell auf der Kommandozeile eingeben (nicht Copy&Paste).
Den Webserver hast du auch nach dem Einbinden der Datei in den entsprechenden vHost neu gestartet?
Gruß,
Jan
Der Fehler lag in der Ordnerstruktur („„/etc/nginx/htpasswd/.htpasswd statt /etc/nginx/.htpasswd). Garnicht schlecht so ein Error.log :)
Nun bekomme ich „nur noch“ einen 502 Bad Gateway:
2018/11/04 22:08:35 [error] 27413#27413: *4 connect() failed (111: Connection refused) while connecting to upstream, client: 127.0.0.1, server: 127.0.0.1, request: „GET /fhem HTTP/1.0“, upstream: „http://127.0.0.1:8083/fhem“, host: „127.0.0.1:86“
Das Netz erzählt was von der Anpassung der listen IPs in /etc/php/7.2/fpm/pool.d/www.conf
Muss ich da noch Ports freigeben?
An php handler bzw. der Version 7.2 statt 7.0 kann es ja nicht liegen oder?
Mein handler sieht wie folgt aus:
upstream php-handler {
server unix:/run/php/php7.2-fpm.sock;
}
Ich hoffe es liegt nicht wieder an irgend einem copy&paste-Fehler. Dann wirds langsam peinlich…
Moin.
Ich hoffe ich habe eine ähnliche Frage wie meine in den Kommentaren nicht überlesen.
Ich habe Nextcloud nach der Anleitung installiert und wollte nun Invoice Ninja installieren. Die Installation hat geklappt, leider bekomme ich den Fehler 403 Forbidden wenn ich die Seite aufrufen möchte.
Ich habe schon vieles Probiert und vermute das es daran liegt das die index.php von Invoice Ninja unter dem Ordner /public liegt. Ich werde nur leider nicht aus der Fehlermeldung von /var/log/nginx/error.log schlau. Kann mir da jemand helfen?
2018/12/09 22:01:13 [error] 321#321: unexpected response for ocsp.int-x3.letsencrypt.org
2018/12/09 22:01:13 [error] 321#321: unexpected response for ocsp.int-x3.letsencrypt.org
2018/12/09 22:01:13 [error] 321#321: *5 directory index of „/var/www/invoiceninja/“ is forbidden, client: 127.0.0.1, server: 127.0.0.1, request: „GET /invoiceninja/ HTTP/1.0“, host: „kubaner.spdns.de“
2018/12/09 22:01:13 [error] 319#319: *7 directory index of „/var/www/invoiceninja/“ is forbidden, client: 127.0.0.1, server: 127.0.0.1, request: „GET /invoiceninja/ HTTP/1.0“, host: „kubaner.spdns.de“
2018/12/09 22:01:14 [error] 321#321: *9 directory index of „/var/www/invoiceninja/“ is forbidden, client: 127.0.0.1, server: 127.0.0.1, request: „GET /invoiceninja/ HTTP/1.0“, host: „kubaner.spdns.de“
2018/12/09 22:01:14 [error] 319#319: *11 directory index of „/var/www/invoiceninja/“ is forbidden, client: 127.0.0.1, server: 127.0.0.1, request: „GET /invoiceninja/ HTTP/1.0“, host: „kubaner.spdns.de“
2018/12/09 22:01:17 [error] 319#319: *13 directory index of „/var/www/invoiceninja/“ is forbidden, client: 127.0.0.1, server: 127.0.0.1, request: „GET /invoiceninja/ HTTP/1.0“, host: „kubaner.spdns.de“
2018/12/09 22:01:18 [error] 319#319: *15 directory index of „/var/www/invoiceninja/“ is forbidden, client: 127.0.0.1, server: 127.0.0.1, request: „GET /invoiceninja/ HTTP/1.0“, host: „kubaner.spdns.de“
2018/12/09 22:01:18 [error] 321#321: *17 directory index of „/var/www/invoiceninja/“ is forbidden, client: 127.0.0.1, server: 127.0.0.1, request: „GET /invoiceninja/ HTTP/1.0“, host: „kubaner.spdns.de“
Grüße
Clemens
Hi Clemens,
sorry für die verspätete Antwort.
Der Fehler sagt eigentlich nur, dass der nicht auf das Verzeichnis /var/www/invoiceninja/ zugreifen darf. Ich vermute mal, dass du im vHost für invoiceninja noch eine „root“ Anweisung brauchst, die auf das entsprechende Verzeichnis zeigt.
Leider kenne ich invoiceninja nicht, so dass ich hier keine detaillierte Anleitung liefern kann.
Gruß,
Jan
Hallo Jan,
nun muss ich mich für die späte Antwort entschuldigen…
Danke für deine Rückmeldung. Du hattest natürlich recht. Ich denke ich habe es soweit geändert das es gehen könnte.
Vielleicht kannst du mir bei folgendem Fehler auch noch einmal helfen:
Der Nginx Error Log spuckt folgendes aus:
2019/01/16 06:34:01 [error] 3970#3970: unexpected response for ocsp.int-x3.letsencrypt.org
2019/01/16 06:34:01 [error] 3970#3970: unexpected response for ocsp.int-x3.letsencrypt.org
2019/01/16 06:34:20 [error] 10316#10316: unexpected response for ocsp.int-x3.letsencrypt.org
2019/01/16 06:34:20 [error] 10316#10316: unexpected response for ocsp.int-x3.letsencrypt.org
Oder wenn ich den „root“ etwas abändere lade ich eine leere Datei runter. Gebe ich den gesamten Pfad mit php.info ein, lädt er die runter.
Hast du vielleicht noch eine Idee?
Grüße
Clemens
Hi Clemens,
kommt bei den Let’s Encrypt Fehlermeldungen noch etwas hinterher (Network unreachable oder so)? Falls nicht, würde ich den Fehler erst einmal ignorieren. Wenn die Zertifikate richtig eingebunden und auch erneuert werden, dann ist alles OK.
Wenn er Dateien herunterladen möchte, dann werden diese nicht richtig an den PHP-Handler weiter gegeben. Den PHP-Handler selbst hast du im Gateway-Host platziert?
Gruß,
Jan
Hallo Jan,
Wie immer erstklassiges Tutorial!
Aktuell scheitere ich daran, OpenProject zum laufen zu bekommen.
Leider finden sich nicht wirklich viele Infos in Verbindung mit Nginx.
Was ich herausfinden konnte ist, dass das Aufrufverzeichnis hier liegt:
root /opt/openproject/public
Der Port zum Aufruf:
6000
Und folgende Nginx Konfigurationsempfehlung:
# assume :
# – openproject installed in /opt/openproject
# – local port: 6000
# – external port: 6020
server {
listen 6020;
server_name SERVER_DOMAIN_NAME;
root /opt/openproject/public;
location ~ / {
proxy_pass_request_headers on;
proxy_set_header X-Forwarded-Host $host:$server_port;
proxy_set_header X-Forwarded-Server $host:$server_port;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://127.0.0.1:6000;
}
}
Leider fehlt es mir an tieferem Verständnis, wie ich dies in Gateway und vHost verarbeiten kann.
Aktuell sieht der Gateway folgend aus:
location ~ ^/openproject {
proxy_pass_request_headers on;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://127.0.0.1:85;
}
^
Und der dazugehörige vHost:
server {
server_name 127.0.0.1;
listen 127.0.0.1:85;
root /opt/openproject/public/;
location /openproject/ {
rewrite ^/openproject/(.*) /$1 break;
proxy_pass http://127.0.0.1:6000;
proxy_read_timeout 90;
}
}
Das führt leider aber nur zu einer weißen Seite ohne Fehlermeldung.
Hast du hier eine Idee?
VG
Phillip
Das error.log von Nginx liefert noch folgendes:
*515 open() „/etc/nginx/html/assets/openproject-9f70455eb1…
*515 open() „/etc/nginx/html/assets/frontend/vendor.05bf9d47…
*515 open() „/etc/nginx/html/assets/frontend/polyfills.1f4c3…
*515 open() „/etc/nginx/html/assets/frontend/runtime.56cacfcc…
*515 open() „/etc/nginx/html/assets/frontend/main.9c8c8be8…
*515 open() „/etc/nginx/html/assets/frontend/styles.22aa6b3…
*515 open() „/etc/nginx/html/assets/application-9129f999389…
*515 open() „/etc/nginx/html/assets/locales/de-3383a7a7…
*515 open() „/etc/nginx/html/assets/vendor/ckeditor/ckeditor-aee783204…
*515 open() „/etc/nginx/html/assets/vendor/enjoyhint-3016066…
VG
Phillip
Hi Phillip,
OpenProject sagt mir nun erst einmal nichts. Ich habe mich mal kurz eingelesen und es sieht so aus, als ob es einen Installer gibt, der dann die komplette Webanwendung hochzieht. Daher vermute ich mal, dass der doppelte proxy_pass hier zu viel ist. Ein proxy_pass auf die Anwendung selbst sollte ausreichen. Ich würde daher den vHost für OpenProject entfernen (oder deaktivieren) und dann im gateway-Host folgendes ausprobieren:
location ~ ^/openproject(/.*|$) {proxy_pass_request_headers on;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://127.0.0.1:6000;
}
Wenn das dann nicht geht, nochmal das nginx error.log checken bzw. in der Developer Console im Browser (F12) nachsehen, was mit einem Request passiert, d.h. wo hier Redirects stattfinden.
Wenn alles nichts hilft, evtl. mal im Forum von Openproject nachfragen.
Gruß,
Jan
Hallo Jan,
Danke schonmal für deine Antwort.
Leider funktioniert das nicht. Webbrowser sagt
„Page not found
The page you were trying to access doesn’t exist or has been removed.
Back“
Nginx Log sagt:
„open() „/etc/nginx/html/favicon.ico“ failed (2: No such file or directory)“
Ich schließe daraus, dass er im falschen Verzeichnis sucht, oder?
VG
Phillip
Hi Phillip,
der eine Fehler im nginx error.log ist soweit normal und sollte nicht die Ursache dafür sein, dass es nicht funktioniert. Dann wären da nämlich andere Fehler zu sehen.
Ich würde nun mal die Konstruktion mit dem Gateway-Host aus der Gleichung nehmen, da hat man schon mal eine potentielle Fehlerquelle weniger.
Wenn ich das richtig verstanden habe, wird OpenProject auf dem System so installiert, dass es über den Port 6000 erreichbar ist. Stelle nun zunächst sicher, dass keine Firewall den Port 6000 blockiert. Falls du also ufw einsetzt, deaktiviere die Firewall mal temporär mit ufw disable.
Anschließend rufst du nun über den Browser OpenProject direkt auf, d.h. ohne über den Gateway-Host zu gehen. Dazu nimmst du die IP des Rechners nebst port 6000: Beispielsweise also http://192.168.178.100:6000
Was passiert nun? Wenn es dann auch noch nicht funktionieren sollte, liegt der Fehler nicht in der nginx-Konfiguration, sondern bei OpenProject selbst. Hier müsste man mal schauen, ob es für OpenProject Log-Dateien gibt und was hier zu sehen ist.
Gruß,
Jan
Hi Jan,
Danke für deine Hinweise.
Tatsächlich komme ich auch mit abgeschalteter Firewall und Direktaufruf nicht auf die Seite.
Das Log von Openproject gibt hier folgendes aus:
„ActionController::RoutingError (no route matches [GET] /openproject/login):“
Spricht also für ein Openproject Thema.
Ich werde dort mal weiter auf die Suche gehen.
Trotzdem besten Dank!
VG
Phillip
Hallo Jan,
Das ganze hat mir noch keine Ruhe gelassen.
Habe die Installation nochmal durchlaufen lassen und versuche direkt über IP und Port nun auf Openproject zuzugreifen.
Dabei erhalte ich folgende Browsermeldung:
„ERR_UNSAFE_PORT“ (aus Chrome)
Wie hab ich „unsafe Port“ zu verstehen?
Nginx schreibt nichts ins error.log
VG
Phillip
Hi Phillip,
Chrome blockiert wohl verschiedene Ports. Das kann man wohl auch ausschalten, siehe hier. Alternativ könntest du das mal mit Firefox ausprobieren.
Gruß,
Jan
Hallo Jan,
Leider noch keinen Erfolg.
Für mein Verständnis:
In der meinedomain.conf wird das root-Verzeichnis auf /var/www gesetzt (dein Nextcloud auf 18.04 Tutorial). OpenProject liegt aber in /opt/openproject/public. Muss ich in der .conf dann nicht ein anderes root-Verzeichnis definieren? und wenn ja, wie wird ein weiteres root-Verzeichnis für nur diese Webanwendung definiert?
VG
Phillip
Hi Phillip,
das hängt ganz von der Funktionsweise der Webanwendung ab. Braucht diese eine eigene Webserver-Config? Wenn ja, dann wirst du höchstwahrscheinlich einen eigenen vHost dafür brauchen. Läuft die Anwendung aber „stand alone“, reicht ein einfacher proxy_pass im Gateway-Host.
Vielleicht hilft dir ja dieses Tutorial: Hier geht es zwar um phpMyAdmin, aber dies ist eine Anwendung, die stand alone läuft. Hier reicht ein einfacher proxy_pass im Gateway-Host und das Setzen des root-Directories mittels
root /usr/share/;Wenn OpenProject ebenso stand alone läuft (d.h. sich direkt über die IP im Browser aufrufen lässt, ohne dass der Webserver beteiligt ist), dann wird die Einrichtung hier sehr ähnlich ablaufen.
Funktioniert nun mittlerweile der direkte Aufruf von OpenProject über http://ip:port?
Gruß,
Jan
Hi Jan,
Über IP:Port bekomme ich ein:
„Failed to load resource: the server responded with a status of 404 (Not found)“
Laut Forum muss ein Webserver vorhanden sein:
„Alternatively you can just skip the apache2 configuration in the installer, and add a vhost by yourself, which just proxies requests to localhost:6000.“
Auf Github gibt es eine Config für Nginx:
https://gist.github.com/seLain/375d16ccd4542e3727e97a7478187d3a
Hier wird root gesetzt, ich weiß nur nicht, wie ich dies in den bestehenden Gatewayhost integriere, ohne dass es zu Komplikationen mit Nextcloud etc kommt.
VG
Phillip
Hi Phillip,
die Config aus dem Link legt einen server-Block an. Um dies im Gateway-Host zu integrieren, brauchst du allerdings einen location-Block.
Dies sollte dann in etwa so aussehen:
location ^~/openproject {root /opt/openproject/public;
proxy_pass_request_headers on;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://127.0.0.1:6000;
}
Das ‚root‘ wird einfach innerhalb des location-Blocks definiert.
Gruß,
Jan
Hi Jan,
Mit der Config erhalte ich in Nginx ein:
*8 upstream prematurely closed connection while reading response header from upstream, client: XXX, server: XXX, request: „GET /openproject/login HTTP/1.1“, upstream: „http://127.0.0.1:6000/openproject/login“, host:“XXX.de“
Hast du eine Idee, was mir das sagen soll?
VG
Phillip
Hi Phillip,
das bedeutet eigentlich nur, dass der Upstream (das ist in deinem Fall OpenProject) die Verbindung beendet hat. Warum, das geht aus der Meldung nicht hervor. Hier bräuchte man Logs, o.ä. von OpenProject.
Gruß,
Jan
Hi Jan,
OpenProject Log gibt folgendes:
Fatal:
ActionController::RoutingError (No route matches [GET] „/openproject/login“):
Ich glaube, ich bin für die Installation von OP einfach zu unerfahren (aka „doof“).
Werde das Projekt wohl notgedrungen erstmal on hold legen.
Danke dir trotzdem für deine Mühen!
VG
Phillip
Hi Phillip,
das Problem sehe ich hier eher auf der Seite von OpenProject. In dem Thema stecke ich leider nicht drin, um hier Tipps zu liefern.
Ich kann das Thema aber mal auf meine ToDo-Liste packen. Ich komme nur momentan leider zeitlich nicht dazu, viel am Blog zu arbeiten. Kann also eine Weile dauern.
Gruß,
Jan