Kerberos und NFS einrichten.

Ich kämpfe schon eine weile mit CIFS/Samba her rum. Bisher hab ich es leider nicht geschafft die Transferraten über mehr als 40MByte/s zu bekommen. Was bei Gigabit-Ethernet unbefriedigend ist. Vor einem Wechsel auf NFS habe ich mich aber immer gedrückt. Zum Einen weil dann immer die „Böse“ LDAP-Konfiguration im Raum stand, zum Anderen, weil ich der Meinung war Kerberos nicht zu brauchen.

Nun hat sich in den letzten Tagen herausgestellt, dass ich ein paar mehr Dienste brauche, die alle eine eigenen Authentisierung mit sich bringen. Darauf hatte ich keine Lust, ergo Kerberos musste her. Zweitens hat sich gezeigt, dass man LDAP nicht braucht. Das Maping von Usernamen/Groups funktioniert auch so Prima.

Es gibt ein gutes Tutorial, mit dem man innerhalb von einer Stunde einen NFS-Share mit Kerberos Unterstützung einrichten kann: NFSv4-Howto

Das Tutorial hat nur zwei Schönheitsfehler:

  • Der wichtigste Hinweis wird nicht hervorgehoben. Wer es ums verrecken nicht hinbekommt, dass sich NFS über Kerberos Authentifiziert sollte  seine /etc/krb.conf checken. Dort muss unter [libdefaults] der Eintrag „allow_weak_crypto = true“ gemacht werden.
  • Die Angaben für die /etc/exports Datei sind veraltet. Es wird noch die „gss/krb5“ verwendet. Aussehen sollten die exports aber so.

    /export       10.0.0.0/24(sec=krb5,rw,fsid=0, secure, no_subtree_check,async,no_all_squash)
    /export/Share1 10.0.0.0/24(sec=krb5:krb5i:krb5p,rw,fsid=0, secure, no_subtree_check,async,no_all_squash)

    So kann man auch gleich dem Benutzer überlassen welche „Absicherung“ er gerade benötigt.

Des bin ich beim Einrichten des NFS-Shares noch über eine Stolperstein gefallen:

Aus irgendeinem Grund war der NFS-Server im all_squash Modus. Soll heißen alle User wurden auf „Nobody/Nogroup“ gemapt. Was zur folge hatte, dass ich zwar den Share mounten konnte aber keine Berechtigung hatte. Mit der Option „no_all_sqash“ war das behoben.

Anschließend hab ich mal Bonnie++ auf den Share los rennen lassen. Das Ergebnis waren 95.1MByte/s Read/Write. Kein Vergleich zu CIFS. Einzig wenn ich die höchste Sicherheitsstufe (krb5p – Transportverschlüsselung) ging die Performance in Knie (20 MByte/s).

XBMC – FullHD – Micro-Ruckler

Wenn man durch die Foren schaut, stolpert man immer mal wieder über das Problem, dass einige Nutzer Micro-Ruckler bekommen wenn sie 720p oder 1080p Quellen abspielen. Ich gehörte auch zu dieser Problemgruppe und will hier kurz beschreiben wie man das Problem angehen kann.

Als erstes muss man die Mikro-Ruckler erst mal eindeutig einer „Quelle“ zuordnen. Es gibt sehr viele Möglichkeiten, wie Mikro-Ruckler zu Stande kommen können:

  • Kodierfehler – die Ruckler z.B. tretet nur bei einem Film auf.
  • Frame-Drops – Das passiert wenn ein Bildwiederholfrequenz der Quelle höher ist als die Abspielfrequenz.
  • Falsche Timings bei der Ansteuerung des Bildschirms.
  • „andere Störenfriede“…

In meinem Fall konnte ich Kodierfehler ausschließen. Alle Filme wiesen sporadisches extrem kurzes Ruckeln auf. Einige Leute haben es nicht mal war genommen, mich hat es hingegen schon genervt (besonders wenn man weiß auf was man achten muss).

Um der Fehlerquelle einzugrenzen hab ich mir einige Naturaufnahmen mit langen ruhigen Schwenks in FullHD ausgesucht, dazu noch Batman – The Dark Knight wegen den starken Hell-Dunkel Kontrasten.

Als erstes hab ich die Timings wie in diesem Beitrag beschrieben korrigiert: Fixing the 24p issue.

Das hat die Ruckler zwar reduziert, aber sie waren immer noch vorhanden, das hat mich jedoch auf eine zweite Fährte gelockt. In dem Beitrag wird beschrieben wie man die Timings korrigiert und XBMC auf die Wiederholfrequenz der Quelle anpasst (Option). Durch test wurde mit ziemlich schnell klar, dass in meinen Fall nicht die Wiederholfrequenz das Problem darstellten, sondern die Timings. Eine Änderung von 60Hz auf 50Hz oder gar 24Hz hatte faktisch keinen Einfluss. Was jedoch auffällig war: sobald ich VSync abgeschaltet hatte, waren die Ruckler weg, aber die Bildfehler beim abspielen einer Testsequenz enorm. VSync musste also aktiviert bleiben. Ein kurze Suche im Internet hat mich auf die Composite-Extension aufmerksam gemacht.

Ich hab die automatische Anpassung abgeschaltet und in der xorg.conf nur einen Bild-Modus hinterlegt. Zusätzlich habe ich die Composite-Extension abgeschaltet.

Section "Extensions"
 Option "Composite" "disable"
EndSection

Nach einem Neustart kommt es nun zu keinen Mikrorucklern mehr.

BIRD manuel auf DD-WRT einrichten

Wenn man die Buffalo DD-WRT Version einsetzt und Routing (RIP, OSPF, BGP) aktiviert und sich danach nichts tut, sollte man mal mittels SSH Kontrollieren ob überhaupt ein Routing-Dienst läuft. Dazu muss man erst mal raus finden welcher dienst überhaupt laufen sollte. Das geht ganz einfach. In der Konsole versuchen „zebrad“ oder „bird“ aufrufen. Schlägt letzterer an muss man wie folgt vorgehen um den BIRD „manuell“ einzurichten.

Als erstet den Router-Modus zurückstellen auf „Gateway“, nicht das einem die Einstellungen aus der WebGUI in die Suppe spucken. Anschließend erstellt man das Verzeichnis /tmp/bird und die Datei /tmp/bird/bird.conf. Diese Datei gestaltet man nach seinen Wünschen und startet dann den BIRD.

mkdir /tmp/bird
vi /tmp/bird/bird.conf
bird

Eine Beispiel-Config findet man hier: Routing unter Ubuntu

Um das ganze zu automatisieren, muss die Config-Datei im NVRam hinterlegen.

nvram set zebra_conf="$(cat /tmp/bird/bird.conf)"
nvram commit

Beim Systemstart muss mittels des Startup-Skriptes das Verzeichnis und die Config-Datei angelegt werden.

mkdir /tmp/bird
nvram get zebra_conf > /tmp/bird/bird.conf

Den BIRD nicht beim Systemstart starten. Leider schießt die ServiceKontrolle/ProcessMonitor den BIRD automatisch ab wenn er da ist und ein Interface hochfährt (oder sich allgemein was ändert). Da die Speichervariablen (die ich noch nicht ermitteln konnte) keinen BIRD-Start vorsehen, wird er leider nicht nach gestartet.
Der richtige „Ort“ zum startet den BIRD ist daher das Firewall-Scriptes. Das wird immer ausgeführt, sobald sich an den Interfaces was ändern und ganz wichtig, es ist das letzte Skript.

if [ -ne $(pidof bird) ]; then
bird
fi

Das IF-Statement verhindert nur, dass der BIRD nochmal gestartet wird, wenn er schon existiert.

Auto-Reconnect für DD-WRT

Aus irgendeinem, mir noch nicht ganz nachvollziehbaren Grund, erkennt der pppd manchmal nicht, dass das ppp-Interface down ist und keine Verbindung mehr besteht. Um das zu beheben muss man normalerweise das WebInterface aufrufen und „reconnect“ drücken. Das kann man auch automatisieren.

Als erstes erstellt man eine Datei unter /tmp/connection_tracker.sh

#!/bin/sh

if [ $(ping -c 1 $(nvram get wan_ipaddr)|grep -c from) -lt 1 ]; then 
  logger -t connectiontracker nvram get wan_ipaddr unreachable
  killall redial; 
  killall pppd; 
  sleep 5 
  pppd file /tmp/ppp/options.pppoe >/dev/null; 
  logger -t connectiontracker reconnect wan nvram get wan_ipaddr successfully 
fi

Was macht das Script? Es versucht die IP des WAN-Interfaces zu pingen. Ist das Down gibt es keinen Treffer. „grep“ wertet die Rückgabe des ping Befehls aus und zählt die Zeilen. Gibt es weniger als einen Treffer (also Null) wird der redial und pppd gestoppt und neu gestartet.

Anschließend fügt man eine NVRAM-Variable hinzu. Gibt es die Variable wird sie überschieben, Ansonsten wird sie angelegt.

nvram set rc_custom="$(cat /tmp/connection_tracker.sh)"
nvram commit

Über den Startup-Script/Command muss diese Datei nun immer angelegt werden.

nvram get rc_custom>/tmp/connection_tracker.sh

Über einen zusätzlichen Cron-Job die Überprüfung alle 15-Minuten durchführen.

*/15 * * * * root /tmp/connection_tracker.sh