Ankündigung

Einklappen
Keine Ankündigung bisher.

Amazon Alexa Plugin

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • henfri
    antwortet
    Mensch, hier ist es aber still geworden.

    Einen Kommentar schreiben:


  • henfri
    antwortet
    P.s: danke für das tolle Plugin

    Einen Kommentar schreiben:


  • henfri
    antwortet
    Hallo,

    so, ich habe jetzt alles soweit eingerichtet (das Weiterleiten der Domain funktioniert übrigens nicht); ich habe direkt die myfritz Adresse angegeben.

    Das Plugin startet und meldet sich:
    Code:
    2016-12-07 20:30:50 WARNING device alexa Alexa-Device wohnzimmer-lampe: empty description, fallback to name 'Wohnzimmer Lampe' - please set `alexa_description` -- device.py:validate:80
    2016-12-07 20:30:50 INFO service alexa Alexa: service starting -- service.py:start:27
    Wenn ich jetzt aber sage "Alexa schalte die Wohnzimmer Lampe an", bekomme ich die Antwort:
    "Sorry ich konnte kein Gerät bzw. keine Gruppe mit dem Namen Wohnzimmer Lampe in Hendriks Konto finden".

    Müsste ich im Log mehr sehen?
    Ich sehe z.B. nicht, wie das Plugin Geräte/Gruppen bei Alexa anmeldet, oder wie Alexa sich beim Plugin meldet.

    Beim Zugriff per https://mydom.myfritz.net:444 erhalte ich:
    Code:
    Error response
    
    Error code: 501
    
    Message: Unsupported method ('GET').
    
    Error code explanation: 501 - Server does not support this operation.
    In der Konsole (aws.amazon.com) zur Lambda Funktion sehe ich, dass die Funktion bisher zehn mal aufgerufen wurde. Davon zehnmal mit "invocation error".

    Jetzt läuft es. Ich hatte wohl ein Problem mit dem .htpasswd. In der Anleitung steht, man solle es mit openssl erzeugen. Das erzeugt aber bei jedem aufruf ein anderes Passwort. So funktioniert es:
    htpasswd -c htpasswd.alexa henfri

    Gruß,
    Hendrik
    Zuletzt geändert von henfri; 07.12.2016, 21:18.

    Einen Kommentar schreiben:


  • henfri
    antwortet
    Moin,

    wir wollen doch etwas allgemein-taugliches, oder?

    Eine eigene Domain habe ich auch. Sollten wir aber nicht voraussetzen (Davon ab, kann ich meine nicht für Dyndns nutzen; Die Variante von Hotzen könnte ich aber gehen. Geht die ursprüngliche Domain/Subdomain beim Weiterleiten nicht verloren? d.h. Sieht der Nginx die noch?).

    Aber nochmal: John Doe hat keine Domain. Daher hielte ich es für besser, über den Port zu gehen, statt über eine Subdomain. Spricht da etwas gegen?
    Oder andersrum: Was spricht für die Subdomain?

    Davon abgesehen nochmal die Frage: Was spricht für einen Reverse-Proxy und was spricht gegen SSL im Plugin?

    Gruß,
    Hendrik

    Einen Kommentar schreiben:


  • jonofe
    antwortet
    ich nutze auch StartSSL für SMTP und letsencrypt für HTTPS. Funktioniert super und sollte machbar sein.

    Neben einer Enterprise Firewall gibt's auch ganz nette Router für den ambitionierten Home User, z.B. sowas hier ...

    13252-717-hi-res.png

    https://shop.omg.de/mikrotik/integra...as-rm/a-13252/

    Preis-/Leistungsverhältnis ist aus meiner Sicht super, allerdings auch nichts für Netzwerkeinsteiger.
    Angehängte Dateien

    Einen Kommentar schreiben:


  • patrickgoll
    antwortet
    Das wäre meiner Meinung nach das Setup für den Privatmann. Das kann man bewerkstelligen. Mein Setup ist kompliziert wegen meiner Enterprise Firewall, aber das muss ja auch nicht sein.

    Einen Kommentar schreiben:


  • hotzen
    antwortet
    Mein setup:
    - myfritz dyndns service
    - eigene Domain
    - subdomain foo.Domain.tld und Wildcard *.foo.domain.tld forwarded/aliases auf foo. myfritz. net

    den Router würde ich bspw per Router.foo.domain.tld per reverse proxy ansprechen wollen. Dann Alexa.foo.domain.tld auf smarthomeNG etc pp

    ssl per letsencrypt, das wird von allen Browsern anerkannt, ist in 3 Minuten setupd und in der nginx.md beschrieben - so großartig dass es Mittlerweile so einen Dienst gibt
    Zuletzt geändert von hotzen; 07.12.2016, 10:14.

    Einen Kommentar schreiben:


  • patrickgoll
    antwortet
    Ich für meinen Teil habe eine Domäne bei Strato für ein paar Euro im Monat mit 2 Domains und 500 Subdomains. DNS macht also bei mir Strato. Meine Sophos UTM gibt Strato dann als DynDNS Client Updates über IP Änderungen meines Providers. Außerdem habe ich ein StartSSL Zertifikat mit 5 Subdomains als extra DNS. StartSSL ist halt gut, weil jeder Browser standardmäßig das Root Zertifikat als vertrauenswürdig einstuft.

    Einen Kommentar schreiben:


  • henfri
    antwortet
    Moin,

    das heisst aber, dass ich entweder mehrere dyndns accounts brauche (alexa_henfri.dyndns.org, visu_henfri.dyndns.org, ...), oder einen Dyndns-Anbieter der Wildcards/Sub-Subdomains unterstützt, richtig?

    Wie macht ihr das? myfritz unterstützt das nicht (und wäre nachdem andere Anbieter nach und nach nicht mehr kostenfrei sind zu bevorzugen).

    Davon abgesehen, zur Sicherheit:
    Wenn das Plugin direkt https nutzen würde, hätten wir die gleiche Sicherheit, oder?

    Gruß,
    Hendrik

    Einen Kommentar schreiben:


  • hotzen
    antwortet
    indem du *.smarthome.dyndns.foo auf deine IP zeigen lässt. Der Wildcard alias mit * macht die Musik.
    und dann wie von jonofe erklärt, der reverse proxy verteilt dann per verwendetem dns Namen an den richtigen host.

    sorgt für Sicherheit per sicherem Kanal ssl/tls und zentraler Authentifizierung, z.b.auch per client Zertifikat.

    Ist jetzt natürlich erstmal keine inspecting Firewall oder so aber das geht auch, wenn du wie patrickgoll statt nur eines reverse proxys ne web application firewall verwendest

    Einen Kommentar schreiben:


  • jonofe
    antwortet
    das geht über verschiedene DYNDNS Einträge, die alle auf deine öffentlich IP verweisen. Da läuft dann der reverse proxy. Somit gibt es keine Verbindung von externen Rechnern auf deine internen, sondern nur auf deinen reverse proxy. Idealerweise ist der reverse proxy hinter deinem DSL router und dann noch ne firewall zum internen Netz. Aber auch so werden deine internen Rechner nur vom Reverseproxy kontaktiert. Der Rechner auf dem der Reverse Prox läuft sollte dann sehr sicher konfiguriert sein, d.h. minimale Services aktiviert. Selbst wenn dann jemand auf diesen Rechner kommt, dann hat er immer noch keinen Zugriff auf die internen.

    Einen Kommentar schreiben:


  • henfri
    antwortet
    P.s.: wie steigert der Proxy die Sicherheit?

    Einen Kommentar schreiben:


  • henfri
    antwortet
    Und "das Internet" weiss, dass
    a.meine.domain
    b.meine.domain
    Und
    meine.domain

    Unter der gleichen IP erreichbar sind?

    Im Heimnetz funktioniert das ja nicht.
    Der Server ist nur unter Homeserver, nicht aber unter a.homeserver und b.homeserver erreichbar.

    Gruß,
    Hendrik

    Einen Kommentar schreiben:


  • jonofe
    antwortet
    Das macht doch genau ein reverse proxy. Von außen connectest du immer zur selben IP, allerdings mit unterschiedlichen DNS Namen. Der Reverse Proxy verteilt dann diese Anfragen auf die richtigen internen Rechner. Bei apache sind es die ProxyPass und ProxyPassReverse Statements, sowie der ServerName des jeweiligen Virtualhosts.

    Einen Kommentar schreiben:


  • henfri
    antwortet
    Moin,

    noch eine Frage zum Reverse-Proxy:
    Port 443 ist von meinem Router Belegt --> In der Lambda-Funktion wähle ich Port 444. Im Router forwarde ich Port 444 auf den Server, port 444 (es ginge auch 443)

    Woher weiß nun alexa/der Browser/wer auch immer, dass zur alexa.meine_id.myfritz.net der Rechner, auf den ich forwarde gehört?
    Muss ich dafür nicht den DNS anpassen?
    Du hast ja auch ein Beispiel für einen zweiten Service (ANOTHER-SERVICE.YOUR-HOME.DYNDNS.TLD) in der Konfiguration. Darunter würde ich gerne die Smartvisu erreichbar machen.
    Extern also smartvisu.meine_id.myfritz.net (hm.... eigentlich will ich das doch nicht. Aber mal angenommen) und intern (und das ist der eigentliche Usecase) smartvisu.fritz.box (oder smartisu.homeserver?)

    Da bin ich jetzt ein wenig verwirrt.

    Gruß,
    Hendrik

    Einen Kommentar schreiben:

Lädt...
X