Technik

Seit heute sind übrigens wieder alle DNS-Slaves der Blacklist am Netz. Ich bin gespannt, wem von den DNS-Slave-Betreibern das überhaupt auffällt. Zumindest die Abschaltung wurde großflächig nicht bemerkt.

Von einem Kunden

So, also falls sich nochmal ein Kunde melden sollte, dessen Debian System nicht mehr bootet:

wenn man (vor 2 Jahren) mit lenny anfängt, dann auf squeeze geht und immer brav mit aptiude update, safe-upgrade und dist-upgrade durchläuft, kommt man am ende evtl. mit einem System raus, das kein linux-image installiert hat, weswegen das grub update eine leere grub.cfg produziert (weil in /boot/ nur ein bzImage herumliegt, aber kein vmlinuz). Reparieren kann man das ganze im Rettungssystem wie folgt:

mount /dev/[bootplatte] /mnt/;
mount -B /dev /mnt/dev;
mount -B /sys /mnt/sys;
mount -B /proc /mnt/proc;

chroot /mnt

und dann, weil Debian gerade sowieso dabei ist, sich selber zu zerhäckseln, ist die mdadm conf auch leer. Also:
mdadm --examine --scan >> /etc/mdadm/mdadm.conf

und dann das rettende:

aptitude update;
aptitude install linux-image-[wasManGerneHätte]

An dieser Stelle nochmal herzlichen Dank an A. Hofmann!

Weil ich es immer mal wieder auf externen Server sehe: Eine ~/.my.cnf im Format

[mysql]
user = root
password = letmein

[mysqld]
user = root
password = letmein

[mysqldump]
user = root
password = letmein

[mysqladmin]
user = root
password = letmein

lässt sich auch ohne gzip oder bzip2 relativ einfach komprimieren:

[client]
user = root
password = letmein

Wer sich insbesondere auf virtuellen Maschinen (aber auch solchen mit SMP) immer mal wieder über Probleme mit der Stabilität der Clocksource (was sich in "Clocksource unstable" äußert) ärgert bzw. damit zu kämpfen hat: Ein notsc als Kernel-Parameter wirkt Wunder

Nötig ist dafür allerdings ein CONFIG_X86_TSC_DISABLE.

Man sollte es kaum für möglich halten, aber aufgrund der enormen Rate Ein-/Austragungen aus der Blacklist haben wir heute das "Timing" auf eine Genauigkeit von 1/1.000.000 Sekunde gestellt, u.a. um Race-Conditions zu vermeiden.

Da hat mich vergangene Woche der Windows 7 VirtualStore doch tatsächlich erwischt

Für alle, die es bis jetzt noch nicht kannten: Windows 7 speichert unter bestimmten Umständen die Daten von Programmen nicht unter c:\Programs[Bla]\ sondern unter C:\Users[Benutzername]\AppData\Local\VirtualStore\Program Files (obwohl die Applikation meint, es würde ins eigne Programm-Verzeichnis schreiben).

Ich hätte es nicht gedacht, aber

http://de.php.net/manual/de/function.fwrite.php#106209

konnten wir hier intern in Verbindung mit der Blacklist in der Tat wiederholt bemerken (leider aber nicht bewusst reproduzieren).

Unschön

Einfach mal so:

$locale_old = setlocale(LC_CTYPE, 0);
setlocale(LC_CTYPE, 'de_DE');

$data = iconv('ISO-8859-15', 'ASCII//TRANSLIT', $data);

setlocale(LC_CTYPE, $locale_old);

Wer übrigens einmal darauf stößt, dass (u.a.) SASL-basierte Verbindungen (z.B. bei SMTP in Verbindung mit Authentifizierung) auf mysteriöse Weise plötzlich aufhören, zu funktionieren, sollte einmal ein

sysctl kernel.random.entropy_avail

machen und schauen, ob sich der Entropie-Pool zum Ende neigt.

Wenn ja, ist es sinnvoll, die SASL-Bibliotheken gegen /dev/urandom zu linken (statt gegen /dev/random) (oder sich Gedanken zu machen, warum die Entropie des Kernels zu Ende geht - dagegen helfen u.a. die rng-tools).

Mir ist vorhin aufgefallen, dass die öffentlichen DENIC Whois-Daten im Zeitraum zwischen vermutlich interner Registrierung und Übertragung der Daten in alle internen Systems Diskrepanzen enthalten.

Diese Diskrepanzen bestehen eigentlich nur im Faktor Zeit, genauer: Macht man zwischen nach einer Registrierung eine Abfrage über das Web-Whois, erhält man in einer gewissen Anzahl der Fälle ein "ist bereits registriert", in der anderen ein "ist frei" - solange, bis vermutlich alle internen Whois- und/oder Datenbank-Server aktualisiert wurden.

Ich konnte das eben zumindest über eine gefühlte Minute so immer wieder reproduzieren. Ein F5 hat gereicht.

Ich hätte erwartet, dass die DENIC das intern schöner löst. Es riecht zumindest nach einem simplen DNS-basierten Round-Robin.

Die Angabe 10% stimmt hier weder in Bezug auf die Anzahl der überprüften Dateien noch in Bezug auf die Zeit, die für den Check nötig war/ist. Wie Microsoft auf 10% kommt, die sich im übrigen auch nach einer halben Stunde und trotz fast 100% geprüfter Dateien nicht verändert haben (auch nicht in Phase 2 bis 5): Keine Ahnung!


Im Übrigen ist es eine ganz blöde Idee, einen Dateisystem-Check in Windows für den nächsten Start einzuplanen und dies dann für mehr als eine Woche zu vergessen. Dann wundert man sich beim nächsten Update-bedingten Neustart, warum dieser so ewig dauert. Ich gebe zu, dass ich im ersten Moment dachte, es würden Dateien aktualisiert, nicht geprüft

Es ist schon bedauerlich, dass selbst große Router eines großen Router-Herstellers gratuitous arp-Pakete nicht berücksichtigt und trotz nicht-statischer Konfiguration seine ARP-Tabelle nicht aktualisiert (und munter weiter an die alte MAC-Adresse sendet).

Ich bin gespannt, wie der betroffene Carrier darauf reagieren wird

Manchmal kann ein Options -MultiViews einem viele Nerven bei RewriteRules ersparen

6 Sekunden für einen Reboot - dank SSD - sind einfach nur: WOW!

Ich habe mir gestern einmal angeschaut, wie groß der Umfang der dDNS-Updates des Blacklist-Master-Servers aktuell ist: 2 GB pro Tag an Änderungen (Ein- und Austragungen).

Damit hätte ich - zugegeben - nicht gerechnet.