laserman's blog

Für meine Kunden habe ich schon mehrere Laserdrucker von Samsung besorgt. Die Geräte sind leicht, klein, schnell. Die Druckqualität ist gut. Anschaffungs- und Betriebskosten sind auch o.k.
Ausserdem finde ich es sehr lobenswert, dass in der Werbung und auf der Packung ausdrücklich auf vorhandene Linux-Treiber hingewiesen wird.

Bei einer aktuellen Linux Distribution ist der nötige Treiber “splix” bereits enthalten. Bei SuSE Linux 8.2 aus dem Jahre 2003 war das erwartungsgemäss nicht der Fall – Software zu alt / Drucker zu neu.

Dem Drucker lag eine Treiber-CD bei. Die Installation der darauf gelieferten Software verlief problemlos: Als root setup.sh ausgeführt, danach in yast die passende ppd-Datei aus dem Ordner “samsung” – (nicht “Samsung”) auswählen. Auf dem Desktop findet man ein Samsung/Cups-Config-tool. Damit (oder mit irgend einem anderen CUPS-Frontend) kann man das Seitenformat von Letter auf A4 ändern.

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

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.

Ich komme gerade vom edubuntu Testwochenende im Unperfekthaus Essen und hab’ mir von dort eine Edubunut 6.10 CD mit nach hause genommen und installiert. Die Installation verlief schnell (30min. ohen Download deutscher Sprachpakete) und problemlos. Es ist keine Live CD, sie hat den “klassischen/alternate” Installer. Enthalten sind u.a. die Pakete  ltsp-server  und ltsp-server-standalone , beides in der Version 0.124. Nach dem ersten Boot des Servers habe ich 2 Terminals per PXE booten lassen.

Der Loginmanager LDM

positives:

• ssh Verschlüsselung des X-Traffic
• zeigt unten rechts die IP-Adresse des Terminals
• hat unten links einen Knopf um das Terminal auszuschalten, was aber nicht bei allen Geräten funktioniert(ACPI)
• bietet ein Session Auswahlmenu, welches auch funktioniert – Ich habe icewm nachinstalliert und konnte es benutzen

negatives

• man sieht kene Liste der User wie es in kdm möglich ist, aber das ist wohl von den Autoren so gewollt.
• man bekommt keine Meldung wenn Username oder  Passwort falsch sind.

Soundausgabe am Terminal

Die Soundausgabe am Terminal funktioniert bei Gnome-Programmen wie z.B. Gnome-Audio-Recorder,Rhythmbox und Totem Media Player gut. Auch der Lautstärke-Regler in der jeweiligen Anwendung funktioniert. Der Lautstärke-Regler in der Startleiste zeigte keinen Effekt.  Bei Programmen wie gcompris  oder  Tuxmathcommand kamen die Sounds  aus den Lautsprechern  des Servers.  esddsp half da auch nix. Vermutlich wird esd garnicht verwendet sondern gstreamer.

X-Window

Sowohl am Server als auch bei den Terminals wurde der VESA Treiber verwendet.  Vorteil: Er funktioniert bei fast jeder Grafikkarte.  Nachteil:  sehr langsam/träge – was man besonders beim verscheiben von Fenstern oder bein scrollen im Browser merkt. Manuell lässt sich diese Manko aber beheben: am Server in /etc/X11/xorg.conf und für die Terminals in /opt/ltsp/etc/lts.conf

ltspfs

Der Zugriff auf lokale Laufwerke des Terminals wie z.B. USB-Memory-Sticks, CD-ROM, Disketten funktioniert. Lesend und auch schreibend. Manchmal geht das etws langsam, weil immer wieder das Diskettenlaufwerk gesucht wird. Bei ltsp.org findet man dafür aber eine Lösung. Eine Audio-CD im Terminal funktioniert nicht, weil es auf einer Audio-CD kein Dateisystem und auch keine Dateien gibt.

interessante Pfade

/usr/share/ltsp

/opt/ltsp/i386/usr/sbin/ldm

Heute sollte ich einen Server reparieren, der nach einem Stromausfall nicht mehr bootet. Gestern kam die Kiste nur bis zum Grub-Promt, kein Grub-Menü. Heute morgen bootete sch schon viel weiter: Grub-Menü, Kernel, initrd und dann kam “run fsck manually” für /boot auf /dev/sda1. Weil wir das root-passwort gerade nicht zur Hand hatten, haben wir diesen fsck von Knoppix aus gemacht. Es fand viele Fehler und ich musste oft Return drücken um der Reperatur zuzustimmen. /boot und auch die anderen 2 Partitionen befanden sich in einem Hardware RAID5: 3 SATA Platten an einem 3ware Controller. Die Root Partion und Swap waren LVs in einer LVM Volume Group und unbeschädigt. Nach dem manuellen fsck von /boot bootet die Kiste wieder ohne Fehler. Schön. Oder nicht ? Es bleiben halt ein paar Fragen offen: Wie hat sich Grub über nacht “selbst repariert” ? und: Warum ist /boot überhaupt kaputt gegangen obwohl dort doch nur einmal kurz beim booten lesend zugegriffen wird? Zu Frage 1 vermute ich, dass der RAID-Controller Fehler entdeckt & behoben hat, was möglicherweise ein paar Minuten dauert. Vielleicht wurde er bei seiner Arbeit auch durch Menschen gestört, die mehrfach den Server aus- & einschalteten. Vielleicht war /boot schon vor dem Stromausfall kaputt – man merkt es aber erst beim nächsten boot. Abschliessen kann man wohl sagen: RAID hilft nicht gegen Stromausfall. Wer sich so einen schönen Server leistet, sollte nicht bei der USV(UPS) sparen!

Als virtuelle PCs hatte ich bisher VMware-Player(kostenlos) und qemu(frei) benutzt. Neulich las ich bei prolinux über virtualbox. Runtergeladen, ausprobiert – bin begeistert! Es ist der VMware Workstation sehr ähnlich, läuft angenehm schnell und (subjektiv) blockiert es mein restliches System nicht so stark wie es der VMware-Player tut.

In einem Athlon-500 PC hatte ich zunächst eine IBM 16GB Festplatte und später stattdessen eine 20GB Fujitzu mit einem 28cm kurzen IDE Kabel angeschlossen. Das Kabel hatte ich aus einem alten Siemens-Desktop. Die IBM-Platte funktionierte ganz normal mit diesem Kabel. Bei der Fujitzu gab es reproduzierbar folgenden Effekt: Partitionierung, Formatierung und Installation von z.B. Ubuntu klappt problemlos, nur wenn dann das neu installierte System booten soll, zeigt es zahlreiche IDE-IO Fehler und bleibt mit busybox/limited shell stehen. Dann hab’ ich mal das Kabel gegen ein modernes UDMA-Rundkabel getauscht: Das System bootet ohne Fehler!