[ERLEDIGT] DOCUMENT_ROOT stimmt nicht. Rewrite(?) statt VHosts! Ernstes Problem!

    Beim Umzug einiger Freiwilliger Nutzer von Confixx auf LiveConfig bin ich heute mehrfach auf ein schweres Problem gestossen.


    Da Sub-Domains in LiveConfig über RewriteRegeln realisiert werden, bleibt das DOCUMENT_ROOT gem. des Pfades in der VirtualHost-Section des Nutzers stehen.


    Confixx hingegen (und anders kenne ich es gar nicht) erstellt vhosts für die Sub-Domänen. Diese haben dann entsprechend in DOCUMENT_ROOT ihr unter DocumentRoot gesetztes Verzeichnis stehen.


    Es gibt jede Menge Anwendungen, die DOCUMENT_ROOT nutzen. Es entstehen erhebliche Probleme, wenn eine solche Anwendung aus einem vhost-Unterverzeichnis auf ein rewrite-Unterverzeichnis verschoben werden.


    Auf dem Server, der zuerst komplett auf LiveConfig migriert werden soll, gibt es 445 SubDomains.


    Diese Suche:

    Code
    find /var/www/ -type f -name *.php | grep "/html/" | xargs -i egrep -l -e DOCUMENT_ROOT '{}' | wc -l


    wirft 174 PHP-Dateien, die irgendwo DOCUMENT_ROOT nutzen.


    So kann ich meinen Umzugsplan erst mal streichen.


    Gibt es einen Workaround oder ist es nicht sinnvoller für Sub-Domänen ebenfalls VirtualHost zu benutzen?


    Ich hoffe auf eine schnelle Antwort, denn es brennt! :/


    Schönen Sonntag,


    Oskar

    Computer sind unglaublich dumme Geräte,
    die unglaublich intelligente Sachen können.
    Programmierer sind unglaublich intelligente Leute,
    die unglaublich dumme Sachen produzieren.
    ("Die Presse", 30.8.1999)

    Hallo Herr Groh,


    nun - "Problem" ist relativ, und über die eigentliche Ursache lässt sich vermutlich vortrefflich streiten. Im Grund ist es nämlich "suboptimal", in einem PHP-Script aus DOCUMENT_ROOT irgend etwas anderes auslesen zu wollen als das Webspace-Startverzeichnis (DocumentRoot-Einstellung in Apache). Denn auf diese Weise kann ein Script nicht in ein beliebiges Unterverzeichnis verschoben werden, selbst wenn DOCUMENT_ROOT auf das Startverzeichnis der tatsächlich aufgerufenen Domain verweist.
    Um absolute Verzeichnisnamen zuverlässig und unabhängig von jeglicher Serverkonfiguration auszulesen, sollte idealerweise die Variable SCRIPT_FILENAME genutzt werden:

    Code
    $path = basename($_SERVER['SCRIPT_FILENAME']);


    Das nächste Problem sehe ich nämlich auch schon: in dem von Ihnen verwendeten grep-Ausdruck suchen Sie nach /html/ - in LiveConfig liegen die Webspace-Verzeichnisse in ~/htdocs/ (statt ~/html/). Das ließe sich aber auch anpassen.


    Wir verstehen LiveConfig nicht als 1:1-Ersatz für Confixx, da unserer Meinung nach die damit erzeugten Konfigurationen nicht unbedingt ideal sind; daher wird LiveConfig also auch nicht "identische" Konfigurationen erzeugen.


    Konkret gibt es für die vorliegende Fragestellung zwei Lösungen:
    Variante 1: Kunden erziehen:
    Das sich das Controlpanel ändert wird den Kunden vermutlich nicht entgehen (i.d.R. ändern sich ja einige Daten, u.a. die Controlpanel-URL, die Einstellungsmöglichkeiten, etc.). Im Rahmen eines Rundschreibens an die Kunden könnte man darauf hinweisen, dass aufgrund der neuen Konfiguration ein paar Dinge zu beachten sind - dort könnte man dann u.a. auf die Vorteile von SCRIPT_FILENAME ggüber DOCUMENT_ROOT hinweisen.
    Außerdem könnte man (wie auch oben schon gezeigt) mit grep betroffene Kundenscripts identifizieren und die Kunden informieren (am besten schon vor dem Umzug ;)


    Variante 2: Konfiguration anpassen:
    Mit folgenden Änderungen wird DOCUMENT_ROOT für PHP-Scripte angepasst:

    1. Erzeugen Sie eine Datei namens /usr/lib/liveconfig/document_root.inc.php mit folgendem Inhalt:

      PHP
      <?php
  if (isset($_SERVER['DOMAIN_ROOT'])) {
    $_SERVER['DOCUMENT_ROOT'] = $_SERVER['DOMAIN_ROOT'];
  }
?>


    2. Erzeugen Sie eine Datei namens /etc/php5/conf.d/liveconfig.ini mit folgendem Inhalt:

      Code
      auto_prepend_file=/usr/lib/liveconfig/document_root.inc.php


    3. In der Datei /usr/lib/liveconfig/lua/apache.lua suchen Sie die Zeile mit folgendem Inhalt (ca. Zeile 1716):

      Apache Configuration
      fh:write("        RewriteRule ^/(.*)       ", string.gsub(opts.path .. "/htdocs/" .. key, " ", "\\ "), "/$1 [L]\n\n")


      Ändern Sie darin den Eintrag "[L]" in das hier um:

      Code
      [L,E:DOMAIN_ROOT=',opts.path,'/htdocs/',key,']



    Sobald nun an einer vHost-Konfiguration eines Kunden irgendwas geändert wird (oder an den verwendeten Hostingangeboten, was zu einer Aktualisierung der vHosts führt), wird künftig automatisch die Variable DOMAIN_ROOT gesetzt. Durch das auto_prepend in der php.ini wird diese dann in DOCUMENT_ROOT übernommen.
    Dieser Workaround funktioniert eigentlich reibungslos, gilt aber nur für PHP-Scripte.
    Wenn Bedarf besteht, können wir die DOMAIN_ROOT-Umgebungsvariable auch standardmäßig setzen lassen (also ohne dass man die apache.lua anpassen muss)


    Für eine Änderung von ~/htdocs/ in ~/html/ gibt es in Kürze noch eine bequeme Konfigurationsmöglichkeit über die custom.lua


    Als "Worst-Case-Alternative" könnte die apache.lua auch so angepasst werden, dass tatsächlich für jede Subdomain ein eigener <VirtualHost>-Abschnitt erzeugt wird - das bläst aber schnell die Apache-Konfiguration auf.


    Viele Grüße & schönen Sonntag


    -Klaus Keppler

    Hallo Herr Keppler,


    erst einmal vielen Dank für die ausführliche Antwort.


    Das stimmt. Da kann man sich streiten, müssen wir aber nicht! Ich denke, Sie haben sich dabei etwas gedacht, als Sie statt VirtualHosts die Rewrite-Lösung gewählt haben. So ganz ist das zwar noch nicht mein Freund, da mit VirtualHosts auch spezielle Berechtigungen für eben diesen zu realisieren wären, aber was soll's.


    Zitat

    Das nächste Problem sehe ich nämlich auch schon: in dem von Ihnen verwendeten grep-Ausdruck suchen Sie nach /html/ - in LiveConfig liegen die Webspace-Verzeichnisse in ~/htdocs/ (statt ~/html/). Das ließe sich aber auch anpassen.


    Glauben Sie's oder glauben Sie's nicht, das ist mir schon aufgefallen! ;) In html zu suchen macht allerdings bei Confixx deutlich mehr Sinn, denn so schließe ich die Nebenverzeichnisse bei der Suche aus. Es interessiert mich nämlich nur, was der Kunde online hat und nichts anderes. Für die Konvertierung habe ich schon entsprechend hübsche sed-Konstrukte gebaut, die duch alle Dateien des Kunden rennen und alte Pfade gegen neue tauschen, alte Datenbank- und Nutzernamen gegen neue, sowie alle Vorkommen von Server-Namen von alt auf neu. Und diese Skripte funktionieren prima. Das ist also nicht das Problem. Nutzt der Kunde kein DOCUMENT_ROOT, laufen seine Webs sofort und ohne weitere Anpassungen durch den Nutzer.


    Zitat

    Wir verstehen LiveConfig nicht als 1:1-Ersatz für Confixx, da unserer Meinung nach die damit erzeugten Konfigurationen nicht unbedingt ideal sind; daher wird LiveConfig also auch nicht "identische" Konfigurationen erzeugen.


    Erwartet keiner, will keiner. (Oh wie ich mir vorstellen kann, wie Sie dieses "aber bei Confixx geht..." annerven muss.) ;)


    Also, Ihre Lösungsvorschläge hatte ich beinahe schon so erwartet - ohne die Details der LUA-Lösung zu kennen.


    Aber jetzt das AAABER! Völlig egal ob Confixx oder Plesk oder was auch immer. Irgendwie ist es doch Standard, dass VirtualHosts eingesetzt werden. Ebenso werden wohl die meisten Anwendungen, ob nun Open-Source oder Kommerziell, mit dem Grundgedanken entwickelt, die Anwendung läuft auf dem vermeindlichen DOCUMENT_ROOT.


    Demnach müsste ich nicht nur die Kunden erziehen, sondern allen Web-Entwickern auf die Finger hauen, dessen Software von unseren Kunden eingesetzt werden soll, weil wir DOCUMENT_ROOT im eigentlichen Sinne nicht mehr verwenden können.


    Das mit den Kunden "erziehen" ist ohnehin so eine Sache. Nach acht Jahren im Geschäft glaubt man nicht mehr an Kundenerziehung.


    Lösung 2 klingt zunächst einmal interessant und könnte das "Problem" aus der Welt schaffen. Allerdings bin ich mir nicht sicher, ob es da noch Seiteneffekte geben kann. Ich möchte auch nicht riskieren, eine an sich ordentliche Software - also LiveConfig - mit sochen Konstrukten zu verhunzen und ggf. mit dem nächsten Update x Kunden zu haben, deren Skripte plötzlich nicht mehr laufen.


    Also, aus meiner Sicht bleibt die Rewrite-Lösung für SubDomains die "suboptimale" Lösung. Aber ich denke, diese Lösung ist trotzdem einsetzbar.


    Ich werde wahrscheinlich die Skripte mit DOCUMENT_ROOT identifizieren und via sed mit Ihrem basename-Vorschlag ersetzen. Anschließend dem Kunden eine Nachricht senden und gut ist.


    Ich würde mich aber freuen, wenn Sie mir noch - nur aus Interesse - erklären könnten, warum Sie keine VirtualHosts einsetzen.


    Einen guten Start in die Woche,


    Oskar Groh

    Computer sind unglaublich dumme Geräte,
    die unglaublich intelligente Sachen können.
    Programmierer sind unglaublich intelligente Leute,
    die unglaublich dumme Sachen produzieren.
    ("Die Presse", 30.8.1999)

    Hallo Herr Groh,


    Zitat

    So ganz ist das zwar noch nicht mein Freund, da mit VirtualHosts auch spezielle Berechtigungen für eben diesen zu realisieren wären


    Das kann man in der RewriteRule-Variante i.d.R. ebenfalls, nur eben mit entsprechenden <Directory>/<Location>-Anweisungen.


    Zitat

    Oh wie ich mir vorstellen kann, wie Sie dieses "aber bei Confixx geht..." annerven muss.


    Naja, sooo schlimm ist es zum Glück auch wieder nicht. ;)


    Zitat

    Aber jetzt das AAABER! Völlig egal ob Confixx oder Plesk oder was auch immer. Irgendwie ist es doch Standard, dass VirtualHosts eingesetzt werden.


    Jein. VirtualHosts sind am einfachsten zu konfigurieren (das bekommen also auch die einfachsten Programmierer hin ;)). Einen echten "Standard" gibt es aber nicht. Vor allem sehr große Hosting-Umgebungen (>10.000 Verträge pro Server) werden in der Regel nicht mit einzelnen <VirtualHosts> für jede einzelne (Sub-)Domain arbeiten (s.u.).


    Zitat

    Ebenso werden wohl die meisten Anwendungen, ob nun Open-Source oder Kommerziell, mit dem Grundgedanken entwickelt, die Anwendung läuft auf dem vermeindlichen DOCUMENT_ROOT.


    Hoffentlich nicht - da DOCUMENT_ROOT eben nur auf irgendein Starterzeichnis des Webspaces verweist und die Anwendung somit nicht in einem Unterverzeichnis betrieben werden kann.


    Zitat

    Ich würde mich aber freuen, wenn Sie mir noch - nur aus Interesse - erklären könnten, warum Sie keine VirtualHosts einsetzen.


    Ausschließlich aus Performancegründen.
    Apache prüft bei jedem Reload, ob jedes in "DocumentRoot" angegebene Verzeichnis existiert. Löscht ein Kunde beispielsweise ein Verzeichnis per FTP, das gleichzeitig noch im LiveConfig als Startverzeichnis für eine Subdomain konfiguriert war, würde Apache hierfür dann eine WARNING bringen (was bei einer Subdomain noch egal sein mag, bei hunderten oder tausenden aber schon lästig wird).
    Um aber herauszufinden, ob ein Verzeichnis existiert, ist ein sog. stat()-Aufruf notwendig. Wenn die Webspaces nun z.B. auf einem vergleichsweise langsamen NFS liegen, kann es eine beträchtliche Zeit dauern, die Apache nur mit tausenden stat()-Aufrufen beschäftigt ist - in dieser Zeit werden keine HTTP-Anfragen verarbeitet. Zudem findet ein Reload der Konfiguration relativ häufig statt (jedes mal, wenn an irgendeiner Subdomain-Konfiguration irgendwas geändert wird) - daher sollte der Reload also möglichst flott ablaufen.


    Wenn man beispielsweise 500 Kunden mit durchschnittlich 5 Domains auf einem Server betreibt und jede Subdomain als VirtualHost konfigurieren würde, dann wären das bis zu 5000 <VirtualHost>-Einträge (500 Kunden * 5 * 2 (mit/ohne "www")).
    Beim Apache-Reload also 5000x stat().
    Mit LiveConfig sind das 500x stat() - wir können also sagen "Ein mit LiveConfig konfigurierter Apache startet bis zu 95% schneller" :P
    (Apache kann man ab Version 2.2.17 auch mit der Option -T starten, welche den DocRoot-Check überspringt - in Debian Squeeze ist aber nur Apache 2.2.16 verfügbar).


    Verstehen Sie also unsere Motivation für die so erzeugte Konfiguration?


    Prinzipiell besteht immer die Möglichkeit, die zuständige Funktion in der apache.lua auszutauschen und tatsächlich für verschiedene Sudomains einzelne <VirtualHost>s zu erzeugen, ohne dass man hierzu in LiveConfig selbst irgendwas ändern/anpassen müsste. Wir sehen aber (derzeit?) keinen Vorteil darin.


    Viele Grüße


    -Klaus Keppler

    Das kann ich alles nachvollziehen und ja, Ihre Motivation verstehe ich.


    Ich habe übrigens einen Fehler im meiner Suche nach DOCUMENT_ROOT gemacht. Die Abrage wird mit einem Fehler abgebrochen. So funktioniert es ohne Abbruch und vor allem deutlich schneller:


    Code
    find /var/www/web*/html/ -type f -name *.php -print0 | xargs -0 egrep -l -e DOCUMENT_ROOT {} | wc -l


    Treffer: 2086(!) Dateien in denen DOCUMENT_ROOT vorkommt.


    ohne den Parameter -l in egrep erhalten wir die tatsächliche Anzahl von Vorkommen:


    Code
    find /var/www/web*/html/ -type f -name *.php -print0 | xargs -0 egrep -e DOCUMENT_ROOT {} | wc -l


    Und das sind 7111. :mad:


    Hauptsächlich in Typo3, WordPress, Contenido, Joomla und anderen! Also nicht einmal vom Kunden selbst geschriebene Skripte.


    Mir ist aktuell ein bisschen schlecht.


    Es wird eine größere Herausforderung sein, dem Kunden den Verzicht auf DOCUMENT_ROOT klar zu machen. Insbesondere weil ich den Kunden nun erklären muss, dass sie zwar weitere (nicht nur die über das Panel angebotene) Projekte installieren können, aber diese auf das Vorhandensein von DOCUMENT_ROOT überprüfen müssen und wie von Ihnen beschrieben editieren, sofern sie die Anwendung auf eine SubDomain legen wollen, die in einem Unterordner von htdocs liegt.


    Oh, das wird Gemecker geben und sicherlich auch jede Menge Unverständnis. :(


    BTW: Ich habe den einen oder anderen Thread im Forum gefunden, in dem es immer mal wieder um RewriteBase / geht. Ich denke, dass hier genau das DOCUMENT_ROOT-Problem zugrunde liegt.


    Ich werde nun versuchen einen Kunden umzuziehen, der DOCUMENT_ROOT ebenfalls exzessiv im Einsatz hat. Ich hab da gerade etwas Bauchschmerzen, denn es ist ein großer, bekannter Kunde, der auf Probleme seiner Online-Präsenz ziemlich schnell und empfindlich reagiert. TOI TOI TOI.


    Vielleicht denken Sie ja doch über einen "Schalter" nach, der es ermöglicht dem Admin des Systems zu überlassen, SubDomains via Rewrite oder VirtualHosts einrichten zu lassen.


    Viele Grüße,


    Oskar Groh

    Computer sind unglaublich dumme Geräte,
    die unglaublich intelligente Sachen können.
    Programmierer sind unglaublich intelligente Leute,
    die unglaublich dumme Sachen produzieren.
    ("Die Presse", 30.8.1999)

    Zitat

    Es wird eine größere Herausforderung sein, dem Kunden den Verzicht auf DOCUMENT_ROOT klar zu machen.


    Hmm, das ist natürlich nicht Sinn und Zweck der Sache.


    Wir bauen kurzfristig einen Switch in LiveConfig ein, mit dem Konfigurationen auch mit einzelnen <VirtualHosts> erzeugt werden können, dann entfällt diese Problematik vollständig. :)
    Gedulden Sie sich bitte bis heute Abend, dann gibt es ein Update.


    Viele Grüße


    -Klaus Keppler

    Herr Keppler,


    wir sind baff! Sie sehen also auch das Problem?


    Gut, bis heute Abend kann ich warten. Unser Kunde erwartet seinen Umzug heute Nacht.


    Noch eine Frage: Kann ich denn dann bestehende Kunden auch umswitchen? Da ich bereits den Kunden angelegt habe, die Subdomains angelegt (weil die z. Z. auch als eMail-Adressen genutzt werden) und die Inhalte schon kopiert und per sed auf die neuen Pfade modifiziert habe, wäre das interessant zu wissen. Oder funktioniert der Switch dann nur bei Neuanlage eines Kunden?


    Viele Grüße,


    Oskar Groh

    Computer sind unglaublich dumme Geräte,
    die unglaublich intelligente Sachen können.
    Programmierer sind unglaublich intelligente Leute,
    die unglaublich dumme Sachen produzieren.
    ("Die Presse", 30.8.1999)

    Ja, wir haben hier auf einigen unserer Server auch mal eine solche Suche gemacht. Ich vermute, dass diese Fragestellung bislang deshalb kaum ein Problem war, weil komischerweise 95% aller Kunden alle Domains jeweils im Hauptverzeichnis konfiguriert haben, und die restlichen Kunden (zumindest bei LiveConfig) das DOCUMENT_ROOT bislang nicht anderweitig genutzt hatten.
    Insgesamt sehe ich das aber auch eher problematisch, nicht zuletzt nach den Erlebnissen mit Typo3.


    Und ja, Sie können das auch für bestehende Kunden ändern; eine ausführliche Beschreibung dazu folgt ebenfalls.


    Viele Grüße


    -Klaus Keppler

    Herr Keppler! Hören Sie mich Jubeln, da unten in Bayern?


    Ganz großes Kino, dass Sie das heute noch eingebaut haben. Ich bin schwer beeindruckt! Das ist der Beginn einer wunderbaren Freundschaft! :)


    Und jetzt wird der Kunde umgezogen!


    Grüße aus Preußen,


    Oskar Groh

    Computer sind unglaublich dumme Geräte,
    die unglaublich intelligente Sachen können.
    Programmierer sind unglaublich intelligente Leute,
    die unglaublich dumme Sachen produzieren.
    ("Die Presse", 30.8.1999)

    2 Mal editiert, zuletzt von WebOscar ()

    Die Funktion gibt es schon seit einer ganzen Weile, offenbar ist das aber noch nicht im Handbuch dokumentiert :(


    Sie müssen eine custom.lua anlegen und dort folgenden Befehl einbauen:

    Code
    apache.CONFIGMODE='rewrite'


    (siehe Kopf-Bereich in der apache.lua - dort ist das grob beschrieben)


    Viele Grüße


    -Klaus Keppler

    Hallo,


    ich habe auf meinem vServer jetzt auch Liveconfig installiert. Wenn ich das das richtig sehe, dann benutzt LiveConfig standartmäßig die vhost-Variante. Bei manchen Dingen, wie zum Beispiel neue Subdomains oder neue Domains muss der Apache2 Webserver neugestartet werden. Bei Confixx gab es dafür so ein schönes Counterscript, was nach einer bestimmten Zeit immer ausgeführt wurde und damit, falls notwendig, Apache2 neu geladen hat.


    Gibt es für LiveConfig auch so ein Script?

    Hallo Eschy5,


    eigentlich startet LiveConfig den Indianer "on Demand" durch. Ein Cronjob ist hier nicht nötig und die Counterscripts waren auch nicht "schön". ;) viel Spaß mit LiveConfig.

    Computer sind unglaublich dumme Geräte,
    die unglaublich intelligente Sachen können.
    Programmierer sind unglaublich intelligente Leute,
    die unglaublich dumme Sachen produzieren.
    ("Die Presse", 30.8.1999)

    Exakt. Sobald LiveConfig irgendwas an einer vHost-Konfiguration geändert hat, wird die Apache-Konfiguration neu geladen (wobei LiveConfig dabei bis zu 60 sec wartet, ob noch andere Änderungen erfolgt sind, damit man kein DoS nur durch Konfigurations-Updates erzeugen kann).

    Wenn eine vHost-Konfiguration aktualisiert wird, dann wird automatisch auch ein Apache-Reload gequeued. Falls die Konfiguration nicht übernommen wird, liegt eventuell woanders irgendein Konfigurationsfehler vor. Liefert "/etc/init.d/apache2 reload" einen Fehler?
    Ansonsten werfen Sie bitte mal einen Blick in /var/log/liveconfig/liveconfig.log, ob es Auffälligkeiten gibt.

    Ja. es gibt Fehler. Ich muss aber auch zugeben, dass meine Installation nicht ganz sauber ist. Es handelt sich noch um den selben Server wo auch Confixx drauf ist. Die aktuellen Fehler sind noch mit IPv6 Adressen. Da hatte ich schon mal was eingebaut, damit IPv6 möglich ist aber einige Zeit später habe ich auf 64 Bit gewechselt und nich nicht wieder alles korrekt eingebaut. Aber Ihre Antwort hilft mir schon mal, da weiß ich schon mal, woran ich noch arbeiten muss. Bei Manchen vhots hat Apache2 auch gemeckert, weil noch alte Verzeichnisse drin waren, die ich schon gelöscht hatte.Diese Fehler müssten aber bereits alle behoben sein.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden