Buzz-Tasten

Ein Kollege war so freundlich ein paar BUZZ! Buzzer zu besorgen die über USB angeschlossen werden. Damit man diese allerdings Nutzen kann muss man ein wenig Tricksen. Zwar implementiert Mozilla eine JoystickAPI in seinen aktuellen Browsern, das funktioniert allerdings nicht in anderen Browsern. Daher habe ich mich dazu entschieden, die Tasten einfach auf normale Keyboard-Tasten zu mappen. Unter Linux funktioniert das wunderbar mit JoyToKey.

Persistenz

Das gesamte Spiel läuft mit Hilfe von Javascript, HTML und CSS auf Clientseite. Die Fragen kommen aus einem JSON Array. Tritt ein Problem im Spiel auf, oder wird aus versehen die Seite neu geladen ist der aktuelle Spielstand verloren.  Um das Problem zu beheben stellt HTML5 diverse Möglichkeiten bereit. Da das ganze ohne Server laufen können soll fällt Session Storage allerdings weg. Web SQL Database wird nicht weiter entwickelt und IndexedDB hat keine schöne jQuery API. Aus diesem Grund verwende ich jetzt Local Storage dafür.

Local- und Session-Storage funktionieren beide letzten Endes gleich:

localStorage.setItem('variable', 'inhalt');    // Speichern von Inhalten
localStorage.getItem('variable');              // Abrufen von Inhalten aus dem Storage
localStorage.removeItem('variable');           // Löschen von Inhalten

Nachdem diese beiden “Problemchen” behoben wurden funktioniert das ganze jetzt einigermaßen fehlerfrei. Der Feier steht nichts mehr im Wege :-)

Da mir die existierenden Lösungen nicht so gut gefallen hab ich mir selbst etwas mit jQuery gebaut, das meine Anforderungen erfüllt.

Das FilterList Plugin wird einfach direkt nach jQuery in den HTML Markup eingebunden und anschließend konfiguriert. Es muss lediglich die Suchbox (HTML Input-Feld) und die gewünschten Aktionen angegeben werden.

Beispiel

$('#search').filterlist({
    'actions':[
        {'test':/^\d+$/,
        'title':'Open Ticket "{0}"',
        'help':'Number',
        'action':function(val){window.location.href = "https://github.com/emposha/FilterList/pull/"+val;}},
        {'test':/^l$/,
        'title':'Log Ticket',
        'help': 'l',
        'action':function(val){window.location.href = "https://github.com/chkorn/FilterList/issues/new";}},
        {'test':/^(i )(\w+)/,
        'title':'Open Item',
        'action':function(val){alert("Search...");}},
        {'test':null,
        'title':'Search',
        'action':function(val){alert("You should trigger a search");}},
    ]
});

Beispiel ausprobieren.

Die Aktionen bestehen immer aus:

• Einem test, dem der aktuelle String im Input-Feld unterzogen wird. Gültige Werte sind null oder ein regulärer Ausdruck
• Der durchzuführenden Aktion (action), wenn diese ausgewählt wurde. Dies ist eine normale JavaScript Funktion mit dem aktullem Eingabewert als Paramter
• Einem Titel (title) für die angezeigte Aktion
• Einem optionalen Hilfetext (help)

Weitere Features

Alle im Script verwendeten Strings sind je nach Geschmack anpassbar und alle Ergebnisse sind mit CSS Klassen für einfache Anpassbarkeit des Aussehens ausgestattet.

Download & Co.

Der Code ist auf GitHub gehosted, ausserdem enthält die README Datei weitere Informationen zur Funktionsweise.

Articles für das iPad

Das Featureset der Anwendung lässt zwar im vergleich zu anderen Wikipedia-Apps noch ein wenig zu wünschen übrig. Für längeres lesen ist die App allerdings meine erste Wahl.

Dazu muss man seine E-Mailadresse einfach unter http://www.dropbox.com/edu/ freischalten und schon erhält man für Einladungen 500 MB. Das ganze funktioniert auch rückwirkend. Wenn ihr also schon einen Schwung Einladungen erfolgreich verschickt habt, erhaltet Ihr dafür dann dafür auch nochmal 250 MB zusätzlich.

• Ich sollte meinen Rucksack mit allem notwendigen Kram (Batterien, Taschen- und UV-Lampe, Stiften, Zetteln, etc., etc.) mitschleppen. Dann hab ich wenigstens auch was zu trinken dabei.
• Einfallslose Multi-Caches, die einen für den Final nicht mal im Ansatz an die Start-Location zurück führen sind furchtbar.
• Das einwickeln von Dosen in Plastiktüten ist und bleibt einfach ekelhaft.
• Fliegenpilze sind hübsch :)

Eine Technik die hierfür genutzt wird sind die Load Cycles, dabei wird der Lesekopf der Festplatte bei Inaktivität nach einer gewissen Dauer (z.B. 8 Sekunden) in die Ruheposition gebracht.

Da gerade Betriebssysteme aus der Unix-Familie sehr häufig auch Systemdaten auf die Platte schreiben (Syslogs, allgemeine Informationen, etc.), geschieht dieses parken unter Umständen sehr häufig. Wie häufig, wird durch die Festplattenfirmware als Load Cycle Count gespeichert und kann zum Beispiel mit Hilfe von S.M.A.R.T. ausgelesen werden. Typischerweise geben die Hersteller gleichzeitig mit an, wie viele dieser Zyklen eine Festplatte im Durchschnitt aushält bis sie den Geist ausgibt. Bei den WD Caviar Green sind das zum Beispiel 300.000 Zyklen.

Eine Überprüfung meiner beiden WD20EARS Festplatten mittels smartctl -a /dev/hdX ergibt zum Beispiel:

 193 Load_Cycle_Count        0x0032   171   171   000    Old_age   Always       -       87307 193 Load_Cycle_Count        0x0032   182   182   000    Old_age   Always       -       54641 

Nimmt man diese Werte und dividiert sie durch die “Power_On_Hours“, lässt sich abschätzen wie viele Zyklen pro Stunde durchgeführt werden.  Daraus lässt sich dann letztendlich schließen, wann das vom Hersteller angegebene Limit erreicht wurde.

Für meine beiden Festplatten wären das dann jeweils:

Bei Festplatten die erst seit fünf Monaten in Betrieb sind ist das dann doch eine recht düstere Aussicht. Zum Glück haben das die Hersteller erkannt hat und man kann zum Beispiel mit Hilfe von WD IDLE diese Werte umstellen. Zumindest dann, wenn man die Geräte in einen Rechner einbauen und dort DOS booten kann.

Ich denke das ganze lohnt sich und ich werde das die nächsten Tage mal entsprechend umstellen.

Überwachung

Damit ich das ganze auch etwas besser im Auge behalten kann, habe ich noch zwei entsprechende Graphen in Cacti angelegt. Wer dafür bedarf hat kann das Cacti Graph Template und das entsprechende Shell Script (GitHub) herunterladen.

Das Script erstellt bei mir alle zwei Tage ein Backup von den bereits angelegten Sicherungen. Das ganze verwendet Hardlinks um Plattenplatz zu sparen. Sollte die Time Machine dann wieder auf die Idee kommen einfach alte Backups wegzuwerfen, existiert wenigestens noch eine Kopie für den Fall der Fälle.

Zu finden ist das ganze auch bei GitHub Gist 1144580.

Syslog Server

Die neue DSM 3.2 Beta Firmware für mein NAS liefert einen rudimentären Syslog Server mit. Da sowohl die AirPort Express, als auch die AirPort Extreme Basisstation einen Syslog Server ansprechen können verwenden nun beide Geräte den neuen Serverdienst.

Auf der Disk Station selbst ist die einzig relevante Einstellung, ab welchem Loglevel eine Benachrichtigung per E-Mail verschickt werden soll. Ich verwende im Moment “Error, Critical, Alert and Emergency“.

Syslog Server

Erweitertes Monitoring mit Cacti und SNMP

Für weitere Informationen für die Geräte im LAN habe ich zusätzlich auf dem NAS noch Cacti installiert.

Installation

Die Installation ist in ein paar Schritten Ruck Zuck erledigt:

1. Im Synology DSM die Web Station aktivieren
2. Über das Package Center phpMyAdmin installieren.
3. Cacti herunterladen und im automatisch angelegten Share “web” ablegen.
4. phpMyAdmin öffnen und cacti.sql aus dem Cacti Root-Verzeichnis importieren.
5. Auf der Konsole mit Hilfe von ipkg auf dem NAS net-snmp und rrdtool installieren
6. http://<diskstation>/cacti/ aufrufen und die Installation mit den entsprechenden Pfaden fertig stellen.
7. /etc/crontab mit dem Cacti Poller Aufruf erweitern: */5 * * * * root php /volume1/web/cacti/poller.php
8. /usr/syno/etc/rc.d/S04crond.sh restart

Konfiguration

Access Points

Für die AirPort Basisstationen bietet sich das auf theblinkinglight.com veröffentlichte AirPort Template und die dazugehörige Anleitung. Da der DHCP Server bei mir von der FritzBox (die leider keine Informationen via SNMP bereitstellt) übernommen wird, zeichne ich nur die Wireless Clients und den Traffic bei den einzelnen Interfaces auf.

Disk Station

Die Disk Station ist schon etwas schwieriger. Nachdem die von der Busybox eingesetzten Binaries sehr stark abgespeckt sind, müssen erst mal noch die Pakete grep, coreutils und gawk installiert werden.

Disk Usage

Um die Festplattenausnutzung zu visualisieren kann wohl leider nicht direkt die “Unix – Disk Usage” Data Input Method verwenden da das Script nicht die erwartete Ausgabe erhält. Ausserdem habe ich die Ausgabe erweitert um mehr Informationen getrennt charten zu können. Die angepasste Version:

 #!/bin/sh df -Pk $1 | grep -v Filesystem | awk '{sub(/^[ \t]+/, ""); print}' | awk '{printf "total:" $2 " used:" $3 " free:" $4}' 

Die Data Input Method, die Vorlage für den Graphen (Graph Template) und die Data Source müssen durch die Änderung angepasst werden.

Cacti - Data Input Method Einstellungen

Cacti - Data Template Einstellungen

Cacti - Data Template Einstellungen

Nachdem alle Graphen eingerichtet erhält man eine Schicke Übersicht was alles auf den einzelnen Geräten so los ist.

Die fertigen Graphen