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

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.

Nach dem Konvertieren findet die VM unter VMWare Server nicht mehr das Netzwerk. /etc/network/interfaces ist unter Fusion mit eth0 gelaufen. Unter VMWareServer zeigt die VM mit “ifconfig -a” nur ein eth1 an. Ich habe die also in /etc/interfaces das primary network interface von eth0 auf eht1 geändert. Danach “/etc/ini.d/network restart” und nun läuft es wieder. Muss ich bei Gelegenheit mal genauer schauen, was da schief gelaufen ist – muss wohl irgendwas mit dem vmxnet networking driver sein.

Update: Die VM wurde “geklont” dabei wurde eine neue MAC-Adresse angelegt. Bei Debian ist in der “/etc/udev/rules.d/z25_persistent-net.rules” die alte MAC-Adresse eingetragen. Ich habe die “/etc/udev/rules.d/z25_persistent-net.rules” gelöscht und rebootet. Danach war das interface wieder als eth0 zu verwenden.

Auch andere haben schon vor dem Problem gestanden und versucht die 25 seitige Dokumentation “Timekeeping in VMware Virtual Machines” irgendwie auf das wesentliche zusammenzufassen.

Nach dem Tipp eines befreundeten Admins (Danke Dirk) in die Knowledgebase bei RedHat zu schauen, finde ich dort nur den Weg, den ich zuvor schon versucht hatte. Grob zusammengefasst:

1. Im Gast OS die VMWare-Tools installieren.

2. In der *.vmx Datei den Eintrag
tools.syncTime = “TRUE”
setzen.

3. ntpd im Gast nicht erforderlich aber für den Host empfohlen.

Damit hatte es aber noch nicht geklappt (Gast Uhr läuft extrem hinterher) und ohne den Eintrag “host.useFastClock = FALSE” werde ich mit “rtc: lost some interrupts” im Syslog zugeschmissen.

Also ist eine rasch zu ergoogelnde Lösung nicht in Sicht und ich muss nochmal genauer in die VMWare-Bibel der Zeitsynchronierung schauen. Dort finde ich auf Seite 22 bei Punkt 3, Unterpunkt 3 eine Lösung die für meine Konfiguration (Host = 2.6.18-6-686 #1 SMP mit VMWare Server1.x) funktioniert:

Linux kernel 2.6 guests normally request 1000 PIT 0 timer interrupts per second, plus, in
some cases, 1000 local APIC timer interrupts on each virtual CPU. For single processor guests, you can usually eliminate the unneeded APIC timer interrupts by including the kernel command line flags noapic nolapic nosmp. (All three flags may not be needed, depending on your exact kernel version, but it should be harmless to give all three.)

Aktuelle fahre ich also folgende Kernel Flags für die VM in der grub/menu.lst:
kernel /boot/vmlinuz-2.6.18-6-686 root=/dev/sda1 ro noapic nolapic nosmp clock=pmtmr
und habe damit eine synchrone Zeit zwischen Host und VM und keinerlei “rtc: lost some interrupts” Meldungen im Syslog mehr.

Wie schön dass es noch immer einen Schalter mehr gibt, den man noch ausprobieren kann… Oder wie schreibt VMWare so schön auf Seite 25: “Conclusion: Timekeeping in virtual machines is a complex subject.”

You can prevent /dev/rtc from being used. This will generally cause clocks to run slow
in any virtual machines you have that need the additional interrupts, but that may be
acceptable to you, depending on your application. To do so, add the following setting to
each virtual machine’s .vmx configuration file, or add the setting globally to the host’s
configuration file (/etc/vmware/config):

host.useFastClock = FALSE

Wenn man diese Zeile im /etc/vmware/config einträgt und vmware neu startet (/etc/init.d/vmware restart), ist man die Einträge im Syslog los.

Hier habe ich eine Lösung gefunden, die als root durchzuführen ist:

1. cd /usr/lib/vmware/lib/libpng12.so.0
2. mv libpng12.so.0 libpng12.so.0.old
3. ln -sf /usr/lib/libpng12.so.0
4. cd ../libgcc_s.so.1
5. mv libgcc_s.so.1 libgcc_s.so.1.old
6. ln -sf /lib/libgcc_s.so.1

Auf einer Debian (oder auch Ubuntu) basierten Linux Distribution erfolgt die Installation mit:

Das Verwenden der yml Datei wurde erst in einer späten Version von s3sync hinzugefügt. Es erspart das Setzen der Umgebungsvariablen bevor das s3sync Script aufgerufen wird.

Ein Beispiel für ein SSL_CERT_FILE wird im Readme von s3sync gegeben.

Besitzer, Gruppe und Rechte bleiben mit s3sync erhalten. Leider gehen mir aber die Timestamps verloren.

Weiterführende Dokumentation gibt es hier. In diesem Beispiel wird auch gezeigt wie man s3sync auf einer ec2 Instanz einsetzt.

Jeder Benutzer kann bis zu 100 Buckets erstellen. Da die Buckets bei öffentlichen Dateien als Teil der URL erscheinen sollte man sich hier sprechende und kurze Namen überlegen (sofern diese noch frei sind). Jedes Bucket kann man wie ein logisches Laufwerk betrachten. Daher ist es auch möglich in unterschiedlichen Buckets unterschiedliche Inhalte/Strukturen zu verwenden. Es spricht also nichts dagegen mit einem S3 Benutzerkonto JungleDisk oder andere S3 basierte Tools und S3Sync parallel in getrennten Buckets zu verwenden.

Während der Evaluierungsphase habe ich neben s3cmd.rb auch S3Fox verwendet um den Inhalt meiner mit s3sync.rb gefüllten Buckets zu kontrollieren. Wie auch bei rsync schätze ich den Vorteil, dass ich die erstellten Backups - anders als bei tar oder Duplicity - direkt betrachten, kontrollieren und nutzen kann. Da jede Datei in einem Key/Blob abgelegt wird, kann man leicht einzelne Dateien restaurieren oder über die S3 ACL öffentlich zugänglich machen. Leider hat S3Fox Probleme die von s3sync gefüllten Buckets darzustellen. Im s3sync Readme (Changelog) gibt der Autor dazu folgenden Hinweis:

In the case of commands of the form:
s3sync -r somedir somebucket:
The root directory node in s3 was being stored as "somedir/" instead of "somedir"
which caused restores to mess up when you say:
s3sync -r somebucket: restoredir
The fix to this, by coincidence, actually makes s3fox work even *less* well with
s3sync. I really need to build my own xul+javascript s3 GUI some day.

Anstatt von S3Fox nutze ich nun den Mac OS X S3 Browser.

Alternativen zu S3Sync?
Für umfangreichere Backups mag der s3sync Ansatz weniger geeignet sein, denn aufgrund der Architektur von S3 muss s3sync für jede Datei einen Request an S3 senden, was viel Bandbreite und Zeit verbrauchen kann.

Aus diesem Grund wäre eigentlich Duplicity die bessere Wahl um umfangreiche Datenmengen bzw. viele Dateien auf S3 zu sichern. Duplicity verfolgt einen ganz anderen Ansatz und ist damit in der Lage sehr bandbreitenschonend Backups zu erstellen. Seit der Version 0.4.3.RC9 (2007/07/09) unterstützt Duplicity auch S3 nativ als Backend.
Für mein Vorhaben ist Duplicity jedoch weniger geeigent, da die gesicherten Dateien nicht mehr im "direkten" Zugriff in S3 verfügbar sind sondern in encrypted und signierten Archiven abgelegt werden. Da inkrementell gesichert wird, wird der erforderliche Speicherplatz immer größer da Archive nicht gelöscht werden können solange nicht eine erneute Vollständige Sicherung gemacht wird. Eine vollständige Sicherung auf S3 verbraucht jedoch wieder enorme Bandbreite / Traffic und Zeit. Und immer nur inkrementell zu sichern erscheint mir auch nicht ratsam.

Bestrebungen S3 über ein Filesystem nutzbar zu machen (S3/Fuse, JungleDisk u.a.) um dieses dann per rsync nutzen zu können erscheinen mir aber auch nicht vielversprechend, da die S3 API nur sehr grundlegende Funktionen bereitstellt (z.b. kein Seek in einem Blob; ändert sich ein Blob, so muss er komplett neu hochgeladen werden), so dass die Vorteile von rsync hier nicht ausgespielt werden können.

Allerdings wäre S3/fuse natürlich eine KillerApp. Insbesondere auch für EC2 um so ein persistentes Filesystem zu erhalten.

Verwandte weiterführende Infos gibt's in meinem Artikel "Reguläre Ausdrücke - kurz und bündig".