[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: diskless vs. thin / LTSP Performance



Hi Mike, hallo Liste

Ich habe hier einige "seltsame" Erscheinungen, was wohl damit zusammenhängt, dass mir
das Ineinandergreifen der verschiedenen Komponenten des gesamten Setups noch nicht klar sind. Es laufen eben Dinge (undokumentiert) im Inneren ab, denen man erst auf die Spur kommen muss.

Ich hab mal eine Skizze von meinem Netz in den Anhang gepackt.

Folgende Gedanken "plagen" mich.

Wer ist der Cups-Server?
Der Tjener kann es eigentlich nicht machen, weil er (bei mir) keine Maschinen in den 192er Netzen erreicht.
Damit kann er die Drucker nicht sehen und auch nicht verwalten.
Meine zwei Computerräume sind durch eine 24er Netmask voneinander getrennt => jeder LTSP muss ein
eigenständiger CUPS-Server sein?


DHCP
Auf jedem LTSP läuft ein DHCP-Server (ist nicht optimal, weiß ich). Die Requests der Clients erreichen beide Server (sieht man im Syslog vom Tjener). Der "falsche" LTSP reagiert auch brav mit "wrong net". Der andere LTSP liefert dann die Adresse aus. Die Info, welche Maschine (MAC) welche IP bekommen soll, die sollte wohl über das andere Interface vom Tjener ermittelt werden (oder aus dem eigenen Cache). Nun musste ich aus verschiedenen Gründen die IP der Drucker (im LDAP) ändern. Es war danach nicht möglich, die Drucker mit dieser IP zu versorgen. Ich habe die Dienste, die Server, die Drucker, ... neu gestartet - immer die alte IP. /var/lib/dhcpd.leases geleert - nie bekam der Drucker DIE IP, die im LDAP stand (ja, ldap2bind hab ich auch aufgerufen)


NBD
Am Ende des Tages hängen auf einem der LTSPs zahlreiche Prozesse, die dem User nobody gehören und den Dienst NBD betreffen. Ich habe am Samstag noch einige Fehler (von mir) im LDAP gefunden (IP-Zuweisungen zum falschen Raum). Nun muss ich diese Woche nochmal beobachten, was sich auf den beiden LTSP's abspielt.

CFENGINE
Kann man auf diese Weise Softwareverteilung oder zumindest Nachinstallieren von Programmen veranlassen? Das wäre unbedingt in die Doku aufzunehmen.

DHCP + BIND
In Gosa kann man bei der DHCP Einstellung zwischen

(tjener) dhcp
(tjener) intern
(tjener) 10.0.0.0
(tjener) subnet.intern00
(tjener) 192.168.0.0
(tjener) subnet.intern01
(tjener) 192.168.1.0

Wählen. Wo liegt bei den ersten 3en der Unterschied, die anderen sind auch paarweise identisch.
Wenn man den entsprechenden Bereich im DNS aktiviert (Checkbox rechts), dann ist der Client
dennoch nicht über seinen Namen pingbar. (z.b. ping drucker2 geht nicht) - hier muss man dann den ganzen
DNS-Namen angeben

ping  drucker2.subnet00.intern

Ich bin nicht sicher, dass die gesamte Kommunikation im Netz diesen Namen verwendet.


LTSP
SSH hab ich bereits deaktiviert, hat was gebracht. War schon immer eine Engstelle.

SET RUNLEVEL
Ok, das Skript ist einfach genug - aber das wertet doch die IP-Adresse aus und übergibt
je nach 10er oder 192er den Wert 3 oder 4 an den init(?) Prozess.
Wofür braucht man dann den Runlevel-Parameter in der Appendline, wenn dann doch über
die IP entschieden wird.
Und dann ist mir immer noch nicht klar, was sich am Bootprozess ändert.
Der prinzipielle Unterschied zwischen diskless und Thin ist mir schon klar - aber was ändert das technisch.
Darüber findet man auch in der LTSP-Doku nichts - zumindest ich :)

BIND
Werden die verschiedenen A_Names im Bind dynamisch über die Netgroup-zugehörigkeit erstellt?
Zumindest hat beim Tjener cservd und cups gefehlt.


KDE
Auch auf meinen Workstations eine Katastrophe. Nach dem Login folgt auf die Initialisierung der
Oberfläche eine (mindestens) 30sekündige Totzeit. In der Zeit kann man klicken was man will, es passiert nichts.
Irgendwann wird dann der Start-Button aktiv. So lange waret aber kein Schüler ....


Viele Fragen, ich weiß. Aber leider keine Antworten dort wo ich sie hätte lesen können.
Zum Systemgraben fehlt mir leider etwas die Zeit ....

VG
 Wolfgang



On 23.09.2012 21:11, Mike Gabriel wrote:
Hi Wolfgang,

On Mi 19 Sep 2012 07:13:00 CEST Wolfgang Höfer wrote:

Liebe Liste,

Eine generelle Verständnisfrage:

Der Unterschied Thin-Client / Diskless-Client ist ja, wo die Anwendungen laufen ( so weit ich das
weiß). Im PXE-Boot Menü sind die Append-Zeilen für beide Szenarien aber identisch.
Woher weiß ein Client dann, ob er Thin oder diskless ist?

Das entscheidet das System anhand der IP Adresse bzw. anhand des Runlevels.

runlevel 3 - IP: 10.* -> diskless workstation
runlevel 4 - IP: 192.* -> thin client

Den runlevel kann man beim Booten mitübergeben, einfach die Zahl 3 oder 4 in den Kernel Bootoptions mit übergeben.

Das Handling übernimmt das Skript ltsp_set_runlevel im debian-edu-config Paket:

 $ dpkg -L | grep ltsp_set_runlevel

Mein Problem ist, dass ich relativ schwacht Thinclients habe und die Performance darmaßen schlecht ist.
Ich hatte das Problem mit meiner vorherigen Ubuntu-LTSP Installation ohne Skolelinux nicht!

Vielleicht laufen die Systeme als Diskless Workstations???

Ich habe jetzt schon KDE durch xfce ersetzt, weil mit KDE GAR NICHTS GING - selbst auf den Workstations!

Hmmm... falls deine System doch als ThinClients laufen, dann musst du ggf. SSH Tunneling in LTSP abschalten (suboptimal, aber zur Fehlersuche ganz ok):

Set LDM_DIRECTX=True in lts.conf.
http://sourceforge.net/apps/mediawiki/ltsp/index.php?title=Ltsp_LtsConf

Auf der Konsole des Servers ist die Prozessorauslastung auch sehr gering, wenn Betrieb ist!

Hmmm... das spricht dafür, dass die Maschinen als Diskless Workstations laufen.

Mike





Reply to: