Ich möchte mal behaupten, dass die letzte Nacht und der heutige Tag äußerst erfolgreich verlaufen sind. Gestern Nacht stieß ich bei der Suche nach etwas ganz anderem auf eine Sache, die ich eigentlich schon aufgegeben hatte: mod_vhost_dbi. In Kombination mit mod_dbi_pool ermöglicht es Apache2-VirtualHosts in eine beliebige (!) Datenbank zu speichern. Das Modul ließ sich einwandfrei Kompilieren und funktionierte auf Anhieb. Nun dachte ich also, doch von den lästigen Apache-Konfigurationsdateien los zu kommen. Freude!
Doch die ernüchterung kam gegen 2:00 Uhr: tatsächlich lassen sich nur der DocumentRoot, der User (Sichwort SuExec) und der ServerName einstellen. Grundsätzlich reicht das für eine einfache Konfiguration auch aus, aber gerade wenn man wegen Rails o.Ä. einige Spezialeinstellungen vornehmen möchte, muss man dann doch wieder auf die herkömmliche hartkodierte Variante zugreifen.
Gegen 2:10 Uhr entschloss ich mich dann dazu, mal einen Blick in den Quelltext des Moduls zu werfen. Tatsächlich habe ich es dann auch geschafft, immerhin noch 1-2 Zusatzsangaben wie den ServerAdmin in die Datenbank zu verfrachten. Als ich allerdings gegen 5:40 mit dem Durchpflügen der Apache Runtime API weitestgehend fertig war, war mir klar dass es einen guten Grund gibt, warum ein so praktisches Modul zur VortualHost-Verwaltung in einer Datenbank nicht in dem Umfang existiert, wie ich es mir wünschen würde: Es ist unglaublich aufwändig zu programmieren, da die Apache-API (bzw. eigentlich die betroffenen Module) dafür nicht an den benötigten Stellen "Hooks" (kann man als Broadcast-Funktionsaufrufe sehen, wo jedes Modul sich an bestimmte Stellen ins Servergeschehen einhängen kann) aufweisen. Ich habe bei einem anderen Modul (mod_vhost) versucht, etwas Quelltext abzukupfern, aber für einen Sonntagvormittag nach nur 6 Stunden Schlaf wurde es einfach zu schnell zu komplex.
Dennoch werde ich nun auf die VirtualHost-in-Datenbank-Lösung setzen, und alle weiteren Einstellungen nicht in der Datenbank, sondern über .htaccess-Dateien im Homeverzeichnis der User erledigen (sofern ein globaler default nicht ausreicht).
Da nun Apache-VirtualHosts auch als ActiveRecord-Objekte in Consolvix auftauchen dürften, habe ich mir überlegt, dass es Sinn macht, jedem Benutzer die Möglichkeit zu geben, beliebig viele ("beliebig" im technischen, nicht buchhalterischen Sinne) VirtualHosts innerhalb seines Homeverzeichnisses anzulegten. Das macht für Subdomains etc. durchaus Sinn. In Kombination mit den ProFTP-VirtualHosts (praktischerweise verwenden Apache und ProFTP die selbe Syntax in ihren Config-Dateien, dafür kann ich also die bereits vorhandene Klassensamlung verwenden :-)) kann ein Kunde nun also mehrere unterschiedeliche Domains in mehreren Unterverzeichnissen hosten und dazu noch mehrere FTP-Zugänge (beliebig viele) einrichten -- macht z.B. für eine Vereinsseite Sinn.
In diesem Licht macht die Betrachtung Unterscheidung HostingUser/SystemUser/FTPUser wenig Sinn, ebenso wie wenn ein SystemUser z.B. Webhosting-Eigenschaften Aggregiert. Ich betrachte VirtualHosts nun einfach als zusätzliche Konten: Ein normaler SystemUser bekommt automatisch (durch das Datenbankschema bedingt) einen Master-FTP-Zugang zu seinem Homeverzeichnis. Je nach dem welche Rechte für ihn freigeschaltet sind, kann er nun weitere FTP-Accounts für Unterverzeichnisse anlegen und diese (sofern berechtigt) für den HTTPD freigeben oder sperren.
So, und hier eine kleine Klassenübersicht:
