Warning: Constant ABSPATH already defined in /home/httpd/vhosts/supercloud.ch/apfelschwein.net/wp-config.php on line 21 Februar | 2011 | linux meets öpfel

Archive for Februar, 2011


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.

Um im OS X Terminal zwischen den Tabs zu wechseln, folgende Tastenkombination benutzen:
cmd + Shift {Cursor Rechte/Links}

Das war ein weiterer Hint vom G E D U L D Dealer.

Wer auf den iTunes Store Link in iTunes verzichten möchte, kann dies in einem Terminal eingeben:

defaults write com.apple.iTunes show-store-arrow-links -bool FALSE

Dank geht an den G E D U L D Dealer, der mir diesen Tipp zugemailt hat.

Laut G E D U L D Dealer kann die Geschwindigkeit eines Dateitransfers von einem Mac auf Samba (je nachdem auch andere Shares) erhöht werden, indem folgende Mac OS X Einstellung vorgenommen wird:

sysctl -w net.inet.tcp.delayed_ack=0

Default:
sysctl -w net.inet.tcp.delayed_ack=3

Damit wird dem Betriebssystem resp. dem TCP/IP Stack mitgeteilt, dass die ACK Pakete sofort gesendet werden müssen. Ein TCP/IP Paket beinhaltet Informationen – die Window Size – wieviel Bytes noch gesendet werden können, bis zwingend ein ACK verlangt wird. Ist die Window Size == 0, darf der Sender keine Daten mehr senden. Erst muss der Empfänger ein ACK schicken, in dem wieder ein Wert > 0 für die Window Size steht. Da das Window Size Feld nur aus 16 Bit besteht und dieser Wert (2^16 -> 0 bis 65535) für die heutigen schnellen Leitungen viel zu klein ist, kommt TCP Window Scaling (wird beim TCP Handshake ausgehandelt) zum Einsatz. Damit wird die Window Size mit einem Faktor multipliziert.

Mac OS X Tiger benutzte noch nicht optimale Werte. Ab Leopard sollten diese Werte eigenlich in Ordnung sein.

Vermutlich habe ich nun viel zu viel Verwirrung gestiftet :). Vielleicht schreibe ich mal einen ausführlicheren Artikel warum diese Window Size relevant ist und wie man das messen kann, ob man davon betroffen ist.

Ein weiterer Tipp vom G E D U L D Dealer:

Wer stört sich nicht auch an den .DS_Store Dateien, die man immer wieder auf Netzwerk Shares findet, wenn man mit Windows oder Linux unterwegs ist:

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

Hier noch der offizielle Apple Support Artikel (in Englisch):
http://support.apple.com/kb/HT1629

Wieder einmal ein Tipp vom G E D U L D Dealer. Mit diesen Befehlen – die im Terminal eingegeben werden müssen – kann man den kompletten Pfad im Finder Titel einblenden:

defaults write com.apple.finder _FXShowPosixPathInTitle -bool YES && killall Finder

Ausblenden kann man den Pfad wieder mit diesem Befehl:

defaults write com.apple.finder _FXShowPosixPathInTitle -bool NO && killall Finder