Alexa4p3 für Dummies

[AndreK]

Hallo,

ich bin ja eigentlich ein großer Freund der Vorgehensweise : Lesen - verstehen - dann danach handeln

Das hab ich hier komplett mißachtet

Onkelandy sitzt sicherlich "vor" dem "Arlberg" und lacht sich tot.


Man findet die entsprechenden Hinweise hier

Es gibt ein komplettes Setup-Script für den NGINX als reverse-proxy ist hier zu finden : /opt/setup/setup_nginx.sh
Ich muss mich doch mal intensiver mit dem Image beschäftigen - bevor ich hier versuche zu helfen und dann alles verschlimmere.

2malmama : Versuche es nochmal auf diesem Weg, gerne schicke ich Dir auch die Originaldateien (https.conf / default)

Wenn ich es richtig gesehen habe muss für das setup-Script Port 80 auf Deinen Rechner freigegeben sein ( Router -> smarthome-Raspi)

Gruss Andre

[2malmama]

also ich hab zwar jetzt folgende Ausgabe:

sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Aber intern erhalte ich beim Versuch auf die SmartVisu zuzugreifen noch immer Fehler 404 und von extern erhalte ich die Info, dass die Verbindung unerwartet geschlossen worden wäre.

Ich hatte vermutet, dass ich folgende Zeilen (natürlich nur die mit meinem Inhalt) entkommentieren müsste:

#ssl_certificate /etc/letsencrypt/live/DOMAIN_HERE/fullchain.pem;
#ssl_certificate /etc/letsencrypt/live/meinedomain.meindns.me/fullchain.pem;
#ssl_certificate_key /etc/letsencrypt/live/DOMAIN_HERE/privkey.pem;
#ssl_certivicate_key /etc/letsencrypt/live/meinedomain.meindns.me/privkey.pem;
#ssl_trusted_certificate /etc/letsencrypt/live/DOMAIN_HERE/fullchain.pem;
#ssl_trusted_certificate /etc/letsencrypt/live/meinedomain.meindns.me/fullchain.pem;

aber dann passiert das hier:

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.

und das hier:

sudo nginx -t
nginx: [emerg] unknown directive "ssl_certivicate_key" in /etc/nginx/conf.d/https.conf:44
nginx: configuration file /etc/nginx/nginx.conf test failed

Also habe ich die Zeilen wieder mit Kommentarzeichen versehen - dann gibt es zwar keine Fehler, aber es bleibt bei fehlender Verbindung.

[2malmama]

also hier klemmts dann doch noch mal.

Einerseits beim Anpassen der https.conf, noch immer so wie vorhin:

Bei der Anpassung der https.conf tu ich mir grad irgendwie schwer.

In Zeile 33 steht:
server_name DOMAIN_HERE;


das habe ich auskommentiert und meine persönliche Konfiguration hinterlegt:
server_name meinedomain.meindns.me;


Aber muss ich auch meinen IP-Adressbereich überall dazupflegen, also
allow 192.168.222.0/24;

Ist das richtig so und muss ich die Anpassung für meinen heimischen IP-Adressbereich einpflegen oder reichen die Angaben, die bereits hinterlegt sind (denn die 127.0.0.1 ist auch angegeben).

Ein

sudo systemctl restart nginx.service

ergibt keine Fehler, aber ich erreiche nur intern die 404 auf der SmartVisu.

Dann habe ich noch eine weitere Frage. Wir sind jetzt an dem Punkt, an dem wir festgestellt haben, dass ich die persönliche Conf-Datei überhaupt nicht brauche. Jedoch wird überall davon berichtet (auch in der Anwenderdoku https://www.smarthomeng.de/user/visu...rse_proxy.html, was sich ja gleicht mit: https://www.smarthomeng.de/user/visu...rse_proxy.html).

Wo hab ich den entscheidenden Hinweis übersehen, dass das alles unnötige Arbeit war? Oder gibt's dafür noch andere Gründe?

[2malmama]

sooo - ich hab noch einen Tippfehler hinter einem Strichpunkt eliminieren müssen - jetzt funktionieren

sudo nginx -t

(ohne Fehler) und ein Neustart mit

sudoy systemctl restart nginx.service

auch.

Intern erreiche ich die SmartVisu nicht - aber es kommt jetzt immerhin ein 404 Fehler. Extern geht nichts. Mein DNS-Anbieter verkündet mir jedoch wieder freien Zugang auf Port 80 und 443.

Ich sehe jetzt zu, dass ich die https.conf anpasse

[2malmama]

gefunden da war ein /etc/ zuviel!!

[2malmama]

soo - Vielen Dank Andre für die default aus sites-available sie gleicht meiner Datei mit der Ausnahme des hinzugefügten return 403 in Zeile 63

server {

listen 80 default_server;
listen [::]:80 default_server;
return 403;
include /etc/nginx/snippets/letsencrypt.conf;
root /var/www/html;

Ich hab noch mal geguckt - ich habe jetzt also in sites-available eine default liegen, genauso wie es in sites-enabled eine gibt.

Trotzdem gibt es sie angeblich nicht.....:

sudo ln -s /etc/nginx/etc/sites-enabled/default /etc/nginx/etc/sites-available/default
ln: die symbolische Verknüpfung '/etc/nginx/etc/sites-available/default' konnte nicht angelegt werden: Datei oder Verzeichnis nicht gefunden

default vorhanden.PNG

[2malmama]

nicht schlimm - passiert

Also - ich hab meine Conf-Datei jetzt verschoben (nach Windows)

Dann habe ich die default-Datei in der sites-available wieder hergestellt (hatte sie vorsichtshalber auch weggespeichert). Irgendwie fehlt mir jedoch die default-Datei aus sites-enabled. Ich schicke Dir gleich mal eine PN.

[AndreK]

Hallo nochmal,

der Fehler kommt daher, dass Deine "default" weg ist - mein Fehler.
Dort wird die Variable "websocket" definiert.

Falls Du die Datei benötigst kurze Info - dann schick ich Dir diese

Gruss Andre

[wvhn]

Bedeutet das, dass ich diese Datei jetzt auch anpassen muss?

Nein, aber dort wird gezeigt, was im Image schon alles vorbereitet ist.

Gruß
Wolfram

[AndreK]

Hello again,

neues Image läuft - Da hab ich Dich in ein Sackgasse geschickt

Es ist wie vermutet, die Datei https.conf ist vorbereitet, es müssen hier lediglich die entsprechenden Einträge angepasst werden. Das


Weitere Vorgehensweise :

1.) Verschieben Deiner erstellten /etc/nginx/conf.d/"mydomain"."mydns"."me".conf in ein anderes Verzeichnis (Windows-Rechner ?)
2.) wieder herstellen der default-Dateien

Es muss in /etc/ngix/sites-available eine Datei "default" geben ; Falls wir diese gelöscht haben kurze PN mit Deiner Mailadresse dann schicke ich Dir diese
Falls die Datei vorhanden ist, muss in /etc/nginx/sites-enabled ein Symlink auf diese Datei stehen.
Falls dieser nicht vorhanden ist kann man in mit

sudo ln -s /etc/nginx/etc/sites-enabled/default /etc/nginx/etc/sites-available/default

erstellen.

3.) Neu Test mit sudo nginx -t -> Das sollte keine Fehler mehr schmeissen
4.) NGINX neu starten -> sudo systemctl restart nginx.service

Wenn der nginx dann wieder läut die https.conf entsprechend anpassen (vorher vielleicht eine Sicherung machen)

Im Ansible Playbook musst Du nichts ändern -> Das ist alles OK

Gruss Andre

[2malmama]

Ja, den Symlink hatte ich gelöscht.

Unter sites/available sind keine Dateien enthalten, in sites-enabled folgende:

enabled dateien.PNG
Bei der Anpassung der https.conf tu ich mir grad irgendwie schwer.

In Zeile 33 steht:

server_name DOMAIN_HERE;

das habe ich auskommentiert und meine persönliche Konfiguration hinterlegt:

server_name meinedomain.meindns.me;

Aber muss ich auch meinen IP-Adressbereich überall dazupflegen, also

allow 192.168.222.0/24;

Ich habe es erst mal weggelassen.

Wenn ich nun sudo nginx -t ausführe, bekomme ich einen Fehler zum Websocket:

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

In der https.conf steht an dieser Stelle

proxy_pass http://websocket;

Da habe ich nichts verändert.

Onkelandy weist immer mal wieder darauf hin, dass man sich auf github im ansible branch die Details ansehen kann, wie die Konfiguration des Images läuft. Für nginx ist das hier.

Bedeutet das, dass ich diese Datei jetzt auch anpassen muss? Hier war bisher meines Erachtens noch gar keine Rede von Sorry, an mancher Stelle verwirrt das von Zeit zu Zeit ganz schön....

[wvhn]

Moin,
meine Gedanken sind in die gleiche Richtung gegangen. Onkelandy weist immer mal wieder darauf hin, dass man sich auf github im ansible branch die Details ansehen kann, wie die Konfiguration des Images läuft. Für nginx ist das hier.

Danach sehe ich es auch so, dass nur die https.conf benötigt wird.

Am besten von allem Sicherheitskopien auf dem Windows-Rechner machen, so dass man auch wieder Schritte zurück gehen kann.

Gruß
Wolfram

[AndreK]

Hallo 2malmama ,

es fiel mir glaube ich gerade wie Schuppen von den Augen. Wir sollten nochmal 2 Schritte zurückgehen.

1.) Hattest Du eine Datei oder symlink "default" gelöscht ?
2.) Das ist der wichtigere Punkt - Da ja vor den Anpassungen der NGINX bereits auf Port 80 und 443 gelauscht hat. Ist die Config für Port 443 sicherlich in der https.conf
Das würde heißen, Du benötigst keine "neue" Datei mit "/etc/nginx/conf.d/<mydomain>.<myds>.<me>.conf" sondern musst die https.conf mit Deinen Angaben ergänzen
3.) Versuche mal Deine /etc/nginx/conf.d/<mydomain>.<myds>.<me>.conf" in ein anderes Verzeichnis zu verschieben -> dann Neustart des Nginx bzw sudo nginx -t
4.) Prüfe bitte nochmal welche Dateien unter "/etc/nginx/sites-available" liegen
5.) Prüfe bitte nochmal welche Dateien unter "/etc/nginx/sites-enabled" liegen

Ich denke wir kommen der Sache dann näher, ich werde mir parallel mal noch einen Rechner mit dem Image hochziehen, dann sehe auch klarer.

Gruss Andre

[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

[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