Ankündigung

Einklappen
Keine Ankündigung bisher.

SmarthomeNG v1.9.5 Image für Raspberry Pi

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

    #31
    Schau mal, wie die Fehlermeldung vollständig lautet und ob sie aus dem Browser oder aus der Visu kommt.

    Wenn sie aus dem Browser kommt, hat die Erstellung des Zertifikates nicht geklappt. Evtl. hast Du nur ein “selbsterstelltes“ Zertifikat, d.h. ohne Anbindung an ein CA-Zertifikat. Das musst Du dem Browser noch bekannt machen.

    Wenn die Meldung aus der Visu kommt (Oberfläche wird angezeigt, aber Fehler in der Websocketverbindung), dann poste mal die Einstellungen für das Backend aus der config.

    Gruß
    Wolfram

    Kommentar


      #32
      Hallo Wolfram, wie die Fehlermeldung wörtlich war kann ich erst morgen gucken.
      Beim Zertifikat erstellen ist aber irgendetwas schief gegangen, ich denke es waren zu viele Zugriffe in kurzer Zeit.
      Aber warum kann ich nach dem Abschalten von nginx und damit ja auch den Reverse Proxy trotzdem nicht mehr auf die Seiten zugreifen?

      Kommentar


        #33
        Wenn Du nginx abgeschaltet hast, hast Du den Webserver abgeschaltet, der die Visu Seiten ausliefert.
        Du musst dann einen anderen Webserver (Apache) konfigurieren.
        Viele Grüße
        Martin

        There is no cloud. It's only someone else's computer.

        Kommentar


          #34
          Im Image ist nur nginx als Webserver installiert. Schau mal hier: https://github.com/smarthomeNG/ansib...aster/raspbian
          Da findest du die Original Config File, vielleicht reicht es, die einfach anzupassen und neu einzuspielen..?

          Kommentar


            #35
            Ich bekomme das mit nginx irgendwie nicht mehr auf die Kette.

            Neimmerstellen des Reverse Proxy’s ist das erstellen des letsenctypt Zertifikat fehlgeschlagen und danach ging garnichts mehr. NGINX startet nicht mehr und damit können auch keine Webseiten mehr angezeigt werden.

            Nachdem ersetzen der https.conf durch die originale Config Datei läuft nun Nginx wieder aber jetzt halt immer noch ohne Reverse Proxy.

            Code:
             nginx.service - A high performance web server and a reverse proxy server
                 Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
                Drop-In: /etc/systemd/system/nginx.service.d
                         └─service_nginx_fix.conf
                 Active: active (running) since Tue 2023-09-26 17:10:34 CEST; 2min 38s ago
                   Docs: man:nginx(8)
                Process: 1867 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, s>
                Process: 1868 ExecStartPre=/opt/dnsresolvers.sh (code=exited, status=0/SUCCESS)
                Process: 1875 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/S>
               Main PID: 1876 (nginx)
                  Tasks: 6 (limit: 3932)
                 Memory: 15.0M
                    CPU: 630ms
                 CGroup: /system.slice/nginx.service
                         ├─1876 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
                         ├─1877 nginx: worker process
                         ├─1878 nginx: worker process
                         ├─1879 nginx: worker process
                         ├─1880 nginx: worker process
                         └─1881 nginx: cache manager process
            ​
            Zuletzt geändert von schuma; 27.09.2023, 07:29.

            Kommentar


              #36
              Jetzt habe ich wieder eine Nacht mit den Versuchen verbracht ein Zertifikat zu erstellen und scheitere einfach nur noch

              Vielleicht kann mich noch mal jemand unterstützen.
              Ausgangslage war, eine Image auf einem Pi von vor ganz langer Zeit das aber immer uptodate nachgezogen wurde. Also aktueller Stand von SmarthomeNG und SmartVisu. Inklusive lauffähigem NGiNX mit Reverse Proxy.

              Dann eine neue ssd genommen das aktuelle Image drauf und versucht mit Setup_all den Reverse Proxy mit letsencypt Zertifikat zu aktivieren.
              Das neue Ssd Image hat die selbe IP bekommen wie das alte Image, und auch der Hostname (DynDNS) wird weiterhin so benutzt wie vorher.
              Damit sind alle Weiterleitungen in der Firewall unverändert und sollten Ihren Dienst tun. NGinx ist über Port 80 erreichbar.

              was aber eben nicht funktioniert ist, dass erstellen eines Letsenctypt Zertifikats. Und da kann ich mich auf den Kopf stellen es wird einfach nicht erzeugt.

              Kann sich hierauf jemand einen Reim machen?

              Grüße, Marc

              Kommentar


                #37
                Und wie es der Teufel gerade will, konnte ich gerade mit:

                Code:
                sudo certbot certonly --rsa-key-size 4096 --webroot -w /var/www/letsencrypt -d <HOSTNAME>
                ein Zertifikat erfolgreich erstellen. Warum jetzt und in den 12 Stunden davor, keine Ahnung…. Mal gucken ob es jetzt weiter geht.

                Kommentar


                  #38
                  So, ich habe es jetzt hinbekommen…
                  das Zertifikat konnte ich ja heute Morgen komischer Weise einfach erstellen. (Muss man wohl nur 30x probieren damit es klappt;-) )

                  Dann habe ich noch händisch meinen Hostnamen überall in die https.conf eingetragen.

                  und In der https.conf die beiden Authentifizierungseinträge in der Alexa Section einkommentiert.

                  Damit läuft nun wieder alles. Puhhhh…

                  Onkelandy kann man diese Einstellungen nicht mit in der Setup_all Routine machen?
                  Also Hostname in die Conf Datei und fragen ob Alexa benutzt wird und dann die Auth Einträge einkommentieren?

                  Kommentar


                    #39
                    Das hier wird im Script gemacht:
                    echo "Changing nginx config based on domain $domain"
                    sudo sed -i 's/'DOMAIN_HERE'/'${domain}'/g' /etc/nginx/conf.d/https.conf 2>&1
                    sudo sed -i 's/'DOMAIN_HERE'/'${domain}'/g' /etc/nginx/sites-available/default 2>&1​

                    Klappt das nicht?

                    Ad Alexa.. die Auth Einträge gehören auskommentiert, wenn man Zertifikate nutzt oder verstehe ich dich falsch..? Meiner Meinung nach muss da nix geändert werden: https://github.com/smarthomeNG/ansib...inx_https.conf

                    Kommentar


                      #40
                      Also bei mir hat sich da Nix geändert.
                      Kann ja aber auch durch das nicht richtig durchlaufen mit dem Zertifikat kommen. Was mir immer noch unerklärlich bleibt.
                      Da stand dann Teilweise immer noch $Hostname
                      und weiter unten das „DOMAIN_HERE“ wurde entfernt. Also stand da nur noch „….live//…“

                      Bei Alexa müssen die Auth Einträge einkommentiert sein, da Amazon die User:Pass übergibt und fordert (AWS).

                      Grüße, Marc

                      Kommentar


                        #41
                        $hostname sollte imho auch bleiben. Das DOMAIN_HERE hätte durch die angegebene Domain ersetzt werden sollen. Vielleicht kannst du nochmals testen (davor Config sichern )
                        Ad Alexa: Hier müsste man beim Setup dezidiert nach User und PW für Amazon fragen, oder? Das müsste dann in /etc/nginx/.alexa eingetragen werden und die 2 Comments müssten "weg".,..?

                        Kommentar


                          #42
                          Ich hatte das ja schon x mal getestet. Immer mit dem selben Ergebnis. Auch nachdem ich erfolgreich ein Zertifikat auf der Kommandozeile erstellen konnte. Wobei ich es auch nie hinbekommen habe ein Zertifikat aus dem Setup_all Prozess zu erstellen. Ein selbst erstelltes Zertifikat ( Auf der Kommandozeile) hat dann heute zum Erfolg geführt.

                          Das von dir beschriebene zu Alexa ist so genau richtig. User : Pass wird im AWS in den Umgebungsvariablen eingetragen. Kann man ja noch mal als Hinweis hinzufügen.

                          Kommentar


                            #43
                            Zitat von schuma Beitrag anzeigen
                            User : Pass wird im AWS in den Umgebungsvariablen eingetragen. Kann man ja noch mal als Hinweis hinzufügen.
                            Wie meinst du das..? Könnte man das aus einem File auslesen? Bzw. wenn man's neu initialisiert und eh schon die Daten über das setup_all angibt, gleich noch in eine andere Datei schreiben außer in die nginx config?

                            Kommentar


                              #44
                              Nein, das passiert dann im AWS, also bei Amazon.

                              user : pass das bei Amazon in den Umgebungsvariablen eingetragen ist muss dann auf dem PI in die Datei .alexa

                              Kommentar


                                #45
                                Servus,
                                ich bin Anfänger und habe as image installiert. habe ich nicht das klassische Betriebssystem mit Desktop Oberfläche?
                                bei mir befindet sich mit dem Image alles auf Kommando Editor ebene.

                                Viele Grüße
                                WuTang

                                Kommentar

                                Lädt...
                                X