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

16. November 2016JanHome-Server, 27

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.

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

1	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/favicon.ico {
				log_not_found off;
				access_log off;
		}

		location = /wordpress/robots.txt {
				allow all;
				log_not_found off;
				access_log off;
		}

		location ~ \.php$ {
				try_files $uri =404;
				fastcgi_split_path_info ^(.+\.php)(/.+)$;
				include fastcgi_params;				
				fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
				fastcgi_param PATH_INFO $fastcgi_path_info;
				fastcgi_pass php-handler;
				fastcgi_connect_timeout 60;
				fastcgi_index index.php;
				fastcgi_param PHP_VALUE "open_basedir=/var/www/wordpress
						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;
		}
	}
}

server {

server_name 127.0.0.1;

listen 127.0.0.1:83;

root /var/www/;

location ^~ /wordpress {

index index.php;

location = /wordpress/favicon.ico {

log_not_found off;

access_log off;

}

location = /wordpress/robots.txt {

allow all;

log_not_found off;

access_log off;

}

location ~ \.php$ {

try_files $uri =404;

fastcgi_split_path_info ^(.+\.php)(/.+)$;

include fastcgi_params;

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

fastcgi_param PATH_INFO $fastcgi_path_info;

fastcgi_pass php-handler;

fastcgi_connect_timeout 60;

fastcgi_index index.php;

fastcgi_param PHP_VALUE "open_basedir=/var/www/wordpress

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

1	nano /etc/nginx/conf.d/owncloud9tutorial.goip.de.conf

Die WordPress-Installation soll später unter der URL https://owncloud9tutorial.goip.de/wordpress erreichbar sein. Dazu muss an dieser Stelle ein separater location Block eingefügt werden (direkt unter dem Block für ownCloud):

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;
}

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;
}

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

1	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;

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

cd ~

wget https://wordpress.org/latest.tar.gz

tar xzvf latest.tar.gz -C /var/www

Nun werden auch gleich die entsprechenden Verzeichnisrechte:

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

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

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

cd /var/www/wordpress

cp wp-config-sample.php wp-config.php

nano wp-confg.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', '');

// ** 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_';

/**

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

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

1	service nginx restart

Wenn man danach allerdings in freudiger Erwartung die WordPress-URL aufruft (https://owncloud9tutorial.goip.de/wordpress), erlebt man einen herben Rückschlag:
Das WordPress-Setup wird zwar angezeigt, allerdings sieht die Seite komisch aus – sämtliche Formatierungen und Bilder scheinen zu fehlen. Offensichtlich werden die CSS-Dateien für die Formatierung von Text und Seite nicht korrekt geladen. Ein Blick in die Log-Datei von nginx (/var/log/nginx/error.log) liefert jedoch keinen Hinweis darauf, dass es beim Aufruf dieser Dateien zu Problemen kommt. Dies ist schon mal ein Hinweis darauf, dass es nicht an der Struktur des virtuellen Hosts für WordPress liegt.

Ein weiteres Indiz: Wenn man einen Blick auf den Seitenquelltext wirft (z.B. in Chrome: Rechtsklick auf freien Bereich der Website > Seitenquelltext anzeigen) und die URL einer konkreten CSS-Datei kopiert, lässt sich diese im Browser eingeben und der Dateiinhalt wird anschließend korrekt geladen. Die Dateien werden also vom Webserver definitiv richtig ausgeliefert.

Den entscheidenden Hinweis liefert erst die Developer-Konsole von Chrome (Shortcut: F12): Der Browser hat Mixed Content erkannt (HTTP/HTTPS) und den vermeintlich unsicheren (HTTP-)Inhalt blockiert.

Chrome: Fehlerhafte Anzeige wegen Mixed Content

Wie sich (nach langer Web-Recherche) herausstellt, handelt es sich hier um ein Problem von WordPress selbst: URLs von CSS- oder auch JavaScript-Dateien (*.js) werden hier absolut mittels einer Basis-URL angegeben. Durch das Konstrukt von Gateway-Host und Anwendungs-Host (letzterer wird intern nur über HTTP aufgerufen) ergibt sich hier die Problematik mit Mixed Content. Besser wäre es, wenn WordPress die URLs relativ angeben würde…

Die Lösung

Nun wollen wir natürlich nicht den Quellcode von WordPress direkt anpassen. Das Problem lässt sich aber zum Glück auch anderweitig in den Griff bekommen: Mit einem Zusatz in der wp-config.php weisen wir WordPress an, dass sämtliche Anfragen, die per HTTPS kommen, auch über HTTPS beantwortet werden. Dazu fügen wir in der wp-config.php ganz am Anfang (wichtig!) 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');

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

1	service nginx restart

Wenn es hierbei bereits zu Fehlern kommt (erfahrungsgemäß sind dies dann einfache Tippfehler in einem der Hosts), hilft ein Testen der Konfiguration mit:

nginx -t

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

1	service php-fpm restart

Log-Dateien kontrollieren

Bei auftretenden Problemen lohnt meist ein Blick in die Log-Dateien. Gerade bei HTTP-Statusfehlern (z.B. Fehler 403) sollte hier ein erster Ansatzpunkt zu finden sein. Dies liegt meistens an einer falschen Webserver-Konfiguration (virtuelle Hosts). Die zu prüfenden Logs sind dabei:

nginx Fehler-Log: /var/log/nginx/error.log
Log der Web-Anwendung: Wo dieser zu finden ist, hängt von der jeweiligen Anwendung ab

Developer-Konsole (Browser)

Falls keine Hinwiese in den Log-Dateien zu finden sind, hilft (wie in diesem konkreten Beispiel mit WordPress) ein Blick in die Developer-Konsole des verwendeten Browsers. Diese wird meistens über den Shortcut F12 gestartet (Chrome, Firefox, Internet Explorer). Die Vorgänge beim Laden einer Seite findet man meistens in einem Tab Konsole bzw. Console.

Web-Suche

Dieser Tipp ist zwar offensichtlich, soll aber trotzdem nicht unerwähnt bleiben: Die Konfiguration unter nginx mit einem Gateway-Host ist recht ungewöhnlich und unterscheidet sich z.T. erheblich von einer Standalone-Konfiguration (oftmals beschreiben Tutorials lediglich die Einrichtung unter nginx unter dem Webroot, bzw. als Subdomain). Eine Web-Suche nach <Anwendung> nginx SSL Proxy sollte Ergebnisse liefern, die zumindest die grobe Richtung des Unterfangens weisen.

Vorgehenswiese für andere Web-Applikationen

Nun seid ihr gefragt: Habt ihr andere Anwendungen mit der Konfiguration mit einem Gateway-Host und einzelnen (spezialisierten) virtuellen Hosts zum Laufen bekommen? Dann hinterlasst doch einen Kommentar oder schreibt mir besser noch eine E-Mail mit detaillierten Anweisungen. Ggf. wird der Artikel dann um konkrete Anweisungen für weitere Web-Applikationen erweitert.

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

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

1	nano /etc/netdata/netdata.conf

Beispielsweise kann hier in der [global] Sektion festgelegt werden, wie umfangreich die History der erfassten Daten sein soll. Dazu den Kommentar bei der folgenden Zeile entfernen:

history = 14400

1	history = 14400

Um das sog. Kernel Samepage Merging zu aktivieren, sind dann folgende Schritte notwendig: In der Datei /etc/rc.local sind diese Zeilen zu ergänzen:

#!/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

#!/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

1	nano /etc/nginx/conf.d/owncloud9tutorial.goip.de.conf

Hier wird wie gewohnt eine Weiterleitung an einen nicht belegten Port des Webservers hinzugefügt:

# netdata configuration
        location ^~ /netdata {        
        proxy_pass http://127.0.0.1:84;
}

# 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

1	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 *;
    }
}

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

1 2	systemctl restart netdata service nginx restart

Der Aufruf erfolgt dann über ein Unterverzeichnis des Webservers: http://owncloud9tutorial.goip.de.conf/netdata

Zu guter letzt kann Netdata auch über Skripte upgedated (oder sogar deinstalliert werden):

./netdata-uninstaller.sh
./netdata-updater.sh

1 2	./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

1	sudo ln -s /home/[BENUTZER]/netdata/netdate-update.sh /etc/cron.daily/netdata-update

Vielen Dank an Hans 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;
	}

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;
		}
	}
}

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"

1	SHELLINABOX_ARGS="--no-beep --localhost-only --disable-ssl"

Besonders der letzte Parameter (–disable-ssl) ist hier wichtig, da der proxy_pass vom Gateway-Host an shellinabox unverschlüsselt über HTTP läuft. Dies ist aber kein Sicherheitsrisiko, da die Verschlüsselung „eine Ebene höher“ vom Gateway-Host übernommen wird.

Darüber hinaus sind folgende Erweiterungen im Gateway-vHost notwendig (angenommen, Port 83 ist noch nicht belegt):

location ^~ /shellinabox {		
	proxy_pass http://127.0.0.1:83;
	proxy_read_timeout 90;
}

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;
	}
}

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

Home-Server, Let's Encrypt, Linux, MariaDB, Netdata, Nextcloud, nginx, PHP, 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: 27

Markus sagt:
24. November 2016 um 8:08
wie immer ein super Beitrag! Vielen Dank dafür.
Ich will am Wochenende versuchen „GitLab“ und „Mattermost“ neben der OwnCloud zu installieren. Mattermost bringt dabei einen eigenen Webserver mit. Wenn ich es richtig verstanden habe, sollte es dank des Proxies keine Probleme geben.
Antworten
- Jan sagt:
  24. November 2016 um 8:13
  Hallo Markus,
  genau: Wenn eine Anwendung einen eigenen Server mitbringt (z.B. Apache), oder eine eigene Web-Schnittstelle anbietet (z.B. FHEM), dann leitet man das einfach mittels proxy_pass entsprechend weiter.
  Gruß,
  Jan
  Antworten
Robin sagt:
9. Dezember 2016 um 19:38
Hallo Jan,
Vielen Dank auch für dieses Tutorial. Ich bin schon gespannt welches Projekt du dir als nächstes vornimmst 😉
Ich habe einen kleinen Fehler entdeckt. Bei der finalen Konfiguration der wp-config fehlt in Zeile 8 ein „;“
define(‚WP_SITEURL‘, ‚https://owncloud9tutorial.goip.de/wordpress‘);
Beste Grüße
Robin
Antworten
- Jan sagt:
  10. Dezember 2016 um 9:30
  Hallo Robin,
  danke für den Hinweis, habe ich gleich ausgebessert.
  Gruß,
  Jan
  Antworten
Marc sagt:
5. Januar 2017 um 8:45
Hallo Jan,
ich habe Dein super Tutorial benutzt, um Nextcloud auf meinem Raspberry Pi 3 zuhause zu installieren. Bis auf ein paar kleinere Stolpersteine (diverse Abhängigkeiten sind nur im Debian Stretch Repo zu finden etc.) hat alles wunderbar funktioniert! Danke dafür!
Ich tue mich nun aber schwer, eine zweite ‚Website‘ in die nginx Konfiguration einzubinden. Ich rede dabei nicht von WordPress sondern von pi-hole falls Dir das etwas sagt. Das möchte ich nutzen, um DNS basiert Werbeanbieter für alle Geräte im Netz zu blocken.
pi-hole kommt standardmäßig mit einem lighttpd, den ich einfach deinstalliere. pi-hole installiert sich in /var/www/html mit den Verzeichnissen /admin und /pi-hole wobei ich nur Zugriff auf /admin benötige. Wenn ich die Adresse anspreche passiert auch im Browser eine Umleitung auf Port 83, aber eine Seite bekomme ich nicht angezeigt.
Hast Du evtl. noch Tips?
Beste Grüße
Marc
Antworten
- Jan sagt:
  6. Januar 2017 um 10:02
  Hi Marc,
  danke für das Lob!
  Leider kenne ich mich mit lighttpd nicht aus. Dennoch wird es auch hier eine Konfiguration für vHosts geben. Die „Fleißarbeit“ dürfte hier sein, die lighttpd-Config in einen nginx-vHost zu überführen. Daraufhin könnten weitere Anpassungen notwendig sein, um das Ganze in das Konstrukt Gateway-Host/Anwendungs-Hosts zu überführen.
  Ein ganz anderer Ansatz, der vielleicht sogar einfacher ist: Lass lighttpd einfach installiert und pi-hole hosten. Hier nur darauf achten, dass kein von nginx belegter Port verwendet wird. Nun nutzt du die Reverse-Proxy-Fähigkeiten von nginx: Bei entsprechenden Requests, z.B. meinserver.de/pihole (oder so ähnlich) nimmt nginx den Request entgegen, leitet ihn aber mittels proxy_pass einfach an lighttpd weiter.
  Egal wie du vorgehst: Wenn irgendwas nicht klappt, mal einen Blick in die Webserver-Logs werfen. Hier sind meist Hinweise zu finden, was denn genau schief gelaufen ist.
  Gruß,
  Jan
  Antworten
Hans sagt:
1. Februar 2017 um 21:58
Hallo Jan,
vielen Dank für Anleitung. Ich habe mal wieder eine Herausforderung.
Ich möchte „Shellinabox“ installieren. Über verschiedene Seiten habe ich mir die Daten zusammengesucht:
https://www.djouxtech.net/posts/shell-in-a-box/
http://blog.geekuni.com/2013/12/students-behind-firewall-nginx-to-rescue.html
https://www.linuxhelp.com/how-to-install-shell-in-a-box-access-remote-linux-servers/
https://code.google.com/archive/p/shellinabox/
Meine owncloud9tutorial.goip.de_shellinabox.conf sieht so aus:
server {
server_name 127.0.0.1;
listen 127.0.0.1:83;
location ~/shellinabox/ {
rewrite ^/shellinabox/(.*) /$1 break;
proxy_pass http://127.0.0.1:4200;
proxy_read_timeout 90;
}
}
Miene owncloud9tutorial.goip.de.conf habe ich erweitert:
location /terminal/ {
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Host $http_host;
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:83/;
}
Ein Aufruf von netstat -nap | grep shellinabox bringt
tcp 0 0 0.0.0.0:4200 0.0.0.0:* LISTEN 15927/shellinaboxd
unix 3 [ ] STREAM VERBUNDEN 33081 15927/shellinaboxd
unix 3 [ ] STREAM VERBUNDEN 29559 15928/shellinaboxd
unix 3 [ ] STREAM VERBUNDEN 29558 15927/shellinaboxd
Da finde ich es auffällig, dass keine IP Adresse angezeigt wird. Sollte doch eigentlich so sein.
Ein Aufruf von http://owncloud9tutorial.goip.de/terminal/ bringt eine 404.
Vielleicht hast Du ja eine Idee?
Viele Grüße
Hans
Antworten
- Jan sagt:
  2. Februar 2017 um 18:20
  Hi Hans,
  bei solchen Fehler (404, etc.) sollte man auch immer mal einen Blick in das nginx error.log werfen. Hier solltest du zumindest Infos finden, welche Datei/Seite er nicht finden kann.
  Ich würde es nun mal mit folgenden Änderungen probieren (beachte genau die Zeichen „^~“ und die weggenommenen „/“):
  In der owncloud9tutorial.goip.de_shellinabox.conf:
  location ^~ /shellinabox { rewrite ^/shellinabox/(.*) /$1 break; proxy_pass http://127.0.0.1:4200; proxy_read_timeout 90; }
  Und in der owncloud9tutorial.goip.de.conf:
  location ^~ /terminal { proxy_set_header Host $http_host; proxy_set_header X-Forwarded-Host $http_host; 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:83/; }
  Ansonsten sieht das meiner Meinung nach ganz gut aus.
  Wenn es immer noch nicht klappen sollte, schau mal wie gesagt in die Logs.
  Gruß,
  Jan
  Antworten
Hans sagt:
2. Februar 2017 um 19:49
Hi Jan,
vielen Dank für die Antwort.
Die Änderungen haben leider auch nichts bewirkt. Auch nach einem Neustart.
Das nginx error log sagt
2017/02/02 19:28:07 [error] 1453#1453: *1 open() „/etc/nginx/html/shellinabox“ failed (2: No such file or directory), client: 80.171.80.68, server: laufsegel.goip.de, request: „GET /shellinabox HTTP/2.0“, host: „laufsegel.go$
2017/02/02 19:31:18 [error] 1453#1453: *22 „/etc/nginx/html/index.html“ is not found (2: No such file or directory), client: 127.0.0.1, server: 127.0.0.1, request: „GET // HTTP/1.0“, host: „laufsegel.goip.de“
2017/02/02 19:31:30 [error] 1453#1453: *24 „/etc/nginx/html/index.html“ is not found (2: No such file or directory), client: 127.0.0.1, server: 127.0.0.1, request: „GET // HTTP/1.0“, host: „laufsegel.goip.de“
Er findet also keine Datei in www. Ich habe lediglich unter /etc ein shellinabox Verzeichnis gefunden, dass aber nur die Optionen (Farbe usw.) beinhaltet.
Was könnte ich noch machen?
Gruß
Hans
Antworten
- Jan sagt:
  3. Februar 2017 um 7:27
  Hi Hans,
  um zunächst einmal die Lauffähigkeit von Shellinabox zu testen, kannst du mal http://lokale-IP-des-Servers:4200 aufrufen. Mit diesem Aufruf umgehst du nginx zunächst einmal komplett. Wenn das auch nicht funktioniert, dann liegt es wohl an der Konfiguration von Shellinabox (glaube ich aber nicht).
  Folgendes Problem könnte ich mir noch vorstellen: Aufruf der URL /terminal, er leitet weiter auf den Shellinabox-vHost. Hier wird dann nichts gefunden, weil die URL ja /terminal lautet und nicht /shellinabox -> der proxy_pass wird gar nicht ausgeführt und du bekommst einen 404er.
  Setz doch mal in der owncloud9tutorial.goip.de.conf die Location auf ^~ /shellinabox (nicht mehr ^~ /terminal).
  Gruß,
  Jan
  Antworten
Hans sagt:
3. Februar 2017 um 17:54
Hallo Jan,
http://:4200 funktioniert leider auch nicht.
Wenn ich die Änderung auf /shellinabox mache, bekomme ich eine 502 Seite.
Der nginx error log sagt dann:
2017/02/03 17:48:26 [warn] 19755#19755: no resolver defined to resolve ocsp.int-x3.letsencrypt.org while requesting certificate status, responder: ocsp.int-x3.letsencrypt.org, certificate: „/etc/letsencrypt/live/laufsegel.goip.de/fullchain.pem“
2017/02/03 17:48:26 [error] 19755#19755: *4 upstream prematurely closed connection while reading response header from upstream, client: 127.0.0.1, server: 127.0.0.1, request: „GET /shellinabox/ HTTP/1.0“, upstream: „http://127.0.0.1:4200/“, host: „laufsegel.goip.de“
Was bedeutet das jetzt?
Gruß
Hans
Antworten
- Jan sagt:
  4. Februar 2017 um 8:47
  Hi Hans,
  arg, die Angabe http://:4200 war natürlioch falsch, hier hat WordPress etwas entfernt und mir ist es nicht aufgefallen.
  Die Richtige URL lautet natürlich: http://lokale-IP-des-Servers:4200 (also z.B. http://192.168.178.100:4200)
  Probier es mal damit, so bekommen wir heraus, ob Shellinabox schonmal ordnungsgemäß funktioniert.
  Sorry für die Verwirrung!
  Gruß,
  Jan
  Antworten
Hans sagt:
4. Februar 2017 um 10:13
Hallo Jan,
kein Problem mit der Verwirrung.
Unter http://192.169.178.33:4200/ kommt in Firefox: Verbindung fehlgeschlagen. Er konnte keine Verbindung zu dem Server aufbauen.
Eine Verbindung zu https://192.168.178.33/nextcloud/ funktioniert aber.
Viele Grüße
Hans
Antworten
- Jan sagt:
  4. Februar 2017 um 12:58
  Hi Hans,
  blockt hier vielleicht noch irgendetwas, z.B. ufw?
  Sorry, ich habe gerade keine Test-VM zur Verfügung, sonst würde ich das mal schnell nachtesten. Ich hoffe, dass ich in den kommenden Tagen eine VM aufsetzen kann, dann würde ich mich nochmal melden.
  Gruß,
  Jan
  Antworten
Hans sagt:
4. Februar 2017 um 17:15
Hi Jan,
ich wüsste nicht, dass ich einen firewall installiert habe.
root@lin-core:~# sudo ufw status
Status: Inaktiv
Ich bin ab So bis Mi nicht da, kann also nichts ausprobieren.
Gruß
Hans
Antworten
- Jan sagt:
  5. Februar 2017 um 11:58
  Hi Hans,
  kein Problem. Vielleicht bekomme ich bis Mittwoch eine Test-VM zum laufen. Dann kann ich dir bis dahin wahrscheinlich besser weiter helfen
  Gruß,
  Jan
  Antworten
  - Jan sagt:
    6. Februar 2017 um 18:53
    Hallo Hans,
    Test-VM läuft und ich konnte das nun über einen Gateway-Host zum Laufen kriegen.
    Deine Config war dabei an sich schon richtig, allerdings verweigert shellinabox die Arbeit, wenn die Verbindung nicht über SSL läuft – und die (lokale) Verbindung Gateway-Host -> shellinabox-vHost läuft ja unverschlüsselt über HTTP.
    Hier ist nur eine kleine Änderung in der shellinabox-Konfiguration (nano /etc//default/shellinabox) notwendig:
    SHELLINABOX_ARGS="--no-beep --localhost-only --disable-ssl"
    Ich habe das Tutorial gleich mal um einen Abschnitt über shellinabox erweitert.
    Danke für deinen Input!
    Gruß,
    Jan
    Antworten
Hans sagt:
8. Februar 2017 um 20:21
Hallo Jan,
sorry, dass ich mich nicht früher gemeldet habe, aber ich war ein paar Tage weg. Hatte mich schon auf die Lösung des Problems gefreut.
Bei mir funktioniert es leider immer noch nicht. Ich habe meine nginx configs mit Deinen ausgetauscht. Weiterhin habe ich die shellinabox Konfiguration auch angepasst. Leider das gleiche Resultat.
Ich bin echt ratlos.
Gruß
Hans
Antworten
Hans sagt:
23. März 2017 um 8:21
Hallo Jan,
wenn ich WordPress jetzt über den Browser aufrufe wird automatisch der festgelegte Port (86) mit angehängt.
Z. B. http://www.hans.de:86/wordpress
Ich gebe allerdings nur http://www.hans.de/wordpress ein.
In der conf (wordpress) für den vHost kann ich allerdings nichts finden. Auch in den Netzwerkeinstellungen oder in der conf des Gateway-Host ist kein Fehler.
Hast du eine Idee?
Vielen Dank
Gruß Hans
Antworten
- Jan sagt:
  23. März 2017 um 17:18
  Hi Hans,
  geht der Redirect für WP im Gateway-Host auch tatsächlich an die IP 127.0.0.1 (also kein server_name, LAN-IP des Servers oder so)?
  Ich kann mir das ansonsten nicht wirklich erklären. Wenn du es nicht hinbekommst, kannst du mir aber nochmal deine Configs schicken.
  Gruß,
  Jan
  Antworten
  - Hans sagt:
    23. März 2017 um 19:50
    Hallo Jan,
    der server_name ist nur im Gateway-Host und nicht in der WP hinterlegt. Schicke dir gerne mal die configs.
    Danke schon mal!
    Gruß Hans.
    Antworten
R.S. sagt:
20. April 2017 um 22:28
Wollte die Tage das Ts3 webinterface von psychokiller neben nextcloud installieren, da ein ts3-server nebenher läuft. habe auch soweit alles eingerichtet, aber wenn ich die url aufrufe wird mir sofort der quelltext angezeigt, statt die normale website, sehe also quasi den inhalt der php file. hier nun mal meine vhost file:
server {
server_name 127.0.0.1;
listen 127.0.0.1:84;
root /var/www/;
location ^~ /ts3 {
index index.php;
charset UTF-8;
location = /ts3/favicon.ico {
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/ts3
upload_max_filesize = 1G
post_max_size = 1G
max_execution_time = 3600“;
}
location ~* /ts3/\.(js|css|png|jpg|jpeg|gif|ico)$ {
expires max;
log_not_found off;
}
}
}
Antworten
- Jan sagt:
  22. April 2017 um 8:46
  Hi,
  wenn die PHP-Dateien uninterpretiert ausgeliefert werden, dann wird wohl kein Handler für PHP gefunden.
  Das übernimmt normalerweise diese Zeile: fastcgi_pass php-handler;
  Dieser Handler muss im Gateway-Host definiert sein, damit jeder Anwendungs-vHost diesen auch finden kann. Ich vermute einfach mal, dass dieser Handler bei dir noch im ownCloud vHost definiert ist. Diesen must du dann „eine Ebene hochziehen“ (also in den Gateway-Host).
  Gruß,
  Jan
  Antworten
  - R.S. sagt:
    23. April 2017 um 20:04
    Im Gateway-Host wird der php-handler so definiert:
    upstream php-handler {
    server unix:/run/php/php7.0-fpm.sock;
    }
    und hier noch der location block:
    location ~ \.php$ {
    try_files $uri =404;
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    fastcgi_pass unix:/var/run/php7.0-fpm.sock;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
    }
    Antworten
    - R.S. sagt:
      23. April 2017 um 20:07
      Hat sich erledigt, hab den fehler gefunden, im nextcloud vhost war der fastcgi_pass noch auf den fpm sock definiert und nicht den php-handler… auf den trichter muss man erstmal kommen 😀
      Antworten
      - Jan sagt:
        24. April 2017 um 11:08
        Hi,
        super, wenn es nun klappt. Manchmal sind es wirklich diese Kleinigkeiten, die dafür sorgen, dass irgend etwas nicht wie erwartet funktioniert…
        Gruß,
        Jan
Hendrik sagt:
29. Mai 2017 um 19:24
Hi Jan,
ich hoffe dieser Kommentar kommt nun nicht x-fach. Irgendwie wird mir mein Kommentar nicht mehr angezeigt.
Egal, hättest du Zeit und Lust gegen eine große Pizza-Spende mal auf meine Config per teamviewer zu schaun? Denn ich bekomm es einfach nicht hin. Meine Mail Adresse solltest du sehen, melde dich bitte wenn du magst.
Danke und Gruß
Hendrik
Antworten

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

Netdata

Roundcube

shellinabox

Weiterführende Artikel

Links

Kommentare: 27

Schreibe einen Kommentar Antworten abbrechen

Connect

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

Netdata

Roundcube

shellinabox

Weiterführende Artikel

Links

Ähnliche Artikel:

Kommentare: 27

Schreibe einen Kommentar Antworten abbrechen

Connect

Direktlinks

Beliebt

Schlagwörter

Kategorien

Meta