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.
Inhalt
- 05.05.2019:
- Im vHost für WordPress wird nun folgender Wert gesetzt: fastcgi_param REMOTE_ADDR $http_x_real_ip;
Damit soll sicher gestellt werden, dass WordPress stets die richtige IP des Clients erhält.
- Im vHost für WordPress wird nun folgender Wert gesetzt: fastcgi_param REMOTE_ADDR $http_x_real_ip;
- 24.04.2019:
- Anpassung an der try_files Anweisung im vHost für WordPress.
- 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.
nano /etc/nginx/conf.d/owncloud9tutorial.goip.de_wordpress.conf
Hier wird nun die (minimale) Konfiguration des Webservers für WordPress hinzugefügt:
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$is_args$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 REMOTE_ADDR $http_x_real_ip;
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:
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):
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:
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:
mysql -u root -p
Nach der Eingabe des Root-Passworts kann die Datenbank mit folgenden Befehlen angelegt werden:
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.
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:
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):
// ** 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:
/** * 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:
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:
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.
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:
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:
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:
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:
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:
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):
apt-get install apache2-utils
Als nächstes wird eine .htpasswd-Datei generiert:
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:
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):
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:
nano /etc/nginx/conf.d/owncloud.goip.de.conf
Hier fügen wir am Ende die Anweisungen für FHEM hinzu:
#
# 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:
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:
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:
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:
mysql -u root -p
Nach der Anmeldung als Root-User kann die Datenbank angelegt werden:
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:
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:
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:
nano /etc/nginx/conf.d/nextcloudtutorial.goip.de_moodle.conf
Hier muss wieder der Port entsprechend der Weiterleitung im Gateway-Host angegeben werden:
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:
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:
nano /var/www/moodle/config.php
Folgende Zeilen müssen hier hinzugefügt bzw. modifiziert werden:
$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:
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:
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:
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:
#!/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:
nano /etc/nginx/conf.d/owncloud9tutorial.goip.de.conf
Hier wird wie gewohnt eine Weiterleitung an einen nicht belegten Port des Webservers hinzugefügt:
# netdata configuration
location ^~ /netdata {
proxy_pass http://127.0.0.1:84;
}
Die eigentliche Arbeit übernimmt ein spezieller vHost für Netdata:
nano /etc/nginx/conf.d/owncloud.goip.de_netdata.conf
Dabei sieht der Inhalt der Datei wie folgt aus:
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:
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):
./netdata-uninstaller.sh ./netdata-updater.sh
Um ein Update vollautomatisch per Cronjob erledigen zu lassen, ist dieser wie folgt anzulegen:
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:
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:
nano /etc/lighttpd/lighttpd.conf
Hier wird der Port des Webservers geändert:
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:
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.
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:
nano /etc/nginx/conf.d/meinedomain.de.conf
Hier fügt man ganz unten (aber vor der letzten schließenden Klammer) folgende Anweisungen hinzu:
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:
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):
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:
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):
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):
location ^~ /shellinabox {
proxy_pass http://127.0.0.1:83;
proxy_read_timeout 90;
}
Der vHost speziell für shellinabox sieht dabei folgendermaßen aus:
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
Nextcloud auf Ubuntu Server 20.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
Hi,
danke die für die tolle Anleitung, bei mir funktioniert alles einwandfrei!
Kleine Frage, ich würde gerne Home Assistant (Supervised als Docker installiert, läuft lokal momentan) als zweite Webanwendung in die bestehende Ngnix-Konfiguration reinmontieren, könntest du vielleicht kurzen Hinweis geben wie dies zu schaffen ist? Wäre sehr dankbar.
Gruß
Vladimir
Hi Vladimir,
mit Home Assistant habe ich nun noch keine Erfahrungen, ich habe dazu aber das hier gefunden. Dort ist zunächst mal der vHost für nginx interessant, mit dem dann der proxy_pass zu Home Assistant gemacht wird.
Hilft das bereits weiter?
Gruß,
Jan
Danke für die schnelle Antwort. Ich werde das mal versuchen.
MfG
Hi Jan,
da ich ja alles Neu installiert habe und nun auch verschiedene anders Sachen auch nun ausprobieren wollte wie Apticron und nun auch Netdata musst eich feststellen das Netdata. laut der hier veröffentlichen Anleitung bei mir nicht funktioniert. Ob das nun an dem neuen Ubuntu liegt, mag ich nicht sagen, es hagelt schon bei der Installation lauter FM und am Schluss wird auch Netdata erstellt.
Ich hatte nun eine Anleitung gefunden Quelle: https://gamingsym.in/gr/so-installieren-sie-netdata-unter-ubuntu-22-04-lts/ aber hier habe ich das Problem das beim Fail2ban kein Netzcloud mit aufgelistet wird nur nginx. Hast Du das eventuell im Einsatz ?
Gruß
Thomas
Hi Thomas,
die zahlreichen Anleitungen zu den Anwendungen sind z.T. von anderen Lesern beigesteuert. Kann sein, dass sich hier in der Zwischenzeit einiges geändert hat, der Artikel ist ja schon etwas älter.
Netdata habe ich bisher nur einmal kurz gesehen, daher kann ich hier leider keine genauen Angaben machen. Wenn ich es richtig verstehe, klappert Netdata alles im System ab und erstellt dafür ein „Live-Monitoring“. Kann an dieser Stelle natürlich sein, dass Netdata out-of-the-box nur die Sachen von fail2ban erkennt, die standardmäßig mit fail2ban mitkommen. Allerdings habe ich zu dem Thema nur das hier gefunden.
Entstehen denn beim Nextcloud-Ban über fail2ban Einträge in der Datei
/var/log/fail2ban.log?Gruß,
Jan
Hallo Jan,
zuerst möchte ich dir hier für deine großartige Arbeit danken, damit auch solche wie ich, die werder mit Linux und noch weniger mit der Konsole vertraut sind was hinbekommen.
Nun zu meinem kleinen Problem. Ich habe nach deiner Anleitung mit Ubuntu Server 20.04 LTS Nextcloud aufgesetzt und das läuft auch. Nun wollte ich noch WordPress installieren, was auch soweit geklappt hat. Beim Aufruf jedoch bekomme ich den Fehler 403 forbidden. Im Nginx Error log steht „directory index of /var/www/ is forbidden“. Ich hänge mal den Vhost hier mit an, weil ich glaube das da ein Fehler drin ist.
# Upstream to abstract backend connection(s) for php
upstream php {
server unix:/tmp/php-cgi.socket;
server 127.0.0.1:9000;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name fotografie-frettenheim.de;
root /var/www/wordpress;
# SSL configuration
# RSA certificates
ssl_certificate /etc/letsencrypt/fotografie-frettenheim.de/rsa/fullchain.pe>
ssl_certificate_key /etc/letsencrypt/fotografie-frettenheim.de/rsa/key.pem;
# ECC certificates
ssl_certificate /etc/letsencrypt/fotografie-frettenheim.de/ecc/fullchain.pe>
ssl_certificate_key /etc/letsencrypt/fotografie-frettenheim.de/ecc/key.pem;
# This should be ca.pem (certificate with the additional intermediate certi>
# See here: https://certbot.eff.org/docs/using.html
# ECC
ssl_trusted_certificate /etc/letsencrypt/fotografie-frettenheim.de/ecc/ca.p>
# Include SSL configuration
include /etc/nginx/snippets/ssl.conf;
# Include headers
include /etc/nginx/snippets/headers.conf;
location ^~ /wordpress {
index index.php;
location /wordpress {
try_files $uri $uri/ /wordpress/index.php$is_args$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_nam>
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_pass php-handler;
fastcgi_connect_timeout 60;
fastcgi_index index.php;
fastcgi_param REMOTE_ADDR $http_x_real_ip;
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;
}
}
}
Du kannst es Dir ja mal anschauen. Für die Domains habe ich bei Strato eine gekauft und für Nextcloud ein Cname gesetzt, der funktioniert.
Vielen Dank im vorraus
Udo
Hallo Udo,
du schreibst ja, dass du für die NC-Domain schon einen CNAME-Eintrag gesetzt hast. Lt. deinem vHost sieht es aber nun so aus, als wenn du WordPress in einem Unterverzeichnis des Webservers laufen lassen willst. Wenn du schon CNAME-Einträge nutzt, dann tu doch das gleiche für WordPress. Das macht die Sache dann einfacher und auch aus Nutzer-Sicht unkomplizierter. Dann laufen nämlich NC und WordPress in getrennten (Sub-)Domains.
Bei dem konkreten Fehler will er aber den Directory-Inhalt listen, was „forbidden“ ist. Hier sieht es so aus, als ob er nicht erkennt, dass da eine PHP-Datei über den PHP-Handler zu verarbeiten wäre. Dies sieht eher so aus, als ob der PHP-Handler hier nicht richtig konfiguriert ist.
Eine Grundlage für einen vHost für WordPress findest du übrigens hier.
Hier wäre vielleicht noch ein hilfreicher Artikel für dein Vorhaben.
Gruß,
Jan
Hallo, ich habe die Webseite mit dem Vhost zum laufen bekommen, allerdings im Vhost von Nextcloud und als zweiten wie ich es eigentlich machen wollte. Mir ist dannach ein ziemlich dummer Fehler passiert. Beim aufrufen der Webseite war die Formatierung weg. Also dachte ich mir, machst du einen Reset. Gemacht mit dem Plugin WP-reset. Das Ergebnis ist nun,das nichts mehr funktioniert. Beim Aufruf der Cloud schreibt er „apps directory not found! Please put the Nextcloud apps folder in the Nextcloud folder. You can also configure the location in the config.php file.“ Webseite geht natürlich auch nicht mehr. Ordner Nextcloud-data ist leer.Ich befürchte das die Datenbank ebenfalls leer ist und die User weg. Meine Datenhabe ich noch, weil eine zweite HDD mit eingebaut hatte und jede Nacht die Daten mit rsync abgeglichen habe. Meinst du das man das wieder hinbekommt oder muss ich jetzt wieder bei null anfangen?
Mit etwas geknickten Grüßen
Udo
Hi Udo,
das klingt erst einmal, als hättest du sowohl die Website-Dateien (also die PHP files) von NC, als auch von WP in das gleiche Verzeichnis gepackt. WP-reset hat dann irgendwas gemacht – im Sinne der NC dann wohl „ohne Rücksicht auf Verluste“ – dadurch wurden vermutlich Daten der NC gelöscht.
Dass er nun die DB und den DB-User der NC gelöscht hat, kann ich mir irgendwie nicht vorstellen, das müsstest du nochmal prüfen.
Hast du noch irgendwo die config.php der NC als Backup? Denn hier stehen wichtige Infos drin (Salt, Instance-ID, etc.). Wenn diese noch da ist (und die DB), dann kannst du dir die NC nochmal manuell installieren und die config.php wiederherstellen (anstelle des Setups von NC). Danach sollte die NC wieder funktionieren.
Wenn nicht: Um wie viele User handelt es sich hier? Wenn es nur ein paar User, die man bei einer Neuinstallation der NC schnell wieder anlegen könnte? Hier könntest du dann die Daten aus dem Backup wieder einspielen und einen kompletten File-Scan anwerfen (OCC). Hier gehen dann allerdings alle Daten verloren, die in der DB gespeichert sind (Kalender, Kontakte, etc.).
Generell – du lernst es jetzt wohl auf die harte Tour (nicht böse gemeint!): Bevor du solche Änderungen an einem Webserver vornimmst, sollte vorher ein Backup angefertigt werden. Für NC gibt es z.B. diese Skripte hier, die mehr oder weniger automatisiert ein Backup anfertigen und einen Restore durchführen können. Ein Backup der NC ist eben nicht nur das Datenverzeichnis, sondern alles (Datei- und Datenverzeichnis nebst DB).
Gruß,
Jan
Nachtrag. Die Daten sind auch im NC Verzeichnis noch vorhanden, ebenso die Werte in der Config.php. Die ist noch komplett da, sieht jedenfalls so aus.
Was sich geändert hat ist, das er jetzt ein Internal Server error ausgibt beim aufrufen.
Grüße
Udo
Hi Udo,
bei einem Internal Server Error steht im NC Log meist detailliert, was beim Aufruf schief gegangen ist. Also einfach mal hier schauen.
Wenn noch alles da ist (Daten, config.php und die DB), dann kann man das denke ich recht schnell wieder hin bekommen.
Warum er aber den NC-DB-User gelöscht hat, ist mir ein Rätsel. Hast du die WP-DB irgendwie in der NC-DB angegeben? Für beide Web-Anwendungen brauchst du je eine DB und einen DB-User, der auch nur auf seine eigene DB Zugriff hat.
Gruß,
Jan
Hallo Jan ich gestern noch ein en zweiten Kommentar geschrieben, weil der erste nicht zu sehen war. Kann ignoriert werden.
Zum Problem. Die Datenbank ist noch da,alle User auch bis auf nextcloud_db_user. Der fehlt. Ob ich die config.php noch als Backup habe müsste ich nachschauen.
Ich halte es fast für das beste den ganzen Server neu aufzusetzen. Der läuft rein privat, also nix mit Geschäft oder Firma. Die Daten sind zu 95% nur von mir. Durch die zweite HDD ist ja alles noch da, außer NC selbst. Ich versuche trotzdem nochmal es wieder hinzubekommen.
Grüße
Udo
Hallo Jan, es gibt Neuigkeiten. Nextcloud läuft wieder. Es war in der Config.php eine Klammer falsch gesetzt. Die habe ich gelöscht, dann ging es aber nur einmal. Dann kam wieder Internal Server Error. Über die Notiz-App Joplin hatte ich auch einen Fehler, wonach die App-Verzeichnis in Nextcloud bzw. in der Config fehlen würde. Das Verzeichnis war aber vorhanden. Ich habe dann in der Config der Verweiß auf das Verzeichnis hinzugefügt. Jetzt scheint es wieder zu laufen. Der Datenbank-User von Nextcloud war übrigens nicht gelöscht. Beim einrichten von der Datenbank hatte den User Admin genannt und nicht Nextcloud_db_user wie in der Anleitung. Hatte ich wohl vergessen.
An meinem ursprünglichen Problem mit Webseite hat sich aber leider nix geändert. Wenn ich den Vhost von WordPress in den von der Cloud mit hineinschreibe geht die Seite. Will ich es als extra Vhost, geht es nicht. Ich will die Seite aufrufen als http://www.meineseite.de, wobei ich das www als cname gemacht habe. Bei cloud.meineseite.de/wordpress (alles in einem Vhost) geht es. Als Fehler steht im Nginx Log: /var/www/wordpress is forbidden. Ändern der Berechtigung auf www-data hat nix gebracht.
Der zweite Vhost nur für WordPress sieht so aus:
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name http://www.fotografie-frettenheim.de;
root /var/www/wordpress;
# SSL configuration
# RSA certificates
ssl_certificate /etc/letsencrypt/www.fotografie-frettenheim.de/rsa/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/www.fotografie-frettenheim.de/rsa/key.pem;
# ECC certificates
ssl_certificate /etc/letsencrypt/www.fotografie-frettenheim.de/ecc/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/www.fotografie-frettenheim.de/ecc/key.pem;
# This should be ca.pem (certificate with the additional intermediate certificate)
# See here: https://certbot.eff.org/docs/using.html
# ECC
ssl_trusted_certificate /etc/letsencrypt/www.fotografie-frettenheim.de/ecc/ca.pem;
# Include SSL configuration
include /etc/nginx/snippets/ssl.conf;
# Include headers
include /etc/nginx/snippets/headers.conf;
location ^~ /wordpress {
root /var/www/;
index index.php index.html index.htm;
location /wordpress {
try_files $uri $uri/ /wordpress/index.php$is_args$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
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_pass php-handler;
fastcgi_connect_timeout 60;
fastcgi_index index.php;
fastcgi_param REMOTE_ADDR $http_x_real_ip;
fastcgi_param PHP_VALUE „open_basedir=/var/www/wordpress:/tmp/
upload_max_filesize = 1G
post_max_size = 1G
max_execution_time = 3600“;
}
}
}
Hast du eine Idee an was das liegen könnte?
Grüße Udo
Hi Udo,
wenn der Kommentar nicht gleich erscheint, dann wurde dieser vom Spam-Filter blockiert (passiert häufig, wenn Code oder Config-Inhalte gepostet werden). Dann muss ich diesen manuell frei geben, was mal eine Zeit dauern kann.
Ich denke, dass bei deinem vHost noch der server_name falsch ist (muss hier ohne http://) angegeben werden.
Der server_name ist wirklich nur die Domain, ohne Protokoll.
Gruß,
Jan
Hi Jan, die Cloud und Webseite laufen jetzt, die Webseite jetzt auch mit zweitem Vhost unter anderer URL.
Jetzt ist noch so das Nextcloud streikt wegen angeblich fehlendem Apps directorie. Das habe ich mit folgendem Code in die config.php eingetragen:
‚apps_paths‘ => [
[
‚path’=> ‚/var/www/nextcloud/apps‘,
‚url‘ => ‚/apps‘,
‚writable‘ => true,
],
],
Eine zeitlang läuft sie auch, und stoppt dann plötzlich ohne ersichtlichen Grund. Nach einem kompletten Neustart des Servers läuft sie paar Minuten und stoppt dann wieder.Im Nginx error log stand dann folgendes:
2/07/17 00:59:36 [error] 772#772: *269 FastCGI sent in stderr: „PHP message: PHP Warning: file_exists(): open_basedir restriction in effect. File(/var/www/nextcloud/config/config.php) is not within the allowed path(s): (/var/www/wordpress:/tmp/) in /var/www/nextcloud/lib/private/Config.php on line 204PHP message: PHP Warning: realpath(): open_basedir restriction in effect. File(/var/www/nextcloud/index.php) is not within the allowed path(s): (/var/www/wordpress:/tmp/) in /var/www/nextcloud/lib/base.php on line 151PHP message: PHP Warning: file_exists(): open_basedir restriction in effect. File(/var/www/nextcloud/apps) is not within the allowed path(s): (/var/www/wordpress:/tmp/) in /var/www/nextcloud/lib/base.php on line 212“ while reading response header from upstream, client: 185.13.31.31, server: myncloud.fotografie-frettenheim.de, request: „GET /nextcloud/status.php HTTP/1.1“, upstream: „fastcgi://unix:/run/php/php/php7.4-fpm.sock:“, host: „myncloud.fotografie-frettenheim.de“
Also ich kann damit überhaupt nix anfangen.
Hast du eine Idee wo der Fehler liegt?
Grüße
Udo
Hi Udo,
es sieht so aus, als wenn er manchmal (?) den falschen vHost nimmt, denn die „open_basedir“ Fehlermeldung sieht so aus, als wenn er für NC den vHost für WP nehmen würde (hier ist ja das entsprechende „open_basedir“ angegeben, welches er im nginx-Log bemängelt).
Kontrollier also nochmals den server_name in beiden vHosts und achte darauf, dass die Requests mit dem richtigen Hostnamen kommen. Am Hostname/Base-Path kann man ja auch in der config.php rumschrauben, das sollte in deinem Fall aber nicht notwendig sein (sondern wäre hier eher kontraproduktiv), daher bitte keine solche Änderungen an der config.php vornehmen.
Gruß,
Jan
Hallo Jan,
ich bin so langsam am verzweifeln. Ich bekomme es einfach nicht hin damit die Cloud fehlerfrei läuft. Ich habe sie jetzt sogar komplett neu aufgesetzt mit Ubuntu 22.04 und Nextcloud 24 und habe den fast identischen Fehler. . Läuft auch, zeitweise. Ich habe wordpress nachinstalliert und habe jetzt den Fehler, das er angeblich das Apps Directorie nicht findet. Das ist aber vorhanden und auch in der Config eingetragen.
Ich habe mittlerweile bemerkt, sobald ich meine Webseite aufrufe schmiert die Cloud ab. PHP und Nginx laufen aber weiter. Also die Webseite kann ich immer aufrufen, selbst wenn ich von Nextcloud die obige Fehlermeldung bekomme. Die Fehlermeldung im Log ist die gleiche wie oben. Ich habe die Config im Moment in einem Vhost, also WordPress nur über location. Ich hatte mit der Erstellung des Zertifikats Mist gebaut und muss noch einen Tag warten. Wenn ich nur PHP neustarte geht die Cloud wieder, aber eben nur ohne WordPress. Der Fehler liegt also wahrscheinlich bei der PHP Konfiguration. Nur wo weiß ich eben nicht. Hast du noch eine Idee an was das liegen könnte?
Grüße
Udo
Hi Udo,
ich denke immer noch, dass sich die Website-Dateien oder die Einträge in den vHosts irgendwie „überschneiden“ und du daher Wechselwirkungen hast.
Wenn die Fehlermeldung hier noch die gleiche ist, könnte es beispielsweise sein, dass er (mit einem Request!) Sachen anfordert, die dann – wie auch immer – aus mehreren vHosts stammen. Das ist aber nur so eine Vermutung.
Warum es nach einem Neustart von PHP aber wieder geht, ist mir ein Rätsel.
Welchen server_name haben nun beide vHosts (NC und WP)?
Du schreibst: „also WordPress nur über location“. Ist damit ein Unterverzeichnis gemeint (also z.B. meinedomain.de/wordpress)? Wenn ja, und wenn WP dann „unter“ Nextcloud betrieben wird, dann wird es schnell kompliziert. Hier also lieber zwei getrennte (Sub-)Domains nehmen.
Gruß,
Jan
Hallo Jan,
Wordpress läuft im Moment in einem Unterverzeichnis von Nextcloud. Die Cloud läuft im Moment über server_name meinedomain.de, WordPress mit location /wordpress als meinedomain.de/wordpress in einem V-Host. Will ich aber ändern sobald ich die Zertifikate für WordPress generiert habe. Dannach soll die Cloud über cloud.meinedomain.de erreichbar sein, WordPress entwerder Direkt über die Hauptdomain oder eine zweite Sub-domain mit getrennten V-Hosts. Wenn es Dir was nützt kann ich den V-Host hier mal einstellen so wie er im Moment aussieht. Könnte es vielleicht daran liegen das beide Programme unter dem selben Verzeichnis installiert sind, in meinem Fall unter /etc/www?
Grüße
Udo
Hallo Jan, ich habe im vorherigen Kommentar einen Fehler gemacht. Nextcloud und WordPress sind in /var/www installiert.
Hi Udo,
daran wird es liegen: Entweder, du betreibst beides in einem Unterverzeichnis (z.B. meinedomain.de/nextcloud und meinedomain.de/wordpress), oder beides auf unterschiedlichen (Sub-)Domains.
Wordpress läuft ja nun „unter“ Nextcloud, was vermutlich die Ursache für das komisch Verhalten der Seiten ist. Da bin ich mir nicht sicher, ob man das überhaupt sauber hinbekommen würde.
Seitens des Dateisystems müssen beide Anwendungen auch strikt getrennt werden (z.B. /var/www/nextcloud und /var/www/wordpress).
Wenn NC später dann auf einer eigenen Sub-Domain laufen wird, werden sich die Probleme vermutlich in Luft auflösen.
Gruß,
Jan
Hallo Jan,
ich habe jetzt die zweiten Zertifikate erstellt und die Konfiguration so geändert, das die Cloud jetzt unter cloud.domain.de zu erreichen ist. Das ganze läuft auch stabil. Der Vhost für WordPress ist im Moment noch deaktiviert.
Eine grundsätzliche Frage zu den Vhost’s.
Ist es besser zwei getrennte Vhost zu machen, also z.B. cloud.conf und wordpress.conf oder kann man alles in einen vhost schreiben, getrennt durch server_name?
Die Installation ist getrennt in /var/www/nextcloud und /var/www/wordpress (war von Anfang an so).
Grüße
Udo
Hi Udo,
ich persönlich trenne einzelne vHosts immer durch unterschiedliche Dateien. Das ist aber Geschmackssache, man kann auch alles in eine Datei packen.
Durch die Trennung in unterschiedlichen Dateien hast du allerdings den Vorteil, dass du einen kompletten vHosts ganz schnell deaktivieren kannst, ohne die Inhalte der vHost-Dateien anzufassen.
Gruß,
Jan
Hallo Jan,
ich bin leider noch nicht wirklich weitergekommen. Ich habe wieder das Problem, das ich den Fehler 403 bekomme, unabhängig davon wie der Vhost für WordPress konfiguriert ist.
Nextcloud dagegen läuft weiter, im Moment zumindest.
Da ich jetzt nicht das Genie im Vhost schreiben bin (ist genaugenommen meine erstes mal mit WordPress) habe jetzt testweise den vhost genommen, den du in dem Artikel für Nextcloud mit Ubuntu 22.04 stehen hast. 1 zu 1 übernommen, server_name und Zertifikat geändert auf meine Domain. Und oh Wunder, ich komme auf die Webseite.
Da wären aber noch zwei Sachen. In dem Vhost sind ja Werte drin, die für WordPress nicht zu gebrauchen sind. Wie könnte man den ändern damit das funktioniert?
Und das zweite: WP-Admin geht nicht (liegt wahrscheinlich am Vhost), ich kann die Webseite zwar aufrufen, aber nicht konfigurieren.
Ich hoffe du kannst mir helfen den Vhost so zu schreiben, damit das ganze endlich vernünftig läuft.
Grüße
Udo
Hi Udo,
für WP ist der NC-vHost zu umfangreich, ja.
Hier kannst du aber einfach diesen vHost hier nehmen, der reicht eigentlich immer aus. Zumindest habe ich WP damit schon oft aufgesetzt und hier gab es nie Probleme.
Gruß,
Jan
Hallo Jan,
ich habs hinbekommen das das ganze endlich läuft. Ich hatte zwar nochmal den Fehler 403, das lag aber an einem falschen PHP Eintrag in der conf. PHP stand drin, PHP-Handler musste rein. Seitdem läuft es. Nochmal danke für deine Hilfe und Geduld.
Aber eine Frage hätte ich noch bezüglich Gzip. Ist es besser das mit in die conf zu schreiben und kann man die Werte der Nextcloud.conf übernehmen oder sollte man es als Plugin bei WordPress machen?
Grüße
Udo
Hi Udo,
super, danke für die Rückmeldung.
Ich würde solche Optimierungen wie gzip immer möglichst „auf niedrigster Ebene“ (in diesem Fall: nginx vHost) machen und möglichst wenig Plugins in WordPress installieren.
Gruß,
Jan
Hallo Jan, ich habe noch ein kleines Problem zu lösen. Ich will eine 301 Umleitung einrichten, damit eine www Eingabe im Browser zu meiner Seite ohne www geleitet wird. Bei Strato funktioniert das nicht. Gibt es eine einfache Möglichkeit das umzusetzen ohne das noch einen vhost oder Zertifikate braucht?
Gruß
Udo
Hi Udo,
hier würde ich vorschlagen, dass du beide Domains (die „normale“ und die www-Sub-Domain) in ein Zertifikat generierst (einfach mittels eines weiteren „-d“ Parameters kannst du eine weitere (Sub-)Domain angeben). Hier brauchst du dann nur einen vHost, der eben auf beide Domains „hört“ (server_name). Anschließend kannst du in diesem vHost die Weiterleitung konfigurieren.
Gruß,
Jan
Hallo Jan,
würdest du deine WordPressanleitung aus 2016 auch auf deine aktuelle Nextcloud/Ubuntu 22.04 anwenden und wenn nicht, was würdest du wie anpassen?
Gruß
Frank
Hi Frank,
ja, ich würde heutzutage ein Detail sicher anders lösen: Ich bin mittlerweile kein großer Fan mehr von der Trennung unterschiedlicher Webanwendungen „per Unterverzeichnis“ (z.B. meinedomain.de/nextcloud, meinedomain.de/wordpress, etc.).
Diese Trennung würde ich heute per (Sub-)Domain vornehmen, also in diesem Beispiel: nextcloud.meinedomain.de, wordpress.meinedomain.de, usw.
Dies macht dann die Konfiguration der virtuellen Hosts für die Webanwendungen meistens seht viel einfacher und man kann diese dann meisten aus den offiziellen Dokumentationen der Anwendungen übernehmen.
Du brauchst dafür dann nur mehrere (Sub-)Domains, die auf das gleiche System verweisen, z.B. per A-/AAAA-Record oder per CNAME (wenn es sich um eine DynDNS-Domain handelt). Die „Trennung“ finden dann ganz einfach über den
server_namein nginx statt.Gruß,
Jan