ISPC 3, Wheezy & NGINX: Problem mit default Template

Dieses Thema im Forum "Installation und Konfiguration" wurde erstellt von JeGr, 7. Juni 2015.

  1. JeGr

    JeGr Member

    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
     
  2. nowayback

    nowayback Well-Known Member

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

    JeGr Member

    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".
     
  4. nowayback

    nowayback Well-Known Member

    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.
     
  5. JeGr

    JeGr Member

    @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.
     
    Zuletzt bearbeitet: 8. Juni 2015
  6. Till

    Till Administrator

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

    Code:
    location = /robots.txt {##merge##
    ..... hier was neues ....
    }
     
    robotto7831a und nowayback gefällt das.
  7. JeGr

    JeGr Member

    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:
    Code:
    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!
     

Diese Seite empfehlen