Author: wusel

Ach wie nett, DeNIC kassiert für ß-Domains nun doppelt? 2008 habe ich mir meine eigene Zwei-Zeichen-DE-Domain zugelegt — über IDN, lange bevor das DeNIC diese Möglichkeit – nach einem verlorenen Rechtsstreit – auf US-ASCII-Basis schuf.
Und anders als bei den berühmt-berüchtigten Beispielen db.de und ix.de, die in den »Wirrungen« der Anfänge der deutschen TLD registriert wurden und auch nach den willkürlichen Einschränkungen des DeNICs den Namensraum betreffend nicht kassiert wurden, so gibt es für mein æß.de (xn--ss-0ia.de) keinen Bestandsschutz. Um weiterhin unter der Klarschriftadresse http://æß.de erreichbar zu sein, muß ich nun zusätzlich diese Domain nochmals registrieren (und damit für zwei IDN-Domains – æß.de in der alten Übersetzung nach æss.de => xn--ss-0ia.de sowie æß.de in der neuen, IDNAbis, Übersetzung, für die ich leider noch kein Tool gefunden habe; Verisign z. B. macht da auch heute am 27.10.2010 noch xn--ss-0ia.de draus – zahlen). Und eine Aufgabe der »alten« Übersetzung ist nicht ratsam, denn, wie DeNIC ausführt, der neue Standard ist inkompatibel zum bisherigen:

Die fehlende Rückwärtskompatibilität des neuen IDN-Standards mit dem vorherigen Standard lässt– solange nicht alle Browser und Anwendungen ihn unterstützen – keine eindeutige Adressierung von Domains mit den Zeichen(ketten) “ss“ oder “ß“ zu. […]
Änderungen infolge des neuen Standards
Entsprechend dem bisher geltenden IDN-Protokoll wurde das „ß“ in ein ASCII-kompatibles Format konvertiert, damit es vom Domain Name System (DNS) verarbeitet und bei der Registrierung von Domains verwendet werden konnte. Hat ein Internetnutzer bisher eine Domain mit „ß“ in seinen Browser eingegeben, wandelte dieser automatisch in „ss“ um, d.h. aus „straße.de“ wurde automatisch „strasse.de“. Ob diese Umwandlung in der Adresszeile für den Nutzer ersichtlich war, richtete sich nach dem verwendeten Browsertyp. Der neue IDN-Standard sieht dagegen vor, das „ß“ als selbstständiges Zeichen zu führen, so dass eine Umwandlung von „ß“ in „ss“ nicht mehr stattfindet. Dies wird konform zum neuen Standard vom DNS so realisiert. Damit sind “straße.de” und “strasse.de” nunmehr zwei unterschiedliche Domains. Das bedeutet, dass Anwendungen, die auf dem alten IDN-Standard beruhen, nicht mehr kompatibel mit dem neu eingesetzten Standard sind. Man spricht hier von fehlender Rückwärtskompatibilität.
Auswirkungen der fehlenden Rückwärtskompatibilität
Aus Nutzersicht kann diese Umstellung in einer Übergangszeit insofern zu unerwarteten Ergebnissen führen, als aktuelle Webbrowser und E-Mail-Clients zumeist noch auf dem alten IDN-Standard basieren. Je nach eingesetzter Software gelangen Nutzer bei der Eingabe von „ß“ innerhalb einer Domain demnach zu unterschiedlichen existierenden Domains. Während mit dem neuen Standard konforme Browserversionen den Nutzern die entsprechend ihrer Eingabe korrekte Seite anzeigen, werden die Nutzer älterer Versionen nach wie vor grundsätzlich auf eine Domain mit „ss“ geführt. Diese muss jedoch – unabhängig davon, ob sie auf denselben Inhaber registriert ist – nicht notwendigerweise identisch mit der angefragten „ß“-Domain sein. Wann die Browserhersteller die Neuerungen des DNS-Protokolls ebenfalls mit Updates unterstützen werden, liegt nicht im Einflussbereich von DENIC. Solange diese technische Unwägbarkeit fortbesteht, empfiehlt DENIC Interessenten an einer Domain mit dem Bestandteil „ß“ daher, diesen Umstand bei der Nutzung der Domain zu berücksichtigen.

 
Im Klartext heißt dies also, daß DeNIC sich diesmal ganz offenherzig einem neuen Standard gegenüber gibt (zu zweibuchstabigen Domains mußte DeNIC erst geklagt werden, groß anders war’s Ende der 80er nicht mit Firmendomains, die eine führende Ziffer hatten. Schon damals stand DeNIC im Widerspruch zu geltenden RFCs, die explizit sowas wie 3jean.de seit Jahren ermöglichten … nicht anders war es bis 2009 mit den zweibuchstabigen de-Domains; meine 42.to war schon seit Ende der 80er Jahre technisch problemlos konnektiert, entgegen den DeNIC-»Vorbehalten«) und einen bestehenden (im Gegensatz zum vormals nur behaupteten, aber faktisch nicht vorhandenen) Bruch gerne in Kauf nimmt, um die Domaininhaber ein zweites Mal abzukassieren.
Ein korrektes Vorgehen wäre gewesen, jeder SS-Domain die IDNAbis-Domain mit Eszett als Klon hinzuzustellen, kostenlos, versteht sich — die Kostenlosigkeit könnte man auf max. 10 Jahre ja begrenzen, wobei der Domaininhaber ja nichts für diesen technischen Unsinn kann, den sich andere ausgedacht haben. Der grundlegende Fehler war, das Eszett initial nicht zuzulassen und in ss zwangszuübersetzen; durch die – unnötige – Änderung dieser Entscheidung kommt es jetzt zu einem richtigen Kuddelmuddel. Und das DeNIC glänzt in seiner Paradedisziplin, dem Abkassieren, Stichwort DeNICdirekt …
Ach so: müßig eigentlich hinzuzufügen, daß keiner meiner beiden Registrare – joker.com und regfish.de – mir heute, am 27.10.2010, Tag 1 nach der DeNIC-Verlautbarung, æß.de in der IDNAbis-Version registrieren kann; beide zeigen mir an, daß æß.de bzw. genauer »Domain: æss.de, Domain-Ace: xn--ss-0ia.de« mir gehören … Gründliche Vorbereitung solcher »Staatsstreiche« ist etwas, was man dem DeNIC in der Vergangenheit nicht vorwerfen konnte; es scheint sich nichts geändert zu haben :( Leider mache ich mit æß.de keinen kommerziellen Umsatz, sodaß nicht einmal ein Schadensersatz in Frage kommt; und 12 EUR/Jahr (regfish) bzw. 6,30 EUR/Jahr (joker) lohnen eigentlich nicht einmal das Telefonat mit der Rechtsschutzversicherung … aber grade deshalb sollte man DeNIC hier Paroli bieten, IMHO.

Tja, der eine oder andere mag sich fragen, was eigentlich aus meinem GuruPlug geworden ist, was ich in den fünf Monaten des Besitzes mit ihm gemacht habe, nach all’ den Beiträgen zu insbesondere den Dockstars …
… und die Antwot lautet: nix. Das Ding ist ein Staubfänger, da sich der Distributor NewIT (.co.uk) nach wie vor auf Nachfrage ausschweigt, wann ich denn nun endlich mein »upgrade kit« bekommen kann, welches aus dem lautlosen »Heizkörper« (siehe auch Wills Kommentar hier) einen lärmenden macht :(
Sprich: der GuruPlug war für mich ein Griff ins Klo, wie schon im Juni angedeutet. Insofern, da das grundsätzliche Problem (die heiß werdende CPU) ja auch SheevaPlugs (bei mir: 2 von 2 Netzteilen starben innerhalb <6 Monaten; für den Ersatz des zweiten verlangt der Distributor NewIT mittlerweile Geld, obwohl unbestreitbar es extrem naheliegend ist, daß die hochgegangenen Elkos der enormen Hitzelast im Sheeva-Gehäuse geschuldet sind) betrifft sowie die die darauf aufbauenden Seagate-Geräte Dockstar und insbesondere GoFlex Net sowie GoFlex Home, welche jeweils über SATA-Ports verfügen, bin ich etwas gespannt, wie sich die Rücklaufquote bei grade den GoFlex-Kisten entwicklen wird. Mein(e) Dockstar(s) werden zwar warm, insbesondere, wenn sie 20 MByte/sec zwischen USB und Ethernet zu jonglieren haben, aber zeigen bislang keine Auffälligkeiten. Der SheevaPlug mit noch internem (Ersatz-) Netzteil (Plug Nummer 1 hat ja ein externes Netzteil seit Juni) z. B. verliert sporadisch, leider häufig, und unmotiviert seine USB-Geräte — ein Verhalten, was die (wg. oftmals /dev/sda1 als Root-FS auf USB besonders angewiesenen) Dockstars, toi, toi, toi, bislang nicht aufweisen.
Schade. Aber zum echten »Plugcomputer« ist es offensichtlich noch ein weiter Weg; ins Steckernetzteil jedenfalls gehört das Heizelement, die Marvell-Sheeva-CPU, derzeit offensichtlich nicht :(

… wird ein Kaptiel darin sicher sich um IT im allgemeinen, Linux im besonderen und meine Erfahrungen mit dem ganzen Schrott drehen. Schreiben würde ich sie auf einen altmodischen Schreibmaschine, so mit ohne Kugelkopf und Stromanschluß, just in case.
Das »Schöne« an diesem Gebiet ist nämlich, daß es nie langweilig wird; meine letzten »Herausforderungen« habe ich gemeistert, in dem ich nun alles über eth0 des Dockstars abwickle. Hierzu bekam der Port des Dockstars am GS108T im Keller auch VLAN 1, das Standard-VLAN des Switches, ‘markiert’ zugeführt (alle anderen Ports aller meiner 3 GS108T haben es als Basis-VLAN, unmarkiert), die Konfiguration des LANs wanderte von eth0 nach eth0.1 und eth0 hat nun eine 169.254er Adresse, um das IF hochzubekommen. (Wahrscheinlich geht das in Debian auch anders, aber ich war ehrlich gesagt zu faul, danach zu suchen.)
Soweit, so genial ;) Leider triggert diese Konfiguration offensichtlich einen neuen Bug in der rottigen Firmware des als unzuverlässig und fehlerhaft verrufenen Netgear GS108T: Nachdem bislang der Switch im OG gerne mal seine Managementfähigkeit abschaltete und komplett stumm wurde (HTTP-Requests liefen in den Timeout), hat nun der GS108T im UG, an dem einige Dockstars als Fileserver sowie, wie gesagt, der Dockstar-als-Router hängen, eine neue Marotte entwickelt: dieser schaltet seine Managementoberfläche nun komplett ab, sodaß die HTTP-Pakete wg. »no route to host« verenden.
Einfach großartig. Ich bin nicht wirklich überrascht; seit der besagten Umstellung läuft auch Multicast (T-Entertain) nicht mehr, genauer gesagt versagt das IGMP-Snooping des/der GT108T und der Verkehr wird stumpf an alle Ports geschickt (Broad- statt Multicast). Sobald ich den igmpproxy auf dem Dockstar starte, flooden mir alle GT108T nach wenigen Sekunden das gewählte TV-Programm an alle Ports — die der WLAN-APs eingeschlossen, was dann das WLAN dicht macht. Ach so, genau um das zu vermeiden, hatte ich mir die 3 GS108T gekauft …
Ich werde also nun den ersten Netgear GT108T wegen erwiesener Untauglichkeit und auch in Firmware 3.0.4.10 weiterhin vorhandenen Fehlern durch einen Cisco SLM2008 ersetzen; auch dieses kleine Wunderwerk der Technik soll des IGMP-Snoopings fähig sein, vielliecht schützt die Cisco-Box ja die beiden alzheimernden Netgears endlich wieder vor dem bösen Multicast … Und vielleicht setzt Cisco ja ein fehlerfreiers Switch-Kontroll-OS ein — die Hoffnung stirbt zuletzt ;)

Nach den Versionen 1 (»Holler«-Ansatz mit USB-fähigem neueren uBoot in mtd3) und 2 (UBIFS-Root in mtd3, vom Dockstar-uBoot gestartet) möchte ich heute eine dritte Variante vorstellen, wie man seinen Dockstar »um Debian erweitern« kann.
Anstatt mit mtd3, dem freien Flashbereich der Dockstars, rumzuspielen, möchte ich heute, nachdem auch die JTAG-Belegung bekannt ist und das Risiko eines dauerhaften Bricks somit geringer, das »Übel« an der Wurzel anpacken: der kastrierte leistungsarme uBoot-Loader des Dockstars.
Jeff Doozan hat es dankenswerterweise verskriptet, sodaß es eigentlich nur der Dreisprung Dockstar auspacken, das ersten Mal booten und Jeffs uBoot installieren sein sollte …

-bash-3.2# cd /tmp
-bash-3.2# wget http://jeff.doozan.com/debian/uboot/install_uboot_mtd0.sh
Connecting to jeff.doozan.com (69.163.187.226:80)
install_uboot_mtd0.s 100% |*******************************| 15859 00:00:00 ETA
-bash-3.2# chmod +x install_uboot_mtd0.sh
-bash-3.2# ./install_uboot_mtd0.sh
!!!!!! DANGER DANGER DANGER DANGER DANGER DANGER !!!!!!
If you lose power to your device while running this script,
it could be left in an unusable state.
This script will replace the bootloader on /dev/mtd0.
This installer will only work on a Seagate Dockstar or Pogoplug Pink.
Do not run this installer on any other device.
By typing ok, you agree to assume all liabilities and risks
associated with running this installer.
If you agree, type 'ok' and press ENTER to continue: ok
DISABLE POGOPLUG SERVICES
The pogoplug service includes an auto-update feature which could
be used to cripple or disable your device. It is recommended
that you disable this service.
NOTE: The pogoplug service is proprietary software
created by Cloud Engines. It is not available for use
in other distributions and will not be available in
your new linux installation even if you choose not to disable it.
Would you like to disable the pogoplug services? [Y/n] y
Applying fixes to the pogoplug environment...
Disabling the pogoplug service...
Done fixing pogoplug environment.
# checking for /uboot-original-mtd0.kwb...
# Installing /uboot-original-mtd0.kwb...
Connecting to jeff.doozan.com (69.163.187.226:80)
uboot-original-mtd0. 100% |*******************************| 49 --:--:-- ETA
Connecting to jeff.doozan.com (69.163.187.226:80)
uboot-original-mtd0. 100% |*******************************| 512k 00:00:00 ETA
# Successfully installed /uboot-original-mtd0.kwb.
# checking for /usr/sbin/blparam...
# Installing /usr/sbin/blparam...
Connecting to jeff.doozan.com (69.163.187.226:80)
blparam.md5 100% |*******************************| 42 --:--:-- ETA
Connecting to jeff.doozan.com (69.163.187.226:80)
blparam 100% |*******************************| 14168 --:--:-- ETA
# Successfully installed /usr/sbin/blparam.
# checking for /usr/sbin/nandwrite...
# Installing /usr/sbin/nandwrite...
Connecting to jeff.doozan.com (69.163.187.226:80)
nandwrite.md5 100% |*******************************| 44 --:--:-- ETA
Connecting to jeff.doozan.com (69.163.187.226:80)
nandwrite 100% |*******************************| 11500 --:--:-- ETA
# Successfully installed /usr/sbin/nandwrite.
# checking for /usr/sbin/nanddump...
# Installing /usr/sbin/nanddump...
Connecting to jeff.doozan.com (69.163.187.226:80)
nanddump.md5 100% |*******************************| 43 --:--:-- ETA
Connecting to jeff.doozan.com (69.163.187.226:80)
nanddump 100% |*******************************| 21286 00:00:00 ETA
# Successfully installed /usr/sbin/nanddump.
# checking for /usr/sbin/flash_erase...
# Installing /usr/sbin/flash_erase...
Connecting to jeff.doozan.com (69.163.187.226:80)
flash_erase.md5 100% |*******************************| 46 --:--:-- ETA
Connecting to jeff.doozan.com (69.163.187.226:80)
flash_erase 100% |*******************************| 12819 00:00:00 ETA
# Successfully installed /usr/sbin/flash_erase.
# checking for /usr/sbin/fw_printenv...
# Installing /usr/sbin/fw_printenv...
Connecting to jeff.doozan.com (69.163.187.226:80)
fw_printenv.md5 100% |*******************************| 46 --:--:-- ETA
Connecting to jeff.doozan.com (69.163.187.226:80)
fw_printenv 100% |*******************************| 652k 00:00:00 ETA
# Successfully installed /usr/sbin/fw_printenv.
# checking for /etc/fw_env.config...
# Installing /etc/fw_env.config...
Connecting to jeff.doozan.com (69.163.187.226:80)
fw_env.config.md5 100% |*******************************| 48 --:--:-- ETA
Connecting to jeff.doozan.com (69.163.187.226:80)
fw_env.config 100% |*******************************| 329 --:--:-- ETA
# Successfully installed /etc/fw_env.config.
# Attempting to auto-detect your device...Dockstar detected
# Installing uBoot
Connecting to jeff.doozan.com (69.163.187.226:80)
uboot.mtd0.kwb.md5 100% |*******************************| 49 --:--:-- ETA
Connecting to jeff.doozan.com (69.163.187.226:80)
uboot.mtd0.kwb 100% |*******************************| 512k 00:00:00 ETA
Erase Total 4 Units
Performing Flash Erase of length 131072 at offset 0x60000 done
Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000
Writing data to block 2 at offset 0x40000
Writing data to block 3 at offset 0x60000
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00080000...
## Verifying new uBoot...
Connecting to jeff.doozan.com (69.163.187.226:80)
uboot.mtd0.kwb.md5 100% |*******************************| 49 --:--:-- ETA
# Verified successfully!
# Installing uBoot environment
Warning: Bad CRC, using default environment
## Error: "ethaddr" not defined
Warning: Bad CRC, using default environment
## Error: "rescue_installed" not defined
Warning: Bad CRC, using default environment
## Error: "bootcmd_rescue" not defined
Warning: Bad CRC, using default environment
## Error: "rescue_custom_params" not defined
Warning: Bad CRC, using default environment
## Error: "usb_custom_params" not defined
Warning: Bad CRC, using default environment
## Error: "ubifs_custom_params" not defined
Connecting to jeff.doozan.com (69.163.187.226:80)
uboot.environment.md 100% |*******************************| 52 --:--:-- ETA
Connecting to jeff.doozan.com (69.163.187.226:80)
uboot.environment 100% |*******************************| 128k 00:00:00 ETA
Erase Total 1 Units
Performing Flash Erase of length 131072 at offset 0xc0000 done
Writing data to block 6 at offset 0xc0000
# Verifying uBoot environment
ECC failed: 6
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x000c0000 and ending at 0x000e0000...
Connecting to jeff.doozan.com (69.163.187.226:80)
uboot.environment.md 100% |*******************************| 52 --:--:-- ETA
# uBoot installation has completed successfully.

… wobei es erst einmal nach »Danger, Will Robinson!« aussieht. Aber die Warnungen sind wohl dem ersten Lauf und dem noch leeren Environment des neuen uBoot geschuldet, denn gesetzt wurde augenscheinlich alles:

-bash-3.2# /usr/sbin/fw_printenv
ethact=egiga0
bootdelay=3
baudrate=115200
arcNumber=2097
mainlineLinux=yes
console=ttyS0,115200
led_init=green blinking
led_exit=green off
led_error=orange blinking
mtdparts=mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)
mtdids=nand0=orion_nand
partition=nand0,2
stdin=serial
stdout=serial
stderr=serial
rescue_installed=0
rescue_set_bootargs=setenv bootargs console=$console ubi.mtd=2 root=ubi0:rootfs ro rootfstype=ubifs $mtdparts $rescue_custom_params
rescue_bootcmd=if test $rescue_installed -eq 1; then run rescue_set_bootargs; nand read.e 0x800000 0x100000 0x400000; bootm 0x800000; else run pogo_bootcmd; fi
pogo_bootcmd=if fsload uboot-original-mtd0.kwb; then go 0x800200; fi
force_rescue=0
force_rescue_bootcmd=if test $force_rescue -eq 1 || ext2load usb 0:1 0x1700000 /rescueme 1 || fatload usb 0:1 0x1700000 /rescueme.txt 1; then run rescue_bootcmd; fi
ubifs_mtd=3
ubifs_set_bootargs=setenv bootargs console=$console ubi.mtd=$ubifs_mtd root=ubi0:rootfs rootfstype=ubifs $mtdparts $ubifs_custom_params
ubifs_bootcmd=run ubifs_set_bootargs; if ubi part data && ubifsmount rootfs && ubifsload 0x800000 /boot/uImage && ubifsload 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000; fi
usb_scan=usb_scan_done=0;for scan in $usb_scan_list; do run usb_scan_$scan; if test $usb_scan_done -eq 0 && ext2load usb $usb 0x800000 /boot/uImage 1; then usb_scan_done=1; echo "Found bootable drive on usb $usb"; setenv usb_device $usb; setenv usb_root /dev/$dev; fi; done
usb_scan_list=1 2 3 4
usb_scan_1=usb=0:1 dev=sda1
usb_scan_2=usb=1:1 dev=sdb1
usb_scan_3=usb=2:1 dev=sdc1
usb_scan_4=usb=3:1 dev=sdd1
usb_init=run usb_scan
usb_device=0:1
usb_root=/dev/sda1
usb_rootfstype=ext2
usb_rootdelay=10
usb_set_bootargs=setenv bootargs console=$console root=$usb_root rootdelay=$usb_rootdelay rootfstype=$usb_rootfstype $mtdparts $usb_custom_params
usb_bootcmd=run usb_init; run usb_set_bootargs; run usb_boot
usb_boot=mw 0x800000 0 1; ext2load usb $usb_device 0x800000 /boot/uImage; if ext2load usb $usb_device 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000; else bootm 0x800000; fi
bootcmd=usb start; run force_rescue_bootcmd; run ubifs_bootcmd; run usb_bootcmd; usb stop; run rescue_bootcmd; run pogo_bootcmd; reset
ethaddr=00:10:75:XX:XX:XX

Also, Mut zur Lücke und »halt« getippt. Nach ein paar Sekunden Dockstar stromlos machen, USB-Stick oder -Platte (mit /boot/uImage in Partition 1) angeschlossen und dem Affen Zucker, also dem Dockstar Energie, gegeben …
(Als Debian-Filesystem habe ich mein NFS-Root meiner besherigen Variante auf ‘nen Stick kopiert und dann meinen aktuellen 2.6.32.2er Kernel (mit den Hollerschen Dockstar-Patches) nach /boot/uImage sowie die passende Module nach /lib/modules/2.6.32.2 auf dem USB-Medium geschoben.)
… und in der Tat, der so behandelte Dockstar bootet klaglos /boot/uImage von einem ext3-formattierten USB-Stick (1 Partition) — und auch ein »shutdown -r now« wird klaglos ausgeführt, hier hing die uBoot-läd-uBoot-lädt-von-USB-Lösung ja leider. Kühl. Wenn es jetzt noch haltbare USB-Sticks gäbe …