Kategorie: Administration

Alles rund um das Thema Administration

Ubuntu Upgrade / Neuinstallation mit geringer Downtime

Raptor 2101Leave a comment

Wenn man den Ubuntu LTS auf einem Server einsetzt hat mein ein relativ ruhiges Leben. Es gibt kaum wartungsaufwand, da sich die Updates automatisch einspielen (wenn man das will), nur ab und an sollte man den Rechner neustarten.

Will man die Maschine jedoch auf die neue Version hochziehen ist Arbeit angesagt. Ob man nun das Upgrade macht oder ein blankes System aufspielt. Beides kostet Zeit und eine Downtime. Kann man ein ersatzsystem sein eigenen nennen oder eine Weile auf die Services verzichten ist das keine Problem, leider ist dem selten so.

In meinem Fall geht ohne meinen Ubuntu-Server gar nichts und für eine komplettes Spiegelsystem hab ich weder Geld noch Platz. Ich brauchte einen Weg um die Downtime für die gesamte Familie auf unter 4 Stunden zu drücken. Kurz der WLAN Wecker sollte am nächsten Morgen wieder wecken. (Ubuntu-Server = Radius, MediaStorage und MediaServer)

Was es dazu braucht ist ein Software-Raid (Mirror) eine zweite Maschine und eine Virtuelle-Umgebung die eine physikalische Platte „durchreichen“ kann.

Der Trick ist einfach. Man baut im laufenden Betrieb eine der Mirror-Platten aus. Das kann jeh nach Konfiguration (kein HotSwap, „umbauarbeiten“ notwendig) eine kurze Downtime bedeuten. Anschließend schließt man die Platte an einem anderen Rechner an und haut ein VM-Host seiner wahl drauf. Dieser sollte direkt mit Physikalischen Platten umgehen können. (VMWare, VirtualBox) Nun muss man nur noch eine VM erzeugen und anschließend von der Platte booten. In meinem Fall funktionierte das tadellos. Der virtuelle „Server“ meckerte zwar eine defekten Raid und fehlendes Netzwerk an, aber das ließ sich schnell beheben.

Ab diesem moment kann man in aller Sehlenruhe sein Upgrade einspielen oder gleich den ganzen Server neu aufsetzen.

Anschließen muss man nur die eigentliche Hardware runterfahren. Die noch aktive Platte ausbauen und (ganz wichtig) die RAID-Header-Informationen löschen (mdadm –zero-superblock). Die „VM“-Platte wieder in den Rechner einbauen durchstarten und hoffen dass man alles richtig eingerichtet hat. Wenn alles klappt bootet der Rechner ohne murren durch, man richtet den RAID wieder ein und hat eine Downtime von unter einer Stunde.

XBMC unter 12.04

Raptor 2101Leave a comment

Im Rahmen meines Wechsels von Ubuntu 10.04 bis 12.04 musste als erstes mein HTPC dran glauben. Das ganze ging recht Problemlos von statten. Einzig der NoDM hatte Probleme bereitet. NoDM erwartet den XServer unter /usr/bin/X. Ubuntu 12.04 stellt selbigen aber (ohne Link) unter /usr/bin/Xorg zur Verfügung. Da musste mit einem Link nachgeholfen werden.

Danach lief sofort XBMC hoch, ohne weitere Probleme. Danach begann jedoch die Detailarbeit.

Wie gehabt muss nachgeholfen werden, wenn man vie XBMC den Rechner runter fahren möchte. Dazu bedarf es der Packete policykit-1, upower und acpi-support.

sudo aptitude install policykit-1 upower acpi-support

anschließend müssen dem XBMC-User die entsprechenden Rechte eingeräumt werden:
File /var/lib/polkit-1/localauthority/50-local.d/xbmc-actions.pkla

[Actions for xbmc user]
Identity=unix-user:xbmc-user
Action=org.freedesktop.upower.*;org.freedesktop.consolekit.system.*;org.freedesktop.udisks.*
ResultAny=yes
ResultInactive=yes
ResultActive=yes

Danach kann man über die entsprechenden Menüs/Kommandos aus XBMC heraus den Rechner Ausschalten, Schlafen legen oder in den Hibernate schicken.

Um den Rechner wieder aufzuwecken bedurfte es eines weiteren Kniffs. Die Schnittstelle, wie man ein USB Device für das Aufwecken markiert hat sich verändert. Ich musste es wie folgt erweitern:

#!/bin/sh
echo "USB0" > /proc/acpi/wakeup
echo "USB2" > /proc/acpi/wakeup
echo enabled > /sys/bus/usb/devices/3-1/power/wakeup
echo enabled > /sys/bus/usb/devices/usb1/power/wakeup
echo enabled > /sys/bus/usb/devices/usb2/power/wakeup
echo enabled > /sys/bus/usb/devices/usb3/power/wakeup
echo enabled > /sys/bus/usb/devices/usb4/power/wakeup

Interessanterweise war die „Breitbandfreigabe“ nur für den Suspend nötig. Um aus den Hibernate aufzuwachen reichte es das 3-1 Device zu „enablen“. Ich hab das Script auch nicht mehr in der rc.local verlink sondern lasse es vor und nach jeden Suspend/Hibernate ausführen, indem es unter /etc/pm/sleep.d abgelegt wurde.

Ein letzer Kniff war nötig damit sich das DVD-Laufwerk nach dem mounten auswerfen lies. Dazu musste ich in der /lib/udev/ruled.d/60-cdrom_id.rules die folgende Zeile ändern.

IMPORT{program}="cdrom_id --lock-media $tempnode"

So sollte es aussehen, dann lässt sich das Laufwerk jederzeit öffnen.

IMPORT{program}="cdrom_id $tempnode"

Quellen:

Zwei Jahre Ubuntu 10.04 – Zeit für einen Wechsel

Raptor 2101Leave a comment

Seit dem 29 April 2010 betreibe ich meinen HomeServer mit Ubuntu LucidLynx. Danach hab ich suxesive meine ganze Rechner auf den Langläufer umgestellt. Die folgenden zwei Jahren waren die ruhigsten in meiner ganzen Zeit, die ich mit Computern zu tun hab.

In der ganzen Zeit ereilten mich nur zwei „schwere Fehler“ (GAUs) die ich nicht auf meine eigene Dummheit zurückführen konnte. Gleich zu beginn Zerschoss mir der GRUB-Installer mein verschlüsseltes Storage indem der Bootsektor den Kryptoheader überschrieben hat obwohl ich eine andere Platte als Bootloader-Ziel angegeben habe. Der zweite GAU ereignete sich durch ein defektes Update, der die Netbook-Version unbenutzbar machte.

Beide Fehler liesen jedoch mit überschaubarem Aufwand beheben. Alle weiteren Fehler waren auf die eigene Dummheit zurückzuführen. Alles in allem hat sich der LTS-Release als sehr robust erwiesen. Jetzt wird es Zeit Abschied zu nehmen und auf die neue Version umzusteigen, hoffentlich werden die folgenden 2 Jahre genauso entspannt wie die bisherigen.

LVM – Rolling Mirror

Raptor 2101Leave a comment

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  #ggf  zu für die LVM Nutzung vorbereiten.
vgextend diskGroup  #Diskgruppe erweitern
lvconvert -m 1 diskGroup/logcalDevice  --corelog --type mirror -b
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 diskGroup --force

Bird: strange next-hop

Raptor 2101Leave a comment

Nach meinem Umzug auf OpenWRT kam ich in den Genuss, das bei einem Reconnect nicht jeder Dienst neu gestartet wird. Leider hatte dieses „normale“ verhalten dazu geführt, das BIRD nicht mehr alle Routen propagiert hat. Das Problem: Es tauchten unvermittelt meldungen in folgendem Format im Syslog auf:

KRT: Received route 192.168.100.128/25 with strange next-hop 192.168.100.130

Zu Meldungen dieser Art kommt es wenn eine Routing-Regel aus der Kernel-Routing Tabelle gelernt wird, die ein direkt angeschlossenes Netz über einen entfernten Gateway schleifen will. Typisch für P-T-P und P-T-MP Verbindung wie OpenVPN oder PPPD. Interessanterweise stört BIRD das nur bei neu erlernten Routen. Ist die Route beim Dienst-Start schon in der Routing-Tabelle gibt es keine Probleme. Die Meldung kann man Unterdrücken, was jedoch stört ist die Tatsache, dass die entsprechende Routing-Rule nicht an die anderen Protokolle übertragen wird. Die möglichen Lösungen:

  • Eine statische Route über das Interface definieren und via Filter verhindern, dass diese Route zurück in den Kernel geschrieben wird.
  • BIRD nach einem Reconnect neu starten.
  • Diverse Protokolle bieten es an Netzwerke zu propagieren, die sie eigentlich nicht kennen. Unter OSPF kann man z.B. ein stubnet Konfigurieren. Dies hat den Charme, dass man der Route gleich entsprechende Kosten auferlegen kann. Die Route wird nur an die OSPF-Neighbors weitergereicht nicht an irgendein ein anderes Protokoll in der BIRD Instanz.

Welche der Lösungen man wählt hängt wohl vom Einsatzgebiet ab, ich hab mich für letztere entscheiden.

IPSec/L2TP VPN mit OpenWRT

Raptor 21014 Comments

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. Quelle: http://www.mail-archive.com/users@lists.strongswan.org/msg02787.html]

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.

Linux Bandbreiten-Monitor/Traffic-Accounting

Raptor 2101Leave a comment

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 NFLog 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 NFLOG --nflog-nlgroup 1
iptables -I FORWARD -s 192.168.0.0/16 -j NFLOG --nflog-nlgroup 1

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

Squeezebox und Radius

Raptor 2101Leave a comment

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_action

Nach einem Neustart der Box sollte sich das Gerät ordnungsgemäß am Radius-Server anmelden.

Update:
Squeezeboxen unterstützen nur eine KeyLength von 2048bit

HDMI Output und Ruckler in HD

Raptor 2101Leave a comment

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.

NVidia – HD-Video – MicroRuckler

Raptor 21012 Comments

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'