Amazon Alexa Plugin

[Cannon]

Ich hattee das schon produktiv im Einsatz mit upnpc

Das ist natürlich auch ein Weg. In der Fritz!box muss man dann natürlich noch einstellen "Selbstständige Portfreigaben für dieses Gerät erlauben.".

Ich werde das demnächst mal auch so testen. Dann stehen den automatischen Updates nichts mehr im Weg. :-)

[henfri]

Ich hattee das schon produktiv im Einsatz mit upnpc. Das ist auf Debian per apt verfügbar. Damit ist das ein Einzeiler an der Kommandozeile.

Aktuell mache ich allerdings

do_update_new.sh
#!/bin/bash
letsencrypt certonly --standalone --http-01-port 90 --preferred-challenges http  --config /etc/letsencrypt/cli.ini -d friedel.my-wan.de  #--webroot-path /var/lib/openmediavault/
service nginx restart

Zuvor

do_update.sh
#!/bin/bash
service monit stop
service nginx stop

#Need 443 and 80. 443 is always open for Alexa --> only need to open 80
echo "port 80 in Fritzbox öffnen"
upnpc -r 80 TCP #> /dev/null 2>&1
sleep 20
letsencrypt certonly --standalone #--http-01-port 443  #--webroot-path /var/lib/openmediavault/

upnpc -d 80 TCP # > /dev/null 2>&1

service nginx start

Gruß,
Hendrik

[Cannon]

man kann an der FB via TR-064 mittels curl aus der shell Ports freigeben und die Freigabe auch wieder entfernen. Siehe hier und hier.
Falls ihr hierzu eine Lösung realisiert wäre das sicherlich für alle interessant. Eventuell kann man hier auch was beim AVM-Plugin abschauen

Ich finde den Ansatz toll. Ich habe mir das angeschaut und das ist sicherlich umsetzbar. Ich werde mich damit demnächst mal beschäftigen und das testen.

[AndreK]

Hallo Jürgen, hallo Cannon,

man kann an der FB via TR-064 mittels curl aus der shell Ports freigeben und die Freigabe auch wieder entfernen. Siehe hier und hier.
Falls ihr hierzu eine Lösung realisiert wäre das sicherlich für alle interessant. Eventuell kann man hier auch was beim AVM-Plugin abschauen

Gruss Andre

[Jürgen]

Hallo Cannon,

"durch" kommst Du, wenn Du im NGINX eine Route definierst, z.B. auf Alexa oder die SmartVISU. Wenn der Proxy "aus" ist (restart), dann antwortet auch niemand auf Port 80, also kommt man nicht "überall ran". Nach meinem Weltbild kommst du mit einer Weiterleitung von Port80 auf den NGINX genau auf dessen Startseite.
Damit genug des Halbwissens, vielleicht kommt ja noch Input von einem Netzwerkprofi.

Gruß Jürgen

[Cannon]

ich bin da eher kein Fachmann

Ich leider auch nicht. Und mir ist nicht ganz klar, welches Problem da überhaupt auftreten könnte. Allerdings läuft mein NGINX auf dem gleichen Raspi, wie auch SmartHomeNG und auch die SmartVISU und da bin ich nicht sicher, ob es da Sicherheitsprobleme geben kann.

Aber wenn ich so darüber nachdenke ist ja der NGINX aus, während der Zertifikatsaktualisierung. Das heißt aber auch, dass nicht jeglicher Verkehr über den NGINX läuft, denn sonst würde sich das Zertifikat ja auch nicht aktualisieren lassen. Und somit käme man sicherlich auch mit Port 80 überall ran. Nur per SSL geht es durch den NGINX durch.

[Jürgen]

Hallo Cannon...

der geht auch auf den NGINX. Wenn der da ein Problem macht, dann ist die Weiterleitung des 443 auf den NGINX wohl ebenso gefährlich, oder?
Gerne lasse ich mir von einem Netzwerkspezi erklären, welches zusätzliche Risiko ich damit eingehe, ich bin da eher kein Fachmann..

Gruß Jürgen

[Cannon]

einen Cronjob erstellt, der das Zertifikat jeden Monat erneuern soll

Würde ich auch gern machen. Der Haken an der Sache ist aber, dass du dann Port 80 am Router ja immer offen lassen musst. Wie sicherst du den ab?

[Jürgen]

Hallo Cannon,

ja, der Restart ist wichtig. Ich habe mal nach
https://goneuland.de/certbot-lets-en...ian-9-stretch/
einen Cronjob erstellt, der das Zertifikat jeden Monat erneuern soll. Ich Berichte im September wieder, ob es geklappt hat.

Gruß Jürgen

[Cannon]

Das LetsEncrypt läuft wieder. Im Wesentlichen habe ich das nach der Anleitung hier gemacht, also ohne webroot usw. Wichtig ist in diesem Fall auch den NGINX-Service zu stoppen.

https://orioles.de/2019/02/21/zertif...aktualisieren/

[AndreK]

psilo Ist erledigt

[psilo]

henfri wieso, AndreK hat oben doch genatwortet

problem ist (gerade verifiziert), dass der link auf den supportthread in der plugin.yaml noch auf diesen thread HIER geht.. AndreK kannst du das korrigieren?

[henfri]

@psilo: dein zweiter Post ist wieder im falschen Thread gelandet.

[psilo]

ne der login klappt bei mir nicht mehr:

2019-08-09 06:17:41 ERROR plugins.alexarc4shng Login-State checked - Result: Logged OFF - try to login again
2019-08-09 06:17:41 ERROR plugins.alexarc4shng Login-State checked - Result: Logged OFF - try to login again
2019-08-09 06:17:44 ERROR plugins.alexarc4shng Login-State checked - Result: Logged OFF - try to login again
2019-08-09 06:17:44 ERROR plugins.alexarc4shng Login-State checked - Result: Logged OFF - try to login again
2019-08-09 06:17:45 ERROR plugins.alexarc4shng Login-State checked - Result: Logged OFF - try to login again
2019-08-09 06:17:45 ERROR plugins.alexarc4shng Login-State checked - Result: Logged OFF - try to login again

Evtl. weil ich den pycurl geupdated habe? welche version hast du? ich

7.43.0.3

wenn ich im browser bei alexa einlogge und das cookie kopiere, sieht das inzwischen auch komplett anders aus, als das was das plugin zieht. hmmm

nachdem ich jetzt in der weboberfläche von alexa war (da kam übrigens irgendeine meldung bzgl agb änderung oder sowas) und dann den CORE neu durchgestartet habe, geht es. davor hat jeder logout login versuch fehlgeschlagen.. ich beobachte weiter. könnte schon mit der meldung zu tun haben, die ich bestätigen musste.

[psilo]

keine ahnung wie openhab das macht, aber es muss doch so oder so einen callback ins heimnetzwerk geben. und da kommste um den reverseproxy mit basic auth nicht drumrum? und da würde ich individuelle credentials vorziehen