Packages-Diff Support für aptDienstag, 9. Mai 2006Achtung: 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:
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. LinuxtagSamstag, 6. Mai 2006Heute, 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. So ein Zufall!Samstag, 28. Januar 2006Oder 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. Partielle Debian-PaketdatenbankupdatesDienstag, 18. Oktober 2005Hinter 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. Korrigiertes flow-tools Debian-PaketMittwoch, 14. September 2005Nachdem ich einen guten Tag damit zugebracht habe, darüber zu grübeln, warum flowscan nicht mit den von flow-capture erzeugten Daten spielen mochte:
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. Update2: 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. Kleine Dinge, große WirkungMontag, 22. August 2005Nahezu 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: [...] 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. ErkennungsmerkmalMittwoch, 29. Juni 2005Woran erkennt man einen Laptop, auf dem einmal Gentoo installiert war? "Erkennungsmerkmal" vollständig lesen Es geht wieder los!Dienstag, 7. Juni 2005Kaum ist Debian Sarge released, geht es in Sid schon wieder rund. Viele neue und erneuerte Pakete strömen herein:
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.) Up-to-Date?Montag, 6. Juni 2005Nach langem und und zähend Ringen ist Debian Sarge heute "stale" (sic!) geworden. Aus dem Release Announcement:
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. WPA+TTLS mit Freeradius und LDAP (Teil 1)Montag, 9. Mai 2005Da 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. "WPA+TTLS mit Freeradius und LDAP (Teil 1)" vollständig lesen Es friert!Mittwoch, 4. Mai 2005Aha: Sarge frozen! Allerdings:
[...]
Ich glaube eher nicht. Allerdings sieht man endlich einmal Bewegung in der ganzen Geschichte. Warten wir also ab, was wird. wpa_supplicant RegressionDienstag, 3. Mai 2005Toll. 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. The Lord of the NetDonnerstag, 28. April 2005Ein 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! pbuilder: Weg zu sauberen Debian-PaketenSamstag, 23. April 2005Wer 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:
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. BitKeeper nur noch kommerziellMittwoch, 6. April 2005
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
« vorherige Seite
(Seite 2 von 3, insgesamt 43 Einträge)
» nächste Seite
|
SucheBlog abonnierenVerwaltung des BlogsKategorienPowered by |
