…bin ich seit heute morgen! Hurra! Ok, wahnsinnig schwer war es nicht, in 3 der 6 Bereiche hatte ich sogar 100%, wirklich schlecht war ich aber bei den SQL-Fragen, die wohl eher für die Anwendungsentwickler gedacht waren. Naja egal, wieder ein Schein mehr! 
Das Bild konnte ich euch nicht vorenthalten! Bill Gates saß übrigens auch im Publikum.
Es begab sich folgendes Gespräch am Anfang der Woche (sinngemäß):
Chef: Wir brauchen noch jemanden mit NCLA Zertifizierung für die Ausschreibung von xyz! Wie sieht es aus?
Ich: Hmm, könnte ich wohl packen, versprechen kann ich aber nichts.
Chef: Ok, wir melden dich mal einfach dafür an, der ist grade auch so billig, egal wenn du durchfällst.
Ich habe heute morgen bestanden, 69 Fragen in 30 Minuten (man hatte 90m Zeit)!
Der Test war meiner Meinung nach etwas unter dem Niveau von LPIC-1 und es waren mindestens 5 Fragen in dem Test falsch, bzw. deren Bewertung – das weiß ich sehr sicher, denn am Ende bekommt man mitgeteilt, in welchen Bereichen man Fehler hatte, wenn von einem Bereich nur eine Frage drankam, weiß man natürlich bescheid. Man darf nichts über die Fragen veröffentlichen, woran ich mich auch halten werde, finde das aber schon ziemlich ärgerlich. Zur “passing Score” hin hatte ich aber trotzdem noch jede Menge Luft. Falls jemand die Prüfung auch eben noch vergünstigt machen will: hier gibt es Infos und den Gutscheincode für Pearson und Prometric Testcenter.
Wer MySQL Abfragen häufig auf der Kommandozeile ausführt kennt das Problem: Bei einem langen Ergebnis der Abfrage verschwindet der Großteil der Ausgabe im Nirvana des Verlaufsspeichers. Abhilfe schafft hier das pager Kommando, mit dem sich ein beliebiger Pager wie z.B. less setzen lässt:
[code language="css"]mysql> pager less
PAGER set to 'less'[/code]
Die MySQL Ausgabe wird nun an less übergeben und lässt sich so bequem Seite für Seite durcharbeiten. Jedes andere Linux / UNIX Kommando ist möglich, so dass sich ganz neue Möglichkeiten geben, wie Baron Schwartz im MySQL Performance Blog demonstriert.
Verwundert über die ganzen – nahezu zeitgleichen – Updates für diverse DNS Pakete auf euren Systemen? Es gibt ein massives DNS-Sicherheitsproblem, das schon seit etwa einem halben Jahr bekannt ist, aber soweit möglich unter Verschluss gehalten wurde. Ob der Nameserver, den man nutzt, betroffen ist, lässt sich online auf der Seite des Entdeckers der Lücke Dan Kaminsky testen.
Die Lücke lässt sich durch vorhersehbare Transaction IDs und Quellports ausnutzen, so dass Cache Poisoning möglich ist. Damit lassen sich die Antworten auf DNS Anfragen manipulieren, eine gute Erklärung bietet dieses PDF ab Seite 3.
Also, Updates einspielen und weiter die Ohren und Augen offen halten. Weitere Infos gibt es unter CVE-2008-1447 und securosis.com.
Nachdem ich gestern schon angefangen hatte, einen Beitrag dazu zu schreiben, hat es sich nun wie ein Lauffeuer verbreitet, auch Heise berichtete: das CITP (Center for Information Technology) hat ein Video und Dokument dazu veröffentlich, dass man RAM Bausteine auch nach einem Reboot auslesen und eventuell vorhande Cryptokeys wiederherstellen kann.
Die Technik ist nicht ganz neu, denn schon auf dem Chaos Communication Camp 2007 habe ich einen Vortrag gehört, in dem sie beschrieben wurde. Neu ist nun allerdings, dass RAM gekühlt und erst danach umgebaut wurde, sodass der Baustein seine Daten langsamer “vergisst” und dann im PC eines Forensikers ausgelesen werden kann. Ein USB-Boot mit passender Software am Rechner des “Übeltäters” reicht ja aber auch.
Gegenmaßnahmen gibt es bisher nicht und das wird auch schwierig (wenn nicht gar unmöglich) werden – spontan fällt mir dazu nur ein, dass man den ganzen PC aufbruchsicher in einem Safe verpacken könnte….
Oder man benutzt Crypto-Hardware, die on-the-fly alles im RAM verschlüsselt und den Key bei jedem Reboot des Systems ändert (und den Key natürlich nicht in einem DRAM speichert).
Das Internet Systems Consortium hat einen Benchmark ihrer DNS-Software BIND 9 durchgeführt, und zwar unter “Real-life” Bedingungen, indem sie Anfragen an ihren Server ns-ext.isc.org mitschnitten und diese Anfragen dann mit queryperf dann auf den Testserver einprasseln liessen.
Hier die Testergebnisse:
[sourcecode language="php"]OS Queries/second
Linux Gentoo 2.6.20.7 93,000
Linux Fedora Core 2.6.20.7 87,000
FreeBSD-7-CURRENT 200708 84,000
FreeBSD-6-stable 200708 55,000
FreeBSD 6.2-RELEASE 51,000
Solaris-10 DevelExpr 5/07 50,000
NetBSD-4.0-Beta 200708 42,000
OpenBSD 4.1-snap-20070427 35,000
Windows 2003 Server 22,000
Windows XP Pro64 5.2.3790 SP2 20,000[/sourcecode]
Ich persönlich hätte ja auch sowas vorausgesagt…
Wer ab und zu mal ziemlich große Dateien auf der Shell kopieren mußte (z.B. Oracle-Dumps auf USB-Festplatten), war sicher schonmal genervt, weil cp einfach keine Infos darüber anzeigt, wieviel schon kopiert wurde, wie die Datenrate grade ist und wie lange der Spass noch dauern wird. Hier habe ich nun einen kurzen “Hack” mit pv für euch:
[sourcecode language="css"]cp_pv()
{
dst="$2"; if [ -d "$2" ]; then dst="$2/`basename $1`"; fi
dd if=$1 2>/dev/null|pv –size `/bin/ls -l $1|awk ‘{print $5}’`|dd of=$dst 2>/dev/null;
}[/sourcecode]
So gehts dann:
[sourcecode language="css"]cp_pv /opt/oracle/my.large.file.dmp /mnt/usb/[/sourcecode]
Und so sieht es aus:
[sourcecode language="css"][oracle@slowdbsrv ~]$ cp_pv /opt/oracle/my.large.file.dmp /mnt/usb/
74,6MB 0:00:11 [6,45MB/s] [=> ] 5% ETA 0:03:17[/sourcecode]
Damit das Ziel nicht vollständig angegeben werden muss, habe ich noch einen check eingebaut, durch den das es um den Dateinamen ergänzt wird, falls das 2. Argument beim Aufruf der Funktion ein Verzeichnis ist. Kein großes Kino, ich weiß – ich poste das hier für den geneigten BASH-Neuling und auch als reminder für mich selbst, wenn ich die Zeile mal brauche. 
