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:
$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:
- Erzeugen Sie eine Datei namens /usr/lib/liveconfig/document_root.inc.php mit folgendem Inhalt:
<?php
if (isset($_SERVER['DOMAIN_ROOT'])) {
$_SERVER['DOCUMENT_ROOT'] = $_SERVER['DOMAIN_ROOT'];
}
?>
- Erzeugen Sie eine Datei namens /etc/php5/conf.d/liveconfig.ini mit folgendem Inhalt:
auto_prepend_file=/usr/lib/liveconfig/document_root.inc.php
- In der Datei /usr/lib/liveconfig/lua/apache.lua suchen Sie die Zeile mit folgendem Inhalt (ca. Zeile 1716):
fh:write(" RewriteRule ^/(.*) ", string.gsub(opts.path .. "/htdocs/" .. key, " ", "\\ "), "/$1 [L]\n\n")
Ändern Sie darin den Eintrag "[L]" in das hier um:
[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
