laserman’s blog

NX als VNC-Ersatz

Im Linuxmagazin lese ich gerade, dass NX seit Version 3.x auch das kann was ich bisher so vermisste und bisher mit vnc, x11vnc, krfb… gelöst habe: desktop sharing / session shadowing. Das brauche ich für mindestens 2 Anwendungsfälle: User Helpdesk und “pädagogisches Netzwerk”. Die installation der .deb Pakete http://www.nomachine.com/ unter Kubuntu 7.04 und 7.10 verlief problemlos. Will man nun auf den laufenden X11(KDE,Gnome,..) Desktop eines Users zugreifen, wählt man im NX-Client bei Desktop statt Unix Shadow. Weitere fancy features wie z.B. die Umleitung von Sound oder Cups-Druckern habe ich noch nicht getestet.

kernel module kompilieren - the Debian way

bequem und schmerzlos, geht bei Ubuntu genauso.

apt-get install  linux-kernel-headers module-assistant

module-assistant build hostap

module-assistant install hostap

modprobe hostap

Vergleich der Geschwindigkeit von LTSP 4.2 und MueKow

Ich habe die Geschwindigkeit von einigen Aktionen bei LTSP 4.2 und
LTSP Muekow bei 4 verscheidenen Clients verglichen.
Hier die Ergebnisse:

http://media.lug-marl.de/doc/LTSP-MueKow/zeitmessung-ltsp42vsMuekow.ods
http://media.lug-marl.de/doc/LTSP-MueKow/zeitmessung-ltsp42vsMuekow.html

Analyse & Interpretation

Der grösste Unterschied, ist die Zeit, die zum booten benötigt wird. Wenn die  Geräte am Anfang jeder Unterrichtseinheit gebootet werden ist das ein echtes Problem. Auch ein Reboot nach einem möglichen Crash wird bei Muekow zur Geduldsprobe. Manche Lehrer lassen ihre Terminals tag & nacht non stop durchlaufen - Ich finde das nicht gut. Man sollte zumindest über eine Zeitschaltuhr dafür sorgen , dass sie z.B. zwischen 15 und 8 Uhr und am Wochenende und in den Ferien nicht unnötig Energie verbrauchen.

Fast keinen Untersiched gibt es beim Start von OpenOffice oder auch Firefox. Offenbar werden hierfür nur relativ wenige X11 roundtrips und generell  wenig X11 Traffic benötigt. Dasselbe gilt für den x11perf benchmark, den ich ausgewält hatte - Er zeigt ganz deutlich die Performance der Grafikkarte bzw des verwendeten X11-Treiber-Moduls (vesa ist langsam).  Ganz ander sieht das bei tuxmath und ähnlichen animierten Lernspielen oder Videos, Flash-Content aus. Hier ist LTSP 4 mit unverschlüsseltem X11 deutlich im Vorteil.
Ca. 1 Minute vom Logout bis zum LDM Anmeldefenster finde ich auch etwas heftig. Ich vermute dass hier, genau wie beim booten, die CPU des Clients mit diversen bash und python scripten belastet wird. Bei LTSP 4 hat der Client hier kaum arbeit, der X-Server muss nur das kdm/gdm darstellen, welches auf dem Server läuft. Nun könnte man vielleicht denken, dass der Server beim Muekow entlastet wird, weil ja soviel auf der CPU des Clients läuft. Das Gegenteil ist der Fall, was aber erst deutlich wird wenn 10-20 Terminals gleichzeitig verwendet werden. Dann sieht man in der top Liste des Server viele  ssh Prozesse ganz oben. Server & Client werden duch  ver- & entschlüsseln  nicht unerheblich belastet. Vielleicht ist ipsec eine Alternative, weil dann das ver- & entschlüsseln im Kernel erledigt wird -> weniger context switches. Vielleicht bringt  freeNX (http://freenx.berlios.de/ , http://www.2x.com/) eine Besserung -  hier wird zwar auch mit ssh verschlüsselt, aber es werden viele Roundtrips & Traffic vermieden.

So, nun weiss ich etwas genauer wo & wieviel Muekow langsamer als LTSP 4 ist. Ich halte die Verschlüsselung des X11 Protokolls in einem Schulnetz für Overkill. Schüler finden meisst viel einfachere Wege um an Passwote zu kommen. ARP-Spoofing Attaken fallen auf: das Terminal friert ein. An einem eingefrorenen Terminal lässt sich dann auch nix sniffen. Wenn man dem Lehrer eine Worstation gibt, dann muss er auch kein potentiell unsicheres Terminal benutzen. Ich würde diese MueKow-Generation gerne überspringen und Geräte , die genug Leistung für schnelles Muekow haben, lieber als Diskless Workstations betreiben.

D-Link DWL-122 (11 MBit) wireless USB Adapter

apt-get install linux-wlan-ng
modprobe prism2_usb prism2_doreset=1

wlanctl-ng wlan0 lnxreq_ifstate ifstate=enable
wlanctl-ng wlan0 lnxreq_ifstate ifstate=enable
wlanctl-ng wlan0 lnxreq_autojoin ssid='' authtype=opensystem
dhclient wlan0

kismet.conf:

source=wlanng,wlan0,dwl122

OpenChrome

Seit ein paar Monaten, seit ich das Teil habe, benutze ich für mein Amilo Pro V2030 Notebook den “vesa” Treiber von X11. Das klappt ganz gut - mit wenigen Ausnahmen:

• OpenGL-Anwendungen wie z.B, Tuxracer (aka PlanetPenguinRacer aka ppracer) und Google Earth laufen recht träge
• Videos lassen sich nicht auf Vollbild skalieren.

Deshalb - und aus reiner Neugier/Spieltrieb habe ich mir den “via” Treiber von
http://www.openchrome.org/ installiert. Nach dem Neustart von X11/KDE war dann mein Mauscursor unsichbar. Das bekommt man aber mit einer passenden Option “SWCursor” “true” Zeile in xorg.conf schnell wieder hin:

Section "Device"
Identifier      "Standardgrafikkarte"
#       Driver          "vesa"
Driver          "via"
BusID           "PCI:1:0:0"
Option  "SWCursor" "true"
EndSection

Nun bin ich von den 3D-Fähigkeiten der VIA P4M800 Chipsatzgrafik sehr positiv überrascht. Das habe ich bei einem 530 € Notebook garnicht erwartet. Tuxracer und Google Earth laufen schön flüssig und auch die Videos kann ich jetzt in Fullscreen genießen. Es gibt aber ein paar Feinheiten zu beachten:

In

~/.ppracer/options

set fullscreen false

eintragen, damit ppracer im Fenster und nicht Vollbild läuft.

Bei google-earth einmal F11 drücken um von Vollbild auf Fenster oder umgekehrt zu wechseln.

In mplayer laufen manche Videos mit -vo gl andere aber nur mit -vo x11.

gl kann man auf Vollbild skalieren, x11 nicht. Bei openchrome.org gibt es patches für mplayer und xine - das hab’ ich noch nicht probiert.

Vielen Dank an die OpenChrome Entwickler und an martin (at) gamesplace (dot) info für die Ubuntu Binary Pakete.