Fwd: Re: diskless vs. thin / LTSP Performance
Hi all,
Wolfgang tries to understand "undocumented" phaenomens
on skolelinux servers. Maybe this is valuable hints for missing
chapters - or anybody can comment on this?
Cheers
Ralf
---------- Weitergeleitete Nachricht ----------
Subject: Re: diskless vs. thin / LTSP Performance
Date: Sonntag, 23. September 2012
From: Wolfgang Höfer <hoeferwolf@t-online.de>
To: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>, user@skolelinux.de
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: