This feed contains pages in the "linux" category.
Wer telnet nicht mag, aber trotzdem im Detail sehen will, was passiert, dem sei swaks empfohlen.
Auf einem richtigen Linuxsystem ist es zwar auch kompliziert, das richtige Encoding einzustellen, aber meistens doch halbwegs intuitiv machbar. Bei OpenWRT sieht das allerdings ein wenig anders aus. Dort wird noch - aus Performancegründen - die ältere Samba-Version 2.0.irgendwas eingesetzt. Dummerweise gibt es erst ab Version 3 von Samba die Möglichkeit, die Encodings feiner einzustellen und UTF-8 zu verwenden.
Mein Setup sieht nach einigem herumprobieren also so aus, dass ich eine zwar unter Linux formatierte, aber unter Windows Vista befüllte (Vista wollte die Platte nicht selbst formatieren, warum auch immer ....) USB-Platte mit FAT32 an meinen Asus wl500gd angeschlossen habe.
Die Partiton der Platte habe ich dann ohne besondere Paramenter gemounted. (Ausprobieren hat aber ergeben, dass das "mount" von OpenWRT zwar die Option "utf8" akzeptiert und umsetzt, aber es nicht in der Ausgabe anzeigt.)
Anschließend wurden noch die Pakete "kmod-nls-cp850", "kmod-nls-iso8859-15" und "kmod-nls-utf8" installiert, wobei wohl nur die ersten beiden von Bedeutung sein dürften.
Die /etc/samba/smb.conf hat dann noch folgende Optionen verpasst bekommen:
client code page = 850 character set = ISO8859-1
und "schon" lief alles wie gewünscht.
Das installieren geht mit ies4linux inzwischen sehr einfach. Das wirklich interessante ist aber, dass man damit nicht nur die relativ aktuellen Versionen 5, 5.5, 6 und auch die Renderingengine der Version 7 parallel betreiben kann, sondern auch noch die Versionen 1, 1.5 und 2 bewundern kann. Allerdings musste ich feststellen, dass das heutige Web nicht mehr für so alte Browser zugänglich ist…
Da die offiziellen Pakete - aus welchem Grund auch immer - kein SSL/TLS haben, habe ich mir die halt selbst gebaut. Dabei habe ich nicht mehr gemacht, als die Revisionsnummer des Paketes etwas erhöht und das ganze neu kompiliert. Zum Installieren einfach folgende Zeile an die /etc/apt/sources.list anhängen:
deb http://download.xenim.de/ubuntu/ edgy/
sudo aptitude update; sudo aptitude upgrade, dann gkrellm einmal neustarten und schon kann man auch wieder den Mailstatus per imaps oder pop3s abfragen.
Damit die Warnung wegen nicht vertrauenswürdiger Pakete/Versionen verschwindet, kann man noch meinen GPG-Key zum apt-keyring hinzufügen:
gpg --recv-key 0x87463FA8; gpg -a --export 0x87463FA8 | sudo apt-key add -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:
Es hieß ja schon immer, dass SuSE das Linux sei, das Windows am nächsten kommt, aber das die .NET in der Linuximplementierung Mono für ihren Paketmanager nutzen, ist dann doch einen Schritt zu weit in die falsche Richtung. Gefunden hab ich das ganze über einen Userkommentar bei Heise (auch hier: http://www.osnews.com/permalink.php?newsid=14738&commentid=128737)
Ansonsten hab ich mir endlich mal eine Digicam zugelegt. Eine gebrauchte Canon Ixus 300. Das Bilder auslesen funktioniert mithilfe von gphoto2 und dem "camera:/"-Handler vom Konqueror recht bequem und zuverlässig.
Außerdem hab ich meine Ubuntuinstallationen auf Dapper geupdatet. Das heißt geupdatet hab ich nur meinen Desktop. Auf meinem Laptop hab ich aus reiner Neugier mal eine Neuinstallation gemacht (siehe diesen Kommentar). Bei einer anderen Installation mit teilweise bugiger Hardware (ein PCI-Slot zeigt anscheinend zufällige Device-IDs an) habe ich dann auch eine Neuinstallation gemacht, weil sich die Abhängigkeiten so sehr verknotet hatten, dass irgendwann garnichts mehr ging ...
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 es hier (großartige Linkbenennung, ich weiß) noch nicht so gut klappte, bin ich gestern anscheinend etwas strukturierter vorgegangen und dann ging es auch relativ gut. Aber noch mal Schritt für Schritt. Das Ziel ist, Videos über den Fernseher wiederzugeben. Nach ein wenig googlen kommt man über ein Howto zur Anleitung mit den entscheidenen Hinweisen.
Das ganze kompilieren kann man sich zumindest bei einer aktuellen Ubuntudistribution sparen - die nötigen Kernelmodule und Werkzeuge sind schon dabei. Im wesentlichen muss man die /etc/directfbrc mit Inhalten füllen. Bei mir waren das die Zeilen: »matrox-crtc2« und »matrox-tv-standard=pal«. Danach kann man schon mplayer mit passenden Optionen starten: »$ sudo mplayer -vo dfbmga -ao alsa -fs -zoom film.avi«
Bei mir gibt es noch kleinere Probleme mit der Verkabelung: Mein Fernseher ist so ein ganz altes Teil, das nur einen Antennenanschluß hat. Da man aber hier nur noch digitales terrestrisches Fernsehen (DVB-T) empfangen kann, musste ich mir noch einen Receiver dazu kaufen, der einen Antennenausgang hat und nebenbei natürlich dann auch noch einen Scarteingang. Bisher habe ich versucht den S-Video-Ausgang der Kabelpeitsche der Matrox über einen Adapter zu verwenden. Da erhielt ich aber nur schwarz/weiß-Bilder (auch unter einer testweisen Windowsinstallation). Erst als ich zwischen Grafikkarte und Scartadapter Composite (die mit den Chinch-Steckern) verwendete, erhielt ich auch Farben. Wie ich mir sagen ließ, sind die fehlenden Farben irgendwie durch falsch angedrahtete Kabel im S-Video-Scart-Adapter verursacht. Ich werd dann mal demnächst zum Fernsehtechniker meines geringsten Misstrauens gehen und mal fragen, ob der das richten kann.
Jetzt muss ich mich nur nochmal damit beschäftigen Mythtv auf dem TV-Out laufen zu lassen.
Im Bugtracking von Alsa wird eine Lösung beschrieben, wie auch die internen Lautsprecher und die Headphones-Buchse meines Acer Extensa 6702WLMi zum Leben zu erwecken sind. Ich habs natürlich gleich getestet und es funktioniert 