Monthly Archives: Juli 2009

Vista & TV…

Windows Vista ist… gewöhnungsbedürftig!
Nachdem ich lange meinem geliebten Windows XP treu war, wurde es nun doch einmal Zeit, es neu aufzusetzen. Ob sich dies noch lohnen würde, schließlich steht Windows 7 schon fast in den Startlöchern, und um sich schon mal ein wenig umzugewöhnen, entschloss ich mich, doch erstmal auf Vista zu setzen. Zeitgleich setzte auch mein Brude seinen Rechner neu auf.

Was mich bei Vista besonders gefreut hat: alle Treiber wurden direkt über das Windows Update gefunden (was allerdings erstmal ein bisschen kompliziert war, da ich keinen Vista-Treiber für meinen WLAN-Stick hatte 😉 ), nach einem regelrechten Update-Wahn saß ich dann doch vor einem frisch eingerichteten System. Sieht ja ganz gut, also dachte ich mir, zur Entspannung mal ein bisschen fernsehen. MoreTV wieder installiert (meine Lieblings-TV-Anwendung, bringt / brachte komischerweise immer ein besseres Bild als das Hauppauge-eigene WinTV). Beim Start wurde dann kein Brooktree Chip gefunden. Hmm, dachte ich mir, wahrscheinlich wird kein direkter Hardware-Zugriff erlaubt. MoreTV also als Administrator ausgeführt, lief. Da mein Bruder leider einen anderen Chip auf der TV-Karte sitzen hatte, der von MoreTV nicht unterstützt wird, schauten wir uns nach einer Alternative für WinTV (welches bei ihm grundlos abstürzte), und fanden sie in DScaler.

Sendersuchlauf ist durch, fertig. Dachten wir uns. Bild war zu sehen, doch wir bekamen einfach keinen Sound aus unseren Anlagen. Nochmal nachdenken, verflixt, wo kann man bei Vista den Line-In unmuten. Brachte leider auch nicht viel, also die neuen Realtek HD Audio Driver draufgeschmissen und über dessen Control Panel die Konfiguration vorgenommen. Während mein Bruder nun gemütlich TV gucken konnte, blieben meine Boxen noch immer stumm. Aber warum? Anwendung wird korrekt im Lautstärke-Regler angezeigt, Mute war auch aus, was kann also sonst noch sein?

Dann fiel mir der Unterschied zwischen meiner und der Konstellation meines Bruders auf: Er ging noch vom Line-Out über 3.5mm Klinke auf Cinch an seinen Verstärker, ich dagegen von SPDIF über Toslink. Wird das Signal etwa nicht durchgeschleift? Ein kurzer Test mit Kopfhörer und eine Google-Suche bestätigten dies.

Immer das Kabel umstecken, wenn man TV schauen will? Wäre mir echt zu blöd, also probierte ich etwas aus. Ich lud mir Audacity herunter, wählte meine gewünschten Input- und Output-Devices aus, und aktivierte dann mittels des Pfeils neben dem Micro unter dem Aufnahme-Lautstärkepegel Monitor input. Sauber, ich höre wieder TV 😉

Immer einen Audio-Editor zum Fernsehen anzuschmeissen ist zwar einfacher als Kabel umzustöpseln, aber immer noch nicht das Wahre. Jetzt bin ich eben über eine Software mit dem Namen „Virtual Audio Cable“ gestoßen, welche scheinbar so ziemlich genau meinen Anforderungen entspricht. Werde sie nachher mal testen, hoffe, sie ist das was ich suchte… Ansonsten mache ich mich selbst an ein kleines Tool…

Unser StreamSRV…

Heute ist mal wieder einer dieser Tage, an denen man sich an den Kopf fassen und laut „Wie doof bin ich eigentlich!“ schreien könnte. Die Geschichte hierzu wie gefolgt:
Wie Schakko in Rautiges 2009-07-14 berichtete sitze ich derzeit an der Konfiguration eines Mediastreams für unser Netz. Hierzu kommen MPD (Music Player Daemon) und Icecast2 zum Einsatz. Die Konfiguration der Beiden ging recht flott, die ersten Töne waren schnell entlockt. Zusätzlich noch RelaxxPlayer als grafisches Web-Frontend, welches Drag&Drop aus der Library, Kontextmenüs und noch einiges mehr unterstützt.

Doch leider kommt es bei bestimmten Playern (insbesondere dem VLC) bei Titelwechseln dazu, dass kein Sound mehr empfangen wird. Der Player behält dabei die Verbindung aufrecht, die Zeit läuft auf dem Client aber nicht weiter. Ein Blick in die Admin-Page vom Icecast2 zeigt ähnliches Verhalten, der Client bleibt verbunden, Zeit seit des Verbindens wird ebenfalls gezählt. Scheinen aber nicht die Einzigen zu sein, die dieses Problem haben. Laut diversen Foreneinträgen könnte es mit dem Wechsel der OGG-Header zu tun haben. Demnächst werde ich dann mal einen Test machen, ob es mit einer echten OGGs (bisher waren es MP3s) besser klappt.

Zudem wollten wir uns unseren StreamSRV so aufsetzen, dass sobald neue Musikstücke in den Musikordner kopiert werden, die MPD-DB geupdatet wird. Selbiges Spiel natürlich beim Verschieben und Löschen von Liedern. Da die Platte im StreamSRV jedoch recht begrenzt ist, mussten wir dieses Verzeichnis auslagern. Zunächst hatte ich es mit einer normalen Netzwerkfreigabe probiert. Zum Überwachen des Verzeichnisses fiel mir durch Tipp von Schakko inotify auf. Doch damit lassen sich ja nur lokale Verzeichnisse überwachen. Blöd, irgendwie muss es doch noch einen Umweg geben.

Unser nächster Einfall war, ein iSCSI-Target einzurichten und dieses für die Ablage zu benutzen. Das Target war schnell erstellt und eingerichtet. Nächstes Ziel war es nun, das Laufwerk beim Neustart automatisch wieder in das vorgegebene Musik-Verzeichnis zu mounten. Da dies leider trotz fstab-Eintrag

/dev/sdb1  /var/lib/mpd/music/  ext3  defaults,auto,_netdev  0  0

nicht automatisch geschah (vermutlich, weil zum Zeitpunkt des Mounts die Netzwerkverbindung noch nicht bestand), überlegte ich mir, wie ich dies nun realisieren könnte. Nach meinen gesammelten Erfahrungen mit EFA fiel mir dazu ein, dass es sich am einfachsten über eine udev-Regel realisieren ließe. Diese war auch schnell getippert:

KERNEL=="sdb1",SYMLINK+="mmedia",RUN+="/var/lib/mpd/mnt.sh"

Das zugehörige Mount-Script:

echo "[$(date +%d.%m.%Y-%H:%M:%S)] versuche sdb1 auf /var/lib/mpd/music/ zu mounten" >> /var/log/test.log
mount /dev/sdb1
echo "[$(date +%d.%m.%Y-%H:%M:%S)] mounte sdb1 auf /var/lib/mpd/music/" >> /var/log/test.log

Leider funktionierte dies nicht. Der Symlink wurde korrekt erzeugt, das Mount-Script wollte jedoch einfach nicht ausgeführt werden. Weder wurde ein Eintrag in die test.log getätigt, noch zeigte mir

mount -l

unser neues Laufwerk als gemountet an. Immer wieder erhielt ich laut Log den Fehler

udevd-event[xxxx]: exec of program '/var/lib/mpd/mnt.sh' failed
udevd-event[xxxx]: '/var/lib/mpd/mnt.sh' returned with status 1

Zunächst fiel mir nichts besonderes auf, Test mit einem USB-Stick verlief auch negativ. Rief ich das Mount-Script per Hand auf, verlief alles einwandfrei. Woher kam nun also der Fehler? Berechtigungen waren richtig gesetzt, ausführbar war das Script auch. Nach einiger Zeit knallte mir dann der Kopf auf den Tisch: Sollte ich etwa ein einfaches

#!/bin/bash

am Anfang des Mount-Scripts vergessen haben? Dem war so, und jetzt läuft es auch einwandfrei. Manchmal kann die Lösung so einfach sein 😉

SuperMicro X8ST3-F & das IPMI-Modul…

Man denkt meistens, mit neuer Hardware wird alles besser. Wenn man jedoch schon Probleme hat, bevor der eigentliche Umbau begonnen hat, ist dies höchst frustrierend. So ergang es uns in den letzten beiden Tagen. Für einen neuen Server setzen wir das SuperMicro X8ST3-F ein, welches auch über ein IPMI-Modul verfügt. Hiermit ist es uns möglich, den Rechner über das Netzwerk so zu bedienen, als ob wir tatsächlich lokal davor säßen.
Doch schon bei der Einrichtung ging das Gewusel los. Laut Handbuch sollte man im BIOS das entsprechende Konfigurationsmenü aufrufen und die IP, Netmask und Standardgateway seinen Wünschen anpassen. Die IP Address Source sollte man zu diesem Zweck auf Static stellen (und somit DHCP deaktivieren). Der entsprechende Menüpunkt war allerdings nicht verfügbar, und ein manuelles Setzen der IP wurde auch prompt mit dem Zurücksetzen quittiert.
Nachdem der Server das erste Mal durchstartete, schien auch erst das IPMI-Modul angesprungen zu sein, immerhin hat es sich nun doch vom DHCP eine Adresse zuweisen lassen. Im BIOS war ein Ändern weiterhin nicht möglich.

Nächster Schritt war nun, sowohl das Interface als auch das BIOS auf die aktuellen Versionen upzudaten. Beim IPMI-Modul stellte dies kein Problem dar, einfach auf den entsprechenden Menüpunkt im Web-Interface, und schwupps war das Update drauf. Beim BIOS erwies sich dies als etwas schwieriger. Da das Update knappe 4MB groß war, konnten wir es natürlich nicht per Diskette einspielen. Hätten sowieso keinen Rechner mehr mit Floppy gehabt, also Schwamm drüber 😉 Dank des „Virtual Floppy Drive“ Tools in Kombination mit dem „HP USB Disk Storage Format Tool“ konnten wir uns einen USB-Stick bootfähig machen und darüber schließlich das BIOS-Update einspielen.

Schön und gut, alles lief nun auf den aktuellen Versionen. Auch die IP ließ sich nun im BIOS zuweisen, der vermisste Menüpunkt des Auswählens zwischen DHCP und Static existierte nun auch.

Unser nächster Schritt war es nun, die Authentifizierung gegen das AD einzuschalten. Leider gab es keinen Menüpunkt dafür, nur für LDAP-Authentifizierung (wie wir später feststellten, gab es den Menüpunkt für AD sehr wohl, leider arbeiteten wir scheinbar noch mit den gecachten Seiten, daher war er für uns nicht sichtbar). Nach dem Eintragen der Daten und dem Übernehmen hing sich das Web-Interface komplett auf, das IPMI-Modul war per Ping jedoch weiterhin erreichbar. Also war ein Reboot des sich auf dem IPMI-Modul befindlichen Webservers nötig. Den Versuch, die LDAP-Konfiguration wieder zu deaktivieren, wurde abermals mit einem Einfrieren des Web-Interfaces „belohnt“. Solange man nicht auf die LDAP-Konfiguration klickte, war alles in Ordnung. Ein Zurücksetzen mittels „ipmicfg -fd“ brachte ebenfalls keinen Erfolg.

Letzter probierter Schritt, das Firmware-Update ein weiteres Mal einzuspielen und die Konfiguration überschreiben zu lassen, brachte schließlich Erfolg. Es mussten zwar alle Einstellungen erneut eingetragen werden, aber jetzt läuft alles so wie es soll. Die AD-Authentifizierung haben wir jetzt zwar noch nicht eingerichtet, aber mal schauen, ob wir es überhaupt benötigen.

EFA…

Wie Schakko ja bereits in seinem Blog-Eintrag Rautiges 2009-06-07 berichtete, habe ich mich eine gewisse Zeit lang mit der Software EFA (Elektronisches Fahrtenbuch) beschäftigt. Unser Ziel war es zunächst, eine Linux-Distribution mit der Software aufzusetzen und diese vor Veränderungen von nicht befugten Personen zu schützen. Hierzu diente die sehr ausführliche Anleitung des Mainzer Rudervereins.
Unser Vorhaben wurde zunächst in einer virtuellen Maschine realisiert. Beim Kopieren der Daten aus der VM auf den USB-Stick, um abschließend von diesem starten zu können, gab es jedoch einen Fehler. Somit hätten wir uns die gesamte Arbeit ein weiteres Mal antun müssen. Aus diesem Grunde (und natürlich auch, um für andere eine einfache Methode zu bieten) haben wir ein Install-Script geschrieben, welches einen Großteil der Schritte der Installation übernimmt. Zusätzlich ist noch ein kleines Backup-Script entstanden, welches komfortabel beim Einstecken eines USB-Sticks auf der grafischen Oberfläche gestartet wird. Der Aufruf des Backup-Scripts wird über eine udev-Regel gesteuert.

Install-Script (.sh)
Backup-Script (.zip)

Wer das Backup-Script auf seinen eigenen USB-Stick anpassen will, für den wird entweder ein Blick in das Install-Script, Zeile 77 und evtl. auch Zeile 85, interessant sein. Bei abgeschlossener Installation findet ihr diese Einträge in den Dateien „/etc/udev/rules.d/01-custom.rules“ und „/etc/fstab“ wieder.

An dieser Stelle möchte ich einen herzlichen Dank an den Mainzer Ruderverein für die tolle Anleitung, an Nicolas Michael für das Elektronische Fahrtenbuch, und an Schakko für seine Debugging-Arbeit der udev-Regeln bedanken!