Svens Netzblog

Woran macht man fest, ab wann wirklich und endlich Frühling ist?

Ich für meinen Teil an dem Moment, an dem ich die kurzärmligen Hemden aus dem Schrank hole.

Und dieser Tag war heute.

(Der Tag, an dem das erste Mal gegrillt wurde, gilt bei mir nicht, da ich durchaus schon zu Silvester am Grill stand.)

Zuerst dachte ich daran, mir einen WRT54G zu kaufen, der für das gleiche Geld wie ein WAP54G nicht nur Accesspoint-Funktionen bietet, sondern auch gleichzeitig noch ein Switch und ein DSL-Router ist.

Nachdem wir in der Fachschaft allerdings beim Einrichten des WRT54GS auf so starke Probleme gestoßen sind, wollte ich nicht auch noch Versuchskaninchen spielen und habe mir einen WAP54G zugelegt.

WPA (derzeit noch im PSK-Modus mit CCMP-AES, bald allerdings mit WPA-Radius) war schnell eingerichtet, die wpa_supplicant.conf auf meinen Laptop ebenso schnell erweitert und derzeit kopiere ich lustig Sarge-ISO-Images via WLAN durch die Gegend und erfreue mich an der für 54MBit/s erwartungsgemäßen Geschwindigkeit von knapp 4.8MByte/s (und ärgere mich nicht über lausige 70KByte/s, wie wir sie mit den WRT54GS hatten).

In letzter Zeit hat sich hier so einiges aufgestaut, so daß ich überhaupt nicht dazu gekommen bin, bestimmte Dinge zu erledigen (Ja, du weisst, das du gemeint bist. Sorry.)

An anderer Front komme ich hoffentlich in den nächsten Tagen einmal dazu, zusammen zu fassen, was sich an der "EAP-TLS mit Freeradius und LDAP"-Front verändert hat, denn mittlerweile habe ich ein laufendes Setup, das ich einmal beispielhaft zitieren kann um somit sicherlich einigen Leuten zu helfen, die derzeit ähnlich verloren in den Tiefen des ganzen Protokollwirrwars herumstochern und daran verzweifeln, weil kein Land in Sicht ist.

Also einen Moment Geduld noch.

Lord of the Net MPEG, 36MB

Ein witziges Video von Novell versus das Böse im Netz und der Welt.

Update: Das ganze wurde auf der Brainshare 2004 präsentiert. Das originale Video, plus noch weitere von vergangenen Events, findet sich auf dieser Seite.

And in other news: Hello to Novell UK! Hey, guys, please don't use my bandwidth, but download the video from your very own site. Thank you!

Wer schon einmal selbst Debian-Pakete gebaut hat oder einfach nur Pakete aus einem Release für ein anderes zurück- oder vorwärts portieren musste, kennt die Probleme, die da auf einen zukommen:

• build-dependencies fehlen, d.h. man müßte den Kram erst ins eigenen System installieren, selbst wenn man ihn zum Betrieb nicht braucht. Evtl. gibt es sogar Konflikte mit der bestehenden Konfiguration.
• Aus Versehen entstehen beim Kompilieren Abhängigkeiten zu Paketen, die gar nicht gewollt sind.
• Man übersieht Abhängigkeiten, die im eigenen System zwar erfüllt sind, die aber wegen mangelnden Einträgen in debian/control auf anderen System nicht automatisch erfüllt werden.

Alles in allem sehr nervig und zeitraubend.

Geschickter ist es da schon, sicht eine chroot-Umgebung zu erzeugen, in der man dann die Pakete bauen kann. Allerdings muss man hierbei auch peinlich darauf achten, das diese immer "sauber" ist, damit man sich nicht wieder unerwünschte Abhängigkeiten erfängt. Noch dazu muss man vor der Kompilation auch hier alle build-dependencies manuell erfüllen.

Das dies einfacher geht, zeigt pbuilder.

pbuilder erzeugt eine chroot-Umgebung mit der gewünschten Debian-Distribution als Inhalt, hält sie auf dem aktuellen Stand und sorgt dafür, das nach einer Kompilation keine Reste mehr liegen bleiben.

Unerwünschte Abhängigkeiten werden so vermieden, fehlende schnell gefunden, und durch Benutzung von --use-pdebuild-internal verhindert man effektiv, dass das Host-System mit Paketen zugemüllt wird, die nur zum Erstellen eines Debian-Paketes benötigt würden.

Oh Wunder der modernen Preisgestaltung.

Kann mir einmal jemand verraten, warum ein WRT54G ebensoviel (bzw. nur geringfügig [im Sinne von wenige ¤] mehr) kostet wie ein WAP54G?

Ich meine, das erste ist ein WLAN-Router mit 4-Port-Switch, VPN-Fähigkieten, DSL-Anschluss, "Firewall" und anderem Pipapo und das zweite ein einfacher Access-Point.

Irgendwie geht die Rechnung da für mich nicht auf.

Wenn ich mir so ein Teil zulegen wollte (was ich auch vorhabe, nächsten Monat), dann würde ich doch eher den WRT54G nehmen, man weiss ja nie, wann man doch einmal einen echten Router braucht (der auch noch RIP1/2 spricht, so man das braucht), vor allem, da man auf der Hardware auch ein eigenes Linux laufen lassen kann, so man möchte.

Ich durchblättere nun schon eine ganze Weile die Datenblätter, aber ich finde den Haken nicht.

Man kläre mich bitte auf.

Nach langen Mühen habe ich endlich herausgefunden, warum bei mir das Serendipity-Update nicht funktionierte:

Ich hatte noch PHP 4.1.2 installiert, welches scheinbar "true" und "false" noch nicht kennt, welche aber von Serendipity sehr häufig benutzt werden, z.B. in einer Abfrage IS_up2date === false, welche unter PHP4.1 nicht korrekt ausgewertet wird, so daß der Updater nie aufgerufen wurde.

Jetzt ist das System auf Sarge geupdated (ja, ich weiss, ich weiss) und meine Update-Probleme sind weg.

Ich glaube, diese Info sollte dringend in die Release-Note aufgenommen werden, denn dort finde ich nirgends eine Information bzgl. der benötigten PHP-Versionen.

Ich habe bis gerade versucht, mein Serendipity von 0.7.1 auf das gerade erschienene 0.8 zu updaten. (Diese Entscheidung war um ca. 1 Uhr.) Nachdem die Upgrade-Anleitung ja versprach, das dies sehr einfach wäre (nur entpacken, ein paar Rechte kontrollieren, Einloggen, fertig.) dachte ich mir, das ich dies ja "mal eben" machen könnten, um dann recht bald auch das Bett aufsuchen zu können.

Pustekuchen.

Entpacken und Rechte kontrollieren war ja noch einfach. Danach nur noch wieder den Blog-URL aufrufen, ins Admin-Interface einloggen und ich sollte fertig sein.

Sollte, denn bis zum Admin-Interface kam ich gar nicht, denn mich der folgende Fehler etwas unvorbereitet:

SELECT * from serendipity_plugins WHERE placement = 'event' ORDER BY placement, sort_orderQuery failed:
SELECT

e.id,
e.title,
e.timestamp,
e.comments,
e.exflag,
e.author,
e.authorid,
e.trackbacks,
e.isdraft,
e.allow_comments,
e.last_modified,

a.realname AS author,
a.email

, e.body, e.extended

FROM
serendipity_entries AS e
LEFT JOIN serendipity_authors a
ON e.authorid = a.authorid
LEFT JOIN serendipity_entrycat ec
ON e.id = ec.entryid
LEFT JOIN serendipity_category c
ON ec.categoryid = c.categoryid

WHERE isdraft = 'false' AND e.timestamp <= '1113706352'
GROUP BY e.id
ORDER BY timestamp DESC
LIMIT 15
/ Unknown column 'a.realname' in 'field list'

WTF?

In den Foren findet sich dieser Fehler nur bei einem früheren Beta-Upgrade, mit dem passenden SQL-Code dabei, den man ausführen soll, damit dies ausgebügelt wird.

ALTER TABLE serendipity_authors ADD realname VARCHAR(255) NOT NULL FIRST;
UPDATE serendipity_authors SET realname = username;

Aber wozu soll ich jetzt SQL-Code ausführen? Dafür ist doch das Upgrade da, das ich ja gerade durchführen wollte.

Aber nun gut, tun wir ihm den Gefallen.

Danach sehe ich wieder mein normales Blog, kann den Admin-Link anklicken, mich einloggen und ... es passiert gar nichts. Kein Upgrade-Script, keine Ausgabe, das etwas passiert ist, nicht einmal die Versionsnummer ändert sich.

Hä?

Auch dieses Fehlerbild findet sich im Forum, dort wurde scheinbar das Archiv nicht korrekt entpackt. Aber ich habe alles korrekt gemacht bei mir, im /blog/-Verzeichnis findet sich ein lustiger Mischmasch aus 0.7.1 und 0.8, welcher ja vom Upgrade aufgeräumt werden sollte. Auch sind alle Dateien aus dem tar-ball da, wo sie sein sollen und zwar mit den Rechten, die sie haben sollen.

Und das ist jetzt die Stelle, an der ich aufgebe (Immerhin zeigt die Uhr gerade 5:18. Nur gut, das heute Sonntag ist.). Von PHP habe ich zu wenig Ahnung, um dort richtig Debuggen zu können, ich kann lediglich sagen, das IS_up2date eine "0", also FALSE zurückliefert, aber Auswirkungen auf die Ausführung von /include/admin/upgrader.inc.php hat dies irgendwie nicht.

Bitte, jemand sage mir, das ich nicht wieder der einzige Depp bin, der auf irgendeinen obskuren Fehler hereinfällt.

Der South Park Avatar Creator dürfte ja recht weit bekannt sein. Daher verliere ich nicht viele Worte und lasse lediglich ein Bild sprechen:

Spiele wie "Battle Isle", "History Line" oder auch "Panzer General" dürften recht vielen Leuten bekannt sein. Und leider auch den Mangel an neuen Spielen nach diesem Spielprinzip.

Derzeit muss halt alles 3D und Echtzeit sein, schnelle Kost, die nur dadurch schwer wird, weil man mit Maus und Tastatur nun einmal nicht so schnell agieren kann, wie der Computer seine Übermacht über die Spielkarte rollen läßt.

Um so mehr war ich erfreut, als ich The Battle for Wesnoth gefunden habe.

Wesnoth ist ein rundenbasiertes Open-Source Strategie-Spiel, angesiedelt in einer Welt mit Orcs, Elven, Menschen und anderen Gruppen. Es bietet dabei viele Kampagnen und Szenarios und ist dank Editor einfach erweiterbar. Kompatibel ist es dabei zu nahezu allem, was man so an Betriebsystem finden kann: GNU/Linux, Windows, MacOSX, BeOS, Solaris, FreeBSD, OpenBSD und NetBSD. Und dabei sieht es auch noch gut aus:

Einheiten sammeln während Kämpfen Erfahrungspunkte und steigen bei erreichen einer bestimmten Anzahl in die nächste Stufe auf. Tageszeiten-Wechsel haben Einfluss auf die Kampfstärke, je nach Gesinnung.

Jede Einheit hat ihren eigenen Namen und gewisse Eigenschaften, wodurch man nicht ein Heer an anonymen Kämpfern durch die Lande bewegt, sondern man findet mit der Zeit eine Art von Bindung zu seinen Helden, die man langsam aufpäppelt und zu Elite-Einheiten hernzüchtet.

Konsequenterweise kann man auf der nächsten Karte einer Kampagne die Kämpen aus den vorherigen Missonen (gegen einen Obulus) wieder übernehmen und in weiteren Schlachten weiter verbessern.

Und wem das Spielen alleine zu eintönig ist, der loggt sich auf einem Multiplayer-Server im Internet ein und spielt und chattet mit und gegen andere.

Meine Meinung: Macht süchtig! Ausprobieren!

Es ist zum aus der Haut fahren. Mein persönliches Drama mit OpenLDAP und der Stabilität:

1. OpenLDAP 2.1 mit ldbm-Backend

Das Teil hat ab und zu Probleme und läßt keine Schreibzugriffe mehr zu, funktioniert aber sonst lesend ohne Probleme. D.h. die bisher vorhandene Check-Infrastruktur (Nagios und Co.) haben nichts gemeldet, wenn das Problem auftrat.

OK, das ldbm (unter Debian mittels der db4.2 im Kompatibilitäs-Modus realisiert) Locking-Probleme hat und noch dazu absolut grottig lahm ist, ist ja bekannt. Allerdings kann ich mit OpenLDAP 2.1 kein bdb-Backend einsetzen, weil a) ich Aliase brauche und b) bdb mit 2.1 nicht stabil funktioniert, Stichwort "sched_yield()".

2. OpenLDAP 2.2 mit bdb-Backend (DB4.2.52+patches)

Schon besser, Abfragen sind deutlich schneller, Schreibzugriffe sogar um zwei Größenordnungen. Und das sched_yield()-Problem ist auch beseitigt.

Theoretisch.

Bisher habe ich die Erfahrung gemacht, dass die DB4.2 eine echte Mimose ist, Logging hin, Transaktionen her. Und viele der über DB_CONFIG einstellbaren Parameter lassen sich nicht zur Laufzeit ändern, sonder ich darf mit slapcat die ganze Datenbasis exportieren, DB_CONFIG anpassen und mittels slapadd den Kram wieder importieren. (Das habe ich jetzt bei der Suche nach Debian Bug #303057 schon gut 20 Mal hinter mir.)

Mittlerweile sieht meine DB_CONFIG damit so aus:

set_cachesize           0       252428800        0
set_lk_max_objects      100000
set_lk_max_locks        100000
set_lk_max_lockers      100000
set_lg_regionmax        1048576
set_lg_max              8388608
set_lg_bsize            2097152
set_lg_dir              /var/lib/ldap/logs/
#set_lk_detect DB_LOCK_DEFAULT
set_tmp_dir             /tmp/
#set_flags DB_TXN_NOSYNC
#set_flags DB_TXN_NOT_DURABLE

(Die letzten beiden Zeilen sind nur für slapadd relevant, damit dabei keine Logs geschrieben und Transaktionen geschrieben werden, wodurch die Prozedur in nur 90 Sekunden statt 400 Sekunden abläuft.)

Bisher hatte ich set_lk_max_lockers auf dem Default-Wert von 1000, aber damit trat der sched_yield()-Loop wieder auf (der eigentlich gefixt sein sollte, schon seit "Ewigkeiten").

Bisher sieht alles auf meinen 8 Replikaten soweit gut aus, keine Lockups mehr, keine kaputten Datenbanken, auch bei ärgster Folter unter Höchstlast.

Ich klopfe auf alles Holz, was ich finde, das es das jetzt gewesen ist.

Natürlich stelle ich die Werte für die Lock-Relevanten Einträge wieder auf vernünftige Werte herunter, was mir db_stat -c ja glücklicherweise verräte, aber derzeit soll der Krempel erst einmal einfach nur laufen und nicht alle 24h nach der Mama brüllen.

Und eigentlich sollte der slapd ja auch den Fehler brauchbar abfangen, wenn das bdb-Backend ein Problem hat, aber ... naja, lassen wir das.

BitMover, die Hersteller von BitKeeper, dem derzeit u.a. von Linus Thorvalds für den Linux-Kernel benutzten Versions-Verwaltungs-System hat angekündigt, Bitkeeper ab sofort nur noch unter einer ausschließlich kommerziellen Lizenz zu vertreiben.

Die bisherigen auf bkbits.net gehosteten Projekte, allen voran der Linux-Kernel und Projekte in seinem Umfeld bleiben dort erhalten und es ändert sich nichts an ihrem Status. Allerdings wird mit dem 1. Juli 2005 der Support für die frei verfügbare Version von BitKeeper eingestellt.

Ich erwarte wieder reichlich Flame-Threads auf der LKML, wie jedes Mal, wenn das Thema BitKeeper versus Subversion und GNU Arch an der Tagesordnung war. Allerdings dürfte es diesmal nicht mehr darum gehen, warum Linus denn ausgerechnet BitKeeper nutzen musste, sondern vielmehr darum, welches Nachfolge-System an dessen Stelle treten soll.

Mittlerweile hat sich Linus zu Wort gemeldet:

NOTE! BitKeeper isn't going away per se. Right now, the only real thing that has happened is that I've decided to not use BK mainly because I need to figure out the alternatives, and rather than continuing "things as normal", I decided to bite the bullet and just see what life without BK looks like. So far it's a gray and bleak world

Einer der Hauptgründe für diesen Schritt seitens BitMover liegt in einem Reverse Engeneering Versuch begründet, welches ein vom OSDL bezahlter Entwickler unternommen hat. Weiteres dazu lassen sich in einem Artikel auf Kernel Trap: No More Free BitKeeper nachlesen.

Zusätzliche Links: Heise Online: Source-Verwaltungssystem BitKeeper nur noch kommerziell
Slashdot: No More BitKeeper Linux

Debian bleibt sich treu und setzt eine alt"geliebte" Traditionen fort: Wie "üblich" vor einem Release, schwächelt einer der Haupt-Server des Projektes. Diesmal hat es gluck erwischt, ein bei HP gehosteter Login-Server für Debian Developer.

Martin 'Joey' Schulze schreibt dazu:

Unfortunately the /home filesystem (which contains /org) was broken and more filesystem checks were required. After this was done, we discovered that the filesystem has had permuted the association of files and filenames as well as their location. Sadly, we don't have the source of that permuting function, so we couldn't apply it's inverse function to the filesystem.

As a result of this damage, a lot of crap is in the filesystem. For example, binary Debian packages ended up in the CVS repositories, files that should be RCS files turned out to be gettext po files and the like. In an executive summary, the entire filesystem has been damaged and we experienced gross data loss.

Daran kann man wohl erkennen, das es mit Debian Sarge so langsam ernst wird.

Hiermit setze ich meine beliebte Saga "Sven gegen Freeradius und Libtool" fort.

Wie man schon hier und hier lesen konnte, kämpfe ich gerade mit Freeradius in sowohl Version 1.0.2 und CVS-HEAD auf Debian Sarge.

Das im ersten Teil dargestellte Problem #75 hat sich im aktuellen CVS-HEAD derweil gelöst, er kompiliert brav durch und hat dann auch alle Libraries/Plugins an der Stelle, an der man sie sich wünscht. Es ist allerdings immer noch eine CVS-Version, welche man nicht wirklich produktiv einsetzen will.

Derzeit hege ich ja noch Hoffnung, das 1.1.0 rechtzeitig zu Sarge fertig wird. Wenn es schon nicht in Sarge enthalten ist, dann doch bitte zumindest in einem Zustand, das ich die Pakete selbst bauen kann. (Was ich wegen dem Verlangen nach EAP und TTLS eh machen müßte.)

Für das zweite Problem dagegen, welches mit "undefined symbol: eaptls_process" in rlm_eap_peap-1.0.2.so zu tun hat, gibt es bisher allerdings nur einen Rat: "Update auf 1.1.0 aka CVS-HEAD".

Womit ich wieder am Anfang wäre. (Immerhin kompiliert der CVS-HEAD ja soweit, ohne das ich dabei Händchen halten muss.)

Seufz.