Technik

Ich weiß es nicht.

Was ich aber weiß ist, dass mplayer in Verbindung mit meinem mod_dvb schon mal Probleme bei der Datenübertragung via WLAN hatte, weswegen ich eigentlich immer auf meiner Workstation fern geschaut oder eben ein LAN-Kabel an den Laptop angeschlossen habe.

Irgendwann letzte Woche wollte ich mal Kaffeine, das ja bekanntlich auf Xine basiert, ausprobieren. Das hat auch wunderbar funktioniert, so sehr, dass ich kurzerhand Kaffeine's Playlisten-Format als Handler in mod_dvb integriert habe. Irgendwann einen Abend später fiel mir dann mal auf, dass ich das LAN-Kabel gar nicht im Laptop stecken hatte...

... obwohl ich schon die ganze Zeit völlig ruckelfrei fern gesehen habe... Merkwürdig! Warum sollte Xine besser über WLAN-Netze laufen als mplayer? :hmm:

Es ist nun schon fast eine halbe Ewigkeit her, dass ich festgestellt habe, dass es nun auch LightScribe-Software für Linux gibt...

Allerdings bin ich bis dato niemals wirklich dazu gekommen, es wirklich mal zu testen - bis gestern! Gestern gab es für mich einen privaten Anlass (deswegen gibt es auch keine Fotos oder so ) die ganze Sache mal auszuprobieren - außerdem ist es traurig immer nur den Staub von den ganzen LightScribe-Rohlingen zu wischen.

Entgegen der Weitläufigen Meinungen, dass LightScribe unter Linux immernoch ein schweres Unterfangen sei, bin ich eigentlich richtig zufrieden, denn es hat alles sofort und ohne Probleme funktioniert. Nunja, der Umstand, dass der Labeler immer nur ein einzelnes Bild schreiben kann stellte mich vor ein ganz kleines Problem - aber wozu gibt es so tolle Programme wie GIMP, wo man sich in Windeseile eine Schablone erstellen kann?

Mein Fazit: Immernoch ne tolle Sache - wenn auch nur Spielerei - die ich von nun an Garantiert öfter machen werde!

Ich habe irgendwann mal die Regel eingeführt, dass in unserer Datenbank jeder Posten einer Rechnung seperat abgebildet wird, d.h. es gibt ein übergeordnetes Rechnungs-Objekt, dem mehrere Posten untergeordnet sind.

Eigentlich eine tolle Sache, denn so kann man ganz bequem über unser Interface jede Rechnung anschauen ohne groß kramen zu müssen oder PDFs runterzuladen. Der Nachteil daran ist natürlich, dass man jeden einzelnen Posten gesondert einpflegen muss.

... das stößt mir bis heute jeden Monat ganz besonders bei den Rechnungen unseres Registrars auf, denn jede Registrierung, Verlängerung oder jeder Transfer einer Domain wird dort als einzelner Posten gebucht - und man kann sich vorstellen, dass man hierbei sehr schnell im dreistelligen Bereich ist.

Und das von Hand? Nie wieder!

Heute war es wieder fällig und ich hatte echt keine Lust mehr. Gut, dass unser Registrar dazu eine Schnittstelle hat mit der man indirekt auf die Posten einer Rechnung zugreifen kann - habe ich mehr oder weniger nur durch Zufall herausgefunden und gleich mal implementiert.

Der interessiere Kunde und der neugierige Blogleser wissen, dass wir auf unseren Webserver PHP an einer FastCGI-Schnittstelle betreiben. Im normalen Betrieb ändert sich - nicht zuletzt dank einiger Patches - für den Kunden rein gar nichts, es fühlt sich meistens an wie das andernorts übliche mod_php.

Die Art und Weise wie PHP dies implementiert ist hervorragend, denn für jeden beliebigen PHP-Skript muss nur ein einziger Interpreter ausgeführt werden - etwas, was ich schon oft vermisst habe. Denn die anderen populären Sprachen wie Perl oder Python implementieren ihre FastCGI-Schnittstellen zumeist auf höherer Ebene, d.h. ein FastCGI-Prozess kann oftmals nur mit einem Perl- oder Python-Skript verwendet werden, sprich nicht so universell wie PHP.

... solch eine Lösung kam für mich eigentlich niemals in Frage, zumal im Falle einer "kapitalistischen Umsetzung" der Kunde hier speziell nur FastCGI-Skripte verwenden könnte. Unnötiger Mehraufwand!

Für Python habe ich heute einen ersten "Wrapper" geschrieben: Momentan noch ein kleiner 20 Zeiler in C geschrieben, der sich den Python-Interpreter und die FastCGI-Schnittstelle zu eigen macht und beides "intelligent" miteinander kombiniert. Die ersten Tests waren bisher sehr vielversprechend - ich bin mal gespannt, was daraus wird! :hmm:

... wenns fertig ist, wird es dann natürlich OpenSource - versteht sich von selbst

Ich wollte schon immer mal unsere eingesetzte PHP-Version (5.1.4) auf etwas höheres upgraden...

Allerdings bin ich bisher immer vor der 5.2er-Reihe aufgrund von Migrationsberichten zurückgeschreckt und für die 5.1er habe ich mich ehrlich gesagt zu dämlich angestellt, da das letzte Release zu finden :hmm:

Gestern Nacht habe ich mir dann ein Herz gefasst, nochmal genauer geschaut und ein wenig geschraubt. Auf meinem Entwicklungssystem läuft nun PHP 5.1.6 und PHP 5.2.4 im Parallelbetrieb, d.h. ich kann individuell bestimmen für welchen Kunden welche PHP-Version benutzt wird. Aus Spass habe PHP 4.4.7 noch oben drauf gelegt - man weiß ja nie - auch wenn ich dafür übelste Beschimpfungen vom Helferlein über mich ergehen lassen musste.

Wer PHP 4.4.7 zusätzlich noch mit dem Suhosin-Patch versehen will und das Modul statisch einkompiliert könnte btw. Probleme beim Installieren bekommen - hierzu als kleiner Tipp: Einfach die Funktionen import_request_variables und extract im Modul "Standard" nicht registrieren lassen

Momentan repliziere ich alle Neuerungen auf ein Produktivsystem für den ersten "heißen" Test

Apaches mod_spelling ist ja an sich eine feine Sache - gelegentlich hilft es wirklich mal Seiten zu finden. Was ich jedoch grenzwertig finde ist, die Möglichkeit einen "Index" zu generieren, wenn mehrere mögliche Dateien gefunden worden.

Wenn man sich ganz bewusst selbst dafür entscheidet ist das ja alles kein Problem, ist man nun aber bei einem Hosting-Anbieter, der das ohnehin schon voreingestellt hat, kann es passieren, dass man das gar nicht möchte und in unglücklichen Fällen können Besucher so eine teilweise Verzeichnisauflistung erhalten.

Ich finde das aus Hostersicht datenschutztechnisch bedenklich. Auch wenn ich das gerade ein wenig überzeichnen mag...

Abhilfe schafft dabei dann natürlich folgendes Konstrukt in der .htaccess:

<IfModule mod_spelling.c>

CheckSpelling Off

</IfModule>

Irgendwann anfang der Woche hatte ich kein Strom mehr in meinem Handy. Ärgerlich!

Allerdings habe ich Dank T-Mobile - weil die es nicht schaffen wollen meinen Sprachtarif mit meinem Datentarif zu kombinieren - immer ein zweites, altes Handy dabei, mit dem mein (ebenfalls recht alter) PDA über GRPS online gehen kann. Da Erreichbar sein manchmal wichtiger als im Internet surfen sein kann (gleichwenn der Mensch nicht immer erreichbar sein muss) habe ich einfach die SIM-Karten getauscht und mit meinem alten 6310i-Totschläger vorlieb genommen.

Das Interessante daran: Ich hab seitdem die Handies nicht mehr getauscht. Ich will es gar nicht!

Dieses doch recht betagte Gerät ist einfach klasse... Es liegt gut in der Hand, kann genau richtig viel, ist leicht und strahlt seine Funkwellen wie ein defektes AKW Radioaktivität Nun gut, es ist nicht bunt, hat keine Kamera und kann nicht so Spielereien wie MP3s abspielen oder MMS-Nachrichten versenden. Aber brauch ich das?

Nein!

Ganz nebenbei kann das Ding noch etwas, was die neuen auch nimmer können: Piepen, ohne das es nach Dose klingt. Besonders hervorragend empfand ich hier immer das "einmal kurz piepen und dann nur noch vibrieren", was für mich als Anrufsignalisierung immernoch mehr als ausreichend ist.

Genau heute vor einer Woche - auf meiner letzten großen Zugfahrt - habe ich spontan während der Fahrt von unserem VPN Gateway auf mein heimisches VPN gewechselt.

Grund hierfür war die Tatsache, dass wir beim VPN Gateway auf TCP-Kommunikation setzen, ich zu Hause allerdings - wie für OpenVPN auch normal - UDP für die Verbindung einsetze. Letzteres ist natürlich mehr ein Heimspiel für OpenVPN und sollte bei GRPS-Verbindungen prinzipiell besser funktionieren...

... was auch umgehend bestätigt wurde: Der Verbindungsaufbau ging viel schneller - zwei bis drei Mail schneller - und alles andere schien auch normal schnell bis ein wenig schneller zu funktionieren...

Nur wunderte ich mich ein wenig, warum mir bei Jabber auf einmal niemand mehr zurückschrieb und auch Thunderbird sich beschwerte, dass der E-Mail-Server nicht mehr reagierte. Noch merkwürdiger noch: Wenn mir jemand bei Jabber schrieb, kam das an und auch die Antwort ging laut Konsole raus, kam aber nie beim Server an :hmm:

Testweise habe ich die entsprechenden IP-Adresse am VPN-Tunnel vorbeigeroutet und sofort funktioniere alles wieder wie gewohnt :eek: Später habe ich dann wieder durch den Tunnel geroutet, aber in beiden Fällen die SSL-Verschlüsselung beider Protokolle deaktiviert - auch das funktionierte...

Zugegeben: Ich habe mich seitdem nicht weiter um das Problem gekümmert (es fiel mir gerade eben nur wieder auf) aber ärgerlich ist das doch schon. Immerhin hat sich meine erste große Panik des "Hoffentlich ist das nicht auch beim VPN Gateway so!" nicht bestätigt. Da funktioniert alles so, wie es soll...

Gestern Nacht schraubte ich mehr in eigener Sache am Mailserver:

Ich wollte unsere Support-Mailbox direkt über die Mitarbeiter-Mailboxen verfügbar machen. Die Ursache liegt wohl mehr bei mir als bei irgendwem anders: Ich bin einfach nur zu faul normalerweise mehr als eine Mailbox abzufragen - mit der neuen Lösung wird das überflüssig.

Ganz nebenbei habe ich dann das System dahingend modifiziert, dass jeder Kunde nun einen neuen IMAP-Namespace namens "#shared" verfügt - schließlich macht teilen Spass! Über diesen Namespace können alle Benutzer-Accounts eines Kunden auf ein und die selbe "Mailbox" zugreifen, d.h. Verzeichnisse anlegen und dort Mails austauschen bzw. archivieren...

... wie so oft werden das nicht gerade ein großer Teil der Kundschaft nutzen, aber es ist doch schön die Möglichkeit zu haben

Gerade eben ist es mir wieder aufgefallen und gestern bin ich auch mehrmals drüber gestolpert:

Wenn ich etwas in eine .htaccess-Datei (besonders die von Kunden) schreibe, dann baue ich immer <IfModule>-Direktiven drum herrum. In unserem Falle eigentlich überflüssig, da alle Webserver aus "einem Guss" sind, also immer die selben Module vorweisen und man quasi davon ausgehen könnte, dass es auch ohne funktioniert.

Die andere Seite der Medallie gibt es natürlich auch: Mein Helferlein sollte gestern für einen Kunden eine eGroupware-Installation aufsetzen, die ihn nach Entpacken der Distribution erst einmal mit einem "internal Server Error" begrüßte...

... grund hierfür war wohl, dass der Spassvogel, der die .htaccess-Datei von eGroupware geschrieben hat, vorausgesetzt hat, dass auf dem Zielsystem entweder mod_php4 oder mod_php5 vorhanden ist. Ich mag sowas ja nicht... Die Tatsache, dass ein Webserver PHP-Skripte ausführen kann impliziert für mich noch lange nicht, dass dies über den passenden Apache-Handler geschieht. Es mag weit verbreitet sein, doch als Standard würde ich es dennoch nicht deklarieren wollen. Und warum dann nicht die Techniken für solche Fälle verwenden, die genau für so etwas gemacht worden sind. :hmm:

Ich bin ja für <IfModule>-Direktiven um jede Einstellung (solange sie nicht aus dem "core" stammt)

In den vergangenen zwei Wochen wurde ein Kunde immer wieder Opfer etwas, was wie DDOS-Attacken anmutete...

... im Prinzip waren sie das auch, nur war die Absicht des Verursachers sicherlich eine andere: Spam.

Bei dem Kunden gingen pro Minute mehrere tausend Anfragen ein, die der Webserver schlichtweg nicht mehr schnell genug abarbeiten konnte und seine Warteschlange in Folge dessen "überlief". Heute hatte ich mal die Schnautze voll und bin dem Problem auf den Grund gegangen.

Mit einer einfachen mod_rewrite-Regel lies sich das Problem bis auf weiteres abstellen:

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteBase /

  RewriteRule ^comment\.php.* / [L,forbidden]
</IfModule>

Wie ich dann eben zur Kontrolle in die Zugriffsprotokolle schaute, kam in mir der Gedanke auf, dass man diese Daten rein theoretisch und fast perfekt für eine DNSBL nutzen könnte, denn abgesehen von den vielen IP-Adressen änderte sich nichts. Alle Anfragen gingen auf die comment.php vom dort installierten Serendipity und sendeten weder einen Referer noch einen User-Agent.

Ein fehlender Referer sollte hier sicherlich nicht allein als Kriterium gelten, allerdings ist die Kombination aus beiden Einträgen sicherlich ein einmaliges Merkmal, denn zumindest die Browser senden doch mindestens ein "Mozilla/5.0" (o.ä.) und im Falle von Serendipity schicken "normale" Benutzer ihre Kommentare gar nicht an die comment.php, somit kann wohl jeder der die beiden Einträge nicht sendet als "Zombie-Computer" eingestuft und vielleicht auch beim E-Mail-Verkehr oder via etwas wie mod_dnsbl geblocked werden.

... natürlich nur, wenn der entsprechende Kunde mitmachen will, immerhin würden wir seine Daten weiterverwenden... :hmm:

Wir haben uns in den letzten Tagen ein wenig um unseren DDNS-Dienst gekümmert, der nicht vor allzu langer Zeit seinen ersten Geburtstag feiern durfte.

Rückblickend lässt sich sagen: Die Einführung war mit recht viel Arbeit im Vorfeld verbunden, danach lief aber alles so reibungslos, als hätte es diese Erweiterung unserer Domains schon immer gegeben. Mir sind bis heute keine wirklichen Probleme bekannt...

Wurde also Zeit, dass wir zum einen den Dienst selbst verbessern und ihn gleichsam auch besser in unser Kundeninterface mit integrieren. Letzteres habe ich gestern getan und seitdem...

Übersicht	... wird man nun im Kundeninterface schon auf der ersten Seite zum DDNS-Dienst mit einer Liste der eigenen DDNS-Domains und dem nützlichen Wiki-Link begrüßt...
Protokolle in neuem Gewand	... bekommt eine schönere Übersicht der Zugriffs- und Änderungs-Protokolle...
Ganz neu!	... und kann neuerdings die Domain auch direkt im Kundeninterface manuell bearbeiten... (Was wohl nur bedeuten kann, dass wir da ganz schnell einen "allgemeinen" DNS-Editor nachlegen müssen )

Seit zwei Wochen habe ich hier im "Home-Office" mein - mittlerweile uraltes - SIP-Projekt im parallelen Testbetrieb, d.h. ankommende Anrufe werden zum einen auf die herkömmlichen Telefone wie auch auf SIP-Endgeräte weitergeleitet. Zweiteres funktioniert auch schon richtig gut. So war ich vergangene Woche mal außerhalb, habe mein SIP-Telefon mitgenommen und über meinen Laptop mit der heimischen Telefonanlage verbunden - Telefonieren, eingehend wie auch ausgehend, funktioniere Problemlos

Beim Raustelefonieren kann ich nun auch wahlweise bestimmen, ob ich über ISDN oder über einen (beliebigen) SIP-Provider raustelefonieren möchte. In beiden Fällen kann ich auch bequem die übertragene Absenderkennung direkt an meinem Endgerät setzen.

Mein Helferlein schwört ja auf Jingle anstelle von SIP. So ganz beipflichten würde ich ihm da nicht, allerdings finde ich es grundsätzlich nicht falsch auch eine solche Implementierung mal anzugehen - zumal es auch ganz neue Wege der Kontaktaufnahme ermöglichen würde... :hmm:

In den letzten Wochen hat meine Umwelt mich sehr oft von "White Class" und "Grey Class" sprechen hören...

Das hängt wohl damit zusammen, dass wir - nicht zuletzt wegen dem erhöhten Spam-Aufkommen der Vergangenheit - ein wenig an unserer E-Mail-Infrastruktur gearbeitet haben und seitdem E-Mails in zwei Klassen unterteilen:

• "Weiße E-Mails", die als sauber gelten. Die stammen entweder von unseren Servern direkt, wurden authentifiziert von einem Kunden verschickt oder haben die graue Klasse erfolgreich durchlaufen.
  
• "Graue E-Mails", auch gerne "dreckig" genannt, die von außen kommen und erstmal verschiedene Checks wie Greylisting (was so gesehen kein Check ist ), Spam- und Virenfilter durchlaufen müssen.

Die neue Strategie sieht auch eine klare Trennung beider Systeme vor, was auch für die Zukunft eine großere Skalierbarkeit und Flexibilität ermöglichen sollte... Wenn ein "graues" System mal ausgelastet ist, kann hier einfach ein weiteres dazugeschaltet werden, während für die Kunden keine Veränderung zu spüren ist. Zudem ist die Last auf "weißen" Systemen eher gering, was einen weiteren Geschwindigkeitsvorteil bringt...

Ich weiß noch genau... Es war ein Dienstag morgen und ich wanderte am Essener Hauptbahnhof den Bahnsteig auf und ab und dachte über sowas wie "Anonymisierung für alle" nach...

Seitdem ist recht viel Zeit vergangen und viele Zugriffsprotokolle sind geschrieben worden. Alle alt und klassisch...

Während wir uns intern momentan darauf vorbereiten zum Datensammelmonster zu mutieren (Anfang 2008 solls ja los gehen ), habe ich in den letzten Tagen mal einen ganz anderen Weg gewählt - frei nach dem Motto "Solange es noch möglich ist, sollte man es auch machen":

Unser Backend kann absofort Zugriffsprotokolle in Echtzeit anonymisieren und/oder bestimmte Daten herausfiltern.

Das Webinterface für unsere Kunden hierzu fehlt leider noch, aber wie das genau mal aussehen könnte kann man hier bereits schon sehen (und das was dort steht funktioniert auch wirklich schon so ). Das Portal ist ganz nebenbei ein "Kern-Feature" des ganzen, wo unsere Kunden in Zukunft selbst entscheiden können, ob sie die "Datenschutzregeln" für ihre Webseiten von offizieller Seite her veröffentlichen wollen.