See in HD and fullscreen!
Original blog post here.

Another helpfull resource is: Understanding Git Conceptually and gitref.org

According to Debians Upgrade instruction and it’s “How to recover” section, the problem can be caused by new naming conventions for IDE disks.

This problem can occur when the upgrade of the kernel introduces the use of the new generation of IDE drivers. The IDE disk naming convention for the old drivers was hda, hdb, hdc, hdd. The new drivers will name the same disks respectively sda, sdb, sdc, sdd. The problem appears when the upgrade does not generate a new /boot/grub/menu.lst file to take the new naming convention into account. During the boot, Grub will pass a system root partition to the kernel that the kernel doesn’t find.

This seems like to be very common reason for these “Waiting for root file system” troubles that many faces now when upgrading to Lenny. But in my case I allready had the new sda* names in the grub/menu.lst and /etc/fstab. The “solution to recover” did not work.

The virtual lenny server with the new kernel images that fails to boot was hosted by VMWare Server 1.0.3. For a nearly the same upgrade process (etch to lenny) hosted on FMWare fusion 2.0.2, I did not have these problems.

Solution: My VMWare Server 1.0.3 was out of date and had a known vmware bug that caused this error. Upgrading to the latest version (now 1.0.8) solved the problem.

Error: Could not stat() command file ‘/var/lib/nagios3/rw/nagios.cmd’!

In “/etc/nagios3/nagios.cfg” the “check_external_commands=1″ was already set. So there was something more required to make it run on Debian…

Deep in my memory I know that there was a debian way to solve this user right related problem. This time I’ll write it down here – perhaps I’ll find it more easily when I upgrade to Debian GNU/Linux 6.0 (codenamed squeeze) and/or Nagios4.

/etc/init.d/nagios3 stop
dpkg-statoverride –update –add nagios www-data 2710 /var/lib/nagios3/rw
dpkg-statoverride –update –add nagios nagios 751 /var/lib/nagios3
/etc/init.d/nagios3 start

Eine Änderung, die mit WP 2.6 eingeführt wurde machte nun offenbar im grösseren Stil Schwierigkeiten. Admins konnten sich nach einem brav und eigentlich korrekt nach “HowTo” eingespieltem Upgrade nicht mehr einloggen. Ein über mehre Seiten mit Hilfegesuchen gefüllter Foren-Thread von ausgeschlossenen WordPress-Betreibern (“Upgraded to WP 2.6 and can’t access wp-admin area“) wurde schliesslich von den Moderatoren recht barsch geschlossen. Etliche Ratsuchende wurden nach meinem dafürhalten ohne eine Hilfestellung zurückgelassen, da der abschliessende Beitrag des Moderators keine Lösung nennt.

Was war passiert?
Mit dem Upgrade auf die 2.6 ist man dazu angehalten in die wp-config.php drei weitere Defines zur verbesserten Cookie-Sicherheit einzubauen.

Wer noch den Sticky Beitrag im Support-Forum HOWTO: Set up secret keys in WordPress 2.6+ gefunden hat, konnte sogar erfahren, dass man sich neu einloggen muss (okay, kann man auch von selbst drauf kommen).

Dies sowie der sonst noch häufig zu findende Hinweis, die Cookies zu löschen, nützen aber nichts, wenn man in der Config auch noch eine Define für den SECRET_KEY gesetzt hat (ich meine der wurde so um die v2.5 eingeführt. Wer also von einer Uralt-Version upgraded, wird das Teil ggf. nicht haben und somit von dem Problem verschont bleiben). Sobald aber die drei neuen Keys und der alte SECRET_KEY definiert sind ist man ausgeschlossen da alle Login-Versuche mit You do not have sufficient permissions to access this page bzw. Sie haben nicht ausreichend Rechte, um auf diese Seite zuzugreifen abgewiesen werde.

Es muss offenbar der ehemals gültige SECRET_KEY ab v2.6+ auskommentiert werden, damit es wieder mit dem Login klappt (zumdem muss man die alten Cookies ablöschen). Eine offizielle Erklärung bzw. Bestätigung habe ich beim lesen der Upgrade How-Tows nirgends gefunden; aber das scheint mir die einzig logische Erklärung. Wenn jemand eine andere Vorgesehensweise für dieses Problem hat bitte ich um einen Kommentar.

Wäre doch sinnvollgewesen, wenn die Moderatoren nicht so sehr die Hilfesuchenden beschimpfen würden (okay, die sind auch angenervt von der Konsumer-Mentalität…) sondern beim Upgrade einen nicht zu übersehenden Hinweis draufgebeppt hätten. Ich jedenfalls bin beim schnellen Upgraden voll in dieser Stolpferfalle hineingelaufen (drum tippe ich das jetzt hier hinein; vielleicht findet ein Ratsuchender diesen Beitrag).

BTW: Wer nach “You do not have sufficient permissions to access this page” googelt wird oft auch als Lösungshinweis “force-upgrade.php” finden. Das Tool addressiert aber ein anderes Problem dass offenbar mit älteren Versionen im Zusammenhang steht.

“Wenige Tools haben die Web 2.0 Szene so im Sturm erobert wie die Mikroblogging-Plattform Twitter. Nicht nur Privatpersonen, sondern auch Organisationen, Firmen und sogar amerikanische Präsidentschaftskandidaten nutzen sie für Kommunikation, Marketing, PR und Kundenbindung. Für Millionen von Nutzern ist Twitter inzwischen weitaus mehr als nur 140 Zeichen pro Nachricht: Es ist primärer Kommunikationsweg und zentraler Bestandteil hunderter nützlicher Applikationen und unterhaltsamer Mashups.

‘Twitter – Mit 140 Zeichen zum Web 2.0′ hilft Ihnen von den ersten Schritten bis hin zur professionellen Nutzung dieses Dienstes. Sie lernen wichtige Programme und Anwendungen zu Twitter ebenso kennen wie erfolgreiche Strategien und Firmenprojekte rund um diese neue Kommunikations-Plattform. Zahlreiche Einsatzbeispiele und Interviews geben einen gründlichen Einblick, bieten viele Anregungen für die eigene Nutzung und zeigen Ihnen, was Twitter so besonders macht.”

Das Buch kann beim Open Source Press Shop oder bei Amazon bestellt werden.

Update: Frei nach dem Motto “Entdecke die Möglichkeiten”, habe ich mich nun auch mal fix bei Twitter angemeldet. Da ich sehr viel am Coden bin habe ich mir zusätlich zum Twitter Client Twhirl noch für TextMate ein Bundle für Twitter installiert mit dem das Updaten einfach per markierten Text und Hotkey funktioniert. So kann ich z.B. Quellcodekommentare direkt nach Twitter updaten. Meine Twitter-Seite habe ich zunächst als “nicht öffentlich” angelegt, damit nur explizit freigeschaltete “Follower” meine Updates einsehen können. Mal sehen, was draus wird. Öffentlich seit 01.12.08.

Ich habe zu wenig Zeit um in das interessante Thema tiefer einzusteigen – aber hier dennoch ein paar lesenswerte Artikel (etwas iPhone-lastig):

Über die Schwachtstellen des T-mobile Android G1: zZ kein Syncing, Keyboard, Hardware, T-Mobile Tarife und mehr.

Aus Entwickler-Sicht sehr interessant der Vergleich zum “kontrollierten” AppStore vs. dem unreguliertem Andorid Market Place.

Und ebenfalls interessant: http://gizmodo.com/5053441/giz-explains-whats-good-and-bad-about-developing-for-android-and-iphone

Aus Benutzersicht ist das iPhone zZ noch das deutlich rundere Paket. Zumal wenn man auf dem Desktop OS X einsetzt, drängt sich das iPhone geradezu auf. Allerding sieht es aus Entwicklersicht ganz anders aus: wenn man nicht in das geregelte (geschlossene) System von Apple eintauchen will (und Objective C nicht einsetzen mag), bleibt nur der Android.

Ich vermute, dass Android zum Start kein Renner wird und sich womöglich ähnlich schwer tun wird wie Linux den Desktop zu erobern. Aber immerhin hat das iPhone nun einen mächtigen Gegenspieler (mit sehr starken Konzepten) und die OpenSource Entwickerkommunity hat endlich ein SDK 1.0 für Android. Es wird spannend…

Vulnerable host keys will be regenerated

Some of the OpenSSH server host keys on this system were generated with a version of OpenSSL that had a broken random number generator. As a result, these host keys are from a well-known set, are subject to brute-force attacks, and must be regenerated.
…

Mehr Details dazu unter: http://lists.debian.org/debian-security-announce/2008/msg00152.html

Das ist wirklich schlimm, denn anders als bei den meisten üblichen Sicherheitslücken, die durch einen Patch sofort mehr oder weniger zuverlässig geschlossen werden (hoffentlich ohne neue Sicherheitslücken aufzureissen), ist dieser Fehler eher wie eine Art Bandwurm. Das fehlerhafte Debian Paket OpenSSL hat Schlüssel erzeugt, die nicht so zufällig waren wie sie hätten sein sollen. Daher sind diese Schlüssel vorhersagbar und nicht sicher.

Etliche sicher geglaubte Keys sind längst im Umlauf (das Problem besteht seit dem 17.09.2006) und müssen nun rasch durch neue, sichere Schlüssel ersetzt werden, bevor die schwachen Schlüssel, die ja auch zur Authentifizierung genutzt werden, geknackt werden.

Wenn solche schwachen Schlüssel für vermeintlich sichere Verbindungen genutzt wurden, könnten die übertragenen Daten sogar im Nachhinein entschlüsselt werden, wenn der Traffic mitgeschnitten wurde. Womöglich lassen sich daraus sicherheitsrelevante Daten gewinnen.

Das Patchen verhindert zunächst nur, dass nicht weitere schwache Schlüssel erzeugt werden – aber die bereits in Verwendung befindlichen schwachen Schlüssel sind zunächst ja weiterhin im Umlauf. Das macht diesen Fehler so dramatisch. Der Aufwand für die Admins ist jetzt irre gross: Alles betroffenen Schlüssel müssen ermittelt und ausgetauscht werden – in allen Anwendungen und auf allen Servern wo sie eingesetzt werden. Viel Angriffsfläche wie man auch dem Debian Key-Rollover Dokument entnehmen kann.

Der Fehler zieht also weite Kreise über Debian Grenzen hinaus und stiftet grosses Chaos – auch Heise berichtete schon darüber und bietet einen einfachen deutsprachigen Leitfaden an.

Das installieren des Patches aktiviert eine Blacklist für “schwache” Schlüssel, so dass Debian Admins Gefahr laufen, sich auszuschliessen, wenn sie bisher nur mit schwachen Schlüssen einloggen konnten und versäumen neue “harte” Schlüssel anzulegen und einzutragen.

Der Schaden für das Ansehen von Debian ist gross – auch wenn heise mit einem guten Kommentar versucht die Wogen etwas zu glätten. Wie konnte ein einzelner Paket-Maintainer (Kurt R.) einen solchen dummen und unnötigen Bug einbauen ohne dass eine Qualitätssicherung greift oder jemand von der Mailingliste darüber stolpert. Wieso gab es keine Kommunikation mit den Autoren des OpenSSL Quellcodes. Konnte sich der Fehler einschleichen und so lange unentdeckt bleiben, weil Debian ja neuerdings versucht aktueller zu sein und somit den Zeitdruck auf die Maintainer erhöht? Gergely Riskó stellt in seinem Artikel die Hintergründe des Supergau zusammen.

Auch für Open Source könnte damit Schaden entstanden sein. Was üblicherweise eine Stärke von Open Source ist, könnte sich nun als Nachteil erweisen, denn bei einem Closed-Source System würden wohl nicht so rasch die Details über die Schwachstelle zu ermitteln sein, die es “den Bösen” erleichtern das Sicherheitsloch rasch auszunutzen. Derzeit kann wohl noch keiner einschätzen, wie groß der Schaden sein wird, der durch die Entschlüsselung von mitgeschnittenen Daten über vermeintlich sichere Verbindungen entsteht.