Linux @ Home

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 Warten auf Fedora 10 hat sich mal wieder definitiv gelohnt! Ich komme trotz vorhandener ATI und Intel-Grafikkarten zwar noch nicht in den Genuss des besten grafischen Schmankerls: KMS (Kernel Mode Setting), aber der Rest scheint auf Anhieb zu klappen wie versprcchen. Es sieht aus wie aus einem Guss, der Bootprozess ist etwas schneller geworden und für mich als KDE-Fan wartet endlich ein einigermassen stabiles KDE 4.1 auf Arbeit. Pulseaudio ist stabiler geworden (wenn auch noch nicht bugfrei) und übernimmt nun alle Audio-Aufgaben, so hat Amarok z.B. gar keine Optionen mehr um die Ausgabe auf etwas anderes umzustellen und das ist gut so.

Hier ein kleiner Status meiner Installationen:

• iMac hat denselben Status (d.h. Mikro und Mausrädchen funktionieren noch nicht)
• Thinkpad: Bis auf die Thinkpad-Buttons (unter KDE4 noch nicht direkt unterstützt) alles o.k. Was mich absolut positiv überrascht und besonders freut: KDE4 scheint sogar mit eingeschalteten Desktop-Effekten genausowenig Strom zu verbrauchen wie KDE3! Im Leerlauf zwischen 11-13 Watt und mit Fensterbewegung (3D und transparent) maximal 16 Watt. Damit scheint KDE4 absolut Netbooktauglich zu sein.

Probleme

Natürlich gibt es auch bei diesem Release ein paar “Wie hat das bloss die Beta-Phase überstanden?” Erlebnisse:

• kpackagekit frisst unersättlich Memory, wenn keine Netzwerkverbindung besteht (Notebook)
• amarok 2.0 ist was die Oberfläche anbelangt noch im Betastadium und die Bedienung alles andere als intuitiv. Ausserdem werden Benutzer, die den “alten” Amarok geschätzt haben, verschreckt mit solchen krassen Oberflächen- und Backend-Änderungen
• Instabilitäten im Zusammenhang mit Xorg und KDE4 mit Dekstopeffekten. Beispiele: Abstürze (selten). Switching auf Konsole und zurück auf KDE (tty1) nicht möglich mit aktivierten Effekten (zumindest mit Intel-Grafikchip).
• xine läuft ca. 1 Sekunde bevor’s einen Speicherzugriffsfehler gibt

Nachtrag:

Nach längerer Testzeit sind mir doch noch ein paar mehr Dinge aufgefallen, vor allem solche, die eigentlich niemals so durch die Finger der Betatester rutschen sollten (ich vermute mal überhastete Updates vor dem Release?). Die Fehler betreffen die KDE-Version, über die Gnome-Version kann ich nichts sagen, da ich sie nicht benutze, aber wie ich Gnome kenne, läuft da alles stabil

• CD’s werden standardmäßig mit kscd wiedergegeben, nur leider ohne Ton! Lösung: Kaffeine benutzen In der Konfiguration das Ausgabegerät auf Phonon stellen (das sollte Standard sein, ist es aber leider nicht)
  
• Auch das Ripping-Programm (Sound Juicer) hat ‘ne Macke: Als wir eine CD der Freundin rippen wollten (frustriert durch obiges CD-Abspiel-Problem), sah ich, dass das Programm *.oga Dateien erstellte. “Na klar, Ogg Audio” dachte ich. Nur schade, dass Amarok dieses Format nicht erkennt beim Scannen der Sammlungs-Ordner! Lösung: Umbenennen nach *.ogg und Amarok erkennt die Stücke wie gehabt.

Fazit

Auf dem Notebook sollte man die Desktopeffekte nur anschalten, wenn man seine Freunde und Kollegen beeindrucken möchte. Danach sollte man vorerst darauf verzichten, weil man sonst im Gegenzug auf Funktionen wie Konsolen-Switch, Suspend-To-Ram und Suspend-To-Disk (resp. das Aufwachen macht Probleme) verzichten muss.
Sonst gibt es eigentlich nichts zu beachten, viel Spass beim Installieren und ausprobieren!

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"