Internet

Nachdem ich der IM-Welt nun so lange den Rücken zugekehrt habe (von kurzen Intermezzi mit ICQ mal abgesehen), will ich [d/n]och einmal versuchen, auf den Zug aufzuspringen.

Zu diesem Zwecke habe ich auf meinem Server einen Jabber/XMPP-Server installiert und bin somit via sven auf svenhartge.de zu erreichen.

Schauen wir mal, wie das Experiment verläuft.

Normalerweise bin ich ja eher der Fan von handgemachter Musik mit E-Gitarren und echten Vocals. Aber zum gemütlichen Chillen und Arbeiten bin ich dann doch meistens für trancigeres zu haben, nach möglichkeit fliessend und ohne große Gesangseinlagen, die ablenkend wirken könnten.

Mein derzeitiger Lieblingssender ist daher LiquidFM, damit auf den Ohren und ein paar XTerms vor einem läßt sich schon einiges bewegen.

Das es nicht einfach ist, einen Webserver zu bauen, der mit potentiell "feindlichen" Scripten und Programmen beladen werden wird (lies: Webserver für Studenten und Mitarbeiter), war mir ja schon von Anfang an bewusst.

Aber die Arbeit, die ich bisher investieren musste, zeigt mir doch, wie unausgegohren dieses Feld immer noch ist. Auch die verfügbare Doku ist eher dünn gesäht und auf objektive Vergleiche, was wann wo wozu warum womit wogegen nutzbar ist, findet man nur selten.

Ich bin daher Marc für seine Dokumentation mehr als dankbar, weil er mir zumindest die Arbeit abgenommen hat, die verbreitesten Lösungen zu suchen, zu sammeln und zu bewerten.

Marc berichtete ja schon von seinen Versuchen, allerdings ist seine Problemstellung etwas anders als meine, so dass ich glücklicherweise zu einem anderen Ergebnis kommen konnte.

Mir reicht daher suExec für alle normalen CGI-Scripte (Shell, Perl, Ruby, Python, ELF, ...) und suPHP für den Rest, da ich die User nur über mod_userdir verwalten muss und keine einzelnen Kunden oder virtuellen Domänen voneinander trennen muss.

Glücklicherweise, denn ein eigenes PHP für jeden User (über 1500) oder andere manuelle Verrenkungen wären nicht lustig gewesen. Das System soll so einfach wie möglich bleiben, damit auch ein uneingeweihterer Admin damit klar kommt, ohne auf Dinge wie veränderte Init-Scripte, erweiterte Apache-Komponenten oder manuell gepatchte Wrapper "hereinzufallen" (was zwangsläufig passiert, egal wie gut die intenre Dokumentation dazu ist).

Bitte, bitte, $DEITY, lass den Schmerz vergehen.

Warum werde ich gleichzeitig mit

1. einem uralten und halbkaputten Solaris 2.6
2. 35GB zu tranferierneden Daten auf einer Sun Enterprise 150
3. Cisco IOS 12.3(T)
4. Kernel 2.6.17
5. und den daraus resultierenden bekannten "Interessantheiten" im Bezug auf Window Scaling

geschlagen?

Es macht wirklich keine Freude, wenn man mit 50KB/s diese Datenmengen transferieren muss und einem dabei immer wieder der Transfer-Prozess auf der Datenquelle "abhanden" kommt.

Nach langer Entwicklungszeit ist das von mir verwendete Blog-System Serendipity auf Version 1.0 angekommen.

Glückwunsch an Garvin und sein Team!

Und wie üblich war das Update durch ein einfaches Kopieren über die alte Installation erledigt.

Für alle ungeduldigen Liferea und Debian-Sid-User habe ich neue Pakete der aktuellen Version 1.0.14 gebaut, die mit dem neuen XulRunner-Support ausgestattet sind. Dies ermöglicht endlich vernünftig gerenderte Ansichten in Liferea direkt, ohne das ein externer Browser gestartet werden muss.

Die Pakete findet man im Download-Bereich. (Sorry, kein via apt-get benutzbares Verzeichnis, das kommt später evtl. einmal.)

... Geschwindigkeit.

260 KByte/s fühlen sich dann doch wesentlich besser an als 7,6 KByte/s.

Damit hat die Zukunft auch bei mir Einzug gehalten, nachdem ich (bis auf das kurze Intermezzo in Duisburg) Internet nur auf 80er-Jahre-Geschwindigkeit kannte.

Danach war aber erst einmal nichts mehr zu hören, keine Bestätigung via eMail oder Brief, so daß ich ein klein wenig unruhig wurde, ob mein Auftrag überhaupt angekommen ist und bearbeitet wurde.

Die FAQ teilt mir zwar mit, das bis zu zwei Wochen Wartezeit nach der Erteilung des Auftrags entstehen können, allerdings hätte ich schon irgendeine Regung seitens Iesy erwartet.

Für heute hatte ich mir daher vorgenommen, dort einmal anzurufen und nachzufragen. Bevor ich aber dazu kommen konnte, wurde ich von einem von Iesy beauftragten Unternehmer angerufen und um eine Terminabsprache zur Installation der notwendigen Technik gebeten.

Und somit steht es fest: Sofern nichts gravierendes dazwischen kommt, werde ich am 18.05. gegen 11:30 die Zeit der schmalbandigen Internetanbindung hinter mir lassen und in ein (für mich) neues Zeitalter aufbrechen.

Nur: Das läuft bisher zu glatt. Irgendein Haken muss doch dabei sein.

Nachdem DSL bei mir ja aufgrund der sensationellen Dämpungswerte nicht möglich ist und ich mich schon damit abgefunden hatte, auf ewig (oder zumindest bis zum nächsten Umzug) auf ISDN festgenagelt zu sein, hat meine Kabelgesellschaft ein Einsehen mit mir:

Also habe ich doch gleich einmal das Angebot bestellt und harre der Dinge, die da kommen mögen. (Irgendwann in meinem Leben muss mir doch einmal Glück beschieden sein.)

Danke auch an Jens für den Hinweis.

Vorgestern war der Webmailer dran, heute schlug die Stunde des Umzug des internen Mailservers meiner FH. Gegen 10:00 Uhr haben wir angefangen, die Vorbereitungen abzuschließen, um ca. 15:00 wurde der interne Teil des Mailsystem dann heruntergefahren und mehr oder weniger komplett umgebaut.

Bis 17:00 wollten wir fertig sein, aber wie üblich, wenn man der Meinung ist, alles bedacht, alles vorbereitet zu haben, kommen Dinge dazwischen, an die man nicht gedacht hat bzw. die sich in der realen Welt dann anders verhalten als in der Theorie bzw. der Simulation.

Da nach kurzer Zeit ein bestimmter "Point of no Return" erreicht war, blieb dann nur die "Flucht nach vorn" und die Arbeiten eben abzuschließen, wie lange sie auch dauern mögen.

Was sich in diesem Falle bis kurz nach 01:00 Uhr hinzog.

Dafür war dies ein wichtiger Schritt zu einer einfacheren Skalierbarkeit inkl. der Möglichkeit eines besseren Failover im Fehlerfall.

Ich krebse ja nun schon seit Ewigkeiten mit ISDN im Internet herum. Zwar immerhin eine Flatrate (von Arcor), aber eben nur ISDN. Einen Versuch DSL zu erhalten habe ich bereits hinter mir, damals war dies ein kapitaler Fehlschlag, denn eine Synchronisation des Modems mit dem DSLAM war aufgrund viel zu hoher Dämpfung nicht möglich.

Da man mir gesteckt hat, das sich an der Leitungsführung wohl etwas geändert hat und das die Telekom einige Anschlüsse umgeschaltet hat, hatte ich bei Arcor eine Neuprüfung meines Anschlusses in Auftrag gegeben.

Und heute habe ich das Ergebnis erhalten: Satte 70,01dB für die 5993m Kabel von der VSt zu mir. (46dB sollten es für DSL1000 maximal sein, mit 70dB gibt es noch nicht einmal die Light-Variante davon.)

Mit diesem Wert ist es schon fast verwunderlich, dass ISDN überhaupt funktioniert.

Also werde ich wohl warten müssen, bis iesy mit dem Breitbandkabelausbau voran kommt oder Wimax zur Verfügung steht.

Solange ergötze ich mich eben weiter an phantastischen 7,6KB/s.

Gut, es war mir ja von Anfang an klar, das SPAM (auch UCE genannt) meine neuen Mail-Adressen fluten würde, aber das schon nach wenigen Tagen knapp 15% meines täglichen Spam-Aufkommens über die neue Domain kommen würde, das hat mich doch etwas überrascht.

Also habe ich die notwendigen Dinge erledigt und den auf meinem Server laufenden Exim4 um ein paar ACLs erweitert, die das ganze ein klein wenig dämpfen sollten.

Dazu gehört z.B., dass Rechner, die in einer DNSBL stehen oder deren IP nicht zu einem Hostnamen auflöst, erst einmal 5 Sekunden auf das MTA-Banner warten dürfen. Das erfasst schon einmal viele dumme Spam-Bots und bei meinem geringen Mailaufkommen kann ich mir das leisten.

Dann bekommen Rechner, die sich mit meinem Hostnamen oder meiner IP im HELO melden, gleich die Verbindung wieder weggenommen, da dies zu 100% Spam-Bots sind.

Dann siebt ClamAV nach Viren, Würmern und Phishing-Mails und schlussendlich begutachtet SpamAssassin die Mail, wobei letzterer noch auf moderatoren 9,0 Punkten für eine Ablehnung steht.

Nun muss die Zeit zeigen, wo ich noch drehen und schrauben muss, bis alle Teile soweit brauchbar miteinander harmonieren.

Exim4 bietet ja glücklicherweise genug Möglichkeiten, um in den ACLs auf verschiedene Dinge zu prüfen und sich darauf basierend dann entsprechend zu verhalten.

Geekcode war früher, jetzt gibt es Publicons: