Category: Geeks & Co.

Äh, naja, bin ja eigentlich nur zum Schlafen hier, in meiner Berliner (Übergangs-) Wohnung, da paßt die Überschrift schon — ja, ich habe heute DSL von der ehemals italienischen Schönheit beauftragt, aber länger als 11 Monate werde ich es sowieso nicht nutzen:

1 Für Neukunden, die in den letzten 12 Monaten keinen Alice oder AOL Anschluss hatten und bis zum 31.07.2010 ein Alice DSL-Produkt kündbar 4 Wochen zum Monatsende bestellen, reduziert sich die Grundgebühr im ersten Jahr um 10 €/Mon.; Preis- und Produktdetails hier.

 
Schon schräg, damit erzwingt doch Alice die Kündigungschrift mit der Schaltung des Zuganges; aber immerhin, die Kündigungsfrist paßt zu der der Wohnung, und binnen der nächsten Monate möchte ich mir ja auch was anderes suchen – ob ich dann Alice umziehe oder gleich schon wieder auf VDSL gehe, weiß ich noch nicht. Leider möchte Alice ja für ihr IPTV nach wenigen (3?) Monaten rd. 5 EUR/Monat haben und für einen HD-Receiver richtig Schotter sehen — aber ich zahle doch nicht (nochmal) für Hardware, die nur bei einem Anbieter funktioniert und nach Abschaltung des Dienstes Elektroschrott ist‽ Nein, diese IPTV-Dienste, die nur mit proprietären SetTopBoxen funktionieren, dürft Ihr, liebe Telekom, liebe Alice/o2 und auch Vodafone gerne behalten. I will have DVB-S again, Schüssel auf Balkon/(Dach-) Terrasse ist ja immer drin.
So, nun bin ich mal gespannt, wie schnell die schöne Ex-Italienerin hier den DSL-Anschluß gebacken bekommen; die Surf-SIM soll ja binnen 5 Tagen eintrudeln — Entlastung für meine 500-MB-Tchibo-SIM ;)

Ach nö, das macht doch keinen Spaß … Am Sonntag hat mir noch mein Nachbar (in Gütersloh) seinen WPA-Key genannt, damit ich für T-Ausfälle zukünftig gewappnet bin; und was ist? Ich sperre mich, wieder einmal, aus meiner OpenWRTen Fonera aus. OpenWRT Kamikaze hat diese lustige Firewallkonfiguration, die augenscheinlich nicht angepaßt wird, wenn man munter ath0 zum WAN-Interface macht und mit eth0 bridged. Jedenfalls ist jener Fonera nun ein halber Brick; sprich, ich muß nochmal per ap51-Tools den ganzen Rotz flaschen.
Klingt ja überheblich, aber ich habe mit z. B. CIPE schon »das Internet untertunnelt«, als man noch nicht mal wußte, daß man einen Router namens WRT aufgrund von Programmierfehlern jemals würde »übernehmen« können — und jetzt scheitere ich reihenweise an dieser bekifften Lua/LuCI-Oberfläche‽ Mal ernsthaft, das kann’s doch nicht sein‽
Jedenfalls habe ich nach etlichen Stunden am Sonntag- und Monatabend jetzt die Nase voll; wenn möglich, entsorge ich den LUA-Quatsch und editiere die Konfigurationsdateien so, wie Gott es vorgesehen hat: per Hand.

Trotz Tunnel: die Fritz!Box zu Hause mag nicht mir dieser hier spielen :(

Ich finde ja die Fritz!Boxen mitterweile richtig cool, nur eine Sache nervt: dieser SIP-Registrar ist (zumindest in der alten Version, und – never change an running system – ein Update wollte ich nicht kurz vor knapp noch machen) nervig. Ich verbinde die Netze extra per OpenVPN, damit kein NAT-Gedöns Probleme machen könnte, und was ist der Dank? Genau: keine SIP-Verbindung. Naja, immerhin bei »echten« SIP-Anbietern kommt ‘ne Verbindung zustande, direkt wäre aber cooler und billiger ;)
Aber man kann wohl nicht alles haben, und im Grunde funktioniert die AVM-Software ja angenehm unkompliziert und störungsarm — sollte man auch nie unterschätzen …

Einer meiner SheevaPlugs ist ja schon notoperiert seit knapp einem Monat, und ich glaube ja eigentlich nicht mehr, daß die Netzteile das Problem sind, sondern eher die generelle Hitzeentwicklung in den kleinen Heizkästchen. Aber statt eines kostenlosen neue Netzteils stellt sich NewIT jetzt auch mein Händler, NewIT aus UK, komisch an:

We can of course supply these under your warranty, but first we need to have your failed PSU returned to us (this is a stipulation from Globalscale, we have had to buy the PSU’s and will get refunded for the failed PSU’s we return to them), before we can send out the replacement.
The charge for sending out the replacement PSU will be based on your location:
UK Customers – £2.50
EU Customers – £5.00
If you feel you are not confident to do this replacement you can of course send the unit to us for us to carry out the replacement, there will however be a charge for returning the unit to you, this will again be based on your location:
UK Customers – £ 7.00
EU Customers – £10.00

 
Also soll ich nun auf meine Kosten das defekte Netzteil nach UK schicken und für das Ersatznetzteil 2,5 UKP ablatzen? Da kommt ja ein DockStar nur wg. des Netzteils bald günstiger. Und, mal ehrlich, das sind keine Ausnahmen, das sind massenhafte Ausfälle von Netzteilen in SheevaPlugs, mithin liegt der Verdacht eines Serienfehlers nahe — aus meiner Sicht sollte die EU-Kommission ein Einfuhr- und Verkaufsverbot für GlobalScale-Produkte verhängen, nachdem diese unreife Hardware nun noch zu Folgekosten bei den Kunden führen soll.

… ich bin grade etwas unentspannt. Ich habe zwei SpeedPort W900V, umgefritzt auf (GT) Firmware-Version 29.04.70 bzw. (B) 29.04.80. Gut, vielleicht nicht ganz die Verwendung, wie Gott AVM sie vorsah, aber notfalls hätte ich auch zwei »echte« 7170 da, um den Gegenbeweis anzutreten, daß es nicht an der Hardware/Hardware-mit-nicht-vorgesehener-Software liegt …
Die FB GT ist von der Firmware erweitert, auf ihr läuft nämlich u. a. noch Asterisk und OpenVPN. Über OpenVPN hält sie (über T-VDSL, worüber ein Tunnel ins DC läuft) einen Tunnel zu einem Server in einem DataCenter aufrecht. Über diesen Tunnel werden Pakete zur FB B geroutet:

# traceroute 193.26.120.30
traceroute to 193.26.120.30 (193.26.120.30), 30 hops max, 38 byte packets
1 192.168.44.9 (192.168.44.9) 42.956 ms 43.792 ms 46.191 ms
2 dockstar-4.vpn.uu.org (192.251.226.178) 201.827 ms 203.244 ms 199.464 ms
3 dhcp-14.berlin.uu.org (193.26.120.30) 215.253 ms 204.320 ms 201.604 ms

Der Rückweg funktioniert auch:

# traceroute 192.168.44.8
traceroute to 192.168.44.8 (192.168.44.8), 30 hops max, 38 byte packets
1 gw.berlin.uu.org (193.26.120.17) 0.878 ms 0.603 ms 0.562 ms
2 gw-dockstar-4.vpn.uu.org (192.251.226.177) 166.290 ms 158.050 ms 169.237 ms
3 192.168.44.8 (192.168.44.8) 199.720 ms 191.813 ms 199.749 ms

Die Hardware in B ist einfacher, derzeit der umgefrizte SpeedPort, der an einem Linux-Server (Seagate DockStar unter UBIFS-Debian-Lenny) mit USB-3G-Modem (Huawei E160) hängt. Der DockStar macht DHCP sowie hält einen OpenVPN-Tunnel zum besagten Rechner in einem DC:

# netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.251.226.254 193.26.120.17 255.255.255.255 UGH 0 0 0 lan
195.71.106.44 193.26.120.17 255.255.255.255 UGH 0 0 0 lan
193.26.120.16 0.0.0.0 255.255.255.240 U 0 0 0 lan
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 lan
0.0.0.0 193.26.120.17 0.0.0.0 UG 0 0 0 lan

Bei der FritzBox in GT ist das etwas komplexer:

# netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.44.9 0.0.0.0 255.255.255.255 UH 0 0 0 tun1
192.0.2.46 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.251.226.30 192.168.5.2 255.255.255.255 UGH 0 0 0 lan
192.251.226.176 192.168.44.9 255.255.255.252 UG 0 0 0 tun1
192.0.2.40 192.0.2.46 255.255.255.248 UG 0 0 0 tun0
193.26.120.16 192.168.44.9 255.255.255.240 UG 0 0 0 tun1
192.168.5.0 0.0.0.0 255.255.255.0 U 0 0 0 lan
192.168.44.0 192.168.44.9 255.255.255.0 UG 0 0 0 tun1
192.168.45.0 192.168.44.9 255.255.255.0 UG 0 0 0 tun1
192.0.2.0 192.0.2.46 255.255.255.0 UG 0 0 0 tun0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 lan
0.0.0.0 192.168.5.253 0.0.0.0 UG 0 0 0 lan

Tja; eigentlich hängt die FB B als SIP-Nebenstelle an der FB GT. Nur leider funktioniert bei der Kommunikation weder bei Rufaufbau von der FB B über die FB GT ins D2-Netz (über T-ISDN an FB GT) noch bei der Anwahl der MSN der FB GT, die für den SIP-Client der FB B reserviert ist, die Tonkommunikation von FB GT zu FB B; alles, was vom DECT-Mobilteil der FB B gesendet wird, kann auf der anderen Seite des Anrufs der FB GT empfangen werden …
Ton kommt also nur, egal, in welche Richtung der Verbindungsaufbau stattfindet, von FB B zur FB GT durch. Man davon abgesehen, daß die IP-Adresse, von der aus die SIP-Pakete verschickt werden, etwas zufällig scheint (die Konfiguration wurde entsprechend angepaßt), fällt im tcpdump auf dem Tunnelterminator in der Mitte folgendes auf:

23:43:33.525597 IP 193.26.120.30.5060 > 192.168.44.8.5060: UDP, length 1098
23:43:33.587540 IP 192.168.44.8.5060 > 193.26.120.30.5060: UDP, length 422
23:43:33.827940 IP 193.26.120.30.5060 > 192.168.44.8.5060: UDP, length 387
23:43:33.998078 IP 193.26.120.30.5060 > 192.168.44.8.5060: UDP, length 1259
23:43:34.136540 IP 192.168.44.8.5060 > 193.26.120.30.5060: UDP, length 325
23:43:34.144963 IP 192.168.44.8.5060 > 193.26.120.30.5060: UDP, length 856
23:43:34.147179 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252
23:43:34.151491 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252
23:43:34.183467 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252
23:43:34.215715 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252
23:43:34.240745 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252
23:43:34.273582 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252
23:43:34.333663 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252
23:43:34.384559 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252
23:43:34.411361 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252
23:43:34.440857 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252
23:43:34.473160 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252
23:43:34.503695 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252
23:43:34.528700 IP 193.26.120.30.5060 > 192.168.44.8.5060: UDP, length 1259
23:43:34.529783 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252
23:43:34.561528 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252
23:43:34.574796 IP 193.26.120.30 > 192.168.44.8: icmp 288: 193.26.120.30 udp port 7078 unreachable
23:43:34.604628 IP 192.168.44.8.5060 > 193.26.120.30.5060: UDP, length 856

Sprich: FB GT möchte die FB B auf UDP Port 7078 ansprechen, bei FB B lauscht da aber schein’s nixe. Das würde dann auch erklären, warum kein Ton von FB GT zur FB B geht … Was ich aber auch überhaupt nicht ralle: warum sind da keine UDP-Pakete von der 193.26.120.30 (FB B) zur 192.168.44.8 (FB GT)? Einen Routingfehler kann ich eigentlich ausschließen:

dockstar-4:~# ip route show
10.64.64.64 dev ppp0 proto kernel scope link src 10.171.175.224
192.251.226.177 dev azrael proto kernel scope link src 192.251.226.178
192.251.226.30 dev ppp0 scope link
193.26.120.16/28 dev eth0 proto kernel scope link src 193.26.120.17
193.26.120.0/24 via 192.251.226.177 dev azrael
192.251.226.0/24 via 192.251.226.177 dev azrael
192.168.0.0/16 via 192.251.226.177 dev azrael
0.0.0.0/1 via 192.251.226.177 dev azrael
128.0.0.0/1 via 192.251.226.177 dev azrael
default dev ppp0 scope link 

Irgendwie macht das alles keinen Spaß *sigh*.

Hachja. Sagt mal. kann es sein, daß SIP eine echte bescheidene Erfindung ist? In Vorbereitung meiner Übersiedlung nach Berlin baue ich mir derzeit meine Netzanbindung (samt Telefonie, versteht sich) zusammen, und da ich den dortigen Hardwareaufwand minimal halten will, kommt vor Ort ein Speedport W900V, umgefritzt auf eine DECT-7170 (i. e. eine 7150, IIRC), zum Einsatz, welche über OpenVPN-Tunnel mit dem Gegenstück in Gütersloh, welche am heimischen ISDN hängt, kommunizieren soll. Die FritzBox in Berlin hängt als »Telefoniegerät am Anschluss “LAN/WLAN”« an der FritzBox in Gütersloh. Während das Raustelefonieren in beide Richtungen (also Hören und Sprechen) schon klappte, als die FB-GT nicht zur FB-B durchkam, hatte ich eben Spaß dergestalt, daß ich »in Berlin« zwar einen Anruf auf die Gütersloher Nummer annehmen konnte, Sprache vom »Gütersloh« anrufenden Handy allerdings kam nicht nach »Berlin« durch.
Nunja; wie ich dann feststellte, gab es Routingprobleme von »Berlin« nach »Gütersloh«. Warum aber die spigelbildliche Tonverbindung nicht funktionierte: keine Ahnung. Warum überhaupt die Rufannahme klappte: keine Ahnung.
Jedenfalls super zu debuggen:
GT nach B

# traceroute 193.26.120.30
traceroute to 193.26.120.30 (193.26.120.30), 30 hops max, 38 byte packets
1 192.168.44.9 (192.168.44.9) 47.611 ms 47.318 ms 43.141 ms
2 dockstar-4.vpn.uu.org (192.251.226.178) 214.321 ms 199.393 ms *
3 dhcp-14.berlin.uu.org (193.26.120.30) 201.338 ms 203.731 ms 198.400 ms

B nach GT

dockstar-4:~# traceroute fbw900v-2.uu.org
traceroute to fbw900v-2.uu.org (192.168.5.248), 30 hops max, 40 byte packets
1 gw-dockstar-4.vpn.uu.org (192.251.226.177) 319.574 ms 320.259 ms 320.401 ms
2 albert-vdsl2.uu.org (193.26.120.250) 359.448 ms 359.602 ms 359.728 ms
3 * * *
4 * * *

Falls sich jemand über die Zeiten wundert: »dockstar-4« ist mittles USB-UMTS-Stick und o2-SIM (200 MB-Angebot, bei dem u. a. auch VOIP erlaubt ist :-)) online, das Netz per OpenVPN-Tunnel aus dem Rechenzentrum in Gütersloh erreichbar. Nach Hause, ins 192.168.5er Netz geht’s aus dem DC ebenfalls per OpenVPN-Tunnel (partiell sogar per OpenVPN-in-OpenVPN …).
Gut, nachdem nun auch das bidirektionale Routing klappt …

dockstar-4:~# traceroute fbw900v-2.uu.org
traceroute to fbw900v-2.uu.org (192.168.5.248), 30 hops max, 40 byte packets
1 gw-dockstar-4.vpn.uu.org (192.251.226.177) 179.566 ms 189.495 ms 189.391 ms
2 albert-vdsl2.uu.org (193.26.120.250) 238.676 ms 278.454 ms 288.244 ms
3 192.168.5.248 (192.168.5.248) 308.005 ms 447.815 ms 447.787 ms

… sollte ja auch die bidirektionale VoIP-Kommunikation zwischen den FritzBoxen funktionieren. Aber was ist? Egal, was ich als Ton am Handy, welches die Festnetznummer anruft, welche auf das »Telefon«, aka die FritzBox Berlin, geleitet wird, einspeise: nichts kommt auf dem DECT-Mobilteil in »Berlin« an. Ton aus »Berlin« hingegen kommt super (ok, mit rd. 250ms Minimallatenz, also deutlich verzögert) auf dem »Gütersloh« anrufenden Handy an … Any clues?

Von Dirk Tostmann auf die Idee gebracht, versuche ich mich derzeit an einem Prototypen für das Umflashen eines DockStars zu einem »kleinen« SheevaPlug. Ich habe im Folgenden versucht, meine Schritte zu dokumentieren, die Idee dazu stammt, wie gesagt, von Dirk. Die nachfolgenden Schritte habe ich mittlerweile an einem zweiten DockStar ausprobiert — ohne die Console bemühen zu müssen.
Aber dennoch, auch um mich abzusichern: DON’T TRY THIS AT HOME (YET)! IT MOST CERTAINLY WILL BRICK YOUR DOCKSTAR DEVICE! Sollten einzelne Schritte fehlschlagen, z. B. das Booten der NFS-Root nicht funktionieren, ist es notwendig, die serielle Schnittstelle des DockStars zu aktivieren. You have been warned …
Ablauf:

1. Umgebung vorbereiten: uImage von sheeva.with-linux.com holen, auf dem TFTP-Server ablegen (hier als »sheeva-2.6.34-uImage«, ggf. anpassen).
2. NFS-Rootumgebung bereitstellen auf einem vom DockStar erreichbaren NFS-Server. Ich nehme dazu wieder das Debian-Lenny-Archiv; zum uImage passende Modules von sheeva.with-linux.com holen und in der NFS-Root ablegen; ebenfalls das uImage nach $NFSROOT/boot packen.
   Die Datei $NFSROOT/etc/fstab korrigieren (alles auskommentieren), $NFSROOT/etc/mtab zur Sicherheit löschen. In $NFSROOT/etc/network/interfaces die Zeilen mit eth0 auskommentieren; das Netzwerk ist bei NFS-Root schon konfiguriert, wenn die init-Skripte loslaufen (nette Falle BTW ;)). Evtl. auch $NFSROOT/etc/resolv.conf anpassen, wenn man einen lokalen Nameserver hat (Fritz!Box z. B.).
3. UBIFS erzeugen und in NFS-Root ablegen; ich habe hierzu ebenfalls das Lenny-FS genommen (um ehrlich zu sein: die NFS-Root nochmal kopiert) und insbesondere dort etc/network/interfaces angepaßt, sodaß eth0 per DHCP versorgt wird. Auch etc/hostname und etc/hosts habe ich dort angepaßt, schon um Unterschiede zur NFS-Root zu sehen.
   Erzeugung des UBIFS (im Unterverzeichnis ubifs-root-fuer-DockStar); im Ubuntu 10.04-Paket sind alle erforderlichen Binaries drin, wer auf Debian Lenny arbeitet, braucht das mtd-utils-Paket aus Debian Testing):

   cat <<eof >ubi.cfg
   [ubifs]
   mode=ubi
   image=ubifs.img
   vol_id=0
   vol_size=200MiB
   vol_type=dynamic
   vol_name=rootfs
   vol_flags=autoresize
   eof
   mkfs.ubifs -r ubifs-root-fuer-DockStar -m 2048 -e 129024 -c 4096 -o ubifs.img -x zlib
   ubinize -o ubi.img -m 2048 -p 128KiB -s 512 ubi.cfg

   Die Datei ubi.img dann ins / des NFS-Roots kopieren.

4. DockStar normal booten, IP per DHCP geben lassen. Einloggen per SSH (root, stxadmin). Dann:

   cd
   mount -o rw,remount /
   wget http://plugapps.com/os/pogoplug/uboot/blparam
   chmod 755 ./blparam
   export PATH=/sbin:/usr/sbin:/bin:/usr/bin:/root
   blparam orgbootcmd='nand read.e 0x800000 0x100000 0x300000; setenv bootargs $(console) $(bootargs_root); bootm 0x800000'
   blparam netmask=255.255.255.0
   blparam ipaddr=192.168.5.235
   blparam serverip=192.168.5.2
   blparam arcNumber=2097
   blparam mainlineLinux=yes
   blparam bootargs_end=:::DB88FXX81:eth0:none
   blparam tftpboot='tftp 0x800000 sheeva-2.6.34-uImage ; setenv bootargs $(console) root=/dev/nfs rw rootdelay=5 nfsroot=192.168.5.245:/nfs/DockStar_tmp ip=$(ipaddr):$(serverip)$(bootargs_end) ; bootm 0x800000'
   blparam bootcmd='run tftpboot'
   blparam mtdparts='orion_nand:0x100000@0x0(u-boot),0x400000@0x100000(uImage),0x2000000@0x500000(rootfs),0xDB00000@0x2500000(data)'
   blparam tftpboot='tftp 0x800000 sheeva-2.6.34-uImage ; setenv bootargs $(console) root=/dev/nfs rw rootdelay=5 nfsroot=192.168.5.245:/nfs/DockStar_tmp ip=$(ipaddr):$(serverip)$(bootargs_end) $(mtdparts) ; bootm 0x800000'

   Hier die Daten natürlich dem eigenen Umfeld entsprechend anpassen. Achtung, in dieser Konfiguration hat der NFS-Root-gebootete DockStar *kein* Default-Gateway!

5. Dann beherzt einen Reboot des DockStars durchführen.
6. Nach kurzer Zeit sollte er wieder erreichbar sein (ping aus dem gleichen Netz auf, hier, 192.168.5.235, sollte beantwortet werden), dann wieder einloggen (root, root). Der ssh-Client wird wegen falscher Keys meckern, dann entsprechend den alten löschen. (Alternativen wie eine .ssh/options überlasse ich dem geneigten Leser ;)).
   Auf dem nun per NFS-Root laufenden DockStar mal die Flashaufteilung ansehen:

   debian:~# cat /proc/mtd
   dev: size erasesize name
   mtd0: 00100000 00020000 "u-boot"
   mtd1: 00400000 00020000 "uImage"
   mtd2: 0fb00000 00020000 "root"

   Sieht gut aus. Nun wird’s haarig ;)

   route add default gw 192.168.5.2
   wget http://http.us.debian.org/debian/pool/main/m/mtd-utils/mtd-utils_20090606-1_armel.deb
   dpkg -i mtd-utils_20090606-1_armel.deb
   flash_eraseall /dev/mtd2
   ubiformat /dev/mtd2 -s 512 -f /ubi.img -y
   flash_erase /dev/mtdblock1
   flash_eraseall /dev/mtd1
   cat /boot/uImage > /dev/mtdblock1
   wget http://plugapps.com/os/pogoplug/uboot/blparam
   chmod 755 ./blparam
   ./blparam
   ./blparam bootargs_ubi='ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs'
   ./blparam newbootcmd='nand read.e 0x800000 0x100000 0x300000 ; setenv bootargs $(console) $(mtdparts) $(bootargs_ubi) ; bootm 0x800000'
   ./blparam bootcmd='run newbootcmd'

7. Nach dieser Prozedur sollte der nächste Reboot in ein Debian auf dem DockStar führen, welches als UBIFS im Flash läuft …
8. Login war bei mir aufgrund des gewählten Filesystemarchivs root, root; man sollte dementsprechend auf dem neuen System – ggf. ist nochmal wieder ein Meckern von ssh wegen der ssh-Keys zu umschiffen – noch folgendes tun:
   • Passwort von root ändern (»passwd«-Befehl)
   • Keys für ssh neu machen, z. B. so:

     rm /etc/ssh/ssh_host*
     ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ""
     ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ""

   • /etc/hostname, /etc/hosts anpassen

No animal was harmed during these procedures … No liability assumed, your mileage may vary, standard disclaimers apply …

Es ist etwas untergegangen, aber ich habe gestern beim »Public Viewing« – wie übersetzt man das eigentlich, »öffentliches Gucken«? – im Parkbad Gütersloh mehr oder minder zufällig das 4:2 4:1 Deutschlands gegen England (BTW, bei Gelegenheit mag mir mal wer erklären, warum beim »FIFA World Cup« die »Länder« »England« und »Schottland« antreten (könnten), nicht aber auch Bayern, Sachsen oder Texas …) per Motorola Milestone aufgenommen und, einmal ist immer das Erste Mal, per Pixelpile zu flickr hochgeladen:

Sicherlich kein cineastisches Highlight, und die knapp 12 MB .3gp-Video sehen nach Re-Encoding durch flickr auch nicht besser aus; aber irgendwie cool, daß das geht, finde ich das schon ;) (Ich hätte ja auch qik genommen, aber deren App wollte meine Credentials wissen; keine Ahnung, ob ich die App mal aus Frust ob der schlechten »HighQuality« entsorgt habe oder ein Update schief lief — ein Verlust ist die Löschung von qik IMHO eh’ nicht, sodaß ich sie grade vollzogen habe …)

vdr-1:~# ethtool eth1
Settings for eth1:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
Link detected: yes
vdr-1:~# mii-tool eth1
eth1: negotiated 100baseTx-FD flow-control, link ok

Mal ganz abgesehen von den uneinheitlichen Signalen, 100 MBit/sec aka 12 MByte/sec ist schon saulahm, wenn man darüber, wie ich, Mediendaten »wuppen« will.
Leider, da 1 GBit/sec im fraglichen System instabli nur funktionierte, müssen alle Daten nun durch dieses Nadelöhr. Meine Fileserver selbst sind nicht viel schneller, trotz GBit-Anbindung: die Platten hängen per USB 2.0 dran und damit sind zwischen (häufiger) 20 und (selten) knapp 30 MByte/sec für NFS realistisch.
Derzeit geht es darum, die über die Jahre »gewachsene« »Struktur« zu entfelchten und die Abhängigkeiten zu reduzieren. In der Zeit vor den billigen DockStars hatte ich immer mal wieder (1-TB-) USB-HDDs an Rechner im LAN geklemmt und als weitere Videoverzeichnisse in VDR eingebunden:

vdr-1:~# du -sh /newvideo.? | gawk '{printf("%s ", $0); systemstr=sprintf("df --portability -h %s | grep -v Filesystem ", $2); system(systemstr);}'|gawk '{printf("%-5s %s %-5s %s\n", $1, $2, $6, $3);}'
136G /newvideo.0 0 /dev/hda3
826G /newvideo.1 199M death:/data-20100401/newvideo.1
0 /newvideo.2 1.9M /dev/hdd3
3.7G /newvideo.3 199M death:/data-20100401/newvideo.3
634G /newvideo.4 0 death.uu.org:/data/newvideo.4
83G /newvideo.5 199M death:/data-20100401/tmpvideo.5
5.7G /newvideo.6 199M death:/data-20100401/newvideo.6
179G /newvideo.7 16M nslug-1:/data/tmpvideo.7
3.9G /newvideo.8 199M death:/data-20100401/newvideo.8

Wie man auch sehen kann: eine gewisse Konsoldierung hat schon stattgefunden, das Gros der Inhalte wurde auf dem Quadcore-Hausserver schon zusammengezogen, die Erfahrung zeigt aber, daß es vorteilhaft wäre, die Funktion »VMWare-Server« und »Fileserver« zu trennen, denn unterschiedliche »Anforderer« greifen zu unterschiedlichen Zeiten auf die Dienste »VMWare« und »Fileservice« zu.
Hier kommen nun die DockStars zum Zuge; einen Fileserver habe ich schon seit geraumer Zeit, und er hat mir schon viel Kummer bereitet. Aufgrund des Preisverfalls habe ich irgendwann angefangen, TB-USB-Disks »zu sammeln«, da die anfänglichen 750 GB der 4 250er HDDs im RAID-5 auch irgendwann endlich wurden. Günstige (externe) Festplatten gepaart mit wenig Zeit und dadurch induziertem erhöhen Platzbedarf – z. B. fehlte die Zeit, automatische Aufnahmem um Duplikate zu bereinigen, die Aufnahmen selbst zu schneiden (Vor- und Nachlauf, ggf. Werbepausen) – schaffen interessante neue Probleme. Denn mehr oder minder planlos an Linux-Kisten geklemmt und jene zum Fileserver erhoben — klar, das geht technisch, aber logistisch ist es ein Alptraum (sind Aufnahmen geplant? Falls ja, bis wann muß ich fertig sein, daß alle FS wieder bereitstehen?).
Der erste Schritt, hier Ordnung reinzubringen, war die Anschaffung einer neuen TB-USB-HDD und eines Linksys NSLU2 — mein nslug-1. Leider war die Plattform dermaßen unterirdisch inperformant – VDR, der MPEG-Datenströme aufzeichnet, möchte schon gerne einen konstanten Datenstrom schreiben können, auch wenn ein anderer Client grade auf das Verzeichnis zugreift –, daß ich das Projekt ad acta legte.
Erst mit den Sheeva-Plugs keimte wieder Hoffnung auf, jene als Fileserver für die Armada an USB-Platten benutzten zu können — gleichwohl wissend, daß 1 USB 2.0-Bus eine Bandbreite von ca. 480 MBit/sec hat, effektiv dort aber 1 Platte nur 20-30 MByte/sec bringt, effektiv also gut 200 MBit/sec nutzbar sind. Und, klar, daß zwei Festplatten an einem USB-Bus optimalerweise nur alternativ angesprochen werden sollten …
Meine beiden Sheeva-Plugs allerdings haben schnell ihre Aufgabe gefunden; einer als Camera-Server, einer als Heimautomatisationsbastelbasis. Je einen Seagate DockStar und einen PogoPlug »pink«, die ja auf ähnlicher Hardware basieren, habe ich mir gesichert; und der DockStar wurde bald zum Bastelprojekt …
… wobei der große Durchbruch erst mit dem Hinweis kam, daß es den »Seagate FreeAgent DockStar« für 20,– EUR bei u. a. Atelco.de gäbe — in der Folge habe ich a) mehr Gehirnschmalz in das Projekt »DockStar als normaler Linux-(Files-)Server« gesteckt und b) bislang 4 weitere DockStars gekauft.
Mittlerweile hat 1 DockStar meinen NSLU2 abgelöst; und statt unterirdischer Performance fluppen die Daten jetzt sowohl per NFS als auch per SMB/CIFS dank GBit-Anbindung und GHz-CPU …
Soweit die erfreulichen Nachrichten; beim bisherigen VDR-Server allerdings stecke ich auf 100 MBit/sec fest, was sich insbesondere dann negativ bemerkbar macht, wenn ich Sendungen, die auf NFS-Mounts liegen, schneiden will: es gibt eine merkliche Verzögerung im Abruf der jeweiligen Szenen. Aber gut, 100 MBit/sec am Fileserver erwies sich als geringes Problem, denn die servierenden kleinen Kisten aben alle GBit/sec – nur eben die angeschlossenen Sever nicht.

Nachdem ich nun mehrere DockStars mein Eigen nenne und die an verschiedensten PCs hängenden USB-HDDs nun an diesen zusammenführen möchte, habe ich an einem »frischen« DockStar eine neue Methode zur »Befreiung« ausprobiert.
Vorweg: ich benutzte einen selbstgebackenen Linux-Kernel (2.6.32.2 von kernel.org), der um die DockStar-Patches von Alexander Holler, welchen ich auf einer x86-Kiste cross-compile und den ich per tftp mit dem orginalen DockStar-uBoot boote. Aufsetzen eines TFTP-Servers, Patching sowie Cross-compiling des Kernels sind an anderen Stellen im Netz dokumentiert, ich gehe darauf hier nicht ein — unter anderem auch, um nicht falsche Hoffnungen bei Linux-Anfängern zu wecken: der (Unter-) Titel, den Alexander Holler für seinen Artikel gewählt hat – »How to brick your DockStar and void the warranty« – ist kein Scherz; die Gefahr, seinen DockStar zumindest soweit unbrauchbar zu machen, daß man mit einer seriellen Schnittstelle mit TTL-Pegel den Innereien zuleibe rücken muß, ist nach wie vor hoch!
Dies vorausgeschickt, primär als Gedächtnisstütze für mich, mein aktuelles Kochrezept:

1. An anderem Linux-PC auf einem USB-Stick oder einer USB-HDD das Filesystem erzeugen. Ich bin gemäß »Manually unpacking a tar ball of Debian on SheevaPlug« vorgegangen, also Debian Lenny (armel) auf Medium ausgepackt.
2. Dann nicht vergessen, die etc/fstab dort zu editieren, ich habe auf einem 4 GB-USB-Stick 3 GB /dev/sda1 als ext3 und den Rest als /dev/sda2 für Swap:

   /dev/sda1 / ext3 errors=remount-ro 0 1
   /dev/sda2 none swap sw 0 0

3. Die zum Kernel gehörenden lib/modules- und lib/firmware-Dateien aus dem Kernelbau in das neue Filesystem zu kopieren sollte man nicht vergessen ;)
4. Medium vom (x86-) Linuxrechner abmontieren und ggf. beschriften; dann an den ausgeschalteten DockStar stecken und diesen zum ersten Mal booten. Einloggen per ssh und dann blparam holen:

   -bash-3.2# mount -o rw,remount /
   -bash-3.2# cd
   -bash-3.2# wget http://plugapps.com/os/pogoplug/uboot/blparam
   -bash-3.2# chmod 755 ./blparam
   -bash-3.2# cp -p blparam /tmp/.cemnt/mnt_sda1/root/

   Der letzte Befehl kopiert das Binary gleich in die neue Umgebung.

5. Jetzt die Bootparameter anpassen — dabei auch diese Beispielsdaten natürlich an die lokalen Gegebenheiten ;)

   -bash-3.2# ./blparam netmask=255.255.255.0
   -bash-3.2# ./blparam ipaddr=192.168.5.236
   -bash-3.2# ./blparam serverip=192.168.5.2
   -bash-3.2# ./blparam arcNumber=2097
   -bash-3.2# ./blparam bootcmd_tftp='tftp 0x800000 uImage ; setenv bootargs root=/dev/sda1 rw rootdelay=5 rootfstype=ext3 ; bootm 0x800000'
   -bash-3.2# ./blparam bootcmd2b='setenv bootcmd run bootcmd1 ; saveenv ; run bootcmd_original'
   -bash-3.2# ./blparam bootcmd_original='nand read.e 0x800000 0x100000 0x300000; setenv bootargs $(console) $(bootargs_root); bootm 0x800000'
   -bash-3.2# ./blparam bootcmd2='setenv bootcmd run bootcmd2b ; setenv mainlineLinux no ; saveenv ; reset'
   -bash-3.2# ./blparam bootcmd1b='setenv bootcmd run bootcmd2 ; saveenv ; run bootcmd_tftp'
   -bash-3.2# ./blparam bootcmd1='setenv bootcmd run bootcmd1b ; setenv mainlineLinux yes ; saveenv ; reset'
   -bash-3.2# ./blparam bootcmd='run bootcmd1'

6. Nun noch /root/blparam bootcmd="run bootcmd1" >/dev/null 2>&1 nach /tmp/.cemnt/mnt_sda1/etc/rc.local hinzufügen und auch einmal ausführen.
7. Nach einem Reboot sollte nun das neue Linux hochkommen, Zugriff bekommt man wie folgt:
   

   When Debian has started, you can login as user root with the password root.

    

Disclaimer: Worked for me, your mileage may vary, no liability assumed. You may loose your warranty by doing this. You have been warned. Seriously, don’t try this at home!
Mein erster Versuch schlug fehl, nur jeder zweite Boot klappte, und dann in den »DockStar-Modus«; der Grund war schlicht, daß ich das FS auf dem USB-Stick weder bzgl. /etc/fstab angepaßt hatte noch die Module meines Kernels ‘rüberkopiert. Nachdem ich das nachgeholt hatte, bootete mein dockstar-3 sauber wiederholt ins Debian. Weitere Änderungen: ssh-Keys in /etc/ssh/ neugebaut – sonst hätte ja jeder DockStar identische Host-Keys – und natürlich /etc/hostname angepaßt.

Zugriff auf den DockStar per RS-232-TTL-Pegelwandler.

Immerhin, dieser dritte angefaßte DockStar war der Erste, den ich bislang nicht für den Zugang per Console öffnen mußte ;)
Hope this helps; aber, wie gesagt, zur Nachahmung nur dem empfohlen, der sich mit Linux hinreichend auskennt und der auch kein Problem damit hat, den DockStar zu öffnen und an den vorhandenen Pins einen Adapter anzuschließen, um auf die Console zugreifen zu können.
Der Vorteil im obigen Vorgehen ist für mich einerseits, daß ich im sowieso vorhandenen Netz den Kernel per tftp bereitstellen kann und es kein Vertun gibt, von welchem Medium der Kernel nun geholt werden soll (die Reihenfolge der USB-Geräte-Erkennung erscheint mir noch immer teils zufallsgesteuert?), ferner erspare ich mir das Flashen eines zweiten U-Boot in den freien Flash-Bereich des DockStar; evtl. kann man den Bereich ja später für eine initrd nutzen oder ein minimales Root-FS …
[Edit: Unter Punkt 2 stand bis 2010-06-22 02:35 noch »ext2«, was natürlich Blödsinn ist für ein ext3-FS. Das ist mir natürlich nicht aufgefallen, da man ein ext3 ja als ext2 mounten kann, was mein »dockstar-2« auch tapfer gemacht hatte … Ich habe das auf »dockstar-2« (nein, nicht »frogstar-b« ;)) geändert, ihn rebootet … und er kam brav wieder hoch, jetzt mit einem / als ext3. Danke an Detlef, den aufmerksamen Leser!]