Tag Archives: Eisfair

Zurück im Jahr 2000 mit fli4l

Ich befinde mich gerade auf den Chemnitzer Linux-Tagen 2010 am Stand von eisfair und fli4l. Unser überaus schicker Standrouter1 ist ein sogenanntes WRAP Board, also schon bisschen abgehangen. Der Hersteller hat hier leider keine Pufferbatterie für die RTC vorgesehen, so dass die Uhr nach jedem Stromausfall am 1.1.2000 um 0:00 (UTC) losläuft.

Nun läuft selbstverständlich fli4l (in der aktuellen Version 3.4.0) auf der Kiste und dort gibt es das Paket (bei fli4l traditionell opt genannt) chrony, was eben chrony bereitstellt, einen kleinen Dienst um die Zeit über NTP abzugleichen. Den Sprung von 2000 auf 2010 möchte der aber nicht automatisch abgleichen, so dass hier ein manueller Eingriff erforderlich ist. Die nötige Prozedur ist leider nicht ganz selbsterklärend, daher hier das kurze HowTo, wie man dort vorgehen kann.

Schritt 1: Den chronyd mit den richtigen Optionen neu starten. Per default wird dort bloß -r gesetzt. Die Option -s erlaubt auch das Setzen der RTC über chrony. Also erstmal per ssh einloggen. Dann:

killall chronyd
chronyd -r -s

Schritt 2: Beim chronyd einloggen. Dazu gibt man auf der Shell einfach chronyc ein. Per default darf man dann erstmal fast nichts, aber man kann das vom Paketmaintainer hinterlegte Passwort eingeben, um mehr Rechte zu erlangen. Bitte wie folgt eingeben:

chronyc
password dummy

Schritt 3: Die Zeit setzen. Dazu erlaubt man sich das zunächst mal mit dem Befehl manual, dann setzt man die Zeit und dann sagt man ihm noch, dass er das auch der RTC verklickern soll. Beim Setzen der Zeit reicht es das auf eine Minute genau zu machen, den Rest erledigt chrony später ganz normal per NTP.

manual on
settime 2010-03-14 08:55

Bei der Eingabe von settime springt die von chronyd erzeugte CPU-Last auf über 90%. Nach einem weiteren Neustart von chronyd, ist die Zeit gesetzt, ich kann nicht sagen warum, aber der pragmatische Ansatz funktioniert hier. Also:

killall chronyd
chronyd -r -s

Jetzt passt schonmal die Systemzeit, ein rtcdata im chronyc zeigt aber noch die alte Zeit der RTC. Also führt man hier nochmal ein trimrtc aus. Die Änderung braucht ein paar Minuten um übernommen zu werden, das geschieht aber dann automatisch.

So, und jetzt wo die Zeit vom Messerouter richtig eingestellt ist, freuen wir uns auf den zweiten Tag hier. Gestern war es schon gut besucht und es waren viele freundliche Interessenten am Stand. Der Sonntag Morgen läuft etwas ruhiger an, da könnte man eigentlich nochmal einen Kaffee trinken …

Update: die so gesetzte Uhrzeit übersteht auch einen Soft Reboot. D.h. wenn man das WRAP hinter eine USV hängt, braucht man die ganze Prozedur nur einmal auszuführen! ;-)

  1. wo alle Besucher nur fragen, wo man die Hardware kaufen kann []

HowTo: CAcert Zertifikat für eisfair-Webserver

Der Apache-Webserver für eisfair kann selbstverständlich auch mit SSL umgehen. Das ist beispielsweise sinnvoll für alle Anwendungen, die man auf dem heimischen Server laufen lassen möchte und die Authentifizierung verlangen, damit die Passwörter, die über’s Netz gehen definitiv verschlüsselt sind. Auch die Inhalte wie beispielsweise die vom Webmailer bleiben der Öffentlichkeit lieber verborgen.

Wenn man bei CAcert angemeldet ist, liegt es nahe, sich auch für den eisfair-Server zu Haus ein passendes Zertifikat ausstellen zu lassen. Voraussetzung dafür ist folgendes:

  • eisfair-Server mit den installierten Paketen apache2 und certs
  • Account bei CAcert und genügend Punkte zum Erstellen eigener Server-Zertifikate

Sind alle Voraussetzungen erfüllt, geht man wie folgt vor. Zunächst ruft man auf dem eisfair-Server das Setup-Menü auf und geht ins Service-Menü von certs. Dort wählt man den Punkt Manage certificates. Daraufhin ändert man über 1 den key type auf web server. Als nächstes wählt man Punkt 10 (create a new key or select an exiting one [apache]), sonst schlägt der folgende Punkt fehl. Nun wählt man Punkt 11 (create certificate request), das verlangt CAcert nämlich später beim Erstellen des Zertifikats. Bei den Eingaben kann man sich weitestgehend an die Vorgaben halten. Wichtig: Als Common Name die Domain (FQDN) angeben, unter der der Server später erreichbar sein soll, beispielsweise www.example.dyndns.org, wenn man das später von draußen so im Browser eintippt, um den Heimserver zu erreichen. Als Challenge passwort gibt man einen einfachen Punkt ein.

Der Certification Request liegt jetzt unter /var/certs/ssl/csr/apache.csr. Den Inhalt dieser Datei benötigt man, um nun auf der Webseite von CAcert sein Zertifikat zu beantragen. Also kopiert man den Inhalt der Datei und loggt sich bei CAcert ein. Dort wählt man auf der rechten Seite Server Zertifikate und Neu. Nach einem langen, wichtigen Text gibt es unten ein großes Eingabefeld, in das man nun den Inhalt der Zwischenablage beziehungsweise den Certification Request einfügt. Anschließend auf Abschicken klicken, nochmal den Common Name gegenprüfen und nochmal Abschicken klicken.

Daraufhin zeigt die CAcert-Webseite das neue Zertifikat an. Das kopiert man und speichert es auf dem eisfair-Server in eine Datei mit der Endung .pem, beispielsweise www_example_dyndns_org.pem. Diese Datei kopiert man nun mit root-Rechten nach /var/certs/ssl/certs/. Anschließend ruft man ebenfalls mit root-Rechten einmal das Skript /usr/bin/ssl/c_rehash auf.

Mit einem aktuellen apache2 (probiert mit 1.3.4) wird man bei Aktivierung der Option APACHE2_SSL in der Konfiguration beim ersten Aktivieren einmal durch die komplette Zertifikat-Erstellungsprozedur geschickt, die genutzt wird, wenn der eisfair-Server selbst eigene Zertifikate ausstellt. Da wurstelt man sich einmal durch. Anschließend muss man dem Apache aber noch das CAcert-Zertifikat unterschieben. Wenn vHosts verwendet werden, gibt man den oben vergebenen Dateinamen einfach ohne Endung in der Variablen APACHE2_VHOST_?_SSL_CERT_NAME an. Verwendet man keine vHosts ist noch etwas Trickserei erforderlich. Der Apache erwartet das Zertifikat dann in /usr/local/ssl/certs/apache.pem bzw. (da /usr/local/ssl nur noch ein Symlink auf /var/certs/ssl ist) /var/certs/ssl/certs/apache.pem.

Jetzt gibt’s mehrere Möglichkeiten: apache.pem mit der neuen Datei überschreiben, einen symbolischen Link mit dem Namen apache.pem auf die neue Datei setzen oder den entsprechenden Teil aus der neuen Datei im Editor kopieren und in apache.pem ersetzen. Die zweite Variante (root-Rechte):

cd /var/certs/ssl/
mv apache.pem apache.pem.bak
ln -s www_example_dyndns_org.pem apache.pem
/usr/bin/ssl/c_rehash

Anschließend den Webserver nochmal neu starten, fertig. Der Apache ist fortan über https://www.example.dyndns.org mit einem von CAcert signierten Zertifikat erreichbar.

eisfair-HowTo: richtig krasse Spam-Mails automatisch löschen

Spam, Spam, Spam, Spam und das jeden Tag. Mein Setup sieht derzeit so aus, dass auf meinem eisfair-Server das Paket mail installiert ist. Dies sammelt via fetchmail die Mails von meinen Mailkonten ein, jagt die durch ClamAV und durch SpamAssassin und verteilt die dann wahlweise auf mein IMAP-Konto oder zum User spam. Das funktioniert sehr gut, auch die false positive Rate des Spam-Filters ist traumhaft, ich kann mich an keinen einzigen in den letzten drei Jahren erinnern.

Nichtsdestotrotz kommen immernoch zu viele Spam-Mails durch. Peter vom Fli4l-Team wurde das bei derselben Software zu viel und kam im IRC mit folgender Lösung um die Ecke: alle Spam-Mails, die von SpamAssassin einen Score größer als 10 bekommen, werden direkt nach /dev/null verschoben, also unwiderruflich gelöscht. Als ich gestern die aktuelle Welle in meinem Spam-Ordner anrollen sah, hab ich beschlossen, das auch umzusetzen.

Mit eisfair ist das zum Glück spielend leicht. Man erstellt als root einfach eine Datei namens custom-systemfilter.rm_spam_mail im Ordner /var/spool/exim und übergibt die dann mit

chown exim:trusted /var/spool/exim/custom-systemfilter.rm_spam_mail

dem passenden Systemnutzer. Der Inhalt muss wie folgt aussehen:

# Exim custom filter
#------------------------------------------------------------------------------
if $h_X-Spam-Score: contains "++++++++++++"
then
    logfile /tmp/exim_filter_rm_spam.log
    logwrite "$tod_log To=$h_to Subject=$h_subject From=$h_from Id=$message_id"
    save /dev/null
endif

(Bei neueren Versionen des Pakets mail kann man die Datei direkt aus /usr/local/exim/examples kopieren.)

Dann geht man ins Setup-Menü, dort in die Konfiguration vom Paket mail und lässt die einmal neu durchlaufen. Das Paket erkennt die zuvor erstellte Datei und meldet folgendes:

adding custom system filter /var/spool/exim/custom-systemfilter.rm_spam_mail ...

Fertig, naja fast. Wer den Filter aufmerksam angesehen hat, erkennt, dass das Log erstmal provisorisch in /tmp/exim_filter_rm_spam.log landet. Eleganter ist es, das Logfile dahin schreiben zu lassen, wo die anderen Logfiles von exim landen, nämlich nach /var/spool/exim/log. Dazu ändert man den Pfad im obigen Beispiel entsprechend ab. Jetzt fehlt noch das logrotate dafür. Dazu kopiert man am besten /etc/logrotate.d/mail in eine neue Datei, beispielsweise /etc/logrotate.de/exim_filter_rm_spam. Diese Datei passt man nun an seine Bedürfnisse an, d.h. man schmeißt den Abschnitt für fetchmail raus, ändert die Pfadangabe für das Logfile und spielt dann noch bisschen mit den eigentlichen Einstellungen. Bei mir sieht das Ergebnis so aus:

#------------------------------------------------------------------
# Creation: 2009-07-07 alex
#------------------------------------------------------------------
/var/spool/exim/log/exim_filter_rm_spam.log {
    rotate 53
    weekly
#    compress
    missingok
    notifempty
    sharedscripts
    create 640 exim trusted
    postrotate
        /etc/init.d/mail -quiet reload exim
    endscript
}

Ich lasse in dem Fall recht viele wöchentliche Logfiles übrig und lasse die nicht komprimieren. Das ermöglicht eine einfache statistische Auswertung, wieviel Spam tatsächlich gelöscht wurde (auch wenn ich das noch nicht umgesetzt habe).

Mehr Infos über das eisfair-Paket gibt’s in der eisfair-Dokumentation im Abschnitt Mail-Package. Die Filter vom Mailserver Exim sind detailliert auf exim.org beschrieben.

Ach und wer erkannt hat, dass ich in meinem Filter die Mails erst ab einen Score von 12 wegwerfe und nicht wie Peter schon bei 10, bekommt ein Bienchen!

Freie Paketentwicklung für eisfair

eisfair ist grundsätzlich ein tolles Projekt. Die Idee ist toll, die Software ist toll und die Leute, die für das Projekt arbeiten auch. Neben reinem Eigenbedarf sind das alles Gründe, Zeit in das Projekt zu investieren. Aber es gibt immer zwei Seiten der Medaille und in solchen Projekten auch immer Sachen, die besser laufen könnten.

Ein Punkt, den ich persönlich bedauere ist die Offenheit des Projekts. Es hat sich historisch so entwickelt, dass es ein Kernteam von offiziellen Entwicklern gibt, diejenigen, die das Basis-System betreuen, das Kernel-Paket und diverse große Pakete wie Mail, Samba, MySQL, Apache usw. Das ist grundsätzlich erstmal nichts verkehrtes, man kann z.B. einfach nicht der ganzen Welt Schreibzugriff auf das zentrale Entwicklungs-Repository geben – Lesezugriff hingegen schon. Leider ist nicht nur dieses Repo der Öffentlichkeit verborgen, sondern es läuft auch viel Kommunikation an den öffentlichen Newsgroups vorbei. Dafür gibt es Gründe und die meisten Entwickler und Anwender sind mit der Situation so auch zufrieden.

Ich persönlich denke, dass ein öffentliches Repository (read-only ;-) ) und ein öffentlicher Bugtracker die Entwicklung und Popularität eines Projektes fördern, auch wenn die Entwickler dann möglicherweise mehr Zeit für Support aufbringen müssen und sie diese Zeit nicht für die Entwicklung zur Verfügung haben. Weil ich das so sehe und weil ich mit meinen eigenen Paketen natürlich machen kann, was ich will, gib es eben diese ab sofort frei – so frei wie in Freiheit und so frei wie in Freibier: http://www.lespocky.de/eisfair/

Jeder eisfair-Entwickler und -Nutzer kann also ab sofort meine Pakete nicht nur installieren, sondern den Quellcode auch abseits der Paketdateien direkt im Repository anschauen, auschecken, ändern, mir Patches schicken, Tickets anlegen usw. – wie man das von vielen anderen OpenSource-Projekten kennt. Ich weiß, dass ich keinen Ansturm erwarten darf und genau genommen erwarte ich eher, dass alles genauso ruhig abläuft wie vorher – aber es besteht die Möglichkeit und ich habe die leise Hoffnung, dass sich andere eisfair-Paketentwickler ein Beispiel nehmen und dem Projekt durch mehr Offenheit zu mehr Popularität und dadurch mehr Verbreitung, neuen Entwicklern und letztendlich mehr Qualität verhelfen werden.

:-)

HowTo: Migration von Subversion Repositories mit eisfair

eisfair-2 steht vor der Tür, ich erwähnte es bereits im letzten Jahr und auch dieses Jahr anlässlich des LinuxTag. Da es kein Upgrade von eisfair-1 auf eisfair-2 geben wird, muss man die Kiste mehr oder weniger von Hand migrieren. Wie man seine Subversion-Repositories umzieht, beschreibe ich in diesem Artikel.

Falls aktiv und häufig mit den Repositorys gearbeitet wird, sollte der erste Schritt darin bestehen, die Schreibrechte auf dem alten Server zu entziehen. Das einfachste ist, in der Subversion-Konfiguration die Variablen SVN_REPOS_?_ANON_ACCESS und SVN_REPOS_?_AUTH_ACCESS für das umzuziehende Repository auf ‘read’ oder auf ‘none’ zu setzen.

Dann folgt das Backup des alten Repositorys. Dies sollte man an dieser Stelle manuell anstoßen, weil man nicht sicher sein kann, dass nicht noch jemand nach dem letzten automatischen Backup was eingecheckt hat. Dazu wählt man im Setup-Menü den entsprechenden Punkt für das Backup und im folgenden Dialog aus einer Liste das entsprechende Repository. Danach läuft der Dump vom Repository durch. Wenn das abgeschlossen ist, wird beim Subversion Paket ab 0.5.0 dann der Pfad und Name vom soeben erstellten Backup angezeigt, den man sich merken sollte, um zu wissen, welche Datei man gleich auf den Zielrechner zu kopieren hat. Bei älteren Paketversionen muss man im Setup-Menü nochmal den Menüpunkt ‘List backup files’ auswählen. Das grad erstellte Backup steht wahrscheinlich ganz oben, im Zweifelsfall schaut man auf Datum und Uhrzeit, die im Dateinamen mit drin stehen.

Der nächste Schritt besteht darin, die Backupdatei auf den Zielrechner zu kopieren, auf dem man bereits das Subversion-Paket installiert hat. Um das Backup über das Setup-Menü wieder einspielen zu können, muss der Zielpfad für die Kopieraktion der in SVN_BACKUP_TARGET angegebene sein. Außerdem sollte man ein neues leeres Repository einrichten, in das gleich das Backup eingespielt wird.

Aus dem Setup-Menü des Subversion-Pakets wählt man dann den Punkt ‘Restore repository’. Aus der Liste wählt man das soeben neu erstellte leere Repository. Das war es schon. Jetzt nur noch den Nutzern die neue Adresse mitteilen und fröhlich mit dem umgezogenen Repository weiter arbeiten. Das ganze nochmal in Kürze:

  • altes Repo auf dem Quellrechner deaktivieren oder wenigstens die Schreibrechte entziehen, nicht löschen natürlich!
  • setup -> Administration of services -> subversion administration -> Subversion Administration Tools -> Subversion backup and restore -> Backup repository
  • gewünschtes Repo auswählen
  • bei Paket vor 0.5.x: List backup files, entsprechende Datei steht wahrscheinlich ganz oben, auf die Zeit achten, um von cron-generierten zu unterscheiden, hier: /mnt/data2/backup/svn/repos1-2008-09-24-095600.backup.bz2
  • ansonsten angezeigten Dateinamen des Backup kopieren
  • auf den Zielrechner kopieren in das Verzeichnis was dort bei SVN_BACKUP_TARGET angegeben ist
  • neues Repo anlegen auf Zielrechner
  • Restore repository: richtiges Backup-File aus der Liste wählen
  • das neu erstellte Repo aus der Liste wählen

eisfair-Nostalgie

Angeregt durch eine Diskussion im IRC-Channel von eisfair, ist mir gerade klar geworden, dass ich mich jetzt schon etwa 5 (in Worten: fünf) Jahre lang mit dem System auseinandersetze. Wie hat das also damals angefangen?

Es muss irgendwann im Jahr 2003 gewesen sein, dass ich eisfair zum ersten Mal installiert und ausprobiert habe. Das Projekt selbst lief da schon einige Zeit, das Archiv der Newsgroup wurde jedenfalls im November 2001 eingerichtet. Ich hatte zu Beginn des Studiums ja noch den alten Pentium 233 MMX von meinen Eltern als Rechner benutzt, 2003 erstand ich bei eBay dann das ASUS TUSL2-C mit Celeron 1400, über das ich hier bereits schrieb. Das wurde dann Arbeitsrechner und aus den Teilen vom Basteln mit dem Fli4l-Router waren so einige Teile übrig, woraus dann ein Zweitsystem zusammengesteckt wurde. Irgendwann fand dann eisfair den Weg auf dieses Testsystem, zunächst wohl für Webentwicklung oder Spielerei oder ähnliches. Damals war noch Kernel 2.2.x Stand der Dinge (für eisfair) und es gab auch keine Install-CD. Meinen Promise Ultra 66 bekam ich erst mit dem ersten Testkernel 2.4.23 und manuellem Anlegen von /dev/hde? zum Laufen, das base-Paket war glaube ich noch bei 1.0.3 oder so.

Anfang 2004 waren ein paar Freunde für eine kleine private LAN-Party zu Besuch. Ich spielte immernoch unter Windows 98 und der eine oder andere wird sich erinnern, dass es da mit vernünftigem Multitasking, noch dazu aus nem Spiel raus, nicht soweit her war. Mal eben zum ICQ-Client wechseln und zurück gefährdete massiv die Stabilität des Spiels, warum also nicht den ICQ-Client auf dem zweiten Rechner laufen lassen? Da eisfair nun ein Serversystem ohne grafische Oberfläche ist, kamen da nicht viele Clients in Frage, genau genommen nur einer: micq.

Die damals verfügbare Version hatte Probleme mit der damals aktuellen Version vom ICQ-Protokoll und so fragte ich den damaligen Maintainer vom micq-Paket, Roman Schließmeyer, nach einem Update:

ich habe im Moment leider keine Zeit um die Pakete zu pflegen, deswegen werde ich auch kein Update des micq Paketes durchführen. Wenn du magst kannst du das gerne übernehmen,

So kam dann eins zum anderen und am 12.04.2004 veröffentlichte ich mein micq-Paket in Version 1.0.1. Warum? Eigenbedarf! Genau darum ging es nämlich im eingangs erwähnten Chat. Eine der größten Antriebskräfte im Open-Source-Bereich ist Eigenbedarf. Das gilt für meine eisfair-Pakete ebenso wie für IMPULS und es gilt nicht nur für mich selbst. Viele Open-Source-Entwickler arbeiten an »ihrer« Software, weil sie sie selbst einsetzen und benutzen wollen. Natürlich ist das nicht der einzige Grund, aber ein sehr wichtiger, das sehe ich bei eisfair im Prinzip täglich. Das Zitat zeigt aber auch noch etwas anderes: eisfair ist ein reines Freizeitprojekt und Zeitmangel ist bei den Entwicklern praktisch obligatorisch – damals wie heute.

Ende 2005 bekam ich dann die Einladung dem frisch gegründeten Test-Team beizutreten, im letzten Jahr war ich zum ersten Mal auf dem Entwicklertreffen. Seit 2003 ist viel passiert in der Entwicklung, ich hatte ja schon an der einen oder anderen Stelle mal was angedeutet. Da ließe sich auch noch viel mehr schreiben, aber das hebe ich mir mal für einen späteren Beitrag auf. ;-)

eisXen und eisfair-2 auf dem Weg

Nachdem ich gerade auf eisfair.org die Ankündigung gelesen habe, dass die Release Candidates von eisXen und eisfair-2 offiziell veröffentlicht wurden, kann ich ja hier auch ein wenig drüber plaudern. Die wichtigsten Weichen wurden ja bereits im November gestellt und einige kleinere Punkte sind auch noch offen, aber wir haben gerade eisXen in den letzten Wochen um einiges voran gebracht und ich freue mich, dass es jetzt im Rahmen des LinuxTag 2008 endlich der weiten Welt vorgestellt wird. Da es »nur« ein RC ist, hätte ich die Wette mit Tux Weihnachten 2007 zwar immernoch verloren, aber ich denke mit dem Input von den Nutzern wird das Projekt jetzt wieder Fahrt aufnehmen. Die Entwicklungsumgebung für eisfair-2 ist auch fast fertig, so dass dann auch bald die Pakete folgen werden.

SME Server

Gestern kurz vor Feierabend wurde ich in ein Gespräch über Trac verwickelt. Im Institut laufen die Projekt-Repositories und die entsprechenden Bugtracker auf einem Linux-System mit der Distribution SME Server. Wissensdurstig wie ich bin, hab ich mich mal umgeschaut. Im Hinterkopf hatte ich noch einen Artikel aus der c’t 4/07, wo das System nicht so schlecht weg kam. Mittlerweile ist Version 7.3 aktuell und die Hardware-Anforderungen sind relativ niedrig. Genau genommen handelt es sich bei dem System um direkte Konkurrenz zu eisfair, nur mit Weboberfläche.

Runterladen des Installations-Images per Bittorrent war kein Problem und Testrechner stehen hier genug rum. Die Wahl viel auf den 700er Duron mit den zwei 20 GB Festplatten. SME Server reißt sich auch gleich beide unter den Nagel und richtet ein RAID 1 drauf ein. Bei der Installation konnte man sich auf der zweiten Konsole daher schön /proc/mdstat anschauen und sehen wie er die Arrays synchronisierte. Das ist auf jeden Fall ein nettes und sinnvolles Feature. Der Installer beschwerte sich auch nicht, dass die Platten nicht exakt gleich groß waren. Das kann der neue Installer von eisXen bzw. eisfair-2 noch nicht – ich werde das mal anregen.

Nachdem alle Dateien auf die Kiste kopiert waren, kam der Rechner beim Reboot bis zum Einbinden der Swap-Partition und blieb dann hängen. Schluss, Ende, das war der Test von SME Server. Nächster Kandidat im bunten Distributions-Hopping: DesktopBSD

LIRC für eisfair – eine Episode voller Rückschläge

Wie man auf Pack-Eis sehen kann, betreue ich das Paket »LIRC« für Eisfair. Wie bei climm und GnuPG bin ich 2005 aus persönlicher Notwendigkeit heraus in diese Rolle gerutscht. Mein Heimserver war damals für das Abspielen meiner Musik verantwortlich und eine Infrarotfernbedienung ist da Gold wert. Wie so oft im OpenSource-Bereich brachte ich das Paket auf einen Stand, der meinen Anforderungen genügte und beließ es bei einer längeren Liste mit Ideen und ToDos, die im Prinzip seit 2005 auf ihre Umsetzung warten – andere Dinge waren halt wichtiger.

Nun wurde kürzlich ein neues Kernel-Paket für eisfair-1 veröffentlicht: ein gepatchter 2.4.35. Wir haben im Testteam lange getestet bis er im März der Öffentlichkeit zum Fraß vorgeworfen wurde. Ein neuer Kernel bedeutet aber auch, dass LIRC neu übersetzt werden muss, da es seine Treiber selbst mitbringt und Kernelmodule nunmal zur Kernelversion passen müssen. Es gab auch schon die eine oder andere Anfrage in der Newsgroup und ich beschäftige mich seit ein paar Tagen mit einer neuen Version des Pakets.

Zunächst steht das Kompilieren an. Ich konnte LIRC 0.8.2 für die eisfair-Kernel 2.4.26-1 und 2.4.35-wt1 jeweils in den Versionen mit und ohne Unterstützung für SMP übersetzen – für 2.4.26 mit der alten Build-Umgebung mit gcc 2.95.3 und für den 2.4.35 mit der zukünftigen Build-Umgebung mit gcc 3.4.6, die zur Zeit vom Testteam getestet wird. Das Übersetzen von LIRC artet schnell in Arbeit aus, weil es mit einem Lauf aus ./configure, make und make install nicht getan ist. Das muss für jede Kernel-Version und jeden gewünschten Treiber einzeln gemacht werden, es sei denn, man kompiliert gleich alle Treiber. Tut man dies nicht, ist noch mindestens ein Lauf mit der Option --with-driver=userspace nötig, damit LIRC auch in der Lage ist mit verschiedenen Treibern gestartet zu werden und nicht nur mit dem, für den es kompiliert wurden, wie z.B. serial.

Also wie gesagt, ich konnte LIRC für die Treiber serial und atiusb kompilieren – das sind die beiden, wo ich selbst Hardware zum Testen habe. Dank VMware waren auch die verschiedenen Kernel kein Problem, ich hab einfach für jeden eine neue virtuelle Maschine angelegt. Die anfängliche Euphorie, dass auch ein LIRC 0.7.1 mit den aus 0.8.2 gebauten Kernelmodulen für 2.4.35 läuft, wich dann der ersten Enttäuschung. Ich hatte zunächst die Version, die mit allen Treibern laufen soll, mit --with-driver=none kompiliert. Das funktionierte logischerweise nicht. Der erste herbe Rückschlag: LIRC 0.8.1, 0.8.2 und 0.8.3pre1 lassen sich mit der neuen eisfair-Buildumgebung und der korrekten Option --with-driver=userspace nicht übersetzen, wie man auf der Mailingliste von LIRC nachlesen kann.

Man kann dort ebenfalls nachlesen, dass ich versucht habe, die neueste Version aus dem CVS zu übersetzen, wo dieser Fehler bereits behoben ist. Leider macht mir da die Buildumgebung einen Strich durch die Rechnung. Das Skript ./configure liegt nicht im CVS, sondern wird mit den autotools (autoconf, automake usw.) erst noch selbst erzeugt. In der Theorie funktioniert das gut, in der Praxis tritt bei mir leider der gleiche Fehler auf, den ich vor einiger Zeit schon hatte, als ich climm aus dem SVN bauen wollte. Es wird ein unbrauchbares Skript erzeugt, dass nur eine wenig hilfreiche Meldung ausgibt. Wenn sich jemand gut mit autoconf auskennt und eine Idee hat, wo da das Problem liegt, möge sie sich dringend bei mir melden! Fazit jedenfalls: LIRC aus CVS ist für mich nicht möglich.

Heute erreichte mich dann über die Mailingsliste von LIRC die überraschende Nachricht, dass gerade die 0.8.3pre2 rausgegeben wurde. Der o.g. Fehler tritt nicht mehr auf, dafür ein neuer. LIRC lässt sich nicht mehr mit dem Treiber serial übersetzen, weil in der entsprechenden Quellcode-Datei eine Header-Datei aus den Kernelquellen nicht gefunden wird. Zumindest wird sie bei den 2.4er Kerneln nicht gefunden. Ein flüchtiger Blick in den Quellbaum eines 2.6er Kernels offenbarte, dass es dort zwei Dateien io.h gibt, eine in /usr/src/linux/include/linux und eine in /usr/src/linux/include/asm – beim 2.4er Kernel gibt es bloß letztere.

Auch dies habe ich auf der Mailingliste von LIRC gemeldet und warte erstmal ab. Es gibt nämlich mehrere Möglichkeiten jetzt:

  • ich warte ab, bis die nächste LIRC-Version veröffentlicht wird, mit der ich alles korrekt übersetzen kann
  • ich baue das allgemeine LIRC und die Treiber für atiusb aus der 0.8.3pre2 und die Treiber für serial aus der 0.8.2
  • ich kann durch wundersame Eingebung oder Hilfe von außen den Fehler in der Buildumgebung finden, so es denn tatsächlich einer in dieser ist, und die aktuelle Version aus dem CVS übersetzen
  • ich gehe in den Versionen soweit zurück, bis ich auf eine stoße, die ich komplett übersetzen kann, das wäre dann wahrscheinlich die 0.8.0
  • ich behebe den Fehler in 0.8.3pre2 selbst und übersetze dann meine modifizierte Version

Ehrlich gesagt, gefällt mir die erste Version bisher am besten, allerdings könnte das unter Umständen noch eine Weile dauern, je nachdem wie schnell die Entwickler von LIRC die nächste Version rausbringen. Module aus verschiedenen Versionen wollte ich eigentlich vermeiden, um mir nicht eine zusätzliche Fehlerquelle aufzureißen. Auch eine alte Version finde ich nicht so cool. Ob wir den potentiellen Fehler in der Buildumgebung schnell finden, ist auch ungewiss, bleibt also im Grunde noch die letzte Möglichkeit: ich stöber durch den C-Code und beheb den Fehler selbst – dazu hab ich keine Lust…

Falls sich also jemand fragt, warum die neue Version des LIRC-Pakets für eisfair so lange braucht, ich weise sämtliche Schuld von mir und schiebe es auf höhere Gewalt!

Probleme in OpenSource-Gemeinschaften

Ich lese zur Zeit das Buch »Producing Open Source Software« von Karl Fogel. Er beschreibt aus Insidersicht was für Probleme in OpenSource-Projekten so auftreten und wie man diese von vornherein vermeiden oder später lösen könnte. Ich finde dieses Buch sehr interessant in Bezug auf die Projekte, wo ich persönlich beteiligt bin oder die ich intensiv verfolge (eisfair, IMPULS, climm). Viele Probleme sind da weniger technischer denn sozialer Natur und es gibt interessante Parallelen zwischen all diesen Projekten und den im Buch als Beispiel herangezogenen. Vom Glanz so erfolgreicher Projekte wie Subversion lässt man sich da nur allzu leicht blenden. Es ist vielmehr so, dass die allermeisten Projekte besser laufen könnten. Das ist mir am Wochenende beim Release von Eisfair 1.5.0 aufgefallen und gerade heute noch an anderer Stelle deutlich geworden, als Oliver von F!XMBR über seinen persönlichen Frust mit FreeBSD berichtet hat.

Ich will in Bezug auf Eisfair an dieser Stelle nicht ins Detail gehen, aber ich werde das für die Vorschläge, die ich diese Woche im Eisfair-Team machen will, berücksichtigen…