ISPC 3, Wheezy & NGINX: Problem mit default Template

[JeGr]

Aloha,
in der Hoffnung, dass vielleicht @falko oder ein anderer Gleichgesinnter eine Antwort auf das Problem hat: Ich habe diverse VHosts, die mit einem CMS laufen, welches selbst Dateien wie sitemap.xml oder die robots.txt dynamisch ausliefern.
Das klappt nun aber mit ISPC3 nicht so ohne weiteres, da die Rewrite Regel auf die index.php ignoriert wird, da es vorher bereits einen location Block mit "location = /robots.txt" gibt, den NGINX dann direkt ausführt und alles andere ignoriert.

Meine Frage ist nun: kann man Webspace abhängig diese Default Blöcke ggf. überschreiben oder unterdrücken ohne direkt an das Template zu müssen? Generell sind die Default Einstellungen ja durchaus gewünscht und nützlich, in manchen Fällen aber auch hinderlich und nur mit der Option weitere Regeln zu schreiben nicht ohne weiteres zu lösen.

Jemand eine Idee?

Viele Grüße,
-jens

 

[nowayback]

schreib die regel, auch wenn sie schon existiert trotzdem in das nginx directiven feld und es müsste funktionieren.

 

[JeGr]

Hi @nowayback, das ist leider nicht der Fall, da es bei bspw. der robots.txt eine location = <file> Direktive ist. In der NGINX Engine Doku ist hier klar belegt, dass NGINX bei parsen einer solchen Location diese sofort ausführt und nicht auf eine andere wartet oder springt. Ein zweiter Eintrag mit dem gleichen Wert (= <file>) führt übrigens zu einem Error, da keine = Definition mehrfach vorkommen darf. Wäre es hier lediglich eine ~= oder eine Regex Location, wäre eine genaurere Definition möglich und würde die unschärfere "überschreiben".

 

[nowayback]

getestet?
falls das wirklich nicht funktioniert kannst du immernoch das template anpassen, welches ispconfig verwendet und den bereich rausnehmen. musst halt dann nur dran denken das du das in jeder website in den direktiven mit den angaben die du benötigst angibst.

 

[JeGr]

@nowayback nicht nur getestet, sondern vorher auch zur Sicherheit mein Wissen aufgefrischt und die NGINX Doku gelesen. Ja es geht nicht. Und das ist auch Absicht so wie es ist. Und den Block rausnehmen ist - wie du meinem OP entnehmen kannst - genau das was ich nicht will. Denn dann kann ich den Block für alle anderen dutzende Webspaces händisch nachpflegen, was gelinde gesagt unschön wäre. Von zeit- und fehleranfällig mal abgesehen. Und ich muss als Admin-User immer jeden Webspace anfassen, da die Reseller und Kunden keinen Zugriff auf die Server Optionen haben. Nope, Sorry, kein Bedarf. Ich bin froh, dass ich Reseller habe, da möchte ich nicht jeden derer Kunden anfassen müssen.

Für diesen Fall würde es reichen, wenn man die Chance hätte, einem Webspace ein custom-Template zuzuweisen, damit alle anderen auf Default bleiben. Alternativ eben Checkboxen wie bei custom-Error-Redirects.

 

[Till]

ISPConfig kann bestehende Blöcke mittels ##merge## keyword ändern, hab jetzt aber nicht getestet ob das in diesem Fall auch geht. Also sowas wie:

location = /robots.txt {##merge##
..... hier was neues ....
}

 

[JeGr]

Wow, absoluter Jackpot. Herzlichen Dank @Till - ich kann mich zwar nicht daran erinnern, das mal in der Doku gelesen zu haben, aber es macht genau das was es soll. Dein Beispiel so eingesetzt:

location = /robots.txt {##merge##
    rewrite ^/robots\.txt$ /index.php?seo42_func=robots last;
}

In diesem Fall gings tatsächlich um dynamisch erzeugte robots.txt die nun im CMS verwaltet werden können.

Besten Dank!