/blog/wvk

class HelloSayer
  def scream
    3.times do 
      puts "hello world!".upcase
    end 
  end
end
h = HelloSayer.new
h.scream

Nun, wo dies gesagt ist: Willkommen zu meinem Diplomarbeits-Blog, wo in der nächsten Zeit das eine oder andere mehr oder minder Interessante zum Fortschritt meiner Arbeit zu finden sein wird. Pro Forma soll hier erst eine kleine Zusammenfassung dessen erfolgen, wie das Ziel dieser Arbeit (neben der Erlangung des akademischen Grades des "Diplom-Ingenieur (FH)", aussehen wird. Genaueres befindet sich in der ausführlichen Konzeptbeschreibung, die ich gleich mal versuchen werde als PDF hier anzuhängen.

Die Ausgangsituation: Ich habe momentan einen Hostingserver laufen, der von seiner Softwareauswahl her als typisches LAMP-System angesehen werden kann. Dafür gibt es zwar eine teilamputierte Hand voll webbasierter Administrationsoberflächen, jedoch keine die so wirklich meine Ansprüche abdeckt. Deswegen werde ich im Rahmen dieser Diplomarbeit eine eigene Server-Administrations- und Kundenverwaltungs-Applikation entwickeln, die
a) meinen Ansprüchen gerecht werden,
b) komplett in Ruby geschrieben und
c) sinnvollen Gebrauch von Web 2.0-Technologien machen soll.

Was meine Serverkonfiguration nicht ganz alltäglich macht, ist die Tatsache dass ein Großteil der Software ihre Informationen nicht aus Konfigurationsdateien wie /etc/passwd, /etc/aliases oder ~/.forward bezieht, sondern aus einer MySQL-Datenbank. Das schreit für mich förmlich nach einer Verwaltungsoberfläche in Ruby on Rails mit seinem ActiveRecord-Konzept.

Nundenn, soviel zur Einführung. Mehr Info dazu gibt's in dieser PDF-Datei.
Momentan beschäftige ich mich mit der Erstellung der Use-Case- und Klassen-Spezifikation. Diese liegt in ihrer jeweils aktuellsten Version unter http://chaos.hobby-astronomie.net/dipl/consolvix/consolvix.html. eine XMI-Datei befindet sich unter http://chaos.hobby-astronomie.net/dipl/consolvix.xmi. Ratschläge, Ideen und Wünsche sind jederzeit gern gesehen, auch wenn das alles noch weit von einer brauchbaren Spezifikation entfernt ist.

Der mächtige Indianer stellt sich in Sachen Konfiguration via MySQL etwas quer. Zwar gibt es drei Module, die die VirtualHost-Verwaltung über MySQL ermöglichen sollen, aber es sieht noch nicht danach aus, als kämen diese in Frage für meinen Server. Das eine Projekt, mod_v2h scheint schon länger tot zu sein. Das zweite, mod_vdbh, hab ich vor einiger Zeit mal zu installieren versucht, aber bin gescheitert (OK, ich habe mich vielleicht nicht soo intensiv bemüht...). Das dritte und meistversprechende Projekt ist mod_vhs. Es schien mir bislang etwas konfus von der Konfiguration her, aber ich überlege ernsthaft, es einmal intensiver auszuprobieren.
Allen Modulen gemein ist, dass es keine fertigen DEB-Binaries gibt, was die Systempflege etwas aufwändiger macht. Da nicht die Systemeinrichtung und die damit verbundenen Eingriffe ins Innenleben mancher Software, sondern die Entwicklung einer übergreifenden Hostingserver-Administrationsoberfläche Ziel dieser Arbeit ist, würde ich gerne so weit es geht auf nicht im Standard-Debian System enthaltene Software verzichten. Das bedeutet, dass ich vorerst mit normalen Apache-Konfigurationsdateien arbeiten und mir die Möglichkeit, VirtualHosts zentral über die Datenbank abzuwickeln, für später aufheben werde.
Aus diesem Grund habe ich mir letzte Woche einen Parser für Apache-Configdateien geschrieben. Momentan kann der noch nichts weiter als syntaktisch korrekte Configdateien einlesen, die einzelnen Werte in einer Baumstruktur abpeichern (siehe Klassendiagramm) und veränderte sowie unveränderte Daten in der korrekten Reihenfolge wieder zurückspeichern, aber das wird sich sehr bald ändern. Als nächstes werde ich eine einfache Oberfläche zur Bearbeitung der Werte erschaffen, danach eine saubere Möglichkeit zur Validierung der Werte. Es wäre schön, wenn die ganzen Konfigurations-Direktiven sich so handhaben ließen als wären es ActiveRecord-Objekte aus einer Datenbank, aber ob das nicht vielleicht zu aufwändig zu implementieren ist (und wie sinnvoll), muss noch erörtert werden...

Das Klassendiagram "so far":

Das UML-Modell zum Config-Parser gibt's unter http://chaos.hobby-astronomie.net/dipl/configParser/configParser.html in seiner jeweils aktuellsten Version. Die XMI-Variante gibt's unter http://chaos.hobby-astronomie.net/dipl/configParser.xmi

Mailman ist eine sehr mächige Mailinglisten-Verwaltungssoftware, außerdem eine der beliebtestens in der Unix-Welt. Weiterhin stellt diese Software eine der Hauptmotivationen für meine eigene Serververwaltungssoftware dar: Sie ist nicht mittels z.B. Confixx administrierbar.
Mailman bietet eine umfangreiche Webbasierte Administrationsoberfläche, die aber relativ fest mit der Software selbst verwachsen ist (das Grundgerüst der Seite ist fest im Python-Quelltext verdrahtet). Man hat zwar die Möglichkeit, HTML-Vorlagen pro Liste anzulegen, aber so ganz frei ist man in der Seitengestaltung nicht. Außerdem ist die Integration der Mailinglistenverwaltung in eine andere Administrationsumgebung schwierig.

Mailman ist in Python geschrieben, einer Sprache die Ruby nicht unähnlich ist.

Mailman bietet eine Menge an Konsolenskripten zur Mailinglistenadministration an.
"Hey," dachte ich mir da gestern, "Dann ist es ja ein leichtes, die Änderungen an Mailinglisten vorzunehmen indem ich einfach diese Skripte von meinem Ruby-Programm aufrufe". Möglich wäre es auf jeden Fall, aber bei jeder Änderung erst eine Instanz einer Shell zu erstellen, dann diesem einen zusammengefrickelten string zu übermitteln und den Rückgabewert abzufangen... das ist nicht sauber.
Aber es gibt eine begeisterungsfähige Lösung, auf die ich soeben gestoßen bin:
Mailman bietet ein Skript namens withlist, wo entweder interaktiv via Konsole, oder aber (und darum geht es mir!) programmatisch, also mittels eines eigenen Python-Scripts, direkt Änderungen an Mailinglisten vorgenommen werden können. Nun ist Python aber nicht Ruby, doch dafür gibts eine Bibliothek namens Ruby/Python. Damit lassen sich Python-Objekte und -Funktionen in Ruby wie Ruby-Objekte/-Methoden verwenden.
Was werde ich nun also tun? Ich werde das withlist abspecken und nach Ruby portieren, dann mittels Ruby/Python die von Mailman zur Verfügung gestellten Libs einbinden und dann eine perfekt in Consolvix integrierte Mailinglistenadministrationsoberfläche (38 chars! ;-)) haben.

<added date="2007-09-20 20:39 UTC+2">Leider hat das alles nicht so geklappt, wie ich es mir vorgestellt hätte. Python/Ruby lässt sich nach Anpassen der Bibliothekspfade zwar einwandfrei kompilieren, aber sobald man davon in einer .rb-Datei gebrauch machen möchte, wirft die python.so fröhlich mit Segfaults und Meldungen über fehlende Objektreferenzen um sich. Nunja, ein Versuch war's wert. Ich werde jetzt doch die Methode mit den Shellscripten anwenden, auch wenn das einiges an zusätzlichem Overhead bedeutet...</added>

Nur leider geht eines nicht, und zwar die Verlagerung der Mailman-Konfiguration in eine Datenbank. Es gibt zwar Bemühungen diesezüglich, aber die Beziehungen seien einfach zu komplex laut eines Beitrags in der Mailman-Mailingliste. Ob ich die Daten dennoch redundant in einer Datenbank abspeichere, ist noch nicht entschieden. Vermutlich jedoch eher nicht, da sonst die Listenadministration via Mailman's eigener Oberfläche oder via E-Mail nicht mehr abgeglichen würde. Natürlich könnte man ein Synchronisations-Script schreiben, welches ab und an per Cron getriggert wird, aber dann sind wir ja wieder da, wo ich eigentlich von weg wollte.

Nach einem befruchtenden Gespräch mit Herrn Prof. Klingspor am heutigen Nachmittag bin ich nun in einer zentralen Frage weitergkommen, die im wesentlichen die Hauptbremse für weitere Überlegungen zum Zentralen Modul meiner Software darstellte.
Die Frage: wie gestalte ich meine Benutzerverwaltung? Genauer: Wie ist die Abhängigkeit zwischen den betreffenden Klassen?
Das Problem: Das Gesamtsystem unterscheidet zwischen den folgenden Benutzer-Arten: Systembenutzer (der UNIX-Systemaccount), Hosting-Benutzer (ein Systembenutzer mit der Möglichkeit, Seiten zu hosten und weitere e-Mailadressen anzulegen; verwendet von der Webanwendugn und dem System), E-Mail-Account (sowohl für Systembenutzer als auch virtuell; verwendet von der Mailsoftware), Systemadministrator (vermutlich auch ein Systemaccount, aber mit zusätzlichen Administrationsrechten innerhalb von Consolvix), Reseller (Ein Hostungbenutzer mit der Möglichkeit, weitere Webbenutzer zu administrieren).
Die Lösung: Erst hatte ich gedacht, das als Klassendiagramm vielleicht so abzubilden:

Die Vererbung würde dann durch Single Table Inheritance geregelt. Für jede Art der Authentifizierung und Authorisierung würde dann auf die Methoden/Eigenschaften des "User"-Elternobjektes zurückgegriffen werden. Durch Setzen des entsprechenden "type"-Feld in der Datenbanktabelle könnte man dan auch sehr einfach einen Hostingbenutzer zum Reseller machen usw. Nachteil ist allerdings, dass diese eine Benutzertabelle eine große Zahl an NULL-Werten aufweisen würde und Äpfel und Birnen gewissermaßen alle in einen Topf mit "Obst" geworfen würden.

Nach einiger Überlegung, wie die E-Mailaccounts verwaltet werden sollten, kam ich zu der Entscheidung, dass die sauberste Lösung durch möglichst wenig Vererbung und mehr Aggregation/Komposition erreicht wird:

So gibt es nun eine abstrakte "Benutzer"-Elternklasse. Diese ist letztendlich nur für den E-Mailversand interessant, denn sowohl virtuelle E-Mailbenutzer (alle mit der UID/GID 5000) als auch Systembenutzer besitzen ein E-Mailkonto. Auf Datenbankebene wird diese "Klasse" als View implementiert, welche die benötigten Attribute aus der Systemenutzer- und E-Mailkonten-Tabelle zusammenführt. Auf SW-Ebene kann man sagen, dass Sowohl die virtuellen als auch die Systembenutzer eher ein E-Mail-Konto "implementieren" als "sind", insofern macht es Sinn, den EmailUser als Interface oder abstrakte Klasse zu betrachten.
Die Systembenutzertabelle wird sowohl vom PAM-System als auch von Consolvix zur Authentifizierung verwendet.
Da die Zusatzangaben, wie z.B. alles was mit Hosting und Administrationsrechten zu tun hat, nicht wirklich logisch zur Klasse "Benutzer" gehören, werden diese nun aus anderen Tabellen aggregiert. Dass dieses Design wesentlich flexibler ist als eine strikte Klassenhierachie, dürfte dem geschulten Auge sofort klar sein ;-). Ich werde den Sachverhalt in der Diplomarbeit wohl noch weiter ausführen.

Den heutigen und gestrigen Tag habe ich etwas intensiver mit Klassendesign und Überlegungen zum Datenbankschema gemacht. Zwar ist es in Anbetracht der Tatsache, dass ich noch nicht einmal meine Use Case-Sammlung Fertig habe, etwas verfrüht um mir schon konkrete Gedanken zur genauen technischen Implementierung zu machen, aber ich denke mal dass diese Tätigkeit durchaus gerechtfertigt ist. Warum? Ich habe technische Vorgaben durch das System selbst, die ich verwalten möchte. Andererseits habe ich natürlich auch meine "Vorgaben", wie die Verwaltung im Endeffekt für den Benutzer aussehen soll, und diese sollten möglichst nicht durch technische vorgaben beeinflusst werden.
Momentan laufen also zwei Entwicklungsansätze Ansätze parallel, und das sorgte just heute für Verwirrung. Das gestern noch vorgeschlagene Klassendesign für die Benutzerverwaltung (insbesondere aus E-Mail-systemtechnischer Sicht) war heute wieder mehrfach zentrale Bestandteil meiner Überlegungen. Und siehe da, es wurde wieder mehrfach verändert.
Nun ist mir als Ursache dafür klar geworden, dass ich hier zwei Prozesse miteinander zu verquirksen versuche, die in erster Linie nichts miteinander zu tun habe: Der technische/systemverwalterische Prozess und der Geschäftsprozess. Mal modelliere ich etwas nach den Vorstellungen des einen, mal nach denen des anderen. Und das sollte hier und jetzt aufhören, denn sonst komme ich nie auf einen grünen Zweig.

Ein paar Dinge sollten mir klarer sein, und hier ist ein Versuch der Klärung:

Wer wird die Software am Ende einsetzen?

Ich selbst, meinen Server. Aber: es gibt andere Menschen, die bereits ihr Interesse bekundet haben.

Soll Consolvix eine möglichst flexible Softwarezusammenstellung unterstützen?

Nein. Consolvix soll, insbesondere zu Beginn, genau die vorgegebene Systemkonfiguration möglichst optimal, sprich vollständig, verwalten können. Für andere Softwarekonfigurationen sollen aber später Zusatzmodule geschrieben werden können. Was also an Consolvix flexibel und universell gestaltet werden soll, ist "lediglich" die Modul-API.

Soll die Software Geschäftsprozesse vorgeben oder soll sie möglichst Geschäftsmodell-unabhängig, also eher systemorientiert sein?

Das ist die schwierigste Frage. Ich tendiere zur Antwort, dass sie möglichst meine Vorstellungen des Hostinggeschäftsmodells vorgeben soll. Grundgedanke ist dieser: die rein technische Administration lässt sich auch sehr gut mit Software wie Webmin erledigen, außerdem ist durch die Verlagerung der Konfiguration in die Datenbank bereits eine gewisse Abstraktion zum System gegeben. Insofern ist es möglich, die Systemverwaltung zu einem Großteil über PHPMyAdmin zu erledigen (mache ich zur Zeit). Außerdem spielt der buchhalterische Aspekt eine elementare Rolle: zwar werde ich im Rahmen der Diplomarbeit vermutlich nicht die ganze Rechnungsverwaltung implementieren, aber letzten Endes sollte sich Consolvix doch auf genau diese Aufgabe ausrichten.

Nundenn, mal schauen was diese Antworten mir bringen werden.

Es begab sich zu einer Zeit, als das ARPANET noch blühte und ein Hacker noch ein Hacker und kein von kriminellen Konotationen bevorurteilter Zeitgenosse war, als -- aus heutiger Sicht -- eines der größten Verbrechen der Computer-Industrie begangen wurde: das File Transfer Protocol wurde erfunden und standardisiert. Seitdem sind vermutlich Hunderttausende armer Internetznutzer bereits Opfer der -- aus heutigen Sicht -- hirnrissigen Tatsache geworden, dass FTP ein Plain Text-Protokoll ohne Kennwortverschlüsselung ist. Und während Telnet mittlerweile ein Schattendasein im Lichte von SSH führt (tut es das?!), findet sich noch immer auf jedem Shared Hosting System standardmäßig ein FTP-Zugang für jeden. Von SFTP, RSync oder WebDAV über SSH, SCP und Fish scheint noch nie ein Mensch zuvor gehört zu haben.

Ein Grund mehr also, für mein "imaginäres" Hostingunternehmen Consolving ein weiteres Alleinstellungsmerkmal aufzupolieren: "Bei uns greifen sie stets über erwiesenermaßen sichere Verschlüsselungstechnologien auf Ihre Daten zu!" -- klingt irgendwie gut, weckt Kundenvertrauen, macht das Ganze für erfahrenere Internetnutzer umso attraktiver usw.

Also ran und gleich mal SFTP eingerichtet, das ist mit RSSH (Restricted SSH) sehr einfach. Einfach in /etc/rssh.conf eintragen, dass alle betreffenden Benutzer rsync, scp und sftp nutzen dürfen, und bei den betreffenden Benutzern /usr/bin/rssh als Shell eintragen. Einen Haken hat die Geschichte, und die kann sehr wohl auch zu einem internen Sicherheitsproblem werden: SSH erlaubt es in der "out of the Box"-Variante nicht, die Benutzer in ihr Homeverzeichnis zu "Chrooten" (man verzeihe bitte die vielen Sprachvergewaltigungen an dieser Stelle...). Für eine Shared Hosting-Umgebung mit mehreren Duzend oder gar Hunderten von Kunden ist das natürlich unhaltbar.

Schließlich bin ich doch wieder auf FTP zurückekommen, denn was ProFTP so alles bietet (MySQL-Unterstützung, umfangreiches Quota-Handling, detaillierte und flexible Zugriffsverwaltung pro Host, Gruppe, Klasse, Benutzer, Verzeichnis bis hin zur einzelnen Datei), deckt sich perfekt mit meinen Systemanforderungen. Und als Sagnehäubchen kommt mit mod_tls auch noch verschlüsseltes FTP (FTPS, nicht zu verwechseln mit SFTP, welches ein SSH-Subsystem ist!) hinzu. Das einzige Problem mit FTPS ist, dass längst nicht jeder FTP-Client es untersützt, und außerdem nicht auf Port 20/21 (Daten/Steuerung), sondern auf Port 989 und 990. Diese werden aber duch die meisten Firewalls standardmäßig blockiert (*winkewink* an DVZ@FH Bochum! *grml*) und während viele Internetnutzer bei "Port 21" noch eine leise Glocke bimmeln hören, dürfte "Port 990" vollkommene Ahnungslosigkeit hervorrufen.
Nichtsdestoweniger habe ich nun probehalber einen sicheren FTP-Server eingerichtet (sicher heißt, eine Verbindung ist ausschließlich über TLS möglich) und das funktioniert soweit einwandfrei. Dass in einer Willkommensmail an zukünftige Kunden erklärt wird, wie dieser mit dieser vom de Facto-Standard abweichenden Konfiguration umzugehen hat, versteht sich von selbst :-)

Was nun als nächstes mit Hilfe von ProFTP sehr elegant umgesetzt (und in Consolvix integriert!) werden wird, ist ein Quotasystem und die Benutzerverwaltung. ProFTP ermöglicht den Einsatz virtueller Benutzerkonten über MySQL, was es auch sinnvoll und attraktiv macht, jedem Kunden beliebig viele FTP-Zugänge zur Verfügung zu stellen. Die Idee dahinter: Der Kunde (sprich der ihm zugeordnete Systembenutzer) erhält maximal Q MB Plattenspeicher zur Verfügung gestellt. Das wird in die Quotatabelle eingetragen (und nicht, wie ich erst plante, in die Benutzertabelle). Der Benutzer kann nun neue, virtuelle FTP-Benutzer anlegen und ihnen X MB (< Q, natürlich) Platenplatz zuordnen, bis ΣX = Q. ProFTP's Quotasystem sorgt dafür, dass sowohl die einzelnen Benutzer ihr X, als auch alle Benutzer zusammen (vorgegeben über eine Gruppen-Quota-Regel in der Quotatabelle) Q niemals oder nur kurzzeitig überschreiten.

Durch die geschickte Verwendung von Aggregation (Klassendiagramm folgt später) und die Verwendung der passenden Views auf DB-Ebene kann können so buchhalterische Vorgaben und deren technische einhaltung durch Setzen eines einzigen Wertes, also ohne jegliche Möglichkeit der Dateninkonsistenz, umgesetzt werden.
Doch damit nicht genug: Apache ermöglicht es, Loggingausgaben direkt in eine MySQL-Datenbank zu schreiben. Um das (z.B. monatliche) HTTP-Transfervolumen eines Kunden zu ermitteln, braucht man also nicht mehr als ein SELECT SUM(size) FROM transfer WHERE hostname=[host eines Kunden].

So langsam fängt sie Sache an, wirklich Spaß zu machen ;-)

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: