RackBlogger

Wir entwickeln hier ja gerade eine phänomental geniale Software (die, für die ich auch OpenSolaris brauche). Die Programmierung erfolgt in zuckerfeinem C/C++, und zwar gleich von Anfang an mit einem Blick auf Sicherheit.

So begab es sich nun, dass ich an diesem (hier übrigens regenfreiem) Morgen begonnen habe, die Klasse zur Erzeugung einer PID-Datei fertigzustellen. Die PID-Datei ist eine kleine Datei, die bei Programmstart erzeugt wird und lediglich die Prozess-ID enthält, damit man dem Programm später mal “von außerhalb” Signale schicken kann, z.B. um es zu beenden.

Nun ist das nicht ganz trivilal, wenn man das sicher machen will. Um genau zu sein: der Prototyp aus 20 Zeilen ist nun etwas über 140 Zeilen lang (inklusive Kommentaren usw.).

Ich programmiere ja derzeit an einem Server. Also nicht an so einem Gerät, sondern an einem Server-Prozess (”Daemon”). Unter anderem soll der auch HTTP sprechen.

Wer nun das HTTP-Protokoll schonmal näher betrachtet hat, wird das “Keep-Alive” von HTTP/1.1 kennen. Das bedeutet, dass die TCP-Verbindung zwischen Client und Server nach Beantwortung der (ersten) Anfrage offen bleibt, um ggf. weitere HTTP-Anfragen darüber zu schicken. Der Vorteil dieser Technik ist, dass nicht für jeden einzelnen HTTP-Request eine komplette TCP-Vebindung auf- und abgebaut werden muss.

Und genau hier unterscheiden sich existierende Webserver zum Teil erheblich: der allseits beliebte Apache httpd hält tatsächlich für jede Keep-Alive-Verbindung einen eigenen Prozess/Thread offen, auch wenn der nur “idle” auf seinen Timeout warten muss. Die Skalierung findet also über die Anzahl der Threads statt.
Ganz anders machen das Zeus oder auch lighttpd: im Prinzip arbeiten diese mit nur einem einzigen Thread; die quasi-Parallelisierung findet über Events statt. Die Idee ist ganz einfach: statt eine Pseudo-Parallelität über Kontextwechsel (Threads) herzustellen, gibt es nur einen einzigen Kontrollfluss. Alle potenziell blockierenden Funktionsaufrufe (vor allem Netzwerk- und Datei-I/O) müssen nicht-blockierend aufgerufen werden. Immer wenn eine Operation zurückkehrt, wird ein Event ausgelöst. Ein Kontrollthread oder ein Zustandsautomat (FSM - Finite State Machine) kümmert sich um die Verarbeitung aller Events im Zusammenhang mit den logischen Verbindungen.

Einen exzellenten Einstieg in das Thema findet man auf der C10K problem Website. In dem wissenschaftlichen Paper “A Design Framework For Highly Concurrent Systems” (PDF) wird ein hybrider Ansatz aus Threads und Events beschrieben. Etwa so eine Architektur kommt in “meinem” Server zum Einsatz.

Bevor noch die Beschwerden einhageln, warum hier aktuell so wenig gebloggt wird, möchte ich dem proaktiv entgegen treten. Im Moment brummt’s ziemlich, weil wir letzte Woche auf einen neuen Sicherheitsmechanismus für’s Shared Hosting umgestellt haben. Die bisher eingesetzte Kombination aus CGIWrap und mod_phpcgiwrap (beide recht üppig für unsere Zwecke gepatched) war nicht mehr wirklich zufriedenstellend. Unflexibel in der Konfiguration, und auch nicht der sauberste/gepflegteste Code.

Was macht man dann als Informatiker? Ja, genau - man schreibt mal eben was eigenes… Herausgekommen ist “seCGI”, das steht für “security enhanced Common Gateway Interface”. Dabei handelt es sich um ein auf suexec, CGIWrap und mod_(php)cgiwrap basierendes System. Und leckere Features gibt’s da:

• Ausführung von CGI- und PHP-Scripten jeglicher Art unter der User-ID des jeweiligen Kunden
• Kundenindividuelle Limitierung von Arbeitsspeicher, CPU-Zeit, Anzahl der Prozesse etc. direkt in der Apache-Konfiguration
• Auswahl des PHP-Interpreters kundenindividuell möglich (*)
• in sauberem C programmiert (nicht C++ wie suPHP; in meinen Augen macht das wenig Sinn für die C-API des Apache ein C++-Modul zu schreiben… inklusive dem ganzen Overhead mit der C++-Runtime usw.)

(*) Zum PHP-Interpreter verweise ich auf unsere Erfahrungen mit dem SourceGuardian-Loader; den betroffenen Kunden haben wir einfach auf 5.0.5 umgestellt, während alle anderen Kunden weiterhin mit PHP 5.1.4 arbeiten. Das soll mal einer nachmachen…

Im Rahmen einer kleinen PR-Aktion soll unser neues seCGI dann auch als OpenSource-Software veröffentlich werden. Schließlich nutzen wir hier auch allerhand OpenSource-Produkte, da ist dass doch eine gute Gelegenheit mal was an die Community zurück zu geben. Das Logo für die Aktion steht auch schon:

Wer es noch nicht weiß: dieses (Wissenschafts-)Jahr ist der Informatik gewidmet. Wir sind nun offizieller Partner, und möchten mit dem Logo auch auf die Aktionen aufmerksam machen. Weitere Infos zum Wissenschaftsjahr finden sich auf http://www.informatikjahr.de.

Endlich läuft’s: OpenSolaris. Also in VMware, meine ich damit. Die Installation verlief nicht ganz trivial, aber dank dem Solaris Blog und kleinen Tipps haben wir nun eine wunderbare OpenSolaris-Umgebung am Laufen, ohne doch noch eine alte UltraSparc aus dem Keller holen und wiederbeleben zu müssen.

Die Installation dient übrigens der Portierung bzw. dem Cross-Development unseres großen Software-Projekts (mehr dazu in einigen Monaten)