nohostname.de Tech-Stuff

Mittlerweile bin ich von Arch Linux zu Debian gewechselt. Dort ist die Update-Politik etwas konservativer, sodass neue Versionen von Software erstmal ausgiebig getestet werden, bevor sie in den Stable-Zweig gelassen werden. Das ist für die meiste, sich eher langsam ändernde Software (z.B. das Betriebssystem selbst) vollkommen ok, jedoch für Programme, die einer laufenden Weiterentwicklung, auch hinsichtlich Sicherheitslücken, unterworfen sind, eher unpraktisch.

Deshalb habe ich mir den aktuellen Firefox/Thunderbird als Tarball direkt von mozilla.org geholt und, wie es sich für optionale Software gehört,  in /opt gepackt. Das ist grundsätzlich schön, jedoch sind bei jedem Update der beiden Programme mehrere händische Schritte notwendig. Warum also nicht automatisieren, was man automatisieren kann? Hier kommt das folgende Skript ins Spiel. Es holt abhängig vom Kommandozeilenargument ff/tb jeweils den aktuellen Firefox/Thunderbird vom Mozilla-Server und packt ihn in /opt. Außerdem wird die Rechnerarchitektur (x86/x86_64) berücksichtigt.

Das Skript kann natürlich optimiert werden, aber grundsätzlich erfüllt es seine Funktion. Viel Spass damit!

#!/bin/bash

if [ -z $1 ]
then
	echo "No arguments given - use ff or tb."
	exit 1
fi

if [ $1 = ff ]
then
	if [ `uname -m` = x86_64 ]
	then
		URL="http://releases.mozilla.org/pub/mozilla.org/firefox/releases/latest/linux-x86_64/de/"
	else
		URL="http://releases.mozilla.org/pub/mozilla.org/firefox/releases/latest/linux-i686/de/"
	fi
elif [ $1 = tb ]
then
	if [ `uname -m` = x86_64 ]
	then
		URL="http://releases.mozilla.org/pub/mozilla.org/thunderbird/releases/latest/linux-x86_64/de/"
	else
		URL="http://releases.mozilla.org/pub/mozilla.org/thunderbird/releases/latest/linux-i686/de/"
	fi
else
	echo "Wrong argument given - use ff or tb."
	exit 1
fi

mkdir .mozilla-tmp
cd .mozilla-tmp

wget -nd -r -l 1 -A .bz2 -R .txt,.html $URL
tar -xjvf *.bz2

if [ $1 = ff ]
then
	sudo rm -rf /opt/firefox
	sudo mv firefox /opt
	sudo chown -R root:root /opt/firefox
elif [ $1 = tb ]
then
	sudo rm -rf /opt/thunderbird
	sudo mv thunderbird /opt
	sudo chown -R root:root /opt/thunderbird
fi

cd ..
rm -rf .mozilla-tmp

Ich hatte vor kurzem geschrieben, dass SSH-Connects über IPv6 ewig dauern. Ich habe dann also mal den Debug-Mode angeschmissen und auf dem Server folgendes gesehen:

Aug 7 23:56:33 nohostname sshd[32134]: reverse mapping checking getaddrinfo for cl-???.ham-??.de.sixxs.net [2001:dead:beef:fff::2] failed - POSSIBLE BREAK-IN ATTEMPT!

Ein Eintrag in der /etc/hosts auf dem Server brachte die Erlösung. Problem ist, dass der Reverse-DNS einfach nicht zurück aufgelöst werden kann
Ich muss jetzt noch rausfinden, wie ich den PTR bei Sixxs ändern kann…

Ok, wenn ihr mal “schnell” irgendwo eine IP an ein Interface binden wollt, dann vergesst nicht die Netzmaske. Default ist wohl /128. Ich hab 20 Minuten gebraucht, bis ich gemerkt habe, dass sich die beiden Rechner deshalb nicht anpingen können.

Wir haben zum 31.07.2010 einen Handyvertrag gekündigt. Leider hat da etwas nicht geklappt und $PROVIDER hat am 30.07.2010 erneut die Grundgebühr für den nächsten Monat von unserem Konto abgebucht. Ärgerlich wird es, wenn dann ehemaligen Kunden kein Service geboten wird. Hier ist das, was passierte:

1. Abbuchung festgestellt
2. Rechnung online ansehen nicht mehr möglich, Account gesperrt.
3. Kundenbetreuung unter 01805 123456 (14ct./Min) hängt in einer Schleife, welche unsere Handynummer abfragt. Da diese nicht mehr gültig ist, geht die Abfrage immer wieder von vorn los. Selbst nach 4 Versuchen gibt es da kein Fallback bei denen. 2 Minuten telefoniert für nichts.
4. Im Internet http://$PROVIDER.de besucht. Unter Kontakt die 01805 – 1237654 gefunden und angerufen. Netter Kontakt, kann uns als $ALTPROVIDER-Altkunden (von $PROVIDER übernommen) aber nicht weiterhelfen. 4 Minuten telefoniert für nichts.

Jetzt habe ich gerade eine E-Mail an die Kundenbetreuung geschickt – aber mal ehrlich… 6 Minuten telefoniert. 1,5 Minuten davon mit einem Menschen. Inkl. Rufnummer, alter Rechnung, Login, Kundendaten raus suchen und Login im Servicecenter ausprobieren sind das bisher 20 Minuten meines Lebens, weil $PROVIDER trotz fristgerechter und sehr früher Kündigung die Abbuchung nicht im Griff hat. Und die glauben ernsthaft, dass ich nochmal einen Vertrag bei denen abschließe? Wir haben den Vertrag gegen so einen billig-9-Cent-für-alles-Anbieter getauscht. Das funktioniert super! Da bleiben wir auch.

NACHTRAG: Das wichtigste habe ich ja noch vergessen! Die haben nach Kündigung 3, drei, DREI mal angerufen und gefragt, ob wir nicht den Tarif wechseln wollen. Jedes mal war ich dran und habe freundlich, aber bestimmt gesagt, dass die sich bitte notieren sollen, dass wir gekündigt und kein Interesse haben.

Jetzt hab ich das mit den Meldungen hier im Blog doch wieder schleifen lassen. Leider gibt es zu dem Thema IPv6 auch nicht wirklich neues. Ich habe meinen dritten Tunnel beantragt und ein /64-Netz darauf legen lassen. Eigentlich wollte ich damit jetzt in einer virtuellen Umgebung rumspielen. Ich habe dafür auf einem Ubuntu-Rechner mit KVM/libvirt drei virtuelle Maschinen erstellt. Da die CPU keine Virtualisierungserweiterung hat, musste ich da ewig warten bis alles vorbereitet war. Ich habe dann danach ein dist-upgrade auf Jaunty gemacht und jetzt booten die virtuellen Maschinen nicht mehr, sondern bleiben bei Grub kleben.

Die SIXXS-Tunnel benutze ich regelmäßig und die funktionieren gut. Das einzige was stört ist, dass der Connect via SSH ewig dauert. Ich hatte zuerst ein DNS-Problem vermutet, ein Wechsel des DNS brachte jedoch keine Besserung. Für sachdienliche Hinweise wäre ich sehr dankbar. Ansonsten werde ich das wohl demnächst mal debuggen müssen

Kurze Info:

Ich benutze irssi als Chatclient und bin damit mindestens im IRCnet und Freenode. Beide Netze bieten Server mit IPv6 an. Damit durch meinen IPv6-Tunnel von SixXS keiner mitlesen kann, verwende ich auch noch SSL. Um das zu benutzen sind folgende Dinge in der irssi-config (~/.irssi/config) einzustellen:

[...]
servers = (
  {
    address = "lindbohm.freenode.net";   # IPv6 Server von Freenode in Schweden
    chatnet = "freenode";
    port = "7070";                                # Auf diesem Port wird nur SSL akzeptiert
    use_ssl = "yes";
    ssl_verify = "yes";                          # Gegencheck mit CA-Zertifikat
    ssl_capath = "/etc/ssl/certs";
    autoconnect = "yes";
  },
  {
    address = "eu.irc6.net";                   # IPv6 IRCNet-Server
    chatnet = "IRCnet";
    port = "6667";
    use_ssl = "yes";
  }
[...]
);
[...]
chatnets = {
  IRCnet = {
    type = "IRC";
    max_query_chans = "5";
    max_kicks = "4";
    max_msgs = "5";
    max_modes = "3";
    max_whois = "4";
  };
freenode = {
    type = "IRC";
    max_kicks = "4";
    max_msgs = "1";
    max_modes = "4";
    max_whois = "1";
};
[...]
};

settings = {
[...]
    resolve_prefer_ipv6 = "yes";                   # Bevorzugt IPv6 Adressen nach Namensauflösung verwenden. Andernfalls würde IPv4 für neue Verbindungen benutzt werden, wenn es verfügbar ist.
};

Moin!

Nachdem Hetzner im letzten Monat großflächig IPv6 zur Verfügung gestellt hat und ich sowieso schon mit einem SixXS-Tunnel gespielt hatte, wollte ich mir das mal genauer ansehen.
Wie im o.g. Artikel von Hetzner beschrieben sollte die Bestellung über den Robot einfach durchzuführen sein. Unter dem Punkt “Bestellung zusätzlicher IPs, Failover-IPs oder Subnetze” wählt man das IPv6-Netz und bestätigt die Bestellung. Nach abschicken des Formulars erhält man als Antwort… die Daten für das Netz. Superschnell. Die Einrichtung auf einem Debian-System geht manuell für eine Sitzung so:

# Zugeteiltes Netz: 2a01:4f8:61:20e1::/64
# Gateway: 2a01:4f8:61:20e0::1/59
# Verwendbare Adressen: 2a01:4f8:61:20e1::2 bis 2a01:4f8:61:20e1:ffff:ffff:ffff:ffff
# IP-Adresse die wir zum Test einrichten wollen: 2a01:4f8:61:20e1::2
host:~# ip -6 route add 2a01:4f8:61:20e0::1 dev eth0
host:~# ip -6 route add default via 2a01:4f8:61:20e0::1
host:~# ip -6 addr add 2a01:4f8:61:20e1::2 dev eth0
# Test, ob alles funktioniert
host:~# ping6 -c 4 ipv6.google.com
PING ipv6.google.com(2a00:1450:8007::67) 56 data bytes
64 bytes from 2a00:1450:8007::67: icmp_seq=1 ttl=54 time=47.4 ms
64 bytes from 2a00:1450:8007::67: icmp_seq=2 ttl=54 time=48.2 ms
64 bytes from 2a00:1450:8007::67: icmp_seq=3 ttl=54 time=47.5 ms
64 bytes from 2a00:1450:8007::67: icmp_seq=4 ttl=54 time=48.1 ms

— ipv6.google.com ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 47.474/47.861/48.248/0.430 ms

Die dauerhafte Einrichtung könnte so aussehen, dass man die oberen drei Kommandos in die /etc/network/iterfaces einträgt. Der wichtige Abschnitt in der Datei könnte dann so aussehen:

# device: eth0
auto eth0
iface eth0 inet static
address 213.239.xxx.xx
broadcast 213.239.xxx.xxx
netmask 255.255.255.224
gateway 213.239.xxx.xx

# default route to access subnet
up route add -net 213.239.xxx.xx netmask 255.255.255.224 gw 213.239.xxx.xx eth0
up ip -6 route add 2a01:4f8:61:20e0::1 dev eth0
up ip -6 route add default via 2a01:4f8:61:20e0::1 dev eth0
up ip -6 addr add 2a01:4f8:61:20e1::2 dev eth0

Ich muss zugeben, dass die Einrichtung teilweise aus dem Wiki von Hetzner geklaut ist. Sicherlich kann man das mit der Adresse auch schöner lösen. Ich berichte, wenn ich näheres weiß.

Das war es erstmal dazu

Moin zusammen,

nohostname.de ist jetzt auch via IPv6 erreichbar. Ich habe einen entsprechenden AAAA-Record angelegt:

2001:6f8:1c00:24e::2/64 nohostname.de

Vielleicht kann ja der ein oder andere schon so darauf zugreifen. Wenn nicht: Den Tunnel habe ich mir bei SIXXS.net besorgt. Die Anmeldung geht fix, nur muss man ein paar Stunden bis Tage auf die Freischaltung des Accounts und danach auf den Tunnel warten. Um den Tunnel unter Linux einzurichten, installiert man sich das Programm aiccu, welches auch in den Debian-Paketquellen verfügbar ist.
Sobald man dort den Provider (SIXXS) gewählt und seine Zugangsdaten eingegeben hat, verbindet sich aiccu und legt den Tunnel an. Üblicherweise hat man dann ein Device namens sixxs an dem man Traffic usw. ablesen kann. Übrigens: die Latenz ist bei mir um 15-20ms gestiegen.

Möglicherweise hänge ich jabber.unixgroup.de demnächst auch noch mit dran. Außerdem habe ich vor ein Netz zu beantragen, und bei mir zuhause die Rechner via IPv6 adressieren zu lassen. Ich werde berichten.

Wer mit Debian Squeeze remote einen VMWare Server in Version 1.0 administrieren will, muss sich das Paket “vmware-server-console” herunterladen. Wer dann, so wie ich, beim starten die Fehlermeldung

/usr/lib/vmware-server-console/bin/vmware-server-console: symbol lookup error: /usr/lib/libgio-2.0.so.0: undefined symbol: g_thread_gettime

erhält, hat vielleicht gute Chancen das ganze mit folgender Umgebungsvariable ohne viel Schmerz zum laufen zu bringen:

export VMWARE_USE_SHIPPED_GTK=force; vmware-server-console

Genial