TV-Stick Sundtek MediaTV Pro

So hier mal ein kleiner Betrag zum Thema „Erfahrung mit Hardware“.

Als ich vor 2 Monaten auf der such nach Brauchbarer DVB Hardware war, machte sich schnell Ernüchterung bei mir breit. Wenn man ein Paar gesonderte Anforderungen hat, wird die Auswahl der Anbieter sehr schnell sehr klein. Größtes Problem, der native Support von Linux. Darunter verstehe ich nicht nur, dass es ein von der Community gepflegten Treiber gibt, sondern dass der Hersteller unterstützend zur Hand geht, z.b mit Dokumentation oder eigenen Patches.

Hat man diese Anforderung einmal ausgesprochen, reduziert sich der Anbietermarkt massiv. Träume wie eine DualTuner DVB-C LowProfile kann man ganz abschreiben. Ich bin dann irgendwann auf die Geräte von Sundtek gestoßen. Obwohl mir die Geräte anfangs gar nicht zusagten (USB, extern, budget-Karten) ging mir am Ende einfach die Alternativen aus.

Eine kleine „recherche“ durch deren Support-Forum stimmte mich aber fast euphorisch. Als erstes bekommt man mit, dass es sich bei den Treibern um Closed-Source Treiber handelt. Darüber kann man im ersten Moment entsetzt sein, da es zwei Dinge bedeutet. Support nur vom Hersteller und ein geschränkte Anwendungs-Architekturen. Beim weiteren lesen stößt unweigerlich auf die Liste der unterstützten Plattformen und Anwendungen. Das hat mich dann schon überrascht. Neben Anleitungen zur Installation auf Verschieden geschlossen Media-„Boxen“ gibt es eine detaillierte Liste mit welchen Applikationen der Stick getestet wurde. Darunter nicht nur die gängigen Plattformvertreter sondern auch Exoten oder gar Kombinationen die selbst von den Entwicklern noch als „experimentell“ gekennzeichnet sind. Dazu kommen ein Haufen Forenpost die auf Treiberprobleme hindeuten und meisten damit enden, dass eine neue Treiberversion released wird (zeitnah). Das ungewöhnliche daran ist, dass diese Post nicht gelöscht werden und das die Techniker detaillierte Anweisungen geben, zum Teil Zugang zu dem betroffen Kundensystem erbitten um dort zu debuggen. Sowas kenne ich sonst nur aus dem Suppportgeschöft von Großfirmen zu Großfirmen.

Positiv erwähnenswert ist, dass der Support nicht aufhört zu suchen, wenn sie ihre eigene Hardware als Fehlerquelle ausschließen können. Als ich selbst in die Verlegenheit kam, den Support zu kontaktieren gab es so lange Unterstützung bis ich wusste wo der Fehler zu suchen ist.

Die Hardware an sich ist nicht außergewöhnliches. Es handelt sich (je nach Modell) um eine Tunerkarte mit IR-Sensor. Mitgeliefert werden eine Antenne, eine kleine Fernbedienung und ein Adapterkabel für die zusätzlichen Eingänge (analog Radio,Composite usw). Erwähnenswert ist hier, das der Stick selbst im Dauerbetrieb nur Handwarm wird.. Nicht wie z.b bei meiner Pinnacle Karte. Die schon im Idle als Heizung dienen kann.

Die Treiberinstallation geht flott von der Hand. Man lädt ein install-script das ausgeführt wird. Sofort danach kann man den Stick ansprechen. Es wird alles mitgeliefert was man braucht. Profiele für die Remote-Control, die lirc ein Stellung wird gesetzt usw. Wenn man kein eigenes Setup hat, ist man wirklich sehr schnell mit der Installation durch. Für alle anderen fängt hier das „fummeln“ an. Beim Hochfahren des Sticks wird mit „Gewalt“ der Pfad in der LIRC-Config gesetzt und dieser Dienst neu gestartet. Um das zu unterdrücken, muss man den Script opt/bin/lirc.sh totlegen. In zukünftigen Treiberversionen will Sundtek das Verhalten anpassen. Das Flag um die LIRC Config abzuschalten gibt es schon, es wird nur nicht ausgewertet. Was hingegen super gelöst ist, sind die Device-Atteched/Detached-Hooks. Man muss keine firckeligen UDEV-Rules mehr schreiben oder sonst irgendwelche Klimbzüge machen um das PVR-Backend nur dann zu starten, wenn auch ein Device da ist. Der Treiber führt schön säuberlich eine Schnittstelle raus, die ein Script aufruft, wenn ein Device aufgetaucht und betriebsbereit ist. So einfach kann die Welt sein.

Daneben sind die umfassenden Einstellmöglichkeiten des Treibers erwähnenswert. Das Manual ist zwar ein wenig knapp aber im Forum gibt es eine menge Tipps wo man wie drehen muss, wenn es mal irgendwo hakt. Die Möglichkeiten reichen vom direkten ausgeben der Signalqualität über zu und abschalten von Decodieroptionen bis zum „remote mounten“ des Gerätes. Letzteres ist sehr hilfreich, wenn man den CPU des HTPC im verdacht, oder man sowohl nicht an einem HTPC entwickeln will. Dann mountet man das Gerät über das Netzwerk an seiner „Höllenmaschine“ und kann dort mal das PVR-Backend testen/weiter entwickeln.

Alles in allem bin ich positiv überrascht von der Hard/Software. Was mir nun nur noch fehlt ist eine DualTuner-Variante und eine Treiber-variante die man über apt installieren kann;)

Die wichtigesten mdadm Befehle im Überblick

cat /proc/mdstat #listet den aktuellen Status aller bekannten Raid-Devises

mdadm --detail --scan /dev/mdX #zeigt detailierte informationen eines Raid-Arrays
mdadm --examine /dev/sdX #scannt bei einem beliebigen device nach Raid-MetaInformationen
mdadm --assemble /dev/mdX /dev/sdX [/dev/sdY] ... [--force] #Startet ein Raid-Array --force auch wenn es degraded ist

mdadm --stop /dev/mdX #stop ein Raid-Array (wird benötigt um die Metadaten zu löschen!)

mdadm --manage /dev/mdX -a /dev/sdX #fügt eine neue Platte einem Array hinzu (Platte wird als spare genutzt)
mdadm --manage /dev/mdX -f /dev/sdX #markiert eine Platte als "fehlerhaft"
mdadm --manage /dev/mdX -r /dev/sdX #entfernt eine disk aus einem Array
mdadm --manage /dev/mdX -r detached #entfernt alle nicht mehr vorhandenen Disks aus einem Array raus.
mdadm --grow /dev/md/mdX --raid-devices n #nutze n-Platten für den raid (gibt Spares frei oder nutz Spares für den Raid)

mdadm --zero-superblock /dev/sdX #entfernt alle Metainformationen von einer Disk

Scriptes, Regex und die lang-Environment-Variable

Wer sich eigene bash-Scriptes schreibt und diese ab und an mit RegExes versieht wird irgendwann (freiwillig oder unfreiwilig) feststellen dass der output von manchen Programmen davon abhängt in welchem Kontext sie aufgerufen werden. Was blöd ist, da zb der cron-Daemon einen anderen Kontext hat, als der Systemadmin. Folge ein Skript funktioniert unter dem einem User aber unter dem anderen nicht… da hilft auch sudo nur bedingt.

mittels folgendem Befehl kann man in einem Skript die Umgebungssprache setzten:

LANG=en_US.utf8

c’t Sonderheft: Linux – Server Praxis

Der Heise-Verlag hat ein neues c’t-Sonderheft zum Thema Linux-Server veröffentlicht. Ich hab mir selbiges gegönnt und will hier mal kurz meine Meinung kundtun.

Wer sich das Inhaltsverzeichniss anschaut, sieht dass die Themen breit gefächert sind. Vom Aufbau eines kleinen Home/Small-Buisiness Server über dessen Betrieb bis hin zur Wartung wird alles abgedeckt, was man sich so vorstellen kann. c’t üblich wird das ganze mit schrägen Tux-Grafiken begleitet.

Der Anspruch der Artikel ist irgendwo zwischen Anfänger und „Fortgeschrittener Benutzer“ angesiedelt. Artikel die richtig ins Detail gehen fehlen leider. Gerade bei Samba und NFS4 hätte ich mir mehr Background-Informationen, Performance-Analysen und Tunning-Tipps gewünscht.

Für Leute die sich einen HomeServer hochziehen wollen oder es gerade getan haben, ist die Zeitung ein echte Stütze. Für Leute die schon länger einen Server betreiben bzw schon ein „komplexes“ Netz betreiben, gibt es nur wenig Anregungen.

Karmic Koala auf der Seashell

Hier war es eine weile sehr ruhig, dass hatte zwei Gründe. Erstens hatte ich Urlaub (die letzte Woche) zum anderen hat sich gezeigt, dass beim Netbook-Remix von Jaunty (9.04) auf Karmic (9.10) sehr viel passieren würde. Es hätte wenig Sinn gemacht, den Jaunty auf der Seashell bis zum Brechen zu optimieren, um ihn anschließend durch den Karmic zu ersetzten.

Darum dreht sich die Frage ja im Grunde. Lohnt es sich, eine funktionierende  Jaunty-Netbook-Installation durch eine Karmic zu ersetzten. Kurz und knapp: Ja. Sämtliche Funktionen der Seashell funktionieren Out-of-the-Box. Hier nochmal die Auflistung:

  • WLAN und LAN: Beide Interfaces werden erkannt und können sofort genutzt werden.
  • HotKeys/LEDS: Fast alle wichtigen HotKeys (WLAN ausschalten, usw) funktionieren tadelos. Ausnahmen Touchpad-deaktiviern
  • Suspend to Disk/Ram: laufen jetzt besser/robuster.

Diese Verbesserungen sind zu großen Teilen auf den neuen Kernel (2.6.31) zurückzuführen. Hier war der Jaunty einfach „benachteiligt“. Beim damaligen Release hat sich in zu vielen Treiberteilen, die die Netbooks betreffen, zu viel getan. Besonders hart hat es den Treiber der Intel-Grafikkarten getroffen. Dieser war im alten Kernel einfach „gebrochen“. Die Performance ist zwar immer noch hinter den Windows-Treibern aber schon erheblich besser als unter Jaunty.

Das Design und die Bedienung wurden im Detail verbessert. Es wirkt alles aufgeräumter und dezenter.

Munin und 3Ware

Hinter Munin versteckt sich ein sehr puristisches aber brauchbares Monitoring-Tool um ein ganzes Netzwerk zu überwachen. Munin besteht dabei aus zwei Teilen. Der Node und einem Crawler, der zyklisch (5 Minuten) alle bekannten Nodes abfragt. Danach werden Graphen von den gesammelten Daten über die Zeiträume Tag, Woche, Monat und Jahr erzeugt. Damit lassen sich gut Trends und Ungereimtheiten ablesen. Dazu wird noch rudimentäres „Alerting“ geboten. Über/Unter-schreitet ein „getrackter“ Wert ein vorgegebenes Limit, wird eine Warnmail ausgesendet. Zudem wird der Wert Farblich zusätzlich markiert, so das man beim Kontrollieren der Status-Webseite sofort sieht, das was im Argen liegt.

Die Node bietet dabei von Start weg überhaupt keine Funktionalität. Alles was man angezeigt bekommen will, muss via Plugins geliefert werden. Die Communitie bietet hier jedoch ein extrem umfangreiches Repertoire an schon vorhanden Plugins. Darunter auch Plugins die SNMP Quellen abfragen.

Nun bieten 3Ware einen SNMP Zugang zu allen RAID-Daten. Nur ist dies leider sehr umständlich. Da sich Plugins sehr einfach schreiben lassen, hab ich einfach drei Plugins geschrieben, die mir die wichtigsten Daten extrahieren und in Munin zur Verfügung stellen. Ich benutzte dazu „tw_cli“ welches von 3Ware mitgeliefert wird. Anschließend wird dessen Output ausgewertet und dargestellt.

die Sources gibt es hier:

  • RAID-Status: Liefert den Status aller im System bekannten RAID-Units
  • RAID-Unit-Status: Listet den Status aller physikalisch Einheiten einer RAID-Unit.
  • BBU – Status: Liefert den Status der installierten BBUs

Verschlüsselung von RAIDs

Will man einen RAID verschlüsseln, steht man vor verschiedenen Problemen. Zuallererst muss man sich klar werden, dass eine Verschlüsselung die Datensicherheit (Redundanz) gefährden kann. Tausend Backups nützen nichts wenn der Schlüssel bzw. das Schlüsselfile verloren gegangen ist. Das klingt banal, schießt einen aber ins Knie, wenn der RAID bei einem Systemausfall die wichtigen Daten am Leben hält, das Schlüsselfile aber mit ins Nirwana gegangen ist.

Umgekehrt torpediert dein RAID meist mit der schieren Masse an  Daten die Datensicherheit im Sinne des Zugriffsschutzes. Je mehr Daten man mit dem gleichen Schlüssel verschlüsselt, desto „leichter“ lässt sich der Schlüssel aus dieser Menge extrahieren. Ab 2 GByte sollte man sich intensiv damit beschäftigen, welchen Verschlüsselungsalgorithmus (Cipher) man verwenden kann und mit welcher Schlüssellänge man arbeiten sollte.

Neben solchen theoretischen Vorüberlegungen muss man sich aber auch klar werden wie man Verschlüsseln will. Welche Features will man nutzen, worauf kann man verzichten. Ich für meinen Teil hatte klare Vorstellungen von meinem Setup:

  • FullDiskEncryption (FDE): Das RAID Array soll im ganzen verschlüsselt werden.
  • Dynamische RAID-Vergrößerung: Ab gewissen Speichergrößen ist eine Verdopplung des Speichers nicht mehr praktikabel oder schlicht bezahlbar.

Beide Punkte zusammen haben jedoch ihren Knackpunkt. Nicht alle Verschlüsselungstechnologien sind bei FDE (oder überhaupt) in der Lage einmal verschlüsselte Container/Volumes in der Größe zu verändern. TrueCrypt kann dies nur bei Containern und dann mit einem Performance-Overhead, der inakzeptabel ist. Bei den OpenSource-Technologien bleibt dann nur noch dm-crypt über. Dieses hat jedoch die „Schwäche“, dass der Verschlüsselungheader (welcher Cipher, Start, Ende, etc) selber unverschlüsselt auf der Platte liegt. Sicherheitstechnisch ist das kein Problem. Auch wenn der Angreifer den Cipher kennt, beißt er sich bei den richtigen Algorithmen und Schlüssellängen die Zähne aus. Nur kann ein dm-crypt Benutzer nicht glaubhaft abstreiten, dass er eben dm-crypt nicht benutzt.

Mir war die juristische Debatte erstmal egal, ich wollte ein verschlüsseltes dynamisches RAID-Device. Das hat mich ein ganzes Wochenende gekostet (500GB auf 750GB zu migrieren dauert immer ungefähr 4 Stunden). Es hat sich mir ein zentrales Problem in den weg gestellt. Es gibt für die Konsole kein Tool, dass eine Partition vergrößern kann, dessen Dateisystem es nicht erkennt. Man kann mittels fdisk die Partitionstabelle löschen und neu schreiben. So sadomasochistisch bin ich aber nicht veranlagt. Man riskiert immer vollen Datenverlust!

Man kann den Umweg über Logical Volume Manager (LVM) gehen. Dazu wird bei einem vergrößerten Device nicht die Partition vergrößert, sondern im neuen freien Bereich einfach eine weitere Partition erstellt. Diese wird dann dem Logischen Device hinzugefügt. Arbeitet man nur mit einem Fake- oder Software-RAID, mag das akzeptabel sein. Kommt es bei diesen zu einem Stromausfall darf man eh beten. Hardware-RAIDs nutzen jedoch BBUs um Datenverlust im Fehlerfall zu unterbinden. Was mit der LVM Zwischenschicht wieder ausgehebelt währe.

Möglichkeit drei ist einfach: man nutzt keine Partitionierung. Dazu muss man einfach wie folgt sein Device „beschreiben“

sudo parted /dev/sdX
mklabel msdos
quit

Nach dieser Aktion hat man eine MSDOS – Partitionierung, aber nicht erschrecken, die verschwindet gleich wieder ;).
Jetzt kann man die Festplatte direkt verschlüsseln, was z.B. bei einer GPT – Partitionstabelle nicht geht.

sudo cryptsetup luksFormat --cipher aes-xts-plain:sha256 -s 256 -q /dev/sdX #Verschlüsselung anlegen
sudo cryptsetup luksOpen /dev/sdX someCryptDev #Verschlüsseltes Device öffnen
mkfs.ext3 /dev/mapper/someCryptDev #verschlüsseltes Device formatieren
mount /dev/mapper/someCryptDev /mnt/someCryptDevUncrypted

Beim Wiedereinhängen einfach luksFormat und mkfs weglassen, sonst blöd 😉
Interessant wird jetzt die Vergrößerung. Dazu im unter lagerten RAID erstmal das Device vergrößern. Um die neue Festplattengröße dem System bekannt zu machen muss man entweder mittels des RAID-Treibers ein rescann auslösen, man entlädt einfach den ganzen Treiber und hängt ihn wieder ein oder startet einfach neu.

sudo lsmod #alle Treiber anzeigen lassen und den RAID-Treiber raus suchen.
sudo modprobe -r
 #RAID-Treiber entladen
sudo modprobe
 #RAID-Treiber laden

Letztes geht nicht ohne das aushängen der gemountet Partition. Besser gesagt, es geht schon, bloß muss man dann mit Datenverlust rechnen. Ein Rescan sollte zu keinem Datenverlust führen, das ist jedoch Treiber-abhängig, in jedem Fall das Manual oder den Maintainer konsultieren. Für 3Ware (jetzt LSI) Raids müssen die Devices z.B. ausgehängt sein.

Ist die neue Festplattengröße im System bekannt, muss man sie nutzbar machen. Dazu gibt es zwei Möglichkeiten:

  • Online – ohne Downtime des Dateisystems: Dies benötigt ein Dateisystem, was das Vergrößern/Verkleinern „on-the-Fly“ unterstützt. Das können z.b. EXT3 oder XFS.
    sudo fdisk -lu /dev/sdX #Sektoren raus schreiben
    sudo cryptsetup status  #Offset raus schreiben
    sudo cryptsetup resize -o  -b ;
    sudo resize2fs /dev/mapper/sdX #resize des FileSystems am Beispiel EXT3
  • Offline – mit Downtime des Dateisystems: Die kann mit allen Dateisystemen durchgeführt werden, die vergrößert/verkleinert werden können. Es ist auch ein Stück komfortabler.
    sudo umount /dev/mapper/; #aushängen des verschlüsselten Devices (wenn nicht schon vor dem Scann passiert)
    sudo cryptsetup luksClose  #schließen des verschlüsselten Devices (wenn nicht schon vor dem Scann passiert)
    sudo cryptsetup luksOpen /dev/sdX  #damit ist auch schon die Vergrößerung des verschlüsselten Devise erledigt...
    sudo resize2fs /dev/mapper/ #resize des FileSystems am Beispiel EXT3/EXT2

    Beim öffnen des Device nutzt selbiges scheinbar automatisch allen verfügbaren Platz, wenn man nichts anderes (mittels resize) einstellt.

So kann kann in jedem Fall ohne viel Stress seine RAID-Device stückchenweise nach seinen Bedürfnissen erweitern. Dennoch sollte man von allen wichtigen Daten immer ein Backup haben! Zudem sollte man dieses Vorgehen ein, zwei mal geübt haben, bevor man es mit wichtigen Daten durchführt;)

3Ware installation

Das erste was nach der Installation der Hardware auffällt ist, dass der Boot-Vorgang extrem viel länger dauert. Beim ersten Start hat es locker 30 Sek gebraucht, bis das BIOS des RAID-Controllers durch war und mein Server endlich ins Linux gebootet hat. In den folgenden Boots wird das nicht viel besser.

Die Installation des 9650 ist unter Ubuntu 9.04 denkbar einfach. Auch alle anderen Distributionen werden (wenn auch nicht offiziell) ohne Probleme unterstützt. Einzig die Kernelversion 2.6.14  oder die entsprechenden Treibermodule werden vorausgesetzt. 3Ware bietet drei Möglichkeiten den RAID-Controller zu administrieren. BIOS, CLI und die 3DM -genannte webbasierte RemoteManagement – Konsole. Die Installation erfolgt problemlos, einzig eine „echte“ JavaRuntime und das Programm „bc“ werden benötigt. Beide sind aber im offiziellen Repository enthalten und man gefährdet seinen Server nicht mit Fremdquellen. Ein „kleines“ „aptitude install“ vorneweg und die Installation kann beginnen.

Hat man eine grafische Oberfläche kann man das Setup einfach so starten, steht einem nur ein Kommandozeilen-Terminal zur Verfügung muss man noch den Parameter „-console“ anhängen. Anschließend führt ein Assistent durch die Installation und nach „wenigen“ Minuten steht einem der RAID-Controller in vollen Funktionsumfang zur Verfügung.

sudo aptitute install bc
tar xfvz 3DM2_CLI-Linux-x86_64-9.5.2.tgz
sudo ./setupLinux_x64.bin -consol

Jetzt wird man durch den Assistenten geführt. Das dauert wie gesagt ein paar Minuten. Anschließend ist alles nach Wunsch installiert und konfiguriert. Will man nachträglich etwas ändern so findet man das Config-File unter /etc/3dm2/

Man muss nur noch dafür sorgen, dass die Remote – Konsole auch automatisch gestartet wird. Leider ist der mitgelieferte Startscript, der auch brav unter /etc/init.d abgelegt wird, nicht ganz Standardkonform. Es fehlen die Angaben zu Required-Start und Required-Stop. Ergo schnell die Datei mit einem Editor der Wahl geöffnet und den Header angepasst.

#!/bin/sh
#
# 3dm2:         Starts the 3ware daemon
#
# Author:       Michael Benz

#
# Default-Start: 3 4 5
# Default-Stop: S 0 1 6
# Required-Start:  $network $remote_fs $syslog
# Required-Stop:   $network $remote_fs $syslog
# Provides: tdm2
# Short-Description: 3ware Daemon
# Description: Start the 3dm2 application which logs the current state
#              of the 3ware DiskSwitch controller card, and then polls
#              for state changes.
#
# config: /etc/3dm2/3dm2.conf

Zeile 9 und 10 sind von mir eingefügt. Anschließend folgenden Befehl ausführen.

sudo update-rc.d tdm2 defaults

Nun startet die Remote-Konsole automatisch beim Systemstart mit.
Für den ersten Test startet man entweder neu oder ruft den Script manuell auf.

/etc/init.d/tdm2 start

Wenn man die Konsole aufrufen will muss man beachten, dass nur HTTPS anfragen beantwortet werden. Nach dem Login (Standartpassword: 3ware) sollte man sofort die Passwörter ändern und ein BIOS-Update einspielen. letzteres bedarf leider eines Neustarts.

Anschließend kann man seine RAID-Arrays konfigurieren.