| Mo | Di | Mi | Do | Fr | Sa | So |
|---|---|---|---|---|---|---|
| « Jul | ||||||
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 | |||||
… dachte ich mir beim Aufstieg letztes Wochenende. Ab ca. 1200 Höhenmetern hat es doch tatsächlich richtig weihnachtlich-besinnlich geschneit. Aus diesem Grunde haben wir nach Ankunft bei der Hütte (gegen 23:30) auch kein Bier, sondern wirklich Glühwein getrunken. 
 
Bin also wieder (fit) zurück, und die letzte Woche gab es so viel zu tun, dass es keine Zeit zum bloggen gab. Es sind aber schon viele neue Themen in der Queue
Um der nun gestarteten Erlanger Bergkirchweih zu entfliehen und sowohl ein bisschen Holz als auch Code zu hacken geht’s zum verlängerten Wochenende in die Berge. Und zwar auf den Dachstein nach Österreich; zusammen mit ein paar anderen Höhlenforschern wird der eine oder andere Baum klein gemacht und zum Trocknen eingelagert.
Allerdings müssen wir diesmal wohl zu Fuß die rund 740 Höhenmeter am Steilhang aufsteigen, da wir die letzte Seilbahn am Freitag Abend wohl nicht mehr schaffen werden. Ich packe nun also möglichst effizient.
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.
Nein, gestern war nicht für alle Feiertag. Für viele Unternehmer war es einer dieser typischen kundenfreien Arbeitstage.
So viel Glück muss man auch mal haben: zwei Sekunden, bevor ich auf den “Start”-Knopf des Kaffeeautomaten gedrückt habe, fällt doch glatt der Strom aus. Ich glaube, eine Kaffeemaschine gehört auch an die USV angeschlossen. Dafür klemme ich gerne meinen PC ab. 
Die erste Ãœberraschung waren die Nudeln mit Spargelsoße, als ich nach Hause gekommen bin. Während dem Essen lief im Hintergrund der Fernseher (eigentlich eher eine Ausnahme), um genauer zu sein: Galileo auf Pro7. Und gleich die nächste Ãœberraschung: ein ausführlicher Bericht über die Skater-Europameisterschaft und “Europas besten Skateboard-Rampen-Bauer”. Ein Kunde von uns. Und der auf vielen Bannern zu sehende Hauptsponsor ist auch bei uns.
Herzlichen Glückwunsch für die positive Publicity!
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:
(*) 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.
Eben hat ein Kunde angerufen und Probleme mit seinem E-Mail-Versand gemeldet. Ein Blick ins Logfile sagte mehr als tausend Worte:
2006-05-12 14:51:11 […] F=<####@######.de> rejected after DATA: This message contains a virus or other harmful content (W97M.Story.Y)
Tja, wenn nur jeder Provider auch ausgehende Mails scannen würde, gäbe es wohl kaum noch Viren…
Und: wenn doch nur jedes E-Mail-Programm so schlau wäre (wie Thunderbird übrigens), und Fehlermeldungen bei SMTP-Verbindungen am Bildschirm anzeigen würde…