Ganzes Verzeichniss zippen:
zip -r <ArchiveNama> <Folder1> <Folder2> ….
Schlagwort: Linux
Razer Huntsman unter Linux
Unter Linux gibt es den openrazer Treiber um Razer Geräte anzusteuern. Leider hat Razer bei neueren Geräten das „Protokoll“ gewechselt und betreibt jetzt wohl mehr „Software Based Lightning“. Lange Rede – kurzer Sinn: der openrazor Treiber aus den aktuellen quellen funktioniert noch nicht.
Wenn man nicht alles selber bauen will sollte man sich erst mal das Frontend installieren. Unter KDE bietet sich Polychromatic an. Dazu muss man auch den Treiber „schon mal“ installieren.
Anschließen hohlt man sich die Openrazer-Quellen von hier: https://github.com/sumpster/razer-drivers.git
Danach der üblich Weg:
make sudo make driver_install sudo make setup_dkms sudo make udev_install sudo make daemon_install
danach noch den openrazor_daemon aus /usr/lib/python3.x nach /usr/lib/python3/dist-packages kopieren, durchstarten und schon kann man die Huntsman unter Linux steuern.
Wichtig: nutzt !!nicht!! die abkürzung über ubuntu_install. Die ist fürs pakaging gedacht und zerschießt euch das System.
Interface geht sporadisch down …
Frei nach dem Motto „wenn man nichts zu sagen hat, …“ ist es hier in letzter Zeit sehr ruhig gewesen. Meine IT zu Hause läuft einfach zu rund, es gibt nichts zu Berichten. Nun ja bis heute…
Seit geraumer Zeit läuft auf meinem StorageServer ein TV Headend. Das lief bis vor kurzem Problemlos. Nur seit ein paar wochen plagen mich kurze Verzögerungen/Aussetzer. Anfangs konnte ich das auf einen schlechten SAT Empfang schieben aber immer gehäufter traten folgende Fehlermeldungen in den Logs auf:
igb: eth0 NIC Link is Down igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
Das eth-Interface geht Down und kommt sofort wieder hoch. Fast alle Protokolle und Dienste (NFS, SAMBA,…) scheinen damit gut klar zu kommen nur TV Headend goutiert das mit einem Connection-Reset und am Client sieht man „negative Auswirkungen“.
Davon abgesehen, warum geht das Interface unmotiviert down. Kurze Analyse später, das passiert häufiger: 2-5 mal am Tag. Meine postulierte Verfügbarkeit von 99.999% war dahin. Es folgten 2 Wochen Fehlersuche:
- Kabel tauschen
- Interface tauschen
- Verschiedene Switcheinstellung (Powersave) abgeschaltet…
- div. Optionen testen
- vieles mehr …
Dank des sporadischen Auftretens hieß es nach jeder Änderung Stunden warten …
Ein Switch Tausch brachte die nötigen Hinweis. Der eigentliche Switch konnte als Fehlerquelle ausgeschlossen werden, da der Fehler auf allen Ports auftrat aber immer nur, wenn an dem Port mein Server hing. Alle anderen Geräte wiesen diese Disconnects nicht auf. An dem „notfall“-Switch traten die Disconnects aber auch nicht auf, die OnBoard-Netzwerkkarten waren also auch nicht defekt.
Schnell nochmal alle Switch-Einstellungen kontrolliert und dann die kryptische Option IEEE802.3az gefunden. Google angeworfen und geflucht.
IEEE802.3az (oder Energy Efficient Ethernet/EEE) ist eine Powersaving-Option (die Sinnigerweise nicht unter Powersaving aufgeführt wurde …) bei der zwei Geräte untereinander aushandeln ob und wann sie ihre Transmitter am Interface abschalten. Das erklärte auch das Fehlerverhalten. Immer wenn ich einen Lasttest gefahren hab, trat das Problem nicht auf, da EEE nicht zugeschlagen hat. Erst wenn nur Sporadisch Bandbreite benötigt wurde, kam es zu Disconnects.
Der erste Versuch EEE vie ethtool abzuschalten brachte keine Besserung:
ethtool --set-eee eth0 eee off
Erst als am Switch EEE für den ServerPort abgeschaltet wurde verschwand das Problem.
EdgeMax Router und die eigene DHCP-Server Config
Wer einen EdgeMax Router im Einsatz hat, kann über die Configschnittstelle seinen DHCP Server aufsetzten. Wer aber einen bestehenden DHCP Server migrieren will, wird blöde, alles über dieses Interface einzuhacken. Es geht auch einfacher. Die bestehende dhcpd.conf unter /config ablegen. Man kass es prinzipjell überall hinlegen, aber dort überlebt die Datei ein Firmware-Upgrade.
Anschließend die Datei /etc/init.d/dhcpd anpassen und von der automatisch generierten auf die /config/dhcpd.conf umbiegen. Wenn man im Configmenu den DHCP-Server abgeschaltet hat (kein Eintrag unter services) muss man nun noch den DHCP-Server beim Start mit starten lassen:
update-rc.d dhcpd default
Schon hat man seinen selbst-konfigurierten DHCP Server am Start.
OpenWrt im Langzeittest
Ich hab seit einer geraumen Zeit OpenWRT im Einsatz und will hier mal meine Meinung zu dieser „Linux-Distribution“ kundtun.
Bei OpenWRT handelt es sich wie DD-WRT um eine aus dem WRT54G-Basissystem entstandene, auf Router ausgerichtete Firmware. Viele weitere Projekte wie z.b Freifunk bauen auf OpenWRT auf.
Was zeichnet OpenWRT nun gegenüber anderen Router-Firmwares aus, was macht es empfehlenswert? Kurz und knapp: es ist ein „echtes“ Linux. Soll heißen, man hat ein schreibbares Root-Dateisystem, vollen Zugriff auf /dev, /etc und alle Änderungen überleben einen Reboot. Man kann sämtliche Hilfs- und Automatisierungsfunktionen abschalten bzw. deinstallieren und ggf. auf einem „nackten“ System aufsetzen. Mittels des Paketmanagers opkg kann man bequem fast alles nachinstallieren was man so braucht, wenn mal etwas fehlt kann man es sich auch selber ein Paket bauen. Alles in allem ein Eldorado. Kniffelige Setups lassen sich relativ unkompliziert Umsetzen, Dinge die mit anderen Firmwares nicht funktionieren (VLAN Konfiguration pro Port) sind mit OpenWRT ohne größeren Aufwand umgesetzt. All das hat dafür gesorgt, dass OpenWRT momentan auf allen meinen Routern im Einsatz ist.
Es gibt aber auch Schattenseiten. Die große Funktionsvielfalt geht meist mit einem Konfigurationswust einher. Bei OpenWRT versucht man das über eine einheitliche Konfigurationsschnittstelle abzufangen (UCI). Dabei gibt es unter /etc/config eine reihe von Konfigfiles die immer „gleich“ gestaltet sind. Diese werden mittels Paketabhängiger Scriptes dann in die eigentlichen Konfigurationsfiles umgesetzt. Aus der WLAN-Config Datei /etc/config/wireless wird zb das /tmp/hostapd.conf erzeugt und anschließend der hostapd Dienst hochgefahren. Dieses Verfahren hat drei Schwächen. Wenn der Paketverwalter keine UCI Unterstützung vorsieht, ist man wieder mit der Hand am arm unterwegs. Manchmal wird sowohl UCI als auch die eine eigene Konfiguration benötigt, dann wird es schnell unübersichtlich. In seltenen Fällen empfinde ich das UCI Interface komplizierter als die ursprüngliche Konfigurationsmethoden. Die UCI-Firewall Konfig schmeiße ich immer als erstes runter und setzte mir alles selber mit iptables-befehlen auf.
Was noch Problematisch ist, ist der Upgrade/Deploy-Prozess. Es gibt verschiedene Varianten OpenWRT auf seinen Router zu bekommen. Einmal die „stable“ Images, dann den Entwickler-Images und zu guter letzt kann man sich aus dem Entwickler-Repo auch das latest-Image zusammenbauen. Die komfortabelste Variante ist ein stable-Image. Diese wird über die gesamte zeit mit Packages versorgt. Das Entwickler-Image (trunk) benötigt man, wenn die eigene Hardware noch nicht von dem stable-Image unterstützt wird. Hier hat man mit zwei Problemen zu rechnen. Zum einen fliegen Pakete aus dem Repo einfach raus. Das würde einen normalerweise erst bei der nächsten stable-Version (mit Vorwarnung) ereilen. Das zweite Problem ist, sobald die Entwicklerversion auf einen neuen Kernel setzt, werden die module entsprechend hochgezogen. Will man ein Paket aktualisieren steht nun ein komplettes Router flashen an. Nach dem flashen hat man quasi wieder einer jungfräulichen Router. Einzig ein paar vor definierte Ordner und Dateien (inkl /etc) werden erhalten. Pakete und Anpassungen muss man manuell nachziehen. Das macht die Fernwartung ein wenig kniffelig.
Das sind aber auch die einzigen Probleme, die ich mit dieser Distri hatte. Ansonsten sind in ca einem Jahr betrieb keine einziger störender Effekt aufgetreten. Die ganze Zeit liefen die Router stabil und ohne nennenswerten Konfiguration/Administrationsaufwand.
LVM – Rolling Mirror
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
IPSec/L2TP VPN mit OpenWRT
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
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
Samba/CIFS und Kerberos Authentifizierung
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 = true
Im 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.
Vollständige Migration zu Linux
Seit nun mehr zwei Jahren betreibe ich in meinem privaten Umfeld das Projekt „nie wieder Windows“. Angefangen hat es mit dem hochziehen eines lokalen Servers als NAS, griff über auf einen HTPC und endete nun schlussendlich mit der Migration meiner Desktop-Rechner. Da ich ein recht „vielfältiges“ Aufkommen von Rechnern und Anforderungen habe, will ich mal meine Erfahrung für die niederschreiben, die ebenfalls mit dem Gedanken spielen umzusteigen.
Zu aller erst der Grund meines Wechsels. Mit dem Wechsel von XP zu Vista hat MS mal wieder die Daumenschraube an zusetzten versucht, ala „Technology XYZ“ gibt es aber nur für Vista, den alten Scheiß braucht ihr nun nicht mehr. Der Versuch auf Vista zu migrieren war eine komplette Katastrophe. Anfangs gingen nicht mal meine Standard-Eingabegeräte korrekt. Unabhängig ob die Redmonder dafür etwas konnten oder nicht, ab diesem Moment war der Umstieg von WindowsVersion zu WindowsVersion genauso „kompliziert“ wie die Migration nach Linux. Zu diesem Zeitpunkt begannen die Test und Vorbereitungen wie ein Umstieg zu Linux denn „schmerzfrei“ von statten gehen könnte.
Zu meinen Rahmenbedienungen:
- Ich lebe zu zweit in meinem Haushalt und meine bessere Hälfte ist nicht gewillt meine „Hirngespinste“ mitzutragen. Ergo eine Umstellung muss OHNE Reibungsverluste von statten gehen.
- Ich bin ein Spieler im Sinne von „Computerspieler“. Es gibt Zeiten da will ich die Kiste einfach nur anmachen und anfangen zu zocken. Das alles ohne viel Stress und gefummel.
- Ich bin aber auch ein Bastler. Es muss nicht immer gleich die Ideallösung sein. Es kann auch mal kompliziert werden. Programmieren, frickeln, Betatesten all das macht mir Spaß. Auch das durchforsten von Doku, Foren und einlesen in Komplexe Sachthemen ist mir nicht Fremd.
- Ich bin Faul. Der Endausbau sollte mit minimalen Aufwand wartbar sein.
Es hat sich schnell gezeigt, mit Linux kann man gewissen Anforderungen nur Bedingt bedienen. Gleich vorweg, wer heute in den Laden geht und ein Handelsübliches PC-Spiel aus dem Regal greift, sollte eine funktionierende Windows-Installation sein eigenen nennen oder Leidensfähig sein. Andere Anforderungen lassen sich hingegen sehr gut, teilweise sogar besser als bei Windows abbilden.
Als Plattform hab ich Ubuntu gewählt. Es bot zum Zeitpunkt der Migration den besten Mix aus Aktualität (2 Releases pro Jahr), Support (Foren, Aktive Community), Zugänglichkeit (Doku) und Wartbarkeit. Begonnen hab ich mit 9.04 und setzt aktuell auf 10.04 LTS. Alle geschilderten Erfahrungen basieren auf dieser Basis.
Homeserver
Im Bereich des Serverbetriebs spielt Linux seine volle Stärke aus. Hier merkt man einfach, aus welcher Ecke Linux kommt. Das beginnt damit, dass man einen Server komplett Remote ohne GUI installieren kann, geht weiter über die Art der Konfiguration und endet damit, dass standardmäßig nicht jeder Dödel ohne weiteres den Rechner runter fahren kann. Genug der Seitenhiebe. Konkret manifestiert sich der Vorteil von Linux gegenüber Windows im Serverbetrieb in folgenden Fakten:
- keine Lizenzkosten. Schonmal jemand ein Win2003/Win2008/SmallBuisinessServer gekauft…
- keine Abstriche in Funktionalität: Hier ist Linux Windows eher überlegen. Alles was man für den Heimgebrauch so braucht, gibt es für Linux eher als für Windows und meistens auch noch frei verfügbar. Beispiele: Mailserver, Postfächer, LDAP-Server, Storage-Server, Webserver, Applikation-Server, Monitoring(!!!). Eine Ausnahme Bilden die DB-Server. Sowohl ein Oracle als auch ein MySQL laufen nativ unter Linux. Bei anderen DB-Systemen (MS SQL) sieht es da schlechter aus.
- Hardware-Support: Alle nennenswerte ServerHardware kann von Linux angesprochen werden. Ob nun eine RAID-Controller oder eine abgefahrene ISP-Schnittstelle.
- Integration: Jeh nach Distribution kann die Verfügbarkeit von Paketen zwar abweichen, aber es gibt fast immer einen Weg fremde Pakete einzubinden. Diese werden dann Automatisch mit aktualisiert. Was heißt das konkret? Installiert man unter Windows etwas, was nicht von MS kommt (zb ein MySQL Server, WordPress als WebApp) dann sollte man beten, dass diese Software einen eigenen Update-Mechanismus hat oder man darf sich selbst darum kümmern, dass diese Software auf dem aktuellen Stand bleibt. Auf meinem Homeserver hab ich nur eine „Fremdquelle“ einbinden müssen und das war die damit mein ClamScan schneller aktualisiert wird (vom ubuntu-dev-team)! Ich hab nicht ein Paket installieren müssen, dass nicht vom Distributor gekommen ist. Und selbst wenn (auf Clients z.B.) kümmert sich das System automatisch darum, dass diese Software aktuell bleibt. Solange man nicht an der Paketverwaltung vorbei installiert, kann man über eine automatisches Update die Kiste aktuell halten (und sogar den eventuell nötigen Reboot kann man automatisieren). Der Wartungsaufwand ist minimal.
- Die Logs werden an einer Stelle abgelegt. Dafür kann MS zwar nix. Aber (fast) alle Dienste unter Linux nutzen einen weg Log-Files abzulegen. Gerade im Fehlerfall ist extrem angenehm nur an einer Stelle suchen zu müssen. Dem Windowsadmin ist Luxus leider nicht vergönnt.
Kurzum ich betreibe seit zwei Jahren einen Server mit Linux und bin jedes mal froh mich für Linux entschieden zu haben, wenn ich gezwungen werden einen Windowsserver zu verwalten (beruflich).
HTPC/MediaPC
Hier wird eine klare Empfehlung schon schwieriger. Auf der einen Seite ist hier das klare Problem der Hardware zu nennen. Nicht mehr jede Hardware funktioniert unter Linux. Ob nun TV, Sound, Grafikkarte oder Fernbedienungs- (IR/RF‘)-Empfänger, man muss immer vor dem Kauf der Hardware überprüfen ob diese auch unterstützt wird. Dazu kommt (in Deutschland) ein rechtliches Problem. Hier ist es per Gesetz verboten ein „wirksamen“ Kopierschutz zu umgehen. Was das im konkreten Streitfall bedeutet überlasse ich den Juristen. Praktisch bedeutet es, dass man sowohl beim anschauen von DVDs (CSS), BlueRay (AACS,VEIL,BD+) oder abspielen von Streams (FlashProtection) immer ein rechtliches Problem an der Backe haben kann. Technisch sieht die Abspielproblematik wie folgt aus:
- DVD: kann ohne Einschränkung abgespielt werden.
- BlueRay: Direkt abgespielt werden können nur BDs ohne DRM. Kommt DRM zum Einsatz muss man diesen aktiv brechen (rippen/entschlüsseln/umpacken). Ein direktes abspielen ist noch nicht möglich.
- Streams: hier kommt es darauf an was für Streams verwendet werden. Fast alle Streams können „irgendwie“ abgespielt werden. Einzig Streams basiert auf Microsofts Silverligt Technologie (MaxDome) sind gar nicht abspielbar.
- TV: Sowohl Analog, DVB, SD, HD und sogar PayTV sind abspielbar.
Neben diesem Unwägbarkeiten gibt es jedoch auch ein paar Vorteile:
- Maximale Anpassbarkeit: Booten in unter 10 Sec (PowerOff), Betrieb ohne Fenstermanager direkt in das MediaCenter.
- Breite Auswahl an „MediaCentern“, PVR-Backends und anderen sinnvollen Dingen.
- Einfache Wartung (unterlagerte updates, ein Aufpoppen ala „Rechner jetzt Neustarten“ währen eines Films ist einfach scheiße)
- Große Community
Das Abspielen von von FullHD Material ist problemlos möglich. Entweder hat man einen performanten CPU unter der Haube oder hat eine GPU mit Beschleuniger-Funktion. Auch hier sollte man sich vorab Informieren ob der die verwendete GPU unterstützt wird.
Fazit: mit entsprechender Vorbereitung läuft man in kein offenes Messer. Es stehen einem allle Möglichkeiten offen. Ich selbst betreibe nun seit einigen Monaten einen HTPC auf Linux Basis und hab bis jetzt noch keine Abstriche machen müssen. Allerdings waren meine Ziele auch der Vorklärung angepasst.
Arbeitsstation/Desktop/Laptop
Der Punkt mit dem größten Risiko. Zum einen trifft man hier auf einefahrene Anwenungsmuster der Anwender zum anderen auf einen unkontrolierbaren Fundus an Hardware. Beim versuch zu Migrireren bin ich in zwei Schritten vorgangen. Erstmal einen Testrechner migriert (meine Arbeitsstation) und getestet „wie sich das anfühlt“. Danach hat sich folgendes Fazit eingestellt:
- Handelsübliche Anwendungen wie Surfen, E-Mail, normale Office Anwenungen sowie der Großteil der Unterhaltungs-Anwendungen funktionieren Problemlos.
- Spezialanwendungen: Hat man unter Windows eine bestimmte Anwendung gefunden, die man nicht mehr missen/ersetzten möchte, wird man Probleme bekommen. Einige Anwengunen lassen sich mit Wine zum Laufen zu bekommen. bei weiten aber nicht alle. Man muss sich entweder davon Verabschieden oder weiterhin Windows paralel betreiben.
- Gaming: Das momentane Killerargument. Ein Teil der Spiele läuft unter Wine. Das ist aber jeh nach Spiel mit mehr oder minder viel „basteln“ verbunden. Im schlimmsten Fall pflegt man für jedes Spiel sein eigenes Setup. Wie auch bei den Filmen muss man ebenfalls fast immer DRM-Systeme umgehen um überhaupt was zum laufen zu bekommen.
Als Folge dessen habe ich auf allen Rechner auf den auch gespielt wird parallel ein Windows laufen. Da immer weniger gespielt wird, wird der Bedarf sinken. Die paar Spiele die noch anfallen, laufen unter Wine und lassen sich dort Verwalten. Das ist aber ein Prozess auf Zeit und geschieht ohen Druck. Für alles andere kommt ein Ubuntu-Linux zum Einsatz. Bei meiner „besseren Häfte“ geschah die Umstellung im Zuge eines „Windows muss mal wieder neu Installiert werden “ – Zykluses. Seit diesem „Ereigniss“ gab es zwar kleineren Klärungsbedarf (Sicherheitskonzept usw) aber das ging alles Problemlos über die Bühne. Die Ständigen Bluescreens bei Windows (durch einen defekten Treiber) tun ihr übriges zur Akzeptans.
Zum Einsatz auf Geräten ohne „Spielehintergrund“ geht das alles entspannter zu, Dort gibt es nur die Frage, wird die Hardware von Linux unterstützt: wenn Ja gut, wenn Nein schlecht. Das muss man sich vorher, wie beim HTPC, informieren.
Fazit: Wenn man es mit bedacht angeht und seine Grenzen kennt (und vor allem die der Mitteilnehmer) kann man Linux sinnvoll in seine Heimumgebung integrieren. Auf der „Pro“ Seite hat man dann die einfache Wartbarkeit und die (momentane) Ruhe vor allerlei Viren und sonstigem Gesocks. Auch die (meiner Meinung nach) einfachere Bedinung ist hervorzuheben. Jedoch nimmt sich sonst Windows und Linux auf dem Desktop wenig.