Svens Netzblog

Welche Religion passt?

Nicht, das ich es nicht schon immer gewußt hätte...

You scored as atheism. You are... an atheist, though you probably already knew this. Also, you probably have several people praying daily for your soul. Instead of simply being "nonreligious," atheists strongly believe in the lack of existence of a higher being, or God. atheism 75% Satanism 71% Paganism 67% Buddhism 54% agnosticism 42% Islam 21% Judaism 13% Christianity 8% Hinduism 0% Which religion is the right one for you? (new version) created with QuizFarm.com

(via Thomas und Kristian)

Aus gegebenem Anlass möchte ich auf meinen CIDR-Tester hinweisen:

Das schwarze Loch.

Warum "schwarzes Loch"? Wenn man sich die IP genauer ansieht, wird man verstehen, warum: 195.69.240.255. Augenscheinlich ist dies eine Broadcast-IP eines /24er Netzes. Aber das ist nicht richtig, denn diese IP liegt mitten in einem /22er-Netz und ist damit eine absolut normale IP.

Nun gibt es allerdings einige Provider, die scheinbar noch in alten Zeiten leben und das Klassendenken noch nicht überwunden haben und meinen, dieser IP eine Magie andichten zu müssen, die schlichtweg nicht vorhanden ist. Und da Broadcast-IPs früher (und auch heute noch) gerne für Attacken als Multiplikator benutzt worden sind (bzw. werden), versuchen scheinbar einige ISPs Pakete an solche vermeintlichen Broadcast-IPs auszufiltern.

Zu Zeiten des classful routings mag das noch funktioniert haben, aber heute kann man einer IP eben nicht mehr ansehen, welche evtl. magische Aufgabe sie hat, zumindest nicht, ohne die dazugehörige Netzmaske zu kennen.

So wurde mir berichtet, das der Rechner über Arcor-DSL nicht zu erreichen sei, von Arcor-ISDN aber sehr wohl (das habe ich selbst nachgeprüft). Desweiteren hat Kamp angeblich Probleme mit der IP und sogar einer der Carrier (Level3, wie mir berichtet wurde, prüfen kann ich das derzeit leider nicht) dorthin soll sich verhaspeln.

Also probiert es einmal aus und teilt mir mit, am besten mit traceroute/tracert-Ausgabe, wo es hängen blieb, wenn es denn hängt.

Gerade fängt eine der Western-Digital WD800BB in meinem Arbeitsplatz-Rechner an, wie eine verhinderte Kreissäge zu jaulen. Selbst Musik via Kopfhörer durchdringt das Geräusch mühelos, und das aus einem geschlossenen Gehäuse, welches unter meinem Schreibtisch steht.

Ersatz muss also her.

Glücklicherweise hat der kluge Mann vorgesorgt und alles auf RAID1 gelagert, so daß ich die Platte ausbauen kann, ohne großartige Umkopieraktionen tätigen zu müssen.

Nachdem ich jetzt schon von mehreren Berichten gelesen habe, nach denen auch dort nach knapp 12.000 Betriebsstunden das Gekreische anfing, fällt WD erst einmal als Auswahl für die neue Platte weg.

Zur Auswahl stehen mir nun folgende Modelle:

• Hitachi HDS728080PL
• Maxtor 6Y080P0
• Samsung SP0812N

Bisher verbaut habe ich in einem anderen Rechner zwei Samsung SV0802N, mit deren Lautstärke und Temperatur ich recht zufrieden bin, wenngleich eine davon derzeit ausgebaut ist, weil sie ab und zu ein klackendes Geräusch von sich gab und der Kernel dann fortlaufend hdc: lost interrupt meldete. Wobei ich mir nicht so sicher bin, ob dies jetzt am Board, an der Platte oder am Netzteil lag.

Ich werde diese Platte also testweise einmal anstelle der lärmenden 80GB WD einbauen und beobachten, ob sie dort auch wieder "austickt".

Denn eigentlich hatte ich gerade keine Lust, schon wieder Geld in Platten zu investieren.

Meine Kurzzusammenfassung von Ostern:

Autobahn, Abendessen, pennen, Rückenschmerzen von ungewohntem Bett, Mittagessen, Kuchen (als Abendessen), Herr der Ringe (im Fernsehen, auf deutsch. Grauenhaft. Leider habe ich meine DVDs gerade nicht parat.) pennen, Rückenschmerzen, Mittagessen, Autobahn.

Folgendes fand sich via #debian.de:

Nachdem mir ja eine kleine SparcStation5-110 zugeflogen ist (megumi), habe ich jetzt angefangen, sie in mein Netz zu integrieren.

Zuerst einmal habe ich die kreischenden SCA-Platten ausgebaut, den TGX-Framebuffer entfernt und anstelle dessen eine SBus-HME eingebaut. Außerdem spendierte ich ihr noch 4x32MB, so daß ich jetzt auf 192MB insgesamt komme.

Da ich schon genug Debian-Systeme in meinem Netz habe (und Debian ja ankündigt, evtl. Sparc als Release-Architektur abzukündigen), wird megumi mit NetBSD 2.0 versehen, allerdings als Diskless-Variante, was dank der passenden Anleitung nicht weiter schwer war.

Und da ich mir in den Kopf gesetzt habe, zumindest den Kernel aus den Quellen zu kompilieren, übe ich mich derzeit im Geduldsspiel, denn zugegebenermaßen ist ein SuperSPARC mit 110MHz nicht mehr der Schnellste.

Derzeit, nach knapp 5 Stunden Compilezeit, ist build.sh -u -U tools bei groff angekommen. Mal schauen, wann er fertig ist.

Meine Versuche dagegen, mittels build.sh auf Linux zu Cross-compilen waren leider nicht wirklich erfolgreich, aber ich hatte auch nur einen Versuch gestartet, ohne große Vorkehrungen zu treffen. Sobald ich einmal mehr Zeit dafür habe, werde ich da genauer nachforschen, wie sich das bewerkstelligen läßt. Evtl. ja mit einem cross-compiler auf distcc-Basis.

Und just in diesem Momen ist das build.sh für die Tools fertig:

         build.sh command: ./build.sh -u -U tools
         build.sh started: Thu Mar 24 11:14:39 CET 2005
         No nonexistent/bin/nbmake, needs building.
         Bootstrapping nbmake
         MACHINE:          sparc
         MACHINE_ARCH:     sparc
         TOOLDIR path:     /usr/src/tooldir.NetBSD-2.0-sparc
         DESTDIR path:     /usr/src/destdir.sparc
         RELEASEDIR path:  /usr/src/releasedir
         Created /usr/src/tooldir.NetBSD-2.0-sparc/bin/nbmake
         makewrapper:      /usr/src/tooldir.NetBSD-2.0-sparc/bin/nbmake-sparc
         Updated /usr/src/tooldir.NetBSD-2.0-sparc/bin/nbmake-sparc
         Tools built to /usr/src/tooldir.NetBSD-2.0-sparc
         build.sh started: Thu Mar 24 11:14:39 CET 2005
         build.sh ended:   Thu Mar 24 16:36:09 CET 2005

Seufz.

Nach einer interessanten Odyssee durch die autotools und libtool (mein ganz spezieller Freund) finde ich mich jetzt wieder bei der CVS-Version von freeradius wieder.

Die stabile Version 1.0.2 ist unter Debian Sarge/Sid mit TLS für EAP und WPA nicht benutzbar, da rlm_eap_ttls.so mit einem "undefined symbol: eaptls_process" den Dienst verweigert. Ein Problem, das eigentlich schon seit Mitte 2004 behoben sein sollte.

Die instabile Version hat dieses zwar nicht, aber dafür immer noch das schon von mir ausführlich verfluchte andere Problem.

Argh!

Mal davon abgesehen halte ich die Benutzung einer CVS-Version in einem wichtigen produktiven System für mehr als bedenklich.

Nachdem zuerst die Kernel-Maintainer für 2.6 mit einem für mich befremdlichem Vorschlag bzgl. der Release-Politik Aufsehen erregten, kommt nun die nächste Nachricht vom Debian-Projekt:

Nach einem Treffen mit anderen an der Release-Planung beteiligten Debian-Developern in Vancouver schlägt Release-Manger Steve Langasek vor, für Etch (das auf Sarge folgende Debian-Release) die Anzahl der vom Release-Team als stabil herausgegebenen Architekturen auf 4 zureduzieren: i386, powerpc, amd64 und ia64.

Der sich darauf in der debian-devel Mailingliste entfachende Diskussionsthread bietet viel flammende Mails, Zustimmung, Ablehnung und auch Verzweiflung.

Während ich persönlich begrüße, das eingesehen worden ist, das es so wie bisher nicht weiter gehen kann, bin ich doch etwas enttäuscht von der Endgültigkeit, mit der bestimmte Architekturen vom Tisch gewischt werden, selbst wenn das ganze vorerst nur als "Proposal" gehandelt wird. Man muss allerdings sehen, das dieser Vorschlag vom Release-Team, den FTP-Mastern und den Security-Leuten eingebracht worden ist, ein Personenkreis, der letztendlich eine sehr große Macht innerhalb des Debian-Projektes hat.

So wird zwar gesagt, das die SCC (Second Class Citizens)-Architekturen ja nicht fallengelassen werden, aber sie erhalten kein Testing und kein automatisches Stable mehr. Wenn eine SCC-Architektur ein Release haben will, dann müssen die Porter dieses eben alleine stemmen, z.B. durch einen Snapshot von Unstable.

In meinen Augen ist diese Aussage daher ein reiner Euphemismus, denn es dürfte den Portern einen SCC-Archtektur recht schwer fallen, die nötigen Hürden und Arbeiten für ein stabiles Release alleine ohne jeglichen Support zu machen.

Desweiteren fällt natürlich der Status "Release Critical" für Bugs weg, die auf einer SCC-Architektur einen Fehler hervorrufen, der sich auf den 4 Haupt-Architekturen nicht zeigt. Damit dürfte auf lange Sicht die Bereitschaft der Maintainer betroffener Pakete, Patches anzunehmen, die den Fehler beheben, eher sinken.

Weitere Kritikpunkte bzgl. der Kommunikationsfähigkeit der Core-Teams, der Unfairheit gegenüber bestimmten Architekturen und Personen, etc. wurden ebenfalls laut, brachten aber keine Argumente, außer persönlichen Animositäten auf den Tisch.

Alles in allem finde ich den Vorschlag, ganz vorneweg die Ausschließung von Testing und dann Stable, als unausgegoren und enttäuschend.

Das Testing im bisherigen Zustand mit der erzwungenen Sychronität aller Architekturen nicht haltbar ist, zeichnete sich ja ab. Aber deswegen gleich 7 von ihnen über Bord zu kippen finde ich zu extrem.

Vor allem, weil keine 3 Wochen vorher noch groß beteuert worden ist, das selbst die kleineren Architekturen nicht der Grund für Verzögerungen seien. Diese damalige Aussage in heutigem Licht betrachtet läßt einen Hauch von Farce aufkommen.

Was ist also zu tun?

Die Abtrennung der Synchronität von Testing wäre evtl. eine Möglichkeit. Dazu wurde allerdings gesagt, das dies den Server, der die DAK-Suite betreibt, zu sehr belasten würde. Dann muss man sich natürlich die Frage gefallen lassen, wieso dann kleinere Architekturen dafür zahlen sollen, das ein entsprechender Server des Projektes nicht leistungsfähig genug ist?

Auch das strikte gleichzeitige Release aller Architekturen könnte aufgehoben werden, so dass Showstopper in z.B. der Toolchain oder des Kernels einer Architektur nicht alles gleichzeit lahmlegen.

Beide Vorschläge haben natürlich wiederum Nachteile und eigene Probleme (Security-Support z.B.).

Ich bin jedenfalls gespannt, wie die Diskussion ausgeht, wenngleich ich ein wenig die Befürchtung habe, das der große Knall noch bevor steht.