Unix

Achtung: Dieser Eintrag ist noch technischer als sonst und erschließt sich nur einem kleinen Teil von Debian-kundigen Personen.

Endlich. Lange habe ich darauf gewartet und musste bisher immer selbst die von apt abhängigen Pakete (vorweg die ganze python*-apt-Familie) rekompilieren, damit sie auf die experimentelle Version passten.

Aber jetzt endlich sehen meine verzückten Augen im changelog von apt 0.6.44:

* apt pdiff support from experimental merged

Das Gepfriemel hat für mich ein Ende und damit dürfte auch die Last auf die Mirror-Server abnehmen, wenn nur noch die Unterschiede zwischen zwei Paketdatenbank-Versionen übertragen werden müssen.

Heute, am Samstag, werde ich einmal den Linuxtag in Wiesbaden besuchen, mal schauen, auf wen man so alles trifft. Sicherheitshalber stecke ich ein paar Karten mit meinem PGP-Fingerprint ein, vielleicht ergibt sich ja die Möglichkeit für ein paar Keysignings.

An Vorträgen habe ich mir vor allem den über Xen 3 von Steven Hand vorgenommen, evtl., je nachdem, wie früh ich dort ankomme, schaffe ich ja auch den X Window-Vortrag von Egbert Eich.

Oder besser gesagt: Gar kein Zufall mehr. Oder anders gesagt: keine Entropie mehr übrig.

Nachdem ich mich jetzt schon länger wunderte, warum die Mails über meinen neuen Server nur tröpfelten und warum zwischen 8 und 9 gar kein Mailverkehr mehr aufgezeichnet wurde, bin ich dem Ganzen auf die Spur bekommen: OpenVPN und vor allem Exim saugen so stark am Entropie-Pool des Linux-Kernels, dass dieser sehr oft leer ist, was zur Folge hat, das alles Cryptographische nicht mehr richtig funktioniert.

Der Kernel bezieht einen seine Entropie aus Interrupts, die nicht vorhersagbar sind, z.B. von Maus und Tastatur. Ein Server im Rack hat aber selten Maus und Tastatur angeschlossen, also fällt diese Quelle weg. Dann werden die IRQs von Festplatten- und Floppy-Kontrollern ausgewertet, aber Floppy ist auch nicht und die Entropie vom IDE-Kontroller reicht nicht aus, um den Pool entsprechend gefüllt zu halten.

Was ist also zu tun?

Es gibt mehrere Lösungen, die beste davon ist natürlich ein Hardware-RNG (Random Number Generator), wie ihn manche Chipsätze anbieten, nur leider gibt es den bei mir auch nicht.

Dann kann man das Rauschen am Mikrofon-Eingang einer Soundkarte benutzen, aber eine Soundkarte ist auch nicht vorhanden.

Als weiteres kann man einfach künstliche IDE-Interrupts erzeugen, wie es z.B. regen-entropy.sh aus dem Debian-Exim-Wiki macht, allerdings erzeugt es eine recht hohe Last auf dem Server und ist nur als Notlösung zu betrachten.

Ich habe dagegen einen anderen, allerdings nicht weniger kritisch zu betrachtenden Work-Around implementiert, in dem ich SA_SAMPLE_RANDOM dem request_irq()-Call im vom Server benutzen Netzkarten-Treiber (e100 bei mir) hinzugefügt habe.

Natürlich bin ich mir bewußt, das ich damit eine Entropie-Quelle anzapfe, die von aussen kontrolliert werden kann, so daß hierbei die Zufälligkeit der Werte aus /dev/random negativ beeinflußt werden könnte, allerdings ist ein denkbarer Angriff hieraus doch eher theoretischer Natur, so daß ich den Vorteil, den ich daraus ziehen kann, höher bewerte als das dadurch mögliche Angriffmuster.

Hinter diesem arg sperrigen Namen verbirgt sich die (für mich als ISDN-User) größte Innovation im Debian-Paketmanagement seit langem.

Bisher durfte ich jeden Abend die mittlerweile knapp 3MB großen Packages.bz2-Dateien, welche die für die jeweilige Architektur verfügbaren Pakete auflistet, herunterladen. Da sich aber nur ein jeweils recht kleiner Teil ändert, überträgt man sehr viel Daten immer wieder, die eigentlich gar nicht übertragen werden müßten.

Die Idee zu einer Lösung, nämlich nur die Unterschiede zu übertragen, gab es schon länger, und Andreas Barth (mit Hilfe von Anthony Towns) implementierte einen ersten rohen Entwurf, damals noch als Shellscript.

Später dann stellte Michael Vogt eine APT-Version vor, die alles dies selbst konnte, allerdings die Nützlichkeit war noch eingeschränkt, da die Diffs zu den Paketdaten immer noch auf merkel.debian.org von Andreas Barth gepflegt wurden und nicht in den Haupt-Servern verfügbar waren, so daß man mit einer recht "wilden" Konfigurationsoption den Servernamen intern remappen mußte, damit das ganze funktionierte.

Dies hat sich mittlerweile geändert, und die Diffs stehen auch auf den normalen Debian-Servern bereit, so daß man nicht mehr auf irgendwelche Hacks angewiesen ist, das System funktioniert jetzt so, wie es gedacht ist.

Allerdings ist dies alles noch nicht offiziell verkündet worden und auch die derzeitge Version von APT (0.6.41) hat noch keinen Support für das partielle Updaten der Paketdaten, aber mit den modifizierten APT von Michael Vogt kommt man jetzt schon in den Genuss rasent schneller Updates für die Meta-Daten.

Dazu fügt man folgende Zeile in seine /etc/apt/sources.list ein:

deb http://people.debian.org/~mvo/apt/pdiffs/ /

Danach installiert man das modifizierte APT und sollte dann beim nächsten Update entsprechend wesentlich schnellere beim Updaten der Paketdaten sein. (Dabei kann es vorkommen, das die Geschwindigkeitsanzeige absolut falsch liegt, z.B. 300KB/s anzeigt, obwohl man nur ISDN hat. Das ist normal und nur ein kosmetisches Problem.)

Achtung: Dies alles bezieht sich nur auf die Paketdatenbanken, nicht jeden auf die Pakete selbst, diese müssen nach wie vor komplett heruntergeladen werden. Lediglich die Wartezeit bis man weiss, was man Updaten kann, wird dadurch verkürzt.

Update: apt-proxy-Benutzer müssen erst einen kleinen Patch anwenden, damit apt-proxy korrekt mit den Index-Dateien umgehen kann. Da Python auf whitespaces achtet, stelle ich den sehr kurzen Patch nicht direkt im Artikel zum Copy'n'Pasten, sondern im Download-Bereich im Debian-Unterordner zur Verfügung.

Update 2: Mit dem heutigen dinstall-Lauf ist apt-0.6.42.0exp1 in experimental eingetrudelt, welches einen Merge des Release 0.6.42 mit der Diffindex-Veränderungen darstellt.

Nachdem ich einen guten Tag damit zugebracht habe, darüber zu grübeln, warum flowscan nicht mit den von flow-capture erzeugten Daten spielen mochte:

Invalid index in cflowd flow file: 0xCF100103! Version 5 flow-export is required with all fields being saved.

habe ich Bug #327367 eingereicht, nur um festzustellen, das der Maintainer zwei gleichwertige Bugreports (#163227 und #239744) einfach mit der Bemerkung, das diese alten Bugs nicht mehr zutreffen wären, geschlossen hat.

Nachdem er nun schon mehr als 2,5 Jahre auf einem einfachen Bug sitzt und nichts getan hat, obwohl sogar ein Patch vorliegt, veröffentliche ich meine gefixten Pakete hier auf meiner Webseite.

Derzeit gibt es nur Pakete für Sarge-i386, da sich amd64 derzeit noch etwas ziert; dort muss ich erst dafür sorgen, das -fPIC benutzt wird, während libft.a erstellt wird.

Die Pakete finden sich im Downloadbereich, Kommentare sind natürlich ausdrücklich erwünscht.

Ich hoffe, das die Versionierung mit der Tilde so korrekt ist, da ich unbedingt verhindern wollte, das mein Paket ein Update über die offiziellen Kanäle behindert.

Die Pakete wurden mittels pbuilder in einer sauberen Build-Umgebung erstellt und sollten daher frei von unerwünschten Abhängigkeiten sein.

Update: Jetzt gibt es auch Pakete für Sarge-amd64. Ich habe dafür in lib/Makefile.in ein -fPIC an die AM_CFLAGS angefügt, weil mir das als die sinnvollste Stelle erschien. Man möge mich aber bitte korroigieren, wenn ich falsch liegen sollte (wahrscheinlich). Aber am Endergebnis ändert ein Fehler an dieser Stelle nichts, solange die Library mit -fPIC kompiliert wurde, funktioniert alles so, wie es soll.

Update²: Mittlerweile hat der Maintainer reagiert und den Bug wirklich behoben. Bis die gefixten Pakete auch im nächsten Point-Release von Sarge auftauchen, stelle ich meine Versionen weiterhin zur Verfügung.

Nahezu einen kompletten Tag habe ich jetzt, mit jeweils wachsender Verzweiflung, an einem komischen Bug im Umfeld der Debian Kernel-Quellen herumgesucht.

So ist es nicht möglich mit make-kpkg die aktuellen Debian Kernel-Quellen (2.6.12-5) inkl. des dazugehörigen Patch-Sets zu übersetzen, man erhält immer folgenden Fehler:

[...]
test -f applied_patches && rm -f applied_patches
make: [stamp-debian] Error 1 (ignored)
for patch in /usr/src/kernel-patches/all/2.6.12/apply/debian ; do            \
          if test -x  $patch; then                    \
              if $patch; then                         \
                  echo "Patch $patch processed fine"; \
          echo "$patch" >> applied_patches;   \
              else                                     \
                   echo "Patch $patch  failed.";      \
                   echo "Hit return to Continue";      \
           read ans;                           \
              fi;                                      \
  fi;                                          \
        done
E: Can't patch to nonexistent revision  (wait until 2006)
Patch /usr/src/kernel-patches/all/2.6.12/apply/debian  failed.
Hit return to Continue

Allein die Meldung "nonexistent revision" führt zu einigem Kopfkratzen.

Bis mir schließlich die Lösung durch ein diff zwischen den apply- und unpatch-Skripten aus der vorherigen Paket-Version (kernel-patch-debian-2.6.11) und der aktuellen (linux-patch-debian-2.6.12) in die Hände gefallen ist:

Aus irgendwelchen Gründen fehlt in der aktuellen Inkarnation (2.6.12-5) die Upstream-Version und die Debian-Version in den apply- und unpatch-Skripten (Zeile 158 bzw. 6) des Patch-Paketes, so daß make-kpkg komplett zerbricht.

Das ganze manifestierte sich nun also zu Bug#324583.

Nun bin ich einmal gespannt, wo genau nun eigentlich das Problem liegt, das zu den fehlenden Versionen führt.

Woran erkennt man einen Laptop, auf dem einmal Gentoo installiert war?

Kaum ist Debian Sarge released, geht es in Sid schon wieder rund. Viele neue und erneuerte Pakete strömen herein:

• Gnome 2.10
• PostgreSQL 8.0
• GCC-4.0
• OpenSSH 4.1 (endlich in Client- und Server-Pakete aufgeteilt)
• Perl 5.8.7

Dann bin ich einmal gespannt, auf welch kreative Art und Weise ich mein System dann in Zukunft zerpflücken kann.

Ja, genau deswegen benutze ich Sid auf meinen Heim-Systemen. Ich tanze eben gern auf der blutenden Kante. (Und ja, ich submitte Bugs, wenn ich sie treffe und niemand schneller war.)

Nach langem und und zähend Ringen ist Debian Sarge heute "stale" (sic!) geworden.

Aus dem Release Announcement:

This release includes a number of up-to-date large software packages, such as the K Desktop Environment 3.3 (KDE), the GNOME desktop environment 2.8, the GNUstep desktop, XFree86 4.3.0, GIMP 2.2.6, Mozilla 1.7.8, Galeon 1.3.20, Mozilla Thunderbird 1.0.2, Firefox 1.0.4, PostgreSQL 7.4.7, MySQL 4.0.24 and 4.1.11a, GNU Compiler Collection 3.3.5 (GCC), Linux kernel versions 2.4.27 and 2.6.8, Apache 1.3.33 and 2.0.54, Samba 3.0.14, Python 2.3.5 and 2.4.1, Perl 5.8.4and much more.

Ahja. "up-to-date". Aktueller als Debian Woody allemal (ist ja auch keine Kunst), aber dennoch wurde durch das lange Freeze des Base-Paketsets sowie der dauernden Unsicherheit, ob denn jetzt nun endlich einmal ein Release kommen würde sowie die immer währenden Beteuerungen, das es jetzt bald soweit sei, viel Zeit verschwendet sowie die Maintainer verunsichert, ob es sich z.B. lohnen kann, KDE oder Gnome noch auf eine aktuelle Version zu puschen.

Schade, finde ich.

Hoffentlich wird für Etch aus den Fehlern gelernt.

Hoffentlich.

Denn wenn die Entwicklung so weiter geht, dann stellt sich Debian sowohl für den Serverbetrieb als auch auf dem Desktop selbst ins Abseits.

Was sehr schade wäre, meiner Meinung nach.

Da mich immer mehr Leute danach fragen, wann ich denn endlich meinen Eintrag zu Freeradius und LDAP fertig stelle, habe ich mich entschlossen, das Thema auf mehrere Einträge zu verteilen.

Das ermöglicht mir, das ganze in kleineren Häppchen abzuarbeiten und so schneller zu einem Ergebnis zu kommen und vielleicht reichen einige der Infos ja schon aus, damit bei jemandem der Verständnis-Knoten platzt und der Weg weiter gehen kann.

Da ich natürlich nicht frei von Fehlern bin, bitte ich darum, eventuelle Mißverständnisse und Probleme via Kommentar mitzuteilen, damit ich dann die Ergebnisse einarbeiten kann.

Im ersten Teil gebe ich einen generellen Überblick über das, was ich eigentlich konfigurieren möchte und warum ich das so mache.

In weiteren Teilen gehe ich dann genauer auf die Konfiguration von Freeradius und in geringen Teilen auch vom OpenLDAP slapd ein, letzteres aber nur begrenzt, da ich davon ausgehe, das grundlegendes Wissen über LDAP inkl. eines solchen Servers mit Datenbasis vorhanden ist.

Aha: Sarge frozen!

Allerdings:

Timeline
--------

Now, let's resurrect that earlier freeze timeline, and make a few changes to it based on the great improvements in sarge since we last looked at the question:

[...]

30 May 2005
Release

And if everything goes well, we'll be ready to release at the end of the month.

Ich glaube eher nicht.

Allerdings sieht man endlich einmal Bewegung in der ganzen Geschichte.

Warten wir also ab, was wird.

Toll.

Update von 0.3.8 auf 0.4.0 und schon kann ich mich via WPA EPA-TTLS (mit PAP im inneren Authentifikator, dann TKIP für den Datenfluss) nicht mehr am Netz anmelden. Irgendwo zwischen Kernel 2.6.11.7 (genauer: die Debian-Version davon), dem madwifi BSD-Branch und wpa_supplicant hakt es.

Ich kann mich zwar soweit authentifizieren, aber nach einer Sekunde bricht alles sofort zusammen und wpa_supplicant startet einen neuen Authentifizierungversuch.

Ein Downgrade auf 0.3.8 läßt alles wieder funktionieren.

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.

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