Mich nervt es eigentlich schon seit langem, doch in letzter Zeit kommt es immer häufiger vor, dass meine iPod/Radio-Kombination im Auto mit aktueller Musik nicht mehr klar kommt. Viele Tracks sind dermaßen übersteuert, dass ein Hören nicht mehr möglich macht. Die Anlage zu Hause kommt mit dem Pegel klar, daher habe ich es lange ignoriert, im Auto höre ich zumeist sowieso nur Radio.

Jetzt aber bin ich aber zufällig auf diesen sehr interessanten Artikel gestoßen. Er bestätigt meine Beobachtung und zeigt in einem YouTUBE-Video noch eindrucksvoll, was wir als Konsument hier eigentlich für einen Müll vorgesetzt bekommen. In dem Artikel ist eigentlich schon alles gesagt, so dass ich hier nicht weiter drauf eingehen möchte.

Wer trotz allem noch im Besitz übersteuerter Musik ist, findet in »MP3Gain« möglicherweise einen neuen Freund und glaubt mir, Ihr seid es. Mit »MP3Gain« können einzelne Tracks oder ganze Ordner per Knopfdruck auf z.B. 89,0dB normalisiert werden. Unglaublich, dass die meisten Tracks an die 100db herankommen (siehe Screenshot).

»AACGAIN« stellt ein Kommandozeilentool zur Verfügung um AAC-Dateien zu bearbeiten, »iGain« soll das Ganze in »iTunes« integrieren, wobei ich nicht weiß, ob das mit der aktuellen iTunes-Version noch immer funktioniert. Letztere beide Tools wurden von mir noch nicht getestet, Feedback hierzu ist wie immer natürlich gerne erwünscht

Vorsicht ist geboten, wenn versucht wird die Boot-Partition eines »Windows Server 2008« größer zu ziehen. Als ich heute auf einer frisch eingerichteten VM die Festplatte von 30 auf 80GB vergrößert hatte und die Partition mit dem »Acronis Disk Director 10« angepasst hatte, meldet sich der »Windows-Start-Manager« mit der Fehlermeldung:

Datei: \Windows\system32\winload.exe
Status: 0xc000025
Info: Der ausgewählte Eintrag konnte nicht geladen werden, da die Anwendung fehlt oder beschädigt ist.

Problem ist hierbei möglicherweise eine Signatur, die durch den Fremdeingriff zerstört wird. Ganz klar ist mir der technische Hintergrund hierbei aber noch nicht – weitere Informationen sind an dieser Stelle erwünscht, sollte sie jemand liefern können. Über die Windows-CD lässt sich dieses Problem glücklicherweise aber über die »Eingabeaufforderung« der »Computerreparaturoption« folgendemaßen beheben:

Nachzulesen ist das Problem ebenfalls in Matthew Cosier’s Blog. Weitere Details hierzu sind in den folgenden Screenshots zu erkennen:

Update 2010-01-14: Der gleiche Fehler unter Windows 7

Heute ist mir meine Windows 7 Sandbox zu klein geworden. Eine Vergrößerung der Boot-Partition, ebenfalls mit »Acronis Disk Director 10«, brachte unter »Windows Seven« das gleiche Problem. Auch hier aber hilft ein kurzes Booten der Installations-CD und die »Computerreparaturoption«, um das Problem in den Griff zu bekommen. Anders als bei dem »Windows Server 2008« aber erkennt die Reparatur direkt, dass ein Problem besteht und fragt, ob es behoben werden soll. Man spart sich also die Tipparbeit Ein Tipp von j-zero war die Nutzung von »GParted« für die Partitionsänderungen. Der nächste Versuch wird also mit Hilfer einer »Ubuntu Desktop CD« durchgeführt (hier ist »GParted« direkt aufrufbar). Sollte die kostenlose Software hier tatsächlich wieder einmal die Nase vorn haben?

Pünktlich zum Jahresstart brachte uns der Spamassassin mit einem Jahr 2010-Bug Freude. Problem war die Regel »FH_DATE_PAST_20XX«, welche seit dem 1.1.2010 3,188 Extrapunkte pro Mail auf den Spamstatus aufgerechnet hat. Durch diese Extrapunkte wurden viele Mails als sogenannte »false positives« gekennzeichnet und sind, je nach Konfiguration des Mailservers, im Spamordner gelandet.

Per »sa-update« wurde (ich glaube noch am 1.1.2010 selbst) ein entsprechendes Update veröffentlicht, welches die falsche RegEx ersetzt:

Alt:

Neu:

Wer einmal genau guckt sieht, dass wir uns nach diesem tollen »Patch« am 1.1.2020 wieder sprechen, sollten wir zu diesem Zeitpunkt noch die gleiche Technologie nutzen. Im Bugreport aber war zu lesen, dass nun ja 1 Jahrzehnt Zeit ist, das Problem endgültig zu fixen, wir sind gespannt.

Heise ist am 1.1.2010 noch von einem GMX-Problem ausgegangen, hatte dies in einem späteren Update aber korrigiert. Im Forum wurde mit Recht darauf hingewiesen, dass das im Nachhinein schlecht gewählte Topic viele Spamassassin-Nutzer nur durch Zufall auf den Artikel hat aufmerksam werden lassen.

Weiteres Problem unter Ubuntu- und Debian-Systemen

Ich persönlich hatte auf 2 Ubuntu Hardy-Systemen noch das Problem, dass die mit »sa-update« aktualisieren Regeln nicht aktiviert wurden. Grund hierfür scheint gewesen zu sein, dass Ubuntu (und dies betrifft natürlich genauso auch Debian-Systeme) unter /usr/share/spamassassin noch die Regeln vom Auslieferungszustand liegen hat. Diese können gefahrlos entfernt werden, vorher natürlich ein Backup anlegen. »sa-update« legt seine neuen Dateien unter /var/lib/spamassassin/3.002004 ab. In der Datei
/var/lib/spamassassin/3.002004/updates_spamassassin_org/72_active.cf
kann auch kontrolliert werden, ob die oben genannte RegEx erfolgreich aktualisiert wurde.

Wer „sa-update“ bis jetzt noch gar nicht konfiguriert hatte findet unter http://saupdates.openprotect.com/ ein gutes Howto.

Nachdem ich heute auf einen Windows Server 2003 die aktuellen Updates eingespielt hatte, streikte die LDAP-Apache Anmeldung an einer meiner Intranet-Seiten mit folgenden Meldung:

Zugegeben war der Windows Server 2003 etwas in Vergessenheit geraten und sehr lange schon nicht mit Updates versorgt, ich kann also nicht sagen, welches hier schuld gewesen ist. Begründung und Lösung wird in diesem ebenfalls sehr alten Bug Report beschrieben. Kurz zusammengefasst liegt das Problem möglicherweise daran, dass bei der Abfrage eines Benutzers mehrere Referenzen zurückgeliefert werden. Umgangen werden kann dies, indem man etwas später erst in den Baum einsteigt, z.B. nur in der OU sucht, in der auch die Benutzer liegen:

Sollte dies nicht möglich sein, weil man z.B. in mehreren OUs suchen möchte oder muss, so kann man seine » AuthLDAPURL« auf den »Global Catalog« verlegen, hier werden die bösen Referenzen nicht mit zurückgeliefert. Ob der Port 3268 offen ist, verrät ein »nmap«, hier ein Auszug der normalen LDAP-Ports und der des »Global Catalog«:

Sind Port 3268 und 3269 nicht offen, so wird hier erklärt, wie der »Global Catalog« erstellt wird.

Tauscht man den Port 389 also einfach gegen 3268, so kann man wieder problemlos das gesamte Verzeichnis durchsuchen:

Für mich funktionieren beiden Lösungen, ich bleibe nun aber bei der Nutzung des »Global Catalog«.

Heute wollte ich endlich einmal die Berechtigungen in unserem Nagios-Webinterface in Ordnung bringen und bin einmal wieder über ein Problem gestolpert, von dem ich nicht dachte, dass ich mir hier überhaupt noch Gedanken machen muss. Das Apache-Modul »mod_authnz_ldap« unterstützt doch aber tatsächlich keine Abfrage von Untergruppen im LDAP (Im Fachjargon auch »subgroups« oder »nested groups« genannt). Untergruppen, also eine Gruppe innerhalb einer Gruppe um den Administrationsaufwand beim Zuordnen von Benutzerrechten möglichst gering zu halten.

Im aktuellen Entwicklerzweig bzw. in der zukünftigen Apache-Version (wohl aber erst in Apache 2.3?) scheint es hier über die Option »authldapmaxsubgroupdepth« aber endlich eine Möglichkeit zu geben, wie die Dokumentation zeigt. Ich hab meine Gruppenstruktur in diesem speziellen Fall jetzt erst einmal flach aufgebaut und werde die Option vielleicht später einmal testen. Sollte hier schon jemand Erfahrungen gemacht haben, bin ich über jeden kurzen Kommentar dankbar.