On Sun, Jun 08, 2003 at 04:46:37PM +0200, wolfgang ingrisch wrote:
Sehr geehrter Herr Varkoly,
ich habe Ihre 2 CD's erhalten - vielen Dank. Ich habe versucht, mich mit slss-admin.pdf etwas zu orientieren. Der Abschnitt 7 - Autoinstallation und Netzwerkbooten macht mir noch etwas Schwierigkeiten. Das Ziel am Friedrich-Alexander-Gymnasium wäre nach meinem Verständnis, dass Diskless Clients eine (magere) Linuxinstallation vom Server laden, die es ihnen erlaubt, einen X-Server zu starten und die Anmeldeprozedur am zentralen Server auszuführen.
Ich verstehe nicht ganz, was in der Sprache der "slss-admin.pdf" ein Terminalserver ist: a) Der X-Server, der auf den Clients im Netz läuft und der vom SLSS dazu jeweils beim Booten geladen wird oder b) der SLSS in der Funktion, in der Funktion, dass alle Schüler vermittelt durch ihre Terminals auf ihm angemeldet sind und ihre Prozesse dort laufen haben. b) ist richtig.
Mich irrirtiert dabei etwas die Beschreibung der "terminalserver.xml", in der eine Partionierung angegeben wird. Widerspricht dies im Fall b) nicht der Tatsache, dass die Partinionerung schon exisitert, wenn der SLSS installiert ist. Mit a) passt das natürlich auch nicht zusammen.
Der Terminalserver ist ein eigener Rechner. Die Datei "terminalserver.xml" ist die Beschriebungsdatei womit man einen Solchen Terminalserver installieren kann. Es ist natürlich möglich, den Schulserver selbst als Terminalserver zu konfigurieren, es ist jedoch nicht empfehlenswert. "Man wird nich grlücklich, wenn die SchülerInnen sich auf dem Server herumtoben können". Außerdem ist der Schulserver als Server installiert, d.h. die meisten Programme die man als Workstationbenutzer verwenden würde (us. Openoffice) sind gar nicht installiert.
Eine zweite Frage hätte ich noch bzl. des Bootvorgangs. Der Verwendung von diskless Terminals liegt natürlich auch die Vorstellung zugrunde, dass man dafür ältere Rechner verwenden möchte - deren BIOS dann vermutlich ein Booten über das Netz mittels PXE noch nicht ermöglicht. Gibt es dann außer dem Booten über Startdisketten (etherboot o.ä.) einen empfehlenswerten Weg?
Ja. Ich kann Ihnen PXE-Stardisketten für (fast) alle Netzwerkkarten herstellen. Eigentlich ist es keine richtigige PXE-Bootdiskette, das ist nicht so einfach, sondern eine Grub-Bootdisktte womit man über Netzwerk booten kann.
Mit freundlichen Grüßen
Vielen Dank, das Sie mein Doku lesen!!!!!! Ich bemühe mich ein Schritt-FürSchritt anleitung zu Thema Terminalserver & Diskless Clients zu schreiben.
Wolfgang Ingrisch
-- ----------------------------------- Péter Varkoly -o) SuSE Linux AG /\\ e-mail: Peter.Varkoly@suse.de _\_/ -----------------------------------
On 9 Jun 2003 at 23:58, Peter Varkoly wrote:
Der Abschnitt 7 - Autoinstallation und Netzwerkbooten macht mir noch etwas Schwierigkeiten.
Der Terminalserver ist ein eigener Rechner. Die Datei "terminalserver.xml" ist die Beschriebungsdatei womit man einen Solchen Terminalserver installieren kann.
Es ist natürlich möglich, den Schulserver selbst als Terminalserver zu konfigurieren, es ist jedoch nicht empfehlenswert. "Man wird nich grlücklich, wenn die SchülerInnen sich auf dem Server herumtoben können". Außerdem ist der Schulserver als Server installiert, d.h. die meisten Programme die man als Workstationbenutzer verwenden würde (us. Openoffice) sind gar nicht installiert.
Wir würden infolge einer Neuinstallation in den Sommerferien auch gern slss auf unserem zentralen Server einsetzen. Mit der Frage, Funktionen auf mehrere Rechner zu verteilen, haben wir uns bisher nicht befasst. Wir haben auch nur einen recht leistungsfähigen und zuverlässigen Rechner (Dual Xeon mit SCSI RAID - 5). Eine Verteilung auf mehrere Server würde Anschaffung zusätzlicher Hardware erfordern. Bisher haben wir alle Serverfunktionen unter SuSE 7.3 auf diesem Rechner laufen, dazu gehören: - Gateway zum Internet (TDSL t@school) mit squid und squidguard, ssh-Zugriff von außen - LTSP Terminal-Server für 36 Terminals (KDE, Netscape, JBuilder, StarOffice 6.0, ...) - File- und Anmeldeserver (NFS/NIS) für 750 Benutzer - samba-Server für 36 Windows-98 Clients. - Druckspooler unter cups Die Clients werden wahlweise als Windows98, Linux- Rechenr oder als X-Terminals verwendet. Unter der Argumentation von P. Varkoly überlegen wir nun, auf wieviele Rechner die Serverfunktionen optimal zu verteilen wären und welche Anforderungen an die jeweiligen Rechner zu stellen wären. Erste Überlegung: 1.) Ein kleiner Rechner als Internetgateway mit squid und squidguard. mit SuSE 8.2 2.) Ein kleiner Rechner mit slss als Anmeldeserver 3.) Der bisherige Server als Terminalsserver und Fileserver mit SuSE 8.2 Sind andere Konfigurationen denkbar? cu Kai Wollweber -- IGS Eckernförde http://www.wollw.de
Hallo Kai, Am Donnerstag, 19. Juni 2003 18:35 schrieb Kai Wollweber:
jeweiligen Rechner zu stellen wären. Erste Überlegung:
1.) Ein kleiner Rechner als Internetgateway mit squid und squidguard. mit SuSE 8.2
Eigentlich müsste das mit dem SLSS zu realisieren sein, da ja der Proxy beim SLSS eine extra IP (bei mir z.B. die 192.168.0.5) bekommt und daher dieser auf einen extra Rechner ausgelagert werden kann - allerdings hat bislang noch niemand dokumentiert, wie das zu machen ist und ich weiß noch nicht, wie ich da heran gehen soll :-( Diese Lösung würde ich nämlich für unser Schulnetz bevorzugen.
2.) Ein kleiner Rechner mit slss als Anmeldeserver
Was bedeutet für dich _kleiner_ Server? Ich habe mal so etwas ähnliches mit Arktur probiert (schneller LTSP-Terminalserver, "kleiner" Rechner für Arktur PIII 600Mhz, 256 MB). Da aber dann die Homeverzeichnisse alle auf Arktur lagen, war Arktur überfordert und er bremste das ganze System (für die Linux-(diskless-)Clients) viel zu stark aus, dass das keinen Spaß machte - Arktur war dann für die LinuxCleints sehr schnell _kein_ Anmelde- bzw. Fileserver mehr. Jetzt habe/werde ich zum Glück sehr sehr gute Hardware bekommen, dass ich damit keine Probleme mehr haben werde (hoffentlich ;-) )
3.) Der bisherige Server als Terminalsserver und Fileserver mit SuSE 8.2
Gerade der Terminalserver muss ein schneller Rechner sein und noch wichtiger er muss vielvielvie... Speicher (für 10 Clients am Besten >1GB) besitzen, sonst macht das Ganze auch keinen Spaß.
Sind andere Konfigurationen denkbar?
Man könnte mehr als einen LTSP-Terminalserver ins Netz einbauen und dann alle Clients im Netz als disklessClients betreiben ;-) Viele Grüße Dieter
Hallo Dieter,
1.) Ein kleiner Rechner als Internetgateway mit squid und squidguard. mit SuSE 8.2
Eigentlich müsste das mit dem SLSS zu realisieren sein, da ja der Proxy beim SLSS eine extra IP (bei mir z.B. die 192.168.0.5) bekommt und daher dieser auf einen extra Rechner ausgelagert werden kann - allerdings hat bislang noch niemand dokumentiert, wie das zu machen ist und ich weiß noch nicht, wie ich da heran gehen soll :-( Diese Lösung würde ich nämlich für unser Schulnetz bevorzugen.
Die Auslagerung dieser Funktionen ist einfach zu realisieren und auch unter Sicherheitsaspekten sinnvoll. Es macht im übrigen Schwierigkeiten, squid als Zwangsproxy einzurichten für Browser, die auf dem Server selbst laufen. (Jemand der einen Terminalserver benutzt, der zugleich Internetgateway ist, kann an squid vorbei direkt auf das Internet zugreifen.) zu IP-Einstellungen in der slss-Installation: Ich habe noch nicht begriffen, warum man bei der slss-Installation mehrere IPs für die verschiedenen Funktionen angeben muss. Bedeutet es, dass einem NIC (des slss) mehrere IPs zugeordnet sind oder bedeutet es, dass unter den IPs jeweils ein weiterer Server mit der entsprechenden Funktion erwartet wird. Zumindest für den Terminalserver habe ich die Doku und Peter Varkolys mail so verstanden, dass für den Terminalserver grundsätzlich ein separater Rechner vorgesehen ist.
2.) Ein kleiner Rechner mit slss als Anmeldeserver
Was bedeutet für dich _kleiner_ Server? Ich habe mal so etwas ähnliches mit Arktur probiert (schneller LTSP-Terminalserver, "kleiner" Rechner für Arktur PIII 600Mhz, 256 MB).
In etwa diese Größenordnung. Vor allem klein, damit er mit 1HE in das Server- Rack passt. Da aber dann die Homeverzeichnisse alle auf Arktur
lagen, war Arktur überfordert und er bremste das ganze System (für die Linux-(diskless-)Clients) viel zu stark aus, dass das keinen Spaß machte - Arktur war dann für die LinuxCleints sehr schnell _kein_ Anmelde- bzw. Fileserver mehr.
Unter Anmeldeserver würde ich einen slss verstehen, der _nicht_ Fileserver ist. Fileserver ist bei uns der Terminalserver, das bedeutet, dass die Prozesse des Terminalservers direkt auf das RAID-System desselben Rechners zugreifen und das Netzwerk davon nicht betroffen ist. Das bischen Zugriff von slss auf die home- Verzeichnisse kann IMHO über NFS realisiert werden. Samba könnte man zusätzlich auch auf den Terminalserver installieren, wobei PDC-Funktionen auf slss verbleiben. Die Trennung von slss und Terminalserver ist wohl noch nicht ganz durchdacht, was spricht für die Trennung, was dagegen? Falls zwei Geräte, welche Dienste auf welchem Rechner?
Jetzt habe/werde ich zum Glück sehr sehr gute Hardware bekommen, dass ich damit keine Probleme mehr haben werde (hoffentlich ;-) )
Hardware kann man nie genug haben ;-(( ... die Probleme tauchen irgendwann auf anderem Niveau wieder auf.
3.) Der bisherige Server als Terminalsserver und Fileserver mit SuSE 8.2
Gerade der Terminalserver muss ein schneller Rechner sein und noch wichtiger er muss vielvielvie... Speicher (für 10 Clients am Besten >1GB) besitzen, sonst macht das Ganze auch keinen Spaß.
Das ist bei uns gewährleistet. Dual-Xeon mit 1 GB RAM (wird auf 4 GB aufgerüstet.) und RAID-5 15k-SCSI-Platten.
Man könnte mehr als einen LTSP-Terminalserver ins Netz einbauen und dann alle Clients im Netz als disklessClients betreiben ;-)
Wir wollen an dem einen Terminalserver alle 40 Clients als "diskless Terminals" betreiben. Allerdings brauchen wir auf einigen Clients für diverse Lernprogramme noch eine Windows-Partition als local boot (deshalb auch samba auf der Server-Seite) cu Kai Wollweber -- IGS Eckernförde http://www.wollw.de
Dieter Kroemer wrote:
2.) Ein kleiner Rechner mit slss als Anmeldeserver
Was bedeutet für dich _kleiner_ Server? Ich habe mal so etwas ähnliches mit Arktur probiert (schneller LTSP-Terminalserver, "kleiner" Rechner für Arktur PIII 600Mhz, 256 MB). Da aber dann die Homeverzeichnisse alle auf Arktur lagen, war Arktur überfordert und er bremste das ganze System
wir haben ähnliche probiert und ähnliche Erfahrungen gemacht. Wir haben "konsolidiert" indem wir den Arktur rausgeschmissen haben, und der kmLinuxTSE Terminalserver Arktur's Aufgaben übernommen hat. Arktur's NFS Implementation ist warscheinlich langsamer als aktuelle NFS-Server. Aber auch das Gemisch von viel X11 Traffic(Terminals) plus viel NFS Traffic im selben Netz war wohl nicht so gut. Bei skolelinux http://www.skolelinux.de/architektur.html wurde dieser Traffic getrennt, dennoch spürt man momentan noch NFS und/oder LDAP als leiche Verzögerung ... wir arbeiten dran ;-)
Man könnte mehr als einen LTSP-Terminalserver ins Netz einbauen und dann
ja, genau so ist die skolelinux-architektur. Gruß, Martin Herweg
participants (4)
-
Dieter Kroemer -
Kai Wollweber -
Martin Herweg -
Peter Varkoly