Wenn rdiff-backup mal streikt…

Rdiff-backup ist meine favorisierte Backuplösung. Sie hat einfach zu viele nette Feutures, allen vor ran der geringe Speicherplatzverbrauch plus der Datei-Historie. Leider hat rdiff-backup ein Problem mit seiner Stabilität.  Wenn es mal zu einem inkonsistenten Backup kommt. steht man ziemlich mit runter gelassenen Hosen da. Ich selbst leide an einem solchen Problem. Um zu ermitteln ob mit einem Backup alles in Ordnung ist muss man folgenden Befehl ausführen:

rdiff-backup --verify [BackupDir]

Liefert dieser Befehl keinen Output kann man es ruhig angehen lassen. Gibt es jedoch Meldungen wie diese hier, sollte man auf jeden Fall prüfen was mit dem Backup nicht stimmt.

Warning: Computed SHA1 digest of

doesn't match recorded digest of

Your backup repository may be corrupted!

Wenn man dem nicht traut kann man mittels folgenden Befehl einen kompletten vergleiche Quelle<>Backup anstoßen:

rdiff-backup --compare-file [SourceDir] [BackupDir]

Dieser Befehl liefert die Files, bei dehnen sich Quelle und Backup unterscheiden unabhängig davon ob sich laut Change-Time irgendwas an der Datei geändert haben sollte.
Zusätzlich gibt es noch:

rdiff-backup --compare-hash [SourceDir] [BackupDir]

Dieser macht das gleiche wie der vorherige Befehl, nur vergleicht er nur die gespeicherten Hashes mit den neu genierten der Qulle. Das hilft nichts, wenn sich die Dateien im Backup geändert haben (z.B. korruptes File-System).
Kurz wenn der „compare-file‘ Befehl sagt „alles ok“, dann kann man dem trauen. Er ist jedoch auch der aufwändigste. Jeh nach Datenmenge kann das 24 Stunden und mehr brauchen. Leider hat der Befehl auch noch einen anderen Hinkfuß. Für die Dauer der Prüfung darf die Quelle nicht geändert werden, da es sonst zu unnützen Flaschmeldungen kommt.

Hat man einmal eine Datei (oder mehrere) ermittelt die defekt im Backup gespeichert vorliegt muss man diese im Backup aktualisieren. Leider bietet rdiff-backup dafür keinen Mechanismus. So das man händisch bei allen dateien  den „mdoified“-Zeitstempel auf einen Wert nach dem letzt Backup setzt muss. Also einfach ein touch auf alle Quelldateien bei den das Backup nicht in Ordnung ist, anschließend rdiff-backup nochmal laufen lassen.

AES-XTS-PLAIN – Retest die Zweite

Wenn man Ubuntu 11.04 installiert bekommt man den neuen 2.6.38 Kernel installiert, oder man installiert sich über das Ubuntu-Kernel-Team einen Backport. Was hat das nun mit der AES-XTS-PLAIN Verschlüsselung zu tun. Nunja mit dem 2.6.38 wurde die Mehrkernfähigkeit der Verschlüsseungsalgorithmen entscheidend verbessert.  Hier nun mein kleiner Nachtest:

  • Write Char: ? 1,11 MB/s (aktuell) statt 65,85MB/s (alt)
  • Read Char: 2,5 MB/s (aktuell) statt 29,46MB/s (alt)
  • Write Block: 165,08 MB/s (aktuell) statt 133,81MB/s (alt)
  • Rewrite: 51,91 MB/s (aktuell) statt 33,14MB/s (alt)
  • Read Block: 147,34 MB/s (aktuell) statt 57,13 MB/s (alt)

Fazit: Wie gehabt ist das schreiben zufällige einzelnen Chars extrem langsam. Was dem gut gefüllten Filesystem zugeschrieben werden kann. Was jedoch auffällt ist die enorme Leistungssteigerung in den restlichen Disziplinen. Es kann nun nahezu so schnell gelesen wie geschrieben werden. Was nahezu einer Verdopplung der Lesegeschwindigkeit gleich kommt. Auch die Schreibgeschwindigkeit konnte gesteigert werden, wobei der nicht so hohe Steigerungen zu erreichen sind. Die Leistungssteigerung wird natürlich durch eine höhere Auslastung der CPU erkauft. In meinem Fall werden nun beide CPUs in Beschlag genommen. Das System blieb aber während des Test gut ansprechbar und reagierte ohne Probleme auf eingaben. Also ein reiner Zugewinn an Geschwindigkeit.

Spielen unter Ubuntu

In meinem letzten Beitrag habe ich über sie Einsetzbarkeit von Linux als Systemplattform schwadroniert. Dabei ging ich auch auf das Einsatzfeld des Desktops ein. Das Fazit war, das es noch immer „abenteuerlich“ ist, ein „normales“ Spiel unter Linux zum laufen zu bekommen. Hier mal etwas mehr Details zum Thema Zocken unter Linux (am Beispiel Ubuntu)

Da es bei diesem Thema nur so von Problemen, Schwierigkeiten und Stolpersteinen wimmelt, geh ich sie einfach der Reihe nach durch, so wie sie mir Wiederfahren sind und gehe dann auf die Lösungsansätze ein.

Grafikkarten

Dies ist ein mehr oder minder leidiges Thema. Wer es gewohnt ist, mit der aktuellen Grafikkarte zu spielen, die eben erst auf den Markt geworfen wurde, wird nicht viel spielen. Obwohl sowohl NVidia als auch AMD Linuxtreiber zur Verfügung stellen dauert es immer ein wenig bis das Top-Model auch von diesen Treiber unterstützt werden. Aber selbst dann ist der Funktionsumfang und die Einstellmöglichkeiten der Treiber weit hinter dem, was die Windowstreiber bieten. Es gibt zwar auch OpenSource Treiber für beide Grafik-Hersteller, diese haben meist jedoch eine noch hoher Verzögerung was den Support anbelangt und können kaum im 3D Bereich mithalten ((??? zu klären). Fürs spielen ist mal also auf die ClosedSource Treiber angewiesen, wenn die nicht gehen, hat man Pech gehabt.

Verfügbarkeit:

Hat man eine funktionierende 3D Umgebung OpenGL kommt das zweite große Problem: läuft das Spiel überhaupt? Das Feld für die möglichen Antworten teilt sich theoretisch in folgende Quellen auf:

  • Das Spiel liegt compilierbar vor und ist Multiplatformfähig – hier hat man den wenigstens Stress. Selbst wenn es kein Pakete für die eigene Distribution gibt, kann man das Spiel zum laufen bekommen.
  • Das Spiel liegt als Binary für Linux nativ vor – hier hängt es von der Architektur und den vorliegenden Rahmenbedienungen (verwendete libc) ab ob das Spiel läuft.
  • Spiele auf Java/Mono/Flash-Basis – Spiel einfach starten.
  • Spiele die nativ nur unter Wundows laufen – wine installieren und ausprobieren was geht.

Punkt 1-3 bekommen erst in den letzten Monaten Relevanz. Durch das Aufkommen der verschiedener Plattformen (iOS, Android) und einem wachsendem Indi Markt, rückt der Gedankte der nativen MultiPlatformfähigkeit von Spielen mehr in den Mittelpunkt. Das nützt nur alles nichts, alle aktuellen Bestseller sind Windows Spiele oder laufen gar nicht erst auf dem PC.

Wine

Und hier beginnt das Basteln. Als erste Anlaufstelle sollte app.winehq.com sein um zu schauen ob es eine Realistische Chance gibt, dass man das gewünschte Spiel/Anwendung überhaupt zum laufen bekommt. Idealerweise vor dem Kauf machen. Wenn das Wunschspiel dort nicht gelistet ist, kann man sich auf Schwierigkeiten einstellen.

Wine sollte man über das WineUbuntu-Team aus dem Launchpad (https://launchpad.net/~ubuntu-wine/+archive/ppa) installieren, da dies eine der wenigen Applikationen ist, wo man hinter der Entwicklerversion hinterherhecheln darf/muss.

Nach der Installation einmal wincfg im Terminal aufrufen und ggf. zusätzliche Verzeichnisse einbinden.

Wichtiger Hinweis: wine legt das DosDrive C: standardmäßig ins Homeverzeichniss. Wenn man selbiges nicht Sprengen will sollte man den symbolischen Link einfach umbiegen:

cd ~/.wine/dosdevices
mv c: /some/user/defined/path
ln -s /some/user/defined/path c:

Hat man das gemacht kann es losgehen. Spiel installieren, starten, zocken und Spaß haben… theoretisch. Im Problemfall gibt es wenig allgemeine Hilfe. Da wine die Functions-Calls der Anwendungen „umbiegt“ kann alles an Fehler passieren was man sich so vorstellen kann. Auch Dinge die eigentlich nicht möglich sind… 😉

Hier ein paar Lösungsansätze:

  • Die CD wird beim installieren nicht erkannt/ Installieren geht gar nicht: Versuchen aus einer VM heraus das Spiel zu installieren. Anschließen das Verzeichnis raus kopieren und versuchen die Sache so ans fliegen zu bekommen.
  • Der Kopierschutz erkennt die CD nicht/ Kopierschutz verweigert dienst: kurz und knapp – Pech gehabt. Fast alle Kopierschütze haben ein Probleme mit der Fake-Windows-Umgebung. Da hilft nur ein „patch“ aus hebelt
  • Das Spiel startet nicht, stürtzt ab, verhält sich komisch: starte das spiel von der Konsole aus. Wine logt fast alles mit, was schief geht. Schmiert das Spiel ab und es Tauchen „FixMe – ToBe Implemented“ Meldungen auf, ist der Fall klar, da ist eine Funktion noch nicht implementiert. Meist sind die Fehlermeldungen aber kryptischer. Dann kann man google bemühen oder seinen Fall bei winehq posten. Je beliebter das Spiel ist, je schneller wird sich Support einstellen.

Hat man das Spiel erst mal am Laufen und will es sich „bequem“ machen, wird es erst richtig spaßig. Der Markt da draußen ist voll von programmierbaren Zusatztastaturen, Mäusen mit X-Tasten und allerlei Sonderhardware (HOTAS-Sticks usw). Zuerst die gute Nachricht: Fast alle davon werden erkannt und angesteuert. Ob nun mein alter HOTAS Cougar, PCDash oder Tacticalboard. Nun die Schlechte: das nutzt wenig. Meist wird das ganze „programmieren“ unter Windows über den Treiber abgefackelt. Unter Linux werden die Tastencodes ganz normal ausgewertet. Mir ist noch kein praktikabler Weg bekannt, bei dem Tastencode X von Tastatur A etwas anderes macht als von Tastencode X von Tastatur B.

Bei den Mäusen sieht es da schon besser aus. Wenn der XServer prinzipiell die Tastencodes erkennt und weiterreicht, gibt es das Tool btnx um diese Tastencodes in sinnvolle Aktionen umzusetzen. Das funktioniert sehr gut. Bei keinen meiner Logitech-Mäuse musste ich auf eine Tastenfunktion verzichten.

Wenn man solche Sachen wie TrackIR einsetzten will, kämpft man auf ganz verlorenen Posten.

Fazit

So genug gesalbert, hier mein Fazit nach 2 Jahren Linux Einsatz und dem Versuch darunter zu Spielen:

  • Für Spieler die nur mit Maus und Tastatur spielen, lebensfähig sind und auf ein paar Spiele verzichten können, kann ich Linux uneingeschränkt empfehlen.
  • Spieler die eh nur ab zu zu ein paar „simple“ Spielchen spielen wollen, ebenfalls. Flash geht immer 😉
  • Ambitionierte Spieler die entweder fast jedes aktuelle Spiel mitnehmen oder diverse Sonderanforderungen haben, werden ihre liebe Not bekommen. Hier ist ein parallel betriebenes (Gamer)Windows die bessere Wahl.

Ich selbst habe eine „Erfolgsrate“ von 75% vorzuweisen. Nach dem Wechsel auf Linux hab ich meinen Spiele-Konsum ohnehin stark eingeschränkt, daher ist die Rate so hoch. Von 4 Spielen war eins gar nicht zum laufen zu bekommen (ausgerechnet eins, dass eigentlich auf OpenGL setzt):

  • Ein altes Spiel (JaggedAllience2 Wildfire) war mit kniffen zum laufen zu bekommen, seit dem läuft es anstandslos.
  • WoW wird dank „Relevanz“ extrem gut unterstützt. Hier war gar kein Gefrickel notwendig. Leider war das dazu gehörige Tacticalboard nicht sinnvoll zum laufen zu bekommen. Außerdem ist WoW verdammt langweilig geworden.
  • Combat Mission – das besagte OpenGL Spiel… bekomme ich stand heute nicht zum laufen.
  • Eve Online – läuft mit einigen Kniffen sogar im vollen DualScreen – Modus

Bei allen 3D Spielen kann ich alle Shader (sofern vorhanden) aufdrehen und alle GrafikSettings auf Anschlag stellen, die Performance ist ordentlich. Bis auf kleine Bugs gibt es nur ein Manko: ich kann kein AA zuschalten.

Vollständige Migration zu Linux

Seit nun mehr zwei Jahren betreibe ich in meinem privaten Umfeld das Projekt „nie wieder Windows“. Angefangen hat es mit dem hochziehen eines lokalen Servers als NAS, griff über auf einen HTPC und endete nun schlussendlich mit der Migration meiner Desktop-Rechner. Da ich ein recht „vielfältiges“ Aufkommen von Rechnern und Anforderungen habe, will ich mal meine Erfahrung für die niederschreiben, die ebenfalls mit dem Gedanken spielen umzusteigen.

Zu aller erst der Grund meines Wechsels. Mit dem Wechsel von XP zu Vista hat MS mal wieder die Daumenschraube an zusetzten versucht, ala „Technology XYZ“ gibt es aber nur für Vista, den alten Scheiß braucht ihr nun nicht mehr. Der Versuch auf Vista zu migrieren war eine komplette Katastrophe. Anfangs gingen nicht mal meine Standard-Eingabegeräte korrekt. Unabhängig ob die Redmonder dafür etwas konnten oder nicht, ab diesem Moment war der Umstieg von WindowsVersion zu WindowsVersion genauso „kompliziert“ wie die Migration nach Linux. Zu diesem Zeitpunkt begannen die Test und Vorbereitungen wie ein Umstieg zu Linux denn „schmerzfrei“ von statten gehen könnte.

Zu meinen Rahmenbedienungen:

  • Ich lebe zu zweit in meinem Haushalt und meine bessere Hälfte ist nicht gewillt meine „Hirngespinste“ mitzutragen. Ergo eine Umstellung muss OHNE Reibungsverluste von statten gehen.
  • Ich bin ein Spieler im Sinne von „Computerspieler“. Es gibt Zeiten da will ich die Kiste einfach nur anmachen und anfangen zu zocken. Das alles ohne viel Stress und gefummel.
  • Ich bin aber auch ein Bastler. Es muss nicht immer gleich die Ideallösung sein. Es kann auch mal kompliziert werden. Programmieren, frickeln, Betatesten all das macht mir Spaß. Auch das durchforsten von Doku, Foren und einlesen in Komplexe Sachthemen ist mir nicht Fremd.
  • Ich bin Faul. Der Endausbau sollte mit minimalen Aufwand wartbar sein.

Es hat sich schnell gezeigt, mit Linux kann man gewissen Anforderungen nur Bedingt bedienen. Gleich vorweg, wer heute in den Laden geht und ein Handelsübliches PC-Spiel aus dem Regal greift, sollte eine funktionierende Windows-Installation sein eigenen nennen oder Leidensfähig sein. Andere Anforderungen lassen sich hingegen sehr gut, teilweise sogar besser als bei Windows abbilden.

Als Plattform hab ich Ubuntu gewählt. Es bot zum Zeitpunkt der Migration den besten Mix aus Aktualität (2 Releases pro Jahr), Support (Foren, Aktive Community), Zugänglichkeit (Doku) und Wartbarkeit. Begonnen hab ich mit 9.04 und setzt aktuell auf 10.04 LTS. Alle geschilderten Erfahrungen basieren auf dieser Basis.

Homeserver

Im Bereich des Serverbetriebs spielt Linux seine volle Stärke aus. Hier merkt man einfach, aus welcher Ecke Linux kommt. Das beginnt damit, dass man einen Server komplett Remote ohne GUI installieren kann, geht weiter über die Art der Konfiguration und endet damit, dass standardmäßig nicht jeder Dödel ohne weiteres den Rechner runter fahren kann. Genug der Seitenhiebe. Konkret manifestiert sich der Vorteil von Linux gegenüber Windows im Serverbetrieb in folgenden Fakten:

  • keine Lizenzkosten. Schonmal jemand ein Win2003/Win2008/SmallBuisinessServer gekauft…
  • keine Abstriche in Funktionalität: Hier ist Linux Windows eher überlegen. Alles was man für den Heimgebrauch so braucht, gibt es für Linux eher als für Windows und meistens auch noch frei verfügbar. Beispiele: Mailserver, Postfächer, LDAP-Server, Storage-Server, Webserver, Applikation-Server, Monitoring(!!!). Eine Ausnahme Bilden die DB-Server. Sowohl ein Oracle als auch ein MySQL laufen nativ unter Linux. Bei anderen DB-Systemen (MS SQL) sieht es da schlechter aus.
  • Hardware-Support: Alle nennenswerte ServerHardware kann von Linux angesprochen werden. Ob nun eine RAID-Controller oder eine abgefahrene ISP-Schnittstelle.
  • Integration: Jeh nach Distribution kann die Verfügbarkeit von Paketen zwar abweichen, aber es gibt fast immer einen Weg fremde Pakete einzubinden. Diese werden dann Automatisch mit aktualisiert. Was heißt das konkret? Installiert man unter Windows etwas, was nicht von MS kommt (zb ein MySQL Server, WordPress als WebApp) dann sollte man beten, dass diese Software einen eigenen Update-Mechanismus hat oder man darf sich selbst darum kümmern, dass diese Software auf dem aktuellen Stand bleibt. Auf meinem Homeserver hab ich nur eine „Fremdquelle“ einbinden müssen und das war die damit mein ClamScan schneller aktualisiert wird (vom ubuntu-dev-team)! Ich hab nicht ein Paket installieren müssen, dass nicht vom Distributor gekommen ist. Und selbst wenn (auf Clients z.B.) kümmert sich das System automatisch darum, dass diese Software aktuell bleibt. Solange man nicht an der Paketverwaltung vorbei installiert, kann man über eine automatisches Update die Kiste aktuell halten (und sogar den eventuell nötigen Reboot kann man automatisieren). Der Wartungsaufwand ist minimal.
  • Die Logs werden an einer Stelle abgelegt. Dafür kann MS zwar nix. Aber (fast) alle Dienste unter Linux nutzen einen weg Log-Files abzulegen. Gerade im Fehlerfall ist extrem angenehm nur an einer Stelle suchen zu müssen. Dem Windowsadmin ist Luxus leider nicht vergönnt.

Kurzum ich betreibe seit zwei Jahren einen Server mit Linux und bin jedes mal froh mich für Linux entschieden zu haben, wenn ich gezwungen werden einen Windowsserver zu verwalten (beruflich).

HTPC/MediaPC

Hier wird eine klare Empfehlung schon schwieriger. Auf der einen Seite ist hier das klare Problem der Hardware zu nennen. Nicht mehr jede Hardware funktioniert unter Linux. Ob nun TV, Sound, Grafikkarte oder Fernbedienungs- (IR/RF‘)-Empfänger, man muss immer vor dem Kauf der Hardware überprüfen ob diese auch unterstützt wird. Dazu kommt (in Deutschland) ein rechtliches Problem. Hier ist es per Gesetz verboten ein „wirksamen“ Kopierschutz zu umgehen. Was das im konkreten Streitfall bedeutet überlasse ich den Juristen. Praktisch bedeutet es, dass man sowohl beim anschauen von DVDs (CSS), BlueRay (AACS,VEIL,BD+) oder abspielen von Streams (FlashProtection) immer ein rechtliches Problem an der Backe haben kann. Technisch sieht die Abspielproblematik wie folgt aus:

  • DVD: kann ohne Einschränkung abgespielt werden.
  • BlueRay: Direkt abgespielt werden können nur BDs ohne DRM. Kommt DRM zum Einsatz muss man diesen aktiv brechen (rippen/entschlüsseln/umpacken). Ein direktes abspielen ist noch nicht möglich.
  • Streams: hier kommt es darauf an was für Streams verwendet werden. Fast alle Streams können „irgendwie“ abgespielt werden. Einzig Streams basiert auf Microsofts Silverligt Technologie (MaxDome) sind gar nicht abspielbar.
  • TV: Sowohl Analog, DVB, SD, HD und sogar PayTV sind abspielbar.

Neben diesem Unwägbarkeiten gibt es jedoch auch ein paar Vorteile:

  • Maximale Anpassbarkeit: Booten in unter 10 Sec (PowerOff), Betrieb ohne Fenstermanager direkt in das MediaCenter.
  • Breite Auswahl an „MediaCentern“, PVR-Backends und anderen sinnvollen Dingen.
  • Einfache Wartung (unterlagerte updates, ein Aufpoppen ala „Rechner jetzt Neustarten“ währen eines Films ist einfach scheiße)
  • Große Community

Das Abspielen von von FullHD Material ist problemlos möglich. Entweder hat man einen performanten CPU unter der Haube oder hat eine GPU mit Beschleuniger-Funktion. Auch hier sollte man sich vorab Informieren ob der die verwendete GPU unterstützt wird.

Fazit: mit entsprechender Vorbereitung läuft man in kein offenes Messer. Es stehen einem allle Möglichkeiten offen. Ich selbst betreibe nun seit einigen Monaten einen HTPC auf Linux Basis und hab bis jetzt noch keine Abstriche machen müssen.  Allerdings waren meine Ziele auch der Vorklärung angepasst.

Arbeitsstation/Desktop/Laptop

Der Punkt mit dem größten Risiko. Zum einen trifft man hier auf einefahrene Anwenungsmuster der Anwender zum anderen auf einen unkontrolierbaren Fundus an Hardware. Beim versuch zu Migrireren bin ich in zwei Schritten vorgangen. Erstmal einen Testrechner migriert (meine Arbeitsstation) und getestet „wie sich das anfühlt“. Danach hat sich folgendes Fazit eingestellt:

  • Handelsübliche Anwendungen wie Surfen, E-Mail, normale Office Anwenungen sowie der Großteil der Unterhaltungs-Anwendungen funktionieren Problemlos.
  • Spezialanwendungen: Hat man unter Windows eine bestimmte Anwendung gefunden, die man nicht mehr missen/ersetzten möchte, wird man Probleme bekommen. Einige Anwengunen lassen sich mit Wine zum Laufen zu bekommen. bei weiten aber nicht alle. Man muss sich entweder davon Verabschieden oder weiterhin Windows paralel betreiben.
  • Gaming: Das momentane Killerargument. Ein Teil der Spiele läuft unter Wine. Das ist aber jeh nach Spiel mit mehr oder minder viel „basteln“ verbunden. Im schlimmsten Fall pflegt man für jedes Spiel sein eigenes Setup. Wie auch bei den Filmen muss man ebenfalls fast immer DRM-Systeme umgehen um überhaupt was zum laufen zu bekommen.

Als Folge dessen habe ich auf allen Rechner auf den auch gespielt wird parallel ein Windows laufen. Da immer weniger gespielt wird, wird der Bedarf sinken. Die paar Spiele die noch anfallen, laufen unter Wine und lassen sich dort Verwalten. Das ist aber ein Prozess auf Zeit und geschieht ohen Druck. Für alles andere kommt ein Ubuntu-Linux zum Einsatz. Bei meiner „besseren Häfte“ geschah die Umstellung im Zuge eines „Windows muss mal wieder neu Installiert werden “ – Zykluses.  Seit diesem „Ereigniss“ gab es zwar kleineren Klärungsbedarf (Sicherheitskonzept usw) aber das ging alles Problemlos über die Bühne. Die Ständigen Bluescreens bei Windows (durch einen defekten Treiber) tun ihr übriges zur Akzeptans.

Zum Einsatz auf Geräten ohne „Spielehintergrund“ geht das alles entspannter zu, Dort gibt es nur die Frage, wird die Hardware von Linux unterstützt: wenn Ja gut, wenn Nein schlecht. Das muss man sich vorher, wie beim HTPC, informieren.

Fazit: Wenn man es mit bedacht angeht und seine Grenzen kennt (und vor allem die der Mitteilnehmer) kann man Linux sinnvoll in seine Heimumgebung integrieren. Auf der „Pro“ Seite hat man dann die einfache Wartbarkeit und die (momentane) Ruhe vor allerlei Viren und sonstigem Gesocks. Auch die (meiner Meinung nach) einfachere Bedinung ist hervorzuheben. Jedoch nimmt sich sonst Windows und Linux auf dem Desktop wenig.

Munin – „unknown warning“ unterdrücken

Ich nutzte Munin seitdem ich meine Serverstruktur am laufen habe und es hat mir gute Dienste geleistet.

Eine Sache hat mich doch immer ein wenig gestört. Ich besitze Geräte/Nodes die nicht 24/7 online sind, jedoch auch überwacht werden wollen, da sie keine direkte Interaktion mit dem Nutzer zulassen (oder der Nutzer es nicht will). Kurz: mein HTPC soll meckern, wenn was ist, aber bitte nicht während man gerade genüsslich einen Film schaut!

Bis „vor kurzem“ kam es dabei auf Seiten Munin immer zu Fehlermeldungen wie „WARNING <node>.<value> unknown“. Eine Mail mit solchen Zusammenfassung gab es am Tag mindestens 2 Mal. Einmal mit „Unknown“ und einmal mit „OK“ wenn der Rechner wieder da war. Unter den ganzen Unknown/OK Meldungen gingen die wirklich wichtigen Meldungen wie WARNING/ERROR/NOTICE leider unter, so dass ich einmal wöchentlich die Statistik aufrufen musste und nachschauen durfte…

es gibt Abhilfe. Man kann in der Munin-(Server)-Konfiguration bei der Node folgendes angeben:

 df._sdb1.unknown_limit 300

In dem oben angebenen Fall würde für das Plugin df Fieldname sdb1 erst nach 300 „Unknown“ Meldung wirklich eine Mail ausgelöst werden. Bei 5 Minuten pro Prüfungen macht das 25 Stunden, die der Rechner offline sein kann, ohne dass es eine Warnmeldung gibt.

Nachteil an der Sache, man muss das für jeden Plugin/Feldwert machen. Das führt in jedem Fall zur Plugin-Hygiene!

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;)

AES-XTS-PLAIN – Retest

Nach einer langen Zeit (über einem Jahr) war es mal wieder Zeit zu testen, wie es um die Performance meines NAS bzw dessen Verschlüsselung steht. Leider hat sich zu damals die Plattenconfiguration geändert, so dass man eigendlich die Performance nicht vergleichen kann. Jedoch war damals wie heute nicht der RAID-IO der limitierende Faktor sondern die Cipher-Performance. Wie damals kommt ein RAID5 als Storage-Basis zum Einsatzt. Diesmal nur 1GB statt 250GB Platten. Weiterhin werkelt ein 2.5GHz Intel Core2Duo samt 4GB Ram in dem Server.

Da auf dem Storage schon ein Haufen Daten liegen entfallen leider die Vergleichstest der anderen Cipher, da ein on-the-fly umschlüsseln nicht möglich ist und ich keine Lust hab 8 stunden zu warten um ein Full-Backup einzuspielen.

Nun zu den Testergebnissen von Bonnie++:

  • Write Char: 1,31 MB/s (aktuell) statt 65,85MB/s (alt)
  • Read Char: 2,46 MB/s (aktuell) statt 29,46MB/s (alt)
  • Write Block: 128,57 MB/s (aktuell) statt 133,81MB/s (alt)
  • Rewrite: 38,68 MB/s (aktuell) statt 33,14MB/s (alt)
  • Read Block: 72,18 MB/s (aktuell) statt 57,13 MB/s (alt)

Zusammenfassung: Wie gehabt können Daten scheinbar schnell entschlüsselt als verschlüsselt werden. Was auch auffällt, dass die ersten drei Testwerte sehr viel schlechter sind als beim ersten Test. Das schiebe ich mal auf das initialisierte XFS Filesystem. Das FileSystem ist zu 55% gefüllt. Daher kommt es beim Write zu einer Lückensuche, die damals bei einem frisch aufgesetzten Filesystem nicht nötig war. Bei BlockRead und Rewrite zeigt sich dann, dass es Verbesserung in der Performance der Algorithmen gab. Leider scheint die Parallelisierung des AES-Algoritmus noch nicht wirklich weit voran geschritten zu sein. Ein CPU-Kern langweilt sich immer noch vollständig…

3Ware/LSI 9560SE Activity Indication LEDs

Bei den 9560SE Reihe kann man (wie auch bei fast allen anderen RAID-Controllern) kann man sowohl LEDs als auch eine „Enclosure-Einheit“ anschließen. Werden zwei LED-Modi angeboten.

  1. HDD – Status – Indication: Fällt eine Platte aus ist es ganz praktisch, wenn der RAID-Controller anzeigt welche Platte man austauschen muss. So vermeidet man es, die falsche Platte zu ziehen. 
  2. HDD – Access – Einfaches blinken ob auf eine Platte zugriffen wird oder nicht. Dabei gibt es aber eine „SUM-LED“ in jedem Block von 4 HDD-LEDs (4+1)

Leider ist das Manual nicht wirklich aussagekräftig, was für diese Funktionalitäten vor rausgesetzt wird, oder welche Feinheiten es gibt.

  1. Status-Indication funktioniert nur mit angeschlossenem I2C-Enclosure. Schließt man LEDs direkt an den Controller an, dienen diese nur zur anzeige von Lese/Schreib-Zugriffe.
  2. Von allem vorhanden SUM-LEDs funktioniert immer nur die Höchstwertige. In Abhängigkeit wo die Platten (beim Boot) gesteckt sind, wird die LED ausgewählt. Anstatt die Aktivität in einem Block aus 4 HDDs anzuzeigen, wird der zugriff auf alle Festplatten angezeigt.

 

RAID-Access in Aktion

VDR und der automatische Sendersuchlauf

Nutzt man den VDR in Zusammenarbeit mit XBMC läuft man auf kleinere Probleme. Zum Beispiel nervt der automatische Spendersuchlauf ein wenig. Er kann sehr hilfreich sein, kann aber unnütz sein, wenn man z.b. die update-zeiten gering halten will.

Standartmäßig merkt sich VDR alle Kanäle die er über ein Update (tune in ein neues Band) mitbekommt. Das kann man abschalten. Dazu braucht es neben der channels.conf eine setup.conf. Dort trägt man den Parameter „UpdateChannels“ ein.

UpdateChannels = 0

Möglichkeiten:

  • 0 – Kein automatischer Sendersuchlauf
  • 1 Update der Kanal-Namen
  • 2 Update der PIDs
  • 3 Update von Kanal-Namen und PIDs
  • 4 Update von Kanal-Namen, PIDs und neu gefundenen Kanälen
  • 5 Update von Kanal-Namen, PIDs sowie neu gefundenen Kanälen und Transpondern (Standard)

Quelle: Benutzerhandbuch-VDR