Linux @ Home

http://chaosradio.ccc.de/cre135.html lohnt sich wirklich. Mehrere wunderbare Aussagen und Beobachtungen (z.B. von Juli Zeh bei 00:44). Wer CRE noch nicht kennt und nur im entferntesten interessiert an der Welt sind, haben was nachzuholen.

Wie schon immer erregen die laut schreienden Idioten das meiste Aufsehen. Das gilt insbesondere für Nationalisten. Als Anfangs August beispielsweise (vermeintlich) russische Hacker aus nationalistischen Kreisen Facebook, Twitter und Co. lahmlegten durch eine sog. D-DoS (Distributed Denial-of-Service) Attacke, war dies auch den internationalen Medien durchaus eine Meldung wert.

Bei diesen „Nationalisten“ handelt es sich in der Regel um frustrierte und gelangweilte Jugendliche in der Türkei oder Russland, welche mangels Perspektive braunes Gedankengut aufschnappen, damit sie im Namen von ihrem Land oder Wasauchimmer ihre heruntergeladenen “Do-your-own-virus-Kit” benutzen können. Mit echten Hackerfähigkeiten hat das nicht im entferntesten zu tun.  Dazu reicht auch die Intelligenz eines durchschnittlichen PC-Benutzers aus, der weiss, wie man die entsprechenden Programme mit Google suchen muss. Wenn jemand eine Autoscheibe mit einem Wagenheber einschlägt, micht ihn das schliesslich auch nicht zu einem Automechaniker.

Diese peinliche Holzhammer-Methode (mache tausende Abfragen pro Sekunde mit vielen PC’s) wird in der Regel mit Viren- oder Wurmverseuchten Windows-PC’s durchgeführt, deren ahnungslose Besitzer sich bald genervt fragen, warum ihre Internetleitung immer langsamer wird. Windows bietet sich also nach wie vor an für minderbemittelte Skript-Kiddies. Durch die enorme Verbreitung von Viren wie “Conficker” und Konsorten steht den Angriffswerzeugen jederzeit eine ganze Armada von willigen Angriffsrechnern zur Verfügung, die nur darauf warten, dass ihre offenen Ports missbraucht werden. Dass russische Softwarehersteller solche Tools auch unverhohlen verkaufen mit Slogans wie „Legen Sie Ihre Konkurrenten lahm“ ist so gesehen kein Zufall, wenn man sich die Karten über die Verbreitung von den Windows-Schädlingen anschaut. Für die Antiviren-Software-Hersteller wie z.B. Kaspersky (auch aus Russland, hmm…) sieht die Zukunft nach wie vor rosig aus.

Quellen:

1. The Guardian: http://www.guardian.co.uk/world/2009/aug/07/georgian-blogger-accuses-russia
2. Heise.de: http://www.heise.de/security/Spekulationen-ueber-DDoS-Attacke-auf-Twitter–/news/meldung/143190
3. Kaspersky (Antivirus-Software-Hersteller): http://www.kaspersky.com/de/

Nachdem sich der Anfangsstress bei meinem neuen Job als Vollblut-Linux-Admin etwas zu legen beginnt, ist wieder mal Zeit für ein paar Experimente: Schon viel zu lange habe ich dieses Thema aufgeschoben, weil ich mir sagte “Sowas brauch’ ich nicht”. Jetzt wo es einmal läuft habe ich mich schnell daran gewöhnt und will gar nicht mehr anders: Dual-Monitor-Betrieb ohne Xinerama-Ärger.
Wie das geht? Erstmal wie üblich: KEINE ATI-Karte kaufen, sondern den Konkurrenten bevorzugen (vielleicht darf ich diese Aussage endlich mal relativieren in einigen Jahren). Der Rest ergibt sich fast von selbst, denn mit nvidia-settings kann man die benötigten Einstellungen machen. Der Nachteil ist, dass man bei jeder X-Session von neuem die Einstellungen machen muss, da sie nicht im .nvidia-settings gespeichert werden. Man könnte auch die X11-Konfiguration speichern, dies funktioniert bei den modernen Distributionen allerdings nicht (das xorg.conf wird immer spartanischer oder existiert gar nicht mehr). Deshalb lässt man sich die X11-Einträge von nvidia-settings anzeigen und ergänzt sie dann selbst im /etc/X11/xorg.conf:

Section "Device"
        Identifier  "Videocard0"
        Driver      "nvidia"
        Option      "NoLogo" "true"
        Option      "TwinView" "on"
        Option      "TwinViewOrientation" "RightOf"
        Option      "MetaModes" "DFP-0: nvidia-auto-select, DFP-1: nvidia-auto-select"
        Option      "Coolbits" "1"
        Option      "RandRRotation" "yes"
        Option      "AddARGBGLXVisuals" "True"
EndSection
Section "Extensions"
        Option      "Composite" "Enable"
EndSection

Auch hier gilt natürlich: Besser selber mit nvidia-settings erstellen anstatt nur kopieren.

KDE4 macht glücklicherweise fast keine Zicken mit dem Dual-Monitor-Betrieb, auch unter erschwerten Bedinungen wie bei mir (zwei verschiedene Auflösungs-Modi). Es muss lediglich eine sogenannte “Aktivität” unter Plasma hinzugefügt werden, welche sich automatisch der Auflösung des zweiten (rechten) Monitors anpasst. Anders als in anderen Betriebssystemen kann nun auch eine zweite Kontrollleiste erstellt werden, welche dem zweiten Monitor dann dieselbe Funktionalität zur Verfügung stellt wie dem “Hauptmonitor”.

Wie konnte ich sowas praktisches nur so lange ignorieren? Naja, im nächsten Artikel stelle ich Euch “multitail” vor, welches ich ebenfalls leider viele Jahre ignoriert habe.

Das neue Opensource-Jahrbuch 2008 wurde veröffentlicht. Man kann es hier heruntergeladen werden mit oder ohne kleine Spende an die Autoren (so 2 Euro wären ja eigentlich angebracht). Ideal für ein paar einsame Stunden am sonnigen Strand (oder Balkon)! Vor allem wird die Freundin nicht neugierig drin blättern (ja ich weiss, das war jetzt ein klassisches Vorurteil)

Im Rahmen meiner RHCE-Ausbildung hatte ich das erste Mal die Gelegenheit, Xen-Installationen für den “professionellen” Einsatz einzurichten. Die überraschend gute Performance auch bei mehreren Instanzen auf einem einzelnen Rechner hat mich sehr beeindruckt. Diese Performance erreicht man indes nur, wenn die virtuellen Maschinen “paravirtualisiert” sind, also dann wenn nicht nur das Wirts- sondern auch das Gastsystem einen Xen-angepassten Kernel verwendet, der gegenseitig kompatibel ist.
Mein Spieltrieb für zu Hause war geweckt. Nach und nach migrierte ich also alle Services themenorientiert auf vier verschiedene sog. DomU’s (unprivilegierte Domains = virtuelle Maschine = Gastsystem, alles austauschbare Begriffe) unter einem CentOS 5.1 Wirts-Server. Dazu benötigt man unter den Redhat Derivaten folgende Komponenten: Xen-Kernel, libvirtd und xend. Dank yum reicht eigentlich ein “yum install kernel-xen” und man hat im Handumdrehen alle notwendigen Werkzeuge für die Virtualisierung zur Hand.

Nach anfänglichen Abhängigkeitsproblemen zwischen den VM’s (oder besser Anfängerfehler, denn das der DNS-Server als erster gestartet werden sollte, müßte mir klar gewesen sein…) kann ich bestätigen, dass die Virtualisierung auch für den kleinen Server im Keller zu Hause durchaus Sinn machen kann. Ich kann nichts über komplexere Applikationen wie Oracle u.ä. sagen aber die Antwortzeiten von LDAP, DHCP, DNS, FTP etc. sind praktisch identisch zu ihren Pendants direkt auf physischen Servern. Auch netzwerktechnisch gesehen ist die Antwortzeit (Ping-Messung) identisch zu einem klassischen Server.

Den Overhead durch die Verwaltung von 4 gleichzeitig laufenden virtuellen Maschinen kann ich indes nur schätzen resp. beobachten. Im Leerlauf sind es zur Zeit nicht mehr als 5-15% des Wirtsystems, die verbraucht werden. Durch die Erweiterung von 2 auf 4 oder gar 6 GB Arbeitsspeicher erhoffe ich mir einen weiteren Leistungsgewinn, da die Resourcen im Moment doch etwas knapp zu sein scheinen, vor allem der Wirt selber hätte etwas mehr Arbeitsspeicher verdient. Die durch den Einsatz des Xen-Kernels fehlende CPU-Geschwindigkeitsregelung (das cpu-ondemand Kernelmodul gibt’s noch nicht für den Xen-Kernel) wird mehr als aufgehoben durch die Tatsache, dass bei mir der 2. Server nicht mehr ständig laufen muss (naja, zumindest sobald ich mir für das Backup resp. NFS/SMB auch eine Lösung geschnitzt habe).
Eine Live-Migration der Server bei einem Ausfall habe ich noch nicht getestet, sobald beide Server RAM-technisch aufgerüstet sind, werde ich dies aber vermutlich in Angriff nehmen. Eine gewisse Flexibilität ist sowieso gegeben, wenn man z.B. wöchentlich die virtuellen Disk-Imagedateien sichert und diese auf einen zweiten Server transferiert. Dann muss im Falle eines Ausfalls des ersten Servers dort nur noch die virtuelle Maschine gestartet werden und schon ist der Service (z.B. FTP) wieder einsatzbereit, ganz ohne weitere Eingriffe in DNS oder DHCP. Dies alleine bedeutet schon einen enormen Fortschritt an Unabhängigkeit im Vergleich zu Server-gebundenen Diensten oder klassischen Failover-Lösungen, da der Server an sich nur noch aus einer Disk-Imagedatei und der Xen-Konfigurationsdatei besteht.

Fazit

Abgsehen vom Aufwand, die VM’s einzurichten, empfinde ich den Serverbetrieb nun als ziemlich aufgeräumt und elegant. Habe ich irgendwo ein Problem, kann ich es auf die betreffende VM eingrenzen. Und auch der Aufwand für die Einrichtung der VM’s lässt sich in engen Grenzen halten, wenn man die Installation mit Kickstart-Konfigurationen, DHCP-vergebenen Adressen sowie mit Netzwerk-Images weitgehend automatisiert.

Hier noch ein Beispiel des virt-install Aufrufes für eine solche automatische Installation. Wenn man das grafische Werkzeug virt-manager zur Einrichtung einer DomU nimmt, geschieht im Hintergrund so ziemlich dasselbe wie hier von Hand:

virt-install --paravirt --name=another_vm --location=http://installserver/centos5_1
--keymap=de_CH --extra-args=ks=http://192.168.1.4/inst/vm_stuff/ks/another_vm.cfg
--ram=512 --vcpus=1 --vnc --file=/vm/xen/images/another_vm.img --file-size=8
--accelerate --mac="00:18:ef:dd:aa:cc"