Synology Synology und Ngnix Fehlermeldung

[borsel]

Hallo Leute,

ich hänge mich mal hier mit rein. Hoffe dass mein Problem hier hin passt. Ansosnten bitte gerne verschieben.

Ich habe mir vor kurzem den neuen CloudKey Gen 2 angeschafft. Darauf läuft jetzt die neueste Version des UnifiControllers bzw der SDN Controller. Bis auf die Tatsache, dass ich immer die "unsichere Verbindung"-Warnung bekam war alles super.

Mit dem hier beschriebenen Trick habe ich jetzt auch diese Warnung weg bekommen. Nutze also das in der Synology installierte SSL-Zertifikat und schalte diese per Reserve-Proxy davor. Soweit so gut .... vielen Dank für den Tipp hier !

Aber jetzt bekomme ich nach der Anmeldung natürlich die oben angesprochene Websocket Error Meldung ..... Würde auch diese natürlich noch gerne weg bekommen. Kann ich aber per o.g. Anleitung nicht, weil meine Synology nicht Ngnix als HTTP-Backend benutzt, sondern Apache 2.4. Muss auch so sein, weil sonst andere HTTP-Anwendungen nicht mehr laufen, die die Synology so betreibt .....

Jetzt weiß ich nicht wie ich diese Fehlermeldung weg bekomme, wenn ich Apache 2.4 weiterhin nutzen möchte. Einer von den Cracks hier evtl. eine Anleitung für mich?

 

[hot chili]

Gute Frage,
meine Vermutung ist, du meinst in der Web Station die Backend Einstellung?
In dem Fall bleibt Ngnix für den Reserve Proxy wohl weiter zuständig mit dem Code aus Beitrag #2 von oben kannst mal testen.

Du musst Regestriert sein, um das angehängte Bild zusehen.

Edit: Hauptbeitrag geändert mit der Lösung

 

[borsel]

Ja genau. In der Web Station hab ich Apache 2.4 eingestellt. Wie bei dir hier zu sehen ...

Okay, wenn Ngnix dann auch weiterhin für Reserve Proxy zuständig ist, mache ich die Eintragungen aus #2.

Wenn ich diese Eintragungen (so wie sie hier stehen, nix angepasst) in diese Datei eintrage und meine Synology neu starte .... tja, dann ist das Chaos perfekt. Keine meiner o. erwähnten Web-Anwendungen sind mehr erreichbar. Als ob die Webstation gar nicht mehr laufen würde ..... Sogar das DSM ist nicht mehr unter den eingestellten Port erreichbar .....

Muss ich die drei Zeilen irgendwo in Breich "location /" eintragen? Egal wo da ?

 

[hot chili]

Oha,

ja normal nur in eine neue Zeile der Datei /usr/syno/share/nginx/Portal.mustache unter location.
Aktuell bei mir ist so drin, nach irgend ein Update habe ich es dort wieder eingefügt:

Spoiler: code

{{#ReverseProxy}}
server {
    listen {{port}}{{#https}} ssl{{/https}}{{#https.http2}} http2{{/https.http2}}{{#reuseport}} reuseport{{/reuseport}}{{^fqdn}} default_server{{/fqdn}};
    listen [::]:{{port}}{{#https}} ssl{{/https}}{{#https.http2}} http2{{/https.http2}}{{#reuseport}} reuseport{{/reuseport}}{{^fqdn}} default_server{{/fqdn}};

    {{#resolver}}
    resolver {{resolver}};
    set $backend "{{backend}}";
    {{/resolver}}

    server_name {{#fqdn}}{{fqdn}}{{/fqdn}}{{^fqdn}}_{{/fqdn}};

    {{#https.profile}}
    ssl_protocols             {{protocols}};
    ssl_ciphers               {{ciphersuite}};
    ssl_dhparam               {{dhparam}};
    {{/https.profile}}

    {{#https.certificate}}
    ssl_certificate {{https.certificate}};
    {{/https.certificate}}
    {{#https.key}}
    ssl_certificate_key {{https.key}};
    {{/https.key}}

    {{#https.hsts}}
    {{> /usr/syno/share/nginx/HSTS}}
    {{/https.hsts}}

    {{#acl.rules}}
    {{#access}}allow{{/access}}{{^access}}deny{{/access}} {{address}};
    {{/acl.rules}}

    location / {
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 86400;
        {{#customize_header_variable}}
        if (${{&.}} = false) {
            set ${{&.}} '';
        }
        {{/customize_header_variable}}

        {{#advanced}}
        {{directive}} {{value}};
        {{/advanced}}

        {{#customize_headers}}
        proxy_set_header        {{&name}}            {{&value}};
        {{/customize_headers}}

        {{#resolver}}
        proxy_pass $backend;
        {{/resolver}}
        {{^resolver}}
        proxy_pass {{backend}};
        {{/resolver}}
    }

    {{#letsencrypt}}
    {{> /usr/syno/share/nginx/LetsEncrypt}}
    {{/letsencrypt}}

    {{> /usr/syno/share/nginx/error_page}}
}
{{/ReverseProxy}}

 

[borsel]

So, ich habs gerade nochmal manuell eingefügt. Direkt unter location / .... wie bei dir.

Und jetzt ist wieder nichts erreichbar, was über die WebStation läuft. Die Internetseite nicht, owncloud nicht mehr und auch der E-Mail Client nicht ..... zum verzweifeln hier !

 

[hot chili]

Und ohne den Eintrag läuft alles?

Die Klammern "{" und ";"
sind alle richtig?

Du bist auch weiter auf Apache 2.4 angeblich, oder bringt 2x umschalten auf Ngnix und zurück was?

 

[borsel]

Ohne Eintrag läuft alles perfekt. In der Web Station ist weiterhin Apache 2.4 eingestellt. Daran habe ich auch nichts geändert. Mache ich die Einträge rein, nichts mehr erreichbar was mit Web Station läuft.

Das mit dem Hin und Her Wechsel hab ich noch nicht probiert. Kann ich aber auch gerne noch probieren. Jedes Mal Neustart ???

 

[hot chili]

Neustart nicht. Nur das Ngnix irgendwie neu gestartet wird, anschubsen...

ngnix neu starten
dafür reicht eine Änderung in der Systemsteuerung/Netzwerk/DSM Einstellung

wie hier, kannst mal vergleichen ein Wert ändern:

Spoiler

Du musst Regestriert sein, um das angehängte Bild zusehen.

 

[borsel]

Also, wenn ich auf Nginx umstelle, sind der Owncloud und der E-Mail Client nicht mehr erreichbar. Laufen beide webbasiert. Da kommen von der Synology die Feherl 401 bzw. 404 ....

Stelle ich auf Apache 2.4 zurück, läuft alles wieder gut. Vll. sollten wir erstmal da ansetzen? Vll. ist da schon was falsch bei mir ....
Aber der Unifi Controller (der ja auf dem CloudKey ist) ist problemlos erreichbar - auch mit Nginx.

Jetzt müsste ich gleich nochmal die drei Zeilen einfügen und sehen wie es sich dann verhält wenn ich die Einstellung in der WebStation änder ....

Hier geht gaaaaar nichts. Wenn ich was anderes als Apache 2.4 auswähle geht gar nichts mehr.

 

[hot chili]

Ich habe auch einige Anwendungen laufen, die gehen auch nur mit Apache sauber.
Abgesehen von dem Reserve Proxy. Die richtige Datei wird es wohl sein die überarbeitest hast?

DSM 6.2.2-24922 Update 2
Web Station neuste
PHP 7.3 Edit

 

[borsel]

Ich denke Bilder sagen mehr als tausend Worte ...

Spoiler: Version DSM

Du musst Regestriert sein, um das angehängte Bild zusehen.

Spoiler: WebStation

Du musst Regestriert sein, um das angehängte Bild zusehen.

Spoiler: SSH angepasste Datei

Du musst Regestriert sein, um das angehängte Bild zusehen.

Was mache ich falsch? Kann mir irgendjemand irgendeinen Tipp geben?

Alles wie oben eingestellt. Daraufhin wollte ich die Änderung unter Netzwerk - DSM-Einstellungen vornehmen, damit die WebStation neu gestartet wird. Sobald ich die Änderung speichern möchte, meldet er "Operation fehlgeschlagen." Das deutet für mich darauf hin, dass ein Fehler in der Konfiguration vorliegt und der WebServer nicht neu gestartet werden kann. Bisher habe ich ja immer die gesamte Synology neu gestartet und dann ging nix mehr was die WebStation braucht ...

 

[Gatzi]

hab mal ein neues Thema draus gemacht!

 

[borsel]

Dankeschön, scheint ja doch in nen andere Richtung zu gehen ...

 

[hot chili]

Ich habe was gefunden, sehr hilfreich, seit DSM 6.2.1 ist bereits was vorbereitet:

Edit: Habe es jetzt getestet, scheint zu laufen.
Beim Speichern war er erst etwas zickig, ging aber beim dritten Versuch.

Spoiler: Meine DS

Du musst Regestriert sein, um das angehängte Bild zusehen.

 

[borsel]

Dieses Board ist sooooo geil ! Jeder hilft auf seinen Fachgebiet wo er kann. Vielen Dank dafür !

Ja, das ist die Lösung, die funktioniert. Sollte auf jeden Fall in den angepinnten Thread aufgenommen werden. Änderung per SSH scheint nicht mehr notwendig zu sein. Bei mir ist es jetzt jedenfalls perfekt! Vielen lieben Dank an alle - insbesondere an @hot chili :smiley:


Edit: @Moderatoren Habe gerade gesehen, dass der entsprechende Thread gar nicht angepinnt ist. Das sollte auf jeden Fall nachgeholt werden. Dabei geht es ja schließlich darum den Unifi Controller mit einer Synology per Reserve Proxy mit SSL abzusichern. Und als Lösung für die Websocket-Fehlermeldung sollte der Post #14 von hier mit angegeben werden!