NGINX redirect für Photo Station

[OdinsAuge]

Ich nutze immer noch Apache, würde aber gerne auf nginx umsteigen.
Für die Photo Station habe ich ein redirect eingerichtet von sub.domain.com auf sub.domain.com/photo
Mit der .htaccess kein Problem. Jetzt wollte ich das über den nginx machen.
Ich habe in /usr/syno/share/nginx/WWWService.mustache folgendes eingefügt

server {
listen 443;
server_name sub.domain.com

location = / {
return 301 https://sub.domain.com/photo;

Leider bekomm ich aber nur Error 404 wenn ich sub.domain.com aufrufe.
Ich habe statt dem return auch rewrite / /photo; ausprobiert, selbes Ergebnis.

Wo liegt der Fehler?

 

[steffenms]

Ich habe aktuell das gleiche Problem.
Hast Du eine Lösung gefunden?

Ich würde mich sehr freuen, wenn Du hier weiterhelfen kannst.

 

[OdinsAuge]

Ich hab tatsächlich eine Lösung gefunden

Zuerst erstellst du die Datei /usr/syno/share/nginx/Photo.mustache mit folgendem Inhalt:

    server {
    listen 80;
    listen [::]:80;
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name <subdomain die du nutzen willst>;

    location = / {
        rewrite / https://$host/photo/ redirect;
    }

    include /usr/local/etc/nginx/conf.d/www.PhotoStation.conf;
}

Dann änderst du die Datei /usr/syno/share/nginx/nginx.mustache. Relativ weit unten stehen die Zeilen

 {{> /usr/syno/share/nginx/DSM}}
 {{> /usr/syno/share/nginx/WWWService}}

Und dort fügst du die Zeile ein

 {{> /usr/syno/share/nginx/Photo}}

Mit nginx -t testest du ob deine Config auch syntaktisch korrekt ist und mit synoservicectl --restart nginx startest du den nginx neu.
Jetzt sollte der redirect funktionieren.

 

[steffenms]

Vielen Dank für Deine Antwort.
Ich habe ebenfalls gerade eine eigene Lösung gefunden:

Ich bin mir nicht sicher wo das Problem liegt, aber ich gehe davon aus, dass nginx bei dem ursprünglichen Setup von OdinsAuge einen Ordner "photo" im root verzeichnis sucht, der nicht existiert.
Die Photo-Station ist nicht unter volume1/web/photo zu finden, sondern mittels eigenen nginx Regeln hinterlegt: /etc/nginx/conf.d/www.PhotoStation.conf
Darum muss man dafür sorgen, dass nginx auf den entsprechenden server block in der weiteren nginx configuration "weiterleitet".

Die nginx configurations die in /etc/nginx (symlink: /usr/local/etc/nginx) hinterlegt sind würde ich aber nicht anfassen. Die werden ggf. durch das System überschrieben.
Man kann aber weitere Dateien in /etc/nginx/sites-enabled anlegen, die dann entsprechend included werden.

Dort habe ich also eine photostation.conf Datei angelegt (Name und Endung sind egal):

#nginx configuration for Photo Station

#redirect any http to https
server {
    listen 80;
    server_name MyDomain.tld www.MyDomain.tld;
    return 301 https://$server_name$request_uri;
}

# redirect photostation domain to the photostation app
server {
    listen 443;
    server_name MyDomain.tld www.MyDomain.tld;

    location / {
        proxy_pass https://localhost/photo/;
    }

    location /photo/ {
        proxy_pass https://localhost/photo/;
    }
}

Damit werden alle anfragen an MyDomain an die photostation durchgeleitet.
Die Durchleitung an localhost sorgt dafür, dass im nächsten Schritt nicht mehr der nginx server block für MyDomain.tld, sondern der default nginx server block verwendet wird, welcher die location /photo dann entsprechend behandelt wie DSM und PhotoStation es eben definieren.
Ich bin mir nicht ganz sicher, weshalb die zweite location Regel notwendig ist, ohne funktioniert das setup allerdings nicht.

 

[steffenms]

Ich finde es sehr interessant wie beide unsere Lösungen eigentlich gut funktionieren.
Mich würde interessieren, ob es Nachteile bei der einen oder der anderen Variante gibt, oder ob eine eleganter ist.

Odins Lösung macht genau das, was ich ursprünglich vor hatte und auch meine .htaccess Lösung vorher gemacht hat:
Alle Anfragen an <subdomain> ob http (80) oder https (443) auf https://<subdomain>/photo umschreiben.
Das ist eine einfache und elegante Lösung.
Dann wird die configuration der PhotoStation included. Das sollte in Ordnung sein, solange sich der Ort und die Struktur der allgemeinen nginx Konfiguration in DSM in Zukunft nicht ändert.

Meine Lösung macht das ein bisschen anders.
Zuerst leite ich alle http Anfragen an <subdomain> auf https um (mittels eines permanenten 301 redirect).
Dann leite ich alle https Anfragen an <subdomain> an https://localhost/photo weiter.
Das sorgt dafür, dass der server block aus der standard nginx Konfiguration verwendet wird (in nginx.conf), der dann auch die www.PhotoStation.conf includiert.
Im Zweifel sollte dieses Setup robuster gegen Änderungen der nginx Konfigurations-Struktur sein. Ich meine, hier könnte die PhotoStation unter https://localhost/photo sogar unter einem anderen Webserver laufen.
Ich bin mir allerdings nicht ganz sicher, ob das mapping auf localhost nicht ein Sicherheitsproblem darstellen könnte.

Meine Lösung sorgt allerdings dafür, dass <subdomain>/#!Albums genauso gültig ist wie <subdomain>/photo/#!Albums. Um Links eindeutig und permanent wie möglich zu halten werde ich das in Zukunft unterbinden und teilweise Odins Lösung verwenden:

server {
    listen 80;
    listen [::]:80;
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name <subdomain>;

    location = / {
        rewrite /  https://$host/photo/ redirect;
    }

    location /photo/ {
        proxy_pass https://localhost/photo/;
    }
}

Ob der Eingriff in die mustache Konfiguration eleganter ist als das Hinzufügen in sites-enabled, kann ich nicht beurteilen.

 

[OdinsAuge]

Die Mustaches Dateien wurden in verschiedenen Foren empfohlen, speziell für die DiskStation auch im englischen Forum, leider sind die Details zur nginx-Konfiguration auf der DiskStation eher rar.

Es ist aber tatsächlich so, dass /usr/syno/share/nginx bei einem DSM-Update resetted wird. Das habe ich vergessen zu erwähnen. Danke für den Hinweis.
Ich habe eine Backup von Photo.mustache das ich nach dem Update wieder dort hin kopiere und die Zeile in der nginx.mustache trage ich dannach wieder ein.

Ich habe mittlerweile mehrere Änderungen in nginx/Apache/PHP die ein DSM Update nicht überstehen, ich hab eine Checkliste um nach dem Update wieder alles zum Laufen zu bekommen.

 

[KGBist2000]

Hi Zusammen,
ich hatte die Lösung mit der Photo.mustache und musste feststellen, dass das abspielen von Videos aus der Photostation über SSL (https://photo.domain.de) nicht möglich war. Es kam immer zum Fehler. Dann habe ich die Lösung über die *.conf Datei gemacht und siehe da nut geht wieder alles.

Hier mein Problem und Lösung:
https://www.synology-forum.de/showthread.html?101200-Photostation-Videos-lassen-sich-nicht-abspielen

Habt ihr das Problem mit den Videos auch, wenn ihr über Photo.mustache es löst?