ipv6 bei hetzner

Tuesday, December 30. 2014

 schon schräg. IPv6 humpelt immer noch.

Neuen root server bei hetzner bestellt (EX40 im RZ 21), Debian-77-wheezy-64-minimal drauf. Erste Aktion die neuen IPs auf dns.he.net eingetragen, host erkennt sie sofort, also als naechstes ein ssh auf den neuen Vogel. Dauert, und dauert, und .. Ok, ssh -4 neuerVogel.domain.tld: zap ist er da.

Gleich ein ping6 heise.de und 

PING heise.de(redirector.heise.de) 56 data bytes
From Debian-77-wheezy-64-minimal icmp_seq=1 Destination unreachable: Address unreachable
From Debian-77-wheezy-64-minimal icmp_seq=2 Destination unreachable: Address unreachable
From Debian-77-wheezy-64-minimal icmp_seq=3 Destination unreachable: Address unreachable
^C
--- heise.de ping statistics ---
6 packets transmitted, 0 received, +3 errors, 100% packet loss, time 5030ms
 
Na fein, Tante Google findet mir serverfault.com/questions/477471/ipv6-only-works-after-pinging-the-default-gateway mit einer Problembeschreibung, die ich voll nachvollziehen kann. Nur die dort beschriebene Lösung bleibt hier wirkungslos.
Zahllose google/test/reboot - Zyklen später bleibt als Ergebnis meiner Recherche:
- verblüffend wenige Fundstellen. IPv6 scheint wirklich kaum jemanden zu interessieren.
- der einzige auf meinem Rechner funktionierende Weg ist, den im obigen Link beschriebenen Workaround
  ping6 -I eth0 -c3  fe80::1
mit etwas sleep davor und danach in /etc/rc.local zu packen. slep 1 war zu wenig, sleep 10 tuts scheinbar.
 
Das ist doch kaum zu glauben, dass das Hetzner/debian - Image IPv6 nicht auf Anhieb klaglos hinbekommt sondern ich eine solche Krücke einsetzen muss! 
Vor gefühlt 10+ Jahren habe ich mir IPv6-Tunnel von sixxs und später he.net auf Hetzner-Server gelegt und die waren schneller benutzbar konfiguriert als das 'native' heute ...
 
 

KRDC kann kein vnc

Sunday, August 18. 2013

 Ich hatte den Remote Desktop Client krdc mit pacman -S kdenetwork-krdc allein installiert, aber es ging und ging nicht. Den gewohnten Aufruf aus der konsole lehnte er mit Verweis auf nicht unterstützte URL ab und bei manuelle Auswahl bot er nur RDP aber kein VNC an. Google wusste gar keinen Rat. Die Antwort erriet ich aus der Beschreibung im KDE-Userbase Wiki: Krdc is one of a pair of KDE programs (Krfb is the other) 

Krdc funktioniert nur, wenn kdenetwork-krfb auch installiert ist.

Arch Linux und VirtualBox

Monday, September 24. 2012

 Mal eine Nase in Arch Linux gesteckt und eine vm (unter Virtual Box 4.1.22) damit angelegt. Der erste Schritt der Installation klingt vertraut, man lädt und startet ein Live-Image. Nur, wenn man sich jetzt so was wie Mint vorgestellt hat, grafische Oberfläche und ein freundlicher Button "Installiere mich" - wird man sich etwas die Augen reiben. das Live Image startet (sehr flink!) in eine Konsole und der Rest geht zu Fuß nach den Steps des Beginners Guide. Bei der Suche nach Installationspaketen hilft www.archlinux.org/packages/

Die vm, die per default erstmal mit der "Intel Pro/1000 MT Desktop" Nic und NAT als Netzwerkeinstellung eingerichtet war, hatte ich wie üblich ein den Modus Netwerkbrücke / Bridged Networking" umgestellt, damit die vm von anderen rechnern im Lan erreichbar ist und IPv6 gleich geht. So, und nun bekam ich super lahmen Netwerktransfer. 5-10 KiB/sec, in Spitzen auch mal 15 KiB/s - ging gar nicht. Selbst im laufenden Betrieb zuück nach NAT wechseln, dem GastOS 2 min Zeit zum umstellen geben und der Trnfer sprang auf das 100- bis 300fache.

Googlen auf "arch linux virtualbox slow" ergab nicht viel, verstreute Ratschläge, den hostname in /etc/hosts einzutragen. Meine Massnahmen waren:
- hostname als fqdn setzen
- hostname in /etc/hosts eintragen
- in VBox als Netzwerk-Hardware auf virtio-net wechseln
Die ersten beiden sind ja ohnehin Teil der Installation und änderten auch nichts an dem Problem, der Wechsel auf das virtio - Netzwerk machte dagegen den grossen Unterschied aus. Ich habe später die verschiedenen Netzwerk-Karten der Reihe nach ausprobiert und alle drei Intel-Varianten lieferten die gleiche, schneckenlahme Performance.

copy/paste der Zwischenablage zwischen Host und Guest funktioniert noch nicht, ansonsten unauffällig.


update 3.11.2012:
insgesamt hat mir arch linux bei dem test so gut gefallen, dass ich wenig spaeter auch auf dem host, meinem normalen Arbeitsrechner, auf  Arch umbestiegen bin und damit derzeit recht zufrieden bin. 

Mit IPv6 sind Adressen nun nicht eben knapp und ein Interface kann etliche globale IPs haben - wie kann man Einfluss darauf nehmen, welche davon für ausgehende Verbindungen genutzt wird?

Ich fand ein nützliche Beschreibung der Auswahl, zwei Infos daraus waren mir nützlich:

- Wenn mehrere globale Adressen alle anderen Auswahlkriterien bestanden haben, nimmt Linux die zuletzt hinzugefügte.
- Man kann bestimmte Adressen als "deprecated" markieren, so dass sie bei der Auswahl nicht berücksichtigt werden.
ip -6 addr change 2001:db8:F00::BA2/128 dev eth0 preferred_lft 0
(Hm. So steht's da, aber im Test passiert etwas ganz anderes: die Adresse wird nicht als deprecated markiert, stattdessen steht da nun valid_lft forever preferred_lft forever. Statt dem beabsichtigten 'Mach schnell mal 'ne neue Adresse' ist es ein: 'Nimm jetzt immer diese' geworden, grad das Gegenteil.)

 

Nicht alles geht so, wie ich es erwartet hätte:  eine manuell (in /etc/network/interfaces) vergebene IPV6 und privacy extension. Ich würde halt gern einem Rechner eine 'nette' IPv6 verpassen, was mit dem hex-Zeichensatz und etwas leetspeak ja gut möglich ist. Ein besonders schoenes beispiel sieht man etwa mit host facebook.com  . Und gleichzeitig möchte ich für von dem Rechner ausgehende Verbindungen die privacy extensions aktivieren, also Adressen mit scope global temporary dynamic verwenden. Und das klappt nicht (verlässlich). Nach einem reboot sehe ich zuweilen eine temp Adresse verwandt, aber bald schon ist es doch die manuelle Adresse, die in den Logs auftaucht. 
cat /proc/sys/net/ipv6/conf/eth0/use_tempaddr gibt eine 2 aber ip -6 addr listet nur eine globale Adresse mit valid_lft forever preferred_lft forever.

Ist Autokonfiguration aktiv, dann bleibt die automatische IP, die ja nach einer festen Regel gebildet wird, stabil, solange man nicht mit der MAC herumspielt. (Man erkennt die automatischen IPs daran, dass an der Grenze zum letzten Drittel, also Byte 12 und 13, immer ff:fe steht.) Und dann werden für ausgehende Verbindungen auch die temporären Adressen verwandt. 

 

RetroShare unter debian squeeze 64

Tuesday, March 6. 2012

RetroShare ist ein "Sicheres Soziales Netzwerk", mit dem man Nachrichten und Dateien mit Freunden austauschen kann. Was ist das Sichere? Es kann sich nicht einfach jeder darin einklinken sondern nur Freunde, die sich gegenseitig Vertrauen aussprechen. Und deren Freunde. Ich sende meinem Freund ein Zertifikat, der installiert es auf seinem Rechner und schickt mir seinerseits sein Zertifikat, dies installiere ich bei mir. Jetzt koennen wir beide uns verbinden.

Der Grundgedanke ist, dass man nicht wie Napster, emule etc ein fuer alle offenes p2p - Netzwerk hat (wo dann gleich die Anwälte der Contentlobby mitlesen und IPs notieren) sondern nur eingeladene Freunde hineinnimmt. Aller Dateiaustausch geht dann verschluesselt und im Stillen, dann kommt es nur noch darauf an, moeglichst viele Leute mit hinein zu bekommen, damit es auch etwas zu finden gibt...

Es gibt einen Thread bei Slashdot, der die Sache diskutiert, und hier ist der Artikel dazu 

RetroShare ist opensource, fuer Windows, OsX und Ubuntu gibt es fertige Binaries bzw Repositories, fuer Debian steht nur eine veraltete version und nur für 32 Bit auf der Download-Seite, also habe ich mir den Source Tarball gezogen, entpackt und bin den Installationsanweisungen gefolgt. 

Das resultierte erst einmal in einer Fehlermeldung ("idle/idle_platform.cpp:32:38: fatal error: X11/extensions/scrnsaver.h: No such file or directory")

Etwas googlen zeigt mir wenigstens, dass ich nicht der einzige bin, andere haben den gleichen Kummer. Debian ist gut dokumentiert und so findet sich auch das package mit der fehlenden screensaver.h

apt-get install libxss-dev
apt-get install libqt4-dev g++
apt-get install libgpgme11-dev libgpg-error-dev libupnp-dev libssl-dev libgnome-keyring-dev

So alle Abhängigkeiten erfüllt liess es sich dann klaglos kompilieren. Dann kann man es von der command line starten mit ~/retroshare/retroshare-gui/src/RetroShare (Pfad ggf anpassen).
Gleich als erstes wird man zur Erstellung eines Profile, gnupg-Zertifikat und Passworteingabe geführt, wenn man das dann soweit durch hat, kann man Ordner freigeben und an den Netzwerkeinstellungen drehen.
Das war mein Weg, unter Optionen/Server/Netzwerkkonfiguration fand ich die Portnummer, an der retroShare lauscht und für diesen Port habe ich dann in der firewall des Gateway gleich eine Portumleitung zu der privaten IP des Rechners mit Retroshare eingestellt, tcp und udp. Ob die Umleitung klappt, kann man schön auf canyouseeme.org Und ja: alles IPv4.

Das änderte aber alles nichts daran, dass in der Statuszeile unten NAT rot oder gelb signalisierte und DHT rot blieb. DHT Fehler, Network bad. Leider zeigt sich RetroShare auchh nicht sehr auskunftsfreudig, was Fehlermeldungen im log (~/.retroshare/id/retro.log) angeht. Beim Herumstochern in den Sourcen kam ich dann eher zufällig darauf, dass RetroShare nach dem Kompilieren schon noch richtig installiert werden will.

Im tarball ist auch ein Unterverzeichnis  build_scripts/Debian/ mit einer make.sh, die aus den kompilierten Programmen ein .deb - Package erstellt. Der besseren Ordnung halber sollte man es vor dem start mit dem Editor des Vertrauens öffnen und gleich oben die Zeile version="0.5.1b" in die aktuell heruntergeladene  Version umschreiben. Dann führt man dies make.sh von der command line aus und hat anschliessend ein ordentliches .deb. Das kann man mit dpkg-i RetroShare_0.5.3b._debian_amd64.deb installieren und dann ist RetroShare auch mit Icon in der Rubrik Internet des KDE-startmenues installiert.

Fein! - geht nur nicht. Es ist aber nur noch ein kleiner Fehler: build_scripts und Sourcen sind sich nicht einig über die Schreibweise des Programmnamens, mal "RetroShare", mal "retroshare". So zeigt der Menüeintrag dann halt in's Leere, meine Abhilfe war auf die Schnelle, symlinks anzulegen:

ln -s /usr/bin/RetroShare /usr/bin/retroshare

ln -s /usr/share/RetroShare /usr/share/retroshare

 

Neustart, und jetzt kann man in der Statusleiste erst Nat, dann DHT auf grün wechseln sehen und dann geht der Zähler von RetroShare-Nutzern in DHT langsam nach oben. Viele sind das nicht, ich sehe 1,8 k.

Soweit die technische Seite, nun die soziale: wie finde ich Freunde?
Das steht nicht im Handbuch... 

 

update:
Nur kurz ergänzt, retroshare unter Arch Linux. Viel zu erklärenn gibt es da auch nicht, es gibt auch dafür eine Seite in AUR und so genügt der Kommandozeilen-Aufruf 
yaourt retroshare
gefolgt von der Paketauswahl (1) und, bald darauf, einer Passwort-Eingabe (für root-Rechte zur Installation). Etwas Geduld noch, weil doch einiges zu kompilieren ist.
Zwei plugins werden als neu hinzugefügt erkannt und müssen gesondert bestätigt werden.
Nach der Installation starte ich retroshare und gebe in den Einstellungen die Porteinstellungen ein, für die ich meinen firewall-Rechner schon bei der debian-Installation eingestellt hatte, account und Passwort. Fertig!

(Page 1 of 3, totaling 11 entries) » next page