Blog - gnuheidix

CSS: prefers-color-scheme

Nur durch reinen Zufall bin ich über das verhältnismäßig neue Media Feature prefers-color-scheme gestolpert.

Motivation

Schon immer haben mich sehr helle Bildschirme gestört und besonders wenn man viele Stunden davor sitzt, ist es für die Augen einfach entspannender, wenn es mal nicht wenig schwarz auf viel weiß sein muss. Seitdem die Desktopumgebung Gnome einen Dark-Mode anbietet, bin ich ein großer Fan davon und eben ist an mir vorbreigescrollt, dass die Browser den bevorzugten Modus ans CSS durchreichen.

Nutzung

Wie man es genau nutzt, muss ich hier jetzt nicht groß ausführen.

@media (prefers-color-scheme: dark) {
  ...
}

Lest Details einfach bei Mozilla nach. Auch die achten übrigens darauf, ob ihr den Dark-Mode bevorzugt.

Bei meinem Blog habe ich mich für ein vollständiges Schwarz im Dark-Mode entschieden, weil mich besonders bei OLED-Displays immer sehr nervt, wenn Leute meinen ein sehr dunkles Grau großflächig verwenden zu müssen. Pixel, die aus sein dürfen, leben länger.

Fazit

Die Unterstützung in mein Blog einzubauen, hat mich nur ein paar Minuten gekostet. Es bisschen könnte ich besonders bei der Kommentareingabemaske noch schrauben, aber alles in allem ist das schon mal recht gut nutzbar.

Mod: Braun IRT6520

Ein Fieberthermometer, dass für den Einsatz an Kindern konzipiert ist und dabei eine nicht deaktivierbare akustische Tastendruckrückmeldung aufweist, ist ja schon eine skurrile Sache.

Motivation

Das IRT6520 verspricht die Körpertemperatur im Ohr messen zu können und dabei relativ genau zu sein. Ich kann bestätigen, dass es eine gute Schätzung im Vergleich zur als exakt einzustufenden rektalen Messung abgibt und dabei praktisch nicht invasiv ist. Wenn man aber dem schlafenden Kind die Körpertemperatur messen möchte, ist der Tastendruckton, welchen es stets von sich gibt, einfach völlig unnötig und sogar störend. Es reicht schließlich aus, dass das Display nach erfolgter Messung die Farbe ändert.

Modifikation

Das Gerät hat im Batteriefach eine TX6-Schraube. Ist diese raus, wird das Gerät noch von sechs Plastiknasen an der linken und rechten Längsseite zusammengehalten. Man kann deren Position sehen, wenn man sich die Fuge zwischen beiden Gehäusehälften genau anschaut. Mit einem sehr dünnen flachen Schraubendreher bekommt man das zerstörungsfrei auf. Das Gehäuse steht unter keiner nennenswerten Spannung, das öffnet sich ohne Gewalt.

Nun sieht man die Leiterplatte und die Sensoreinheit. Beide werden von jeweils zwei kurzen TX6-Schrauben gehalten. Alle vier Schrauben sind zu entfernen und die Leiterplatte samt Sensoreinheit herumzudrehen. An der Sensoreinheit abgewandten Seite findet man den SMD-Buzzer, welcher für die Geräusche verantwortlich ist. Er ist allein auf weiter Flur und man braucht keinen spezialisierten Lötkolben, um ihn auszulöten. Mir hat mein 8W USB-Lötkolben völlig ausgereicht.

Nun baut man das Gerät in umgekehrter Reihenfolge zusammen.

Fazit

Das IRT6520 ist leicht modifizierbar. Hätte Braun das Gerät einmal gegen seine Zielgruppe getestet, wäre bestimmt aufgefallen, dass ein mehrfarbiges Display zur Bewertung der Körpertemperatur gut für übermüdete Eltern ist, der Ton diesen Vorteil aber durch Hinzufügen von Nervenkitzel direkt wieder über Bord wirft.

Ich hoffe, euch hilft dieser Tipp und es bewahrt ein paar dieser Geräte vor der Mülltonne.

Mod: Lenco SCD-24

Unerwünschte nicht deaktivierbare Produktfunktionalitäten bereiten einem oft Kopfzerbrechen. Besonders hat das letztlich ein Geschenk geschafft, welches nicht ohne Weiteres zurückgegeben werden konnte.

Motivation

Es handelt sich um ein Radio mit CD-Spieler, welches für die Nutzung durch Kinder bestimmt ist. Zumindest behauptet das die Produktbeschreibung. In der Anleitung steht: "Wenn das Gerät für ca. 15 Minuten nicht bedient wird, dann schaltet es sich automatisch aus (im Stopp-Modus/ bei geöffnetem CD-Fach)."

Dagegen ist ja ersteinmal nichts einzuwenden. In der Tat war die Funktionalität aber so geschaffen, dass sich das Gerät stets sowohl im Radio- als auch im CD-Betrieb nach ziemlich genau zehn Minuten abgeschaltet hat. Das ist unglaublich nervig, weil es dann erst aus und wieder eingeschaltet werden musste. Weiter ging die CD wieder von vorn los.

Beim Einschalten konnte man stets feststellen, dass sich das Gerät etwa eine halbe Sekunde Zeit gelassen hat, bis die Power-LED an ging. Für ein derartiges Gerät in dieser Preisklasse ist das grundsätzlich ungewöhnlich, weil Steuerungstechnik, die nachdenkt, ob Einschalten jetzt eine gute Idee ist, einfach nur unnötig die Stückliste aufbläst. Normalerweise wacht ein Ferengi über diese Liste, weil er mit einer kürzeren Liste mehr Profit macht.

Meine Vermutung geht in die Richtung, dass diese Zeitsteuerung einfach nur ein zu einer Standardschaltung nachträglich hinzugefügter IC ist, welcher sich ohne Schaltplan leicht umgehen lässt. Ich selbst würde sowas mit einem NE555 realisieren.

Modifikation

Das Gerät ist mit fünf Schrauben an der Unterseite leicht zu öffnen und alle Verbinder kann man zerstörungsfrei abstecken. An der Oberseite war auch noch ein markiertes Schraubenloch, aber da hat der Hersteller einfach keine Schraube reingeschraubt.

Der fragwürdige IC ist sehr schnell gefunden. Auf der Oberseite hat er keine Beschriftung. Pin 1 ist VCC und Pin 8 ist GND. Die Pins 2 und 3 sind nicht angeschlossen. Ich habe den IC, welcher meines Erachtens ein kleiner PLC ist, entfernt und nach ein wenig Messen hat sich gezeigt, dass lediglich Pin 5 und 7 überbrückt werden müssen, um dem Rest des Gerätes das Gefühl zu geben, dass die zehn Minuten noch nicht um sind.

Das Gerät schaltet sich nun auch ohne Gedenksekunde ein. Im eingeschalteten und ausgeschalteten Zustand hat sich der Stromverbrauch nicht geändert. Die Lösung macht einen richtigen Eindruck.

Fazit

Leider wird das Gerät nicht wie einst üblich mit einem Schaltplan geliefert. Die EU sollte hierfür mal eine klare Regelung schaffen, um Geräte reparier- und modifizierbar zu machen.

Meine NE555-Lösung wäre zu kompliziert gewesen für eine optimierte Stückliste und PLCs scheinen einfach billig genug zu sein.

Eine konfigurierbare maximale Lautstärke oder ein verschraubtes Batteriefach hätte ich für ein Kinderradio als sinnvoller erachtet als eine Zeitschaltung, welche jedes Hörspiel oder Märchen mit hoher Präzision versaut.

Ich hoffe sehr, dass dieser Beitrag ein solches Gerät vor der Müllkippe bewahrt.

Lasst euch dieses Gerät nicht schenken. Die Gesamtkonstruktion ist auch für ein Kinderradio einfach ungenügend.

Nachtrag

Auf der Unterseite des IC steht nach genauem Hinsehen 3CF1946T 028-4. Eine kurze Suche war dazu erfolglos.

Sommer: Lüftungsapparatur

Unser globales Terraforming-Experiment beschert uns jeden Sommer wärmere Temperaturen. Auch wenn man nicht im Dachgeschoss wohnt, kann man die Raumtemperatur bei wochenlang anhaltendem heißen Wetter nur schwer unter Kontrolle bringen. Mein Lösungsansatz ist seit mehr als einem Jahr mit Erfolg im Einsatz.

Motivation

Es handelt sich um eine eingeschossige Wohnung mit Fenstern zur Nord-, West- und Südseite. Bei kontinuierlich heißem Wetter ist es in der Regel nach mehr als einer Woche trotz geschickter Lüftungsstrategie und konsequenter Abschattung nicht mehr möglich, die Wärme in der Wohnung unter 26°C zu halten, ohne Einbußen bei CO₂- und Luftfeuchtigkeitsniveau hinnehmen zu müssen.

Nachts sinken die Außentemperaturen auf ein angenehmes Niveau, aber mangels hinreichender Luftzirkulation kühlen die Räume trotz vollständig geöffneter Fenster nur unzureichend ab. Darüberhinaus stellen sperrangelweit offene Fenster ein potentielles Sicherheitsproblem dar.

Basierend auf meinen Erfahrungen mit Kühlung in Computergehäusen habe ich die dort zur Anwendung kommenden Konzepte auf die gesamte Wohnung angewendet.

Konzept

Es soll keine dauerhafte Installation sondern lediglich ein Fenstereinsatz sein, welcher die Raumluft nach Draußen zur Westseite abführt. Durch die Öffnung des am weitest entfernten Nordseitenfenster und dem gezielten Öffnen bzw. Schließen der Türen ist der Luftstrom der kühlen Nordseitenluft durch vier Räume zu führen. Weiter gilt es, die Intensität des Luftstroms regulierbar zu machen.

Fenstereinsatz

Das Ganze basiert auf einem Lüfter aus dem Kfz-Bereich und einer dicken Sperrholzplatte. Diese wird im Fensterrahmen mit kleinen Riegeln an dessen Beschlägen gehalten. Auf der Außenseite ist eine Art Gitter angebracht, welches ein modizifizierter Grillrost ist, um Tiere vor dem Eindringen abzuhalten. Auf der Innenseite habe ich solide Schubladengriffe aus Aluminium angebracht, die beim Einsetzen- und Herausnehmen helfen.

Der Lüfter ist ein Noname-Modell und hat 80W Leistung. Man muss darauf achten, dass die Anlaufleistung stets erheblich höher ist. Aus dem Stillstand direkt auf 100% Drehzahl hat er bei meinen Messungen bis zu 160W gezogen. Mit einem 200W-Netzteil sollte man auf der sicheren Seite sein. Der Luftdurchsatz ist auf allen Verkaufsplattformen, auf denen dieser Lüfter vertrieben wird, anders angegeben. Es ist aber genug für den Anfang, habe ich festgestellt.

Es ist noch genügend Platz in der Holzplatte für einen weiteren baugleichen Lüfter, welcher bei fortschreitender Klimaerwärmung hingezufügt wird.

Stromversorgung

Aus Gründen der Einfachheit habe ich mich für ein PC-Netzteil entschieden, welches ich bereits im Keller hatte. Das Gute daran ist, dass solche Netzteile für diese Zwecke mit stets hinreichender Qualitätsanmutung und Leistung daherkommen. Die 12V-Versorgung ist in der Regel für besonders energiehungrige Komponenten, wie Grafikkarten, mehr als ausreichend dimensioniert. Nichtsdestotrotz sind stets die technischen Details zu prüfen, da der Spaß schließlich unbeaufsichtigt die ganze Nacht entspannt durchlaufen soll. Abbrennen sollte bei diesen Netzteilen nichts, da sie in der Regel mit Überhitzungs- und Überlastschutzschaltungen ausgestattet sind.

Zur Einstellung der Lüfterdrehzahl habe ich einen PWM-basierten Regler eingesetzt. Bei diesen Reglern ist unbedingt darauf zu achten, dass die Steuerfrequenz über 20kHz liegt, sonst hört man ein nerviges Pfeiffen.

Nach dem Drehzahlregler ist ein analoges Amperemeter geschaltet. Es kommt problemlos mit dem PWM-Signal zurecht und hilft sehr beim Betrieb. Sobald es dauerhaft mehr als 7A anzeigt, ist etwas nicht in Ordnung.

Von Bahar Enclosure gibt es sehr schicke Gehäuse für derartige Projekte. Ich habe mich für das Modell BDA-400 in der Variante 220*120*275 mm with handhold entschieden. Es macht einen soliden Eindruck, obwohl die Ober- und Unterseite nur über selbstschneidende Schrauben in den Plastikelementen der Vorder- und Rückseite zusammengehalten werden. Mehr als zehn Mal kann man das Gehäuse deshalb nicht auf- und zuschrauben, bevor die Schrauben ihren Biss verlieren. Es spricht aber nichts dagegen die mitgelieferten Schrauben durch ordentliche Senkkopfschrauben mit Muttern zu ersetzen. Die Plastikteile haben hinreichend Material, um die Muttern gut integrieren zu können.

Obwohl das PC-Netzteil einen recht großen, nach draußen blasenden Lüfter eingebaut hat, ist der erzeugte Luftstrom nicht gut genug, um die Abwärme der Kühlkörper des Drehzahlreglers abzuführen. Deshalb habe ich an der Vorderseite einen Lüfter eingebaut, welcher direkt auf diese Kühlkörper bläst. Weiter hat der Netzteillüfter schon einiges seiner Lebensdauer verbraucht und sobald er ausfällt gibt es noch einen anderen, der alles vor dem Hitzetod bewahrt.

Den PWM-Ausgang habe ich mittels dreipoliger XLR-Steckverbinder gelöst. Das mag jetzt für Leute aus der Tontechnik unentspannt sein, weil man jedes ihrer Geräte beim Anschluss direkt zerstören kann, aber ich versichere, dass der Kasten die Wohnung nicht verlässt. Weiter habe ich zwischenzeitlich eine entsprechende warnende Beschriftung aufgeklebt. Das tolle an den XLR-Verbindern von Neutrik NC3MXX und NC3FD-LX ist ihre überaus solide Machart, welche eine praktisch unverwüstliche und präzise gefertigte Qualitätsanmutung aufweist. Die Buchse verriegelt auch den Stecker, sodass nichts abrutschen kann.

Nutzung

Innerhalb von drei Minuten hat man das Netzteil aus dem Schrank geholt und den Fenstereinsatz eingehängt. Meist lasse ich den Lüfter zwischen 40 und 80% laufen, weil das zum einen völlig ausreicht und zum anderen die Geräuschentwicklung im Rahmen hält. Auf voller Lüfterdrehzahl kann man sich nur mit Mühe längere Zeit im Raum aufhalten. Er rauscht eben einfach wie ein Kfz-Radiatorlüfter. Bei denen wird auf Luftdurchsatz anstatt auf Geräuschentwicklung optimiert.

Der Luftdurchsatz ist auch bei 60% Leistung groß genug, sodass man Kraft braucht, wenn man die Tür, die den letzten großen Luftweg durch die Wohnung schafft, schließen möchte. Da pfeift es durch alle Türritzen und Schlüssellöcher, wenn man sie trotzdem schließt. Der Lüfter dreht dann direkt ein wenig langsamer und der Strommesser zeigt an, dass sich der Lüfter mehr anstrengen muss als normal.

Wenn in der Nacht draußen 22°C und in der Wohnung 26°C sind, schafft man es mit der Lösung, bis zu ein Grad pro Stunde zu reduzieren. Meist läuft der Lüfter nur die erste Stunde auf Maximum, um fürs Schlafen eine angenehme Temperatur zu schaffen, um dann mit etwa 60% Leistung über die Nacht zu kommen. Wenn draußen tagsüber 30°C und nachts 20°C herrschen und in der Wohnung abends beim Einschalten knapp 26°C sind, ist die Raumtemperatur am Morgen auf etwa 22°C gesunken. Es ist aber wichtig, nicht zu verschlafen, da sonst wieder wärmere Luft von außen in die Wohnung transportiert wird.

Fazit

Diese Lösung war einst lediglich als Experiment gedacht, aber jetzt ist sie zum festen Bestandteil des Lebens im Sommer geworden.

Ich hoffe, dass ihr wie ich durch eine derartige Bastelei auf die Anschaffung einer richtigen Klimaanlage verzichten könnt.

Nachtrag

31.07.2020:

Falls ihr es dennoch nicht aushaltet und eine Klimaanlage kauft, achtet bitte stets darauf, dass sie mit einem Kühlmittel geladen ist, welches bei Austritt keinen katastrophalen Schaden an unserer Erdatmosphäre anrichtet. Diese haben einen sehr kleinen GWP-Wert in dieser Liste. Isobutan (R600a) und Propan (R290) sind beispielsweise welche von den klimafreundlichen Mitteln. Gleiches gilt für Kühlschränke, Wärmepumpentrockner und anderen Geräte, in denen Kältemittel ist. Gute Hersteller schreiben die Kältemittelnummer mit in die technischen Details eines Produktes auf ihrer Website. Letztlich hatte ich die Wahl zwischen einem Modell, dass bei einem Kältekreislaufleck 1,5t CO₂-Äquivalent in die Atmosphäre entweichen lässt und einem anderen Modell, bei dem es nur knapp ein Kilogramm ist.

24.06.2021:

Video ansehen

Der Noname-Lüfter fällt immer mehr durch eine erhöhte Geräuschentwicklung auf. Noch ist der Stromverbrauch unverändert, aber es ist abzusehen, dass sich die Lager im Motor verabschieden. Vermutlich waren sie erhöhtem Verschleiß ausgesetzt, weil das Lüfterrad nicht sauber ausgewuchtet ist. Das Vibrationsniveau war von Anfang an nicht brillant.

Um das Problem zu beheben, habe ich mich für einen VA18-AP70/LL-86S von Spal entschieden. Der ist zwar völlig überdimensioniert, aber das Ziel ist nicht, ihn auf voller Leistung laufen zu lassen. Mit 3450m³/h maximalem Luftdurchsatz, ist er mehr als doppelt so leistungsfähig wie der bisherige und er muss noch weniger arbeiten, um den gewünschten Luftstrom zu erzeugen. Die Spezifikation des Lüfters weist ihn mit einer maximalen Stromaufnahme von 17,4A aus, was fast das dreifache des bisherigen Lüfters ist. Das von mir eingesetzte 300W PC-Netzteil reicht mit den 18A (21A kurzzeitig) auf der 12V-Schiene gerade so aus. Den PWM-Regler musste ich aber größer dimensionieren, um ruhig schlafen zu können.

Video ansehen

Erste Tests des Spal sind äußerst vielversprechend. Er zieht 15A ohne Gegendruck und erzeugt praktisch keinerlei Vibrationen. Er schafft gefühlt bei 5A die selbe Menge an Luftdurchsatz wie der alte bei 7A und macht dabei ein angenehmeres ruhiges rauschendes Geräusch. Wenn man ihn voll aufdreht, ist er natürlich bei weitem lauter.

Mod: Grunwerg SS30R

Warmes Wasser ist für den Windelwechselvorgang in meiner Familie zentraler Bestandteil und um dies stets verfügbar zu machen, haben wir uns für eine Pumpthermoskanne (SS30R) entschieden. Dies funktioniert hervorragend, aber man braucht für die Bedienung leider zwei Hände.

Motivation

Bei der Bedienung der SS30R in unmodifizierter Form hält man mit der einen Hand den Lappen und mit der anderen pumpt man Luft in die Kanne mithilfe des integrierten Blasebalgs. Es ist jedoch grundsätzlich erforderlich, eine Hand immer am Kind zu haben.

Modifikation

Das Pumpen der Luft gilt es mit dem Fuss auslösbar zu machen, da einer zum Stehen ausreicht. Ich bin zufällig über eine regelbare Aquariumpumpe gestolpert und habe diese mit ein paar anderen Teilen kombiniert, die ich noch herumliegen hatte.

Der Kern der Modifikation ist das Ersetzen des Blasebalgs und die Verstärkung des Kannendeckels bis zu dem Punkt, ab der er im Stande ist, den Thermosdeckel so straff auf die Kanne zu drücken, damit die unterdimensionierte Dichtung hinreichend abdichtet, sodass die im Vergleich zum Blasebalg geringe Luftpumpleistung der Aquariumpumpe ausreicht, um das Wasser aus der Kanne zu drücken.

Bewährt hat sich ein zurechtgeschnittener Heinz-Bohnenbehälter, der zum einen gut in den blasebalgumschließenden Deckel passt und zum anderen strukturell stabil genug gebaut ist. Dies alleine reicht allerdings nicht aus, da der obere Ring des Kannendeckels nur eingeschnappt ist und der Bohnenbehälter so nicht hinreichend auf die Druckplatte zum Thermosdeckel wirken kann, ohne dass der obere Ring herausschnappt.

Abhilfe für diese Unterdimensionierung schaffen mehrere zum Drittelkreis gebogene Stricknadeln, die im Schnappmechanismus versenkt und mit Heißkleber großzügig vergossen werden.

Damit hinreichender Druck zwischen Druckplatte und Thermosdeckel hergestellt wird, haben sich Einmachglasgummis bewährt. Je nach Zuschnitt des Bohnenbehälters kann man hier in der Anzahl variieren.

Die Aquariumpumpe hat bereits einen dünnen Silikonschlauch und ein Rückschlagventil im Paket dabei und diese Teile können direkt mit benutzt werden. Der dünne Schlauch passt perfekt in den 6x8er Schlauch, welcher wiederum sehr gut abdichtend direkt in den Thermosdeckel passt. Mithilfe einer Druckfeder kann man einen zweckmäßigen Knickschutz am Kannendeckel realisieren.

Einen Absperrhahn habe ich nachträglich hinzugefügt, um im Krabbelalter keine Überschwemmungen zu haben. Besser wäre hier allerdings ein Trennschalter oder ein Entlüftungsventil, um Druckaufbau direkt zu verhindern.

Die Regelbarkeit der Pumpe ist relevant, da bei voller Thermoskanne eine niedrige Pumpleistung völlig ausreichend ist, da kaum Luft komprimiert werden muss. Beim letzten Drittel des verbleibenden Wassers in der Kanne ist es praktisch, die Pumpleistung erhöhen zu können, um den Druckaufbau zu verkürzen. Da die Kanne nicht perfekt dicht ist, sinkt der Innenluftdruck kurz nach der Nutzung schnell zurück auf Umgebungsdruck ab, wodurch die Pumpe bei leerwerdender Kanne die Luft immer erst soweit verdichten muss, damit das Wasser nach draußen gedrückt werden kann.

Der Grobhandtaster ist kombiniert mit dem beliebig teilbaren Verlängerungskabel großartig für den kurzzeitigen Betrieb der Aquariumpumpe. Die Beschriftung mit "Alarm" ist in meiner Realisierung ein wenig irreführend, aber einen anderen Taster mit hinreichender Wasserdichtigkeit hatte ich gerade leider nicht in meinem Fundus.

Fazit

Die vorliegende Modifikation stellt für unsere Anforderungen die optimale Lösung dar. Waschbare Mulllappen wie diese sind unseres Erachtens Einmalfeuchttüchern stets vorzuziehen. Im Außeneinsatz nutzen wir sie in Kombination mit einer kleinen Dessertschüssel und einer sowieso stets vorhanden Wasserflasche.

Ich hoffe, diese Lösung hilft noch anderen Leuten. Für uns ist sie nicht mehr wegzudenken.

Nachtrag

19.07.2020: Ich habe euch eine Teileliste mit kleinen Hinweisen zusammengestellt.

13.08.2020: Heute ist die Spule der Aquariumpumpe mit einem Plopp ausgestiegen. Glücklicherweise war das nur die oberste Windung, die durchgebrannt ist und ich konnte die Spule schnell reparieren. Habt bestenfalls ordentlichen Lackdraht daheim, um die Spule zur Not neu wickeln zu können.

22.11.2020: Die Spule der Aquariumpumpe hat heute endgültig versagt. Dieses Mal waren mehr als 20 Windungen gleichzeitig ausgestiegen und die Geruchsentwicklung war auch nicht schlecht. Lackdraht habe ich gerade nicht hinreichend zur Hand. Ich probiere jetzt einen Pumpenhersteller aus dem Nebenort. Drückt mir die Daumen, dass die länger hält.

23.11.2020: Die Schego 850 macht von der Verarbeitungsqualität und dem Luftdurchsatz her einen überragend guten Eindruck. Ich bin begeistert und hoffe, dass ich nun an der Front Ruhe habe.

Mod: Angelcare Classic XL

Auf das Thema Nachwuchs haben sich eine Menge Industriezweige eingeschossen, um Eltern das Geld aus der Tasche zu ziehen. Beim Windeleimer fängt es an.

Es gibt eine große Anzahl vorgefertigter Lösungen, von der mich keine als Ganzes überzeugt. Es gibt immer etwas, was man Nachkaufen muss und es wird alles erheblich mehr als bei üblichem Marketing mit fadenscheinigen Alleinstellungsmerkmalen versehen.

Grundsätzlich ist es für mich neu gewesen, Fäkalien - wenn auch zeitlich begrenzt - in der Wohnung zwischenzulagern. Obwohl ich ein großer Fan des Youtube-Channels draingo1 bin, hat mich dieses Thema im Vorfeld sehr beschäftigt, um es so komfortorientiert wie möglich zu gestalten.

Motivation

Ich bin über den Angelcare Classic XL (2370) für rund 10€ gestolpert und habe mir gedacht, dass es sicher einfache Wege gibt, die Primärfunktion ohne ständiges Nachkaufen von Kartuschen für ca. 7€ das Stück nutzen zu können. Mit einer Kartusche kann man den 2370 vier Mal laden. Alleine das Plastik der Kartuschen ist unnötige Ressourcenverschwendung. Es reicht mir der Umweltschaden der Einwegwindeln.

Lustig ist der Name, den sich die Firma auf der Kartusche gegeben hat. Tja, da ist der Name perfekt gewählt und ich habe auch herausgefunden, dass sie eine ähnliche Produktserie als Katzenklokotzwischenlager vermarkten.

Modifikation

Sobald man die eine mitgelieferte Kartusche leergefahren hat, baut man den Beutelabschneider im Inneren des 2370 aus, da dieser nun nicht mehr gebraucht wird und potenziell im Weg ist, insofern man nicht plant Endlosbeutel zu nutzen. Am besten ist es natürlich, wenn man ihn beim initialen Zusammenbau garnicht erst installiert hat. Man kann ihn am einfachsten entfernen, indem man den Scharnierstift, welcher beide Eimerhälften verbindet, kurzzeitig halb herauszieht.

Die leere Kartusche entnimmt man dem 2370 und wärmt schon einmal die Heißklebepistole an. Man merkt spätestens jetzt, wenn man sich das Teil genau anschaut, dass es strukturell so ausgelegt ist, dass es die vier Ladevorgänge gerade so überlebt, bevor Teile abbrechen. Von der Unterseite betrachtet sieht man eine Falz, an welcher der innere Ring und das äußere Beutelreservoir zusammengeklipst und minimal geschweißt ist. Das bekommt man ohne Werkzeug mit Fingerspitzengefühl problemlos auf. Falls der Hersteller seine Pressschweißmaschine zwischenzeitlich rekonfiguriert hat, dann schneidet man es mit einer kleinen Trennscheibe einfach auf.

Besonders der innere Ring, an welchem der Beutel anliegt, sieht über die Zeit einigen mechanischen Stress und um ihn zu verstärken, bietet es sich an, die Löcher am inneren Ring von unten mit Malerkreppband zur verschließen und eine Schicht Heißkleber rundherum zu verteilen. Sobald das trocken ist, entfernt man das Kreppband und wiederholt die Prozedur von unten. Sollte eure Kartusche am oberen Rand des inneren Rings, an dem der Beutel vorbeigeführt wird, scharfe Kanten haben, dann schleift sie einfach mit etwas feinem Sandpapier ab.

Steckt beide Hälften wieder zusammen. Verklebt sie mit Heißkleber insofern man nicht plant, Endlosbeutel zu nutzen.

Ihr werdet merken, dass die Kartusche nun einen erheblich vertrauenserweckenderen Eindruck an den relevanten Stellen macht.

Beutelwahl

Grundsätzlich hat man die Wahl zwischen Endlos- und konventionellen Plastikbeuteln. Es gibt Anbieter, die sich darauf spezialisiert haben, am Nachkaufwahnsinn teilzuhaben und umweltfreundlichere Lösungen bereitstellen, die minimalen Mehraufwand mit sich bringen.

Ich kann zu den Endlosbeuteln nichts weiter sagen, da ich mich für den konventionellen Weg entschieden habe.

Ich empfehle, dass man Beutel mit etwa 70 Litern Fassungsvermögen wählt, die höher als breit geschnitten sind. Der innere Klappenmechanismus des 2370 bedarf etwas Zusatzbeutelmaterial, deswegen die großzügige Dimensionierung. Für Stillstuhl empfehle ich Beutel aus HDPE mit einer Stärke von mindestens 10 µm. Für alles, was danach kommt, sollten es 15 µm oder mehr sein. Ich selbst nutze aktuell AG-264 mit 9 µm. Die funktionieren gut, wenn man nicht stopft, sobald der 2370 voll ist. LDPE-Beutel sollten über 20 µm haben, falls man sich für sowas entscheidet.

Ich habe diesbezüglich viel getestet und alles, was der Spezifikation eines Gelben Sacks nahe kommt, ist gut genug.

Nutzung

Um den 2370 nun zu laden, entfaltet man den Beutel vollständig, zieht ihn in die Länge und führt ihn bei geschlossenem Eimer durch die Klappe, sodass noch etwa 10 cm Beutel an jeder Kante sichtbar sind. Nehmt einen stumpfen schmalen Gegenstand und drückt den Beutelüberstand von oben in das Beutelreservoir der Kartusche. Nehmt ein Gummi und fixiert die Geschichte. Bei mir hat sich hierfür ein abgebrochener Schaschlikspieß und ein ausgemustertes Stirnband, dass ich mit einer Schlaufe versehen habe, bewährt.

Zum Entladen entfernt ihr das Gummi, holt den Beutelüberstand aus dem Reservior und öffnet den Eimer. Nehmt die Beutelöffnung nicht allzu fest in die eine Hand und komprimiert den Beutelinhalt in das untere Eimerteil mit der anderen Hand, sodass die Luft entweicht, um Kapazität der schwarzen Tonne zu sparen. Verschließt den Beutel mit einem Knoten.

Ich habe letztendlich immer einen monolithisch anmutenden Würfel von etwa 30 cm Kantenlänge.

Fazit

Alles, was häufig genutzt wird, sollte so wenig wie möglich im Weg sein, um den Frustfaktor von unnötig empfundener repetitiver Arbeit zu minimieren. Mit meinem Lösungsansatz habe ich meines Erachtens einen guten Weg gefunden, nicht mehr an die Firma gebunden zu sein, die versucht aus Scheiße Geld zu machen. Nebenbei habe ich Müll ohne Komfortverlust reduziert.

Ich hoffe, dass diese Erkenntnisse jemand anderem Zeit sparen, die anderswo sicherlich besser investiert ist.

Nachbau

Falls ihr überlegt, die Kartuschen robust und wiederverschließbar nachzubauen und zu vertreiben, dann vergesst es besser schnell wieder. Obwohl es mir technologisch unerklärlich ist, hat die Firma es wie auch immer geschafft, das Design in den Vereinigten Staaten, Japan und China zu patentieren.

Mod: Comandante C40

Die handbetriebene Kaffeemühle Comandante C40 ist unglaublich gut in allen Belangen. Wenn man aber widererwartend körperlich den Handbetrieb nur mit Mühe benutzen kann, wird der Weg zum Kaffeegenuss steinig.

Motivation

Aktuell nutze ich meine Arme mehr als sonst und ich finde es sehr entspannend, wenn sie mal eine kurze Pause haben. Meine Kaffeemühle braucht also eine Erweiterung, welche die Entspannung nicht behindert.

Ich habe zwar noch meine alte elektrische Kaffeemühle im Keller, aber bei der ist das Endprodukt bei weitem nicht so gut. Auch ein zeitweiser Wechsel zurück war für mich keine Lösung.

Modifikation

Die Comandante besitzt einen 5,5 mm Sechskantantrieb, welcher magnetisch am Kurbelelement gehalten wird. Mit ein paar Teilen aus dem Werkzeugkasten, ist schnell ein passender Kurbelersatz konstruiert, welcher mit jedem Akkuschrauber angetrieben werden kann.

Es braucht hierfür eine 5,5 mm Nuss, ein 1/4" Kugelgelenk und einen 1/4" Vierkant auf Sechskant-Adapter. Die Plexiglasscheibe kann man weglassen oder von der Kurbel auf die Nuss übertragen. Ich hatte die Scheibe noch von einer Ersatzkurbel übrig.

Anstatt des Kugelgelenks hatte ich erst ein Kreuzgelenk im Einsatz, aber das ist von der Handhabung her nicht bedienfehlerresistent, was besonders im halbwachen Geisteszustand ein wichtiger Faktor ist.

Beispielsweise in Verbindung mit dem Bosch IXO hat man nun eine elektrische Kaffeemühle. Es ist aber ratsam, die Mühle mit nicht mehr als 200 min^-1 zu drehen. Die Kaffeemühle würde das mit ihrer Kugellagerung ohne Probleme aushalten, aber dem Kaffee würde das bestimmt nicht gut tun.

Fazit

Not macht erfinderisch und ich hoffe, das hilft jemandem anders genauso, wie es mir geholfen hat.

Nachtrag

11.07.2020: Wie sich herausstellt, gibt es ein solches Produkt bereits für Gewürze.

Mod: Bosch GAS 18V-1

Der Akkusauger GAS 18V-1 ist gut verarbeitet, praktisch und preiswert, insofern man bereits Akkus und Ladegerät der Bosch 18V-Linie hat. Leider fehlt ihm aber für die Nutzung abseits der Werkstatt die Filterfähigkeit für den feinen Hausstaub.

Motivation

Der Staubsauger ist prima, um das Chaos beim Basteln im Rahmen zu halten. Leider habe ich aber feststellen müssen, dass der vliesbasierte Filter (Hygienefilter) mangels hinreichender Vorfilterung beim Aufsaugen von Hausstaub übermäßig belastet wird und dadurch das Gerät schnell an Saugleistung verliert.

Ich betrachte das nicht als konzeptionellen Fehler des Gerätes, weil es meines Erachtens nur für groben Schmutz konzipiert wurde.

Modifikation

Ich habe mir das Filtersystem genau angeschaut und angepasst, sodass es von den Filterstufen her an meinen AEG AUFGREEN angelehnt ist. Der AEG ist wie der Bosch zyklonbasiert.

Der AEG hat den Hygienefilter nach dem Motor, was eine unfassbare Fehlkonstruktion ist, weil sich der Motor und sein umgebendes Gehäuse mit der Zeit komplett mit sehr feinen Partikeln füllt. Das macht der Bosch mit seinem Filter direkt vor dem Motor besser.

Der AEG hat allerdings einen Feinstaubfilter, welcher einen sehr großen Teil der feineren Partikel auffängt. Den hat der Bosch leider nicht, weil der Hersteller vermutlich die notwendigen Schritte für die Schmutzbehälterleerung so gering wie möglich für den Werkstattbetrieb halten wollte.

Der Bosch hat im Vergleich zum AEG nur einen sehr groben Innenfilter aus transparentem Plastik mit Löchern von etwa einem Millimeter. Der AEG hat ein Innenfiltergitter aus Nylon mit Löchern von etwa 0,3 mm für die kleinen Fussel, die nicht von der zyklonbasierten Filterung erfasst werden. Das macht der AEG eindeutig besser.

Feinstaubfilter

Direkt vor dem Hygienefilter ist hinreichend Platz, um Filterschwämme passender Größe einzubauen. Hier habe ich die Ohrpolster eines ausgedienten Kopfhörers, welche zufällig gerade perfekt vom Durchmesser her gepasst haben, eingesetzt und aus einer Papprolle Abstandshalter zugeschnitten. Die beiden Halteelemente sind erforderlich, weil die von mir eingesetzten Filter, welche in etwa 60 ppi haben, zu dünn sind, um alleine vom Hygienefilter gehalten zu werden. Wenn man einen Filterschwamm herumliegen hat, der etwa 2-3 cm Dicke aufweist, kann man sich die Halter sparen.

Optimal wäre meines Erachtens eine Filterschwammkombination aus 60 und 10 ppi hintereinander. Das feine 60er fängt den Feinstaub und das 10er steuert strukturelle Festigkeit bei. Die Idee ist nicht auf meinem Mist gewachsen, sondern an dem mir bekannten Sockelfilter der Miele T1 angelehnt.

Innenfiltergitter

Ein Obst- und Gemüsenetz von meinem Supermarkt, welche seit etwa einem Jahr als Plastikbeutelersatz angeboten werden, habe ich mehrlagig genäht, sodass es um den Innenfilter gewickelt und mit Schlüpfergummis gehalten werden kann. Die Gummis hätte ich natürlich auch in das Filternetz integrieren können. Mangels Zeit habe ich die provisorische Variante gewählt, welche bei jeder Filterreinigung etwas aufwändiger zu reinstallieren ist.

Fazit

Der Akkusauger funktioniert nun klasse im gesamten Haushalt und die neuen Filter können unter fließendem Wasser gereinigt werden. Die Wartung hat jetzt natürlich mehr zu erledigende Schritte.

Es wäre klasse, wenn Bosch diese Filtererweiterung vorgefertigt für dieses Gerät anbieten könnte.

Hinweis zum AEG AUFGREEN

Bitte seht vom Kauf eines AEG AUFGREEN ab, weil der nachgelagerte Hygienefilter die Luft zwar reinigt, aber der im inneren verschmutzte Motor nur äußerst aufwändig gereinigt werden kann. Das Gerät ist zwar vollständig zerlegbar, aber das klappt höchstens zehn Mal, weil die schraubenarme Konstruktion mit seinen vielen Plastiknasen bei jeder Reinigung kontinuierlich schwächer wird.

Weiter bricht die Verbindung vom Drehzahlregler zum Poti alleine beim scharf ansehen. Viele Dichtungen sind nicht dicht, was zu Saugleistungsverlust führt. Das Innenfilternetz wird bei Hausstaub stark belastet, weil wohl die Zyklonfilterung unzureichend arbeitet. Der Feinstaubfilter ist schnell dicht und die Saugleistung im Keller.

Viel besser konzipiert und wartbar ist hingegen ein Miele CX1.

Nachtrag

12.07.2020: Auch für die handwerkliche Nutzung ist der Feinstaubfilter von Vorteil. Hier sind die improvisierten Feinstaubfilter, nachdem Bohrstaub eingesaugt wurde, zu sehen. Der nachgeschaltete Hygienefilter sieht nach wie vor aus wie neu und riecht auch nicht nach Bohrstaub.

HTTP/2: off

Ich hätte ja nicht gedacht, dass ich so schnell wieder den Stecker dieses Protokolls ziehen muss. Netflix hat eine Analyse veröffentlicht, welche auf inkorrekte Behandlung von Sonderfällen bei Implementierungen von HTTP/2 hinweist, die zu Denial-of-Service-Attacken genutzt werden können.

Motivation

Netflix hat schon einmal CVEs angemeldet und hat klar herausgearbeitet, dass sich die zugehörige RFC7540 größtenteils nur auf den Happy Path bezieht und Sonderfälle und Angriffsszenarien der individuellen Implementierung überlässt. Obwohl noch nicht klar ist, welche Implementierungen konkret für welche CVEs betroffen sind, deaktiviere ich es vorsichtshalber überall.

Der Fakt der vagen RFC ist für mich Grund genug, alle Implementierungen als nicht hinreichend vertrauenswürdig einzustufen, bis das Gegenteil individuell bewiesen ist. Die Qualität einer Protokoll-Spezifikation liegt in genau diesen Details. Die RFC ist von 2015. Vier Jahre, schade, dass sich erst jetzt Leute damit beschäftigen.

Fazit

Danke Netflix!

Nachtrag

16.08.2019: Ubuntu hat USN-4099-1 veröffentlicht.

nginx: ECDH mit mehreren Kurven

Erst letztlich habe ich ein Distributions-Upgrade meines Servers durchgeführt und nun kann ich mich an den vielen neuen Features erfreuen. Bisher konnte ich nginx nur eine ECDH-Kurve nutzen lassen. Das hat sich geändert.

Der Webserver nginx kann mit Version 1.11.0+ in Verbindung mit OpenSSL 1.0.2+ den TLS-Schlüsselaustausch abhängig von den Fähigkeiten der sich verbindenden Clients mit unterschiedlichen Kurven durchführen. Das ist eine positive Entwicklung, weil man sich nicht mehr auf einen kleinsten gemeinsamen Nenner als Kompromiss einigen muss.

Konfiguration

Standardmäßig überlässt nginx die Entscheidung, welche Kurven zu verwenden sind, OpenSSL. Der Default ist:

ssl_ecdh_curve auto;

Bei mir hat dies jedoch dazu geführt, dass die Kurven in der Prioritätenreihenfolge x25519, secp256r1, secp384r1, secp521r1 stehen. Das mag aus Performancesicht Sinn ergeben, aber wenn man die Transportsicherheit auf 11 drehen möchte, braucht es imho eine andere Reihenfolge.

Ich nutze diese Konfiguration:

ssl_ecdh_curve X25519:secp521r1:secp384r1:prime256v1;

Das belohnt natürlich jeder vernünftige TLS-Tester und vor allem fortschrittliche Clients, die NIST-Kurven für vertrauensunwürdig halten, freuen sich.

Fazit

Sinnvolle Defaults sind gut und wichtig für jedes Stück Software. Man sollte aber jeden noch so guten Default hinterfragen, ob er zu den Anforderungen passt.

DNS: CAA Resource Record

Das Vertrauen in TLS und damit auch in HTTPS basiert für normalsterbliche Leute auf dem Vertrauen in die vielen Zertifizierungsstellen, die bei Betriebssystemen und Browsern vorkonfiguriert sind. Ein Sicherheitsproblem in auch nur einer Zertifizierungsstelle (CA) reicht, um das ganze System unsicher zu machen.

Motivation

Die Geschichte der CAs ist gespickt mit Fehlern. Nur wenige haben eine weiße Weste.

Ab September 2017 haben sich alle CAs selbstverpflichtet den Certification Authority Authorization (CAA) Resource Record (RR) bei der Ausstellung eines jeden Zertifikats zu prüfen.

CAA RR

Der CAA RR ist im RFC6844 beschrieben und definiert, dass man im DNS hinterlegen kann, welche CA einem ein Zertifikat ausstellen darf. Im Falle von Let's Encrypt sieht das z.B. wie folgt aus.

example.com.    CAA    0 issue "letsencrypt.org"
example.com.    CAA    0 issuewild ";"
example.com.    CAA    0 iodef "mailto:bla@example.com"

Der Eintrag issue und issuewild beschreibt, welche CAs erlaubt sind. Da Let's Encrypt keine Wildcardzertifikate ausstellt, ist dies im Beispiel deaktiviert.

Mit iodef kann man eine URL oder Mailadresse spezifizieren, an die Verstoßversuche gemeldet werden sollen.

Anmerkungen

Qualys SSL Server Test prüft seit neustem auch diesen Record, ein Punktabzug ist mir nicht bekannt.

Es gibt einen CAA RR Generator für die großen CAs, über das Critical Flag, welches im Beispiel 0 ist, sollte man sich aber noch weiter informieren, bevor man das einfach auf 0 setzt.

Fazit

Ich bin gespannt, inwiefern dies hilft. Überzeugt bin ich erst, wenn zehn Jahre am Stück kein CA-Problem mehr auftritt. Das ganze CA-Konzept erachte ich als inherent unsicher und gehört überholt.

DNSSEC und Fingerprints der benutzten selbsterzeugten Zertifikate drin ablegen und schon wäre man den CA-Wasserkopf los;

Hetzner: Firewall für Rootserver

Seit 01.12.2016 kann man sich, wenn man bei Hetzner einen Rootserver besitzt, eine Firewall klicken. Das ist ein feiner Zug von Hetzner.

In einem Beitrag im Newsbereich bei Hetzner ist mir heute diese Neuerung aufgefallen und ich habe sie gleich bei diesem Server eingerichtet. So wird das System etwas besser geschützt und auch ein bisschen entlastet, wenn jemand meint, alle Ports durchprobieren zu müssen.

Fazit

Die Firewall funktioniert auf den ersten Blick wie spezifiziert. Die Übernahme einer Konfigurationsänderung dauert etwa 20 Sekunden. Leider wird aber nur IPv4 unterstützt. Ich bin allerdings zuversichtlich, dass IPv6-Funktionalität bald nachgerüstet wird.

HTTP/2: Performancegewinn(er)

Ich achte privat und beruflich stets auf optimale Frontendperformance und mir wird es von modernen Webapplikationen oder esoterischen Architekturen diesbezüglich selten leicht gemacht, weil während derer Entwicklung oft unzureichend an diese Anforderung gedacht wird. HTTP/2 wird mir die Arbeit etwas leichter machen.

Motivation

Seitdem HTTP/2 nun auch in den beiden großen Webservern Apache und nginx implementiert ist, habe ich es nun auch für mein Blog aktiviert, um zu sehen, inwieweit die bisher schon sehr guten Performancewerte übertroffen werden.

Mir ist bekannt, dass die Dokumentation beider Webserver zum Zeitpunkt der Erstellung dieses Beitrags die HTTP/2-Funktionalität als experimentell ausweist.

Mir geht es in diesem speziellen Beitrag primär um die Testung der Frontendperformance ohne Browsercache. Dies ist dem geschuldet, dass ich die Cachingkonfiguration dieser Website bereits als praktisch optimal erachte. Weiter will ich hier die Datenübertragungsperformance beleuchten und Daten werden schließlich nur übertragen, wenn sie noch nicht im Browsercache liegen.

HTTP/1.1

Am 09.10.2016 habe ich eine Performanceanalyse mittels WebPagetest ausgeführt, um den allgemeinen TLS-Overhead von einem externen System zu prüfen.

Es ist zu sehen, dass der Chrome-Browser für die neun einzelnen Ressourcen der Startseite dieses Blogs nacheinander insgesamt drei TLS-Verbindungen aufgebaut hat. Dabei wird nach der DNS-Auflösung bereits eine zweite Verbindung aufgebaut, weil er sich wohl auf weitere Ressourcendownloads vorbereitet. Er versucht, sobald er eine bisher nicht geladene Ressource erkennt, eine der aktuell nicht benutzten Verbindungen zu benutzen. Falls alle ausgelastet sind, wird direkt eine neue Verbindung aufgebaut.

Dieses Verhalten ist dem geschuldet, dass HTTP/1.1 pro Verbindung keine Ressourcen gleichzeitig übertragen kann. Dabei wird aber pro Verbindung in Kauf genommen, dass trotz geringer Datenmengen bei optimierten Websites die unter dem TLS liegende TCP-Verbindung bezüglich Slow-Start noch nicht warm ist. Die maximal mögliche Datenrate des Clients von 5 Mbps wird dabei gerade mal zur Hälfte ausgenutzt.

Es ist außerdem zu sehen, dass abhängig von den verfügbaren Verbindungen alle Ressourcen nacheinander geladen werden.

Der vollständige Ladevorgang der Seite benötigt in diesem Test etwa 1,4 Sekunden.

HTTP/2

Heute habe ich eine weitere Performanceanalyse mit identischer Konfiguration durchgeführt, um die Änderungen durch die Aktivierung von HTTP/2 von einem externen System zu prüfen.

Es fällt direkt auf, dass der Browser lediglich eine einzige TLS-Verbindung aufbaut. Sämtliche im HTML referenzierten Ressourcen werden durch die selbe Verbindung gleichzeitig übertragen und dabei wird sogar kurzzeitig die maximal mögliche Datenrate des Clients erreicht.

Der vollständige Ladevorgang der Seite benötigt hier 0,9 Sekunden, das ist eine halbe Sekunde weniger als mit HTTP/1.1 auf den ersten Blick.

Man darf nicht übersehen, dass es, bis die initiale TLS-Verbindung steht, länger im HTTP/1.1-Test dauerte als im Test mit HTTP/2. Diese Unterschiede kommen in der Regel von unterschiedlichen Lastzuständen der Netzwerkinfrastruktur zwischen dem WebPagetest-Client und meinem Server.

Wenn man diesen Nachteil berücksichtigt, dann ist HTTP/2 etwa 0,4 Sekunden performanter.

Webserveranpassung

Ich nutze die größte Version von nginx, die in den Ubuntupaketen verfügbar ist. Diese Version hat bereits das notwendige Modul hineincompiliert. Man aktiviert es in der listen-Direktive. Es ist nur eine Zeile, die man anpassen muss.

Man darf nicht vergessen, dass dieses Modul experimentell ist und man sich gut überlegen sollte, ob man es aktiviert. HTTP/2 ist im Vergleich zu HTTP/1.1 erheblich komplexer. Mangels Alter bzw. Reife des Codes ist es im Prinzip nur eine Frage der Zeit, bis kritische Bugs bekannt werden.

Im schlimmsten Fall übernimmt mir jemand den Webserver. Bei diesem Blog finde ich das Risiko akzeptabel. Wenn niemand sowas benutzt und keiner Bugs meldet, wird der Code schließlich auch nicht reifer. Man sieht aber an existierenden Sicherheitsanalysen, dass sich nginx ganz gut schlägt.

Fazit

Mit der breiten Unterstützung von HTTP/2 auf Client- und Serverseite ist ein Grundstein gelegt, Anforderungen von Nutzern moderner Webapplikationen mit endlichem Aufwand gerecht werden zu können.

Ich muss noch weitere Tests fahren, um weitere Aussagen treffen zu können. Als nächstes sehe ich Lasttestvergleiche, um zu prüfen, wie viel "Strom" die HTTP/2-Komplexität auf dem Server in Abwärme umwandelt.

Nachtrag

26.10.2016: Man muss beachten, dass die HTTP/2-Verbindung fehlschlagen kann, wenn man zu unsichere TLS-Ciphers konfiguriert hat. Ich habe das gemerkt, weil mein SailfishOS Mobiltelefon diese Site nicht mehr erreichen konnte. Zum Glück hat nginx die debug_connection-Direktive.

Coreutils: dd kann jetzt sprechen

Bei der Verwendung von dd steht ja immer die Frage im Raum, wie weit es schon ist. Mit Coreutils 8.24 wurde dd nun die Fortschrittsanzeige beigebracht.

Bisher brauchte ich immer einen anderen Prozess, der ein Signal an den dd-Prozess gesendet hat, damit dieses den eigenen Fortschritt ausgibt. Das sah in der Regel so aus.

$ watch 'killall dd -USR1'

Dies lässt alle dd-Prozesse alle zwei Sekunden den aktuellen Fortschritt ausgeben.

Coreutils 8.24 und neuere

Bei einer am Puls der Zeit mitlaufenden Linux-Distribution reicht es aus, dd einen weiteren Parameter mitzugeben.

$ dd if=/dev/zero of=/dev/mmcblk0 status=progress
1222816256 bytes (1,2 GB, 1,1 GiB) copied, 491,063 s, 2,5 MB/s

Wenn man den Parameter status beim Start von dd vergessen hat, funktioniert die alte Variante natürlich auch noch.

Ob man das coole Feature nutzen kann, lässt sich natürlich auch leicht herausfinden.

$ dd --version
dd (coreutils) 8.25

Fazit

Ich finde es schön, dass auch dieses Stück Software noch hervorragend gepflegt wird. Ich hoffe, Euch hilft dieser Tipp bei der nächsten Kopierorgie.

Unitymedia: WifiSpot - Der erste Kontakt

Seit kurzem hat Unitymedia vielen Kunden ein öffentliches Wifi mit der SSID Unitymedia WifiSpot in die Unitymediabox konfiguriert. Dieses Vorgehen ist sehr umstritten.

Hintergrund

Über die Intention der Unitymedia für diesen Schritt kann man viel Spekulieren und Pressemitteilungen wälzen. Fakt ist, dass ich mit diesem WifiSpot beglückt wurde.

Aus den FAQs konnte ich entnehmen, dass

auf WPA2-Enterprise gesetzt wird
man mit Geräten, die einmal erfolgreich mit dem eigenen Wifi verbunden waren, nicht mehr auf WifiSpot zugreifen kann
eigenes internes Netz und WifiSpot-Netz getrennt behandelt werden
die im gebuchten Tarif erlaubten Datenraten durch WifiSpot-Aktivität nicht beeinflusst werden
sich Unitymediakunden kostenfrei Zugangsdaten anlegen können, um mit hohen Datenraten ohne Volumenbegrenzung in fremden WifiSpots aufs Internet zugreifen zu können
sich Nicht-Kunden Zugangsdaten per SMS zusenden lassen können, um mit begrenztem Datenvolumen und niedrigen Datenraten aufs Internet zugreifen zu können

Beobachtungen

Kanäle

Meine erste Feststellung war, dass vom WifiSpot und meinem eigenen Wifi der selbe Kanal belegt wird. Dies hat selbstverständlich zur Folge, dass WifiSpot-Aktivität meine maximal möglichen Datenraten einschränkt. In einem solchen Kanal und den umliegenden Kanälen kann zu einem Zeitpunkt x schließlich immer nur ein Teilnehmer senden. Lediglich die per LAN-Kabel an die Unitymediabox angeschlossenen Geräte mögen also von WifiSpot-Aktivität unbeeinträchtigt bleiben.

Schön wäre es, wenn man z.B. das eigene Wifi ins 2,4 Ghz und den WifiSpot ins 5Ghz-Band packen könnte. So würden sich beide nicht beeinflussen.

Deaktivierung

Nach weiterer Recherche habe ich herausgefunden, dass falls man den WifiSpot anderen nicht zur Verfügung stellen möchte, man sich ins Kundencenter auf der Website von Unitymedia einloggen und dort unter Meine Produkte - Internet den Haken bei WifiSpot entfernen muss. Die Kabelbox wird dann innerhalb von 24h von Unitymedia aus umkonfiguriert und neugestartet. Weiter wird der eigene Premiumzugang zu fremden WifiSpots gesperrt.

Nur schwer kann ich mir erklären, warum man das nicht im Webinterface der Box vom lokalen Netz aus einstellen kann. Ich kann mir nur vorstellen, dass dann eine Firmware eingespielt wird, die diese Funktionalität garnicht erst mitbringt. Auch ist es möglich, dass die Box den Zugang zum zentralen WifiSpot-Authentifikationssystem entzogen bekommt.

WPA2-Enterprise

In einem FAQ wird bereits darauf hingewiesen, dass kein allgemein akzeptiertes Zertifikat eingesetzt wird. Leider wird aber das Zertifikat der ausstellenden CA nicht zum Download angeboten. Alternativ fehlt auch der Fingerprint des Zertifikats, um es selbsttätig bestätigen zu können. Somit kann kein Nutzer sicherstellen, dass die Kommunikation wirklich mit der potentiell vertrauenswürdigen Gegenstelle bei Unitymedia stattfindet.

Mein wpa_supplicant lässt deshalb die Verbindung beim TLS-Handshake berechtigterweise sterben. Das hier hat der Journald aufgefangen.

NetworkManager[402]: device (wlan1): supplicant interface state: associating -> associated
wpa_supplicant[470]: wlan1: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
wpa_supplicant[470]: wlan1: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
wpa_supplicant[470]: TLS: Certificate verification failed, error 19 (self signed certificate in certificate chain) depth 2 for '/C=NL/O=Liberty Global Oper
wpa_supplicant[470]: wlan1: CTRL-EVENT-EAP-TLS-CERT-ERROR reason=1 depth=2 subject='/C=NL/O=Liberty Global Operations B.V./OU=Root CA0001/CN=Liberty Global
wpa_supplicant[470]: SSL: SSL3 alert: write (local SSL3 detected an error):fatal:unknown CA
wpa_supplicant[470]: OpenSSL: openssl_handshake - SSL_connect error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
wpa_supplicant[470]: wlan1: CTRL-EVENT-EAP-FAILURE EAP authentication failed
kernel: wlan1: deauthenticated from c6:xx:ca:fe:ba:be (Reason: 23=IEEE8021X_FAILED)

Es riecht in den Standardeinstellungen auf Clientseite sogar nach SSLv3, was mich sehr beunruhigt.

Fazit

Ohne eine Möglichkeit, die Gegenstelle als vertrauenswürdig einstufen zu können, kann man das so nicht benutzen. Zum Schutz der Leute in meiner Nähe habe ich den WifiSpot nun im Kundencenter deaktiviert. Das hat nach fünf Minuten und einem automatischen Neustart der Unitymediabox auch wunderbar geklappt.

Nachtrag

10.07.2016: Das Fehlen des Fingerprints und des CA-Cert-Files habe ich Unitymedia bereits heute gemeldet.

11.07.2016: Meine Unitymediabox hat sich heute ohne Ankündigung neugestartet und der WifiSpot war wieder da. Im Kundencenter steht, dass WifiSpot bei mir deaktiviert ist. Das ist doch eine Frechheit. - Die Unitymediabox habe ich einmal von Strom getrennt, um zu sehen, ob das wirklich mein WifiSpot ist und nicht der eines Nachbarn. - Nein, der WifiSpot wird eindeutig von meiner Box erzeugt. - Ich schalte WifiSpot im Kundencenter jetzt nochmal ein und aus. - Das hat geklappt.

12.07.2016: Wieder wurde der WifiSpot ohne meine Genehmigung aktiviert. Ich hab angerufen und vom Berater die Nummer 0800-7001177 bekommen. Weiter hat er gesagt, dass ich dort richtig Randale machen soll. - Laut Techniker ist der WifiSpot deaktiviert und sollte nicht da sein. - viele Warteschleifen, mehrere Weiterleitungen in die "Technik" - Techniker2 empfiehlt einen Reset des Gerätes mit dem Knopf an der Rückseite, ich bin gespannt. Der Reset dauerte eine Stunde bis das Modem wieder da war und man es im LAN ansprechen konnte. Die Wifi-Einstellungen meines privaten Netzes und das Adminpasswort habe ich geändert. Jetzt noch ein Blick in die umliegenden Netze. - Der WifiSpot ist noch da.

13.07.2016: Ich habe diesen Blogbeitrag an @UnitymediaHilfe getwittert, weil ich gerade keine Zeit und Lust auf Warteschleifen und Telefonieren habe.

14.07.2016: Heute hat sich @UnitymediaHilfe gemeldet, dass sie diese Angelegenheit prüfen.

17.07.2016: Der WifiSpot ist nun nicht mehr da. Entsprechend der Uptimeanzeige, wurde das Gerät gestern um 16:00 Uhr neugestartet. Vermutlich hat Unitymedia die Konfiguration korrigiert. Ich bin mal vorsichtig optimistisch, dass das nun gelöst ist.

Fail2ban: Already banned

Mithilfe des Tools Fail2ban kann man automatisiert Logdateien überwachen lassen und entsprechend konfigurierbarer Regeln bestimmen, ab welcher Anzahl an bestimmten Logeinträgen in einem bestimmten Zeitraum z.B. eine IP in die Firewall geworfen werden soll. Auf Fehlkonfiguration ist bei Fail2ban ist allerdings peinlich genau zu achten.

Nicht abgedeckte Ports

Falls eine konfigurierte Regel nicht alle Ports des zu überwachenden Prozesses abdeckt, kommt es zu dem Phänomen, dass Fail2ban dieselbe IP immer und immer wieder blocken möchte. Im Logfile /var/log/fail2ban.log macht sich das wie folgt bemerkbar.

2016-01-01 12:00:00,000 fail2ban.actions: INFO   [process] xxx.xxx.xxx.xxx already banned

Dies weist darauf hin, dass weiterhin Anfragen den Prozess belästigen, obwohl bereits vorher von Fail2ban festgestellt wurde, dass dies geblockt gehört.

Beispiel

Bei einem Mailserver sind eine Menge an Ports im Spiel und so kann es sein, dass man bei der Fail2ban-Konfiguration z.B. den Message-Submission-Port submission vergisst und ein Bot trotz Blockversuch fröhlich weiterversucht, seinen Spam über den smtpd zu verschleudern.

[sasl]
enabled  = true
port     = smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s,submission
filter   = sasl
logpath  = /var/log/mail.log

Fazit

So ein Blick ins Log von Fail2ban ist immer mal wieder zu etwas gut. Ich hoffe, dass der Hinweis Euch hilft.

IPv6: Dynamische IPs bei Unitymedia

Als Kunde von Unitymedia bekomme ich für all meine Geräte eine IPv6-Adresse zugewiesen. Leider ändert sich diese bei jedem Bootvorgang des Modems.

Motivation

Ich habe einen RaspberryPi mit externer Festplatte und ich möchte, dass er jeden Tag einmal von meinem Rootserver ein Päckchen mit Backups empfängt.

Früher war das bei Unitymedia kein Problem, da sich die einmal zugewiesene IPv4-IP praktisch nie geändert hat. Seit meinem Umzug nach Frankfurt am Main bekommt mein Modem nur noch eine geNATete IPv4-IP, bei der jegliche Portweiterleitung im Router auf das Zielsystem nicht zuverlässig funktioniert. Weiter bekommt jedes meiner Geräte aber eine IPv6-IP, die vollständig erreichbar ist.

Da sie sich entgegen meines Verständnisses von IPv6 regelmäßig ändert, muss ein Hack her.

freedns.io

Da ich keine Lust hatte, auch noch einen DNS-Server zu betreiben, habe ich mich dazu entschieden, den Dienst freedns.io zu verwenden. Diesen kann man per HTTPS-POST einfach aktualisieren. Das API lässt zwar nur zwei Updates am Tag zu, das reicht aber in der Regel für meine Zwecke. Es werden übrigens nur Updates gezählt, bei denen sich der Eintrag tatsächlich ändert.

Somit kann man einen trivialen Cronjob schreiben, der alle 15 Minuten die eigene IP meldet.

*/15     ~/scripts/freednsio.sh

Bei ArchLinux wird das Paket python2-netifaces benötigt, damit das folgende Skript funktioniert.

#!/usr/bin/python2

import urllib
import urllib2
import netifaces

addrs = netifaces.ifaddresses('eth0')
url = 'https://freedns.io/request'
params = {
  'username': 'blipp',
  'password': 'blubb',
  'host': 'hostname',
  'record': 'AAAA',
  'value': addrs[netifaces.AF_INET6][0]['addr']
}

data = urllib.urlencode(params)
req = urllib2.Request(url, data)

try:
  response = urllib2.urlopen(req)
  content = response.read()
  print content
except urllib2.URLError as e:
  print "FreeDNS-Update-Error: %d %s (%s)" % (e.code, e.reason, e.read())

Fazit

Mit diesem etwas unschönen Hack kann man die eigene Maschine ohne große Ausfälle erreichbar halten. Vielleicht hilft es Euch ja auch.

Performance: Perfmap für Bilder

Wasserfalldiagramme sind sehr gut für die Analyse der Frontendperformance einer Webseite geeignet. Es ist aber schwierig, Nichttechnikern Probleme auf deren Basis verständlich zu machen.

Wasserfalldiagramme

Es ist eine Menge Vorwissen notwendig, um Wasserfalldiagramme, welche jeder vernünftige Browser auf Anfrage für einen Seitenladevorgang erstellt, deuten zu können.

Im Bild ist meine Blogstartseite als Wasserfall zu sehen. Lediglich die CSS-Ressource blockiert das Rendering während des Ladevorgangs.

Perfmap

Es wird eine Heatmap durch das Bookmarklet Perfmap auf Basis der Informationen aus dem Resource Timing API in die Seite gezeichnet. Dies kann sehr einfach interpretiert werden und hilft, die Prioritäten bei der Frontendperformanceverbesserung bezüglich teurer Bilder richtig zu setzen. Im Bild ist zu sehen, dass meine Blogstartseite relativ unspektakulär ist.

Diese Heatmap ist bei bilderlastigen Seiten wesentlich sinnvoller.

Fazit

Wasserfall und Heatmap haben ihre Daseinsberechtigung. Die Heatmap gibt uns neue Möglichkeiten, um ressourcenlastige Seiten zu analysieren. Versucht es doch auch einmal.

Google: Zwei-Faktor-Authentifizierung braucht Backup

Damit niemand Zugang zu einem Googleaccount bekommt, selbst wenn das Passwort z.B. durch einen Keylogger im einem Internetcafé mitgeschnitten wurde, empfiehlt es sich, die Zwei-Faktor-Authentifizierung zu aktivieren. Das kann aber auch nach hinten losgehen.

Logins klappen ab dem Zeitpunkt der Aktivierung dieser Funktion nur dann, wenn man z.B. eine Information aus einer SMS, die während des Loginvorgangs auf dem eigenen Mobiltelefon empfangen wird, eingibt.

Problem

Meine Frau hat für einen neuen Mobilfunkvertrag ihre Telefonnummer aus dem alten Vertrag mitgenommen. Aus unerfindlichen Gründen kann sie seit der Vertragsumstellung keine SMS mehr von Google empfangen. Die SMS-Zentrale ist korrekt eingestellt und SMS können auch an andere Telefone gesendet und empfangen werden. Google verlangt nun bei jedem Loginversuch eine Information, die nicht mehr empfangen werden kann. Sie ist aus dem Account ausgesperrt.

Leider bietet es Google nicht an, auf diese Mobiltelefonnummer einen Sprachanruf mit einer Codedurchsage durchzuführen, anstatt eine SMS zu senden. Um dies ändern zu können, müsste sie sich erst einloggen.

Die Kontowiederherstellungsanfrage, welche meine Frau gestellt hat, wurde bisher abgelehnt. Ich bin gespannt.

Möglichkeiten

Sobald der Zugang wieder möglich ist, werden wir Backup-Codes erzeugen lassen, um genau für diesen Fall gewappnet zu sein. Diese stellen einen dauerhaft gültigen Ersatz dar und man kann sie an einem sicheren Ort aufbewahren.

Fazit

Ich finde es schade, dass Google seinen Nutzern Zwei-Faktor-Authentifizierung anbietet, ohne sie zu zwingen, Backupcodes zu erstellen.

Sollte dieses Problem einmal bei meinem Online-Banking auftreten, kann ich zumindest zu einer Filiale fahren und das Problem dort lösen lassen, weil ich mich mit meinem Personalausweis einfach ausweisen kann. Im Falle von Google ist das nicht so einfach.

Ich hoffe, Du erzeugst nun Deine Google-Backupcodes, wenn Du sie nicht bereits hast.

Nachtrag

Nach etwa fünf Tagen ohne Zugang und mehreren Versuchen mit Problemtickets wurde die Zwei-Faktor-Authentifizierung durch Google deaktiviert. Nun funktioniert der Login wieder wie er soll.

LCA2015: Programming - Engineering

Die Menschen der heutigen Welt verlassen sich täglich darauf, dass eine Menge Softwaresysteme so funktionieren, wie sie es sollen. Um diese komplexen Systeme zu bauen, bedarf es aber mehr als eine Hand voll Leute, die Programmieren können.

Software ist Vertrauen

So, wie man als Fahrer dem Automobilhersteller vertraut, dass ein Fahrzeug bei 200 km/h auf der Autobahn nicht die Heckklappe verliert, vertraut man auch Software-Entwicklern im täglichen Leben.

Beim Abruf dieses Blogbeitrags vertraut man darauf, dass sich der verwendete Browser nicht dazu bewegen lässt, Schadcode, der in dieser Webseite eingebettet sein kann, auf dem eigenen Gerät auszuführen.

Programming Considered Harmful

Video ansehen

Der XFS-Entwickler Dave Chinner erklärt schön in seinem Vortrag Programming Considered Harmful, den er auf der LCA2015 gehalten hat, was gute Softwareprojekte und Software-Entwickler ausmacht.

Am Beispiel des Linux-Kernels erklärt er, wie dieses Softwareprojekt mit der ständig steigenden Komplexität zurechtkommt und welche Maßnahmen aus welchen Gründen ergriffen wurden, um Silos zu vermeiden.

Fazit

Dave erläutert klar, dass es nicht auf die Cleverness einer Einzelperson ankommt, sondern darauf, dass alle beteiligten Entwickler ihr Wissen strukturiert weitergeben und dass sie ihre Arbeit gegenseitig überprüfen.

Der Prozess der Softwareentwicklung ist der entscheidende Faktor, der die resultierende Softwarequalität bestimmt. Ihm muss man vertrauen, denn niemand ist vollkommen.

Munin: Export nach Carbon bald möglich

Aussagekräftige Dashboards sind bei der Analyse von Metriken ein Muss. Grafana ist diesbezüglich das komfortabelste und flexibelste Werkzeug, das ich bisher gesehen habe und es sieht so aus, als würde man bald Metriken aus Munin mit Bordmitteln in Grafana anzeigen lassen können.

Situation

Ich erachte Munin als ein sehr einfach zu konfigurierendes Monitoringsystem. Für die Erfassung neuer Metriken reicht es, ein kleines Skript - ein Plugin - zu schreiben und auf dem Munin-Node einzubinden. Der Munin-Node-Prozess ist auf praktisch jedem Stück Blech lauffähig, solange Perl installiert ist. Das Protokoll, das er mit dem Master spricht, ist so einfach, dass es sogar einen sehr schlanken in C geschiebenen Spin-Off gibt.

Der Munin-Master skaliert bis zu einer Nodeanzahl, die sein fünfminütigens Pollingintervall nicht sprengt. Es gibt aber noch ein Zwischenstück, dass den Master diesbezüglich entlastet und öfter Daten einsammeln kann, um sie dann geschlossen an den Master übergeben zu können.

Motivation

Leider aber ist die Ausgabe der Graphen durch den Munin-Master ein wenig unflexibel, wenn man es mit heutigen Standards misst. Die Übersichtlichkeit der Graphenanordnung ist ausgezeichnet und ich kann gut die Korrelation von Vorfällen des aktuellen Tages und der letzten Woche herausfinden. Alles, was darüber hinaus geht, ist ein ziemlich großer Schmerz.

InfluxDB

Grafana benötigt als Datenquelle in der aktuellen Version 2.0 eine Instanz von Graphite, OpenTSDB oder InfluxDB. Ich persönlich finde InfluxDB am interessantesten, weil es einfach keine Abhängigkeiten aufweist und sehr interessante Features anbietet. Es ist aber ganz klar noch nicht so gut abgehangen, wie OpenTSDB oder Graphite.

Munin mit Carbon-Export

Heute ist mir beim Durchgehen der letzten Commits im Munin-Projekt aufgefallen, dass ein Pull-Request akzeptiert wurde, der einen Export nach Carbon - dem Metrikdatenempfänger von Graphite - möglich macht. InfluxDB liefert standardmäßig die Funktionalität mit, Metriken wie ein Carbon-Prozess zu empfangen. Damit lässt sich InfluxDB in bestehende Graphite-Setups einfach integrieren.

Fazit

Munin kann nach dem Release dieses Features sowohl Graphite als auch InfluxDB mit Metriken und damit externe Dashboards wie Grafana mit Daten versorgen.

Das vom Munin-Master erzeugte simple Dashboard ist damit nicht obsolet geworden, weil es nach wie vor hervorragend ohne Konfigurationsaufwand funktioniert und aus dem Stand 80% all meiner Anforderungen erfüllt. Die restlichen 20% übernimmt bald einfach Grafana.

Munin: Alarme via Jabber versenden

Die Erfassung von Metriken ist beim Monitoring mindestens genauso wichtig, wie das Benachrichtigen verantwortlicher Personen, wenn nun mal etwas wohldefinierte Grenzwerte überschreitet. Ich löse das nun via Jabber.

Situation

Oft habe ich schon beobachtet, dass sich Leute bei Problemen automatisiert E-Mails senden lassen. Das führt oft zu überlaufenden Postfächern und qualmenden Mailservern. Schließlich wird kein Mailserver auf die Idee kommen, Mails nicht zuzustellen, wenn er meint, dass ein Benutzer zu viele Mails bekommt. Er wird alles versuchen, seinen Job zu machen und bei Ressourcenknappheit dem anderen Mailserver Bescheid sagen, es bitte später erneut zu probieren.

Jabber

Jabber hingegen ist auf Chatnutzung ausgelegt und jede Nachricht ist nach dem Lesen tendenziell zum Wegwerfen bestimmt. Weiter haben Jabberserver stets gesetzte Limits, wie viele Nachrichten bei einem Nutzer, der offline ist, vorgehalten werden. Alarme aus Monitoringsystemen erfüllen den Wegwerfcharakter hervorragend.

Wenn man sie direkt mitbekommt, sucht man den nächsten Rechner und beginnt mit der Analyse in Graphen und Logfiles. Wenn man sie nicht sofort mitbekommt, weil man vorübergehend offline ist, ist das schade und man muss hoffen, dass eine andere verantwortliche Person den Alarm bemerkt hat.

Munin mit Jabberalarm

Die folgende Konfiguration ist auf dem Munin-Master vorzunehmen. Weiter wird auf das Werkzeug sendxmpp zurückgegriffen.

Man erstellt als erstes ein Jabberkonto für Munin, damit man sich von ihm sauber anschreiben lassen kann. Technische- und Menschenaccounts sollte man tunlichst trennen.

Mit ejabberd geht die Erstellung wie folgt.

# ejabberdctl register munin JABBERSERVERHOST PASSWORT

Nun legt man die Zugangsdaten für den neuen Nutzer munin in einer Konfigurationsdatei, die nur von einem Muninprozess gelesen werden kann ab.

# echo "munin@JABBERSERVERHOST PASSWORT" > /etc/munin/munin-jabberalert.conf
# chmod 400 /etc/munin/munin-jabberalert.conf
# chown munin /etc/munin/munin-jabberalert.conf

In der Konfiguration /etc/munin/munin.conf fügt man nun die Kontaktanweisung im globalen Abschnitt - außerhalb der Node-Einstellungen - hinzu. Jede Direktive bekommt dabei eine Zeile für sich.

contacts jabber
contact.jabber.command sendxmpp -i -t -f /etc/munin/munin-jabberalert.conf NUTZER@JABBERSERVERHOST

# the first node configuration
[foo]
    address bar

Das war es bereits und das Logging findet normalerweise nach /var/log/munin/munin-limits.log statt, falls debuggt werden muss.

Test

Zum Test kann ein Plugin modizifiert werden, um einen Warning oder Critical zu triggern. Ob das klappt, sieht man im Webinterface von Munin. Die Kategorie mit dem Alarm wird gelb bzw. rot markiert, wenn ein Grenzwert überschritten wurde.

Ich persönlich habe zum Test einfach eine meiner Websites einen Fehlercode werfen lassen.

Fazit

Abhängig davon, wie wichtig etwas ist, kann man sich beliebig viele Grenzwerte definieren. Ich habe nur die aller wichtigsten eingerichtet, wie Platte aus dem RAID gefallen, Plattenplatz wird knapp, Webserver melden etwas anderes als 200 auf der Startseite, Errorlogs haben Einträge und so weiter.

Ich hoffe, ich konnte Dir bei Deinem Monitoring-Fanatismus behilflich sein.

Hetzner: vServer und Plattenwartezeiten

Aufgrund der wiederkehrend hohen Plattenwartezeiten habe ich bei Hetzner letztlich von einem vServer auf einen Rootserver aus der Serverbörse gewechselt. Der Unterschied ist erheblich.

Situation

Meine Maschinen überwache ich stets mit Munin. Dieses Werkzeug misst alle fünf Minuten relevante Metriken und visualisiert sie bei Bedarf in hübschen Graphen. So kann ich Änderungen in den Systemleistungen zeitlich verfolgen und frühzeitig Gegenmaßnahmen einleiten.

Bei Hetzner hatte ich seit Jahren einen vServer VQ7 mit einem halben Gigabyte Hauptspeicher und einem Prozessorkern. Dieser war völlig ausreichend für meine Zwecke aber etwa ein bis zweimal im Jahr sank die Plattenperformance im Bezug auf die Wartezeiten erheblich. Dies war offenbar stets dem Umstand geschuldet, dass ich mir die eigentliche Maschine mit anderen Leuten teilen musste. Ein Supportticket reichte in der Regel, um auf einen ruhigeren Host umgezogen zu werden. Dieses Mal wurde es aber bei jedem Umzug schlimmer und ich wollte keine neuen Supportanfragen mehr schreiben.

Serverbörse

In der Serverbörse kann man gebrauchte Rootserver zu einem angemessenen Preis mieten. Ich habe mich für einen Vierkerner mit 16 Gigabyte Hauptspeicher entschieden. Wie Ihr an den Graphen seht, ist die Plattenwartezeit (Disk Latency) von Durchschnittlich 260ms mit Spitzen bis zu sieben Sekunden auf Durchschnittlich 20ms mit Spitzen bis 200ms gefallen.

Dies entspricht der normalen Performance konventioneller Platten. Bei SSDs hingegen geht es nur noch um etwa 0,5ms Wartezeit.

Wie Ihr seht, habe ich zwei unterschiedlich flinke Platten. Die schnellere ist eine neue Western Digital und die langsamere eine Seagate mit bereits einem Jahr Betriebszeit.

Fazit

Der vServer hat mir gute Dienste geleistet, auch wenn er gelegentlich lahmte. Für durchgängige Leistung kommt man meines Erachtens an einem Rootserver nicht vorbei.

HTML: Performance durch Resource Hints

Die Frontendperformance von Websites ist äußerst wichtig, um Nutzer nicht auf die Idee zu bringen, schnell eine andere Website aufzurufen. Das W3C bohrt mit Resource Hints HTML mal wieder etwas auf, um komplexen Systemen mit verteilten Ressourcen auf die Sprünge zu helfen.

Motivation

Browser bauen bei der Benutzung einer bestimmten Domain nur eine begrenzte Anzahl an Verbindungen auf. Dies beschränkt die Anzahl der Ressourcen, die gleichzeitig geladen werden können.

Um dies zu umgehen und die verfügbare Bandbreite eines jeweiligen Nutzers besser auslasten zu können, bietet es sich an, Ressourcen auf verschiedene Hosts zu verteilen.

Der Aufbau von neuen Verbindungen ist allerdings ein nicht zu unterschätzender Overhead, wodurch diese Maßnahme weise eingesetzt gehört.

DNS-Prefetch

Die Browser unterstützen bereits das Auflösen einer Domain bevor das HTML komplett eingelesen wurde. Folgendes kommt dabei in den <head>.

<link rel="dns-prefetch" href="//largeimages.mydomain.tld/">

Besonders wenn beispielsweise Javascript am Ende des HTML von externen Ressourcen eingebunden wurde, erhöht diese Maßnahme die Performance spürbar.

Resource Hints

Das W3C geht mit Resource Hints einen Schritt weiter. Mit Preconnect und Preload können ganze Verbindungen aufgebaut bzw. ganze Ressourcen in den Browsercache vorgeladen werden.

Beispiel aus dem Draft:

<link rel="preconnect" href="//example.com"/>

<link rel="preload" href="//example.com/next-page.html" as="html" loadpolicy="next"/>

Besonders wenn es verschlüsselte Verbindungen über Leitungen mit hohen Latenzen sind, wird dieses Feature bei korrektem Einsatz erhebliche Geschwindigkeitsverbesserungen erzielen. Bisher wurde diese Funktionalität bei Bedarf mittels XMLHttpRequest in Javascript individuell nachgebaut.

In Chromium wird die Unterstützung für Resource Hints gerade implementiert. Wenn andere Browserhersteller mitziehen, kann bald auf diesen Hack verzichtet werden.

Fazit

In den Anfängen von HTML war Performance noch Nebensache und die Leute haben sich gefreut, wenn sie einen Link zu einem anderen Dokument einbinden und etwas farbig hervorheben konnten.

HTML passt sich nun immer mehr neuen Anforderungen an.

Nachsatz

Es versteht sich von selbst, dass auf externen Domains keine Ressourcen liegen, die das Rendering blockieren.

Elektronik: Adventskalender ohne Schokolade

Bereits 2013 habe ich überlegt, mir den Adventskalender von Conrad zuzulegen. Dieses Jahr war es nun soweit.

Motivation

Mir war es wichtig, einen Adventskalender zu haben, der für meine Freundin und mich zusammen passend ist. In einem Radio- und TV-Geschäft habe ich in meiner Kindheit im Reparaturdienst ausgeholfen und besitze grundlegende Kenntnisse in der Elektronik. Meine Freundin ist grundsätzlich offen für alles technische und liebt Basteleien.

Erfahrungen

Auf der Rückseite des Kalenders ist ein Karton mit Grundlagen der Elektrotechnik und ein Beschreibungsbuch für die Experimente. Das Buch enthält etwa eine halbe Seite mit Erklärungen, einen Schalt- und einen Steckplan pro Tag. Die notwendige Zeit pro Experiment steigt von Tag zu Tag, übersteigt aber jeweils nie 30 Minuten. Es werden nur die absolut notwendigen technischen Grundlagen erklärt. Für meinen Geschmack hätte es gern etwas mehr sein können.

Es wird behauptet, dass lediglich eine 9V-Batterie notwendig ist. In der Tat braucht man aber noch zusätzlich eine spitze Zange und ein scharfes Messer, da man den Klingeldraht sonst nicht bearbeiten kann.

Der Schwierigkeitsgrad ist für Amateure passend. Geduld und feinmotorische Fähigkeiten sind aber zwingend notwendig.

Durchführung

Am ersten Tag bekommt man eine LED und einen Widerstand. Am dritten Tag bekommt man ein Steckbrett und täglich kommen dann Widerstände, LEDs, Transistoren usw. hinzu. Besonders interessant finde ich die Spezial-LEDs mit integrierten Schaltungen, die Mehrfarben, Kerzen- und Blinkeffekte ohne Eigenarbeit bereitstellen. Erst im letzten Experiment werden alle verbaut und man hat, wenn man möchte, einen Weihnachtsbaumanhänger in Form eines Steckbretts.

Fazit

Meiner Freundin und mir hat der Kalender sehr gefallen. Interessant ist, dass kein weiterführendes Werbematerial von Conrad mitgeliefert wird, welches erklärt, wo man durchgebrannte Bauteile nachbestellen kann.

Besonders schön hätte ich es gefunden, wenn man z.B. einen Blinkeffekt mit einzelnen Transistoren aufbaut und dann die Schaltung in die LED integriert bekommt.

Duplicity: Paramiko und OpenSSH 6.7

Täglich führt mein Server ein inkrementelles Backup mittels Duplicity durch. Ein Update von OpenSSH auf dem Zielsystem Raspberry Pi hat letztlich diesen Prozess unterbrochen.

Backend Exception

Im Duplicity-Log meines zu backupenden Servers war lediglich folgendes zu sehen.

BackendException: ssh connection to XXXX failed:

ssh: Connected (version 2.0, client OpenSSH_6.7)
ssh: Exception: Incompatible ssh peer (no acceptable kex algorithm)
ssh: Traceback (most recent call last):
ssh:   File "/usr/lib/python2.7/dist-packages/paramiko/transport.py", line 1585, in run
ssh:     self._handler_table[ptype](self, m)

Das SSH-Backend verweigert den Verbindungsaufbau. Ein manueller Versuch mittels CLI-Werkzeug sftp funktioniert hingegen problemlos.

Nach kurzer Recherche bin ich bei Github fündig geworden. Laut dem Paramiko-Entwickler ist mindestens Version 1.15.1 der Bibliothek erforderlich, wenn man mit einem Zielsystem dieser OpenSSH-Version kommunizieren möchte.

Lösungsansätze

Grundsätzlich hatte ich die Möglichkeit des Downgrades von OpenSSH 6.7 auf 6.6 auf dem Zielsystem. Diese Option mochte ich allerdings nicht, da ich sonst ab diesem Zeitpunkt keine Sicherheitsupdates mehr von den Arch-Repositories hätte einspielen können. Bei einem von außen praktisch frei aufrufbaren Dienst sollte man diese Option nie ziehen.

Ein Update der Paramiko-Bibliothek auf dem Ubuntu-Server wurde auch in keinem PPA angeboten. Auf ein Update über den üblichen Weg von Canonical will ich nicht warten. All meine bisherigen derartigen Bugreports wurden nie bearbeitet, obwohl ich stets Patches mit angehängt habe. Diese Option scheidet also auch aus.

In der Manpage von Duplicity habe ich einen guten Hinweis gefunden. Es gibt ein weiteres SSH-Backend.

pexpect

Das Backend pexpect existiert noch und wird noch unterstützt.

Nach dem Setzen der folgenden Option im Duplicity-Befehl des Backupskripts, funktionierte der Prozess wieder.

--ssh-backend pexpect

Fazit

Es ist sehr fein, dass diese Legacyimplementierung noch zur Verfügung steht.

Varnish: Shared Memory Log

Varnish liefert Seiten, insofern sie im Cache vorgehalten werden, ohne Plattenzugriff direkt aus dem Hauptspeicher aus. Wie ich aber letztlich gelesen habe, stimmt das nicht uneingeschränkt.

Laut Varnish-Book wird das Shared Memory Log standardmäßig auf der Platte geführt, wo es bei vielen Zugriffen eine Menge IO erzeugen kann.

Dem varnishd kann mittels des Parameters -l mitgeteilt werden, wie groß er das Log dimensionieren soll. Eine Entkopplung von der Platte ist mittels tmpfs einfach möglich, da die als Round-Robin geführte Datei nicht größer als konfiguriert wird.

Meine /etc/fstab besitzt damit nun folgende Zeile.

tmpfs /var/lib/varnish tmpfs rw,size=64M 0 0

Ich hoffe, ich konnte Euch bei Eurer Varnishkonfiguration einen guten Tipp geben.

PHP: FPM-Backend offline nach Update

Nach dem Einspielen der heute bei Ubuntu 14.04 LTS veröffentlichten PHP-Updates für 5.5.9, blieb das PHP-Backend (FPM) für den Webserver nicht erreichbar. Seitenaufrufe meines Blogs resultierten in einem Fehlercode. Was war passiert?

Status 503 und 502

Der dem Webserver nginx vorgeschaltete Varnish meldete einen 503 Service Unavailable. Statische Inhalte funktionierten.

Ok, FPM ist wohl nicht erreichbar. ps aux | grep fpm zeigte allerdings, dass es läuft. Die Logfiles von nginx sind aufschlussreicher. Laut Accesslog wird 502 Bad Gateway an Varnish gemeldet. Das Errorlog gibt den entscheidenden Hinweis.

[crit] 1337#0: *169 connect() to unix:/var/run/php5-fpm.sock failed (13: Permission denied) while connecting to upstream, client: xxx.xxx.xxx.xxx, server: gnuheidix.de, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "gnuheidix.de"

Wie sich herausstellte, hatte der Unix Domain Socket mit root:root 660 für nginx unpassende Einstellungen.

Anpassung der Konfiguration

Die Prozesspool-Einstellung /etc/php5/fpm/pool.d/www.conf habe ich nach kurzer Recherche um folgende Zeilen erweitert.

listen.owner = daemon
listen.group = daemon
listen.mode = 0660

Diese Einstellung lässt die FPM-Worker den gleichen Nutzer und Gruppe nehmen wie nginx. Nach dem Durchstarten von FPM war mein Blog wieder vollständig erreichbar.

Hintergrund

FPM war nicht mehr zugreifbar, weil die Defaults, welche meine Konfiguration nutzte, geändert wurden. Im Rahmen von CVE 2014-0185 konnten beliebige Prozesse auf den Socket zugreifen. Dies ist im Ubuntu-Bugreport schön dokumentiert.

Meine FPM-Konfiguration war bis zum Zeitpunkt meiner heutigen Änderung nicht wasserdicht. Ich hatte es nicht gemerkt, weil der Default mit 0666 jedem Prozess Zugriffsrechte eingeräumt hatte.

Fazit

Gute Software erkennt man an sinnvollen und vorausschauend gewählten Defaulteinstellungen. PHP ist nun ein kleines Stückchen besser und ich ein bisschen achtsamer geworden.

SSH: Proxyfunktion als VPN-Ersatz

Eine gewisse Zeit hatte ich OpenVPN auf meinem Server im Einsatz, um vertrauenswürdige Internetverbindungen herstellen zu können. Das gleiche erreiche ich nun einfacher mit SSH.

Motivation

In Hotels, auf Konferenzen, Parteitagen oder ähnlichen Veranstaltungen wird oft ein frei zugängliches WLAN angeboten. Dies ist löblich, aber da ich den anderen Leuten im Netz oder dem Netzbetreiber selbst in der Regel nie komplett vertrauen will, brauche ich einen hochgradig verschlüsselten Kanal zu einem von mir kontrollierten Computer, von dem ich beruhigt aufs Internet zugreifen kann.

OpenVPN

Mit dem auf OpenSSL aufsetzenden System OpenVPN habe ich bis vor ca. einem Jahr diesen verschlüsselten Tunnel aufgebaut. Die Einrichtung war leider nicht wirklich einfach und einen Dienst, den ich vielleicht fünf Mal im Jahr brauche, permanent laufen zu lassen, mag ich nicht. Die Systemressourcen sind mir zu kostbar.

Darüber hinaus meide ich wenn möglich gern alles, was auf *SSL zurückgreift. Ich glaube, dass seit Heartbleed auch andere Leute so denken.

SSH als SOCKS-Proxy

Auf all meinen Rechnern ist ein SSH-Server zur Fernwartung eingerichtet und mit dem Parameter -D kann man den SSH-Client anweisen, einen SOCKS-Proxyserver bereitzustellen, sobald die Verbindung zum SSH-Server steht. Anwendungen, wie Browser, Mailprogramm usw. kann man so konfigurieren, dass der Verkehr über den Proxy läuft. In vielen Linuxdistributionen kann man das sogar sehr einfach mittels Klickibunti systemweit einrichten.

Wenn zu erwarten ist, dass die fremden Netze den SSH-Port sperren, kann man den SSH-Server auf einem grundsätzlich erreichbaren Port, wie 80 oder 443 laufen lassen.

Fazit

SSH tunnelt sauber IPv6, ich muss keinen Dienst extra laufen lassen und ich nutze ein Werkzeug, das ich schon sehr lange kenne, ein bisschen öfter. Mehr kann ich mir nicht wünschen.

Versucht es doch auch einmal.

Mailserver: Sender Policy Framework

Die Bearbeitung von Spammails ist heutzutage leider die Hauptbeschäftigung von praktisch jedem Mailserver. Verschiedene Mechanismen werden bei der Spamprüfung hintereinander geschaltet, um beim Durchlauf einer jeden E-Mail zu entscheiden, ob sie zugestellt werden sollte oder nicht. Das Sender Policy Framework (SPF) kann den Servern die Arbeit etwas erleichtern.

Geschichte

Mit der Arbeit an SPF wurde 2003 begonnen und der finale experimentelle Status wurde 2006 mit RFC4408 erreicht. Dieser Standard wird heutzutage bereits von einigen Mailservern unterstützt.

Im April diesen Jahres wurde SPFv1 mit RFC7208 offiziell von der Internet Engineering Task Force als Standard verabschiedet.

Motivation

E-Mails von meinem Mailserver an einen Google-Mailaccount wurden, wenn sie recht kurz waren, öfters als möglicher Spam ohne Zustellung zurückgewiesen. Ich mache Google keinen Vorwurf. Viel mehr als das Ergebnis vom Bayes-Filter und einer Übereinstimmung von SMTP-Banner und Reverse-DNS-Eintrag mit hatte es zur Klassifizierung schließlich nicht greifbar. Weiter schlägt bei Google so viel Spam auf, dass sie es sich einfach nicht leisten können, dort Ressourcen zu verbraten.

Nach etwas Recherche habe ich herausgefunden, dass SPF mein Problem lösen könnte.

Funktionsweise

Dieser Mechanismus verhindert, dass jemand E-Mails mit falschem Absender versenden kann, insofern der empfangende Mailserver das prüft bzw. prüfen kann. Es wird beim versendenden Mailserver ein SPF-Record im DNS gesetzt, welcher beschreibt, welche Rechner E-Mails für die benutzte Domain versenden dürfen. Ein empfangender Mailserver kann nach Abfrage des SPF-Records entscheiden, ob die IP des Mailservers, von dem er die Mail bekommt, der Regel des Records entspricht.

Einrichtung

Alles hängt am SPF-Record, der in jedem Fall korrekt sein muss. Falls man sich vertut und empfangende Mailserver ein SPF-Fail feststellen, kann das die Zustellungen um ein Vielfaches unwahrscheinlicher machen.

Senderichtung

Abhängig vom Setup kann es beliebig kompliziert sein, die passende SPF-Regel herauszufinden. Mir hat es geholfen, die RFC zu lesen. Letztendlich war die Regel aber für mein Setup mit einem Mailserver und einer mailsendenden Domain ziemlich einfach.

$ host -t txt gnuheidix.de
gnuheidix.de descriptive text "v=spf1 mx -all"

Diese Regel sagt nicht mehr aus, als dass die im MX-Record hinterlegten Rechner Mails senden dürfen und kein anderer. Es gibt übrigens auch einen Tester vom Schreiber der RFC.

Empfangsrichtung

Es kann sein, dass beim eigenen Mailserver bereits SPF geprüft wird. OpenSPF hat eine Liste der Implementierungen zusammengestellt.

Man kann die eigene Unterstützung testen, indem man in den Header einer E-Mail, die man von außerhalb des eigenen Mailservers empfangen hat, schaut. Folgender Header zeigt beispielhaft, dass gegen SPF erfolgreich geprüft wurde.

Received-SPF: Pass (sender SPF authorized) identity=mailfrom;
 client-ip=199.59.150.99; helo=spruce-goose-bd.twitter.com;
 envelope-from=bbbbbbbbbb2baaa=gnuheiix.de@bounce.twitter.com;
 receiver=baaa@gnuheiix.de

Um die SPF-Prüfung bei meinem Postfix an den Start zu bringen, habe ich das Package postfix-policyd-spf-python installiert und die Einrichtungsschritte der Manpage befolgt. Das ist nach 15 Minuten erledigt.

Fazit

Diese weitere Komplexitätsstufe kann den entscheidenden Unterschied bei der Spamklassifizierung machen.

X-Spam-Status: No,
  tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.552,
         SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]

Probiert es doch mal aus.

Nachtrag

29.05.2014: Es gibt auch ein Plugin für Munin.

Postfix: Verschlüsselung zwischen Mailservern

Eine vollkommen wasserdichte verschlüsselte Kommunikation mittels E-Mail ist nur durch eine Ende-zu-Ende-Verschlüsselung realisierbar. Nur wenige Nutzer greifen jedoch darauf zurück. Grundlegende Maßnahmen sind dennoch möglich.

Geschichte

E-Mail kommt aus einer Zeit, in der alles als Klartext übertragen wurde und niemand jemals an Verschlüsselung dachte. Die Zeiten haben sich geändert und das dafür zuständige Protokoll SMTP wurde um Verschlüsselungsoptionen erweitert.

Bis eine E-Mail ihren Empfänger erreicht, wird sie unter Umständen über mehrere verschiedene Mailservern geleitet. Während dieser automatischen Weiterleitungsvorgänge zwischen Mailservern kann bei unzureichenden Maßnahmen der E-Mail-Inhalt durch Dritte einfach mitgelesen werden.

Motivation

Insofern Mailserver korrekt konfiguriert sind, können sie den Mailtransport untereinander verschlüsselt durchführen, indem sie auf Bibliotheken wie OpenSSL zurückgreifen. Auch wenn man lediglich die eigenen Server beeinflussen kann, hat jeder Mailserveradministrator die Verantwortung, das Setup zeitgemäß zu halten. Verschlüsselungsverfahren gelten eben nur eine begrenzte Zeit als sicher.

Mit dem Werkzeug starttls.info kann man den eigenen Mailserver prüfen lassen und es werden allgemeine Hinweise ausgegeben, wo Verbesserungsbedarf besteht.

Konfiguration von Postfix

Ich setze Postfix als Mailserver ein und folgende Einstellungen habe ich getroffen, um besser gerankt zu werden.

smtp_tls_ciphers = high
smtpd_tls_ciphers = high
smtp_tls_mandatory_ciphers = high
smtpd_tls_mandatory_ciphers = high

smtp_tls_security_level = may
smtpd_tls_security_level = encrypt

smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3

smtp_tls_exclude_ciphers = aNULL, DES, RC4, MD5, 3DES
smtpd_tls_exclude_ciphers = aNULL, DES, RC4, MD5, 3DES
smtp_tls_mandatory_exclude_ciphers = aNULL, DES, RC4, MD5, 3DES
smtpd_tls_mandatory_exclude_ciphers = aNULL, DES, RC4, MD5, 3DES

# NO_RENEGOTIATION postfix 3.3 openssl >1.1.1
tls_ssl_options = 0x40000000
tls_preempt_cipherlist = yes
tls_eecdh_auto_curves = X25519 X448 secp521r1 secp384r1 prime256v1
tls_high_cipherlist = !aNULL:!eNULL:!CAMELLIA:HIGH:@STRENGTH

Mit den Einstellungen in *protocols deaktiviere ich SSL vollständig, da es von verschiedenen Stellen als unsicher eingestuft wird. Weiter gibt es TLS 1.0 bereits lange genug. Mit *tls_ciphers und *tls_mandatory_ciphers auf high schränke ich auf die durch Postfix als gut eingestuften Ciphers ein und danach deaktiviere ich manuell weitere mittels *exclude_ciphers.

Durch smtp_tls_security_level auf may mache ich alles optional. So kann man weiterhin mit Mailservern kommunizieren, die keinerlei verschlüsselte Kommunikation unterstützen, wie aktuell z.B. die von KabelBW und Hotmail. Wenn man Hardliner ist, kann jederzeit das Level auf encrypt gestellt werden und schon pocht Postfix auf Verschlüsselung. Es gibt aber auch noch härtere Level.

Testung

Mit sslscan kann man jederzeit die verbliebenen aktivierten Ciphers auflisten lassen.

$ sslscan --starttls --no-failed localhost:25

Weiter bietet es sich an, das Senden und Empfangen von E-Mails an große E-Mailanbieter wie gmail, gmx,... zu testen. Das Logfile von Postfix bzw. das hoffentlich korrekt eingerichtete Monitoring dessen gibt Aufschluss darüber, ob alles einwandfrei arbeitet.

Fazit

Unglaublich viele Konfigurationsparameter machen OpenSSL für einen Dienst wie Postfix nur in Verbindung mit viel Rechercheaufwand einrichtbar. Weiter muss man stets IT-Nachrichten lesen, um zu Wissen auf welche Funktionalität der Bibliothek man lieber gerade verzichten sollte.

Leider kann man OpenSSL nicht dienstübergreifend konfigurieren, wenn man es nicht gerade selbst kompilieren will.

Nachtrag

27.05.2014: Einen weiteren guten Mailservertester gibt es übrigens bei ssl-tools.net.

20.05.2015: smtp(d)_tls_ciphers hinzugefügt, danke Akimiya

28.08.2016: smtp(d)_tls_exclude_ciphers um 3DES erweitert; Noch einen guten SSL-Tester gibts bei tls.imirhil.fr.

06.12.2019: Kompatibilität zu testssl.sh in der Version 3.0

01.06.2020: Cipherlist und Protokolle für eingehende Mails aufgeweicht, um von ranziger kommunaler IT empfangen zu können - in Anlehnung an Mike Kuketz

HTTP: Header und Browsercaching

Die Standardeinstellungen der gängigen Webserver nginx und Apache sind in vielen Linux-Distribution so vorgenommen, dass sie ganz gut mit statischen Dateien umgehen können. Bei dynamisch generierten Inhalten sind sie allerdings grundsätzlich machtlos und man muss etwas in die Trickkiste greifen, um das Browsercaching sauber hinzubekommen.

Statische Inhalte

Bei ordentlich umgesetzten Websites haben statische Inhalte, wie Bilder, JavaScript, CSS, Schriften und was einem da noch so alles einfallen könnte, grundsätzlich einen gesetzten Last-Modified-Header auf die letzte Änderungszeit der jeweiligen Datei und einen gesetzten Cache-Control-Header mit einem MaxAge sehr weit in der Zukunft liegend. Alternativ kann man auch einen Expires-Header in der Zukunft liegend benutzen. Wenn einem bei sowas ein Fehler unterlaufen ist, wird einem Google Pagespeed oder YSlow freundlich aber bestimmt auf die Fehlkonfiguration hinweisen.

Der Vorteil an diesem Vorgehen ist, dass Browser eine einmal gecachte statische Datei nie wieder anfragen werden. Die Seitenaufbauzeit bereits besuchter Seiten und der erzeugte Traffic wird dadurch auf ein Minimum reduziert.

Dateiänderungen

Es gibt Leute, die den Grund aufführen, dass sie eine JavaScript- oder CSS-Datei gerne immer mal wieder ändern möchten und vermeiden wollen, gegen gefüllte Browsercaches zu laufen. Dieser Grund ist ungültig, wenn man in der Webapplikation grundsätzlich den Ansatz fährt, den Dateinamen der jeweiligen veränderten statischen Datei zu ändern sobald sich der Inhalt geändert hat. Bei JavaScript und CSS gehört es heutzutage aus Performancegründen zum guten Ton, es zu minifizieren. Im gleichen Zug kann man bei Änderungen dem Dateinamen ja auch noch um eine Hashsumme des Inhalts anreichern.

Bei Bildern und anderem gibt es meines Erachtens ebenfalls keine nennenswerten Showstopper. Die Arbeitsprozesse der Webapplikation müssen einfach darauf ausgerichtet sein bzw. werden.

Dynamische Inhalte

Webserver können grundsätzlich keine Standardaussage treffen, wie lange z.B. das HTML eines Blogbeitrags vom Browsercache vorgehalten werden soll, ohne zwischendurch neue Inhalte abzufragen. Das Blogsystem kann das in der Regel auch nicht, weil es nicht vorher wissen kann, wann ein Autor einen neuen Beitrag veröffentlichen wird oder wann eine eingebundene Twitternachricht in der Seitennavigation aufpoppen wird. Es kann aber eine klare Aussage machen, wann der Inhalt einer bestimmten URL das letzte Mal aktualisiert wurde.

Hierfür braucht das System lediglich den Last-Modified-Header oder einen Etag-Header setzen. Browser werden bei jedem Aufruf den Last-Modified-Zeitpunkt und / oder das Etag der gecachten Version mitsenden. Wenn das Blogsystem feststellt, dass die Version bereits die aktuelle ist, antwortet es mit einem HTTP 304 und sendet keinen Inhalt. Der Browser weiß damit, dass er bereits die aktuelle Version hat und kann sie ohne Download des HTML darstellen. Falls es eine neue Version gibt, kommt ein regulärer HTTP 200 mit Inhalt.

Ein MaxAge sollte man bei HTML nur setzen, wenn man sich absolut sicher ist, keine neuen Inhalte in der gegeben Zeit ausliefern zu wollen. Einen Blogbeitrag zu veröffentlichen und dies direkt zu vertwittern könnte bei heißen Browsercaches der jeweiligen aufrufenden Benutzer sonst peinlich werden.

Problem

Die von mir aufgezeigten Funktionsprinzipien des Browsercaches ohne Nachfrage bei statischen und mit Nachfrage bei dynamischen Inhalten werden von keiner mir bekannten Standardwebapplikation sauber implementiert. Im Falle von Blogsystemen schaffen es diesbezüglich weder Wordpress noch Serendipity, aus der Standardkonfiguration heraus gute Scores bei PageSpeed zu bekommen. Sie greifen den grundlegenden Mechanismus des Browsercachings nicht auf.

Die Gründe für derartige Designlücken sind mir nicht bekannt. Offenbar ist Frontendperformance für viele Leute nicht so wichtig. Es kann auch sein, dass wegen der gesteigerten Komplexität von der Umsetzung abgesehen wird.

Für mich persönlich haben Effizienz und Zuverlässigkeit die höchste Priorität. Der Funktionsumfang ist zweitrangig.

Varnish mit synthetischem Last-Modified-Header

Varnish kann man einen Last-Modified-Header zur Backendantwort hinzufügen lassen, um so für die Zeit, in der das jeweilige Objekt im Cache von Varnish liegt, Browsercache mit Nachfrage zu unterstützen.

sub vcl_fetch {
    if (!beresp.http.last-modified) {
        set beresp.http.Last-Modified = beresp.http.date;
    }
}

Varnish bügelt damit etwas aus, was in der Applikation vernachlässigt wurde. Probiert es einfach mal aus.

Munin: Monitoring von Details

Zur Überwachung meiner Server nutze ich das Monitoring-Werkzeug Munin, um wichtige Statusindikatoren kontinuierlich aufzuzeichnen und die Entwicklung der Werte jederzeit einsehen zu können. Zwischenzeitlich habe ich eine recht hohe Detailstufe erreicht.

Indikatoren

Bei meinem Monitoring-Setup sind bei der Überwachung einer jeden Maschine bis zu vier unterschiedliche Indikatortypen vorzufinden.

Systemwerte

Dies umfasst alles, was direkte Rückschlüsse auf den Status vom Betriebssystem mittels Prozessorlast, Hauptspeicherbelegung, Prozesse, Interrupts uvm. zulässt. Subsysteme wie Dateisysteme und Netzwerkkommunikation sind da auch dabei.

Angebotene Dienste

Jeder bereitgestellte Dienst hat potentiell unterschiedliche Eckpunkte, welche Überwachung erfordern. Bei Webservern bieten sich z.B. Logfiles, Workerinformationen, Requestraten, Request-RTTs, Netzlast usw. an. Bei Mailservern sind hingegen die unterschiedlichen Queues, Greylisting-Treffer, Eingeloggte Nutzer usw. interessant.

Applikationen

Dies ist die höchste Flughöhe. Es werden immer wieder Interaktionen aus Nutzersicht nachgestellt und geprüft. Dies umfasst z.B. den HTTP-Responsecode [Munin-Plugin] aller Website-Homepages, deren Ladezeit und deren Google PageSpeed-Werte.

Besonders interessant ist dabei die Auswertung von Google PageSpeed [Munin-Plugin]. Einen besseren Test gibt es in der Tat fast nicht. Die Sites werden periodisch von einem externen System abgefragt und analysiert. Selbstanalysen, wie es die bisherigen Indikatoren waren, sind zwar gut, helfen aber bei der Erkennung von externen Problemen, wie Routingfehlern, nicht. Wenn es ein externes System schafft, die eigene Applikation zu verwenden, dann ist die Chance sehr sehr hoch, dass es die Nutzer auch können.

Externe Dienste

Da ohne essentielle Dienste, wie DNS und NTP nichts sauber arbeitet, ist auch an dieser Stelle ein wenig Überwachung notwendig. So ist man in der Lage, extern verursachte Applikationsausfälle schneller eingrenzen zu können.

Benutzung

Wenn das Monitoring erst einmal ein paar Wochen gelaufen ist, erkennt man im Muster der Graphen, wie sich Nutzerzahlen zu unterschiedlichen Tageszeiten und andere Ereignisse auf die einzelnen Teilbereiche auswirken. Beispielsweise erkennt man, was z.B. das tägliche Backup, eine Konfigurationsänderung oder ein neuer Blogbeitrag für das System bedeutet.

Wenn man z.B. einen Blogbeitrag schreibt, vertwittert und dann auf einmal das Monitoring meldet, dass der Webserver sporadisch 500er rausgibt, der PageSpeed-Score sinkt und Datenbanken am Limit sind, weiß man, wo man als nächstes mit dem Hammer nacharbeiten muss, um ein optimal laufendes System für den zu erfüllenden Zweck zu haben.

Ausblick

Als nächstes habe ich vor, das Alerting auszubauen und für jeden Indikator Limits festzulegen. Munin hebt dann bei einer Limitüberschreitung den jeweiligen Graph hervor und erklärt in der Detailansicht, was wie weit überschritten wurde. Beispielsweise triggert die Verfügbarkeit von Updates bereits jetzt eine Warnung, welche mich darauf hinweist, dass ich reagieren muss.

Es gibt viele Leute, die sich für sowas E-Mails senden lassen, aber - ganz ehrlich - E-Mail ist nicht das passende Werkzeug für sowas. Was, wenn ein DNS ausfällt, alle Limits auf einmal überschritten werden und das System tausende Problemmails rauspumpt. Nicht nur fängt man sich bei sowas die Pole-Position in Spamblacklists ein, man hat auch keinen Überblick drüber, was alles wann kaputt ging.

Eine Alert-Historie hat Munin noch nicht so richtig, aber die Erweiterung ist, soweit ich weiß, in der Pipeline. Ich setze übrigens noch die Version 1.4.x ein, obwohl es bereits 2.x gibt. Ein Upgrade wird bei nächsten Betriebssystemupgrade fällig.

Infrastruktur-Graphen

Angefangen habe ich nun auch, Graphen erzeugen zu lassen, die Indikatoren mehrerer unterschiedlicher Maschinen zusammen anzeigt. Wenn man weiß, wie es geht, ist es einfach. In der Anleitung gibt es einen hervorragenden Eintrag hierfür.

Fazit

Es gibt immer etwas, was noch kein Monitoring hat. Sobald man ein Problem gelöst hat, sollte man überlegen, ob man es mit etwas mehr Monitoring schneller hätte eingrenzen können. Es ist meines Erachtens besser, erst einmal alles aufzuzeichnen. Verwerfen kann man unwichtige Daten durch umfassende Health-Report-Graphen immernoch.

Wenn man es auf die Spitze treibt, hat man nur noch eine Art Lampe, die sagt, ob alles i.O. ist. Besonders beim Treffen wichtiger Entscheidungen, ist das hilfreich.

Nachtrag

17.02.2014: Nach erneutem Lesen der Dokumentation von Munin, habe ich herausgefunden, dass es nicht geplant ist, eine Alerthistorie zu implementieren. Die Designentscheidung hingegen ist, dass Alerts an externe Programme, wie Nagios, weitergereicht werden, weil diese dafür spezialisiert sind. Gute Entscheidung!

LCA2014: Aufzeichnungen interessanter Vorträge

Die linux.conf.au, welche eine der größten Linux-Konferenzen ist, fand diese Woche statt. Es gab eine Menge sehr guter Vorträge, welche nicht immer mit Linux zu tun hatten. Einige schöne habe ich gemirrort.

Linux Filesystems: Where did they come from

Video ansehen

Der XFS-Entwickler Dave Chinner fasst sehr schön die Geschichte der Dateisystemtechnologien zusammen. Außerdem geht er auf Featurehistorie und unterschiedliche Entwicklungsstile der heutzutage wichtigen Linux-Dateisysteme ein.

Die Entwicklungsstile sind echt klasse illustriert. Die einen bauen tendenziell immer dazu und dazu und die anderen räumen auch mal komplett um und auf.

Testing for Accessibility

Video ansehen

Alice Boxhall erklärt die Hintergründe von Barrierefreiheit im Web und führt Maßnahmen und Tests auf, die man bei der Entwicklung von Webanwendungen beachten sollte.

Es ist erstaunlich, was man alles übersehen und falsch machen kann. Die im Vortrag erwähnten Entwicklertools habe ich direkt installiert und über dieses Blog eiern lassen.

TCP Tuning for the Web

Video ansehen

Jason Cook arbeitet beim Content Delivery Network fastly und erklärt, was an vorderster Front arbeitende Server die ganze Zeit tun, wenn sie unter Feuer stehen und wie man sie auf Kernellevel so konfiguriert, dass sie sich selbst so wenig wie möglich im Weg sind.

Ich finde es äußerst fesselnd, wie Jason unglaublich viele Aspekte anspricht und Lösungsmöglichkeiten aufzeigt. Leute, die hauptberuflich als Administrator im Webbereich arbeiten, werden diesen Vortrag lieben.

Synchronous Replication Even Across Datacentres

Video ansehen

Arjen Lentz zeigt, wie man Datenbanken über Rechenzentrumsgrenzen hinweg repliziert und die Applikation ausfallsicher macht. Dabei geht er auf verschiedene Replikationsarten ein. Kern des Vortrags ist die Funktionsweise von Galera in MariaDB auf hohem Detailgrad. Außerdem gibt er Hinweise, was man bei der Umstellung beachten sollte.

Ich finde es interessant zu sehen, wie Datenbanken ernsthaft eingesetzt werden. So heißen Scheiß habe ich bisher nicht gemacht, aber es ist gut zu Wissen, wie man sowas richtig macht.

A web page in seven syscalls

Video ansehen

Tollef Fog Heen ist Varnish-Entwickler und erklärt detailliert, was Varnish ist, wie er funktioniert und wie man ihn mit den mitgelieferten Werkzeugen administriert.

Mein Blog hier nutzt Varnish und ich betrachte ihn als eine der zur Zeit wichtigsten serverseitigen Technologien von heutigen Webapplikationen. Speeeed!

Raspberry Pi Hacks: Building Great Pi Projects

Video ansehen

Ruth Suehle und Tom Callaway haben ein Buch über mögliche Einsatzgebiete des Raspberry Pi geschrieben und geben einige ihrer Erfahrungen auf äußerst erfrischende Art zum besten. Tom stellt unter anderem klar, dass die Stromversorgung den größten Ärger macht.

Auch ich hatte bei meinem eigenen Raspberry Pi damit Schwierigkeiten.

Zusammenfassung

Auch wenn ich nicht alle Aufzeichnungen gesehen habe, kann ich sagen, dass es wieder eine äußerst lehrreiche Konferenz war. Wenn Du die anderen Mitschnitte willst, musst Du nach Australien, was zeitweise sehr langsam ist.

Ich habe absichtlich HTML5-Video für die Einbindung eingesetzt und hoffe, dass es ausreichend gut funktioniert. Hinterlass einfach einen Kommentar, wenn es Probleme macht. Oh, hoffentlich habe ich ausreichend wenig Besucher auf diesem Blog, sodass mein Traffickontingent nicht überzogen wird.

PHP: Versionsunterschiede mit Travis CI erkennen

Die Unterschiede zwischen den Versionen der PHP-Laufzeitumgebung sind erheblich. Dies kann man den Release Notes leicht entnehmen. Um die Auswirkungen einer Umstellung auf die eigene Applikation klar abgrenzen zu können, bedarf es Tests.

Normalerweise rollt man ein Versionsupgrade erst schrittweise auf Entwicklungs-, Test- und Stagesystemen aus. Neben den notwendigen Anpassungen sind dann parallel sämtliche Test-Suites und am Ende ein manueller Systemtest zu fahren. Dies beeinträchtigt die reguläre Arbeitsgeschwindigkeit erheblich, bis das Upgrade überall durchgeführt wurde.

Continuous Integration

Wenn Continuous Integration (CI) ein Bestandteil des gelebten Softwareentwicklungsprozesses darstellt, ist es ein unverzichtbares Instrument zur Sicherstellung der Softwarequalität.

Fakt ist, dass man nur in seltenen Fällen während einer solchen Aktion die reguläre Entwicklungsarbeit einstellen kann, was zur Folge hat, dass man sich nicht leisten kann, dass das CI-System für längere Zeit nicht mit Stage- bzw. Produktionsparametern betrieben wird.

Man kann aber das CI-System so umbauen, dass es beide Laufzeitumgebungen abdeckt.

Travis CI

Mittels Travis CI kann man in wenigen Klicks ein Repository bei Github um ein vollwertiges CI-System erweitern. Man braucht lediglich eine Konfigurationsdatei im Repository hinterlegen und schon kann man seine Test-Suites dort laufen lassen. Getriggert wird ein CI-Build unter anderem bei jedem Push, wenn man es nicht explizit im Commitkommentar unterdrückt. Selbst wenn mehrere Leute nahezu gleichzeitig pushen, werden alle Builds nacheinander erstellt und man kann Probleme komfortabel zurückverfolgen.

Man kann auch wunderbar konfigurieren, welche Versionen der PHP-Laufzeitumgebung bei der Builderstellung berücksichtigt werden sollen.

Versionsunterschiede

Zu Testzwecken habe ich mir ein Github-Repository mit ein paar wenigen Tests zusammengesteckt und es auf alle aktuell von Travis-CI unterstützten PHP-Laufzeitumgebungen losgelassen. Das Ergebnis kann man in der Ausgabe eines jeden Buildjobs - 5.2, 5.3, 5.4, 5.5, HHVM 2.3 - sehen.

array_memory.php - 100.000 Arrayelemente

Es ist zu sehen, dass Speicherverbrauch und Ausführungszeit bei 5.2 im Gegensatz zu 5.3 bis 5.5 niedriger sind. 5.3 ist dort in beiden Fällen eindeutig am schlechtesten. HHVM gibt für die 100.000 Nullerelemente keinen signifikanten Speicherverbrauch aus, braucht aber knapp das Doppelte an Ausführungszeit. Für dieses triviale Beispiel hat HHVM offenbar noch nicht die notwendige Betriebstemperatur erreichen können. Den Speicherverbrauch würde ich nur mit Vorsicht genießen.

Ich vermute stark, dass bei HHVM die Speicherverwaltung effizienter als beim regulären PHP gestaltet ist, was eine echte Wohltat wäre. 100.000 Arrayelemente mit jeweils dem Integerwert 0 sind beim regulären PHP mit um die 14 MB echt eine Menge Holz. Bevor man sowas einem einem Embedded-Entwickler zeigt, sollte man in Deckung gehen.

binarytrees.php

Ich habe mich wieder mal beim Benchmarks Game bedient, um einen kleinen aber schweren Algorithmus im Bezug auf Prozessor- und Speicherlast zu haben. PHP 5.3 ist wieder der ultimative Verlierer und 5.2 steht verhältnismäßig gut da. HHVM kann seine Stärken voll ausspielen und es zeigt sich, dass bei einem genügend komplexen Algorithmus der Overhead vom JIT irrelevant wird.

Fazit

Grundlegendes Monitoring von Rahmenparametern ist beim Fahren von Tests ratsam. So kann man beispielsweise auch schnell auf einen Performanceeinbruch, verursacht durch beispielsweise ein Datenbankupgrade oder eine frisch hinzugekommene zu teure Abfrage, hingewiesen werden.

Man sieht bei PHP klar, dass dessen Featureerweiterungen von 5.2 auf 5.3 Nachteile im Ressourcenverbrauch nach sich zogen, welche man in 5.4 und 5.5 versuchte wieder zu glätten. HHVM stellt meines Erachtens für PHP langfristig gesehen die Zukunft dar.

Ubuntu 12.04: Featured Bugs

Meinen vServer betreibe ich mit der aktuellen Version von Ubuntu Server LTS. Damit nicht noch jemand anders über die darin enthaltenen Bugs stolpert, habe ich hier ein Liste angefangen.

Ich habe das Gefühl, dass nun weniger unkritische Bugs in der aktuell laufenden Version 12.04 gefixt werden. Vermutlich hängt es damit zusammen, dass die neue LTS-Version 14.04 schon in greifbarer Nähe ist. Die folgenden Bugs haben mich selbst betroffen. Sollte ich auf weitere stoßen, werde ich diese Liste erweitern.

#1058760 - Logwatch: unmatched entries for dovecot login

Ich lasse mir wöchentlich die Zusammenfassung aller Logfiles per E-Mail senden, um eine Dokumentation des Systemstatuses zu haben und Probleme zurückverfolgen zu können. Dovecot loggt unter anderem alle Loginvorgänge. Logwatch kommt mit diesem Format nicht zurecht und verzeichnet jeden normalen Loginvorgang hervorgehoben als unbekannten Eintrag. Alleine mein Telefon ruft stündlich E-Mails ab und das macht die Zusammenfassung unnötig lang und unübersichtlich.

#1210936 - Munin: Warnings in munin-graph.log during each graph rendering run

Als Monitoring-Werkzeug setze ich Munin ein. Eine Ungenauigkeit in der Programmierung erzeugt Warnungen im Log, welche einfach nicht sein müssen.

#1052815 - Munin: users plugin throws warnings

Im Munin-Plugin users, welches Art und Anzahl der eingeloggten Betriebssystembenutzer auswertet, wird ein veralteter Programmierstil verwendet, welches mit der nun eingesetzten Version von Perl nicht mehr zusammenpasst.

Fazit

Laut Ubuntu LTS-Dokumentation wird 12.04 bis Oktober 2017 gepflegt. Obwohl es bald etwas Neues gibt, sollten meines Erachtens auch Unsauberkeiten angegangen werden. Ich mag einfach Systeme, die absolut einwandfrei arbeiten.

Software ist wie in Fässern gelagerter Whiskey, je älter, desto besser.

Markenrecht: Canonical mahnt ab

Seitdem dieses Blog existierte, setzte ich als Schriftart stets die Ubuntu Font Family ein. Heute habe ich das geändert.

Die Ubuntu-Schrift finde ich erfrischend und passend für mein Blog. Die Firma Canonical, welche hinter Ubuntu steht, hat heute mit jemandem Streit angefangen, weil das Logo in einem unpassenden Kontext eingesetzt wurde. Mir widerstrebt das Verhalten von Canonical und als Konsequenz habe ich die Schrift entfernt. Wenn ich also nun hier "Ubuntu" schreibe, bin ich vor diesem rechtlichen Logo-Angriff sicher.

Auf meiner Sympathiepunkteskala bewegt sich Canonical mit hoher Geschwindigkeit in Richtung Apple.

Performance: Der Weg zu Lasttests

Überraschungen sind beim Betrieb einer Webapplikation unerwünscht und deshalb ist es unter anderem gut zu wissen, wie viel sie aushält.

Mit dieser Information kann man dann entscheiden, ob das für den jeweiligen Zweck ausreichend ist, oder ob man die Performance noch weiter optimieren muss. Besonders nachdem man Änderungen vorgenommen hat, sollte ein Lasttest gefahren werden, um zu sehen, ob sich das System diesbezüglich verschlechtert hat.

Brot und Butter

All das, was eine Applikation sehr oft machen muss, hat so wenig Ressourcen wie nur irgend möglich zu verbrauchen. Beispielsweise bei einem Blog muss das Aufrufen von Beiträgen flutschen, damit im Ernstfall hohe Zugriffszahlen bewältigt werden können. Das Erstellen von Kommentaren ist im Vergleich äußerst selten, wodurch man dort nicht so viel Zeit investieren muss.

Wenn die Webapplikation nicht trivial ist, sollte man prüfen, wie sich die meisten Benutzer verhalten. So kann man herausfinden, wo sich Optimierungen am meisten lohnen würden.

Do it yourself

Es gibt eine Menge Werkzeuge, die einem beim Erzeugen von Last unterstützen. Diese können aber nur dann aussagekräftige Ergebnisse liefern, wenn man sie unter Rahmenbedingungen einsetzt, die der realen Nutzung entsprechen.

Folgendes ist zu beachten:

Wenn man von Daheim aus Tests durchführt, kann die eigene Internetverbindung eher ausgelastet sein, als das unter Feuer zu nehmende Zielsystem.
Wenn man direkt gegen das Produktionssystem testet, darf man sich bei dessen Ausfall nicht beschweren. Ein Testsystem mit einer möglichst der Produktionsumgebung entsprechenden Hardware, Anbindung und einem repräsentativen Datenbestand ist erforderlich.
Wenn man das zu testende System über das Loopback-Interface sich selbst belasten lässt, fehlt ein erheblicher Teil der Realität bei der Netzwerkkommunikation. Paketlaufzeiten, das Verlorengehen von Paketen und das lange Offenhalten von Verbindungen langsamer weit entfernter Clients; Weiter verfälscht man das Ergebnis, weil die Lasterzeugung selbst auch Last erzeugt.

Siege

Mit Siege kann man zusammenhanglose GET und POST HTTP-Anfragen absetzen. Externe Ressourcen wie Bilder usw. werden dabei nicht nachgeladen. Mit dem folgenden Befehl wird beispielsweise die Startseite dieses Blogs von 50 simulierten Benutzern abgefragt und dies für zehn Sekunden lang mit jeweils einer Sekunde Wartezeit zwischen der jeweiligen Benutzerabfrage.

$ siege http://gnuheidix.de/ -d1 -c50 -t10s
** SIEGE 3.0.5
** Preparing 50 concurrent users for battle.
The server is now under siege...
HTTP/1.1 200   0.04 secs:    3430 bytes ==> GET  /
HTTP/1.1 200   0.06 secs:    3430 bytes ==> GET  /
:
:
Lifting the server siege...      done.

Transactions:		         857 hits
Availability:		      100.00 %
Elapsed time:		        9.82 secs
Data transferred:	        2.80 MB
Response time:		        0.05 secs
Transaction rate:	       87.27 trans/sec
Throughput:		        0.29 MB/sec
Concurrency:		        4.78
Successful transactions:         857
Failed transactions:	           0
Longest transaction:	        0.15
Shortest transaction:	        0.04

Die Auswertung des Testlaufs ist informativ, spiegelt aber wie gesagt nur die der Startseite alleine wider. Dies lässt dadurch keine Aussage über die Zugriffsfestigkeit zu. Dieser Test ergibt Sinn, wenn die abzufragende Seite bei jeder Anfrage on-the-fly gerendert wird und man wissen möchte, ab welcher Anzahl an gleichzeitigen Zugriffen dieser Prozess in die Knie geht.

Apache JMeter

Im Gegensatz zu Siege kann man sich bei JMeter umfangreiche Testsuites zusammenklicken, bei denen einzelne Aufrufe voneinander abhängen und Prüfungen der Abfrageergebnisse durchgeführt werden. Die Bedienung ist entsprechend der vielen Möglichkeiten kompliziert. Die Hilfefunktion ist allerdings sehr ausführlich und verständlich.

Dave Gardner hat in seinem Blogbeitrag Effective load testing with Apache JMeter gut beschrieben, wie man etwas mehr als nur einen "Hello World" HTTP-Request macht.

Dienstanbieter

Da nicht jeder eine gut angebundene Maschine hat, die zur Erzeugung der Last benutzt werden kann, wurden einige Plattformen entwickelt, die darauf spezialisiert sind, Last auf anderen Systemen zu erzeugen.

Last erzeugt man mit Netzwerktraffic und das kostet Geld. Die meisten Anbieter geben aber ein gewisses Monatskontingent frei.

Blitz

Bei Blitz gibt man eine unter Last zu setzende URL mit ein paar Rahmenbedingungen wie Dauer, simulierter Benutzeranzahl, Anfragenherkunft, Ramp-Up usw. ein und schon bekommt man zwei schicke Graphen und einen kurzen Report über Fehler und Antwortzeiten. Blitz ist mit Siege vergleichbar. Es werden keine externen Ressourcen nachgeladen. Besonders praktisch finde ich, dass man sich von verschiedenen Rechenzentren aus unter Feuer nehmen lassen kann.

Load Impact

Etwas mehr als Blitz kann Load Impact. Dort werden alle Ressourcen nachgeladen und man kann sich Benutzungsszenarios zusammenbauen. Dies kann man in einer Art Skript machen oder Klickpfade direkt im Browser aufzeichnen lassen. Es ist sogar möglich, die Anfragen aus Rechenzentren verschiedener Länder gleichzeitig kommen zu lassen. Am Ende gibt es einen verlinkbaren Report. Die Möglichkeiten kommen zwar bei weitem nicht an JMeter heran, aber für die meisten Zwecke dürfte es ausreichen.

Fazit

Lasttests gehören einfach in den Entwicklungsprozess einer jeden guten Webapplikation. Dabei ist es egal, ob es ein Blog, ein Shop, eine Kommunikationsplattform oder ein API ist. Habt bei Euren Tests stets genügend Monitoring auf das zu testende System ausgerichtet, um herausfinden zu können, an welcher Stelle der Applikation Probleme auftauchen. Falls Ihr das nicht macht, ist die Findung von Verbesserungsansätzen reines Rätselraten.

Nachtrag vom 04.01.2014

Bei Blitz kann man nun bis zu vier URLs angeben, die beim Testlauf auch abgerufen werden sollen. So könnte man also im Falle eines Blogs die Startseite laden, einen Beitrag aufrufen und einen Kommentar schreiben. Auf einen sehr kurzen Report kann man sogar verlinken. Dessen Informationsgehalt ist gering, aber zum Angeben reicht es.

Nachtrag vom 09.08.2016

Seit der Version 4.0.0 von Siege ist die Option parser zur siegerc hinzugekommen. Diese standardmäßig aktivierte Funktionalität parst das geladene HTML und fügt nun auch Bilder, Stylesheets, Skripte,... mit zur Liste der URLs hinzu, die abfragt werden.

Munin: Graph-Größen anpassen

In letzter Zeit habe ich die Graphen des Monitoring-Werkzeugs Munin öfters mittels Zoomfunktion im Browser vergrößert, um auf hochauflösenden Monitoren genug erkennen zu können. Das geht auch anders.

Entweder stieg die Pixeldichte meiner Monitore oder meine Augen werden schlechter. Egal, ich halte die standardmäßige Größe von 400 mal 200 Pixel für nicht mehr zeitgemäß.

Master-Konfiguration

In der Konfiguration des Munin-Masters, welcher die Graphen und die HTML-Seiten rendert, kann man die Standardbreite und -höhe global oder gruppenweise festlegen.

/etc/munin/munin.conf

# global
graph_width 600
graph_height 300

[gnuheidix.de]
    # aktuelle Gruppe
    graph_width 600
    graph_height 400

Man kann diese Einstellung auch im Node oder im Plugin selbst durchführen, aber ich rate davon ab. Der Master gibt die Graphen aus und es ist meines Erachtens seine Verantwortlichkeit, die Größe zu bestimmen.

Plugin-Konfiguration

Mir ist aufgefallen, dass beispielsweise das Plugin diskstats der Meinung ist, die Graphbreite selbst festlegen zu müssen. Zum Glück kann man den hartcodierten Wert noch mit einer Pluginkonfiguration im Node überschreiben.

/etc/munin/plugin-conf.d/munin-node

[diskstats]
env.graph_width 600

Die Gründe für dieses Plugin-Verhalten sind mir aktuell nicht klar. Im Plugincode wird eine Menge daran herumgerechnet, wie breit der Graph nun sein soll. Ich werde dem nachgehen und für Tipps bin ich natürlich dankbar.

Fazit

Wieder einmal zeigt sich, wie vielseitig Munin ist. Zu viele Möglichkeiten, etwas lösen zu können, erfordern enorme Disziplin, da man sich sonst sehr schnell alles verbaut. Glaub mir, ich entwickle beruflich zur Zeit mit PHP Webshops. Ich spreche aus Erfahrung.

Webserver: Ausliefern zufälliger Inhalte

Auch wenn die Problematik vielleicht selten vorkommen mag, ist das Ausliefern zufälliger Inhalte für eine Webanwendung nicht trivial. So viele Möglichkeiten...

Motivation

Die Seite shipitsquirrel.github.io finde ich klasse. Dort wird einfach ein Eichhorn gezeigt, welches zum Shippen eines Produkts auffordert. Ich wollte etwas ähnliches haben.

Es gibt niemanden, der "Make it so." besser sagen kann, als der Captain des Raumschiffs USS Enterprise NCC-1701-D aus dem Universum von Star Trek. Jeder, der von der Serie Star Trek - The Next Generation noch nie etwas gehört hat, wird jetzt nur noch wtf? denken, aber das ist mir egal. Die Allgemeinbildung ist einfach nicht gleichmäßig verteilt.

Gerne möchte ich beim Aufruf des Systems immer mal ein anderes Bild mit dem Spruch "Make it so" ausliefern lassen. Es soll schließlich nicht gar so schnell langweilig werden.

Die Subdomain makeitso war von mir schnell angelegt und während sich das nun munter unter den DNS-Servern herumgesprochen hatte, stand ich vor der Qual der Wahl.

Möglichkeiten

In welchem Layer meines Setups löse ich das nur?

Varnish-Cache

Varnish kann selbst praktisch keine bei sich liegenden Inhalte ausliefern. In seiner Konfigurationssprache VCL kann man lediglich kurze personalisierte Fehlermeldungsrückgaben zusammenbauen. Damit ein Bild auszuliefern, ist Quark. Mit Umleitungen kann Varnish aber sehr gut umgehen. Ein Round-Robin-Umleiter ist in VCL schnell zusammengesteckt.

sub vcl_recv {
    if(req.http.host ~ "makeitso.gnuheidix.de"){
        error 750 "Make it so";
    }
}

sub vcl_error {
    if (obj.status == 750) {
	set obj.status = 302;

        # true on each odd request id
        if (req.xid ~ "[13579]$"){
             set obj.http.Location = "http://ownsite.de/1.jpg";
        }else{
             set obj.http.Location = "http://ownsite.de/2.jpg";
        }

        return(deliver);
    }
}

Abhängig von der Anzahl der Bilder wird öfters ein anderes kommen als beim Aufruf zuvor. So ganz prickelnd finde ich die Lösung nicht, weil man tatsächlich weggeleitet wird und man für jede Bildererweiterung an der Varnish-Konfiguration basteln muss. Zur Syntaxprüfung der Konfiguration kann man folgenden Befehl nutzen.

sudo varnishd -C -f /etc/varnish/default.vcl

Die Weiterleitungsziele sollten auch auf eigenen Systemen liegen, damit sich niemand anders gestört fühlt. Zum einen hat nicht jeder ein performantes Setup und zum anderen kostet Traffic Geld. Weiter ist Bandbreite leider für jede Maschine endlich.

Nginx

Es gibt ein sehr schönes Modul, welches genau für den Zweck zu passen vermag. Mithilfe vom HttpRandomIndexModule kann man Inhalte eines Verzeichnisses zufällig ausliefern lassen.

Bei Ubuntu ist das Modul aber nur in den Nginx des Pakets nginx-extras hineinkompiliert, wodurch ich nginx-full ersetzen musste. Das ist nicht schlimm, dachte ich. Nach dem Ersetzen des Pakets kam Nginx nicht mehr hoch. Er meldete, dass Port 80 bereits durch einen anderen Prozess belegt ist. Das ist vollkommen richtig. Varnish gehört dieser Port. Tatsächlich hat der Paketwechsel die Defaultkonfiguration mittels Symlink in /etc/nginx/sites-enabled/ aktiviert. Naja, das Paket hat es gut gemeint, aber es hat mir gezeigt, dass man bei Ubuntu nicht stets die volle Kontrolle hat.

Varnish muss bei diesem Ansatz alles zum Webserver durchleiten ohne an Caching zu denken.

sub vcl_recv {
    if(req.http.host ~ "makeitso.gnuheidix.de"){
        return (pass);
    }
}

Nginx wird auf das Verzeichnis ausgerichtet und browserseitige Cachingmechanismen werden entschärft.

server {
    listen   127.0.0.1:8081;

    root /srv/www/makeitso.gnuheidix.de;
    server_name makeitso.gnuheidix.de;

    location / {
        random_index  on;
        if_modified_since off;
        add_header Last-Modified "";
    }
}

Funktioniert! Seht Euch makeitso.gnuheidix.de an und ladet ein paar Mal neu. Der Zufall hält sich bei zwei Dateien zwar in Grenzen, aber so muss es aussehen. Die Erweiterbarkeit ist auch sehr gut, weil man keine Konfiguration ändern muss, um neue Bilder aufzunehmen.

PHP

Die im Webservermodul realisierte Funktionalität hätte ich auch in einem PHP-Skript abbrennen können. Es wäre allerdings um Welten langsamer. Auf eine mögliche Beispielimplementierung verzichte ich an dieser Stelle.

Ergebnis

Mein MakeItSo-Generator ist schick umgesetzt und gefällt mir. Alles, was nicht bis in die niedrigste Systemschicht muss, ist eine potenziell erwägenswerte Lösung.

HHVM: Darf es in die Produktion?

In den letzten Tagen habe ich mit HHVM experimentiert, einiges geschrieben und ich bin beeindruckt, wie gut es bereits funktioniert. Jetzt steht natürlich die glorreiche Frage im Raum, ob man es bereits auf Produktivsystemen einsetzen sollte.

Fakten

Es ist Freie Software.
In Sachen Kompatibilität zu PHP wird stets etwas fehlen.
Es wird stetig weiterentwickelt, um mit aktuellen PHP-Versionen und deren Features schritthalten zu können.
Facebook nutzt HHVM seit 2013 produktiv. Sein Vorgänger war HPHP, welcher seit ca. 2008 in der Entwicklung war.

Meinung

Die Fakten klingen doch nicht schlecht, oder?

Offenheit

Ganz wichtig finde ich persönlich, dass ich in die Software hineinschauen kann und Änderungen vornehmen darf. Alleine diese Macht zu haben, gibt mir schon ein sicheres Gefühl, wenn es brennt, nicht komplett aufgeschmissen zu sein. Ja, ich werde den Code mangels Zeit höchstwahrscheinlich nicht komplett auditieren, aber andere interessierte Entwickler werden das tun. Falls doch mal ein Problem unerkannt bleibt, wird es nach dem Erkennen zeitnahe behoben werden können.

Kompatibilität

Die aktuelle PHP-Version setzt meines Erachtens kaum jemand produktiv ein, weil sie die großen Distributionen erst in die Mainstream-Repositories aufnehmen, wenn sie zumindest etwas abgehangen ist. Selbst Gentoo hat die zum Zeitpunkt der Veröffentlichung dieses Blogbeitrags aktuelle Version PHP 5.5 noch als unstable markiert. Es ist also nicht schlimm, wenn die Bleeding-Edge-Features nicht am Start sind. Um die Kompatibilität zu einer PHP-Anwendung zu prüfen, sollte zumindest die Testsuite der Anwendung mit HHVM ausgeführt und die Ergebnisse und vor allem Laufzeiten verglichen werden.

Entwicklung

Das Projekt sieht von der Anzahl der mitarbeitenden Personen und den Commits gesund aus. Der Issue-Tracker ist gut gefüllt und wird bearbeitet. Weiter finde ich, dass die Dokumentation auf dem richtigen Weg ist.

Verbreitung

Mir ist keine andere Firma oder Person als Facebook selbst bekannt, die HHVM produktiv einsetzt. Im Readme des Projekts steht wörtlich:

HipHop is most commonly run as a standalone server, replacing both Apache and modphp.

Die Software an vorderster Front bei geringer Verbreitung einzusetzen, halte ich persönlich für gefährlich. Nicht umsonst hat es viele viele Jahre gebraucht, bis beispielsweise der Apache-Webserver die Stabilität und Robustheit von heute erreicht hat. Der Code wurde einfach von vielen Leuten eingesetzt, geprüft und verbessert ohne dabei einer Featuritis zu verfallen. Sicherheitslücken gibt es in Apache deshalb vergleichsweise wenig. Genau das fehlt meines Erachtens HHVM noch.

Fazit

Nur wenn unkritische Anwendungen betrieben werden, würde ich HHVM als Standalone-Server einsetzen. Gegen den Einsatz bei einzelnen rechenintensiven Prozessen spricht wenig, wenn die Eingaben nicht von potenziell bösen Nutzern stammen.

Das ist nur meine Meinung.

PHP: HHVM-Benchmark

Im Benchmarksgame schneidet PHP stets äußerst schlecht ab. Die Implementierung in C benötigt meist wenige Sekunden Ausführungszeit, wohingegen PHP stets mehrere Minuten den Rechner belastet. Was bringt da HHVM?

Ausgangssituation

In meinem letzten Blogbeitrag habe ich herausgefunden, dass durch HHVM im Falle der Applikation Serendipity keine erhebliche Beschleunigung erzielt wird, wenn man PHP in Verbindung mit XCache einsetzt.

Offensichtlich habe ich nicht den Anwendungsfall getroffen, für den HHVM einst gebaut wurde. Dann lasse ich es eben richtig rechnen. Am Binarytree-Benchmarksgame habe ich mich hierfür bedient.

Auf der dort vorliegenden Testumgebung benötigt PHP 5.5 satte elf Minuten und C etwa zehn Sekunden für den selben Algorithmus.

Testumgebung

Ich habe wieder meine Hiphop-VM gestartet, alle unnötigen Dienste deaktiviert und den Quellcode vom Binarytrees in eine PHP-Datei gesteckt. Beim ersten Ausführungsversuch mit PHP 5.3 wird mir trotz Speicherlimit von zwei Gigabyte die folgende Meldung ausgegeben.

hiphop@hiphop-test:~$ php -n -d memory_limit=2048M binarytrees.php 20
Fatal error: Allowed memory size of 2147483648 bytes exhausted (tried to allocate 73 bytes) in /home/hiphop/binarytrees.php on line 18

Ich verkneife mir jetzt jeglichen Kommentar und aktualisiere die PHP-Version auf 5.4, weil dort diesbezüglich optimiert wurde.

Es ist zu erwarten, dass mein Setup die beim Benchmarksgame angegebenen elf Minuten nicht exakt erreicht, da ich andere Hardware am Start habe.

Durchführung

Die Ausgabe des Benchmarkskripts binarytrees.php sieht stets wie folgt aus. Es wird also bei jedem Testlauf richtig gerechnet.

stretch tree of depth 21	 check: -1
2097152	 trees of depth 4	 check: -2097152
524288	 trees of depth 6	 check: -524288
131072	 trees of depth 8	 check: -131072
32768	 trees of depth 10	 check: -32768
8192	 trees of depth 12	 check: -8192
2048	 trees of depth 14	 check: -2048
512	 trees of depth 16	 check: -512
128	 trees of depth 18	 check: -128
32	 trees of depth 20	 check: -32
long lived tree of depth 20	 check: -1

Nun folgen die Ausführungszeiten ohne die Skriptausgaben.

PHP 5.4 mit Standardeinstellungen

Der Schalter n deaktiviert die php.ini und damit jegliche Extensions.

hiphop@hiphop-test:~$ time php -n -d memory_limit=2048M binarytrees.php 20

real	8m26.254s
user	8m4.882s
sys	0m21.217s

Die Zeit weicht wie erwartet ab, bewegt sich aber in gleichen Regionen.

PHP 5.4 mit XCache

Ohne den Schalter n wird nun auch auf XCache zurückgegriffen.

hiphop@hiphop-test:~$ time php -d memory_limit=2048M binarytrees.php 20

real	8m27.003s
user	8m5.634s
sys	0m21.201s

Die Zeit steigt minimal im Vergleich zur Standardeinstellung.

HHVM mit Standardeinstellungen

Es muss kein Speicherlimit gesetzt werden, weil HHVM in den Standardeinstellungen keines gesetzt hat.

hiphop@hiphop-test:~$ hhvm --version
HipHop VM v2.1.0-dev (rel)
Compiler: tags/HPHP-2.1.0-0-gee8da60efaad9398eb4fb5909ede5cf6bb662128
Repo schema: 56ccb9c5c4a45b351e042a3b4da0b98d7e4e27f9

hiphop@hiphop-test:~$ time hhvm binarytrees.php 20

real	4m34.108s
user	4m33.741s
sys	0m0.176s

Cool!

Zusatztest: PHP 5.5 mit eigenem OpCode-Cache

Um allen gerecht zu werden, habe ich auch einen Testlauf mit der aktuellsten PHP-Version gefahren. Ich setze den Schalter n nicht, damit die gesamte Zend-Magic in Betrieb ist. Früher hieß das Teil übrigens nicht einfach OPcache sondern Optimizer Plus.

hiphop@hiphop-test:~$ php -v
PHP 5.5.1-1~precise+1 (cli) (built: Jul 22 2013 07:33:14) 
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2013 Zend Technologies
    with Zend OPcache v7.0.2-dev, Copyright (c) 1999-2013, by Zend Technologies

hiphop@hiphop-test:~$ time php -d memory_limit=2048M binarytrees.php 20

real	8m32.390s
user	8m9.683s
sys	0m22.509s

Bummer!

Ergebnis

PHP 5.3 ist ein Speicherschwein.

PHP 5.4 kommt mit zwei Gigabyte Speicherlimit aus und es ist irrelevant, ob XCache aktiviert ist. Es benötigt knappe 8,5 Minuten. XCache erzeugt unnötigen Overhead, weil es nie einen Cachehit erzeugen kann. Das Skript läuft eben exakt ein einziges Mal.

HHVM benötigt lediglich 4,5 Minuten. An dieser Stelle kommt der JIT voll zum Tragen. Ich habe mir eine erheblichere Beschleunigung gewünscht, aber eine knapp 50 prozentige Verkürzung der Ausführungszeit ist ein gutes Ergebnis.

PHP 5.5 braucht gute 8,5 Minuten und damit noch mehr Zeit als 5.4. Ich betrachte das als Reinfall.

Fazit

Wenn Ihr also langlaufende rechenintensive Prozesse in PHP benutzen müsst, probiert HHVM definitiv mal aus.

PHP: Apachemodul vs. HHVM

Dass PHP bzgl. Performance nicht gut ist, steht außer Frage. Überspitzt gesagt sind viele Handstände notwendig, um Webanwendungen, die darauf zurückgreifen, so gut einzurichten, dass sie bei endlichem Ressourcenverbrauch mehr als eine Hand voll Anfragen gleichzeitig bedienen können. Heute habe ich ein Experiment zur Beschleunigung der reinen Ausführungsgeschwindigkeit durchgeführt.

Oldschool

Im 0815-Style werden Webanwendungen unter Verwendung von Apache mit mod_php deployt. Apache führt dabei den PHP-Code in seinen Arbeitsprozessen direkt aus. Bei jeder Anfrage, die PHP benötigt, wird das angefragte Skript aus dem Dateisystem geholt und Zeile für Zeile interpretiert. Das verbraucht aus technischer Sicht unter anderem viel Prozessorzeit, welche bei jeder Anfrage erneut aufgewendet werden muss, auch wenn sich der PHP-Code selbst nicht geändert hat. Unterm Strich wird also durch unnötige repetitive Arbeit Strom in Abwärme umgewandelt.

HipHop VM for PHP (HHVM)

Die Entwickler der Werbeplattform Facebook greifen ebenfalls auf PHP zurück. Aufgrund der vielen Millionen täglichen Benutzeranfragen haben sie HHVM zur Just-in-time-Kompilierung von PHP-Skripten entwickelt. Es basiert auf der Idee von phc, wurde aber nicht auf maximale Kompatibilität optimiert, was einen Geschwindigkeitsvorteil bringt.

Testumgebung

Ich habe mir eine VM in Virtualbox mit Ubuntu-Server 12.04 amd64 geklickt und den Apache mit mod_php, welche auf PHP-Version 5.3 zurückgreift, installiert. Weiter habe ich die Blogsoftware Serendipity, welche ich auch für diesen Blog einsetze, heruntergeladen, den Apache darauf ausgerichtet und die Installation unter Verwendung von SQLite als Datenbankbackend durchgeführt. Ich habe einen Testbeitrag im Blog erstellt, damit es mehr als nur eine leere Startseite gibt. Das Kommentieren des Beitrags klappt auch. So weit so gut.

Um HHVM nutzbar zu machen, habe ich die entsprechende Paketquelle eingerichtet und das Hiphop-Paket installiert. Hiphop hat keine vordefinierte Konfigurationsstruktur wie Apache. Das muss man sich selbst zusammenlöten, wenn man es produktiv einsetzen möchte.

Status: Apache läuft und bedient Anfragen auf Port 80, HHVM ist aus

Rahmenbedingung: Es gibt praktisch keine Netzwerkwartezeiten, da wir alles auf einer Maschine machen. Es gibt Overhead durch die VM, welcher aber bei beiden Testkandidaten gleichermaßen existiert.

Durchführung

Ich öffne zwei Browsertabs und Firebug ist auf Netzwerkanalyse ausgerichtet. Ich lade die Startseite zehn Mal neu. Die Time-to-first-byte liegt beim Apache bei etwa 60ms. Ich fahre den Apache herunter und starte HHVM im Serendipityhauptverzeichnis mit folgendem Befehl.

sudo hhvm -m server -p 80

Nun lade ich im zweiten Browsertab die Seite zehn Mal neu. Die Time-to-first-byte pegelt sich nach drei Ladevorgängen bei etwa 15ms ein. Das Serendipity-Backend ist auch nutzbar.

Fazit

Dieses Experiment hat eindrucksvoll gezeigt, wozu Hiphop VM for PHP in der Lage ist. Eine Laufzeitverringerung um satte 75% ist ein sehr gutes Ergebnis. Jeder, der eine stark unter Feuer stehende PHP-Webanwendung betreibt, hat die Chance mit HHVM die Applikationsperformance zu erhöhen, insofern die Kompatibilität gewährleistet ist.

Facebook betreibt übrigens auch ein WordPress-Blog mit und über Hiphop.

Probiert es doch einfach selbst aus.

Nachtrag: XCache

Da ich die Testumgebung einmal aufgebaut hatte, ließ ich es mir nicht nehmen, Apache einmal mit und einmal ohne XCache laufen zu lassen. Siehe da, im Falle der Webapplikation Serendipity bewegt sich die TTFB-Beschleunigung bei aktiviertem XCache im Vergleich zur Standardinstallation ohne auch bei etwa 75%. Bei einem Ubuntu-Server reicht damit die Installation vom Paket php5-xcache aus, um Serendipity serverseitig enorm zu beschleunigen.

JavaScript: Visual Event 2

Nicht selten musste ich bisher bei mir unbekannten Websites herausfinden, auf welchen Events welche DOM-Elemente registriert sind. Visual Event 2 von Allan Jardine ist dabei eine große Hilfe.

Nach dem Aktivieren dieses Bookmarklets werden alle auf Events lauschenden DOM-Elemente farblich hinterlegt und beim Anklicken wird angezeigt, welches Event der Auslöser ist und welcher Codeabschnitt die Verarbeitung übernimmt. Eine tiefgreifende Recherche ist damit nicht möglich, aber für einen Anfang ist das schon mal sehr gut. Der Punkt in der linken oberen Ecke zeigt Events, die am Dokument hängen.

Probiert es doch einfach selbst aus.

Varnish: Fehlerbehandlung bei Backendfehlern

Gestern hatte mein Server ein Problem mit seinem Dateisystem. Es ist plötzlich Read-Only geworden und dadurch konnte das PHP beim Rendern der Seiten keine Cachedateien mehr erzeugen. Lediglich eine Fehlermeldung war beim Aufruf dieses Blogs zu sehen. Sowas in der Mittagspause zu entdecken, ist schon bitter.

Webanwendung mit Problemen

Ohne schreibend auf das Dateisystem zugreifen zu können, quittierte das Blogsystem Serendipity sofort den Dienst. Es wurden nur noch Fehlermeldungen mit dem HTTP-Fehlercode 500 ausgegeben. Dank des stets heißen Varnish-Cache hat man das als Benutzer beim Klicken durch die Seiten ohne Kommentare zu schreiben nicht gemerkt. Erst als das Alter der Cacheeinträge eine Stunde überschritten hatte, verwarf Varnish diese und die Fehler waren auf allen Seiten in voller Pracht zu sehen.

Sonderbehandlung für Backendfehler

Varnish beantwortet alle HTTP-Anfragen einer Site. Alles, was nicht in dessen Cache ist, wird beim Webserver Nginx angefragt. Jener fragt wiederum PHP und so weiter. Nginx ist also das Backend von Varnish, welches in meinem Fall nicht mehr korrekt arbeitete. Glücklicherweise ist in der Anleitung von Varnish ein Kapitel, welches erklärt, wie man mit einer fehlerwerfenden Webanwendung umgehen kann.

Grace-Mode

Meine Konfiguration umfasst nun, dass etwas einst korrekt gecachtes von Varnish nur dann verworfen wird, wenn der jeweilige Cacheeintrag:

mindestens eine Stunde alt ist und das Backend eine fehlerfreie Antwort liefert.
älter als fünf Tage ist.

Saint-Mode

Weiter lasse ich Varnish beim Auffrischen eines abgelaufenen Cacheeintrags erst nach einer Minute einen neuen Auffrischungsversuch unternehmen, wenn währenddessen ein Backendfehler aufgetreten ist. Damit versuche ich zu verhindern, dass bei vielen Fehlern das Backend durch Überlastung den Geist aufgibt.

Fazit

Dieses Vorgehen hat zur Folge, dass Backendfehler nicht so schnell für den Sitebesucher sichtbar werden. Es erfordert aber gleichzeitig ein Monitoring, welches nicht nur schaut, ob beim HTTP-Request von außen etwas kommt. Vielmehr muss der Gesundheitszustand des Backends selbst überwacht werden. Ich löse das so, indem ich alle paar Tage ins Munin schaue und prüfe, ob der Webserver nginx etwas ins Errorlog geschrieben hat. Besser wäre es allerdings den Server an ein externes Monitoring anzuschließen. Ein System kann sich schließlich nur bis zu einem gewissen Grad selbst überwachen.

Ich hoffe, ich konnte Euch insofern helfen, dass Ihr nicht die gleichen Fehler wie ich macht.

Nachtrag

Fehler müssen nicht zwangsläufig den Code 500 haben. Ich betrachte alles >= 500 als Fehler und aktiviere hierfür dann den Saint-Mode. Wenn z.B. das PHP-Backend down ist, meldet nginx einen 502 an Varnish und der sollte damit umgehen können. Schaut in meine Varnishkonfiguration.

Ghostery: Externe Dienste erkennen und blockieren

Die Einbindung von Diensten externer Anbieter ist auf Websites heutzutage nichts Neues. Analytics, Werbung, Marketing,... werden dabei vom Websitebetreiber eingekauft und unterstützen ihn beim Erreichen mehr oder weniger sinnvoller Ziele. Ein tolles Werkzeug, welches diese externen Einbindungen komfortabel sichtbar macht, ist das Firefox-Plugin Ghostery.

Ghostery

Dieses Plugin besitzt eine vom Hersteller gepflegte Liste an bekannten Einbindungen, welche periodisch aktualisiert wird. Diese hat keinen Anspruch auf Vollständigkeit. Besonders selbstgebaute Lösungen, die kaum verbreitet sind, werden dadurch nicht erkannt. Nichtsdestotrotz ist es erstaunlich, was alles so eingesetzt wird. Besonders Nachrichtenseiten binden eine Menge Zeug ein. Kein Wunder, dass sie X Handstände machen müssen, um die Frontendperformance nicht allzu sehr zu beeinträchtigen.

Aktuell meldet mir Ghostery, dass es 740 Cookies und 1490 Pixel externer Anbieter erkennen und auf Wunsch blockieren kann.

Alternative

Ohne dieses Werkzeug könnte man auch alle derartigen Einbindungen erkennen. Man müsste lediglich das HTML und JavaScript der Website Zeile für Zeile durchgehen. Wenn alles minified ist und selbst ein Beautifier nur Müll liefert, bleibt fast nur noch der Blick ins Protokoll der Netzkommunikation und das Setzen von XHR-Breakpoints. Beim Firefox macht man das in der Webkonsole und die ist über die Tastenkombination Ctrl+Shift+K zu erreichen. Selbst da sieht man nicht wirklich gut, was genau über WebSockets nach draußen kommuniziert wird.

Probiert Ghostery einfach auf Euren Lieblingssites aus.

Serendipity: Performancezentriertes Serversetup

Im September 2012 habe ich dieses Blog auf Serendipity umgestellt. Seitdem habe ich Erfahrungen gesammelt, wie ich meinen Server gut für diese Anwendung einstelle, um eine höchstmögliche Performance herauszuholen.

Motivation

Mir liegt die Performance von Websites sehr am Herzen. Es stört mich, wenn ich warten muss und noch mehr stört es mich, wenn eine Webanwendung wie Serenditpity (S9y), Wordpress usw. zum Beantworten einer Anfrage aufwändige Berechnungen durchführt und diese danach komplett verwirft. Kommt die gleiche Anfrage eine halbe Sekunde später nochmal, muss die Antwort erneut berechnet werden.

In einem 0815-Setup muss ein Webserver für jede Anfrage PHP bemühen, viele Skripte auszuführen, welche wiederum Datenbankabfragen durchführen. Nach diesem Brimborium, kann er die fertiggerenderte Antwort endlich an den anfragenden Webbrowser senden. Wenn es eine etwas durchdachtere Webapplikation ist, benutzt sie selbst Caches, um Berechnungen und Datenbankabfragen zu reduzieren.

Nichtsdestotrotz halte ich alles für unperformant, was über PHP abgewickelt wird. Häufig vorkommende Aufrufe will ich dort nicht permanent durchleiten, es darf schließlich nur wenig Systemressourcen benötigen. Andernfalls reicht es, wenn Fefe einen Link setzt, um die Site zu lüften. Selten vorkommendes wie das Hinzufügen eines Kommentars oder das Editieren eines Blogbeitrags kann ruhig einen Augenblick länger dauern.

Architektur vereinfacht erklärt

In meinem Setup werden HTTP-Anfragen von außen auf Port 80 vom Cache Varnish entgegen genommen. Kennt Varnish die Antwort auf die Anfrage bereits, beantwortet er sie direkt. Wenn nicht, fragt er den Webserver nginx auf dem lokalen Port 8081. Wenn die angefragte Ressource statisch ist, zieht sie Nginx aus dem Dateisystem. Wenn die Ressource auf ein PHP-Skript abzielt, spricht nginx mit php-fpm über das FastCGI-Protokoll auf einem UNIX-Domain-Socket. php-fpm lässt einen neuen oder arbeitslosen Arbeitsprozess die Antwort in Verbindung mit XCache rendern. Dabei auftretende Datenbankabfragen laufen gegen eine SQLite-Datenbank. Varnish merkt sich jede Antwort von nginx für knapp eine Stunde. Ein Cacheanheizer läuft stündlich über die Site und aktualisiert im Varnishcache die wichtigsten Ressourcen.

Das 0815-Setup hat lediglich den Apache-Webserver mit mod_php. Apache führt selbst das PHP bei Bedarf aus und blockiert jeweils einen seiner Arbeitsprozesse dabei. PHP spricht bei Bedarf mit einer MySQL-Datenbank über eine TCP-Socketverbindung.

Varnish

Jede Webapplikation benötigt potenziell eine eigene Varnishkonfiguration. Bei S9y können sogar einzelne Plugins Anpassungen erfordern. Varnish hat eine eigene Konfigurationssprache namens VCL. Sie ist mit der vhost-Konfiguration von Apache vergleichbar, welche auch für jede Site individuell ist.

Bei meinem Blog ist bis auf das S9y-Backend und die Kommentarfunktion alles cachebar. Dem entsprechend habe ich auch meine Konfiguration gestaltet. Die Cacheverfallsdauer ist auf exakt eine Stunde minus zwei Sekunden eingestellt.

Solange die Cacheeinträge nicht veraltet sind, kann ich den Webserver nginx sogar runterfahren. Die Site bleibt verfügbar. Bei anderen Setups kann in Verbindung mit Varnish die Datenbank wegglühen, externe Ressourcen nicht antworten oder die Festplatten vollgas arbeiten. Varnish hat alles im Hauptspeicher und bedient, soweit er kann, Anfragen.

Cacheanheizer

Ein profaner Cronjob läuft exakt stündlich über die gesamte Site und aktualisiert damit den Varnishcache.

cd /tmp && wget --header "X-Varnish-Nuke:1" --mirror -A '*.html','*.css','*.js','*.png','*.jpg','*.gif' --delete-after http://gnuheidix.de

Bilder sind in meinem Blog nur Schmuckwerk und können getrost ein wenig langsamer sein. Wenn weitere Ressourcen z.B. für den Style benötigt werden, sollten sie an dieser Stelle mit angeheizt werden.

Nginx

Ich habe mich für diesen Webserver entschieden, weil er einfach wesentlich performanter ist als Apache und trotzdem Features wie Rewrites unterstützt. Weiter ist er auch weit verbreitet und dadurch gut getestet. Für Nginx wird wieder eine eigene Konfiguration benötigt. Besonders wichtig ist dabei der S9y-Teil und der FastCGI-Teil. Die Rewrites lassen die URLs gut aussehen und die FastCGI-Konfiguration übergibt einfach alles an php-fpm, was nach PHP riecht.

php-fpm mit XCache

Durch php-fpm ist unter anderem die Überwachung langsamer PHP-Prozesse sehr einfach. Weiter lässt er stets nur so viele Arbeitsprozesse am Leben, um die aktuelle Last gut abzuarbeiten, was Hauptspeicher spart. Mittels XCache muss ein PHP-Arbeitsprozess die Skripte nicht immer von Grund auf verarbeiten. Es wird der OpCode im Hauptspeicher gehalten und kann ohne Parsen direkt ausgeführt werden.

XCache ist schnell eingerichtet. Mir fällt kein Grund ein, XCache auf einem Webserver mit PHP nicht zu aktivieren. Auch das oben umschriebene 0815-Setup würde davon profitieren.

SQLite

Ich erspare meinem Server eine MySQL-Instanz, weil ich das für meine Zwecke für völlig überzogen halte. Diese würde etwa 100MB im Betrieb verheizen, die im Varnish, XCache oder Linux-Dateisystemcache wesentlich besser angelegt sind. S9y unterstützt SQLite als Datenbank, schließlich führt es keine Super-Fancy-Abfragen durch. Die Datenbank liegt als Datei im Dateisystem und wird bei Bedarf von PHP angezogen. Ein Performancevergleich zwischen MySQL und SQLite bei der Anwendung S9y würde mich echt interessieren. Wenn ich viel Zeit habe, messe ich das mal.

Serendipity

Auch S9y habe ich modifiziert. Hauptsächtlich habe ich da an den eingebundenen statischen Ressourcen geschraubt. Dies arbeite ich aber in einem anderen Blogbeitrag auf, weil dieser hier wohl bereits etwas länger geworden ist.

Nachtrag

05.06.2013: Varnish mit mehreren Backends

18.12.2013: Varnish-Konfiguration aktualisiert mit Grace-Mode und Saint-Mode, Cacheanheizer immer ein Cache-Miss für gleichmäßiges Anheizen

12.01.2014: nginx-Konfiguration aktualisiert mit Rewrite-Magic für www-Subdomain; Hinweis: Client-IPs kann man in nginx mit dem Modul HttpRealip extrahieren. (Anleitung)

Spiel: Zen Bound 2

Beim Durchstöbern von Steam bin ich vorhin auf Zen Bound 2 gestoßen. Die Einfachheit des Spielkonzepts finde ich klasse.

Umwickle einen Gegenstand mit einem Stück Schnur. Nur wenig Computerspiele basieren auf etwas so einfachem. Besonders für zwischendurch zur Entspannung ist es wunderbar.

Ursprünglich wurde es für Touchgeräte entwickelt, aber mit der Maus klappt es auch ganz gut. Die Musik und Soundeffekte sind ruhig und können einzeln abgeschalten werden. Mit den über einhundert Leveln hat man einiges zutun.

Probiert es einfach mal aus.

Monitoring: Dateigrößen mit Munin überwachen

Die Größen bestimmter Dateien können viel über den Zustand eines Systems aussagen. Ich setze Munin als Monitoringtool meines Servers ein und habe es letztlich um diese Art Überwachungsfunktionalität erweitert.

Munin ist simpel. Es läuft einfach alle fünf Minuten los und sammelt die konfigurierten Messwerte ein. Diese werden als Graphen in Bilddateien gerendert und in ein paar HTML-Seiten geordnet einsortiert. Die Messwerte werden dabei von vielen einzelnen Munin-Plugins besorgt.

Mithilfe der ausführlichen Dokumentation habe ich mir das Plugin du gebaut, welches eine oder mehrere Dateigrößen abfragen kann. Zur Zeit verwende ich es, um die Größe des Webserver-Errorlogs zu überwachen. Schließlich schaue ich da nicht täglich rein.

Besonders nach dem Deployment neuer Softwareversionen kann ich so einfach und schnell prüfen, ob etwas schief gelaufen ist. Das Errorlog wird täglich mittels Logrotate "auf Null gesetzt", wodurch über Tage, Wochen und Monate Tendenzen und Spitzen in den Munin-Graphen schön sichtbar werden.

Ich hoffe, dass Euch diese Idee bei der Überwachung Eurer Maschinen geholfen hat.

Kaffee: Austausch der Schalter beim Kaffeeboy

Als ich letztlich meine Kaffeemaschine instand gesetzt habe, ist mir aufgefallen, dass die Schalter des knapp dreißig Jahre alten Geräts nicht mehr lange durchhalten würden. Gestern haben sie nun vollends versagt.

Durch das Auslösen der Sicherung haben sich die Schalter gestern Abend beim Ausschalten verabschiedet. Mich hat es in der Tat sehr überrascht, als ich in der Küche auf einmal im Dunkeln stand. Das war für mich das Zeichen, dass ich sie ersetzen muss.

Ausgangssituation

Ich brauchte zwei Schalter, die mindestens 250V / 4A schalten können. Die Verkabelung in der Maschine sah auch nicht mehr so gut aus. Besonders nervig fand ich, dass sämtliche Kabel eine schwarze Isolation hatten. Als das Gerät 1985 in Leipzig gebaut wurde, gab es wohl gerade nichts anderes.

Ersatzteileinkauf

Zum Glück gibt es in Stuttgart eine Filiale von Conrad. Mir war von vornherein klar, dass ich nie und nimmer exakt die gleichen Bauteile bekommen würde. Meine Anforderung war lediglich, dass sie von den Dimensionen her so ähnlich sein sollen, dass ich sie durch Bearbeitung des Kaffeemaschinengehäuses passend machen kann. Die integrierten Kontrollleuchten waren für mich zweitrangig, weil ich sie zur Not durch zwei externe hätte ersetzen können.

Letztendlich habe ich mich für einen roten und einen grünen Schalter mit jeweils integrierter Kontrollleuchte und einen Beutel passender Flachsteckhülsen entschieden. Alles zusammen hat rund sechs Euro gekostet.

Was nicht passt...

Mein Plan war es, die neuen Schalter quer zur Schaltrichtung der alten einzubauen. Augenmaß und Nebeneinanderhalten stimmte mich zuversichtlich. Von der Höhe her passten die neuen perfekt. Auch die Schaltervertiefung im Maschinengehäuse passte sehr gut. Nebeneinander hatten beide allerdings noch keinen Platz.

Den Steg, welcher die beiden alten Schalter voreinander separierte, habe ich heraus gebrochen. Beim grünen Schalter habe ich auf der breiten Seite links und rechts sämtliches überstehendes Plastik mit einem scharfen Messer entfernt. Beim roten Schalter habe ich das gleiche nur auf der linken breiten Seite gemacht. Dabei habe ich mir in den Daumen geschnitten. Naja, das war ja abzusehen.

Beim Maschinengehäuse habe ich die linke Schaltervertiefung mit dem Messer vollständig entfernt. Der grüne Schalter wird damit nur noch oben und unten vom Gehäuse gehalten, was völlig ausreicht. Durch das Entfernen des überstehenden Plastiks rutschen beide Schalter sehr nahe zusammen. Nun passen sie knapp aber gut ins Gehäuse. Die Einschnapparretierung beider Schalter hält ausgezeichnet. Von außen betrachtet sehen beide Schalter nun so aus, als wären sie für diese Kaffeemaschine gebaut worden.

Verkabelung

Ein altes Kaltgerätekabel habe ich im Keller gefunden, welches sich sofort freiwillig zur Aderspende gemeldet hat. Mithilfe der Flachsteckhülsen, einem Messer, diverser Zangen und viel Geduld habe ich die Verkabelung schick in blau und braun wiederhergestellt. Das erhöht die so schon gute Wartbarkeit noch mehr. Die Schaltung ist nun richtig schön übersichtlich.

Testlauf

Nach dem Schließen des Gehäuses konnte ich nun den ersten Test durchführen. Wie erwartet funktionierte die Maschine. Die neuen Schalter haben eine sehr schöne Beleuchtung und ich bin gespannt, ob sie wie die alten auch knappe dreißig Jahre halten.

Von nun an kann ich also wieder Kaffee trinken.

Enterprise Architect: PDF-Generierung nicht möglich

Die Einstellungen meiner Installation von Enterprise Architect habe ich letztlich zurückgesetzt. Die Hauptfunktion der PDF-Generierung war danach leider verschwunden.

Es hat mich eine Stunde gekostet, um herauszufinden, wie ich die PDF-Generierung, welche ich normalerweise über die F8-Taste aufrufe, wiederherstellen kann.

Man muss auf der Startseite Interface Customization auswählen und prüfen, dass in den nachfolgenden Dialogen Complete gewählt ist. Offenbar war eine Einstellung drin, welche F8 komplett entschärft hat.

Wenigstens ist nun wieder alles wie früher.

Filme: Regisseur von Pretty Woman

Gerne verfolge ich die Audiokommentare zu Filmen, die mir besonders gefallen, um Hintergründe zur Entstehung von Szenen mitzubekommen.

Besonders hervorheben möchte ich die Einstellung von Garry Marshall bei seiner Arbeit als Regisseur am Film Pretty Woman.

I as a director always choose to have the viewer say "What a bad editor.", "What a bad director." than say "What a bad actress or actor.".

[...]

I want you to see the best of them.

[...]

I believe that you must always pick the best performance. I try everything possible to make the acting honest. If the acting can't be fixed with editing, I take out the dialog and blow music through it. That is the way you protect an actor.

andere in Schutz nehmen; Mut zur Lücke zeigen; Garry hat einen guten Job gemacht.

Webserver: mögliche Schwachstellen in der php.ini

Beim Betrieb von Webapplikationen ist aufgrund der vielfältigen Angriffsvektoren stets Vorsicht geboten. Diesbezüglich ist mir beim Ausloten von Möglichkeiten letztlich das Skript php-reverse-shell über den Weg gelaufen. Das hat mich daran erinnert, dass es unter vielen anderen ein paar besondere Ecken gibt, auf die man beim Setup eines Webservers und der php.ini achten sollte.

Grundsätzlich gilt, dass "gefährliche" PHP-Funktionen wie proc_open mittels disable_functions deaktiviert gehören. Einschalten kann man sie, wenn sie von der jeweiligen Applikation gebraucht werden. Bevor ich alles wiederhole, was andere schlaue Leute bereits geschrieben haben, verweise ich einfach mal auf den Artikel Serverfrieden bei heise Security. Der deckt meines Erachtens einiges ab. Auch die iX hat 2006 im Artikel PHP-Sicherheit: Vorsicht vor popen() und proc_open() vor dieser Art Sicherheitslücken gewarnt.

Bitte prüft Euer Serversetup, bevor jemand ein böses Skript hochlädt und eine Reverse-Shell aufmacht.

Kaffee: Instandsetzung eines AKA K500 - Kaffeeboy

Ich liebe guten Kaffee. Aus diesem Grund habe ich mir zum Geburtstag eine Dampfdruckkaffeemaschine schenken lassen. Es handelt sich dabei um einen in Ostdeutschland wohl bekannten Kaffeeboy. Mein Modell stammt aus dem VEB Elektrogeräte Leipzig, wurde im Jahr 1985 gebaut und ist damit älter als ich.

Dichtungen

Im Kaffee-Zubereitungsbetrieb habe ich feststellen müssen, dass stets geringe Mengen an Wasser an den Kanten der Kesselverkleidung austreten. Da Undichtigkeit kein Feature sein kann, habe ich die Maschine kurzerhand zerlegt und bin fündig geworden. Am Wassereinfüllstutzen und an der Schraube einer Wartungsöffnung oberhalb des Brühelementanschlusses war jeweils die Dichtung komplett defekt. Glücklicherweise hatten meine Eltern noch Ersatzdichtungen vorrätig. Im Bild sind die alten und neuen Dichtungen im Vergleich zu sehen.

Nach dem Dichtungswechsel war es allerdings noch nicht ausgestanden.

Schalter

Bereits beim Zerlegen ist mir der starke Abnutzungszustand der Schiebeschalter aufgefallen. Der rote Schalter ist für den Zubereitungsbetrieb und der weiße für den Warmhaltebetrieb. Als ich sie für den ersten Test mit neuen Dichtungen in Betrieb nehmen wollte, hat der rote Schalter nicht funktioniert. Nach dem Zerlegen habe ich festgestellt, dass die Kontakte im Laufe der Jahre offenbar völlig verdreckt sind. Mit einer Nagelfeile, welche aus der gleichen Zeit wie die Maschine stammt, habe ich die Kontakte sehr gut reinigen können.

Der zweite Testlauf ging erfolgreich über die Bühne. Alles ist dicht, die Schalter funktionieren und der Kaffee schmeckt. Morgen werde ich die Kesselverkleidung wieder installieren.

Fazit

Besonders bei Maschinen, die exzessiv verwendet werden, merkt man das Alter verhältnismäßig schnell. Mein Respekt gilt den Konstrukteuren dieser Kaffeemaschine. Die Eigenschaften Einfachheit, Robustheit und Wartungsfreundlichkeit sind einfach bemerkenswert. Leider gibt es keine Ersatzteile mehr, wodurch diese Maschine bestimmt irgendwann aufgrund eines Verschleißteils wie einem Schalter außer Dienst gestellt werden muss.

codecademy.com: eine Programmierlernplattform

Vor kurzem bin ich durch die Autorin von ryuu auf die Site codecademy.com aufmerksam geworden.

Dort können alle, ohne sich unbedingt anmelden zu müssen, Programmieraufgaben, die von anderen Leuten erstellt wurden, lösen. Zur Zeit werden Kurse für die Sprachen Python, JavaScript und Ruby angeboten. Weiter gibt es Grundlagenkurse für die Webseitenerstellung mit HTML und CSS. Der Fortschritt der Teilaufgaben wird zuverlässig getrackt und es werden virtuelle Trophäen verteilt. Das besondere ist meines Erachtens, dass man die Lösungen zu den Aufgaben direkt im Browser eingeben kann. Dort wird alles sofort kontrolliert und es werden je nach Kurseinstellungen Tipps ausgegeben, wenn es nicht ganz gestimmt hat.

Fazit

Alles in allem finde ich die Idee und den Workflow der Plattform gut. Noch Potenzial sehe ich bei den Leuten, die die Kurse erstellen. Zu jeder Programmieraufgabe fände ich Links zu mehr Hintergrundinformationen sinnvoll. Auf der anderen Seite ist es auch wieder gut, dass diese Infos fehlen, weil man so lernt, selbst danach zu suchen. Das Problem, was ich beim Selbstsuchen sehe, ist, dass Neulinge eventuell durch ungenaue Informationen von schlechten Quellen verwirrt werden und dadurch die Lust verlieren.

idle3-tools: Alterung von WDC-Festplatten verlangsamen

Da ich mein RAID-Array aus Mangel an freiem Speicherplatz erweitern musste, habe ich mir aufgrund der guten Rezensionen die WD20EARX von Western Digital zugelegt. Nach den ersten Betriebsstunden ist mir das ungewöhnlich starke Ansteigen eines Vitalwerts der neuen Platte aufgefallen.

S.M.A.R.T. - Kontrolle ist besser

Moderne Festplatten überwachen sich mittels Self-Monitoring, Analysis and Reporting Technology selbst und melden dem Betriebssystem, wenn das eigene Versagen absehbar ist. Das manuelle Prüfen dieser Werte ist nichtsdestotrotz ratsam. Mir ist es beispielsweise einmal bei einem Rechnerumbau passiert, dass ich den großen Lüfter der Festplatten vergessen habe anzuschließen. Das hätte ich nie bemerkt, wenn ich in der Woche nicht flüchtig in die Plattenüberwachung geschaut hätte. Alle Platten waren mit jeweils ca. 60°C heiß gelaufen und bewegten sich an der oberen Grenze der Herstellerspezifikationen. Wären sie so die nächsten Jahre durchgelaufen, hätte ich mich wohl vorzeitig von ihnen verabschieden können.

WD Green - Desktopfestplatten

Laut Western Digital sind ihre Platten der Serie "Green" besonders umweltfreundlich. Das finde ich grundsätzlich nicht verkehrt. Leider scheinen aber alle diese Platten einen kritischen Konfigurationsfehler zu haben. Standardmäßig parken diese Platten ihre Schreib-/Leseköpfe nach fünf Sekunden Nichtbenutzung außerhalb des Plattenstapels, um Energie zu sparen. Das Feature hat die Firma "IntelliPark" getauft. Das klingt nicht schlecht, ist es aber, wenn man die Herstellerspezifikation gelesen hat. Für lediglich 300.000 Parkvorgänge sind diese Festplatten ausgelegt. Noch schlechter wird es einem, wenn man bedenkt, dass Linuxmaschinen normalerweise nach ca. zehn bis 30 Sekunden die Dateisystemcaches auf die Platten wegschreiben.

Bereits nach 13 Stunden in Betrieb war der Zähler der Parkvorgänge - Load Cycle Count - meiner neuen Platte bereits bei über 400. Meine anderen Platten haben nach mehreren Jahren jeweils nur knappe 2000 dieser Parkvorgänge.

Konfiguration anpassen

Dank Christophe Bothamy dem Entwickler von idle3-tools kann man die Zeit bis zum Parkvorgang bei diesen Green-Platten beliebig einstellen und einer vorzeitigen Alterung entgegenwirken. Die Software ist sogar in den Ubuntu-Repositories, was darauf schließen lässt, dass es ein weit verbreitetes Problem zu sein scheint. Es gibt sogar einen Wikieintrag bei Ubuntuusers.de zu diesem Thema.

MinimalCD: eine kleine Installation mit viel Potenzial

Um eine Linuxdistribution zu installieren, lädt man sich in der Regel ein CD oder DVD-Image aus dem Netz. Danach packt man es auf ein Speichermedium, steckt dieses ins Zielsystem und führt die Installation durch. Bei Images von Linuxdistributionen verhält es sich allerdings genauso wie mit den Rechnern selbst. Wenn man sie einmal hat, sind sie im Prinzip bereits veraltet.

mini.iso

Nahezu jede größere Distribution bietet zu diesem Zweck ein sehr kleines Installationsimage, welches nur die nötigsten Dinge enthält und direkt während der Installation die aktuellsten Pakete, die man auch wirklich braucht, aus den Netz lädt. Damit spart man sich Zeit, Netzwerktraffic und Strom. Bei Ubuntu lautet diese Installationsart MinimalCD.

Hat man diese einmal installiert, besitzt man nach dem ersten Hochfahren lediglich ein Terminal. Nun kann man sich sein System so zusammenstellen, wie man es für richtig hält. Möchte man nun z.B. das Derivat UbuntuStudio installieren, reicht lediglich ein einziger Befehl aus.

sudo apt-get install ubuntustudio-desktop

Probiert es einfach mal aus, wenn Ihr das nächste mal einen Rechner aufsetzt.

andere Distributionen

Debian netinst, OpenSuse Network installation

byobu: Screen mit Extras

Meinen vServer bediene ich ausschließlich über das Terminal via SSH. Das finde ich sehr bequem und es ist vor allem ressourcensparend für den Server selbst. Noch bequemer mache ich mir dabei die Arbeit mithilfe von byobu.

Dieser auf Screen aufbauende Terminalmultiplexer lässt mich mehrere Terminals in einer SSH-Session benutzen. Diese sind recht modern in Tabs eingeteilt und über F-Tasten erfolgt die Bedienung des Multiplexers. Er kann komfortabel konfiguriert werden, damit er z.B. in der untersten Zeile bestimmte Systemparameter anzeigt. Besonders, wenn man mehrere unterschiedliche Systeme bedient, helfen diese Angaben unheimlich, um den Überblick zu bewahren.

Mit einem Druck auf F6 kann ich byobu die Verbindung zwischen Server und meinem System beenden lassen. Sämtliche Terminals laufen auf dem Server in allen Tabs weiter. Das ist auch praktisch, wenn die SSH-Verbindung während eines kritischer Prozesse ungewollt abreißt. So laufen diese weiter und werden nicht abgewürgt. Nach erneutem Verbindungsaufbau startet byobu automatisch und ich kann mit exakt dem gleichen Setup weiterarbeiten. Die Installation des Werkzeugs geht in Ubuntu schnell von der Hand.

sudo apt-get install byobu

Nach dem ersten Start erklärt es sich auch nahezu von selbst. Mit F9 kommt Ihr ins Konfigurationsmenü. Probiert es einfach mal aus.

Blog-Relaunch mit Serendipity

Nach etwa einem Jahr mit einer selbstgebastelten Blogsoftware habe ich mich nun dazu entschlossen, sie durch Serendipity (s9y) zu ersetzen. Dies ist darin begründet, dass ich meine Hauptdesignentscheidung, welche das direkte Ausliefern der Webseiteninhalte ohne PHP-Bremse umfasst, mit meinem jetzigen Wissen geschickter lösen kann. Außerdem war mir der Aufwand einen Blogbeitrag zu erstellen in meinem alten System zu hoch.

Ladezeit

Bei meinem alten System hat ein Cronjob stündlich sämtliche Inhalte in HTML-Dateien gerendert, damit der Webserver nicht erst irgendein Skript anwerfen muss, um die Inhalte zusammenzustellen. In Kombination mit dem gatling-Webserver stand zumindest auf Serverseite einem schnellen Seitenaufbau nichts im Wege. Auch der Ressourcenverbrauch dieses Setups war äußerst gering. Gegen Ende habe ich aber angefangen, dieses Prinzip aufzuweichen. Eine Suchfunktion über sämtliche Microblogeinträge ließ bei jeder Anfrage ein PHP-Skript laufen. Es war egal, ob dabei 100 mal das gleiche gesucht wurde. Immer wurde PHP bemüht, die Informationen zusammenzukratzen.

Varnish

S9y ist ohne PHP nicht lauffähig. Ich setze nun den Webserver nginx ein, da s9y erweiterte URL-Rewrites für den Betrieb benötigt. Der Webserver spricht über FastCGI direkt mit einem ständig laufenden PHP-Prozess um derartige Anfragen rendern lassen zu können. Nginx lauscht lediglich auf einer lokalen Adresse. Vor ihm steht der Cache Varnish, welcher auf Port 80 Anfragen entgegen nimmt, bisher nicht gecachte Inhalte vom nginx bestellt und sie sich dann für eine Stunde merkt. Wenn also nun Fefe aus irgendeinem Grund auf eine meiner Seiten linkt, muss mein Server nicht aufgrund von Überlastung zu Grunde gehen. Varnish hält die Inhalte im Hauptspeicher zum direkten Ausliefern bereit und sämtliche Besucher bekommen die Inhalte schnell ausgeliefert.

Nutzerintraktionen

Dieses Vorgehen bedeutet auch, dass Nutzerinteraktionen, wie z.B. Kommentare, frühestens nach einer Stunde sichtbar sind. Ob sich dieses Setup bewährt, werde ich erst sehen, wenn es ein Stückchen gelaufen ist. In einem nächsten Schritt kann ich einen Cronjob anlegen, welcher nach 55 Minuten den Varnish-Cache leert und sämtliche Seiten bestellt, um den Cache zu erneuern und eine schnelle Auslieferung sicherzustellen. Dies lässt zwar eine konkrete Suchanfrage nach "Bla" trotzdem das PHP arbeiten, allerdings passiert das für gleiche Suchanfragen innerhalb einer Stunde nur einmal.

Ressourcen

Varnish lasse ich bis zu 256 MB für den Cache nutzen. S9y greift auf SQLite zurück, damit ich mir den ressourcenfressenden MySQL-Server spare. Böse Menschen können den Cache locker voll laufen lassen und ihn zum Flattern bringen. Gegen das können meines Erachtens nur Firewallregeln helfen, die ich einrichte, wenn erste Angriffe aufschlagen. Im Bild sind Varnish, Nginx und der PHP-Prozess samt aktuellem Ressourcenverbrauch zu sehen.

Musik: Qualität für alle

Musik heutzutage schnell und bequem kaufen zu können, ist bei amazon und anderen Anbietern gut möglich. Leider ist allerdings die Qualität der Daten meist nicht einmal ansatzweise mit dem vergleichbar, was es auf CDs zu kaufen gibt, bzw. technisch problemlos möglich ist.

Damals

Im Gegensatz zu heute hatten früher viele Leute nur Internetverbindungen mit sehr geringen Datenübertragungsraten. Es war Ende der 90er Jahre normal, lediglich auf etwa 56kbps bei der Internetnutzung zurückgreifen zu können. Die betuchten Leute hatten ISDN und konnten durch Bündelung beider Leitungen bis zu 128kbps rausholen, wenn sie bereit waren die doppelten Verbindungsgebühren zu zahlen. Das war für die Websites dieser Zeit völlig ausreichend. Für größere Datenübertragungen war es trotzdem nicht tauglich, insofern man begrenzt Zeit oder Geld zur Verfügung hatte.

Audiodatenkompression

Alle denken sofort an MP3. Ja, dieses Kompressionsverfahren funktioniert gut, um trotz geringer Übertragungsraten Audiodaten mit Wiedergabelängen im Minutenbereich in endlicher Zeit laden zu können. Die Reduktion der Datenmenge wird dadurch erreicht, indem für das menschliche Gehör fast nicht wahrnehmbare Frequenzbereiche entfernt und schwer unterscheidbare nur ungenau gespeichert werden.

In der Spektrumanalyse eines Titels meiner Musiksammlung aus dem Jahr 2000 ist zu sehen, dass mindestens ein Viertel des hörbaren Frequenzbereichs praktisch entfernt wurde. Wenn ich den Titel anhöre ist die Qualität schlechter als das, was ein gutes analoges FM-Radio bei optimalem Empfang zu leisten vermag. Für MP3-Player von damals mit sehr wenig Speicherplatz war das ok. Es ging durch die Speicherpreise schlichtweg nicht anders.

Heute

Die begrenzenden Faktoren Speicherplatz und Datenübertragungsraten spielen heute keine primäre Rolle mehr. Keine Frage, es ist wichtig für Geräte, die Beschränkungen unterliegen, Fallbacks zur Verfügung zu stellen. Es gibt trotzdem keinen Grund für Musikläden wie amazon, Titel ausschließlich mit verlustbehafteter MP3-Datenkompression anzubieten. Wenn ich ein Musikstück digital kaufe, möchte ich mindestens das haben, was es auf einer CD gibt.

Wenn der Anbieter freundlich ist, weil er möglichst viele Kunden haben möchte, bietet er die Musikstücke in verschiedenen Formaten an, um praktisch jedem Anspruch gerecht werden zu können. So kann sich z.B. jemand, der noch ein 56kbps-Modem nutzt, den gekauften Titel gleich als stark komprimierte MP3 laden und einen Tag lang glücklich hören. Nebenbei kann ja der Download der z.B. mittels FLAC verlustfrei komprimierten Fassung über Nacht laufen, wenn es wichtig genug ist.

Man muss einfach die Freiheit haben, selbst entscheiden zu können. Die Spektrumanalyse zeigt einen Titel, den ich 2012 bei amazon gekauft habe. Für MP3 üblich sind Frequenzbereiche gleich ganz ausgeblendet, was sich bei gutem Audioequipment einfach nur schlecht anhört.

Meine Anforderungen

Ich möchte Musikstücke grundsätzlich als FLAC haben. Dabei sollte in der Datei gleich noch das Albumcover integriert und der Dateiname sinnvoll gewählt sein. Ich kann mir für meine Geräte schließlich selbst die komprimierten Version encodieren, wenn ich möchte. Da alle meine Geräte mit FLAC zurecht kommen, brauche ich das allerdings nicht mal. In der Spektrumanalyse ist ein mit FLAC enkodiertes Musikstück zu sehen. Auffällig ist, dass der Frequenzbereich von 0 bis 22 kHz komplett vorhanden ist. Diesen Unterschied höre ich und der ist mir wichtig. Ihr könnt, wenn Ihr möchtet, gern selbst den Titel Piracy von Botany Bay, den ich der Spektrumanalyse verwendet habe, mit verschiedenen Verfahren komprimiert und als FLAC bei Bandcamp anhören. Den Preis könnt Ihr beim Kauf zumindest momentan selbst festsetzen. Beachtet bitte, dass die FLAC-Version sogar noch besseren Ton liefert als die Audio-CD. Die Daten sind bei gleicher Abtastrate von 44,1kHz mit 24 Bit statt wie bei einer Audio-CD üblich mit 16-Bit-Werten gespeichert.

Für wirklich Audiophile sind Versionen mit höheren Abtastraten bis zu 192kHz erforderlich. So hohe Qualitätsstufen ergeben nur bei Musikstücken Sinn, bei denen die Aufnahmetechnik absolut einwandfrei ist und der Hörer die besten Wiedergabegeräte hat, die es für Geld zu kaufen gibt. Bei solchen Anlagen kosten selbst Kabel hunderte Euro. Mir persönlich reicht 16 Bit / 44,1kHz über meine Kopfhörer von Sennheiser. Ich wollte nur aufzeigen, was es noch gibt.

Studium: Bachelorarbeit

Im April 2011 habe ich meine Bachelorarbeit abgegeben. In diesem Beitrag könnt Ihr sie selbst lesen und ich würde mich freuen, wenn jemand darauf aufsetzt.

Vor etwa einem Jahr habe ich mein Studium durch die Abgabe meiner Bachelorarbeit mit dem Thema "Galerie-Synchronisation" abschließen können. Zurückblickend muss ich sagen, dass meine Schulzeit, zu der ich mein Studium dazuzähle, sehr schön war. Täglich teils sehr weit auseinanderliegende Themenbereiche in unterschiedlichen Veranstaltungen erleben zu können, hat schon was.

Abschluss

Besonders spannend finde ich jedoch die Wochen, in denen ich meine Bachelorarbeit bei miradlo geschrieben habe. Unzählige Flipcharts und viele thematische Diskussionen mit meinen Betreuenden haben die Zeit geprägt. Damit auch andere von meiner Arbeit profitieren können, ohne mich fragen zu müssen, habe ich sie unter die Lizenz CC-BY-SA 3.0 gestellt. Ich finde, dass solche Arbeiten nur etwas bringen, wenn möglichst alle darauf Zugriff haben und sie weiterverwenden dürfen. Ich würde mich sehr freuen, wenn jemand meine Arbeit als Basis für etwas eigenes verwendet. Schreibt mir, wenn Ihr zur Arbeit Fragen haben solltet.

Fazit

Auch nach der Schulzeit geht zumindest für mich das Lernen weiter. Die tägliche Arbeit, Diskussionen mit anderen und die Teilnahme an Barcamps helfen mir dabei am meisten. Für mich funktioniert diese Strategie sehr gut. Falls Ihr bisher noch bei keinem Barcamp wart, solltet Ihr es zumindest einmal ausprobieren.

Linux Mint: Manchmal sind es nur Kleinigkeiten

Im September habe ich geschrieben, dass Lubuntu mein Lieblingsubuntuderivat ist. Dies hat sich zugunsten von Linux Mint geändert.

Seit etwa dem 27.November 2011 bin ich Feuer und Flamme für Linux Mint. Bis zu diesem Zeitpunkt war bei mir Lubuntu im Einsatz, welches mir gute Dienste geleistet hat. Was ich besonders geschätzt habe, waren der sparsame Ressourcenumgang und die Arbeitsgeschwindigkeit. Nicht gefallen hat mir die Instabilität von lxpanel und PCManFM. Der Dateibrowser PCManFM war äußerst schnell, allerdings hat es mich immer geärgert, wenn er beim Verschieben der Desktopicons den Geist aufgab. Ihn hatte ich relativ schnell durch den altbewährten Nautilus ersetzt. Die meisten anderen LXDE-eigenen Anwendungen habe ich im Laufe der Zeit wieder durch ihre Gnomependants ersetzt.

Gnome kam wieder durch

Als ich Linux Mint 12 ausprobierte, welches ein aussehenstechnisch angepasstes Gnome3 einsetzt, ist mir sofort die Fensterleiste aufgefallen. Diese habe ich bei meinen bisherigen Gnome3-Tests immer so stark vermisst, dass ich es nahezu direkt als nichtbenutzbar abstempelte und mich abwandte. Nach genauem Hinsehen stellte ich fest, dass das Gnome3 von den Entwicklern von Linux Mint mit diversen Extensions angepasst wurde, welche sich problemlos im laufenden Betrieb an- und abschalten lassen. Das Menü, welches Ihr auf dem Bild in aufgeklappter Form seht, finde ich nicht so hübsch. Alle Fenster, Anwendungen, Arbeitsflächen usw. sind meines Erachtens gut über den Knopf oben rechts erreichbar. Besonders gelungen finde ich das Iconset, welches ich als einziges nicht verändert habe.

Das Benachrichtigungssystem in der Mitte des unteren Bildrandes finde ich sehr schön unauffällig, da sich die Hauptbedienelemente bei Gnome3 beim Arbeiten oben befinden. Lediglich in der Aktivitätenansicht wird man auf dem ersten Blick mit Knöpfen überhäuft. Links gibts die Favoriten und rechts die Arbeitsflächen. Unten rechts gibts noch nicht bearbeitete Nachrichten und z.B. Wechseldatenträger. In der Mitte sind Anwendungen verschieden kategorisiert zu finden.

Anpassungen

Diese Extensions sind recht schnell mit JavaScript und CSS erstellbar und können auf einer Gnome-Plattform veröffentlicht und direkt durch einen Klick im Browser installiert werden. Diese ganze Funktionalität arbeitet für ihren Alphastatus schon beeindruckend gut. Vorsicht ist bei dieser Ecke stets geboten, da diese Extensions so weit ich weiß Vollrechte haben. Ein Keylogger lässt sich da sicherlich perfekt verstecken. Das API ist umfangreich und man kann alle Ecken prima erreichen. Auch ich habe mich gestern mal an einer Extension versucht und so schwierig fand ich es nicht.

Den Theme von Linux Mint finde ich zwar gelungen, aber mir hat schon immer der originale Gnome3-Look mit dem blauen Hintergrund gefallen. Ich finde das sehr beruhigend und die Infos der schwarzen oberen Leiste sind wegen des stärkeren Kontrasts besser lesbar.

Möglichkeiten

Die Systemeinstellungen sind wunderbar zusammengefasst und äußerst übersichtlich. Die Backupanwendung Deja-Dup, welche in jedem Ubuntu nachinstalliert werden kann, bietet eine komfortable Möglichkeit, automatisiert Backups des Systems anzufertigen. Wenn Ihr diesbezüglich ein schlechtes Gewissen habt, solltet Ihr das mal ausprobieren.

Standardmäßig ist bei Linux Mint 12 Gnome-Zeitgeist aktiviert, welche sämtliche Nutzeraktivitäten loggt und bei Bedarf einsehbar macht. Rein prinzipiell kann man nachschauen, was man letzten Mittwoch um 15:30 Uhr für einen Musiktitel gehört hat. Es ist praktisch ein kleiner Überwachungsstaat auf dem eigenen Rechner. Ich habe diese Funktion deaktiviert, da ich meine Dateien, Musiktitel usw. nicht so sehr überwachen möchte. Wenn man schließlich seine Dateien gut behandelt, behandeln sie einen auch gut. Für andere Leute mag das sicherlich sinnvoll sein. Bemerkenswert finde ich die extrem einfache Deinstallation der Überwachung. Einfach die Zeitgeistpakete entfernen und fertig. Keine Anwendung ist mir unter die Augen gekommen, welche diesen Dienst zum Funktionieren braucht. Ich bin offenbar von KDE geschädigt worden, weil dort zumindest in der Version 4.7 ohne Akonadi und Nepomuk nichts wirklich funktioniert.

Debian Edition

Von Linux Mint gibt es auch eine Debian Edition. Diese basiert auf dem Testing-Zweig von Debian und nicht auf Ubuntu. Dies wird als Rolling Release betrieben, was bedeutet, das man durch die Updates stets ein aktuelles System hat und keine Upgrades durchführen braucht. Auch dieses habe ich einmal auf meinem Testlaptop installiert. Alleine der Punkt, dass es den S3-Standby nicht Out of the box hinbekommen hat, fand ich erschreckend. Das Laptop habe ich mir zu meinem Studiumsbeginn gekauft und es ist meines Erachtens schon so sehr in die Jahre gekommen, dass ich das einfach erwarten kann. Das von Linux Mint eingesetzte Gnome-Panel für Fensterleiste, Anwendungsmenü, Benachrichtigungsfeld usw. hatte öfters Darstellungsfehler.

Fazit

Als ich Lubuntu einsetzte war ich der Meinung, dass Arbeitsflächeneffekte überflüssig seien. Die bei Gnome3 eingesetzten finde ich nach ein bisschen Eingewöhnung nun richtig klasse. Tja, wenn man sich wirklich an etwas gewöhnen möchte und im Kopf nicht "die Rolladen runterlässt", kommt man mit fast allem zurecht.

Linux und Ich: Weihnachtsverlosung

Christoph Langner führt in seinem Blog eine Weihnachtsverlosung durch und jeder darf mitmachen.

Die große Weihnachtsverlosung von Christoph Langner in seinem Blog Linux und Ich ist eine tolle Sache. Jeder darf mitmachen und als Hauptpreis gibt es einen kleinen Rechner zu gewinnen.

Genau genommen ist diese Gelegenheit für mich perfekt. Vor einiger Zeit konnte ich nämlich auf meiner PS3 noch offiziell Linux ausführen. Diese Funktionalität wurde sogar beim Kauf von Sony beworben und es war einer meiner Kaufgründe. Einen Cell-Prozessor gibt es schließlich sonst nur in Großrechnern von IBM. Sowas daheim zu haben und den eigenen Code darauf auszuführen hatte was. Ubuntu lief recht gut und ich konnte mittels mplayer jedes vorstellbare Videoformat in hoher Qualität wiedergeben.

Leider aber hat Sony die Linuxunterstützung mittels eines Firmwareupdates ausgebaut. Seitdem ist diese schwarze Kiste unter meinem großen Monitor nur noch zum Abspielen von BluRays und gelegentlich einer Zockerrunde da. Der eigentliche Reiz, dieses Gerät zu verwenden, ist weg. Mit dem Hauptpreis hätte ich einen guten Grund, diese Kiste ihres Amtes zu entheben.

Mach doch auch mit bei dieser Verlosung.

Piratenpartei: Bundesparteitag 2011.2

Wer meine Kurzmeldungen verfolgt hat, weiß, dass ich am Bundesparteitag 2011.2 der Piratenpartei teilnehme. In diesem Beitrag werde ich nach und nach ein paar Impressionen veröffentlichen.

Das sind ein paar Bilder, die ich während meines Aufenthaltes beim Bundesparteitag (BPT112) aufgenommen habe.

Vor der Stadthalle steht das Piratenschiff "Orange Pearl". Die Halle ist dadurch von weiten nicht zu übersehen.

Kurz vor 10:00 Uhr sind schon sehr viele Piraten vorm Eingang der Stadthalle und warten auf die Eröffnung der Akkreditierung.

Die Akkreditierung läuft und es geht langsam in Richtung Eingang.

Der mäßige Fluglärm ist hier in Offenbach nicht zu überhören, wenn man unter freiem Himmel steht.

Kurz vor dem Eingang nach hinten blickend ist zu sehen, dass weiterhin stetig Piraten an der Halle ankommen.

In der Halle kurz vor der Eröffnung. Alle bauen ihre Rechner samt Netzwerktechnik auf und testen die Internetverbindung. Zumindest ich habe von Beginn an Netz.

Eine kleine Showeinlage mit Nebelwerfern zu Beginn.

Während der Eröffnungsrede von unserem Bundesvorsitzenden Sebastian Nerz ist die Halle schon sehr gut gefüllt. Sebastian legt uns nahe, uns nicht gegenseitig zu bekämpfen. Jeder, der weiß, was in letzter Zeit auf den Mailinglisten bzw. anderen Kommunikationsmedien los war, kann ihm nur zustimmen.

ein leichter Linksschwenk mit der Kamera

Während der Abstimmung der Geschäfts- / Tagesordnung konnten wir unsere Ja/Nein-Karten schon mal Warm machen.

Auch Oliver Welke von der heute-show ist da und interviewt ein Mitglied.

Besonders die politische Geschäftsführerin Maria Weisband und der Bundesvorsitzende Sebastian Nerz durften heute unzählige Interviews der Presse geben.

Während der Diskussion von Anträgen sind stets Nummer und Titel der aktuell abzustimmenden Anträge auf der Großleinwand. Weiter war oben rechts die verbleibende Zeit für den aktuellen Redner eingeblendet. Redezeitbegrenzungen zwischen 60 und 90 Sekunden haben endlose Monologe wirkungsvoll reduziert.

Abends in der Stadt

Gegen Ende des ersten Tages sind wir mit Shuttlebussen wieder zu den umliegenden Hotels gebracht worden. Meins lag zwar nicht auf deren Route, aber was solls. Es war eine schöne Fahrt durch Offenbach und zum inneren Rand von Frankfurt am Main. Imposante Gebäude waren in jeder Himmelsrichtung zu sehen. Meist waren sie an ihrem oberen Ende mit beleuchteten Logos von Banken versehen. Nachdem ich im Bus ein paar interessante Gespräche über so manche verrückt anmutende Themen hatte, hielt der Bus an seiner Endstation.

Die Jugendherberge Frankfurt liegt im Stadtteil Sachsenhausen und war ca. 10km von meinem Hotel entfernt. Mit dem GPS-Handy, Piratenflagge und Rucksack bewaffnet war mein Hauptziel eine große Mainbrücke. Die Deutschherrnbrücke war meines Erachtens mit den hellsten Scheinwerfern ausgestattet. Sie musste wohl besonders cool sein. Auf ihr stehend war es echt atemberaubend. Der Main fließt unter einem entlang, es ist ruhig und in der Ferne spürt man das Zentrum der Großstadt vibrieren. Weiter erzeugt die Stadt einen erheblichen Lichtkegel in den Nachthimmel.

Nachdem ich auf dem Marktplatz keinen Bus in Richtung meines Hotels in der nächsten Zeit zu erwarten hatte, nahm ich einfach ein Taxi. Dem Taxifahrer war unser Event wohlbekannt. Er wünscht uns weiterhin viel Erfolg.

Der zweite Tag

Kurz vor 9 Uhr hat es geregnet. Dem entsprechend dicht gedrängt stehen wir unter dem überdachten Eingang der Stadthalle. Glücklicherweise können wir heute schneller in die Halle, da die meisten bereits akkreditiert sind und ein Vorzeigen des Armbandes ausreichte.

Die Tische sind wie gewohnt mit Laptops und Netzwerktechnik gespickt. Selbstmitgebrachte Switches und Mehrfachsteckdosen sind äußerst hilfreich und sollten in keinem Parteitagsgepäck fehlen.

Beim Verlassen des Saals muss man aufpassen, dass man nicht versehentlich durch ein laufendes Interview läuft.

Ich fand diesen Parteitag äußerst gut organisiert und möchte mich an dieser Stelle nochmals für das unermüdliche Engagement aller Beteiligten bedanken. Nur die Arbeit dieser vielen Helfenden hat es ermöglicht, dass wir unser Programm wieder ein gutes Stück erweitern konnten. Die Anzahl der Piraten in einem Saal wird jedoch meines Erachtens bei anhaltendem Wachstum ein Problem werden. Die bereits bekannte Idee eines über das Bundesgebiet verteilten Parteitages mit Liveübertragungen wird wohl auf kurz oder lang in irgendeiner Form kommen.

Hoffentlich hat Euch dieser Beitrag einen kleinen Einblick ermöglicht.

24C3: Tracker fahrn

Im Blogbeitrag BCS4: Ressourcensparen bei Websites - Ladezeit habe ich opentracker bereits als spezialisierten Webserver vorgestellt. In den Aufzeichnungen vom 24. Chaos Communication Congress habe ich einen Talk zu diesem Projekt gefunden.

Ich habe die folgende Aufzeichnung des Talks 24C3_2355 "Tracker fahrn - We Track Harder - We Track More! Take the pain out of running a Bittorrent-Tracker!" vom 27.12.2007 hier verlinkt. Die Entwickler Erdgeist, Denis und Cristian erläutern anschaulich und in einer erfrischenden Art und Weise, welche Erfahrungen sie bei diesem Softwareprojekt sammeln konnten.

Das Video stammt vom Chaos Computer Club und steht unter der Lizenz CC-BY-NC-ND-2.0. Viel Spaß beim Anschauen.

Nachtrag

24.03.2018 - Die habe die Iframe-Einbindung aus datenschutzgründen durch einen Hyperlink ersetzt.

gatling: Bauen und Installieren

Auch wenn das Medium Internet bei manchen Personen noch nicht angekommen ist, wird es bereits von sehr vielen Menschen zur Informationsbeschaffung, Kommunikation und spätestens seit facebook auch zur exzessiven Selbstdarstellung verwendet. In diesem Blogbeitrag erkläre ich kurz die ersten Schritte mit dem bei meiner Site eingesetzten Webserver gatling.

Webserver sind aus dem heutigen Internet nicht mehr wegzudenken, da für die meisten Menschen das Internet nur im Webbrowser existiert. Ich habe mich beim Aufsetzen meiner Site für gatling entschieden, da mich die Ladegeschwindigkeit von Fefes Blog einfach fasziniert. Fefe ist der Entwickler von gatling und ich finde seine Meinung zu langsamer Software klasse. Rechner von vor 10 Jahren waren gefühlsmäßig genauso schnell, wie die von heute, obwohl die heutige Hardware erheblich leistungsfähiger ist. gut, zurück zum Thema;

Installationsablauf

Als erstes muss sichergestellt werden, dass die für das Bauen erforderliche Software installiert ist. Unter einer zu diesem Zeitpunkt aktuellen Ubuntuinstallation 11.10 geht das mit folgendem Befehl. Er installiert sämtliche notwendigen Pakete, insofern sie noch nicht installiert sind.

sudo apt-get install cvs build-essential zlib1g-dev libssl-dev

Da gatling von den zwei, ebenfalls von Fefe entwickelten, Libs dietlibc und libowfat abhängt, müssen wir diese im folgenden mit installieren. Die Abhängigkeiten lassen sich mit der Abarbeitungsreihenfolge dietlibc, libowfat, gatling auflösen. Das folgende kleine Skript beachtet diese Reihenfolge. Es holt die Quellcodes aus Fefes CVS, übersetzt sie und installiert nach /opt/diet. Zumindest zum Zeitpunkt der Erstellung dieses Blogbeitrags, wurden bei diesem Vorgang einige Warnings ausgegeben. Bitte beachtet, dass das Skript auch auf schnellen Rechnern ca. eine Minute benötigt.

#!/bin/bash
cd ~
for i in dietlibc libowfat gatling
do
    cvs -d :pserver:cvs@cvs.fefe.de:/cvs -z9 co $i
    cd $i
    make > /dev/null
    sudo make install
    cd ..
done

Einrichtung

Abschließend müssen wir noch den Programmpfad /opt/diet/bin bekanntmachen, um den soeben installierten gatling komfortabel nutzen zu können. Hierzu fügen wir in die Datei /etc/environment das Verzeichnis /opt/diet/bin hinzu und laden diese Einstellungen.

#!/bin/bash
k=$(grep /opt/diet/bin /etc/environment)
if [ $? -eq 0 ]
then
    echo "/opt/diet/bin bereits im PATH"
else
    sudo sed -i 's/\(PATH="[^"]*\)"$/\1:\/opt\/diet\/bin"/' /etc/environment
fi

source /etc/environment

Nun dürfte gatling korrekt installiert sein.

Erste Schritte

Als erstes sollte probiert werden, ob die Manpage aufrufbar ist.

man gatling

Dort findet ihr erste Bedienungshinweise. Weitere sind im vorhin ausgecheckten gatling-Quellcodeverzeichnis in den README*-Dateien zu finden. Außerdem gibt es noch die gatling-Mailingliste, auf der Fefe mitliest.

Prinzipiell reicht es aus, in einem Verzeichnis, in welchem dem aktuellen Nutzer Leserechte eingeräumt sind, gatling ohne Parameter aufzurufen, um die Verzeichnisinhalte per HTTP und FTP zugreifbar zu machen. Die Log wird von gatling direkt auf die Standardausgabe geschrieben.

heidi@anna:~/gnuheidix.de$ gatling
warning: could not bind to SMB port; SMB will be unavailable.
starting_up 0 :: 8000
start_ftp 0 :: 2121
accept 7 127.0.0.1 35101 1 http
GET 7 / 282 Mozilla/5.0_(X11;_Linux_x86_64;_rv:7.0.1)_Gecko/20100101_Firefox/7.0.1 [no_referrer] localhost:8000
request_done 7 325 426

Abschließendes

Zu gatling gibt es noch ein paar eindrucksvolle Benchmarks. Seid vorgewarnt, wenn ihr ApacheBench einsetzt. Es kann passieren, dass dieses Benchmarktool mehr Ressourcen als gatling verheizt. Letztendlich kann es den Prozessor zu 100% auslasten, wohingegen gatling zwischen 0 und 1% bleibt. Beim Quellcode von gatling sind auch ein paar Benchmarkskripte dabei, mit denen Ihr selbst ein paar Tests fahren könnt, oder ich lest Euch gatling vs. nginx durch. Ich wünsch Euch viel Spaß beim Experimentieren.

Barcamp Stuttgart 4: Ressourcensparen bei Websites - Ladezeit

Jeder kennt das Problem einer sich gemütlich aufbauenden Website. Die Ursachen für dieses Verhalten können vielfältig sein. Zum einen kann die Verbindung zum Webserver teilweise gestört sein und zum anderen können auf der Server- und/oder Clientseite "teure" Prozesse im Gange sein, welche die Inhaltsdarstellung verzögern.

Am zweiten Tag vom Barcamp Stuttgart 4 habe ich mich dazu entschlossen, eine Session zum Thema Ressourcenverbrauch und deren Auswirkungen auf die Ladezeit von Websites zu halten. Der Phrase "Besser spät als nie" folgend, ist hier nun endlich meine Zusammenfassung dieser Session.

Ablauf eines Webseitenabrufs

Der Abruf einer Webseite von einem Webserver erfolgt in einer Vielzahl von Einzelschritten auf Client- und Serverseite. Stark vereinfacht betrachtet geschieht dieser Vorgang in drei Schritten.

Anfrage

Ungefragt liefert kein Webserver etwas aus, da laut HTTP stets der Client die Initiative beim Abruf ergreifen muss. Weiter ist der Client dem Webserver nur während der Anfragenbearbeitung bekannt. Ist eine Anfrage einmal beantwortet, muss der Client bei einer Folgeanfrage unter Umständen gewisse Zustandsinformationen mitliefern, um identifiziert und korrekt behandelt werden zu können. Beispielsweise wird nach einem Loginvorgang an einer Webapplikation vom Client ein Cookie bei jeder Folgeanfrage mitgeliefert, um jede einzelne Benutzersitzung von der Applikation verfolgbar zu machen.

Antwort

Der Webserver nimmt die Anfrage entgegen, berechnet die Antwort und liefert sie zurück an den Client. Dabei können je nach Webserver und evtl. vorliegender Webapplikation mehrere Bearbeitungsschritte zur Beantwortung der Anfrage erforderlich sein. Hier sind ein paar Varianten, wie sowas aussehen kann.

Spezialisierung

Ein Webserver, welcher sämtliche auslieferbaren Inhalte bereits im Hauptspeicher vorhält und direkt versenden kann. Bei steigender Komplexität der Inhalte, steigt der Haupspeicherverbrauch ebenfalls an. Dieser Ansatz wird meist nur bei spezialisierten Webservern eingesetzt, welche auf einige wenige Anwendungsfälle optimiert wurden. Als bestes Beispiel sehe ich dabei opentracker.

Dateiauslieferung

Ein Webserver, welcher Inhalte von Dateien aus einem relativ zügig zugreifbaren Dateisystem direkt ausliefert. Der Hauptspeicherverbrauch für den Webserver selbst kann dabei minimal ausfallen. Bei jeder Anfrage eines Clients, bestellt sich der Webserver vom Betriebssystem, in dem es läuft, die jeweilig angefragte Datei und liefert deren Inhalte aus. Nicht jeder Zugriff auf das Dateisystem muss dabei zwangsläufig in einem Festplattenzugriff münden. Geschickte Betriebssysteme sind in der Lage, die Dateizugriffe zu cachen. Finden lediglich lesende Zugriffe statt, ist der Cache nach dem Start des Webserver und einigen Clientanfragen warmgelaufen und lässt den Webserver fast so geschwind reagieren, wie die spezialisierte Variante mit reiner Hauptspeicherdatenhaltung. Die Größe des Caches hängt von der Größe des verfügbaren Hauptspeichers und der Konfiguration des Betriebssystems ab. Meine Website wird beispielsweise exakt nach diesem Prinzip von gatling ausgeliefert.

Rendern

Besonders bei äußerst dynamischen Inhalten wird meist auf einen Webserver zurückgegriffen, welcher nach dem Empfang einer Anfrage beginnt, die Antwort erst zusammenzustellen und sie danach auszuliefern. In der Regel erfolgt dieser Zusammenstellungsprozess über ein Programm, welches verschiedene Inhaltselemente von einem Datenbankserver bezieht. Der Vorteil bei diesem Ansatz ist das geordnete Ablegen der Inhalte und derer Beziehungen zueinander in der Datenbank. Der Nachteil ist die Programmausführungszeit, welche mit steigender Komplexität der Inhalte ebenfalls ansteigen kann.

Darstellung

Der Client empfängt die Antwort, stellt die Webseiteninhalte dar und lädt bei Bedarf weitere ihm fehlende eingebundene Inhalte mittels weiterer Abfragen nach. Je nach Art des Clients ist dies sehr unterschiedlich. Programme wie wget oder httrack speichern die empfangenen Daten im Dateisystem. Browser stellen die Inhalte hingegen direkt auf dem Bildschirm dar.

Zeit sparen und Ressourcen kürzen

In allen drei Schritten wird Zeit für die Durchführung der Abfrage verbraucht. Besonders wenn Webseiten mit einem Browser abgerufen werden, ist die benötigte Zeit erheblich, da in der Regel ein Benutzer aktiv darauf wartet. Ein gewisser Teil an Ressourcen wird bei jeder einzelnen Abfrage verbraucht, da HTTP ziemlich gesprächig ist und obenrein noch auf dem relativ schwerlastigen TCP aufbaut. Dieser Verbrauch lässt sich nicht vermeiden. Je weniger jedoch für eine Abfrage neu berechnet werden muss, desto mehr Ressourcen werden eingespart.

Vorberechnung von Inhalten

Besonders bei lesendem Zugriff auf Inhalte, die nicht zwangsweise hochaktuell sein müssen, bietet es sich an, bereits vorgerenderte Inhalte auszuliefern. Beispielsweise reicht es bei den meisten Statistikausgaben aus, diese höchstens alle n Zeiteinheiten neuzuerstellen. Ein weiteres Beispiel ist die Einbindung externer Inhalte. Während der Benutzer auf die Abfrage wartet, ist es unvorteilhaft, erst einen externen Rechner einer anderen (administrativen, lokalen, …) Domäne nach Inhalten zu befragen. So kann z.B. die Einbindung von Mikrobloginhalten sonst zu erheblichen Wartezeiten führen, wenn dieser externe Dienst einmal nur langsam oder garnicht erreichbar ist.

Arbeit verteilen

Aus performancetechnischer Sicht ist es nicht zweckmäßig, Webserver mit etwas anderem als dem direkten Ausliefern von Inhalten zu beauftragen. Dies merkt man besonders, wenn während hunderten Benutzeranfragen jeweils, x-tausend Datensätze verarbeitet werden müssen. Besser ist es, diese Arbeit an andere Programme oder Rechner zu verteilen, die darauf spezialisiert sind, diese Verarbeitung durchzuführen. Verteilung selbstzubauen ist nicht trivial, da es dabei eine sehr große Menge Fehlerfälle gibt, die gefangen gehören. Man kann aber die Verteilung auch mit einem Framework wie Gearman lösen. Der Vorteil dabei ist, dass man die eigene Anwendungslogik von der Gearman-Verteilungslogik klar trennen kann. Geschenkt erhält man dabei unter anderem Skalierbarkeit und Fehlertoleranz. Man kann also einfach bei Bedarf "Lastesel" hinzufügen oder entfernen, um mehr Rechenkapazität für den verteilten Code zu erhalten. Weiter fällt es kaum ins Gewicht, wenn einmal einer der "Lastesel" stirbt, da ja noch genügend andere seine Arbeit übernehmen können. Der Nachteil ist der erhöhte Verwaltungsaufwand der "Lastesel".

Eine weitere Möglichkeit ist die Verteilung von unterschiedlichen Inhalten auf physikalisch getrennte Rechner. Beispielsweise könnte man einen oder mehrere Bilder-, Javascript-, Videoserver betreiben. Deren Integration kann dann im eigentlichen HTML erfolgen. Das bedeutet, dass z.B. drei Bilderserver per Round Robin-DNS die gleiche Arbeit verrichten und über bilder.DOMAIN.TLD angesprochen werden. Fällt einen von denen aus, ist es nicht schlimm. Fallen alle aus, sieht die Applikation etwas spartanischer aus, aber sie läuft weiter. Der HTML-Webserver kann sich so entspannt dem Ausliefern von reinen HTML-Inhalten widmen.

Lastabhängig arbeiten

Es ist zwar schön, wenn man eine funktionsträchtige, bunte, … Webapplikation gebaut hat, aber zu Spitzenlastzeiten, kann jedes noch so effiziente System einmal gemütlich werden. Ein Ansatz ist es, von Anfang an verschiedene "Featurestufen" in der Applikation zu realisieren. Die Last sämtlicher kritischer Systeme wird permanent überwacht und bei einem Engpass wird automatisch eine Featurestufe heruntergeschaltet, um die Last zu reduzieren und notwendige Ressourcen freizugeben. Mögliche Featurestufen sehen z.B. wie folgt aus.

HTML ohne weitere externe evtl. nachzuladende Einbindungen und ReadOnly-Zugriff (minimale Features)
HTML und CSS ohne Bilder und ReadOnly-Zugriff
HTML, CSS, Bilder
HTML, CSS, JavaScript, Bilder
HTML, CSS, JavaScript, Bilder, Videos, … (maximale Features)

Klar ist, dass je tiefer die Featurestufe ist, desto potentiell unschöner fühlt sich alles an. Fakt ist jedoch, dass die Verfügbarkeit über einen verhältnismäßig breiten Lastbereich hinweg gewährleistet ist.

Cachingstufen

Besonders bei zahlreichen ReadOnly-Zugriffen, kann man Cachinghierarchien einführen. Stark belastete Teilsysteme wie Webserver und Datenbanken können so vor der Beantwortung von Lesezugriffen geschützt werden und sich komplexeren Aufgaben wie schreibenden oder zustandsabhängigen Zugriffen widmen. So können Proxies wie Squid vor potentiell langsame Webserver geschalten werden. Das perfekte Beispiel ist für mich der Webserver eines Wikis, welcher sich nur noch kaum um profane Seitenaufrufe kümmern muss, wenn eine solche Cachingstrategie gefahren wird. Der Nachteil bei diesem Ansatz kann die verzögerte Auslieferung von neuen Inhalten sein. Dies tritt immer dann auf, wenn der Proxy die Änderung eines Datensegements nicht mitbekommen hat und so lange "alte" Daten ausliefert, bis das Maximalalter des jeweiligen Datensegments erreicht und ein Neuladen erzwungen wurde.

Abfragen sparen und Inhalte komprimieren

Wenn man eine HTML-Seite z.B. so aufbaut, dass zehn verschiedene CSS-, fünf JavaScript-Dateien, ein Favicon und 25 Bilder vom Client potentiell nachgeladen werden müssen, so wird der Seitenaufbau unweigerlich gemütlich werden. Fakt ist, dass jede Abfrage einen gewissen Overhead mit sich bringt, der in großer Menge erheblich sein kann.

Eine Verringerung erreicht man, indem Inhalte zusammengefasst werden. CSS und JavaScript kann man theoretisch in jeweils eine große Datei packen, welche in jeweils einer Abfrage übertragen werden kann.

Auch Bilder lassen sich z.B. mit CSS-Sprites zusammenfassen. Ein Favicon kann man wunderbar Base64-kodiert ins HTML verfrachten, da die meist nur wenigen Bytes eines solchen Minibildes nach der Komprimierung den unkomprimierten HTML-Header unverhältnismäßig aussehen lassen. Auch diese Technik setze auf allen Seiten dieser Site ein.

Sicherstellen sollte man, dass für sämtliche textbasierten Inhalte die gzip-Komprimierung des Webservers aktiviert ist. Die meisten Clients unterstützen diese Betriebsart und es wäre eine Verschwendung an teurem Trafficvolumen und Bandbreite, dies nicht einzusetzen.

Fazit

In jeder Website und Webapplikation steckt ein gewisses Optimierungspotential und bei Bedarf kann man mit wenigen Handgriffen schon viel erreichen, um den Nutzern und den eigenen Systemen das Leben angenehmer zu machen. Welche Strategien man anwendet, ist sehr stark situationsabhängig und deren wohlüberlegte Wahl ist entscheidend. Ich hoffe, dass ich keine wichtigen Aspekte der Session vergessen habe und bedanke mich nochmal bei den Teilnehmern für die konstruktive Stunde in diesem Themenbereich.

Anmerkung

In diesem Blogbeitrag habe ich Systemressourcen der Wichtigkeit geordnet nach Netzwerk, Prozessor, Hauptspeicher und Massenspeicher betrachtet. Ob dies für jeden anderen Fall angemessen ist, muss individuell entschieden werden.

Barcamp Stuttgart 4: Android Malware

Malware begegnet uns seit ein paar Jahren an jeder Ecke im Internet. Vollmundig werden auf vielen Websites gar so tolle Softwareapplikationen beworben, welche diese oder jene Funktionen dreimal besser erfüllen, als altes im Einsatz befindliches. Erst einmal installiert verbirgt diese Software ihre, dem Nutzer meist verborgene, Schattenseiten.

Am ersten Oktober habe ich an vielen äußerst informativen Sessions beim Barcamp Stuttgart 4 teilgenommen. Falls jemand nicht weiß, was ein Barcamp ist, gibt es einen kurzen und guten Wikipediaartikel. Auf Anfrage von @pawelf erkläre ich nun ein wenig, was ich aus der Session "Android Malware", welche von Denis gehalten wurde, mitgenommen habe. Ich muss übrigens klarstellen, dass ich weder ein Android noch ein ichPhone besitze und somit absolut nicht aus Erfahrungen spreche. Bitte verzeiht sämtliche eingebaute Ungenauigkeiten.

Situation

Zumindest auf heutigen Mobilgeräten gibt es die meiste Malware für die Android-Plattform. Auch wenn diese vorgebrachte Untersuchung von einem Antiviren-Softwarehersteller stammt, welcher sein Geld mit in Umlauf befindlicher Schadsoftware verdient, kann da etwas wahres dran sein. Im Gegensatz zur Softwarevertriebsplattform für ichPhones, wo grundsätzlich und ausschließlich der Hersteller bestimmt, was Nutzer angeboten bekommen und somit installieren dürfen, gibt es beim Einstellen von Applikationen für Androidgeräte weniger Hürden. Zum einen ist der zu bezahlende Geldbetrag pro eingestellter Applikation niedriger und zum anderen wird nicht sämtliche Software vor der Freigabe in großem Umfang geprüft. Kurz gesagt, bekommt man relativ problemlos beliebige Software in die Androidsoftwareangebots- und -verteilungsinfrastruktur.

Konkret Böse

Beispielsweise ist ein Stück Software, welche sich dafür ausgibt, von einer seriösen und bekannten Firma zu stammen, dies aber in der Tat nicht ist, gefährlich. Normale Menschen merken es einfach nicht, wenn z.B. der für viele bekannte Opera-Browser auf einmal als Opara-Browser bezeichnet wird. Hoffend, einen guten schnellen und vertrauenswürdigen Browser zu installieren, haben sie auf einmal einen Browser, der sämtliche Passwörter und sonstige privaten Angelegenheiten an den "bösen Malwareentwickler" schickt, welcher diese dann potentiell Missbrauchen kann.

Gegenmaßnahmen

Android weist einen Nutzer bei der Installation einer Anwendung auf Gerätefunktionen hin, welche sich von der Anwendung im Zugriff befinden werden. Diese muss der Softwareentwickler in einer bestimmten Datei zur Entwicklungszeit in seiner Anwendung deklarieren. Wenn er dies nicht vollständig macht, gehen die in dieser Datei nicht bekanntgemachten Aufrufe ins leere.

Problem

Nutzer ignorieren solche sicherheitsrelevanten Informationen meistens, um schnellstmöglich die von ihnen erhoffte Funktionalität bereitgestellt zu haben. Dies mündet auch darin, dass Aufforderungen, einen bestimmten kritischen Vorgang gesondert zu autorisieren, praktisch im Unterbewusstsein übersprungen werden. Meist mangelt es den Nutzer auch einfach an ausreichendem Fachwissen, um entscheiden zu können, ob es gut ist, einer Anwendung, die nur Verdauungsgeräusche von sich gibt, Netzzugang zu erlauben.

Lösung

Als Lösung wurde in der Session demonstriert, wie einfach man als geübter Nutzer eine beliebige Androidapplikation entpackt, decompiliert und kritische API-Aufrufe, wie das Versenden von SMS identifiziert. Dieser Ansatz mag für eine sehr kleine Nutzerschicht funktionieren, aber der "Fußgänger" kommt damit nicht zurecht. Fakt ist, dass Quellcode beliebig kryptisch geschrieben sein kann und eigentliche ablaufende Prozesse so sehr verschleiert werden, dass es in endlicher Zeit nicht möglich ist, zu bestimmen, ob ein Stück Software "gut" oder "böse" ist.

Ein Vorschlag war es, einfach Reviews durchzuführen und einen Expertenmodus für die Verteilungsplattform, welcher standardmäßig bei der Geräteauslieferung deaktiviert ist, einzuführen. Ist dieser deaktiviert, werden nur von möglichst verschiedenen Stellen positiv gereviewte Softwareapplikationen zur Installation angeboten.

Auf eine einfache und allumfassende Lösung sind auch wir in der Session nicht gekommen. Alles in allem habe ich einen sehr guten Einblick bekommen, was zur Zeit in diesem Bereich alles für Gefahren und suboptimal gelöste Probleme existieren.

Ich bedanke mich nochmals für die tolle Session und hoffe, dass ich die Inhalte und Resultate nicht allzu oberflächlich wiedergegeben habe.

Update: Slides der Session

Passwörter: Länge ist nicht alles (2)

Ein Brute-Force-Angriff - ein Durchprobieren sämtlicher Kombinationen - kann sich ziemlich in die Länge ziehen und sich ab einer bestimmten Passwortkomplexität nicht mehr rentieren. Dies habe ich im letzten Blogbeitrag gezeigt. In diesem erkläre ich, in welcher Form Passwörter in Computersystemen heutzutage gespeichert werden und demonstriere kurz, was ein Brute-Force-Angriff auf dem Prozessor einer Grafikkarte leisten kann.

Früher wurden Passwörter so abgespeichert, wie sie der Nutzer in das System eingegeben hat. Diese Klartextspeicherung hat allerdings einen riesigen Nachteil. Wenn sich ein Angreifer einmal Zugang zum System verschafft hat, kann er im schlimmsten Fall sämtliche Passwörter aller Nutzer einsehen und potentiell Missbrauchen.

Passwortspeicherung in heutigen Systemen

In heutigen Systemen werden Passwörter unter Verwendung von Hashfunktionen bei der Passwortspeicherung in Hashwerte umgerechnet. Hashfunktionen arbeiten prinzipbedingt nur in eine Richtung. Immer wenn ein Passwort von einem Nutzer eingegeben wird, findet diese Berechnung statt. Am Ende wird lediglich der gespeicherte Hashwert mit dem vom eingegebenen Passwort verglichen. Stimmen beide überein, hat der Nutzer das korrekte Passwort eingegeben. Hier ein Beispiel mit dem Passwort "26.09.2011", welches in die Hashfunktion SHA1 eingegeben wird.

heidi@julia:~$ echo -n "26.09.2011" | sha1sum
c29e802c6ccef536e588caf8f8a782d9aea06f80  -

Passwörter, die in dieser "geschredderten" Form gespeichert sind, können wegen des Einwegcharakters der Hashfunktion nur schwer missbraucht werden.

Schwach bleibt schwach

Bei einem bekannten Hashwert eines in Verwendung befindlichen Passworts, kann ebenfalls der Brute-Force-Angriff eingesetzt werden. Am besten sind diese Angriffe mithilfe von Streamprozessoren aus heutigen Grafikkarten durchzuführen. Wer beispielsweise eine aktuelle der Firma Nvidia besitzt, kann Cryptohaze Multiforcer einsetzen. Dieses Programm ist darauf spezialisiert, für einen gegebenen Hashwert den zugehörigen Eingabewert zu finden. Auf das aktuelle Beispiel angewendet, sieht die Bedienung wie folgt aus. Ich speichere den zu brechenden Hashwert und den einzusetzenden Zeichensatz in jeweils eine Datei. Im Anschluss starte ich das Programm und gebe ihm noch mit, dass es sich um einen Hashwert der SHA1-Hashfunktion handelt.

heidi@julia:~$ echo c29e802c6ccef536e588caf8f8a782d9aea06f80 > hash
heidi@julia:~$ echo "0123456789." > charset
heidi@julia:~$ ./Cryptohaze-Multiforcer -f hash -c charset -h SHA1

Während das Programm läuft merkt man sofort, dass der Lüfter der Grafikkarte seine Drehzahl hochfährt und ein Blick in das Nvidia-Steuerungsprogramm zeigt, dass die Temperaturen ein hohes Niveau erreicht haben. Weiter steigt der Energieverbrauch der Grafikkarte massiv an. Ich vermute, dass selbst bei heutigen 3D-Spielen nur selten eine so hohe Dauerbelastung vorkommt. Im Bildschirmfoto ist zu sehen, dass rund 150 Mio. Kombinationen pro Sekunde vom System bearbeitet werden. Verglichen mit den 30.000 aus dem letzten Blogbeitrag, ist das ein gewaltiger Unterschied und zeigt einmal mehr, dass Passwörter wohlüberlegt gewählt werden sollten. Nach weniger als einer Minute beendet sich das Programm und gibt die Lösung aus.

C29E802C6CCEF536E588CAF8F8A782D9AEA06F80:26.09.2011

Grenzen

Auch wenn das Finden der Lösung innerhalb einer Minute sehr eindrucksvoll erscheinen mag, muss eines bei der Bewertung dieses Ergebnisses beachtet werden. Der Zeichensatz war mit "0123456789." nur elf Stellen breit. Je breiter dieser wäre, um so länger hätte mein Rechner benötigt, um auf die Lösung zu kommen, da so erheblich mehr Kombinationen probiert werden müssten. Bei einem echten Angriff gegen Hashwerte von Passwörtern ist ein solch gearteter Angriff nicht sonderlich effizient, da prinzipiell von einem breiten Zeichensatz ausgegangen werden muss. Allerdings reicht er völlig aus, um z.B. alle Hashwerte, die aus einem Datum bestehen, zu brechen.

Diesen vertiefenden Beitrag rund um Brute-Force-Angriffe habe ich wegen der durchweg positiven Rückmeldungen zum letzten Artikel erstellt. Ich hoffe er hat durch das praktische Beispiel verdeutlicht, was mit geschickter Verwendung vorhandener Technologien trotz eines naiven Durchprobieransatzes alles erreicht werden kann.

Passwörter: Länge ist nicht alles

Passwörter sind Teil unseres Lebens geworden. Nichts geht mehr ohne sie. Wo früher noch ein "Guten Tag" und eine Unterschrift auf einem Stück Papier beim wohlbekannten Pförtner genügte, muss heute die Identität für die Autorisierung von schützenswerten Vorgängen über Passwörter geprüft werden.

Der Grund für die exzessive Nutzung von Passwörtern in der heutigen Zeit liegt auf der Hand. Computer können mit einem Krakel auf einem Stück Papier nur bedingt etwas anfangen. Zu fehleranfällig ist die optische Auswertung einer menschlichen Unterschrift. Dies ist darin begründet, dass Menschen zu viele Fehler machen. Jede menschliche Unterschrift ist ein Unikat und Computerprogramme können diese zwangsläufig entstehenden Abweichungen zum gespeicherten Original nicht genau genug herausrechnen. Entweder der Erkennungsalgorithmus wäre zu streng und würde nur jeden tausendsten Versuch von ein und demselben Menschen akzeptieren oder er wäre zu lax und würde jede Unterschrift akzeptieren, die ein wenig nach dem gespeicherten Krakel "riecht".

Computer lieben Passwörter

Passwörter sind anders. Sie sind klar definiert, Computer können sie problemlos abspeichern und solange keine hundertprozentige Übereinstimmung nach einer Eingabe vorliegt, wird der Vorgang nicht als autorisiert betrachtet. Das Problem dabei ist aber, dass sich Menschen lange Zeichenkolonnen nur schwer merken können. Je mental unzusammenhängender die Zeichen eines Passworts gewählt sind, desto kürzer muss es für einen Menschen sein, damit es einigermaßen sicher im Gedächtnis gehalten werden kann.

Schon wieder ein neues Passwort

Jeder war schon in dieser Situation. Man wird von einem System gefragt, welches Passwort man doch gerne benutzen möchte. Der meines Erachtens einfachste Weg ist es, die vierstellige PIN der EC-Karte zu verwenden. Diese Nummer braucht man im täglichen Leben verhältnismäßig häufig und das Vergessen ist durch diesen Umstand und die geringe Komplexität der vierstelligen Ziffernfolge unwahrscheinlich. Dieser Ansatz klappt in den meisten Fällen allerdings nicht, da heutige Systeme eine Mindestpasswortlänge vorschreiben. Erst neulich hat mich das Kundenportal eines Online-Shops aufgefordert, für die Registrierung ein mindestens achtstelliges Passwort einzugeben.

Menschen können langsam sein

Kurze Passwörter haben den Nachteil, dass sie durch einfaches Ausprobieren der möglichen Zeichenkombinationen herauszufinden sind. Beispielsweise hat ein dreistelliges aus Dezimalziffern bestehendes Passwort 1000 mögliche Kombinationen. Beginnend bei 000 hat ein Mensch bei einem primitiven Kofferschloss verhältnismäßig lange zu tun, bis er alle Kombinationen zur 999 ausprobiert hat. Angenommen er benötigt für das Einstellen einer neuen Kombination und dem Probieren, ob der Koffer nun geöffnet ist, drei Sekunden, so erfordert das Knacken im schlechtesten Fall 50 Minuten. Ungeduldige Menschen kann dies von unbefugtem Öffnen abhalten.

Computer sind manchmal schneller

Computer sind bei repetitiven Aufgabenstellungen meist erheblich schneller als Menschen. Beispielsweise hat mir mein Internetprovider bis vor ein paar Monaten die Monatsabrechnung per E-Mail zugesandt. An der E-Mail hing stets ein verschlüsseltes PDF, welches mit einem neunstelligen Zifferncode geschützt war. Dieser Zifferncode war meine Kundennummer und als sich diese beim Wohnungsumzug geändert hat, war ich nicht mehr in der Lage, die Rechnung zu lesen. Die Kundennummer steht in der Rechnung und ich komme nicht ran, da sie verschlüsselt ist. Eine verzwickte Situation möchte man meinen.

pdfcrack

Glücklicherweise habe ich das Werkzeug pdfcrack in den Paketquellen meines Betriebssystems entdeckt.

heidi@julia:~$ apt-cache search pdf knack
pdfcrack - Passwörter von PDF-Dateien knacken

Nach erfolgter Installation und habe ich es auf die verschlüsselte Rechnung "gehetzt", um endlich meine neue Kundennummer zu erfahren. Eingestellt habe ich dabei, dass die Passwortlänge exakt neun Stellen hat und dass der zu verwendende Zeichenvorrat die zehn möglichen Ziffen unseres Dezimalsystems umfassen soll.

heidi@julia:~$ pdfcrack -f rechnung.pdf -n 9 -m 9 -c 0123456789

Mit den ca. 30.000 Versuchen pro Sekunde hätte mein ca. zwei Jahre alter Computer im schlechtesten Fall etwa 9,5 Stunden gebraucht. Dies ist kurz im Vergleich zu menschlichem Ausprobieren, aber wenn man bedenkt, dass pdfcrack lediglich auf den Hauptprozessor meines Computers zurückgegriffen hat, ist die Situation noch viel brisanter. Der Hauptprozessor heutiger Standardcomputer ist für diese Art von Berechnungen verhältnismäßig ungeeignet, da er für das Probieren einer Kombination eine Vielzahl verschiedener Lade-, Vergleichs- und Speicheroperationen immer wieder nacheinander durchführen muss. Viel besser geeignet sind stattdessen Streamprozessoren, die in heutigen Grafikkarten zu finden sind. Sie sind darauf spezialisiert, gleiche Operationen auf eine riesige Menge an Daten anzuwenden. Man kann es sich so vorstellen, dass der Streamprozessor einmal auf die durchzuführenden Operationen eingestellt wird und im Anschluss die Datenmengen "nur noch" nacheinander durchgeschoben werden. Im Passwortbeispiel wären das die vielen möglichen Passwörter. Mit leistungsfähigen Streamprozessoren heutiger Generation sind Raten von weit über einer Million Versuchen pro Sekunde möglich.

Die Mischung machts

Nicht nur die Länge eines gewählten Passworts ist wichtig. Auch die Breite des eingesetzten Zeichensatzes ist erheblich. Auch noch so schnelle Prozessoren können es momentan nicht mit endlichem Zeitaufwand schaffen, ein z.B. achtstelliges Passwort bestehend aus Ziffern, Buchstaben und Zeichen wie z.B. S$1äö§fG über den Ansatz des naiven Ausprobierens zu knacken. Auch wenn diese Passwörter relativ komplex sind, ist es durchaus möglich, gut merkbare Passwörter zu wählen. Welches am besten merkbar und trotzdem sicher ist, muss jeder selbst entscheiden.

Ich hoffe, dass dieser Beitrag ausreichend veranschaulicht hat, wie ein sogenannter Brute-Force-Angriff gegen einen verschlüsselten Container funktioniert. Weitere Arten von möglichen Angriffen gibt es in einem der nächsten Blogbeiträge. Hoffentlich war dieser nicht zu lang(weilig).

Lubuntu: Mein Lieblings*buntu

Ich habe bereits einige Linuxdistributionen ausprobiert, aber bisher erfüllt keine andere meine Ansprüche für den täglichen Einsatz so gut, wie das Ubuntuderivat Lubuntu.

Ich mag Ubuntu. Dies liegt mit hoher Wahrscheinlichkeit daran, dass ich bisher die meiste Zeit mit dieser Distribution verbracht habe. Besonders gefällt mir dabei, dass die Standardeinstellungen vieler Softwarepakete, wenn überhaupt nur noch wenig Nacharbeit erfordern. Falls ich beispielsweise VirtualBox installieren möchte, schaffe ich das mit einem einzigen Befehl°. Ich muss mir keinerlei Gedanken über eventuell notwendige Kernelmodule, Menüverknüpfungen usw. machen.

Seitdem sich nun die Ubuntuentwickler in 2010 für den Einsatz von Unity entschieden haben, komme ich mit der standardmäßig installierten Benutzeroberfläche nicht mehr zurecht. Für mich und meine Gewohnheiten war und ist der Unterschied im Bedienkonzept einfach zu groß, um mich in endlicher Zeit so umorientiert zu haben, dass ich die gleiche Arbeitsgeschwindigkeit wie vor der Umstellung erreiche. Gnome 2 anstelle von Unity einfach weiterzuverwenden, war leider nicht möglich, da die Gnomeentwickler in der neuen Version Gnome 3 ebenfalls einige Änderungen im Bedienkonzept vornahmen, mit denen ich nicht direkt zurechtkam. In meiner täglichen Arbeit habe ich die folgenden Anforderungen an ein Desktop Environment:

schonender Umgang mit Systemressourcen - Die eigentlichen Anwendungen wie Firefox, Eclipse, VirtualBox, LibreOffice, Evolution, Nautilus usw. haben schließlich einen enormen Ressourcenbedarf.
mehrere Desktops
mehrere frei verschiebbare Fenster auf jedem Desktop möglich
eine permanent sichtbare und auswählbare Liste an Fenstern des aktiven Desktops
eine falls vorhanden permanent sichtbare Titel- und Menüleiste an jedem Fenster
ein permanent erreichbares Menü mit installierten Anwendungen
frei konfigurierbares Maus- und Tastaturverhalten
Fensteroptionen
- Schließen
- Minimieren
- Größe ändern
- Maximieren
- immer im Vordergrund
- auf anderen Desktop verschieben
- Vollbildmodus
permanent sichtbare Basisinformationen
- Datum und Uhrzeit
- Netzwerkstatus
- Prozessorlast
- Speicherlast
- Akkufüllstand (bei Mobilgeräten)
keine Bewegungen oder Animationen

Da all diese Punkte meines Erachtens nicht bzw. nicht ausreichend von Unity oder Gnome 3 erfüllt wurden, musste ich also einen Ersatz für das in Ubuntu bald nicht mehr unterstützte Desktop Environment Gnome 2 finden, das ich im Laufe der Jahre so schätzen gelernt habe. Das Ubuntuderivat Kubuntu habe ich bereits bei Kollegen öfters benutzen dürfen. Das dort eingesetzte KDE erfüllt nahezu all meine Anforderungen, allerdings sind viele der angebotenen Funktionen teilweise instabil. Dies in Kombination mit dem relativ hohen Ressourcenbedarf, hat dazu geführt, dass ich KDE als Alternative im Auge behalte, aber zumindest momentan als für mich nicht passend betrachte.

Als ich eines Abends auf Lubuntu stieß, war ich von der Einfachheit sämtlicher Komponenten überrascht. Ein so minimalistisches Anwendungsmenü hatte ich zuletzt bei Windows 95 gesehen. Es gibt keine Möglichkeit, dort per Maus Einträge zu verschieben oder zu löschen. Die Einträge müssen in einem Systemverzeichnis° per Hand verwaltet werden. Ähnlich funktioniert es mit der Konfiguration der Tastenkombinationen und des Mausverhaltens. Ein Programm suchte ich vergeblich bis ich auf eine große XML-Datei° im Benutzerprofil stieß. Mit ein wenig Übung konnte ich die Konfiguration sehr gut überschauen und im Nachhinein finde ich es schön, dass die Einstellungen nur an diesen Stellen gesetzt werden. So muss ich nicht in verschiedenen Konfigurationstools nach etwas suchen. Im Zweifel brauche ich nur eine Suche innerhalb von Dateien oder Verzeichnissen absetzen und schon finde ich, was ich will. Auch wenn die Konfiguration nicht direkt auf Anhieb von der Hand geht, erfüllt Lubuntu und dessen LXDE praktisch meine sämtlichen Anforderungen. Lediglich eine Speicherlastanzeige musste ich selbstprogrammieren.

Über meine Erfahrungen mit Lubuntu werde ich in ein paar Blogbeiträgen demnächst etwas detaillierter eingehen. Verweisen möchte ich an dieser Stelle auch nocheinmal auf die Lubuntu Screencasts, die man auf der Lubuntu-Website anschauen kann.

Blog-Stöckchen: Darum mag ich Foobar! - Evolution

Auch wenn ich meiner Webseite und damit besonders dieser Blogfunktion noch einige Funktionalitäten schuldig bin, fange ich nun einfach einmal an. Mein eigentliches Ziel ist es schließlich Inhalte zu produzieren und nicht ewig und drei Tage an der Technik zu feilen. Der Grund für diesen Sinneswandel war der Beitrag von Ute über GIMP, in welchem sie die Idee von Christoph aufgreift.

Mailprogramme sind wie Religionen. Jeder hat seine besonderen Gründe, einige legen sich nicht fest und manche kommen auch ohne prima zurecht. Im Bezug auf Religionen traf für mich bisher stets letzteres zu, aber im Bezug auf Mailprogramme kommt für mich seit meines Linuxumstiegs in 2007 nur Evolution in Frage.

Seit meines Betriebssystemumstiegs in 2007 bin ich zumindest privat stets von Linuxmaschinen umgeben. Die Distribution Ubuntu bzw. Lubuntu ist für mich seitdem mein Mittel der Wahl. Da ich damals als Einsteiger die erdrückend anmutende Auswahl an verschiedenen Mailprogrammen nicht überblicken konnte, fing ich einfach an, das standardmäßig installierte Mailprogramm Evolution zu nutzen und habe es im Laufe der Zeit sehr schätzen gelernt.

In der täglichen Arbeit mit E-Mails bevorzuge ich grundsätzlich Mailprogramme, da diese speziell für den Zweck der Mailverwaltung gebaut sind. Sie sind in der Lage E-Mails in geordneter Form auf dem eigenen Rechner vorzuhalten. Weiter bieten sie einen schnelleren Zugang als Browser, da sie exakt wissen, welche Daten sie wo abholen müssen, ohne sich dabei groß Gedanken über die Darstellung machen zu müssen.

Evolution

Die Desktopumgebung GNOME, welche bis vor kurzem in Ubuntu zum Einsatz kam, bietet Nutzern standardmäßig Evolution als Mailprogramm an. In diesem Beitrag möchte ich zwei Funktionen von Evolution hervorheben, die ich beim Ausprobieren anderer Mailprogramme dort oft nicht vorfand.

Einstellungen sichern und wiederherstellen

Ist Evolution einmal eingerichtet, kann man sämtliche E-Mails und Einstellungen im Handumdrehen auf beliebig viele andere Rechner, VMs oder Installationen übertragen. Beim ersten Start von Evolution in einem neuen Benutzerkonto bietet es komfortablerweiser an, eine solche Sicherung zu importieren. Wenn man dies macht, ist die gesamte Einrichtung im selben Augenblick abgeschlossen. Lediglich die Passwörter zu den Mailkonten werden - vermutlich aus Sicherheitsgründen - nicht mit übertragen. Diese Funktion habe ich bisher eingesetzt, um vor einem Upgrade der Distribution eine Sicherung zu erstellen und um den Datenstand von meinem Laptop auf meine anderen Rechner zu übertragen.

Lokalen Postfix einbinden

Da ich momentan als Webentwickler arbeite, habe ich oft die Aufgabe, aus Anwendungen heraus E-Mails zu versenden. Auf meiner Entwicklermaschine habe ich aus diesem Grund stets Postfix laufen, welcher auf die E-Mailadresse heidi@<rechnername>.info lauscht. Sobald beispielsweise ein PHP-Skript nun eine E-Mail an diese Adresse sendet, stellt sie der lokale Postfix in eine mbox-Datei. Zur Kontrolle, ob die E-Mail ein korrektes Format hat, könnte ich zwar einfach diese Datei in einem Editor öffnen, komfortabler ist es jedoch mit der mbox-Postfacheinstellung in Evolution. Mit deren Hilfe wird die von Postfix erzeugte mbox-Datei als "richtiges" Postfach dargestellt und ich kann exakt prüfen, ob der Text- bzw. HTML-Inhalt korrekt übertragen wurde.

Ich hoffe, dass dieser Beitrag den allgemeinen Anforderungen an einen Blogeintrag genügt und dass ich bald Zeit finde dieses Blog mit noch ein paar mehr Features zu versehen.

Blogartikelfunktion

An dieser Stelle kann in naher Zukunft ein richtiger Blogartikel bestaunt werden.

Die Kurzmeldungen werden geschlossen unter diesem Aufreißerblogartikel dargestellt. Diese sind bereits mit einer eigenen Archiv- und Tagfunktion ausgestattet und können dadurch meines Erachtens bequem durchsucht werden. Mir ist klar, dass noch eine große Menge an Funktionalitäten fehlen. Beispielsweise habe ich noch vor,

eine Kommentarfunktion
ein Teaserbild
Artikelbilder
Artikeltags
eine Artikelarchivübersichtsfunktion
...

zu implementieren.