Rolling Backups sind eine beliebte Variante um zum einen alle BackupMedien gleich-verteilt zu ab zu nutzen und zum anderen mehrere Backupversionen zur Verfügung zu haben. Diese Arbeitsweise wird jedoch mit zunehmender Speichergröße unpraktisch. Ein Fullbackup ist bei 2TB nicht mehr Täglich möglich (6-8 Stunden IO nur durch Backup). Bei inkrementellen Backups ist das Wiederherstellen einzelner Dateien zeitaufwändiger.
Ein guter Kompromiss sind Tools wie “rdiff-backup”. Diese bietet quasi ein Full und Inkrementell Backup in einem rutsch an. Da nur Änderungen geschrieben werden, bleibt die Dauer des einzelne Backuplaufes kurz und da immer ein FullBackup gehalten wird, kann man ohne Umwege auf die “aktuellste” Version zurückgreifen. Nur wenn man auf ältere Versionen zurückgreifen will, muss man “ein bisschen” Rechenzeit einplanen.
Jedoch muss bei rdiff-backup immer der letzte aktuelle Stand als Backup vorliegen. Tauscht man einfach platten durch, kann man beim “einlegen” einer neuen Platte nicht mehr auf die alten Daten zugreifen. Mann muss die neue Platte also vorher mit den alten Daten bespielen.
Die Idee: Man richtet kurzzeitig einen Mirror zwischen HDD n und HDD n+1 ein. Die Syncronistation beeinflusst das Gesamtsystem kaum, da es sich Backupplatten handelt. Das Backup bleibt über die gesamte Zeit verfügbar, es können also weitere Inkrements gespeichert werden. Die Syncronisationsdauer spielt also keine Rolle. Ist der Mirror hergestellt entfernt man HDD n aus dem System und legt sie in einer anderen “Brandzone” ab. HDD n+1 übernimmt jetzt die aktive Backupphase. Das kann man so lange treiben bis einem Entweder die Platten ausgehen oder man die gewünschte Datensicherheit/Speicherdauer erreicht hat.
Zum umsetzen kann man LVM nutzen. Das Backupdevice muss jedoch von Anfang schon ein LVM-Device sein.
Als erstes initialisiert man einen Mirror. In Fall wird dem Logischen Device vgBackup/lvBackup die Platte /dev/sda hinzugefügt.
pvcreate /dev/sda #ggf sda zu für die LVM Nutzung vorbereiten. lvconvert -m 1 vgBackup/lvBackup /dev/sda --corelog lvs #hiermit kann der Sync-Status abgefragt werden.
Nun muss der Spiegel aufgebrochen werden. Normalerweise kann man die Platte einfach so entfernen (HotSwap) wenn kein IO stattfindet. Wenn man sichergehen will, mountet man das Device mal kurz read only.
Anschließend werden ein Haufen fehlermeldungen auftrehten die auf die Fehlende Platte hinweisen. Die wird man mit folgendem Befehl los:
vgreduce --removemissing vgBackup --force
Da ich mehrere Android Geräte in Benutzung habe die ich nicht “rooten” darf und dennoch einen VPN Tunnel in mein Heimnetzwerk brauche, hatte ich das “Vergnügen” mich mit IPSec/L2TP – Tunneln auseinander zu setzten. Android bietet native aktuell vier VPN-Varianten an: PPP, L2TP, IPSec/L2TP (PSK), IPSec/L2TP (Certificate)
PPTP fällt aus, da der Android-Client nur primitive Authentifizierungen anbietet, welche als leicht angreifbar gelten. L2TP ist nur ein Layer2-Tunnel-Protokoll um darüber wiederum ein PPP-Tunnel aufzubauen. Da L2TP selber nicht Verschlüsselt ist das ganze nur so sicher wie der PPP Tunnel. Bei welchem wieder nur primitive Authentifizierungen angeboten wird. Bleibt als letzte Alternative nur den L2TP-Tunnel via eines IPSec Tunnel zu sichern. Sowohl die PSK (PreSharedKey) als auch zertifikatsbasierte Lösung sollten hinreichend sicher sein.
Damit beginnt aber auch schon der Ärger. IPSec-Gateways findet man nur in wenigen SOHO Geräten vorkonfiguriert (z.b. einigen Fritzboxen) und das aus gutem Grund. Das Zusammenspiel Clients, Netze, Netzanbieter und IPSec läuft nicht so reibungslos wie es sollte. Dazu gleich mehr.
OpenWRT bietet gleich mehrere IPSec und L2TP Dienste an. Ich hab mich für den StrongSwan4 – Daemon als IPSec Dienst entschieden. Da dieser auch IKEv2 anbietet, in der Hoffnung dass dies vom auf Android eingesetzten Racoon-Daemon auch mal genutzt wird.
Des weiteren komm der xl2tp-Daemon oder der standardmäßig installierte ppp-Daemon zum Einsatz.
Bevor man die Sache angeht sollte man folgendes beachten um sich viel Zeit und Ärger zu ersparen: Das fehleranfälligste an einem IPSec/L2TP-VPN ist der IPSec-Anteil. Man sollte diesen also getrennt testen. Als sinnvoll hat es sich gezeigt, den Zielrouter mal vom Netz ab zu klemmen, die Firewall abzuschalten und plain den xl2tp-Daemon im Zusammenspiel mit dem PPP-Daemon zu testen. Das ganze geht einfach von der Hand und ist robust und stressfrei.
Danach kann man den IPSec Tunnel via PSK hochziehen und im internen Netz testen. Anschließend kann man ggf noch Zertifikate zur Authorisierung nutzen. Erst wenn das alles im internen Netz klappt sollte man Versuchen von “Außen” auf das VPN zuzugreifen. Es empfiehlt sich an dieser Stelle für die Mobilen Devices einen LogReader zu installieren. Für Android ist das die App aLogcat. Leider gibt der racoon-Daemon nur in die Logfiles aus warum er einen Tunnel wieder zu macht oder warum er erst gar keinen aufbauen will.
Wie eingangs erwähnt gibt es mehrere Stolpersteine. Es war mir z.b. nicht möglich eines meiner Geräte dazu zu bewegen, den IPSec Tunnel aufzubauen. Das lies sich aber zweifelsfrei auf das Netzsegment zurückführen. Eine SIM-Karte des gleichen Netzanbieters aus einem anderen Gerät (anderes Netzsegment) eingewechselt und schon konnte der Tunnel aufgebaut werden. Es scheint Probleme beim Zusammenspiel Racoon – open/strong-Swan zu geben wenn mehrfaches “NAT”ing zum Einsatz kommt.1
Diesen Widrigkeiten zum Trotz kann man das ganze relativ leicht auf OpenWRT oder Ubuntu wie folgt einrichten:
Man benötigt als Pakete den PPP-Daemon, XL2TP-Daemon und StrongSwan.
Configuration – /etc/ppp/options.xl2tpd
#Das wird nur gebraucht für radius-anbindung plugin radius.so radius-config-file /etc/ppp/radius.conf avpair NAS-Identifier=l2tp-vpn avpair NAS-Port=1 auth #ggf für testzwecke noauth #für debugging dump lock noccp novj novjccomp nopcomp noaccomp ms-dns DNS-Server-IP refuse-chap require-pap
Hinweis ich erzwinge das unsichere PAP weil der IPSec-Tunnel via Zertifikaten gesichert ist (sehr schwer zu brechen, eigene CA) und FreeRadius für alles andere Klartextpasswörter im Zugriff braucht. Das muss man ggf. an seine Anforderungen anpassen!
Configuration xl2tp – Achtung hier verwende ich keine Authentifizierung. Das überlasse ich IPSec und PPPd
/etc/xl2tpd/xl2tpd.conf
[global] port = 1701 ;auth file = /etc/xl2tpd/xl2tp-secrets access control = no ipsec saref = no ;wichtig SAREF funktioniert nicht mit StrongSwan ;folgende zielen für debuggin einkommentieren ;debug avp = yes ;debug network = yes ;debug packet = yes ;debug state = yes ;debug tunnel = yes [lns default] exclusive = yes ip range = 10.0.100.5-10.0.100.50 hidden bit = no local ip = 10.0.100.1 length bit = yes refuse authentication = yes name = IpSec-Tunnel ppp debug = no pppoptfile = /etc/ppp/options.xl2tpd
Nun zu IPSec
config setup
strictcrlpolicy=no #Für ein kleines Setup wird keine RevokationList verwaltet...
plutodebug=none
nat_traversal=yes #anschalten wenn man mit NAT(ted) Clients rechnet.
virtual_private=%v4:10.0.0.0/8,%v4:192.168.99.0/24,%v4:!192.168.100.0/24
charonstart=no #noch brauchen wir kein IKEv2
#protostack=netkey
conn NAT-Tunnel
authby=rsasig #Authentisierung via Zertifikaten
pfs=no
compress=no
rekey=no
keyingtries=3
type=transport
auto=add
left=%defaultroute
leftcert=mycert.pem
leftid=@mydomain
leftrsasigkey=%cert
leftsendcert=always
leftprotoport=17/1701
right=%any
rightsubnet=vhost:%no,%priv
rightprotoport=17/%any
rightrsasigkey=%cert
rightca=%same #Wichtig das sorgt dafür dass alle Zertifikate die von der gleichen CA unterschrieben wurden wie das LeftCert angenommen wurden.
keyexchange=ikev1 #ikev2 ist Standard auf ikev1 downgraden, da Android mit ikev1 reinkommt.Anschließend sollte man sich noch vor der Dummheit der Nutzer und Clients schützen. Wenn der Racoon unter Andoid die Verbindung abbricht, versucht es der L2TP-Daemon dennoch aufzubauen. Die Verbindungsverwaltung bemerkt das zwar und beendet die Verbindung sofort, dummerweise wurden schon die Authentisierungs-Daten im Klartext gesendet. (Nein auch MS-Chap-v2 zählt als Klartext). Ein Angreifer kann so gezielt (über NAT) ein kurzes Downgrade erzwingen, die Daten abgreifen und dann selber ohne IPSec einen L2TP-Tunnel aufbauen.
Um das zu verhindern muss man IPTables dazu bringen Verbindungen für Port 1701(L2TP) nur dann anzunehmen, wenn diese über IPSec reingekommen sind. Früher war das einfach, da gab es ein ipsec-Device, heute muss man über die mangle-Table rann. Das ganze sieht dann wie folgt aus
iptables -A INPUT -p udp --dport 500 -j ACCEPT #IPSec kommt immer über port 500 rein iptables -A INPUT -p esp -j ACCEPT # Encapsulated Security Payload - IPSec Protokoll iptables -A INPUT -p ah -j ACCEPT #Authentication Header - IPSec Protokoll iptables -t mangle -A PREROUTING -p esp -j MARK --set-mark 1 # Der eigendliche Paylod kommt über das ESP protokol, alle Pakete markieren. iptables -A INPUT -m mark --mark 1 -p udp --dport 1701 -j ACCEPT #alle Pakete die markiert wurden und an 1701 gehen werden akzeptiert.
Mittels dieser Regel lehnt der Gateway alle L2TP Pakete ab, die nicht über IPSec gesichert wurden.
Wenn man unter Linux einen Rechner betreibt findet man einen Haufen an Möglichkeiten den Bandbreitenverbrauch zu ermitteln. Betreibt man hingegen einen Router und will nicht nur den eigenen Verbrauch, sondern den Transfer-Traffic aufgeschlüsselt nach gewissen Attributen, wird es dünn im Lösungsumfeld. Soll das ganze dann noch auf einem handelsüblichen SOHO-Router laufen, wird es richtig kniffelig.
Das erste Problem ist, dass man wissen muss nach,nach was man sucht. Unter “Bandbreiten-Monitor” verstehen die meisten Lösungsvorschläge das Monitoring des eigenen Verbrauchs/Traffic oder nur das “Gesamtaufkommen” an einem Interface. Kurzum: Werte die sich leicht ermitteln lassen. Das aufschlüsseln des Transfertraffics bezeichnet man häufig als IP-Accounting. Danach teilt sich das Feld in folgende Lösungen auf:
- Promiscuous Mode Basiert: Hierbei wird ein Interface in den Promiscuous-Mode geschaltet und der komplette Netzwerktraffic mitgeschnitten. Die Lösungen unterscheiden sich dann darin, wo und wie die Daten ausgewertet werden. Im einfachsten Fall werden die Pakete vorverarbeitet und an eine Sammelstelle weiter geleitet. Bekannteste Vertreter sind NTop, NProbe und bandwidthd.
- IPTables/NetFilter Basiert: Hierbei wird ausgenutzt, dass IPTables mit protokolliert wie viele Pakete/Bytes über eine Filter-Regel gelaufen sind. Dies kann man dann asyncron über Bash-Befehle auslesen.
Der Promiscuous Mode basierten Lösungen sind die allumfassenden Lösungen. Sie schneiden alles mit und können die detailliertesten Auswertungen bieten. Sie haben jedoch immer zwei massive Nachteile. Erstens ist die benötigte CPU-Leistung enorm. Selbst die schlanke NPrope schaffte bei einem 600MHz Prozessor nicht mal Ansatzweise den zu erwartenden Transfertraffic (100Mbit/s). Auch wird das Analyseziel stark belastet. Sowohl was die Bandbreite als auch die CPU-Last betrifft. Das ist für eine einfache Bandbreitenanalyse ein wenig übertrieben. Des weiteren ist es mehr als fraglich ob das ganze rechtlich überhaupt zulässig ist. Immerhin handelt es sich hierbei um eine DPI, jeh nach Ausführung sogar mit ungesicherter Ausleitung.
Die IPTables -Variante hat den Vorteil, dass die Pakete sowieso durch IPTables verarbeitet werden müssen. Der Overhead für das zusätzliche Monitoring hält sich in Grenzen. Auf besagtem 600 MHz Prozessor war keine Leistungsabfall durch Zu- oder Abschalten der Filter-Regeln zu messen, noch gab es eine nennenswerte CPU-Last. Der Nachteil ist jedoch, dass man wissen muss was man Monitoren will. Wenn man nur wissen will, wie viel Traffic auf ein Netzsegment entfällt, ist das einfach umsetzbar. Will man jedoch wissen auf welchen Client im Netzsegment der Traffic aufgelaufen ist, wird es schwierig. Besonders wenn es sich um ein Netzsegment mit ständig wechselnden Clients handelt wird es nahezu unmöglich das mit IPTables alleine zu bewerkstelligen.
Abhilfe schafft ein die ULog Schnittstelle und ein Daemon aus dem pmacct.net-Project. IPTables führt das Decoding und Vorfilterung durch und leitet das Paket dann an den uacctd weiter. Dieser filtert, aggregiert und verarbeitet die Daten oder leitet sie an ein Sammelstelle weiter.
Das Ganze ist denkbar einfach zu konfigurieren. Als erstes braucht es nur IPTables-Regeln die die interessanten Pakete ausleiten.
iptables -I FORWARD -d 192.168.0.0/16 -j ULOG --ulog-nlgroup 1 --ulog-cprange 48 --ulog-qthreshold 50 iptables -I FORWARD -s 192.168.0.0/16 -j ULOG --ulog-nlgroup 1 --ulog-cprange 48 --ulog-qthreshold 50
Durch diese Regeln werden alle Pakete die das 192.168-Netz betreffen an die ULog-Schnittstelle weitergeleitet. Die weiteren Parameter bewirken, dass immer gewartet wird bis sich 50 Pakete gesammelt haben und nur die ersten 48 Bytes weitergeleitet werden. Die Group-Angabe ist später für die Auswertung wichtig.
Der entsprechende uacctd ist wie folgt konfiguriert:
daemonize: true pidfile: /var/run/uacctd.pid syslog: daemon uacctd_group : 1 plugins: memory[host_in], memory[host_out] aggregate[host_in]: dst_host aggregate[host_out]: src_host aggregate_filter[host_in]: dst net 192.168.0.0/16 aggregate_filter[host_out]: src net 192.168.0.0/16 imt_path[host_in]: /tmp/pmacct_host_in.pipe imt_path[host_out]: /tmp/pmacct_host_out.pipe
Durch diese Konfiguration werden zwei Endpunkte angelegt, jeweils einen für ein- und ausgehendem Traffic und nach internem Client aggregiert. Der Speicherverbrauch und die Prozessorlast ist in meinem Einsatzgebiet zu vernachlässigen (selten mehr als 20 Clients gleichzeitig) kann jedoch je nach Einsatzart stark ansteigen. Ob das ganze bei 10k Clients und “portgenauem” Monitoring noch skaliert habe ich nicht ausprobiert.
Auswerten kann man das ganze wie folgt:
pmactt -s -p /tmp/pmacct_host_in.pipe
Mit der eigenen Wunsch-Skriptsprache kann man nun die wildesten Skriptes zum überwachen des Traffics basteln.
Hier mein Beispiel für einen Perl-Skript/Munin-Plugin: munin-bandwidth.perl
Betreibt man privat einen Radius-Server und will seine Squeezebox mittels EAP-TLS ins Netzwerk einbinden, wird man vom der geführten Konfiguration darauf hingewiesen, dass dieser Modus nicht unterstützt wird. Das ist gelinde gesagt Bullshit. Die Entwickler waren sich nur zu fein ein entsprechenden Konfigurationstool anzubieten.
Bevor es losgeht, braucht man erst mal die entsprechenden Client-Certs. Leider unterstützt der wpa_supplicant nicht alle Formattypen, explizit müssen die Client-Certs im DER-Format sein. Beim Root-CA-Cert ist es egal.
Wer zb aus dem PEM Format ein DER machen will, kann das wie folgt machen
openssl x509 -in newcert.pem -inform PEM -out newcert.der -outform DER#Konvertiert das Signierte ClientCert openssl rsa -in newkey.pem -inform PEM -out newkey.der -outform DER #Konvertiert den Client-Key
Ist das erledigt muss man die Squeezebox erst mal mittels Kabel anschließen und per SSH auf die Box zugreifen. Am besten unter /etc/certs die erzeugten certs (inklusive root-ca) per scp ablegen.
Anschließend nimmt man sich die /etc/wpa_supplicant.conf vor und legt wie folgt ein Netzwerk an (oder modifiziert es):
network={ ssid="SSID" scan_ssid=1 #proto=RSN #WPA2 key_mgmt=WPA-EAP pairwise=CCMP group=CCMP eap=TLS identity="frei zu wählen" ca_cert="/etc/cert/root.ca.pem" client_cert="/etc/cert/client-cert.der" private_key="/etc/cert/client-key.der" private_key_passwd="password" }
Das ist aber nur die halbe Miete, leider muss man die Netzwerkfähig auch noch manuell vornehmen. Die GUI ist nicht nicht der Lage von einem Halb-Vorkonfigurierten WLAN eine DHCP Request zu machen.
Also noch schnell in die /etc/network/interfaces und das Netzwerk hinterlegt/angepasst
auto lo
iface lo inet loopback
mapping eth1
script /etc/network/if_mapping
iface eth0 inet dhcp
script /etc/network/udhcpc_action
auto eth1=SSID
iface SSID inet dhcp
script /etc/network/udhcpc_actionNach einem Neustart der Box sollte sich das Gerät ordnungsgemäß am Radius-Server anmelden.
So nun hoffentlich der finale Artikel zum Thema Ruckler während des HD Playbacks. Nachdem ich mir sogar ein neues Board (AMD FUsion zum Test) geholt hatte , musste ich leider feststellen, dass das Thema alles andere als einfach zu Debuggen ist.
Nach nunmehr mehreren Monaten des Suchens hab ich den letzten Verursacher von Bildrucklern gefunden. Am ende liefen nicht mal H264 Videos im Baseline-Profile ordentlich Ruckelfrei. Da hab ich in meiner Verzweifelung (und Hoffnung) mal das HDMI Kabel getauscht. Zum Glück hatte ich kein Ersatz und fand den Input-Converter DVI-HDMI meines TVs nicht. Folglich musste ich auf das “gute alte” VGA-Kabel ausweichen. Sowohl Board als auch TV hatten den Anschluss noch. Und siehe da, ruckelfreies H264 in allen Lebenslagen! Kein störendes Bildstottern oder Fragmente. Alles so wie es sein soll.
Da ich nicht glauben wollte, dass das Kabel defekt war oder gar ein genereles Problem mit HDMI vorliegt, hab ich mich mal auf die Suche nach “Bildverbesserern” auf Seitens des TVs gemacht. Ich wurde fündig. Ein bisschen vergraben wendet mein TV allerhand Algorithmen auf das Eingangssignal an. Allerdings nur auf das HDMI Signal. Standardmäßig waren die Einstellung wohl zu viel für die kleine CPU des TVs. So dass es statt zu Verbesserungen zu Fragmenten und Stottern kam. Sehr brauchbar.
Fazit: Wer ein modernes Display mit HDMI Input betreibt, kann nicht davon ausgehen, dass sein Eingangssignal auch ohne Veränderung ausgegeben wird. Kommt es zu Rucklern, Fragmenten oder anderen sporadischen Bildfehlern, einfach mal nachschauen ob nicht irgendwo ein Bilderverbesserer wie “Rauschunterdrückung”,”Bewegungsglättung” oder gar “Upscaler” sein Unwesen treibt.
Nach meinen ersten Maßnahmen gegen MicroRuckler hat es ein wenig gedauert bis ich den letzten Verursacher gefunden hatte. Das Problem war, dass die Ruckler nur sporadisch ab und zu auftraten. Mal 30 Minuten lang gar nicht, dann wieder im 5 Minuten Takt.
Als Verursacher hat sich das PerformanceManagement der NVidia-Karte herausgestellt. Die Taktet die Karte runter, sobald wenig Leistung gebraucht wird. Scheinbar dauert das Justieren zu lange, so dass es zu FrameDrops kommen kann.
Zur Behebung hab ich folgendes in die ‘/etc/X11/xorg.conf’ eingepflegt:
Section "Device" Identifier "Device0" Driver "nvidia" VendorName "NVIDIA Corporation" Option "NoLogo" "True" Option "NvAGP" "1" Option "RenderAccel" "true" Option "TripleBuffer" "True" Option "RegistryDwords" "PowerMizerEnable=0x1; PerfLevelSrc=0x2222; PowerMizerDefault=0x1; PowerMizerDefaultAC=0x1" EndSection
Die Vorletzte Zeile aktiviert den TripleBuffer, so werden 3 statt zwei Bilder vorgehalten. In 2D Anwendungen (Videodarstellung) ist der Performanceverlust und Speicherverbrauch verkraftbar gegenüber der ruckelfreiem Abspielen.
Der letzte Befehl erzwingt vom NVidia-Treiber, dass die Grafikkarte immer mit maximaler Leistung arbeitet.
Sollte es immer noch zu leichten Ruckler kommen, kann man den Treiber nochmals mittels nvidia-settings dazu zwingen, endlich in den PerformanceMode zu gehen…:
nvidia-settings -a '[gpu:0]/GPUPowerMizerMode=1'
Nachdem ich NFS und Kerberos installiert hatte, wollte ich auch Samba/CIFS an Kerberos anbinden. Das gestaltete sich schwerer als erwartet.
Das Einrichten auf Serverseite gestaltete relativ reibungslos. Einfach dem Samba-Dienst entsprechend Konfigurieren.
security = ADS
realm = AQUA
kerberos method = system keytab
encrypt passwords = trueIm Kerberos hinterlegt man einen entsprechenden Principal und fügt ihn dem CIFS-Server hinzu.
sudo kadmin -p kerberosadmin/admin addprinc -randkey cifs/server.fqdn ktadd cifs/server.fqdn
Nach einem Neustart des Dienstes werden die User-Credentials von Samba gegenüber Kerberos Authentiziert.
Auf Client-Seite war dem ganzen nicht so leicht bei zu kommen. Als erstes muss ein Client-Key am Kerberos erzeugt werden und in der Client Keytab hinterlegt werden.
sudo kadmin -p kerberosadmin/admin addprinc -randkey cifs/client.fqdn ktadd cifs/client.fqdn
Anschließend mounted man den Share wie folgt:
mount -t cifs //server.fqnd/Share /mnt/cifs-share -o sec=krb5,uid=1001
Bis dahin hat mich das “nur wenige” Stunden gekostet. Der Parameter “uid” wird scheinbar gebraucht wenn Winbind nicht so will, wie es soll. Ich hab es ums verrecken nicht hinbekommen, dass der Winbind mehr schmeißt als nur Fehler.
Daneben war es mit nicht möglich den krb5i-Modus zu aktivieren, also Schutz gegen Veränderung der einzelnen Daten-Pakete. Zudem scheint CIFS/Samba nur beim Mount die Usercredentials zu überprüfen und die Verbindung dann an den User zu knüpfen. Wenn ein anderer User (root) auf den Share zugrifft, erfolgt das unter der UID des Users der den Mount aufgemacht hat.
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).
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.
