linux meets öpfel

Wenn ich mich vom Arbeitsplatz entferne, will ich das mein Computer (sei es Linux, Mac OS X oder Windows) gesperrt ist. Ein Arbeitskollege hat mir mal gezeigt, wie ich das Schloss der “Menu Bar” hinzufügen kann, aber ich hab’s – wie’s halt so ist – nicht aufgeschrieben.

Damit ich das auf keinen Fall wieder suchen muss, veröffentliche ich es hier:

Das Programm “Keychain Access” öffnen.

Die “Preferences” aufrufen und “Show keychain status in menu bar” aktivieren.

Voilà, c’est ça.

Am Mittwoch wurde Mac OS X Lion veröffentlicht.

Einige Features und weitere Informationen wurde in diesem Post beschrieben

Zur Zeit stehen Upgrades von Debian Lenny auf Debian Squeeze an…

Da ich auf meinem Debian Lenny Server virtuelle Maschinen unter Xen laufen habe und auf einen fast unterbruchsfreien Upgrade angewiesen bin, habe ich den ersten Teil des Upgrades ausgiebig getestet. Es wäre gelogen, wenn mir das Ganze nicht etwas Kopfzerbrechen bereitet hätte…

Wo will ich hin:

• Debian Lenny VMs (DomU) auf Debian Squeeze aktualisieren
• Debian Lenny Xen Hypervisor (Dom0) auf Debian Squeeze aktualisieren

Der erste Teil befasst sich mit dem Upgrade der VMs. Nach einem finalen apt-get update && apt-get -u upgrade von Debian Lenny wird die sources.list für Squeeze angepasst. Anschliessend wird apt-get update && apt-get -u dist-upgrade ausgeführt. Hier kann man mehr oder weniger bestätigen, was vorgeschlagen wird (je nach installierten Applikationen kann es einige Anpassungen geben). Der Upgrade sah dann auch ziemlich gut aus. Leider kam nach einem erneuten Start der VM folgende Fehlermeldung:

dom0:~# xm create -c /etc/xen/guests/domU1.cfg
Using config file "/etc/xen/guests/domU1.cfg".
Error: Boot loader didn't return any data!

Na toll… Anzahl funktionierende VMs: -1

Nach unzähligen weiteren Versuchen (man arbeitet ja zum Glück mit LVM Snapshots und fängt mit einer Test VM an) und stundenlanger Recherche habe ich die Lösung herausgefunden.

Das Problem wird durch pygrub und grub2 verursacht. grub2 arbeitet neu mit “named partitions” und damit kommt pygrub nicht klar. Aus diesem Grund verzichten wir (vorübergehend) auf grub2 und installieren den alten grub wieder. Mehr Infos hier, hier und hier.

Die Lösung:

Nach dem Upgrade auf Debian Squeeze und vor dem Reboot muss grub-legacy installiert werden. Dabei wird auch gleich grub2 deinstalliert (ich habe die Config ebenfalls gelöscht (--purge)). Anschliessend habe ich zur Sicherheit das alte Kernel Image von Debian Lenny nochmals installiert. Dieses sollte man unbedingt zur Hand haben.

Anschliessend kann man rebooten. In meinem Fall hat das geklappt und die VM kommt wieder hoch.

Nun stellt sich die Frage was passiert, wenn nun Dom0 auf Squeeze aktualisiert wird. Ich gehe davon aus, dass man vorgängig auf allen VMs grub2 installieren muss, damit die VM auch mit Xen 4 wieder hochfährt. Das werde ich ebenfalls ausgiebig testen, um dann auf dem produktiven System keine Überraschungen erleben zu müssen.

Apple hat vor einigen Tagen einen weiteren Release von ihrem Mac OS X angekündigt. Mac OS X Lion wird ab Juli verfügbar sein.

Interessante Features (für mich) sind FileVault 2, Launchpad und die neuen Sicherheitsfeatures. Leider fehlen aber nach wie vor Focus-follows-Mouse und Auto-Raise-Window. Das vermisse ich nach wie vor…

Alle Features im Überblick sind hier zu finden.

Desweiteren haben sie ihren neuen Dienst iCloud vorgestellt. Ein weiterer Anbieter, der dem Cloud Hype nachrennt. Ich verstehe nach wie vor nicht, wie man seine Daten extern lagern kann. Hauptsache es ist cool…

Und iOS5 wurde ebenfalls noch angekündigt. Mit iOS5 ist iCloud offenbar gratis dabei… Dabei wird mein iPhone schon seit geraumer Zeit nicht mehr unterstützt und mein Wecker wird am 1. Januar 2012 einmal mehr den Dienst verwehren.

Der G E D U L D – Dealer war wieder einmal mehr aktiv. Dieses Mal ein Tipp, wie man root das Login erlaubt. Ich möchte hiermit betonen, dass dies auf keinen Fall eine gute Idee ist und man davon absehen möge.

Wenn man nur temporär als root arbeiten will, kann genauso gut folgenden Befehl verwenden, um die Bash Shell mit root Rechten zu starten:

sudo bash

Aber jetzt zum eigentlichen Vorhaben. So gehts:

Root Account aktivieren

1. Terminal öffnen
2. dsenableroot
3. Passwörter eingeben, respektive setzen.

Live sieht das so aus:

apfeleimer:~ andy$ dsenableroot
username = andy
user password:
root password:
verify root password:

dsenableroot:: ***Successfully enabled root user.

Root Account deaktivieren

1. dsenableroot -d
2. Passwort eingeben

Und das Deaktivieren sieht dann so aus:

apfeleimer:~ andy$ dsenableroot -d
username = andy
user password:

dsenableroot:: ***Successfully disabled root user.

Wer schon immer danach gesucht hat, wie man den Mac ohne Maus herumschubsen neu starten, in den Sleepmodus oder herunterfahren kann, dem sei Ctrl + Eject empfohlen.  Folgendes Menu erscheint:

Um herauszufinden unter welchem Device Name, die externe Festplatte unter Mac OS X angesprochen wird, kann man im Terminal folgenden Befehl eingeben:

diskutil list

/dev/disk0
#:                       TYPE NAME                    SIZE       IDENTIFIER
0:      GUID_partition_scheme                        *500.1 GB   disk0
1:                        EFI                         209.7 MB   disk0s1
2:                  Apple_HFS Macintosh HD            499.8 GB   disk0s2
/dev/disk1
#:                       TYPE NAME                    SIZE       IDENTIFIER
0:     Apple_partition_scheme                        *999.5 GB   disk1
1:        Apple_partition_map                         32.3 KB    disk1s1
2:                  Apple_HFS andy                    999.5 GB   disk1s2

Die erste Disk ist die interne Disk vom Macbook Pro, die zweite ist eine externe USB Festplatte.

Während der Installation schien alles perfekt zu funktionieren, doch nach dem ersten Start hatte ich ganz seltsame Probleme mit der DNS Auflösung.

Ein ntpdate swisstime.ethz.ch funktionierte nicht:

root@zelia:~# ntpdate swisstime.ethz.ch
Error resolving swisstime.ethz.ch: Name or service not known (-2)
28 Dec 16:27:34 ntpdate[1908]: Can't find host swisstime.ethz.ch: Name or service not known (-2)

28 Dec 16:27:34 ntpdate[1908]: no servers can be used, exiting


Löste man das aber manuell mit host swisstime.ethz.ch auf, klappte es:

root@zelia:~# host swisstime.ethz.ch
swisstime.ethz.ch is an alias for swisstime.ee.ethz.ch.
swisstime.ee.ethz.ch has address 129.132.2.21


Die typischen Einstellungen in /etc/resolv.conf, /etc/nsswitch waren alle in Ordnung.

Während meiner Recherche bin ich auf verschiedene Quellen aufmerksam gewordern, die die Ursache IPv6 zuschreiben. Aus diesem Grund habe ich IPv6 deaktiviert. Leider war es das noch nicht…

Dann fand ich noch den Bug #541167, der ziemlich gut mein Problem beschreibt.

Die Probleme schienen bei ntp, ntpdate und apt aufzutreten, die alle die getaddrinfo() Funktion von libc6 benutzten.

Ein tcpdump führte folgendes zu Tage:
Der funktionierende Aufruf mit host:

16:40:08.078351 IP 172.16.6.40.57131 > 172.16.6.1.53: 55253+ A? swisstime.ethz.ch. (35)
16:40:08.091726 IP 172.16.6.1.53 > 172.16.6.40.57131: 55253 2/0/0 CNAME swisstime.ee.ethz.ch., A 129.132.2.21 (78)
16:40:08.091997 IP 172.16.6.40.52537 > 172.16.6.1.53: 11428+ AAAA? swisstime.ee.ethz.ch. (38)
16:40:08.104752 IP 172.16.6.1.53 > 172.16.6.40.52537: 11428- 0/0/0 (38)
16:40:08.104859 IP 172.16.6.40.57842 > 172.16.6.1.53: 29048+ MX? swisstime.ee.ethz.ch. (38)
16:40:08.117815 IP 172.16.6.1.53 > 172.16.6.40.57842: 29048- 0/0/0 (38)

Und nun mit ntpdate, das getaddrinfo() benutzt:

16:43:36.497574 IP 172.16.6.40.45926 > 172.16.6.1.53: 40071+ A? swisstime.ethz.ch. (35)
16:43:36.497577 IP 172.16.6.40.45926 > 172.16.6.1.53: 25658+ AAAA? swisstime.ethz.ch. (35)
16:43:36.510563 IP 172.16.6.1.53 > 172.16.6.40.45926: 40071 2/0/0 CNAME swisstime.ee.ethz.ch., A 129.132.2.21 (78)
16:43:36.513496 IP 172.16.6.1.53 > 172.16.6.40.45926: 25658- 0/0/0 (35)
16:43:36.513564 IP 172.16.6.40.56470 > 172.16.6.1.53: 40071+ A? swisstime.ethz.ch. (35)
16:43:36.513613 IP 172.16.6.40.56470 > 172.16.6.1.53: 25658+ AAAA? swisstime.ethz.ch. (35)
16:43:36.526550 IP 172.16.6.1.53 > 172.16.6.40.56470: 40071 2/0/0 CNAME swisstime.ee.ethz.ch., A 129.132.2.21 (78)
16:43:36.529225 IP 172.16.6.1.53 > 172.16.6.40.56470: 25658- 0/0/0 (35)
16:43:36.529298 IP 172.16.6.40.59051 > 172.16.6.1.53: 2262+ A? swisstime.ethz.ch.lab.init0.ch. (48)
16:43:36.529347 IP 172.16.6.40.59051 > 172.16.6.1.53: 51840+ AAAA? swisstime.ethz.ch.lab.init0.ch. (48)
16:43:36.529749 IP 172.16.6.1.53 > 172.16.6.40.59051: 2262 NXDomain- 0/0/0 (48)
16:43:36.530108 IP 172.16.6.1.53 > 172.16.6.40.59051: 51840 NXDomain- 0/0/0 (48)


Es sieht effektiv danach aus, als hätte libc6 Probleme, wenn der Nameserver für den AAAA Record eine Null-Response bekommt.

Als allerletzte Option habe ich den Nameserver (interner DNS Server des Swisscom ADSL Routers [Motorola 3347]) auf die externen von Bluewin gewechselt:

root@zelia:~# cat /etc/resolv.conf
nameserver 195.186.1.111
nameserver 195.186.1.110


Und schwupps… Jetzt gehts!

Fazit: Der DNS Server des Swisscom ADSL Routers ist kaputt.