This feed contains pages in the "webseite" category.
Im Folgenden möchte ich mal im Detail beschreiben, wie die Streams und die nette Übersicht unter http://stream.xenim.de/ genau funktionieren und wie man es bei Interesse nachbauen kann. Ich beschreibe dabei nur die Installation auf Debian 3.1 Sarge; die Anleitung sollte aber auch auf andere Distributionen übertragbar sein, wenn man die Paketbezeichnungen entsprechend anpasst. Der erste Teil beschreibt das Ganze recht allgemein und sollte von jedem, der schoneinmal vor einem Computer gesessen hat, verstanden werden können, der zweite Teil enthält dann die detailierte Installationsbeschreibung, für die grundliegende Kenntnisse der Linuxsystemadministration erforderlich sind.
Wie alles zusammenpasst
Zunächst einmal braucht man natürlich einen Mp3- oder Ogg-Stream. Das verteilen dieses Streams erledigt Icecast. Woher bekommt der Icecast aber die Audiodaten? Da gibt es im Groben und Ganzen zwei Möglichkeiten: Die eine ist, die Daten von einem anderen Server einfach weiterzuverteilen (zu "relayen"). Dabei klinkt es sich wie ein normaler Player bei einem anderen Server (Icecast oder Shoutcast) ein und verteilt die weiter. Diese Möglichkeit nutzt man vorallem, um den ursprünglichen Server zu entlasten, falls dieser für die Hörerzahl nicht so gut genug ans Internet angebunden ist. Die zweite Möglichkeit für den Icecast an Audiodaten zu kommen, ist, sich direkt von einer Quelle versorgen zu lassen. Das funktioniert zB mit dem Winamp/xmms-Plugin oddcast oder unter Linux mit ices. (Genauere Infos gibt es demnächst hier nach einem kleinen Update)
Jetzt hat man einen (oder mehrere) Server, der (die) Streams anbieten Wie kommen jetzt die Informationen über die Streams (URL, Metadaten, Hörerzahlen, etc) von den Streamingservern in die Übersicht? Das erledigt eine Funktion names »Yellow Pages«. Die ist normalerweise dazu gedacht, die eigenen Streams in große, öffentliche Verzeichnisse (wie dir.xiph.org) einzutragen, damit die gefunden und auch gehört werden. Diese Funktion ist im Standardicecast bereits integriert.
Nun sollen die Daten nicht in einem öffentlichen Verzeichnis, sondern in einer bestimmten Übersicht landen. Dazu braucht man das, was die Betreiber größerer Verzeichnisse auch verwenden. Diese Software (auch als »Yellow Pagess« oder kurz yp bezeichnet) ist auch Open-Source muss auf dem eigenen Server installiert werden. Die Adresse des yp trägt man in allen Icecaststreamingservern ein, woraufhin diese regelmäßig die benötigten Daten an das yp schicken. Dort nimmt das yp die Daten entgegen und schaufelt sie in eine Datenbank. In der Datenbank wird immer nur der aktuelle Stand der Daten und Nutzerzahlen vorgehalten. Die Seite wird immer dynamisch aus dieser Datenbank generiert.
Wie wird aus diesen Daten die schicke Grafik generiert? Dazu braucht man ein anderes Stück Software namens rrdtools (Round Robin Datenbank Tools). Das ist noch eine Datenbank, die aber nicht nur einen Datensatz, sondern einen Datensatz pro Zeitabschnitt speichert. Dadurch hat man dann auch den zeitlichen Verlauf der Hörerzahlen. Von der ersten Datenbank (in die das yp die Daten speichert) in die zweite Round-Robin-Datenbank kommen die Daten durch ein kleines Perlskript, das - wenn eine Sendung gestreamt wird - regelmäßig in etwa alle 3-5 Minuten läuft. Das Perlscript übernimmt auch das genieren der Grafik aus den Daten der Round-Robin-Datenbank. Damit wären dann alle Teile beisammen: Stream, Tabelle und Grafik.
Die Details
Icecast
Das Paket, das Debian Sarge mitliefert ist etwas veraltet, also ist selberkompilieren angesagt. Also Downloaden, entpacken, ./configure, Abhängigkeiten (Debianpakete libxml2-dev, libxslt1-dev, libcurl3-dev, libogg-dev, libvorbis-dev, liblame-dev) installieren, make, make install (Alternativ könnten man sich auch ein Debianpaket dafür bauen oder das bestehende aktualisieren). Die Binary sollte dann in /usr/local/bin/icecast gelandet sein, die Konfigurationsdatei deponiert man dann am zweckmäßigsten in /usr/local/etc/. In der Konfiguration ändert man dann ersteinmal die Passwörter: Das Admin-Passwort braucht man eigentlich nur für das Webinterface und sollte eigentlich geheim bleiben, das Source-Passwort wird für die Sourceprogramme (oddcast, ices) benötigt und muss gegebenenfalls an diejenigen weitergegeben werden, die dann das Signal liefern. Unter
<directory>
<yp-url-timeout>15</yp-url-timeout>
<yp-url>http://directory-server.tld/cgi-bin/yp_cgi</yp-url>
</directory>
YellowPages
Das yp ist eigentlich nicht viel mehr als ein kleines CGI-Programm. Daher braucht man einen Webserver, der auch cgi-Programme ausführt. Auf den meisten Servern sollte Apache2 schon installiert und konfiguriert sein (wenn nicht hilft YaCy beim Finden einer Anleitung). Das yp gibt es garnicht als Debian-Paket, daher ist wieder selbstkompilieren an der Reihe. Erst die benötigten Librabies libxml2-dev und libmysqlclient14-dev als Debianpakete installieren. Die libcgi muss wieder händisch installiert werden: Download, entpacken, Bug fixen (Datei libcgi-1.0/src/cgi.c öffnen, in Zeile 339, »13« gegen »14« tauschen), ./configure, make, make install. Dann erst ist yp selbst dran: downloaden - diesmal aus dem SVN: svn co http://svn.xiph.org/trunk/icecast2yp/, automake, ./configure, make. Dann erhält man ein paar Binaries, die ypcgi kopiert man in das cgi-Verzeichnis des Webservers, die entstehende URL (http://web.server.tld/cgi-bin/ypcgi oder ähnlich) trägt man dann in die Icecast Konfigurationsdatei ein. Für den nächstens Schritt braucht man einen laufenden MySQL-Server (das ist die erste Datenbank), der aber auch auf jedem Standardwebserver vorhanden sein sollte (wenn nicht, hilft wieder YaCy). Dort braucht das yp einen User und eine Datenbank. Als kleinen Test kann man yp_cgi einfach auf der Konsole starten, wenn dann eine Meldung wie »YPResponse: 0« »YPMessage: No action specified« kommt, sollte alles wie gewünscht funkionieren.
Jetzt kann man schoneinmal einen kompletteren Test durchführen und einen Stream an den Icecast legen. Wenn alles geht, wie es soll, sollten sich jetzt die Tabellen in der MySQL-Datenbank mit Daten füllen.
Tabelle auf der Webseite
Diese Tabelle wird einfach mit PHP dynamisch aus den MySQL-Tabellen gelesen, nach Servern sortiert, die Hörer ein wenig addiert und dann ausgegeben. Der komplette Source der Seite ist am Ende verlinkt.
rrd und Grafik
Die Round Robin Datenbank speichert immer eine bestimmte Anzahl von Datensätzen, wenn die erreicht ist, werden die ältesten wieder überschrieben. Weitere Details der Funktionsweise der rrd findet man in Artikel des Linuxmagazins oder in der Dokumentation zu den rrdtools. Ich habe bei dieser Übersicht die Anzahl so bestimmt, dass die Datenbank einen Zeitraum von fünf Stunden abdeckt. Die Round-Robin-Datenbanken werden von einem Perlscript, das die Daten aus der MySQL-Datenbank ausliest, gefüttert. Dabei wird für die Hörerzahlen eines Streams jeweils eine Datenbank genutzt. Die Datenbanken an sich sind einfache Dateien, die sich an beliebigen Stellen im Dateisystem ablegen lassen. Ich habe als Dateinamen für die einzelnen Datenbankdateien jeweils die md5sum der Streamurl gewählt, weil man damit allen Problemen mit Sonderzeichen im Dateinamen aus dem Weg geht. Die Zuordnung zwischen den vorhandenen Dateien, den MD5-Summen und den Streamurls übernimmt eine XML-Datei. Für neue Streams werden automatisch neue Datenbanken und Einträge in der XML-Datei erzeugt. Die Farben für die Graphen und die Kästchen in der Tabelle werden mit Trick 18 bestimmt: es wird wieder die MD5-sum der Streamurl bestimmt und dann nimmt man einfach die ersten sechs Zeichen der MD5sum und hat einen Farbbezeichner, der als HTML-Farbangabe geeignet ist.
Dateien:
Wenn ich versuche meinen Server oder meine Desktopcomputer funkionell etwas zu erweitern, habe vorher meist eine ungefähre Idee, was ich wie machen will. Bereits nach sehr kurzer Suche stellt sich aber dann oft heraus, dass es das Gesuchte entweder überhaupt nicht gibt, es dafür einen Entwurf für einen Standard gibt, jemand anders hat sich da schon vor 2 Jahren Gedanken drüber gemacht und etwas dazu geschrieben, aber es läuft mit heute aktueller Software nicht mehr oder das ganze endet darin, dass man das gesamte System neukompilieren muss.
Als erstes Beispiel will ich das Mailsystem nehmen: Da ich mich nicht wirklich für einen Client entscheiden kann - Ich wechsle immer zwischen mutt, IlohaWebMail (PHP-Webmailer) und irgendwas grafischem GTK-basiertem - nutze ich IMAP. Das klappt für die Mails an sich super, aber schon bei so simplen Sachen wie dem ändern des Passwortes hat sich nicht einmal ansatzweise so etwas wie Lösung durchgesetzt.
Weiter geht es mit dem serverbasiertem Sortieren der Mails. Das geht solange sehr einfach, wie jeder Nutzer Shellzugang hat und in der Lage ist die .procmailrc selbst zu schreiben. Nun habe ich aber aber die ganze Mail-Verwaltung in einer MySQL-Datenbank, damit ich keine Shell-Konten brauche. Ich suche also eine Lösung mit der ich die FIlterregeln in einer MySQL-Tabelle speichern kann. In meinem jetzigen Setup (Postfix, Courier-IMAP, amavis) wäre Maildrop dafür zuständig. Alles was ich zum jetzigen Zeitpunkt gefunden habe, ist, dass Maildrop zwar mit User in MySQL-DB's klarkommt, aber die FIlterregeln weiter in normalen Dateien braucht. Aber selbst wenn man es schaffen sollte, dass Maildrop mit den Regeln aus MySQL arbeitet bleibt das Problem, dass man diese nur via Webinterface und nicht etwa über den Mailclient ändern kann.
Beim Thema E-Mail gibt es natürlich recht viele weitere Themen. Beispielsweise das Adressbuch, das auf dem Server liegen soll und von allen Clients nutzbar sein soll. Da gibt es mit LDAP natürlich eine Lösung, die für mich aber völlig oversized ist. Eine simplere, bsp WebDAV-basierte Lösung habe ich nicht gefunden. Weiter geht es bei Kalendern/Terminplanern. Da sieht es etwas besser aus. Da scheint das von Apple entwickelte iCal ein recht verbreitetes und akzeptiertes Standardformat zu sein. Es gibt auch schon einen Entwurf für einen Standard für das Verwalten von iCal-Kalendern über WebDAV, der aber anscheinend noch nicht in ein Apache-Modul umgesetzt wurde. Die meisten Kalender unterstützen zumindest das Importieren von iCals über HTTP, beim Export über WebDAV sieht es wieder sehr duster aus.
Weiter geht es beim Browser: Es geht wieder darum, Daten per WebDAV zentral zu speichern. Es gibt eine Extension für Firefox, die die Bookmarks als xBel per WebDAV exportieren kann. Nur leider lädt es immer die gesamte Datei hoch und wieder runter, was den Browserstart/das Beenden merklich verzögert und es erlaubt natürlich auch kein zeitgleiches Arbeiten an mehreren Browsern. History oder Cookies sind aber weiterhin auf den verschiedenen Computern verschieden.
Wieder zum Server: Wenn man mehr oder weniger fremden Leuten Zugriff per WebDAV erlaubt, möchte man natürlich auch eine Quota setzen. Wie schon zu erwarten gibt es dazu einen Entwurf und sogar schon ein RFC für die Protokollerweiterung, aber wie auch zu erwarten noch keine umsetzung in das Apache-Modul.
Zumindest bei den WebDAV-Server-Problemen bin ich zuversichtlich, dass sich da in Zukunft einiges bewegen wird. Die Kalender/Adresssachen sind bei den meisten großen Groupwaresuiten - meistens als Insellösungen - schon implimentiert, so dass ich da nicht so sehr sicher bin, ob sich da noch was ändern wird.
Da ich irgendwie unzufrieden mit der Auswertung der Apachelogs bin (Shortstat - ein Plugin für Wordpress - ist zwar für den Überblick geeignet, hat aber keine Grafiken; webalizer macht zwar mehr oder weniger schicke Grafiken, ist dafür aber nicht Realtime) und ich wiedermal ein wenig frickeln wollte, dachte ich mir, dass es doch nicht schlecht sei, Apache die Logs direkt in einer Datenbank (MySQL) ablegen zu lassen.
Nach ein wenig suchen fand ich dann mod_log_sql. Es gibt sogar jemanden, der sich schon die Mühe gemacht hat, Debian-Pakete zu schnüren. Leider stand das dort: If you are using MySQL 4.1, you have to recompile it yourself otherwise apache will segfault.
. Eben genau diese Version verwende ich 
Als kleine Geografieaufgabe stand dort noch das: Use the closest mirror next to you (florida or singapore)
. Muss ich eben noch warten bis es passende Pakete gibt ...
Nachdem ich das mal lokal ausprobiert hatte, habe ich heute also auch hier auf Wordpress 2.0 geupdated. Was an der neuen Version am auffälligsten ist, sind zum einen der WYSIWYG-Editor für Beiträge und Seiten und die stark verbesserte Unterstützung für Uploads und Bilder. Uploads kann man nun direkt unter dem Editor machen und Bilder samt automatisch erstelltem Vorschaubild einfügen. Auch unter der Haube scheint sich einiges getan zu haben. Mein Theme läuft jetzt nach einer kleineren Anpassung auch ohne Änderungen am Wordpressquellcode.
Auch am Theme selbst habe ich einige kleinere Änderungen vorgenommen. Jetzt stehen der erste und letzte Eintrag in der dunkelblauen Navigationsleiste ganz am Rand und die Rundungen verändern beim Hover jetzt auch die Farbe (nur bei standardkonformen Browsern natürlich) und dann hab ich in der Seitenleiste noch die Listenstruktur etwas listenartiger gemacht.
Zum Schluss hab ich dann noch das Statistikplugin ShortStat installiert, weil ich einfach keine Lust mehr hatte die apachelogs mit grep zu bearbeiten oder irgendwas anderes einzurichten 
Beim Notebook gibt es nicht viel Neues. Eine unverschlüsselte WLAN-Verbindung habe ich aufbauen können, der Monitor Mode mit kismet funktioniert auch. Beim Sound bisher auch nichts Neues, ich hab mir daher mal einen USB-Soundstick bestellt (Soundkarte für den USB-Port). Der "Designed for Windows XP"-Aufkleber ziert jetzt nicht mehr mein Notebook, sondern meinen Taschenrechner. Einfach mit einem Fön etwas erwärmen - nicht zu stark, weil direkt darunter die Festplatte ist - und dann zum Beispiel mit einem FIngernagel oder was ähnlichem (Achtung Kratzer) druntergehen und anheben. Bei bog sich zunächst nur eine kleine Ecke hoch - den Rest habe ich dann mit einer Zange abgezogen. Der Aufkleber an sich scheint aus irgendeinem Metall zusein und ist nebenbei bemerkt die beste Qualitätsarbeit die ich je von Microsoft gesehen habe.