Zweite Web-Anwendung neben ownCloud/Nextcloud einrichten (am Beispiel WordPress)

16. November 2016JanHome-Server, 250

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-Anwendungen

Andere 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: 05.05.2019)

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.
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.

Hinweise für andere Web-Anwendungen

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-Anwendungen

Wie 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.

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:

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-Anwendungen

Die 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

Links

FHEM, Home-Server, Let's Encrypt, Linux, MariaDB, Moodle, Netdata, Nextcloud, nginx, PHP, Pi-hole, Reverse Proxy, Roundcube, sehllinabox, shellinabox, SSL, Ubuntu, WordPress

Windows Server Advanced Power Management: Version 1.5.3 Windows Server Advanced Power Management: Version 1.5.4

Kommentare: 250

Karl-Heinz Trieglaff sagt:
7. März 2019 um 14:53 Uhr
Hi Jan,
bin doch etwas zu euphorisch gewesen. Wie oben schon berichtet lies sich WordPress neben Nextcloud einwandfrei installieren. Doch am Tag danach konnte ich über den Browser keinen Zugriff mehr über https://kht-ohz.de/wordpress/wp-admin nehmen. (Seiten-Ladefehler / Zeitüberschreitung) Nextcloud Einwahl dagegen ohne Probleme. Beim 2. Aufruf von ../wp-admin wechselte unerwartet die Adresse nach: https://kht-ohz.de:83/wordpress/wp-admin/ . Nach einer erneuten Einwahl ohne den Port 83 hatte ich wieder Zugriff. Das Problem tritt also jedesmal auf wenn mein Rechner neu gebootet wird und mich über den Browser neuen Zugriff auf WordPress nehmen will. Habe auch schon nur WordPress allein ohne Nextcloud installiert. Selbige Problematik.
Antworten
- Jan sagt:
  7. März 2019 um 20:15 Uhr
  Hi Karl-Heinz,
  ich beobachte, dass in deinem Blog alle Links funktionieren, bis auf „wp-admin“, da dies ein „Verzeichnis im Unterverzeichnis“ darstellt.
  Probier doch mal bitte folgendes im Gateway-Host (den kompletten Block für WP durch dies hier ersetzen):
  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$1; proxy_redirect off; }
  Wenn das auch nicht gehen sollte, dann müssen wir mal weiter sehen.
  Gruß,
  Jan
  Antworten
Karl-Heinz Trieglaff sagt:
7. März 2019 um 21:04 Uhr
Sorry, leider nein.
https://kht-ohz.de/wordpress/wp-admin
404 Not Found
nginx
Antworten
- Jan sagt:
  7. März 2019 um 21:12 Uhr
  Hi,
  OK, dann werde ich mir das am Wochenende mal genauer ansehen. Ich melde mich dann wieder.
  Gruß,
  Jan
  Antworten
  - Jan sagt:
    8. März 2019 um 7:37 Uhr
    Hi,
    wenn der erste Versuch nicht geklappt hat, dann bitte die Änderungen erst einmal rückgängig machen.
    Ich habe hier die Vermutung, dass es nicht unbedingt an der nginx Config liegen muss.
    Füge mal folgende Zeile in die wp-config.php ein:
    $_SERVER['REQUEST_URI'] = str_replace("/wp-admin/", "/wordpress/wp-admin/", $_SERVER['REQUEST_URI']);
    Gruß,
    Jan
    Antworten
    - Karl-Heinz sagt:
      8. März 2019 um 10:10 Uhr
      Moin, moin,
      1. Aufruf https://kht-ohz.de/wordpress/wp-admin
      automatischer Wechsel der Adresse nach
      https://kht-ohz.de/wordpress/wordpress/………
      habe dann Zugriff auf WordPress als wp-admin
      2. Rechner neu gebootet:
      https://kht-ohz.de/wordpress/wp-admin
      automatischer Wechsel der Adresse
      https://kht-ohz.de:83/wordpress/wp-admin/
      Seiten Ladefehler
      Netzwerk Zeitüberschreitung
      Antworten
      - Jan sagt:
        8. März 2019 um 16:10 Uhr
        Hallo Karl-Heinz,
        also ich habe das nun mal auf meiner Test-Maschine ausprobiert und bin genau so vorgegangen wie im Artikel beschrieben. Bei mir funktioniert das einwandfrei: …/wp-admin leitet mich weiter auf die Login-Page bzw. aufs Dashboard (wenn ich schon eingeloggt bin).
        Daher vermute ich mal, dass sich bei dir irgendwo ein kleiner Fehler eingeschlichen hat. Hier reicht u.U. schon ein „/“ bei einem location-Block im vHost, etc.
        Beginne doch einfach mal von neuem und gehe wirklich Schritt für Schritt genau wie im Tutorial vor. Das ist meistens schneller, als in einer Fehlersituation lange auf die Suche zu gehen.
        Gruß,
        Jan
      - Karl-Heinz sagt:
        11. März 2019 um 10:42 Uhr
        Moin, moin Jan,
        habe separat einen Freund gebeten besagte Installation nach den Vorgaben zu machen mit selbigen Ergebnis wie bei mir. Habe allerdings ermittelt, das eine Anmeldung mit https://kht-ohz.de/wordpress/wp-login.php anstelle von https://kht-ohz.de/wordpress/wp-admin einwandfrei arbeitet. Sprechen irgendwelche Gründe dagegen immer diesen Weg der Anmeldung zu wählen?
      - Jan sagt:
        11. März 2019 um 19:31 Uhr
        Hallo Karl-Heinz,
        zunächst einmal: Es spricht überhaupt nichts dagegen, wenn du erst über wp-login.php gehst und erst danach auf das Dashboard zugreifst. Der Login ist ja Voraussetzung für den Zugriff auf das Dashboard.
        Trotzdem kann ich es nicht nachvollziehen. In einem Zustand ohne Login kam bei mir beim Zugriff auf /wp-admin immer direkt die Weiterleitung auf die Login-Page (wp-login.php).
        Was passiert, wenn du bei der wp-admin-URL noch einen Slash dranhängst, also https://kht-ohz.de/wordpress/wp-admin/
        Gruß,
        Jan
Karl-Heinz sagt:
11. März 2019 um 22:47 Uhr
Tja, Jan, was soll ich sagen? Habe damit mehrere meiner Rechner getestet. Nach Eingabe von https://kht-ohz.de/wordpress/wp-admin/ wechselte diese nach https://kht-ohz.de/wordpress/wp-login.php?redirect_to=https%3A%2F%2Fkht-ohz.de%2Fwordpress%2Fwp-admin%2F&reauth=1 und das bekannte WordPress Anmeldefenster tat sich auf.
Ich bedanke mich außerordentlich für deine ausdauernde und mühevolle Hilfestellung für mich als Linux Dummie.
Nochmals recht herzlichen Dank
Karl-Heinz
Antworten
- Jan sagt:
  12. März 2019 um 18:24 Uhr
  Hallo Karl-Heinz,
  OK, das grundsätzliche Problem wäre ja nun gelöst.
  Schau dir aber nochmal die location-Blöcke in den vHosts an, wie zu WP gehören: Vielleicht fehlt hier noch ein Slash am Ende des Pfades des location-Blocks.
  Gruß,
  Jan
  Antworten
  - Karl-Heinz sagt:
    17. März 2019 um 19:44 Uhr
    Moin, moin Jan,
    werde mich morgen gleich drum kümmern. Habe schon danach im Netz recherchiert und wenig gefunden und alle Variationen ergaben nicht das gewünschte Ergebnis. Habe allerdings eine weitergehende Frage in Bezug auf WordPress. Besteht die Möglichkeit auch WordPress Multisite unter Verwendung mit Subdomains in dein System einzubinden?
    Wünsche dir noch einen restlichen schönen Sonntag.
    Gruß
    Karl-Heinz
    Antworten
    - Jan sagt:
      18. März 2019 um 7:49 Uhr
      Hallo Karl-Heinz,
      mit Sub-Domains ist das natürlich auch möglich. In diesem Fall brauchst du aber mehrere Sub-Domains als DynDNS-Domain. Das ist nur per CNAME-Eintrag bei den Domains möglich, da du in den meisten Routern nur eine einzige DynDNS-Domain hinterlegen kannst.
      Des weiteren kannst du dir dann das Konstrukt mit dem Gateway-Host sparen, sondern hier kommt dann ein vHost pro Sub-Domain zum Einsatz, die dann ohne Bezug zueinander laufen.
      Gruß,
      Jan
      Antworten
      - Karl-Heinz sagt:
        18. März 2019 um 12:25 Uhr
        Moin Jan,
        danke für die Auskunft. Ich glaube ich traue mich da mal ran. Bei mir ist das immer so, egal in welchem Bereich, wenn’s dann perfekt läuft verliere ich schnell das Interesse daran und etwas Neues muss her.
        Gruß
        Karl-Heinz
Bernd sagt:
17. April 2019 um 15:16 Uhr
Hallo Jan,
ich hätte da eine Frage zu Netdata. Kann ich für den Aufruf der Webseite eine Passwortabfrage mit einbauen? Da mein Server bei einem Hostingprovider steht kann ich nicht über die Localhostadresse gehen. Es soll aber auch niemand der u.U. die URL kennt sofort auf die Serverstatusseite gelangen können.
Danke vorab.
Gruß Bernd
Antworten
- Jan sagt:
  18. April 2019 um 14:18 Uhr
  Hi Bernd,
  ja, das geht über htpasswd. Wie du hier vorgehen musst, ist z.B. in diesem Artikel beschrieben.
  Gruß,
  Jan
  Antworten
  - Bernd sagt:
    18. April 2019 um 14:57 Uhr
    Hallo Jan,
    vielen Dank und schöne Ostern.
    Gruß Bernd
    Antworten
Timo sagt:
3. Mai 2019 um 23:42 Uhr
Hi Jan,
ich möchte ein Unterverzeichnis anlegen, dass auf eine andere Maschine verweist.
ich habe meine nginx Gateway Host conf wie folgt erweitert:
location ^~ /test/ {
proxy_pass http://192.168.1.56:7807;
proxy_redirect off;
}
danach nginx service neugestartet.
Leider kann ich meinedomain.de/test nicht aufrufen.
Kannst du mir weiterhelfen?
Antworten
- Jan sagt:
  4. Mai 2019 um 7:26 Uhr
  Hi Timo,
  wenn mehrere Maschinen beteiligt sind, dann wird die Fehlersuche leider etwas aufwändiger.
  Zu klären wäre hier:
  - Was läuft denn auf der entfernten Maschine? Ein Webserver? Eine andere Anwendung ohne Webserver?
  - Kommt der Request auf der entfernten Maschine überhaupt an? Hier erst einmal die Logs der ersten Maschine (mit nginx) checken. Wenn hier Fehler auftreten, dann auf Maschine 1 weiter suchen. Ansonsten auf Maschine 2 ebenfalls die Logs checken.
  Gruß,
  Jan
  Antworten
Marin sagt:
7. Mai 2019 um 0:56 Uhr
Hallo Jan,
könntest du vielleicht auch auf die Besonderheiten bei der Installation von phpbb3 eingehen?
Ich habe phpbb3 nach deiner Anleitung installiert und bekomme beim Zugriff auf die URL /phpbb3 einen Redirect auf :83/install/app.php.
Ich habe keine geeignete Konfiguration für den Gateway-Host gefunden, aber in den anderen Beispielkonfigurationen wird viel mit rewrites etc. gearbeitet, was das Ganze evtl zerschießt.
Was mich sehr wundert, ist, dass mein Firefox eben auf den Server auf Port 83 weitergeleitet wird, was ja gar nicht gehen kann bzw. passieren sollte. Der Server sollte das ja intern weiterleiten.
Kannst du mir da weiterhelfen?
Antworten
- Jan sagt:
  7. Mai 2019 um 9:01 Uhr
  Hi Marin,
  mit phpbb habe ich mich noch nicht beschäftigt. Wenn ich mal Zeit finde, kann ich mir die Sache ja mal ansehen. Könnte aber eine Weile dauern.
  Gruß,
  Jan
  Antworten
Jürgen sagt:
8. Mai 2019 um 17:11 Uhr
Mit Hilfe der verschiedenen Anleitung habe ich nextcloud, wordpress und phpmyadmin funktionsfähig installiert. Vielen Dank für die ausgesprochen hilfreichen Anleitungen. Ein Problem bleibt über: Bisher habe ich meinen wordpressblog direkt über die Hauptdomain (ohne xxx/wordpress) erreicht, und das schon seit längerer Zeit, so dass dieser blog doch häufiger gelesen wird und auch auf meinen Visitenkarten so eingetragen ist. Das Sahnehäubchen wäre jetzt, über die Angabe „meinedomain.de“ ,ohne angehängten Ordner, immer direkt auf WordPress weiter zu leiten und so meinen blog direkt aufzurufen. Hilfreiche Angaben dazu würden offene Türen bei mir einrennen!
Antworten
- Jan sagt:
  8. Mai 2019 um 17:32 Uhr
  Hi Jürgen,
  wenn du WP direkt über meinedomain.de erreichen willst, ist das im Grunde genommen sogar einfacher.
  Voraussetzung ist allerdings, dass du eine zweite Domain hast, die per CNAME auf deine Haupt-DynDNS-Domain verweist. Ich habe hier gerade einen Artikel dazu in der Pipeline, aber das kann noch ein wenig dauern. Auch kann ich hier keine genaue Anleitung geben, da das Vorgehen vom Domain-Provider abhängig ist.
  Wenn das mal erledigt ist, dann:
  - Weiterleitung für WP im Gateway-Host entfernen.
  - server_name im WP-vHost an den neuen Domain-Namen anpassen.
  - WP_HOME und WP_SITEURL in der wp-config.php auch an die neue Domain anpassen.
  Das sollte es dann eigentlich schon gewesen sein…
  Gruß,
  Jan
  Antworten
  - Jürgen Waczkat sagt:
    9. Mai 2019 um 17:15 Uhr
    Hallo Jan,
    vielen Dank für die prompte Bedienung ;-)) ! Ich habe in der Tat eine zweite (Sub-)Domain, die ich für diverse Spielereien zum ausprobieren nutze. Mit meinem Paket bei Strato kann ich bis zu zehn Subdomains einrichten und diese ziemlich frei – cname, a-record usw. – konfigurieren. An dieser Stelle muss ich jetzt ehrlich gestehen, diese Lösung ist mir so nicht eingefallen aber ich werde versuchen hier weiter zu kommen, und da ist nämlich mein anderes Handycap: Ich bin zwar ein leidenschaftlicher User aber ein lausiger Programmierer. Insofern sehe ich dem von dir angekündigten Beitrag voll aufgeregter Spannung entgegen.
    Gruß
    Jürgen
    Antworten
    - Jan sagt:
      9. Mai 2019 um 19:30 Uhr
      Hi Jürgen,
      wenn du den CNAME-Eintrag schon setzen kannst, dann mach das einfach mal. Dann kommst du auch mit der zweiten Domain bei dir am Webserver raus, wenn es dafür einen vHost gibt, der auf diese Domain hört (server_name).
      Wenn du HTTPS brauchst, musst du ebenfalls die Zertifikate neu ausstellen und die neue Domain dann ebenfalls mit „-d neuedomain.de“ an acme.sh übergeben (so dass dann beide Domains mit einem Befehl abgedeckt sind). Dann wird ein Zertifikat erstellt, welches dann auf beide Domains anwendbar ist.
      Gruß,
      Jan
      Antworten
Guido Giger sagt:
16. Mai 2019 um 8:18 Uhr
Hallo Jan
Ich habe bereits die Installation von deinem hervorragendem Artikel „https://decatec.de/home-server/nextcloud-auf-ubuntu-server-18-04-lts-mit-nginx-mariadb-php-lets-encrypt-redis-und-fail2ban/“ erfolgreich hinbekommen.
Nun habe ich hier versucht anstatt WordPress noch DokuWiki zu installieren.
Leider klappt dass nicht wirklich.
Die Seite: https://giger.selfip.com/dokuwiki/ wird zwar angezeigt, aber nicht richtig. Auch kann ich das install.php file nicht starten.
Eventuell ein hilfreichen Tip?
Gruss Guido
Antworten
- Jan sagt:
  16. Mai 2019 um 9:58 Uhr
  Hallo Guido,
  ich komme ohne Login-Daten zwar nicht in das DokuWiki, aber ich sehe die Seite und die wird meiner Meinung nach korrekt angezeigt.
  Ansonsten kann ich ohne konkrete Fehler- und/oder Log-Meldungen nicht viel zu dem Thema sagen. Am besten checkst du mal die Logs von nginx und DokuWiki (falls es da Logs gibt).
  Gruß,
  Jan
  Antworten
Bastian sagt:
19. Juni 2019 um 20:10 Uhr
Moin, könntest du bitte noch die funktion eines ftp-server hinzufügen.
Also so das der ftp-user der sich verbindet im „www-verzeichnis“\webseiten landet.
Antworten
- Jan sagt:
  21. Juni 2019 um 7:02 Uhr
  Hi Bastian,
  ein FTP-Server passt allerdings nicht ganz zu der Thematik. In diesem Artikel geht es darum, eine zweite Webanwendung, die auf Port 80/443 läuft, neben Nextcloud zu installieren.
  Bei einem FTP-Server ist gar kein Webserver im Spiel und der Port ist auch ein anderer.
  Bei Interesse könnte ich das Thema mal auf die Wunschliste setzen, aber das wäre dann ein komplett eigenständiger Artikel.
  Gruß,
  Jan
  Antworten
Christoph sagt:
14. Juli 2019 um 21:07 Uhr
Hallo,
ich habe bisher mehrere Anwendungen (nextcloud, fhem, phpmyadmin, letsencrypt) nach diesem Tut erfolgreich ans Laufen bekommen.
Jetzt möchte ich meinen Zoneminder auch noch hier mit unterbringen, leider schaffe ich es gerade mal soweit, daß der nginx sich wieder ohne starten läßt, jedoch bekomme ich die ZM-Oberfläche nicht angezeigt, sondern allenfalls ein „No input file specified.“
Ich habe die Anpassungen im Prinzip aus dem Zoneminder-Wiki entnommen und übertragen (https://wiki.zoneminder.com/Ubuntu_Server_18.04_64-bit_with_Zoneminder_1.32.x_the_easy_way), bekomme diesen Fehler aber nicht korrigiert …
Gruß, Christoph
Antworten
- Jan sagt:
  15. Juli 2019 um 16:35 Uhr
  Hi Christoph,
  hier wären die Einträge des nginx Logs wichtig. Vermutlich steht hier genauer drin, was fehlt oder falsch ist.
  Ansonsten kenne ich mich mit Zoneminder nicht aus, aber gibt es hier evtl. auch Log-Files?
  Gruß,
  Jan
  Antworten
Christoph sagt:
16. Juli 2019 um 21:04 Uhr
Hallo Jan,
wie bekomme ich denn eine Zoneminder-Instanz auf dem Server als virtuelle Maschine ans laufen? Ich habe mich analog zu Deiner Anleitung und dem ZM-Wiki (https://wiki.zoneminder.com/Ubuntu_Server_18.04_64-bit_with_Zoneminder_1.32.x_the_easy_way; nur der Teil zur ergänzenden zm-conf-datei), bekomme aber nur die datei index.php als Download angeboten …
Gruß, Christoph
Antworten
- Jan sagt:
  19. Juli 2019 um 13:29 Uhr
  Hi Christoph,
  wenn die PHP-Datei zum Download angeboten wird, kann vermutlich kein PHP-Handler gefunden werden. Du brauchst irgend etwas in der Form:
  upstream php-handler { server unix:/run/php/php7.2-fpm.sock; }
  Dies muss entweder im vHost für Zoneminder sein, oder besser noch im Gateway-Host, über den die Zoneminder-Requests „getunnelt“ werden.
  Gruß,
  Jan
  Antworten
  - Christoph sagt:
    3. August 2019 um 18:49 Uhr
    Hallo Jan,
    das steht drin – ich habe mich da ganz an Deine Anleitung „Zweite Web-Anwendung neben ownCloud/Nextcloud…“ gehalten, und da wurde es ja bereits thematisiert.
    Zudem laufen ein fhem, phpmyadmin, nextcloud, letsencrypt bereits erfolgreich auf dem Server ;-)
    Ich bin jetzt einige Zeit nicht dran gewesen, jetzt bekomme ich „nur“ noch eine Zeitüberschreitung …
    Die Zoneminder-Conf:
    server {
    server_name 127.0.0.1;
    listen 127.0.0.1:85;
    root /var/www/;
    location /cgi-bin {
    auth_basic off;
    alias /usr/lib/zoneminder/cgi-bin;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $request_filename;
    fastcgi_param HTTP_PROXY „“;
    fastcgi_pass unix:/var/run/fcgiwrap.socket;
    }
    location /zm/cache {
    auth_basic off;
    alias /var/cache/zoneminder/cache;
    }
    location ~ /zm/api/(css|img|ico) {
    auth_basic off;
    rewrite ^/zm/api(.+)$ /api/app/webroot/$1 break;
    try_files $uri $uri/ =404;
    }
    location /zm {
    auth_basic off;
    alias /usr/share/zoneminder/www;
    try_files $uri $uri/ /index.php?$args =404;
    location /zm/api {
    auth_basic off;
    rewrite ^/zm/api(.+)$ /zm/api/app/webroot/index.php?p=$1 last;
    }
    location ~ \.php$ {
    auth_basic off;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $request_filename;
    fastcgi_param HTTP_PROXY „“;
    fastcgi_index index.php;
    fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
    }
    }
    }
    Gruß,
    Christoph
    Antworten
    - Jan sagt:
      4. August 2019 um 15:53 Uhr
      Hi Christoph,
      hier sollten wir erst einmal heraus finden, was die Zeitüberschreitung verursacht. Leider kann ich aus dem vHost keine Infos ableiten, so dass wieder mal nur ein Blick in die Logs (nginx, Zoneminder) weiter helfen kann.
      Gruß,
      Jan
      Antworten
Christoph sagt:
4. August 2019 um 17:22 Uhr
Im Log steht „… file not found …“
Ich habe mich mal mit einer bestehenden ZM-Install auf einem BananaPi mit LAMP unter Ubuntu 18.04 beschäftigt – von ZM werden die Daten u.a. in /usr/share/zoneminder/www installiert.
Bisher habe ich mit verschiedenen Symliks nach /var/www/* versucht – aber bisher kein Erfolg…. ich suche mal weiter ;-)
Antworten
- Jan sagt:
  5. August 2019 um 17:12 Uhr
  Hi Christoph,
  im Log sagt er dir doch, welche Dateien er wo sucht und nicht finden kann, oder?
  Hier stimmt dann etwas mit den Pfad/root-Angaben nicht (im vHost).
  Das ganze müsste dann ähnlich wie im Artikel über phyMyAdmin umgesetzt werden, hier gehen die Pfadangaben auch auf /usr/share/…
  Gruß,
  Jan
  Antworten
Jürgen Fuchs sagt:
21. August 2019 um 18:49 Uhr
Hallo Jan,
nach wochenlanger Recherchen bin ich auf die Lösung eines kleinen aber nervigen Problems im Zusammenhang mit der WordPressinstallation auf dem Virtual Host gestoßen.
In WP kann man einzelne Posts mit einem Passwort absichern. Das Problem ist aber, dass WP nach Passworteingabe (egal ab korrekt oder nicht) einen White Screen ohne weitere Hinweise anzeigt. Da ich den Passwortschutz in manchen Situationen benötige, ist dieses Verhalten aus Benutzersicht mehr als unbefriedigend.
Es zeigte sich, dass die Problematik an der Referrer Policy lag, die im Virtuellen Host eingestellt ist. Dort heißt es unter
#Add headers to serve security related headers
…
add_header Referrer-Policy no-referrer always;
Durch diesen Header wird für alle unterlegten Apps verhindert, dass der Browser die anfordernde URL an die angeforderte URL mitteilt. WP benötigt diese Information allerdings, um nach der Validierung des Passworts wieder zu der anfordernden Stelle zurückkehren zu können. Gibt es diese nicht, kommt es zum gefürchteten White Screen.
Lösung:
add_header Referrer-Policy no-referrer-when-downgrade always;
Die Lösung führt nicht zu einem schlechteren Rating im SSL-Test. Diese Referrer-Policy ist auch defaultmäßig in WordPress vorgesehen.
Gibt es damit evtl. Sicherheitsprobleme unter Nextcloud? Falls ja, könnte in der Nextcloudkonfiguration ein entsprechender Header wiedereingestellt werden.
Vielen Dank und viele Grüße
Jürgen
Antworten
- Jan sagt:
  22. August 2019 um 12:52 Uhr
  Hallo Jürgen,
  OK, das ist wirklich interessant. Passwort-geschützt WP-Postings hatte ich noch nicht.
  Wenn man hier andere Header-Werte braucht, sollten diese im vHost für WP gesetzt werden. Bei NC sollte dann im NC-vHost ein anderer Wert gesetzt werden. Es muss auf jeden Fall vermieden werden, dass Header-Werte doppelt gesetzt werden, denn diese werden dann häufig ignoriert.
  Danke für das Teilen dieser Lösung, ist vielleicht auch für andere interessant.
  Gruß,
  Jan
  Antworten
- Matthias R sagt:
  19. Mai 2020 um 10:18 Uhr
  Hallo Jürgen,
  ich hatte das gleiche Problem – und hätte mal gleich hier in der Liste nach möglichen Antworten suchen sollen :-) Allerdings hat es bei mir eine andere Headereinstellung ermöglicht das Problem zu umgehen:
  add_header Referrer-Policy „strict-origin-when-cross-origin“ always;
  Soweit ich das verstehe handelt es sich hierbei um eine striktere Variante von no-referrer-when-downgrade und ist hier: : https://wiki.crashtest-security.com/enable-security-headers ganz gut beschrieben
  Antworten
Jürgen Fuchs sagt:
28. August 2019 um 19:37 Uhr
Hallo Jan,
erstmal möchte ich nochmals ein großes Lob für deinen WP-Installation aussprechen. Das funktioniert wirklich großartig zusammen mit NC auch auf meiner relativ schwachen Hardware.
Da wir in der Schule nur über geringe Bandbreite verfügen, habe ich unter https://developers.google.com/speed/pagespeed/insights/ die Performance meines WP getestet. Dabei sind mir zwei Dinge aufgefallen:
1. pagespeed stellt fest, dass gzip nicht aktiv ist. Lösung: Verlagern der gzip Einstellungen vom NC-vHost in die nginx.conf. Dadurch profitieren alle unterlegten Apps von der Datenreduktion. Tipp: Etwas mit rumspielen. Mit:
gzip_comp_level 2;
gzip_min_length 2048;
habe ich auf meinem schmalbrüstigen Server einen phantastisch Leistungsschub erreicht
2. Statische Inhalte im Browser Cache ablegen.
Dieser Punkt bringt mich schier zur Verzweiflung. Wenn ich in Chrome mit F12-Network die Header anschaue, bekomme ich immer im Request Header die Meldung
:authority: serverfox.mynetgear.com
cache-control: max-age=0
Ich habe im WP-VHost schon alles mögliche ausprobiert, aber ich bekomme das einfach nicht hin.
Könntest du mir einen Tipp geben? Es sieht für mich so aus, als ob die NC-Installation die cache-control Einstellung irgendwo erzwingt, aber ich habe kein Ahnung, wo das geschieht.
Vielen Dank für deine Unterstützung und viele Grüße aus Düsseldorf
Jürgen
Antworten
- Jan sagt:
  29. August 2019 um 12:48 Uhr
  Hallo Jürgen,
  danke für den ersten Tipp. Dies ist generell empfehlenswert, gzip zu aktivieren. Jedoch muss man hin und wieder etwas aufpassen, falls eine Webanwendung mit aktivierter Komprimierung nicht richtig funktioniert. Wenn es hier zu Problemen kommen sollte, dürfte es relativ schwierig sein, die Ursache des Problems zu finden.
  Zum zweiten Punkt: Hier sehe ich nur ein „cache-control: max-age=0“ nur im Request-Header, d.h. im Header, der vom Browser kommt. Hier ist der Webserver noch gar nicht im Spiel. Von diesem kommt dann nur der Response-Header. Ich glaube, dass man dieses „cache-control: max-age=0“ an dieser Stelle nicht ändern kann.
  Oder verstehe ich hier etwas falsch?
  Gruß,
  Jan
  Antworten
Jürgen Fuchs sagt:
29. August 2019 um 15:26 Uhr
Hallo Jan, danke für die schnelle Antwort.
Die Request-authority ist serverfox.mynetgear.com , das ist bei mir die url des Gateway Hosts. Daher habe ich die Vermutung aufgestellt, dass dort die cache-control Anweisung implementiert ist. Der Grund für die Annahme ist, dass pagespeed bei all meinen Apps (WP, NC Onlyoffice) caching für statistische Elemente empfiehlt. Die Aufrufe erfolgen doch alle über den Gateway Host, oder?
Hast du eine Idee?
Vielen Dank und viele Grüße
Jürgen
Antworten
- Jan sagt:
  30. August 2019 um 10:05 Uhr
  Hallo Jürgen,
  habe mir deine Seite mal mit Pagespeed angesehen. Das ist doch eigentlich doch schon ein recht gutes Rating.
  Es werden auch nur einige wenige Ressourcen wegen Caching „angemeckert“. Die CSS/JS Files sind wohl eher Sache von WP selbst. Ob du hier von der Seite des Webservers verbessern kannst, da bin ich mir nicht so sicher.
  Die anderen Sachen kommen von externen URLs, darauf hast du gar keinen Einfluss.
  Übrigens: Wie für bestimmte Elemente ein spezielles Caching aktiviert wird, ist im Nextcloud-Artikel beschrieben.
  Aber ich denke, dass du dir hier auch nicht den großen Performance-Boost erwarten kannst.
  Gruß,
  Jan
  Antworten
Tobias sagt:
25. November 2019 um 18:53 Uhr
Guten Abend Jan,
zunächst einmal wollte ich mich bedanken für die großartigen Anleitungen zum Thema Nextcloud, die nicht nur zielführend sondern auch sehr informativ sind.
Ich hätte jetzt nur noch die Frage welche Stellen angepasst werden müssen um WordPress direkt unter / verfügbar zu machen ?
Antworten
- Jan sagt:
  27. November 2019 um 9:11 Uhr
  Hallo Tobias,
  hier brauchst du das ganze mit dem Gateway-Host ja nicht, es ist also weitaus weniger kompliziert.
  Daher kannst du z.B. einfach diesen vHost verwenden.
  Gruß,
  Jan
  Antworten
  - Tobias sagt:
    1. Dezember 2019 um 23:17 Uhr
    Hallo,
    aber parallel zu WordPress müsste in meinem Fall weiterhin Nextcloud erreichbar sein. Müsste ich dann den Nextcloud Block in den oben verlinkten vHost kopieren ?
    Desweiteren würde ich gerne die erreichbare Adresse von /nextcloud ändern, welche Stellen müsste ich dazu anpassen ?
    Grüße Tobias
    Antworten
    - Jan sagt:
      3. Dezember 2019 um 19:14 Uhr
      Hallo Tobias,
      am einfachsten ist es in diesem Fall, zwei getrennte (Sub-)Domains einzurichten. An einem DynDNS-Anschluss kann dies einfach mittels CNAME-Einträgen realisiert werden, wie hier schon mal skizziert.
      Die Trennung WP/NC erfolgt dann über die einzelnen Domains, „gesteuert“ werden kann das über getrennte vHosts (mit jeweils eigenem server_name).
      Auf diese Weise hast du den wenigsten Aufwand, mehrere Seiten/Anwendungen parallel laufen zu lassen.
      Gruß,
      Jan
      Antworten
      - Tobias sagt:
        4. Dezember 2019 um 14:58 Uhr
        Hallo Jan,
        Können die Subdomains auch über den reverse Proxy betrieben werden ?
        Meine Idee wäre das WordPress unter meinedomain.de und nextcloud unter daten.meinedomain.de erreichbar wäre
        Grüße Tobias
      - Jan sagt:
        4. Dezember 2019 um 20:05 Uhr
        Hallo Tobias,
        ja, das kann auch über einen Reverse Proxy betrieben werden. Irgendwo brauchst du jedoch die Trennung zwischen den beiden (Sub-)Domains. Du brauchst also irgendwo zumindest zwei vHost, die über den server_name die Trennung per (Sub-)Domain vornehmen.
        Gruß,
        Jan
Hans M. sagt:
27. Januar 2020 um 20:20 Uhr
Hallo Jan,
hast du ein „Rezept“ für Tiny Tiny RSS? :)
Wär echt Klasse. Ich bekomme es einfach nicht zum Laufen…
Beste Grüße
Antworten
- Jan sagt:
  28. Januar 2020 um 16:58 Uhr
  Hallo Hans,
  sorry, eine Anleitung dazu habe ich gerade nicht auf Lager.
  Scheint aber nginx-technisch nicht all zu aufwändig zu dein (siehe hier). Das muss dann „nur noch“ mit dem Konstrukt des Gateway-Hosts „verheiratet“ werden.
  Gruß,
  Jan
  Antworten
Triglaw sagt:
6. Februar 2020 um 0:57 Uhr
Guten Morgen Jan,
erstmal danke für die Tutorials. Diese haben mein Interesse an Linux geweckt
und ich konnte Nextcloud mit WordPress auf mehreren Systemen erfolgreich installieren.
Jetzt hänge ich an einem kleinen Problem. Ich bekomme die Managementsoftware Odoo in dieser Konfiguration nicht zum laufen.
Ich habe verssucht dieses Tutorial anzupassen jedoch bekomme ich den Fehler „504 Gateway Time-out“.
Ich würde mich freuen wenn du mir den Weg weisen könntest.
Mit freundlichen Grüßen
Triglaw
Antworten
- Jan sagt:
  6. Februar 2020 um 13:12 Uhr
  Hi,
  leider kenne ich Odoo nicht, daher kann ich dir hier auch kein „Rezept“ präsentieren.
  Von der Config her sollte das aber gar nicht so wild sein (siehe z.B. hierhierhier).
  Dies muss dann „nur noch“ mit der Gateway-Konfiguration harmonieren.
  Gruß,
  Jan
  Antworten
  - Triglaw sagt:
    6. Februar 2020 um 22:39 Uhr
    Guten Abend,
    ich habe mir die Seite durch gelesen und habe Odoo auf Basis dieses Tutorials (https://linuxize.com/post/how-to-install-odoo-13-on-ubuntu-18-04/) installiert.
    Das Terminal zeigt das Odoo läuft, jedoch bekomme ich nur ein „HTTP-Fehler 500 Internal server error“ wenn ich die IP und den Port in den Server eingebe.
    Danach probierte ich diese Beispiel (https://linuxize.com/post/how-to-set-up-nginx-server-blocks-on-ubuntu-18-04/). Leider ohne Erfolg.
    Irgendwas übersehe ich.
    Was ich eigentlich fragen wollte ist: Woher weißt du was man beim Konfiguration Virtuellen Host angeben oder beim Gateway-Hosts muss?
    Wird das vom Hersteller der Software definiert?
    Mit freundlichen Grüßen
    Triglaw
    Antworten
    - Jan sagt:
      7. Februar 2020 um 7:36 Uhr
      Hi,
      der Gateway-Host ist hauptsächlich für das Routing zuständig – also welcher Request muss an welchen anderen vHost weitergeleitet werden.
      Die Anwendungs-spezifischen Anweisungen kommen dann in den vHost zur jeweiligen Anwendung.
      Der Hersteller der Software gibt das nicht fix vor, da jede Anwendung unabhängig vom verwendeten Webserver laufen muss. Du könntest hier ja auch einen Apache statt des nginx verwenden.
      Gruß,
      Jan
      Antworten
Triglaw sagt:
11. Februar 2020 um 0:04 Uhr
Guten Abend,
nachdem ich eine Demo von Odoo getestet habe, entschied ich mich dagegen. In der Community-Version fehlen einige Funktionen, die es nur im Enterprise Paket gibt.
Nun versuche ich mich an Dolibarr.
Allerdings habe ich aber die gleichen Probleme, mit der Konfiguration des vHosts, wie schon bei Odoo.
Ich fand einige Tutorials, welche die Konfiguration eines vHosts beschreiben z.B.
(https://www.rosehosting.com/blog/learn-to-install-dolibarr-on-debian-9/)
jedoch mag Nginx diese Konfiguration überhaupt nicht.
Ich habe versucht es anzupassen und das ist dabei herausgekommen:
server {
listen 127.0.0.1:84;
server_name 127.0.0.1;
root /var/www/;
location ^~ /dolibarr/htdocs {
index index.php index.html index.htm;
client_max_body_size 100M;
location ~ ^/api/(?!(index\.php))(.*) {
try_files $uri /api/index.php/$2?$query_string;
}
location ~ [^/]\.php(/|$) {
include snippets/fastcgi-php.conf;
if (!-f $document_root$fastcgi_script_name) {
return 404;
}
fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
fastcgi_param SCRIPT_FILENAME$document_root $fastcgi_script_name;
}
}
}
Für die Konfiguration des Gateway-Host habe ich dein Netdata-Tutorial als Vorlage genommen.
Wenn du mir die richtige Richtung weisen könntest (außer zur Tür) würde ich mich freuen.
Mit freundlichen Grüßen
Triglaw
Antworten
- Jan sagt:
  11. Februar 2020 um 16:58 Uhr
  Hi,
  ich denke, dass du ziemlich direkt die Anweisungen aus dem von dir verlinktem Artikel nehmen kannst. Hier müsste meines Erachtens zumindest der Pfad (aus der URL, wo Dolibarr erreichbar sein soll) noch in die location-Blöcke eingepflegt werden.
  Du schreibst, dass „nginx die Konfiguration gar nicht mag“. Was heißt das genau? Hier hilft meistens ein Block ins nginx-Log. Zumindest erhält man hier einen ersten Ansatzpunkt, was genau ihm hier nicht passt.
  Gruß,
  Jan
  Antworten
Boris sagt:
22. März 2020 um 16:30 Uhr
Hallo Jan,
erstmal vielen Dank für die Mühe die du in deine ganzen Anleitungen gesteckt hast, hat mir wirklich sehr beim Setup von LEMP und meiner Nextcloud geholfen.
Jetzt habe ich allerdings noch eine Frage bzgl. dem parallelen Betrieb einer Website (statisch, also kein WordPress oder ähnliches). Prinzipiell möchte ich einfach nur unter der TLD eine statische Seite anzeigen, denn aktuell erscheint dort nur die NGINX 403 Fehlermeldung.
https://www.xyz.de/nextcloud » soll Nextcloud öffnen
https://www.xyz.de/phpmyadmin » soll phpMyAdmin öffnen
https://www.xyz.de/ » soll eine statische Seite (index.html) anzeigen
So wie ich das verstanden habe, muss ich dafür lediglich eine weiter vhost-konfiguration anlegen – allerdings ist mir nicht klar, wie die aussehen muss?
Bei mir läuft das ganze übrigens auf einem root Server im Internet.
Vielleicht kannst du mir ja helfen, vermutlich das das ganze garnicht so kompliziert, allerdings fehlt mir mit nginx noch ein wenig die Erfahrung.
Viele Grüße
Boris
Antworten
- Jan sagt:
  22. März 2020 um 18:28 Uhr
  Hi Boris,
  so etwas wird am einfachsten direkt im Gateway-Host konfiguriert. Und zwar an der Stelle, an der bei dir vermutlich noch folgendes steht:
  location = / { # Disable access to the web root, otherwise nginx will show the default site here. deny all; }
  Das ist die Stelle, an der du die statische Seite einbinden würdest.
  Gruß,
  Jan
  Antworten
  - Boris sagt:
    22. März 2020 um 22:30 Uhr
    Hi Jan,
    danke für die schnelle Antwort. Die stelle in der Gateway-Host Konfiguration habe ich gefunden, ist genau wie von dir beschrieben.
    Dort müsste dann folgendes (anstelle von „deny all;“ rein, richtig?
    root /usr/www/html;
    index index.html;
    Habe ich so versucht, allerdings funktioniert es nicht.
    Habe auch die Doku von NGINX durchgeschaut und folgendes gefunden:
    https://nginx.org/en/docs/http/ngx_http_index_module.html#directives
    Hat aber leider auch nichts geholfen…
    Viele Grüße
    Boris
    Antworten
    - Burschi500 sagt:
      3. April 2020 um 9:51 Uhr
      Moinsen,
      ich springe mal einfach auf den Zug auf, denn ich habe ein ähnliches Problem; auch ich will über mein.server.de/ auf eine Seite/Homepage lenken. Die Installation und Einrichtung erfolgte in mein.server.de/nextcloud und läuft ohne Probleme (Danke für die Anleitung!).
      Ich habe an der angegebenen Stelle (statt deny all;) folgendes eingefügt:
      proxy_pass http://127.0.0.1:90;
      proxy_redirect off;
      und dementsprechend in mein.server.de_root.conf
      server {
      server_name 127.0.0.1;
      listen 127.0.0.1:90;
      root /var/www/html;
      location / {
      index index.html;
      }
      }
      …was mir erlaubt die index.html aufzurufen (geht also…). Allerdings werden die Bilder dieser Seite (…und Unterverzeichnisse) nicht geladen. Selbst wenn ich in der index.html statt image/image.png nur image.png schreibe und das Bild testweise in /var/www/html lege nicht gefunden werden. Der error.log zeigt:
      [error] 26800#26800: *1 open() „/etc/nginx/html/paperplane.png“ failed (2: No such file or directory)
      Wieso kommt hier ein Verweis auf /etc/nginx/… obwohl ich doch root /var/www/html gesetzt habe?
      Antworten
      - Jan sagt:
        3. April 2020 um 13:01 Uhr
        Hi,
        setz mal noch vor folgende Zeile
        proxy_pass http://127.0.0.1:90;
        ein
        root /var/www/html;
        Vielleicht hilft das ja dabei. Wenn es immer noch nicht geht, dann scheint er nicht den richtigen Pfad zu erwischen.
        Gruß,
        Jan
Sascha sagt:
26. März 2020 um 19:45 Uhr
Hallo Jan,
wie du merkst, ich bin letzter Zeit wieder etwas aktiver – jedoch anscheinend nicht schlauer.
Nun möchte ich FHEM auf meinem Rasp installieren (Ubuntu-System funktioniert Gott sei dank) und bekomme mit der Zertifikatserstellung auf Grund fehlender „permissions“ diese unter dem user letsencrypt nicht installiert (gem. Logfile acme).
Folgendes habe ich probiert:
…
usermod -a -G www-data letsencrypt
chown -R www-data:www-data /var/www/letsencrypt
chmod -R 775 /var/www/letsencrypt
chown -R www-data:www-data /etc/letsencrypt
chmod -R 775 /etc/letsencrypt
Unter dem User letsencrypt kann ich den Befehl zwar ausführen, aber die Permissions werden nicht gegeben.
Deswegen habe ich o.g. Rechte unter sudo gesetzt – läuft.
ACME.sh nimmt sudo leider nicht an („sudo: acme.sh: command not found“), ist aber erfolgreich installiert. Kannst du mir da weiterhelfen?
Viele Grüße aus der Quarantäne
Antworten
- Jan sagt:
  27. März 2020 um 6:08 Uhr
  Hi Sascha,
  die Befehle zum Ändern der Permissions für den User letsencrypt musst du als root ausführen.
  Ich kann mir vorstellen, dass das schon dein Problem lösen wird.
  Gruß,
  Jan
  Antworten
  - Sascha sagt:
    27. März 2020 um 14:09 Uhr
    Moin Jan,
    leider nein. Weder unter den Nutzer Pi, noch unter dem Nutzer root („sudo -i“) ändert sich nach Eingabe der usermod und chown-Befehle der Umstand unter dem User Letsencrypt.
    Das acme.log-file sagt:
    [Fri 27 Mar 13:01:24 GMT 2020] chown: changing ownership of ‚/var/www/letsencrypt/.well-known/acme-challenge/test.txt‘: Operation not permitted
    chown: changing ownership of ‚/var/www/letsencrypt/.well-known/acme-challenge/p2ur3O29rSIEcQTtputODbvIHAlKAGJckCCYq5KXC5w‘: Operation not permitted
    chown: changing ownership of ‚/var/www/letsencrypt/.well-known/acme-challenge‘: Operation not permitted
    chown: changing ownership of ‚/var/www/letsencrypt/.well-known‘: Operation not permitted
    [Fri 27 Mar 13:01:24 GMT 2020] chown: changing ownership of ‚/var/www/letsencrypt/.well-known/acme-challenge/test.txt‘: Operation not permitted
    chown: changing ownership of ‚/var/www/letsencrypt/.well-known/acme-challenge/p2ur3O29rSIEcQTtputODbvIHAlKAGJckCCYq5KXC5w‘: Operation not permitted
    chown: changing ownership of ‚/var/www/letsencrypt/.well-known/acme-challenge‘: Operation not permitted
    chown: changing ownership of ‚/var/www/letsencrypt/.well-known‘: Operation not permitted
    Der Befehl sudo acme.sh ist leider weiterhin nicht möglich.
    Der Ordner /var/www/letsencrypt/.well-known/acme-challenge gehört „www-data“. Eine Test.txt Erstellung hat über Letsencrypt-User funktioniert.
    Antworten
    - Jan sagt:
      27. März 2020 um 15:23 Uhr
      Hi,
      kannst du die Text.txt Datei mit dem Browser über HTTP abrufen? Dann ist seitens des Webservers alles korrekt eingerichtet.
      Die Fehler mit der permission kannst du denke ich ignorieren, da du ja mit acme.sh mit einem nicht privilegierten User unterwegs bist. Der kann u.U. gar keine Verzeichnisrechte ändern.
      Kommt beim Erzeugen der Zertifikate noch eine andere Meldung?
      Gruß,
      Jan
      Antworten
Marcel sagt:
28. März 2020 um 18:38 Uhr
Hi Jan,
erstmal vielen Dank für deine supergeilen Anleitungen!
Ich versuche gerade das Pi-hole ohne den Webserver lighttpd zum Laufen zu bringen. Also nut mit Nginx.
Ich versuche die hier beschriebene Schritte (https://docs.pi-hole.net/guides/nginx-configuration/#basic-requirements) mit dieser Anleitung zusammenzuführen, leider erfolglos. Ich habe einen location Block (location ^~ /pihole {…}) in der config pihole.conf erstellt und mit einigen Anpassungen den Standalone Teil eingefügt:
server {
server_name 127.0.0.1;
listen 127.0.0.1:84;
root /var/www/html/;
location ^~ /pihole {
#root /var/www/html;
#server_name _;
autoindex off;
index pihole/index.php index.php index.html index.htm;
location /pihole {
expires max;
try_files $uri $uri/ =404;
}
location ~ \.php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name;
fastcgi_pass unix:/run/php/php7.0-fpm.sock;
fastcgi_param FQDN true;
#auth_basic „Restricted“; # For Basic Auth
#auth_basic_user_file /etc/nginx/.htpasswd; # For Basic Auth
}
location /pihole/*.js {
index pihole/index.js;
#auth_basic „Restricted“; # For Basic Auth
#auth_basic_user_file /etc/nginx/.htpasswd; # For Basic Auth
}
location /pihole/admin {
root /var/www/html;
index index.php index.html index.htm;
#auth_basic „Restricted“; # For Basic Auth
#auth_basic_user_file /etc/nginx/.htpasswd; # For Basic Auth
}
location ~* /pihole/\.ht {
deny all;
}
}
}
Leider funktionert es nicht.
# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
Vielleicht hast du Zeit und Lust mir zu helfen? Ich würde mich selbstverständlich erkenntlich zeigen ;-)
Vorab vielen Dank!
Antworten
- Jan sagt:
  29. März 2020 um 16:50 Uhr
  Hallo Marcel,
  schau mal in diesem Artikel weiter unten (wo die „aufklappbaren Teile“ sind). Hier hat mir jemand schon eine Anleitung zukommen lassen, wie man dies mit nginx umsetzen kann. Sollte eigentlich funktionieren.
  Gruß,
  Jan
  Antworten
  - Marcel sagt:
    1. April 2020 um 13:08 Uhr
    Hi Jan,
    vielen Dank für deine schnelle Antwort.
    Allerdings möchte ich lighttpd rauswerfen und möchte mit nginx direkt auf das Verzeichnis vom Pi-hole (/var/www/html) zugreifen. Daher, versuche ich, einen weiteren virtuellen Host fürs Pi-hole anzulegen.
    Leider klappt es nicht wie gedacht.
    In der Doku (https://docs.pi-hole.net/guides/nginx-configuration/#basic-requirements) ist die standalone-config für Nginx, dennoch schaffe ich es nicht, dies in einen virtuellen Host zum Laufen zu bringen…
    Könntest du einen Vorschlag machen? Wie würde dein vHost aussehen?
    Vielen Dank und viele Grüße
    Marcel
    Antworten
    - Jan sagt:
      2. April 2020 um 14:16 Uhr
      Hi Marcel,
      leider habe ich da wenig Erfahrungen, da ich den Pi-hole immer „as-is“ laufen lasse. Welche Fehler treten denn konkret auf?
      Funktionieren die Anweisungen für Pi-hole hier in diesem Beitrag (in den aufklappbaren Bereichen) nicht mehr?
      Gruß,
      Jan
      Antworten
      - Marcel sagt:
        18. April 2020 um 15:04 Uhr
        Doch läuft alles, allerdings finde ich es unnötig nur fürs Pi-hole einen weitern Webserver laufen zu lassen. Außerdem habe ich das Problem, dass sich nach einem Update des Pi-holes der listen-Port des lighttp auf 80 zurücksetzt.
        Was muss man noch beachten – außer deine Tipps aus dem obigen Artikel – wenn man den Standalone- Teil in einen vHost übertragen möchte?
        Vielen Dank
        Gruß
        Marcel
      - Jan sagt:
        18. April 2020 um 16:15 Uhr
        Hi Marcel,
        OK, wo scheitert es denn bei der nginx-Config aus deinem o.g. Artikel? Wenn sich nginx danach nicht mehr starten lässt, dann versuch mal ein „nginx -t“.
        Gruß,
        Jan
      - Marcel sagt:
        18. April 2020 um 19:11 Uhr
        Nginx Gateway Host:
        ###
        #
        # Pihole vHost
        #
        ####
        location ^~ /pihole/{
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass http://127.0.0.1:84;
        proxy_read_timeout 90;
        port_in_redirect off;
        }
        Pihole vHost:
        siehe oben
        # nginx -t
        nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
        nginx: configuration file /etc/nginx/nginx.conf test is successful
        Wenn ich die Seite aufrufe, gibts einen Fehler 502 Bad Gateway
        Danke und Gruß
        Marcel
      - Jan sagt:
        19. April 2020 um 10:26 Uhr
        Hi Marcel,
        „Bad Gateway“ bedeutet immer, dass ein „Backend-Aufruf“ (in deinem Fall Pi-hole) nicht funktioniert hat. In diesem Fall geht die Fehlersuche im nginx error-Log weiter: Hier zeigt er dir dann genau, welcher Aufruf nicht geklappt hat.
        Tipp: Im LAN kannst du auch direkt über die lokale IP von Pi-hole gehen. Dafür muss der vHost, der in deinem Fall über Port 84 läuft, auch auf die LAN-IP (z.B. 192.168.178.xxx) lauschen. Dann hast du den Reverse Proxy schon mal aus der Gleichung rausgenommen.
        Gruß,
        Jan
Florian sagt:
14. April 2020 um 14:30 Uhr
Servus Jan,
auch von mir ein fettes Dankeschön für diese super Website und deren Anleitung.
Ich habe mir Nextcloud wie in deiner Anleitung auf meinem Raspberry-Pi installiert, und wollte nun noch Pi-Hole dazu installieren.
Nextcloud funktioniert wie es soll, nur mit Pihole habe ich probleme.
Ich bin genau der Anleitung gefolgt, und bekomme auch das Anmeldefenster.
Sobald ich mich jedoch mit meinem Nutzer und Passwort anmelde, meldet Nginx den Fehler 404.
Im Fehlerlog von Nginx finde ich folgenden Eintrag:
„/usr/share/nginx/html/admin/index.html“ is not found (2: No such file or directory)
Vielleicht kannst du mir ja weiterhelfen.
Gruß
Florian
Antworten
- Jan sagt:
  14. April 2020 um 14:59 Uhr
  Hi Florian,
  zunächst einmal: Man kann freilich Pi-hole noch neben Nextcloud (oder einer anderen Web-App) installieren. Jedoch rate ich da eher von ab. Besser ist es da, eine extra Maschine nur für Pi-hole zu nutzen.
  Zu deinem eigentlichen Problem: Was passiert, wenn du direkt über lighttpd gehst (also Port 90)? Funktioniert das dann problemlos?
  Gruß,
  Jan
  Antworten
  - Florian sagt:
    15. April 2020 um 11:50 Uhr
    Hi Jan,
    danke für die Super-Schnelle Antwort.
    Folgende Fehlermeldung im Browser wenn ich das Webinterface über die IP-Adresse und Port 90 aufrufe:
    [ERROR]: Unable to parse results from queryads.php: Unhandled error message ()
    Gruß
    Antworten
Jens Will sagt:
11. Juli 2020 um 19:50 Uhr
super Anleitung…lerne unheimlich viel dabei.
Nun habe ich auch mal eine Frage, Ich habe einen Raspberry P$ mit 4 GB RAM, habe laut deiner Anleitung „https://decatec.de/home-server/owncloud-9-auf-ubuntu-server-16-04-lts-mit-nginx-mariadb-php-7-und-lets-encrypt/“ und „https://decatec.de/home-server/zweite-web-anwendung-neben-owncloudnextcloud-einrichten-am-beispiel-wordpress/“ zum laufen gebracht Auch der PHPmyAdmin habe ich nach deiner Anleitung hinbekommen. Soweit passt alles wunderbar. Meine Domain lautet wills-welt.de mit der festen IP 37.24.4.2 nun möchte ich aber wills-welt.de als Wordpess einrichten im Hauptverzeichnis, sprich unter wills-welt.de sollte die WordPress Installation erscheinen. Dann als wills-welt.de/owncloud die owncloud Installation.
Da ich noch keine Daten für WordPress bzw. Owncloud eingerichtet habe bin ich auch für radikale Lösungen bereit!!! Was und wie muss ich da anpassen? Habe noch eine zweite Domain; jens-will.de die ich auch noch auf den Webserver einrichten möchte
Antworten
- Jan sagt:
  11. Juli 2020 um 21:37 Uhr
  Hi Jens,
  du hast vor, quasi eine Webanwendung „unter“ einer anderen Anwendung zu betreiben. Dies würde ich erstmal nicht empfehlen, da dies die Konfiguration nur unnötig kompliziert macht.
  Ich würde hier eher empfehlen, WordPress auf Deiner Haupt-Domain laufen zu lassen und für ownCloud eine eigene (Sub-)Domain zu nehmen. Das macht die Konfiguration sehr viel einfacher. Schau dir dazu einfach mal diesen Artikel hier an, könnte hilfreich sein.
  Gruß,
  Jan
  Antworten
Amelia sagt:
18. Oktober 2020 um 11:16 Uhr
Hallo,
vielen Dank für die Anleitung. Ich habe versucht WP neben der Subdomain für Nextcloud auf einer anderen Subdomain zum Laufen zu bringen und habe versucht die Umsetzung anzupassen. Beim Seitenaufruf gibt es immer einen 403 Fehler von nginx. Im error.log steht dann, directory index of „/var/www/wordpress/“ is forbidden. Liegt das an den Dateiberechtigungen? Oder ist das ein Fehler im vHost? Die Berechtigungen habe ich eigentlich so gesetzt…
Vielleicht hast Du ja noch einen Tipp
Antworten
- Jan sagt:
  18. Oktober 2020 um 12:49 Uhr
  Hallo Amelia,
  „findet“ der vHost von WordPress den Upstream für PHP? kannst du hier eine einfache HTML-Seite erstellen und diese dann im Browser aufrufen?
  Gruß,
  Jan
  Antworten
  - Amelia sagt:
    18. Oktober 2020 um 15:36 Uhr
    Hallo,
    danke für die schnelle Antwort. Der php-upstream ist ja nach der neuesten Nextcloud Anleitung im HTTP-Gateway.
    ich habe mal die Standard nginx index.html nach /var/www/wordpress kopiert, nun kommt kein Fehler mehr im Browser sondern diese nginx Test Seite wird angezeigt.
    Mein Frage jetzt auch, muss ich im HttpGateway noch etwas hinzufügen für wordpress? Bis jetzt ist dort ja nur der Traffic über Port 80 für letsencrypt geregelt, die 301 Umleitung für alles andere auf HTTPS und der PHP Upstream.
    LG
    Amelia
    Antworten
    - Jan sagt:
      19. Oktober 2020 um 6:32 Uhr
      Hallo Amelia,
      wenn der Upstream im HTTP-Gateway ist, dann sollte ihn auch der WP-vHost finden.
      Anderer Ansatz: Hast du vielleicht open_basedir in der PHP-Config konfiguriert und das WP-Verzeichnis ist hier nicht freigegeben?
      Gruß,
      Jan
      Antworten
      - Amelia sagt:
        20. Oktober 2020 um 19:57 Uhr
        Hallo,
        also ich habe keine open_basedir gesetzt, da das nach deiner neuesten Anleitung nicht mehr empfohlen wird.
        Ich weiß nicht wo der Fehler liegt, wahrscheinlich habe ich etwas eher banales übersehen und komme nicht drauf.
        LG
        Amelia
      - Jan sagt:
        20. Oktober 2020 um 21:59 Uhr
        Hi Amelia,
        dann nochmal die Konfiguration sehr genau prüfen. Auch das nginx-Fehler-Log kann dir hier evtl. weiter helfen mit der Frage, wie der Request zustande kommt, der einen Fehler verursacht.
        Gruß,
        Jan
      - Sebastian sagt:
        30. Oktober 2020 um 18:02 Uhr
        Hallo Amelia,
        ich habe dasselbe Problem. Konntest du es bereits lösen? Meine Fehlermeldung: [error] 3920#3920: *1 directory index of „/var/www/wordpress/“ is forbidden
      - Sebastian sagt:
        31. Oktober 2020 um 13:39 Uhr
        Ich habe es lösen können:
        Bei mir hat in der /wordpress.conf
        index index.php;“ gefehlt, so wie es hier beschrieben ist: https://www.nginx.com/resources/wiki/start/topics/recipes/wordpress/

« Zurück 1 2 3

Zweite Web-Anwendung neben ownCloud/Nextcloud einrichten (am Beispiel WordPress)

Ausgangssituation

Virtuellen Host für WordPress anlegen

Erweiterung des Gateway-Hosts

Installation WordPress

Anlegen der Datenbank

WordPress Dateien herunterladen und Anpassen der Verzeichnisrechte

Anpassen der wp-config.php

WordPress: Aufruf und Setup

WordPress-Setup: erster Versuch

Die Lösung

Wozu der Umweg?

Weitere Schritte in WordPress

Tipps & Tricks

Neustart Webserver/PHP-FPM

Log-Dateien kontrollieren

Developer-Konsole (Browser)

Web-Suche

Vorgehenswiese für andere Web-Applikationen

FHEM

Moodle

Netdata

Pi-hole

Roundcube

shellinabox

Weiterführende Artikel

Links

Kommentare: 250

Schreibe einen Kommentar Antworten abbrechen

IT-Services

Direktlinks

Beliebt

Schlagwörter

Kategorien

Meta

Zweite Web-Anwendung neben ownCloud/Nextcloud einrichten (am Beispiel WordPress)

Ausgangssituation

Virtuellen Host für WordPress anlegen

Erweiterung des Gateway-Hosts

Installation WordPress

Anlegen der Datenbank

WordPress Dateien herunterladen und Anpassen der Verzeichnisrechte

Anpassen der wp-config.php

WordPress: Aufruf und Setup

WordPress-Setup: erster Versuch

Die Lösung

Wozu der Umweg?

Weitere Schritte in WordPress

Tipps & Tricks

Neustart Webserver/PHP-FPM

Log-Dateien kontrollieren

Developer-Konsole (Browser)

Web-Suche

Vorgehenswiese für andere Web-Applikationen

FHEM

Moodle

Netdata

Pi-hole

Roundcube

shellinabox

Weiterführende Artikel

Links

Ähnliche Artikel:

Kommentare: 250

Schreibe einen Kommentar Antworten abbrechen

IT-Services

Direktlinks

Beliebt

Schlagwörter

Kategorien

Meta