Alexa4p3 für Dummies

[AndreK]

Hallo 2malmama ,

journalctl -xe muss mit "kleinem x" sein - hat sich ja bereits geklärt

prüfe mal bitte noch was mit der Ausgabe des NGINX-Error-Logs kommt :

sudo cat /var/log/nginx/error.log

vielleicht steht da etwas mehr.

Falls das zu unübersichtlich ist kannst Du mit

sudo tail -f /var/log/nginx/error.log

die Datei mit Aktualisierungen anzeigen lassen.

In einer zweiten Konsole dann den NGINx mittels

sudo systemctl restart nginx.service

neu starten.

Das mit den Dateien die Du nicht findest kommt daher, dass im Image bereits Anpassungen vorgenommen sind (da ich aktuell kein Image am Laufen habe kann ich
das nicht wirklich nachvollziehen)

Welche Dateien stehen im Ordner ../sites-enabled und welche stehen im Ordner ../conf.d ?
Welche von den Dateien hast Du nach deiner Config angepasst ?

Gruss Andre

[2malmama]

Hallo Andre,

also in conf.d sind 2 Dateien enthalten. Die von mir erstellte <mydomain>.<mydns>.<me>.conf und https.conf.
In sites-enabled ist jetzt keine Datei mehr.

Die Ausgabe für

sudo tail -f /var/log/nginx/error.log

ergibt bei dem Befehl

sudo systemctl restart nginx.service

folgendes:

2020/10/16 21:16:06 [emerg] 930#930: the size 62914560 of shared memory zone "SSL" conflicts with already declared size 10485760 in /etc/nginx/conf.d/https.conf:43

Die Zeilen vor dem Restart sehen so aus:

sudo tail -f /var/log/nginx/error.log
2020/10/16 17:29:50 [emerg] 499#499: invalid number of arguments in "proxy_pass" directive in /etc/nginx/conf.d/<mydomain>.<mydns>.<me>.conf:75
2020/10/16 17:53:18 [emerg] 501#501: the size 62914560 of shared memory zone "SSL" conflicts with already declared size 10485760 in /etc/nginx/conf.d/https.conf:43
2020/10/16 18:14:02 [emerg] 508#508: the size 62914560 of shared memory zone "SSL" conflicts with already declared size 10485760 in /etc/nginx/conf.d/https.conf:43
2020/10/16 19:37:00 [emerg] 988#988: the size 62914560 of shared memory zone "SSL" conflicts with already declared size 10485760 in /etc/nginx/conf.d/https.conf:43
2020/10/16 19:50:46 [emerg] 497#497: the size 62914560 of shared memory zone "SSL" conflicts with already declared size 10485760 in /etc/nginx/conf.d/https.conf:43
2020/10/16 19:53:23 [emerg] 711#711: the size 62914560 of shared memory zone "SSL" conflicts with already declared size 10485760 in /etc/nginx/conf.d/https.conf:43
2020/10/16 20:43:38 [emerg] 1064#1064: the size 62914560 of shared memory zone "SSL" conflicts with already declared size 10485760 in /etc/nginx/conf.d/https.conf:43
2020/10/16 20:47:33 [emerg] 1112#1112: the size 62914560 of shared memory zone "SSL" conflicts with already declared size 10485760 in /etc/nginx/conf.d/https.conf:43
2020/10/16 20:48:54 [emerg] 501#501: the size 62914560 of shared memory zone "SSL" conflicts with already declared size 10485760 in /etc/nginx/conf.d/https.conf:43
2020/10/16 20:49:02 [emerg] 676#676: the size 62914560 of shared memory zone "SSL" conflicts with already declared size 10485760 in /etc/nginx/conf.d/https.conf:43

kannst Du Damit was anfangen?

[AndreK]

Hier noch ein kurzer Hinweis zum System selbst :

einen Reboot brauchst Du nur bei einem wirklichen System-Update. Das ist ja gerade das "schöne" an Linux.
Du kannst die Dienste jederzeit neu starten (systemctl restart ...) Dann bekommst Du auch die entsprechende Info ob erfolgreich oder nicht (via journalctl -xe
oder systemctl status xxxx.serice - xxx = name des Services)
Beim Neustart werden fehlerhaft konfigurierte Dienste nicht gestartet und Du musst dir das System-log ansehen.
Anders als bei "WINDOWS"-Systemen wird das meiste in-line nach Installations-Aufforderung direkt installiert und gestartet - Es gibt Ausnahmen - aber diese Anwendungen teilen das mit.

Gruss Andre

[2malmama]

Vielen Dank Andre! Das habe ich mir gleich mal notiert - das wird sicher an der ein oder anderen Stelle noch helfen!

Aber was mach ich, wenn mich z. B. der NGINX bei einem Reload nach einem Kennwort fragt, das ich überhaupt nicht vergeben habe (leer nimmt er nicht).
Die Angabe war so was wie in der Art wie smarthome, , ,(root) oder so ähnlich zumindest

[2malmama]

Ich hab mal testhalber die Zeile 42 in der https.conf auskommentiert (wider besseren Wissens zu der Zeit) neu gestartet und noch mal sudo nginx -t ausgeführt.
Das bringt jetzt folgendes:

sudo nginx -t
nginx: [emerg] host not found in upstream "websocket" in /etc/nginx/conf.d/https.conf:134
nginx: configuration file /etc/nginx/nginx.conf test failed

bringt uns das weiter?

[2malmama]

vielleicht bringt uns ja das hier weiter:

in der https.conf steht: ssl_session_cache builtin:1000 shared:SSL:60m;
in der <mydomain>.<mydns>.<me> steht: ssl_session_cache builtin:1000 shared:SSL:10m;

könnte das den Konflikt ausmachen?

Ich komme darauf, weil

sudo tail -f /var/log/nginx/error.log

sich doch irgendwie auf beide Dateien bezieht mit der Ausgabe, oder?

sudo tail -f /var/log/nginx/error.log
2020/10/16 17:29:50 [emerg] 499#499: invalid number of arguments in "proxy_pass" directive in /etc/nginx/conf.d/<mydomain>.<mydns>.<me>.conf:75
2020/10/16 17:53:18 [emerg] 501#501: the size 62914560 of shared memory zone "SSL" conflicts with already declared size 10485760 in /etc/nginx/conf.d/https.conf:43

[wvhn]

Google liefert einige Einträge zu dem Fehler. Ich denke, es ist sinnvoll, in der mydomain... die Definition des session_cache auszukommentieren.

[2malmama]

ja - ich quäle mich auch schon die verschiedenen Beiträge (und bin mir dabei nicht ganz sicher, ob ich mich freuen soll, dass ich mit meinem Problem nicht alleine dastehe)...

Ich hatte zunächst in der https.conf den shared:SSL:Wert an die in meiner Datei angepasst - das brachte keinen Erfolg.
Als nächstes habe ich mich Deinem Vorschlag gewidmet Wolfram (vorher hab ich meine Änderung wieder rückgängig gemacht)

jetzt passiert folgendes:

sudo nginx -t
nginx: [emerg] host not found in upstream "websocket" in /etc/nginx/conf.d/https.conf:134
nginx: configuration file /etc/nginx/nginx.conf test failed

[wvhn]

Aber was mach ich, wenn mich z. B. der NGINX bei einem Reload nach einem Kennwort fragt, das ich überhaupt nicht vergeben habe

Bist Du sicher, dass der nginx Dich beim Neustart nach dem Passwort fragt? Oder ist es nur der sudo-Befehl?

[2malmama]

bei

sudo tail -f /var/log/nginx/error.log

kommt zunächst

2020/10/16 20:49:02 [emerg] 676#676: the size 62914560 of shared memory zone "SSL" conflicts with already declared size 10485760 in /etc/nginx/conf.d/https.conf:43
2020/10/16 21:16:06 [emerg] 930#930: the size 62914560 of shared memory zone "SSL" conflicts with already declared size 10485760 in /etc/nginx/conf.d/https.conf:43
2020/10/16 21:36:59 [emerg] 505#505: host not found in upstream "websocket" in /etc/nginx/conf.d/https.conf:134
2020/10/16 21:39:17 [emerg] 769#769: host not found in upstream "websocket" in /etc/nginx/conf.d/https.conf:134
2020/10/16 21:55:39 [emerg] 866#866: host not found in upstream "websocket" in /etc/nginx/conf.d/https.conf:134
2020/10/16 21:56:24 [emerg] 505#505: host not found in upstream "websocket" in /etc/nginx/conf.d/https.conf:134
2020/10/16 21:57:32 [emerg] 759#759: host not found in upstream "websocket" in /etc/nginx/conf.d/https.conf:134
2020/10/16 22:06:55 [emerg] 506#506: host not found in upstream "websocket" in /etc/nginx/conf.d/https.conf:134
2020/10/16 22:07:49 [emerg] 716#716: host not found in upstream "websocket" in /etc/nginx/conf.d/https.conf:134
2020/10/16 22:10:28 [emerg] 503#503: host not found in upstream "websocket" in /etc/nginx/conf.d/https.conf:134
2020/10/16 22:10:42 [emerg] 743#743: host not found in upstream "websocket" in /etc/nginx/conf.d/https.conf:134

und wenn ich in einem zweiten Terminalfenster

sudo systemctl restart nginx.service

eingebe, bekomme ich im ersten Fenster keine Reaktion und im zweiten eine Fehlermeldung:

sudo systemctl restart nginx.service
Job for nginx.service failed because the control process exited with error code.
See "systemctl status nginx.service" and "journalctl -xe" for details.

das führt zu folgendem:

systemctl status nginx.service
● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Fri 2020-10-16 22:12:50 CEST; 5min ago
Docs: man:nginx(8)
Process: 792 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=1/FAILURE)

und

sudo journalctl -xe
--
-- The job identifier is 722.
Okt 16 22:12:50 SmartHomeNG nginx[792]: nginx: [emerg] host not found in upstream "websocket" in /etc/nginx/conf.d/https.conf:134
Okt 16 22:12:50 SmartHomeNG nginx[792]: nginx: configuration file /etc/nginx/nginx.conf test failed
Okt 16 22:12:50 SmartHomeNG systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
-- Subject: Unit process exited
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- An ExecStartPre= process belonging to unit nginx.service has exited.
--
-- The process' exit code is 'exited' and its exit status is 1.
Okt 16 22:12:50 SmartHomeNG systemd[1]: nginx.service: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- The unit nginx.service has entered the 'failed' state with result 'exit-code'.
Okt 16 22:12:50 SmartHomeNG systemd[1]: Failed to start A high performance web server and a reverse proxy server.
-- Subject: A start job for unit nginx.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A start job for unit nginx.service has finished with a failure.
--
-- The job identifier is 722 and the job result is failed.
Okt 16 22:12:50 SmartHomeNG sudo[785]: pam_unix(sudo:session): session closed for user root
Okt 16 22:14:39 SmartHomeNG smbd[796]: [2020/10/16 22:14:39.046774, 0] ../lib/param/loadparm.c:784(lpcfg_map_parameter)
Okt 16 22:14:39 SmartHomeNG smbd[796]: Unknown parameter encountered: ". panic action"
Okt 16 22:14:39 SmartHomeNG smbd[796]: [2020/10/16 22:14:39.046979, 0] ../lib/param/loadparm.c:1810(lpcfg_do_global_parameter)
Okt 16 22:14:39 SmartHomeNG smbd[796]: Ignoring unknown parameter ". panic action"
Okt 16 22:14:39 SmartHomeNG smbd[796]: pam_unix(samba:session): session opened for user smarthome by (uid=0)
Okt 16 22:14:49 SmartHomeNG smbd[796]: pam_unix(samba:session): session closed for user smarthome
Okt 16 22:17:01 SmartHomeNG CRON[808]: pam_unix(cron:session): session opened for user root by (uid=0)
Okt 16 22:17:01 SmartHomeNG CRON[812]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Okt 16 22:17:01 SmartHomeNG CRON[808]: pam_unix(cron:session): session closed for user root
Okt 16 22:18:55 SmartHomeNG sudo[826]: smarthome : TTY=pts/1 ; PWD=/home/smarthome ; USER=root ; COMMAND=/bin/journalctl -xe
Okt 16 22:18:55 SmartHomeNG sudo[826]: pam_unix(sudo:session): session opened for user root by (uid=0)
lines 2116-2153/2153 (END)
--
-- The job identifier is 722.
Okt 16 22:12:50 SmartHomeNG nginx[792]: nginx: [emerg] host not found in upstream "websocket" in /etc/nginx/conf.d/https.conf:134
Okt 16 22:12:50 SmartHomeNG nginx[792]: nginx: configuration file /etc/nginx/nginx.conf test failed
Okt 16 22:12:50 SmartHomeNG systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
-- Subject: Unit process exited
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- An ExecStartPre= process belonging to unit nginx.service has exited.
--
-- The process' exit code is 'exited' and its exit status is 1.
Okt 16 22:12:50 SmartHomeNG systemd[1]: nginx.service: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- The unit nginx.service has entered the 'failed' state with result 'exit-code'.
Okt 16 22:12:50 SmartHomeNG systemd[1]: Failed to start A high performance web server and a reverse proxy server.
-- Subject: A start job for unit nginx.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A start job for unit nginx.service has finished with a failure.
--
-- The job identifier is 722 and the job result is failed.
Okt 16 22:12:50 SmartHomeNG sudo[785]: pam_unix(sudo:session): session closed for user root
Okt 16 22:14:39 SmartHomeNG smbd[796]: [2020/10/16 22:14:39.046774, 0] ../lib/param/loadparm.c:784(lpcfg_map_parameter)
Okt 16 22:14:39 SmartHomeNG smbd[796]: Unknown parameter encountered: ". panic action"
Okt 16 22:14:39 SmartHomeNG smbd[796]: [2020/10/16 22:14:39.046979, 0] ../lib/param/loadparm.c:1810(lpcfg_do_global_parameter)
Okt 16 22:14:39 SmartHomeNG smbd[796]: Ignoring unknown parameter ". panic action"
Okt 16 22:14:39 SmartHomeNG smbd[796]: pam_unix(samba:session): session opened for user smarthome by (uid=0)
Okt 16 22:14:49 SmartHomeNG smbd[796]: pam_unix(samba:session): session closed for user smarthome
Okt 16 22:17:01 SmartHomeNG CRON[808]: pam_unix(cron:session): session opened for user root by (uid=0)
Okt 16 22:17:01 SmartHomeNG CRON[812]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Okt 16 22:17:01 SmartHomeNG CRON[808]: pam_unix(cron:session): session closed for user root
Okt 16 22:18:55 SmartHomeNG sudo[826]: smarthome : TTY=pts/1 ; PWD=/home/smarthome ; USER=root ; COMMAND=/bin/journalctl -xe
Okt 16 22:18:55 SmartHomeNG sudo[826]: pam_unix(sudo:session): session opened for user root by (uid=0)

[2malmama]

Bist Du sicher, dass der nginx Dich beim Neustart nach dem Passwort fragt? Oder ist es nur der sudo-Befehl?

ja, denn das hier passiert dann:

/etc/init.d/nginx reload
[....] Reloading nginx configuration (via systemctl): nginx.service==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Legitimierung ist zum erneuten Laden von »nginx.service« notwendig.
Authenticating as: SmartHomeNG,,, (root)
Password:

[henfri]

Hallo,

/etc/init.d/nginx reload

Die Systemkonfiguration betreffende Befehle brauchen sudo.

Wenn ich es richtig gesehen habe, kamen die Probleme mit dem nginx ja nachdem du certbot hast laufen lassen, oder?

Hast du vorher/nachher manuell etwas an der Konfiguration in /etc/nginx/ geändert?

Gruß,
Hendrik

[2malmama]

Guten Morgen Hendrik,

Die Systemkonfiguration betreffende Befehle brauchen sudo.

. Ah - daher die Passwortabfrage - ok, das hab ich glaub ich jetzt verstanden. Das heißt, ich kann bei solchen Passwortabfragen generell mal versuchen, die Abfrage als root zu tätigen.

Hast du vorher/nachher manuell etwas an der Konfiguration in /etc/nginx/ geändert?

Lass mal grad überlegen:

• es lief bevor ich mich an die Reverse-Proxy-Anleitung gemacht habe.
• dann hab ich das SSL-Zertifikat erstellt (bei dem es zum Abschluss zwar die Erfolgsmeldung aber den "Error output from ufw" gab.
• dann hatte ich festgestellt, dass die nginx.conf bereits gemäß Anleitung konfiguriert war
• im Anschluss habe ich meine persönliche Conf-Datei erstellt, die Eintragungen gemacht (hierbei beim Network Plugin Weiterleitungsport aber geraten)

Nee - hab nix geändert.

Macht es Sinn den Certbot noch mal laufen zu lassen?

[henfri]

Lass mal grad überlegen:

• es lief bevor ich mich an die Reverse-Proxy-Anleitung gemacht habe.
• dann hab ich das SSL-Zertifikat erstellt (bei dem es zum Abschluss zwar die Erfolgsmeldung aber den "Error output from ufw" gab.
• dann hatte ich festgestellt, dass die nginx.conf bereits gemäß Anleitung konfiguriert war
• im Anschluss habe ich meine persönliche Conf-Datei erstellt, die Eintragungen gemacht (hierbei beim Network Plugin Weiterleitungsport aber geraten)

Nee - hab nix geändert.

Hm, das sind ja leider viele Schritte auf einmal.
Aber du hast sie auch nicht ganz klar beschrieben... Die Punkte die du gelistet hast *sind* doch die Reverse-Proxy Anleitung, oder? Also Punkt 2-4 sind Teil von 1.

Was meinst du mit Punkt 4?
Zeig mal her, deine Konfiguration.

Das hier ist das Problem

[emerg] host not found in upstream "websocket" in /etc/nginx/conf.d/https.conf:134

Macht es Sinn den Certbot noch mal laufen zu lassen?

Glaube nicht.

Gruß,
Hendrik

[2malmama]

Wie meinst Du viele Schritte auf einmal?

Also - ich hatte eine funktionsfähige Verbindung von Außen, danach habe ich mich and die Reverseproxy-Anleitung gemacht, damit ich mich an die Einbindung von Alexa kümmern kann. Ich wollte also die Vorbereitung treffen, um im nächsten Schritt die Konfiguration von Lambda und Amazon-AWS durchzuführen.

Für mich beginnt die Reverse-Proxy Anleitung an dem Punkt, an dem ich die Zertifkate erstellen muss. (Lag ich falsch?):

- die Weiterleitungen sind in der "/etc/nginx/conf.d/<mydomain>.<myds>.<me>.conf" definiert.
- Es muss zunächst obige Datei entsprechend erstellt und konfiguriert werden, es muss ein Zertifikat via letsencrypt erstellt und eingebunden werden - siehe auch hier

Daher hatte ich folgende Schritte durchgeführt:

SSL zertifikat für DDNS erstellen mit sudo apt-get install certbot

Die /etc/nginx/snippets/letsencrypt.conf ist schon konfiguriert und derOrdner acme-challenge ist schon vorhanden, auch /etc/nginx/sites-available/default ist schon bearbeitet.

Weiter geht es mit sudo certbot certonly --rsa-key-size 4096 --webroot -w /var/www/letsencrypt -d <mydomain>.<myds>.<me>
Und wie beschrieben beginnt die Prozedur nach der Angabe der Mailadresse.

Nach dem Durchlauf kommt eine Erfolgsmeldung (sieht ganz anders aus als in der Anleitung). Trotz der Erfolgsmeldung gab es 2 identische Fehler, einer nach der Frage ob man seine E-Mailadresse der EFF zur Verfügung stellen möchte, der zweite bevor die Erfolgsmeldung kam:

fehler certbot.PNGhttps://knx-user-forum.de/core/image...EAAAICRAEAOw==
Da ich die Erfolgsmeldung, eine Speicherinformation und ein Ablaufdatum für den Key erhalten habe, habe ich der Sache nicht allzu viel Aufmerksamkeit gewidmet.

Die /etc/nginx/nginx.conf ist schon konfiguriert.

Anschließend hab ich die Eintragungen in meiner Conf-Datei gemacht:

server {
server_tokens off;

## Blocken, wenn Zugriff aus einem nicht erlaubten Land erfolgt ##
if ($allowed_country = no) {
return 403;
}

# https://www.cyberciti.biz/tips/linux...-security.html
## Block download agents ##
if ($http_user_agent ~* LWP::Simple|BBBike|wget) {
return 403;
}

## Block some robots ##
if ($http_user_agent ~* msnbot|scrapbot) {
return 403;
}

## Deny certain Referers ##
if ( $http_referer ~* (babes|forsale|girl|jewelry|love|nudit|organic|pok er|porn|sex|teen) )
{
return 403;
}

listen 443 ssl default_server;
#server_name <mydomain>.<myds>.<me>;
server_name meinepersonalisierte.dns.de;

##
# SSL
##

## Activate SSL, setze SERVER Zertifikat Informationen ##
# Generiert via Let's Encrypt!
ssl on;
#ssl_certificate /etc/letsencrypt/live/<mydomain>.<myds>.<me>/fullchain.pem;
ssl_certificate /etc/letsencrypt/live/meinepersonalisierte.dns.de/fullchain.pem;
#ssl_certificate_key /etc/letsencrypt/live/<mydomain>.<myds>.<me>/privkey.pem;
ssl_certificate_key /etc/letsencrypt/live/meinepersonalisierte.dns.de/privkey.pem;
ssl_session_cache builtin:1000 shared:SSL:10m;
ssl_prefer_server_ciphers on;
# unsichere SSL Ciphers deaktivieren!
ssl_ciphers HIGH:!aNULL:!eNULL:!LOW:!3DES:!MD5:!RC4;

##
# HSTS
##

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

##
# global
##

#root /var/www/<mydomain>.<myds>.<me>;
root /var/www/meinepersonalisierte.dns.de;
index index.php index.htm index.html;

# Weiterleitung zu SmartHomeNG (Websocket Schnittstelle) mit Basic Auth
# Nur Verbindungen gegen "/" durchlassen! Also weder auf Dateien noch Verzeichnisse (= nur Websocket Connects)
location = / {
auth_basic "Restricted Area: smartVISU";
auth_basic_user_file /etc/nginx/.smartvisu;
#proxy_pass http://<SmartHomeNG LAN IP>:<Websocket Port>;
proxy_pass http://192.168.222.168:2424;
}

# Zugriff auf die smartVISU mit Basic Auth
location /smartVISU {
auth_basic "Restricted Area: smartVISU";
auth_basic_user_file /etc/nginx/.smartVISU;
#proxy_pass http://<smartVISU Server LAN IP>/smartVISU;
proxy_pass http://192.168.222.168/smartVISU;
proxy_set_header 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;
}

# Alexa Plugin Weiterleitung
location /alexa {
auth_basic "Restricted Area: Alexa";
auth_basic_user_file /etc/nginx/.alexa;
#proxy_pass http://<SmartHomeNG LAN IP>:<Alexa Plugin Port>/;
proxy_pass http://192.168.222.168:9000;
proxy_set_header 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;
}

# Network Plugin Weiterleitung
location /shng {
auth_basic "Restricted Area: SmartHomeNG";
auth_basic_user_file /etc/nginx/.shng;
#proxy_pass http://<SmartHomeNG LAN IP>:<Network Plugin Port>/;
proxy_pass http://192.168.222.168:80;
proxy_set_header 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;
}
}

Dann kam noch mein kurzes Scheitern an der PasswortAbfrage (wegen dem fehlenden sudo), weshalb ich einen Reboot gemacht hatte, dann habe ich die Passwort-Files noch angelegt und dann versucht eine Verbindung herzustellen.

Ich hoffe, ich konnte es jetzt ein bisschen besser darstellen