RAID Controller Freeze

Was ist passiert?

In einem Fileserver haben wir einen (Broadcom) MegaRaid SAS9271-8i RAID Controller. Nachdem kein Platz mehr für neue Daten frei war, haben wir ein JBOD (just a bunch of disks) – gefüllt mit 8 TB HDDs – an den Controller angeschlossen.

Sobald jemand das JBOD nutzen und Daten lesen/schreiben wollte, ist der RAID Controller mit folgender Meldung abgestürzt:

Jan 26 14:34:00  kernel: [702452.978067] sd 0:2:3:0: task abort: FAILED scmd(ffff8801fbd02880)
[...]
Jan 26 14:34:03  kernel: [702455.874238] sd 0:2:3:0: task abort: FAILED scmd(ffff881137b28f00)
Jan 26 14:34:03  kernel: [702455.874273] sd 0:2:3:0: [sdf] tag#22 megasas: target reset FAILED!!
Jan 26 14:34:04  kernel: [702456.878163] megaraid_sas 0000:84:00.0: [ 0]waiting for 140 commands to complete for scsi0
[...]
Jan 26 14:36:59  kernel: [702632.659476] megaraid_sas 0000:84:00.0: [175]waiting for 140 commands to complete for scsi0
Jan 26 14:37:04  kernel: [702637.679616] megaraid_sas 0000:84:00.0: pending commands remain after waiting, will reset adapter scsi0.
Jan 26 14:37:04  kernel: [702637.681111] megaraid_sas 0000:84:00.0: resetting fusion adapter scsi0.
Jan 26 14:37:15  kernel: [702648.715953] megaraid_sas 0000:84:00.0: Waiting for FW to come to ready state

Jan 26 14:37:44  kernel: [702677.480809] megaraid_sas 0000:84:00.0: FW now in Ready state
Jan 26 14:37:44  kernel: [702677.480872] megaraid_sas 0000:84:00.0: Current firmware maximum commands: 1008         LDIO threshold: 0
Jan 26 14:37:46  kernel: [702679.068854] megaraid_sas 0000:84:00.0: Init cmd success
Jan 26 14:37:46  kernel: [702679.092868] megaraid_sas 0000:84:00.0: firmware type  : Extended VD(240 VD)firmware
Jan 26 14:37:46  kernel: [702679.092875] megaraid_sas 0000:84:00.0: controller type        : MR(1024MB)
Jan 26 14:37:46  kernel: [702679.092878] megaraid_sas 0000:84:00.0: Online Controller Reset(OCR)   : Enabled
Jan 26 14:37:46  kernel: [702679.092881] megaraid_sas 0000:84:00.0: Secure JBOD support    : No
Jan 26 14:37:46  kernel: [702679.117243] megaraid_sas 0000:84:00.0: Jbod map is not supported megasas_setup_jbod_map 4938
Jan 26 14:37:46  kernel: [702679.117257] megaraid_sas 0000:84:00.0: Reset successful for scsi0.
Jan 26 14:37:46  kernel: [702679.118806] megaraid_sas 0000:84:00.0: 1496287 (538752919s/0x0020/CRIT) - Controller encountered a fatal error and was reset
Jan 26 14:37:46  kernel: [702679.119565] megaraid_sas 0000:84:00.0: 1496297 (538752945s/0x0004/CRIT) - Enclosure PD 08(c Port 4 - 7/p1) fan 1 failed
Jan 26 14:37:46  kernel: [702679.119728] megaraid_sas 0000:84:00.0: 1496299 (538752945s/0x0004/CRIT) - Enclosure PD 08(c Port 4 - 7/p1) fan 2 failed
Jan 26 14:37:46  kernel: [702679.119864] megaraid_sas 0000:84:00.0: 1496301 (538752945s/0x0004/CRIT) - Enclosure PD 08(c Port 4 - 7/p1) fan 3 failed
Jan 26 14:37:46  kernel: [702679.120071] megaraid_sas 0000:84:00.0: 1496304 (538752945s/0x0004/CRIT) - Enclosure PD 09(c Port 0 - 3/p1) fan 1 failed
Jan 26 14:37:46  kernel: [702679.120207] megaraid_sas 0000:84:00.0: 1496306 (538752945s/0x0004/CRIT) - Enclosure PD 09(c Port 0 - 3/p1) fan 2 failed
Jan 26 14:37:46  kernel: [702679.120346] megaraid_sas 0000:84:00.0: 1496308 (538752945s/0x0004/CRIT) - Enclosure PD 09(c Port 0 - 3/p1) fan 3 failed
Jan 26 14:37:58  kernel: [702691.619843] JFS: nTxBlock = 8192, nTxLock = 65536
Jan 26 14:37:58  kernel: [702691.646422] ntfs: driver 2.1.32 [Flags: R/O MODULE].
Jan 26 14:37:58  kernel: [702691.676287] QNX4 filesystem 0.2.3 registered.
Jan 26 14:37:58  kernel: [702691.766574] Btrfs loaded

Nach dem Reset konnte er wieder eine Zeit lang benutzt werden, bis wieder auf das JBOD zugegriffen wurde. And so on…

Ansatz

Trotz Stunden des Suchens, kam ich hier auf keinen grünen Zweig. Viele schrieben ein Firmware Update solle helfen, das hatte ich jedoch schon gemacht. Viele sagten es liege am Kernel, aber auch verschiedenste Versionen brachten keine Abhilfe.

Lösung

Zuletzt habe ich den Broadcom Support gefragt. Nach etwas hin und her (da der erste Befehl auf unserem Controller nicht funktionierte) kam eine Antwort wie diese:

Ja, das ist ein bekanntes Problem, installieren sie storcli und führe sie bitte die nachfolgenden Befehle aus. Falls diese nicht funktionieren, schicken sie mir einen debug log.

storcli /cx set backplane expose=off
storcli /cx set sgpioforce=off

Und tadaa, bisher keine Fehler mehr.

Obwohl ich zugeben muss, dass der Support weiß was er tut, finde ich es schon fast eine Frechheit, dass dies – obwohl offensichtlich bekannt – nirgends erwähnt wird. Oder noch besser out-of-the-box ohne Fehler funktioniert…

Anyway, ich hoffe das hilft auch anderen weiter.

Update:

Stellt sich raus, das hilft doch nicht! Das Problem trat nach ein paar Tagen wieder auf. Mal schauen was der Support antwortet, ich habe nochmals nachgefragt…

Sobald es Neuigkeiten gibt, update ich den Beitrag.

Update 2:

Laut Broadcom Support sind es wohl defekte / fehlerhafte Platten die den Controller zum Reset bringen (die nur im Log des Controllers auftauchen, aber nicht von storcli oder smart als defekt / fehlerhaft angezeigt werden 🙁 ).

Diese Platten sind jetzt ausgetauscht und das RAID wird neu gebaut, da scheinbar 4 Platten gleichzeitig kaputt gegangen sind. Klingt für mich langsam eher nach einem defekten JBOD, aber wir werden sehen. Hoffentlich läufts jetzt wieder.

Festplatten mit StorCLI (LSI) zu einem existierenden RAID hinzufügen

Um was geht’s?

Der Platz auf unserem Server war mal wieder voll und somit war es Zeit neue HDDs einzubauen und zum RAID (LSI RAID Controller) hinzuzufügen. Bisher hatte ich das immer umständlich mit MegaCLI gemacht, welches mit einer furchtbar komplizierte Bedienung beeindruckt. Das hat wohl auch LSI gemerkt und setzt neuerdings auf StorCLI, eine Überarbeitung und Weiterentwicklung von MegaCLI. Die Umsetzung ist wirklich gut, sinnvoll und macht das ganze etwas einfacher. Leider ist die Dokumentation noch nicht so weit wie die von MegaCLI (vielleicht auch weil es jetzt einfacher ist 😉 ). Die meisten Dinge sind in der Doku vorhanden, jedoch hatte ich nicht gefunden wie neue HDDs einem existierenden RAID hinzugefügt werden können. Daher dachte ich, ich schreib mal wieder ein kleines Tutorial.

Lösung

#1 StorCLI von LSI runterladen (für Ubuntu Nutzer gibt es auch diverse Repos, z.B. hier)

#2 Falls nur ein Controller und eine VolumeGroup existiert kann dieser Schritt übersprungen werden und einfach /c0/v0 verwendet werden, ansonsten muss zuerst die ID des Controllers ermittelt werden:

storcli64 show

Die RAID Controller sind in einer Tabelle unter System Overview aufgeführt

System Overview : 
===============

Danach gilt es dies für die VolumeGroup zu tun

storcli64 /c0 show

Auch diese sind in einer Liste aufgeführt

VD LIST :
======

In der ersten Spalte ist jeweils die ID zu sehen, nun muss nur die Korrekte ausgewählt werden.

#3 IDs der neuen Platten ermitteln

storcli64 /c0 show

zeigt eine Tabelle alle Platten die der RAID Controller verwaltet.

PD LIST : 
=======
#4 RAID Migration starten
Nun sollte die ID des Controllers (/cx), die ID der VolumeGroup (/vx) und die IDs aller Platten (x:x) die hinzugefügt werden sollen bekannt sein. Zusätzlich muss noch der RAID Typ angegeben werden und schon kann es los gehen:
storcli64 /c0/v2 start migrate type=raid6 option=add drives=9:6-11

#5 Warten…

Das ganze kann je nach Größe des RAIDs Stunden, Tage oder gar Wochen dauern. Der Fortschritt kann jederzeit mit folgendem Befehl überprüft werden:

storcli64 /c0/v2 show migrate

Standardmäßig werden 30% des IOs genutzt um das RAID zu migrieren. Dies kann und wird, je nach dem was auf dem RAID liegt, das komplette System für diese Zeit sehr verlangsamen. Die „Migraterate“ kann nachgeschaut und bei bedarf auch umgestellt werden:

storcli64 /c0 show migraterate

Duck DNS

Um was geht’s hier?

Früher hatte ich oft einen TeamSpeak2 Server lokal auf meinem PC laufen. Damit sich meine Freunde dann auf meinen Server verbinden konnten musste ich immer die aktuelle IP nachschauen und diese dann weitergeben. Problem hierbei ist, dass sich die IP (zumindest solange IPv4 noch der Standard ist) alle 24 Stunden einmal ändert und somit jedes Mal die IP nachgeschaut und weitergegeben werden muss. Um dies alles zu vereinfachen gibt es Mengen an Anbietern, wie das sehr bekannte DynDNS, die es einem erlauben eine Subdomain wie zum Beispiel „meintsserver.dyndns.org“ auf die eigene IP weiterzuleiten. Dies kann direkt über den Router erfolgen, der immer wenn er eine neue IP bekommt gleich die Subdomain updatet.

Wo liegt dann das Problem?

Letztens wollte ich eine solche dynamische Subdomain über die Weihnachtstage für meinen RaspberryPi einrichten und habe daher nach einem passenden Anbieter geschaut. Die meisten Anbieter haben allerdings einen kleinen Haken… DynDNS ist nicht mehr kostenlos und somit muss monatlich für den Service gelöhnt werden. Im Prinzip okay, aber da ich das nur sehr spärlich und auch nur ab und an einsetze suchte ich eine kostenfrei Alternative. Auch hier gibt es einige Anbieter, allerdings mit anderen Problemen wie Werbung während der Weiterleitung oder Ähnliches. Insgesamt recht unschön.

Lösung

Dann bin ich auf Duck DNS gestoßen und bin sehr angetan von dem Service. Sieht zwar sehr schlicht und vielleicht sogar etwas komisch aus, ist aber echt super: Einfach einzurichten, es gibt Anleitungen für alle gängigen Update-Methoden (Router, Linux, Windows, etc.), 5 Domains sind kostenlos und ohne lästige Accounterstellung: einfach per Twitter, Google, Facebook oder Reddit einloggen (okay, wer kein solchen Account hat, ist wohl etwas aufgeschmissen).

Also habe ich mein guten alten Google „Fakeaccount“ eingeloggt, eine Subdomain ausgewählt (z.B. wasauchimmer.duckdns.org), das ganze per Anleitung auf meinem RasperryPi eingerichtet und alles hat sofort funktioniert.

Fazit

Es hat keine 15 Minuten gedauert alles anzulegen und einzurichten. Kostenlos, schnell und werbefrei. Klasse Service, danke! Kann ich nur weiterempfehlen.

Recovering a ASUS RT-N56U after Firmware-upgrade fail

Scheint bei mir langsam zur Gewohnheit zu werden diverse Geräte nach einem Upgrade-Fail wieder zum laufen zu bringen 🙂

Was ist passiert?

Ich habe einen ASUS RT-N56U Router bekommen, nachdem ein Firmware-Upgrade von 1.x auf 3.x durchgeführt wurde (das ist jedenfalls was mir gesagt wurde 🙂 ) und der Router danach in keiner Weiße mehr reagiert hat.

Symptome

  • Keine Reaktion/Blinken mehr an den LAN Ports
  • Keine Reaktion/Blinken am WAN Port
  • Keine blinkenden Status LEDs
  • Allein die PowerLED hat durchgehend blau geleuchtet

Ansatz

Mein erster Weg war zur ASUS Support Page dieses Routers. Dort findet man eine recht ausführliche Anleitung wie man mit Hilfe eines Recovery Tools die Firmware neu flashen kann. Leider hat diese Anleitung bei mir so nicht funktioniert und ich musste doch wieder zur allseits beliebten Suchmaschine greifen 😉 .

Lösung

Um nicht lange drum rum zu reden, hier die Anleitung wie ich die Firmware wiederhergestellt hab. Sollten die Direktlinks nicht (mehr) funktionieren einfach auf die oben genannte Support Page gehen, den Router und das passende Betriebsystem auswählen.

#1 Das Recovery Tool herunterladen und Installieren. Achtung: Geht nur auf Windows, ich musste also extra mein Laptop auspacken und ins Windows booten.

#2 Die Firmware mit der Version 3.0.0.4.374.130 herunterladen. Achtung: Auf die Versionsnummer achten! Bei mir ging die aktuelle Firmware nicht, obwohl in vielen Anleitungen die neuste Firmware genannt wird.

#3 Den Router im Recoverymodus starten wie folgt:

ALLE Stecker ausstecken, auch WAN und Strom. Den Resetknopf gedrückt halten, währenddessen den Strom einstecken und warten bis die PowerLED blau blinkt, dann den Resetknopf los lassen.

#4 Den Computer über LAN direkt mit dem Router Verbinden (Port ist eigentlich egal, ich hab Port 1 genommen). Wichtig: Alle anderen Netzwerkschnittstellen deaktivieren! Ich musste mein WLAN in der Systemsteuerung deaktivieren, sonst konnte ich mich nicht mit dem Router über LAN verbinden. Seltsam, aber hilft 🙂 .

#5 In den Einstellungen der Netzwerkkarte eine statische IP vergeben:
IP: 192.168.2.11
Subnetzmaske: 255.255.255.0
Gateway: 192.168.2.1

#6 ASUS Recovery starten, die heruntergeladene Firmware auswählen und auf „Hochladen“ klicken.

#7 Warten und die Daumen drücken! Es dauert eine Weile bis die Firmware geflashed ist. Danach dauert es noch einen Moment bis der Router neugestartet hat. Erst hat wieder nur die PowerLED geleuchtet, aber nach einer weiteren Minute warten lief der Router dann wie er sollte und war wieder übers LAN erreichbar.

And it’s gone – QNAP webinterface

Und schon wieder…

Heute ist zwar nicht (wie letztes Mal) Sonntag, aber ich hatte wieder ein Erlebnis mit meiner QNAP: Mein Webinterface war weg… :-/

Problem

Ich hatte „force SSL“ an und somit den Standard-Port 8080 deaktiviert. Beim Update auf 4.1.0 hat es dann scheinbar den SSL-Port zerschossen und ich konnte nicht mehr auf das Webinterface zugreifen. Die Shares und SSH ging allerdings noch.  Was nun? Eine QNAP ohne Webinterface macht ja auch wenig Sinn. Also auf ins „Gefecht“.

Lösung

Nach einigen Fehlversuchen war die Lösung dann doch zum Glück recht einfach:

#1 Per SSH einloggen

#2 Folgende Befehle ausführen:

setcfg System "Force SSL" 0
/etc/init.d/thttpd.sh restart

#3 Nun sollte der Default-Port wieder funktionieren und ihr könnt euch per ipadresse:8080 einloggen

#4 Einfach in die Einstellungen gehen und den SSL Port auf einen anderen Port der Wahl legen, z.B. 9091.

#5 Nun kann „force SSL“ wieder aktiviert werden und das System sollte über den neu definierten Port erreichbar sein: ipadresse:9091

Linux download utilities

Download-Manager – aria2

Wer sich je eine schön große Datei von einem unglaublich langsamen Server geladen hat weiß wie oft ein guter Download-Manager von Nutzen sein kann. Leider kannte ich bis vor Kurzem keinen den ich auch auf einem Server von einem Terminal aus bedienen konnte.

Dann bin ich über aria2 gestolpert. Das schöne daran ist, auf der einen Seite kann man hiermit von einem Server mit mehreren Verbindungen gleichzeitig herunterladen um die Download-Geschwindigkeit zu maximieren, aber auf der anderen Seite können auch abgebrochene Downloads (z.B. durch einen Disconnect) einfach fortgesetzt werden. Das Tool kann zudem noch einiges mehr wie z.B. Torrent oder paralleler Download von verschiedenen Servern.

Zu haben gibt’s das Package wohl in den meisten Distributionen direkt aus den Repositories. Eine ausführliche Anleitung gibt’s wie so oft in der Arch-wiki. Installiert wird das Programm mit:

pacman -S aria

oder bei Debian/Ubuntu

apt-get install aria

Benutzt wird das ganze dann wie folgt um vom angegebenen Server mit 5 Verbindungen gleichzeitig herunterzuladen:

aria2c -x 5 URL

Sollte die Verbindung einmal abbrechen, einfach wieder in den selben Ordner wechseln und genau den selben Befehl noch einmal ausführen. Schon geht der Download weiter.

Download von mehreren Files

Es kommt öfter vor, dass ich eine ganze Reihe an Daten von einem FTP Server herunterladen will. Oft habe ich eine Liste von URLs die ich oft per Hand, nacheinander, mit wget heruntergeladen hatte. Bis mir der „-i Parameter“ auffiel. Damit lässt sich eine Datei an wget übergeben, in welcher sich pro Zeile eine URL zum download befinden muss. Dann einfach folgendes aufrufen:

wget -i file

und gemütlich zuschauen wie wget einem die Arbeit abnimmt und eine Datei nach der anderen herunterläd. Feine Sache 😉 !

Full-featured Trackmania2 Stadium Server hosten

TrackMania2 Stadium

Falls ihr TrackMania nicht kennt und ihr (Arcade-) Rennspiele mit anspornendem Multiplayer gern habt, solltet ihr euch dieses Spiel unbedingt anschauen. Das Prinzip ist simpel: Eine Strecke wird eine bestimmte Zeit lang gespielt, z.B. 5 Minuten und während dieser Zeit könnt ihr so oft ihr wollt fahren (natürlich auch jederzeit neu starten) und damit eure Zeit verbessern. Wer nach diesen 5 Minuten die beste Zeit gefahren hat gewinnt. Dank guter Fahrphysik und extrem abwechslungsreichen Strecken mit allen erdenklicher Streckenteile wie Loopings, Wallrides, verrückten Sprüngen, etc (es gibt natürlich auch Strecken ohne diese Dinge) macht dieses Spiel auch lange Zeit viel Spass. Ein super Bonus-feature: Ihr könnt auch mit dem eingebauten Map-Editor eure eigenen Strecken bauen.

Was ist mit „Full-featured“ gemeint?

Wer schon mal Trackmania gespielt hat, der weiß wie das Interface normal ausschaut (Singleplayer). Spielt man aber online ändert sich das ganze, die meisten Server haben diverse Plugins für den Dedicated-Server um das Spiel spannender zu machen. So werden oft die „Local Records“ und die aktuelle Plazierung auf der rechten und die „Dedimania Records“ auf der linken Seite angezeigt. Dadurch sieht man sofort beim fahren wie gut man abschließen muss um einen Platz in den Records bekommt oder wie gut momentan die anderen sind. Aber auch Dinge wie „wer war an welchem Checkpoint der schnellste“ oder wie gut ist die aktuelle Strecke bewertet finden sich auf dem HUD.

tm2

Alles in allem verbessern diese Plugins den Spiel-spass und den ganzen Ablauf online um einiges. All dies wollen wir auf unserem Server auch haben.

Der eigene Server

Voraussetzungen

Folgende Dinge werden benötigt:

  1. Ein eigener Server, vorzugsweise ein Root-Server im Rechenzentrum der Wahl. Alternativ geht auch ein V-Server oder ein alter PC zu-hause (allerdings sind dann ein schnelles Internet und wissen über NAT für den Router Pflicht)
  2. Linux (Für mein Tutorial, läuft im Prinzip aber auch auf Windows)
  3. Das Spiel also einen Key für Trackmania und den damit verbundenen Trackmania Account
  4. Einiges an Zeit

 Die Grund-Installation

#1 Einen Dedicated-Server-Account erstellen

Auf ManiaPlanet einloggen und dort eine neuen Dedicated Account erstellen. Einfach einen neuen Login aussuchen (ist später nur ganz klein im Detailfenster zu sehen, also im Prinzip frei wählbar), ein Passwort vergeben (Achtung: Merken, das brauchen wir später!) und als letztes noch den Standort des Servers aussuchen (nach diesem kann im Spiel gefiltert werden)

#2 (Optional) Einen neuen Linux-User für TM2 erzeugen und zum neu erstellen User wechseln

sudo adduser tm2
sudo su tm

#2 Dedicated-Server herunterladen

cd ~ #oder in das gewünschte Verzeichnis wechseln
mkdir tm2-dedi
wget http://files.maniaplanet.com/ManiaPlanet3Beta/ManiaPlanetBetaServer_latest.zip
unzip ManiaPlanetBetaServer_latest.zip

Alternativ kann auch das Ubuntu Repository genutzt werden (natürlich nur unter Ubuntu)

#3 Serverkonfiguration

mv UserData/Config/dedicated_cfg.default.txt UserData/Config/dedicated_cfg.txt
nano UserData/Config/dedicated_cfg.txt

Folgende Dinge müssen verändert werden:

#3.1 Ein neues SuperAdmin Passwort vergeben:

<level>
     <name>SuperAdmin</name>
     <password>DasNeueSuperAdminPasswort</password>
</level>
<level>
     <name>Admin</name>
     <password>DasNeuePasswort</password>
</level>
<level>
     <name>User</name>
     <password>DasNeuePasswort</password>
</level>

#3.2 Den Dedicated-Login eingeben:

<masterserver_account>
     <login>dedicatedLogin</login>
     <password>dedicatedPasswort</password>
     <validation_key>VALIDATIONKEY</validation_key>
</masterserver_account>

#3.3 Den Servernamen vergeben:

<server_options>
     <name>ServerName</name>
<comment>Kommentar für den Server</comment>

#3.4 Environment einstellen:

<title>TMStadium</title>

Achtung: In nano können Änderungen mit Strg+O gespeichert werden und der Editor wird anschließend mit Strg+X wieder geschlossen.

#4 Startscript bearbeiten:

nano RunSrvTM.sh

./ManiaPlanetServer /title=TMStadium /game_settings=MatchSettings/TMStadiumA.txt /dedicated_cfg=dedicated_cfg.txt

 XAseco

Für Trackmania gibt es eine ganze Liste verschiedener Pluginsystem. Recht bekannt und auch schon oft genutzt im alten TrackMania ist XAseco2.

#1 Download

Einfach die aktuellste Version von der XAseco Website herunterladen (Zum Zeitpunkt dieses Blogeintrags war dies Version 1.03).

#2 MySQL

Jetzt wirds ein wenig komplizierter, denn alle Daten von XAseco werden in einer MySQL Datenbank gespeichert (Records, Votes, etc). Also müssen wir zuerst eine MySQL Datenbank installieren (einfach #2.1 überspringen, falls schon installiert).

#2.1 Installation

Je nach Linux Distribution ist das ein wenig anders, für Ubuntu/Debian wäre das:

sudo apt-get install mysql-server

Auf ArchLinux wäre dies (Achtung MySQL wurde hier von MariaDB ersetzt, für den Anwender bleibt aber fast alles beim Alten):

sudo pacman -S mariadb

#2.2 Datenbank anlegen

Erst müssen wir uns in der Datenbank einloggen:

mysql -u root -p

und einfach das bei der Installation vergebene Passwort eingeben. Dann folgenden Befehl kopieren:

CREATE DATABASE xaseco2;

#2.3 MySQL User anlegen

Nun können wir direkt auch den passenden User erstellen, einfach folgendes kopieren und dabei „meinMysqlPasswort“ auf das gewünschte Passwort verändern!

CREATE USER 'tm2'@'localhost';
SET PASSWORD FOR 'tm2'@'localhost' = password('meinMysqlPasswort');
GRANT all ON xaseco2.* TO 'tm2'@'localhost';

#3 Konfiguration

#3.1 Entpacken

Jetzt kann das unter #1 heruntergeladen Archiv entpackt werden.

unzip xaseco2_103.zip

#3.2 Verschieben der Config-Files bei der Erst-Installation

cd xaseco2/newinstall
mv *.xml ../
mv *.php ../
cd ../

#3.3 Database config

nano localdatabase.xml

Hier muss die Datenbank auf die korrekten Daten von oben geändert werden also ändern wir den folgenden Block:

<mysql_server>localhost</mysql_server>
<mysql_login>tm2</mysql_login>
<mysql_password>meinMysqlPasswort</mysql_password>
<mysql_database>xaseco2</mysql_database>

#3.4 Haupt-Konfiguration

Mit Hilfe dieser Datei können viele Detail-Einstellung vorgenommen werden, welche ich hier überspringe, ich hab einfach die Standard-Einstellungen gewählt. Diese sind im Prinzip auch schon super und müssen nur verändert werden, wenn etwas bestimmtes geändert werden soll.

Folgende Einstellungen müssen allerdings geändert werden:

nano config.xml

Erst vergeben wir Adminrechte, hier können beliebig viele Accounts angegeben werden. Wir benötigen hier die ManiaPlanets Loginnamen nicht die Nicknames!

Achtung: Hier wird der MasterAdmin angegeben, MasterAdmins habe ALLE Rechte auf dem Server! Es wird noch weiter unterschieden in Admins und Operators (siehe unten).

<masteradmins>
    <tmlogin>meinManiaPlanetLoginName</tmlogin>
</masteradmins>

Ganz wichtig ist noch die Servereinstellung, die findet man ganz am Ende der Datei:

<tmserver>
    <login>SuperAdmin</login>
    <password>DasNeueSuperAdminPasswort</password>
    <ip>127.0.0.1</ip>
    <port>5000</port>
    <timeout>180</timeout>
</tmserver>

#3.5 Admins/Operators

Wer möchte kann jetzt noch zusätzliche Admins und Operators festlegen (Optional!). Zusätzlich können auch die Rechte beider Ränge einzel eingestellt werden.

nano adminops.xml
<admins>
    <tmlogin>meinManiaPlanetLoginName</tmlogin>
</admins>

<operators>
    <tmlogin>meinManiaPlanetLoginName</tmlogin>
</operators>

#3.6 Dedimania

Dedimania ist ein Records System das Serverübergreifend funktioniert. Jeder Record der auf dem Server gefahren wird, wird anschließend auf die Dedimania Record Server hochgeladen und ist anschließend auf allen anderen Servern auch zu sehn.

Wer diesen Service nutzen will muss sich erst bei Dedimania anmelden. Einfach den ManiaPlanet Account verknüpfen mit dem auch der Server Login erstellt wurde und anschließend bei „register your dedicated server“ diesen Server Login noch registrieren.

Nach der Registrierung wird ein Dedimaniacode angezeigt, diesen brauchen wir gleich für die Konfigurations-Datei.

vim dedimania.xml

Der Dedimaniacode muss nun zusammen mit dem Dedicated Server login eingetragen werden:

<masterserver_account>
    <login>dedicatedLogin</login>
    <dedimaniacode>000000000</dedimaniacode>
</masterserver_account>

Hinweiß: Es gibt insgesammt 100 Dedimania Records für jede Map. Allerdings können auf einem Server nur die Ränge 1-30 belegt werden. Wer einen Server haben will auf dem alle Spiele die Ränge 1-80 belegen können muss eine einmalige Spende von 10 Euro an die Gründer von Dedimania einreichen. Dies wird damit begründet, dass die benötigten Server für den Dedimania Service auch bezahlt werden müssen. Die Website zum Spenden könnt ihr hier finden, denkt daran euren Dedicated Login anzugeben.

Die Ränge 80-100 hingegen können ausschließlich von Spielern belegt werden die selbst an Dedimania gespendet haben.

Habt ihr gespendet müsst ihr noch in der dedimania.xml folgenden Eintrag ändern:

<limit_recs>80</limit_recs>

XAseco Plugins

Läuft XAseco auf dem Server kann man diesen ganz nach seinen Wünschen konfigurieren indem verschiedene Plugins zusätzlich installiert werden. In der Grundkonfiguration laufen zwar schon alle wichtigen Dinge wie Local Records oder Dedimania Records, jedoch lässt das Interface noch ein wenig zu wünschen übrig. Um ein Gameplay wie auf dem oben dargestellten Bild zu bekommen, müssen noch zusätzliche Plugins wie z.B. EyePiece installiert werden.

#1 EyePiece

EyePiece ist ein Plugin welches eine schönes und praktisches HUD hinzufügt und alle Records und auch andere Dinge übersichtlich anzeigt.

Einfach über die Website die aktuellste Version herunterladen. Zum Zeitpunkt dieses Tutorials war das die Version 1.0.9.9. Anschließend entpacken, alles in den XAseco Ordner kopieren und in die Plugin-Liste eintragen:

wget http://www.undef.name/.downloads/XAseco2/plugin.records_eyepiece.php-1.0.9.9.zip
unzip plugin.records_eyepiece.php-1.0.9.9.zip
cp -R ./plugin.records_eyepiece.php-1.0.9.9/xaseco2/* ./xaseco2/
nano xaseco2/plugins.xml

Folgendes hinzufügen:

plugin.records_eyepiece.php

#2 TM Karma

Sehr beliebt ist auch TM Karma für Map Ratings. Hier kann jeder Spieler der die Map geschafft hat diese Bewerten mit —, –, -, +, ++ und +++. Dies ermöglicht feinere Abstufungen und gibt der Map ein recht ausgeglichenes und faires Rating.

Auf hier wieder auf die Website und die aktuelle Version (1.0.7) herunterladen.

wget http://www.undef.name/.downloads/XAseco2/plugin.tmkarma.php-1.0.7.zip
unzip plugin.tmkarma.php-1.0.7.zip
cp -R plugin.tmkarma.php-1.0.7/xaseco2/* ./xaseco2/
nano xaseco2/plugins.xml

TM-Karma hinzufügen/Auskommentieren und RASP auskommentieren:

plugin.tm-karma-dot-com.php

Starten!

Fertig! Jetzt muss nur noch der Server gestartet werden:

./XAseco2.sh

Viel Spass beim Spielen! 😉

Server-Manager

Über die Konfig-Dateien können alle Einstellungen des Server angepasst werden. Wer eine einfache und schnelle Bedienung des Server haben möchte, sollte sich unbedingt einen der Web-Server-Manager anschauen. Ich habe mir auf unserem Server noch den offiziellen Dedicated Manager von Nadeo installiert.

Diesen zu installieren ist allerdings wieder eine Sache für sich und würde auch die Ausmaße dieses Blogeintrags sprengen. Vielleicht komm ich später noch dazu ein extra Tutorial für die Installation des Dedicated Manager zu schreiben.

 

Musik Player Daemon (MPD) und Archlinux

Was ist der MPD und warum sollte ich ihn nutzen?

Der MPD ist ein Daemon (Hintergrunddienst) in Linux der dafür gedacht ist Musik abzuspielen/streamen. Einerseits kann man diesen Dienst statt eines Musikplayers auf dem lokalen Rechner nutzen, aber viel interessanter ist die Idee den Dienst als ferngesteuerter Musikplayer einzusetzen. Er läuft auf nahezu jeder (auch antiken) Hardware, man braucht lediglich einen alten PC/Laptop oder inzwischen läuft er sicherlich auf auf modernen NAS Systemen. Die einzige Anforderung ist eine einigermaßen taugliche Soundkarte und optional einen SPDIF Ausgang (meiner Ansicht nach immer noch die beste Variante Ton zu übertragen).

Ich persönlich nutze einen kleinen Mini PC auf Intel NUC Basis der mir als Media Center dient. Er braucht wenig Strom und läuft daher fast durchgängig. Er ist direkt mit meinem AV-Receiver und dadurch mit dem Soundsystem verbunden. Auf diesem Rechner läuft der MPD im Hintergrund und kann dann mit jedem beliebigen Gerät – sei es ein direkt von dem Media Center, von einem anderen Rechner im Netzwerk oder auch von einem Handy – ferngesteuert werden. Das ist extrem praktisch, wenn z.B. Besuch da ist, kann jeder mit einem passenden Handy-Client (ich bevorzuge bei Android MPDroid) die Musikbibliothek durchsuchen und gleichzeitig eine Playlist „zusammenklicken“.

Problem

Leider ergeben sich auf Archlinux seit dem Umstieg auf systemd einige Probleme wenn PulseAudio genutzt werden soll. Das Problem liegt hierbei an der Verbindung von MPD zum PulseAudio Server. MPD läuft standardmäßig als MPD Nutzer und kann nicht auf die PulseAudio Session des aktuellen Nutzers zugreifen. Dieses Problem kann auf verschiedene Arten gelöst werden.

Das ganze äußert sich dadurch, dass MPD in die Log Datei etwas ähnliches schreibt wie:

Cannot connect to PulseAudio: access denied

Lösung

Starte MPD und PulseAudio mit dem selben User

Wird kein Multi-User System benötigt, ist dies wohl die einfachste und sauberste Lösung. Hierzu bearbeiten wir zuerst die MPD config /etc/mpd.conf und ändern den User von mpd auf den normalen System-User mit dem auch PulseAudio läuft (euer normaler Username).

 user "username"

Als nächstes muss die systemd service Datei bearbeitet werden. Diese Datei wird bei einem System Update wieder überschrieben! Es ist eine einfache und funktionierende Lösung, könnte aber sicherlich anders besser gelöst werden. Die service Datei liegt unter /usr/lib/systemd/system/mpd.service folgendes muss ergänzt werden

[Service]
User=username
PAMName=system-local-login

Um diese Änderung zu übernehmen muss folgender Befehl ausgeführt werden:

systemctl daemon-reload

Nun kann MPD neu gestartet werden

systemctl restart mpd

Jetzt sollte alles einwandfrei funktionieren.

Alternative

Eine Alternative von der ich gelesen habe ist die Nutzung des TCP Plugins von Pulseaudio, siehe Archlinux Forum (Post #10).

 

Videotearing in Linux (Manjaro/Arch) und XBMC

What the heck is Videotearing?

Tearing äußert sich auf dem Monitor dadurch, dass horizontale Streifen durch das komplette Bild wahrnehmbar sind. Das ist vorallem bei Videos und Filmen ärgerlich, da das Bild anfängt zu stocken und ziemlich „zerrissen“ ausschaut. Extrem fällt das bei schnellen Kameraschwenks auf. Es vermittelt den Eindruck als würde man mehrere Bilder gleichzeitig sehen, die alle ein bisschen verschoben sind (wobei genau das auch der Grund ist, siehe unten). Es gibt mehr als genug Beispiele wirft man einfach die Google Bildersuche an. Kurzum, ein Spaßkiller möchte man einen entspannten Filmabend verbringen.

Woher kommt’s?

Das Problem liegt hierbei an der Grafikkarte, diese berechnet und schickt die Bilder schneller an den Monitor als der sie darstellen kann. Das fällt extrem auf bei den genannten schnellen Kameraschwenks. Bevor ein Bild komplett auf dem Monitor angezeigt wird, schick die Grafikkarte schon das nächste Bild, welches der Monitor dann sofort anfängt darzustellen. Dadurch wird das typische Muster erzeugt, dass auf dem Monitor untereinander gleichzeitig verschiedene Bilder dargestellt werden, die deutlich mit einem Streifen getrennt sind. Je nach Film kann dies zu extremen Rucklern oder Verzerrungen führen. Gerade bei schnellen Actionfilmen wird dadurch der Film „unschaubar“.

Was tun?

Abhilfe schafft hier die sogenannte Vertical Synchronisation, kurz VSync. Ist sie eingeschaltet wartet die Grafikkarte bis der Monitor fertig ist ein Bild darzustellen und schickt erst dann das nächste Bild an den Monitor. Diese Option kann man so gut wie bei jeder Grafikkarte in den Einstellungen aktivieren.

Wo liegt dann das Problem?

Was tun, wenn VSync aktiviert ist (in XBMC und in XFCE4) das Problem aber trotzdem noch auftritt? Ja das ist die große Frage. Ich habe sämtliche Optionen und Lösungsansätze getestet die ich im Netz gefunden. Dort habe ich die Lösung dann auch gefunden. Es stellte sich heraus, dass die aktuelle Version von XOrg das Problem war. Ab 1.15.0 ist die sogenannte „backing store function“ standardmäßig aktiviert, welche zu genau diesem Problem führt.

Lösung

Ich habe momentan Manjaro Linux (basiert auf Archlinux) mit XFCE auf meinem mini Media PC mit einer integrierten Intel Grafik am laufen.

Also hab ich zuerst versucht VSync zu aktivieren. In Manjaro muss hierzu diese Datei bearbeitet /etc/X11/mhwd.d/intel.conf (bei purem Arch wäre es: /etc/X11/xorg.conf.d/20-intel.conf) und um folgendes ergänzt/abgeändert werden:

Section "Device"
   Identifier "Intel Graphics"
   Option "SwapbuffersWait" "true"
   Option "AccelMethod"  "sna"
   Option "TearFree" "true"
EndSection

Hiermit wird VSync (TearFree) aktiviert.

Siehe Update 1.

Des weiteren habe ich über Probleme des Compositing gelesen und entschlossen dieses in den XFCE optionen komplett zu deaktivieren. Da ich den PC sowieso nur für MPD, XBMC und ähnliches benutzen möchte, brauche ich hier sowieso keine „fancy“ Effekte 😉

Der letzte Schritt in Manjaro/Arch war dann die backingstore Funktion zu deaktivieren. Das ganze ist in Arch super einfach, es muss lediglich das AUR Repository eingerichtet sein – was in Manjaro schon ab Installation vorhanden ist. Dann einfach ein kurzes:

yaourt -S sdl-nobackingstore

Und nach einem Reboot läuft alles wie man sich das wünscht. Besonders schön ist es in XBMC noch die Funktion „Adjust display refresh rate to match video“ zu aktivieren (vorausgesetzt der Fernseher unterstützt alle Videomodi wie z.B. 24p). Dadurch erhält man ein noch flüssigeres und angenehmeres Filme-Erlebnis 😉

Auch für Ubuntu Jünger gibt es hier Abhilfe (siehe Eintrag #12).

Update 1

Nach mehreren Stunden Videos ist mir aufgefallen, dass das Bild nach einer gewissen Zeit anfängt zu stottern und ab und zu kleine Lags auftauchen. Das äußert sich so, dass das Bild ganz kurz stehen bleibt und dann in doppelter Geschwindigkeit läuft bis es wieder synchron ist, danach läuft es ganz normal weiter. Komisch ist, dass es nicht durchgängig auftaucht. Nachdem ich das neuste Systemupgrade von Manjaro installiert hatte, XBMC auf 13.2 RC1 upgegraded und TearFree wieder deaktiviert hatte (nobackinstore + XBMC VSync reicht vollkommen aus um das Tearing zu verhindern), funktionierte alles einwandfrei ohne Ruckler. Was genau das Problem ausgelöst hat weiß ich nicht, aber in der Konfiguration funktioniert alles wunderbar.

Recovering a QNAP TS-412 after Firmware-upgrade fail

Was ist passiert?

Ein ganz normaler Sonntag. Ich musste kurz was auf dem Webinterface meiner QNAP TS-412 NAS einstellen und bekomme die Meldung eines neuen Firware-upgrades (4.0.1 auf 4.1.0, ja ich weiß, nicht mehr ganz aktuell 😉 ). Da ich bisher noch keinerlei Probleme hatte und doch schon häufig ein Upgrade durchgeführt hab, dachte ich mir „klar, das geht kurz“.

Wie sich herausstellte ein Fehler. Ich habe leider keine Ahnung was genau schief gelaufen ist, aber nach dem typischen Reboot hat nur noch die Status LED der NAS rot/grün abwechselnd geblinkt. Laut Internet ein Zeichen für eines der folgenden Probleme:

  1. The hard disk drive on the NAS is being formatted
  2. The NAS is being initialized
  3. The system firmware is being updated
  4. RAID rebuilding is in process
  5. Online RAID capacity expansion is in process
  6. Online RAID level migration is in process

Abgesehen von der Initialisierung – die allerdings keine 60 Minuten dauern sollte – und dem Firmware-upgrade – das eigentlich schon durchgelaufen sein sollte – keine schönen Vorstellungen…

Ich dachte mir na gut, kann ja sein das braucht einfach seine Zeit und dieses Mal dauert es halt länger. Aber auch nach einer Essenspause keine Verbesserung. Also hab ich mich dem Problem angenommen und mich im Internet schlau gemacht.

Symptome

Falls jemand hier vorbei kommt und das selbe Problem hat, in kurz meine Probleme:

  • NAS bootet nicht mehr -> taucht nicht im QFinder auf, kein Webinterface, kein SSH, kein Zugriff auf die Shares
  • Status LED blinkt grün/rot abwechselnd
  • Ohne HDDs bootet dies NAS einwandfrei und auch der QFinder findet die NAS und will neu initialisieren

Versuche

Versuch 1: Firmware-recovery

Als erstes kam mir die Firmware-recovery in den Sinn. Nach einem abgebrochenen Firmware-upgrade kommt genau dieses Problem wohl öfters vor. Allerdings sollte die NAS dann auch ohne HDDs nicht booten, was sie aber einwandfrei tut. In diversen Foreneinträgen stand, dass es – auch wenn das System ohne HDDs noch bootet – trotzdem helfen kann. Da die Firmware aber offensichtlich auf den HDDs ist – da es ohne mit einer alten Firmware bootet – machte es für mich nicht viel Sinn die Firmware-recovery ohne HDDs durchzuführen. Aber dachte ich mir „Was solls, ein Versuch ist’s wert, wenn’s mal jemand geholfen hat, warum nicht auch mir?“. Also hab ich einmal die komplette Firmware-recovery durchgespielt.

Das Ergebnis: Ohne HDDs hab ich jetzt eine Firmware 4.0.1, mit den Platten komm ich allerdings immer noch nicht über die grün/rote LED…

Versuch 2: Firmware-upgrade ohne HDDs

Kurz: Nicht empfohlen und es funktionierte auch nicht.

Ergebnis: „Upgrade Failed“, nächster Versuch.

Versuch 3: Config reset

Basierend auf einem Thread im QNAP Forum hat der Support bei einem ähnlichen Problem empfohlen die Configs per SSH und Hotplug zu löschen und mit default configs zu ersetzen. Die Idee ist gut, hab mich schon aufgeregt, dass ich nicht selber auf die SSH Hotplug Idee kam. Also einfach mal ganze Programm durchgezogen.

Ergebnis: Kein Unterschied beim starten mit den HDDs.

Lösung

Wenn man so viel wie ich mit Linux Systemen arbeitet wird man irgendwann kreativ. Ich hatte mich schon fast mit einem Reset der NAS abgefunden, aber ein letzten Versuch wollte ich mir noch geben, da ich was von „manuellem Systemupgrade“ gelesen hatte.

Wer genau das beschrieben Problem hat, sollte folgendes versuchen, mir hat’s geholfen.

#1 NAS ans Netzwerk anschließen (damit sie eine IP vom DHCP Server bekommt)

#2 Die NAS starten ohne HDDs (einfach ein zur Hälfte raus-ziehen)

#3 Hotplug aller Platten in richtiger Reihenfolge (1-4) und warten bis alle HDD LEDs grün leuchten und nicht mehr blinken (also einfach alle Platten wieder rein-schieben, bis sie richtig drin stecken)

#4 IP per Qfinder oder Router/DHCP Server herausfinden

#5 SSH Verbindung per Putty (Windows) oder ssh (Linux) aufbauen

Die Logindaten sind:
User: admin
Passwort: admin

#6 Festplatten mounten mit folgenden Befehlen:

config_util 1 #Mirror ROOT partition
storage_boot_init 1 #mount ROOT partition
storage_boot_init 2 #mount DATA partition

Mit diesen Befehlen werden alle Festplatten wieder in das System eingebunden und sind anschließend wieder verfügbar.

Update:
Bei mir gab es keine Fehler bei diesen 3 Befehlen, falls doch sollte man folgendes versuchen:

config_util 4
mount /dev/sda4 /mnt/ext
cp /etc/default_config/uLinux.conf /mnt/HDA_ROOT/.config/
rm -r /etc/config
ln -sf /mnt/HDA_ROOT/.config /etc/config
setcfg -f /etc/config/uLinux.conf Misc configured TRUE

Siehe Comments

#7 Download der neusten Firmware von QNAP und anschließend entpacken (.img Datei)

#8 Kopieren der Firmware (.img) auf eine der jetzt eingebundenen Festplatten (NICHT auf die root-Partition, die ist zu klein!) in der NAS per scp oder in Windows per WinSCP (da meine Firmware kein wget hatte). In meinem Falle hab ich das ganze auf eine RAID Partition geschoben: /share/MD0_DATA/

#9 Durchführen eines manuellen System-upgrades:

Zuerst muss man überprüfen ob der Ordner /mnt/HDA_ROOT/update verfügbar ist, falls nicht wird dieser zuerst erstellt:

mkdir /mnt/HDA_ROOT/update

Der zweite Check, den man durchführen muss bevor man das Upgrade starten kann ist die Überprüfung ob der Ordner /mnt/update im System vorhanden ist. Falls ja muss man diesen zuerst löschen mit:

rm -rf /mnt/update

oder, falls nicht möglich, unmounten:

umount /mnt/update

Nun kann man das manuelle Firmware-upgrade durchführen. Dafür kopiert man zuerst die .img Datei in /share/public, bei mir war das:

cp /share/MD0_DATA/TS-412_20140612-4.1.0.img /share/Public/TS-412_20140612-4.1.0.img

Als nächstes erstellt man einen Symlink zum update Verzeichnis:

ln -sf /mnt/HDA_ROOT/update /mnt/update

Als letztes wird das Update Script ausgeführt:

/etc/init.d/update.sh /share/Public/TS-412_20140612-4.1.0.img

#10 Warten bis das Upgrade komplett durchgelaufen ist und folgende Zeile auftaucht:

Update Finished.

#11 Neustarten per:

reboot

Und siehe da, meine NAS kam endlich über die grün/rote LED raus und hat das System wieder wie vorher gebootet. Man muss nur einfallsreich sein und viele Foreneinträge lesen 😉

Ich hoffe meine kleine Odyssee hilft Anderen schneller ans Ziel zu kommen, falls bei euch nach einem Firmware-upgrade das selbe Problem aufgetaucht ist.