Diskless Linux-Clients

[andy_m4]

Hallo,

ich möchte gerne mehrere Rechner als Diskless-Clients (Linux) einrichten. Man soll einen zentralen Server haben wo der User sowohl seine Dateien speichern kann als auch dieser die zentrale User-Verwaltung übernimmt. Außerdem sollen die festplattenlosen Clients davon über Netz booten können. Also quasi das, was man früher klassischerweise mit BOOTP, NIS und NFS gemacht hat.

Nun weiß ich aber nicht genau, welchen Ansatz ich da fahren soll. Denn sowohl BOOTP ist ja nicht mehr wirklich aktuell (da nimmt man ja eher sowas wie PXE) als auch NIS ist ja evtl. nicht mehr das, was man für die Nutzerverwaltung nimmt. NFS hat inzwischen einen Versionssprung zu Version 4 gemacht und da ist ja auch ein bisschen was anders.
Von daher wäre mal interessant zu wissen wie man so ein Szenario heutzutage aufzieht. Hin kommt noch, das die Clients nicht unbedingt identisch sind. Ist halt die Frage ob man neben einer allgemeinen Linux-Root-Tree noch Client-spezifische Konfig.-Dateien etc. auf dem Server hinterlegen kann.

Evtl. kommen in das Netz auch noch einige Windows-Clients. Auch dort wäre es natürlich schön sich mit den bereits hinterlegten User-Accounts anmelden zu können und dann natürlich auch auf die Dateien zugreifen zu können, die auch von Linux aus erreichbar sind. Vermutlich wird das darauf hinaus laufen das man den Teil dann irgendwie mit Samba / SMB abwickelt und hoffentlich auch mit der Linux-Nutzerverwaltung das irgendwie "verheiratet" kriegt.

Vielen Dank vorab für eure Anregungen

 

[Daloop]

Wir setzen openthinclient und MS Terminalserver in einer Windows-Domäne ein. Klappt an und für sich ganz gut, aber die CPUs der verwendeten Thin Clients (kann jeder beliebige PC mit PXE) sollten bei Verwendung von MS RDP etwas mehr Leistung haben. Bisher war es bis 49 Clients kostenlos, ab Oktober nur noch bis 24 Clients.

Alternativ mal nach Linux Terminal Server Project googeln.

 

[GTrash81]

Für das OS selber wird PXE genommen.
Abfolge in etwa so:

• Client holt sich IP vom DHCP-Server und bekommt direkt die IP vom TFTP-Server genannt
• auf dem TFTP-Server liegt ein Boot-Medium und das gewünschte OS
• das OS startet dann und bekommt auf irgendeine weise die nötigen Befehle für NIS, NFS, Samba, wasauchimmer

Achtung dabei: durch die Arbeitsweise von TFTP ist der Download sensitiv auf Latenzen.
Heißt das Boot-Medium kann durchaus paar Minuten brauchen, falls ein Client hinter 5 VPNs,
7 Routern und 10 Firewalls steht. Liegt unter anderem daran, dass UDP verwendet wird.
Sobald dann das Boot-Medium geladen wurde, geht der Rest deutlich schneller, weil dann
das kleine OS einen kompletten Netzwerkstack mit TCP aufbauen kann.

Nicht ganz so ausführlich, aber geht in die richtige Richtung: https://linuxconfig.org/network-booting-with-linux-pxe

 

[andy_m4]

Wir setzen openthinclient und

Ja. Ist auch interessant. Aber hier in dem Fall soll es kein Thin-Client sein.

Für das OS selber wird PXE genommen.

Ja. Die grundsätzliche Arbeitsweise von PXE ist mir klar.
Wobei ich eine Ergänzungsfrage noch hätte. Als DHCP-Server hatte ich dnsmasq ins Auge gefasst (statt dem ISC-DHCP-Server). Meines Erachtens nach kann man damit auch ein PXE/Netboot-Setup machen. nehmen. Hat das PXE/Net boot schon mal jemand mit dnsmasq gemacht oder sind da irgendwelche Komplikationen zu erwarten?

 

[Daloop]

Ja. Ist auch interessant. Aber hier in dem Fall soll es kein Thin-Client sein.

Muss es doch auch nicht. Du kannst jeden x-beliebigen Rechner verwenden, der PXE-Boot unterstützt.

Welchen DHCP-Server Du verwendest ist egal, solange von diesem die DHCP-Optionen 66 (TFTP-Server) und 67 (Name der Bootdatei) mitgegeben werden. Bei dnsmasq sollte das mit dem Schalter -O bzw. --dhcp-option gehen:

-O, --dhcp-option=[tag:<tag>,[tag:<tag>,]][encap:<opt>,][vi-encap:<enterprise>,][vendor:[<vendor-class>],][<opt>|option:<opt-name>|option6:<opt>|option6:<opt-name>],[<value>[,<value>]]Specify different or extra options to DHCP clients. By default, dnsmasq sends some standard options to DHCP clients, the netmask and broadcast address are set to the same as the host running dnsmasq, and the DNS server and default route are set to the address of the machine running dnsmasq. (Equivalent rules apply for IPv6.) If the domain name option has been set, that is sent. This configuration allows these defaults to be overridden, or other options specified. The option, to be sent may be given as a decimal number or as "option:<option-name>" The option numbers are specified in RFC2132 and subsequent RFCs. The set of option-names known by dnsmasq can be discovered by running "dnsmasq --help dhcp". For example, to set the default route option to 192.168.4.4, do --dhcp-option=3,192.168.4.4 or --dhcp-option = option:router, 192.168.4.4 and to set the time-server address to 192.168.0.4, do --dhcp-option = 42,192.168.0.4 or --dhcp-option = option:ntp-server, 192.168.0.4 The special address 0.0.0.0 is taken to mean "the address of the machine running dnsmasq".

Bei openthinclient macht das aber der OTC-Manager selber - er lauscht per DHCP-Proxy im Netzwerk auf DHCP-Anfragen, grätscht dazwischen und gibt seine eigenen Daten als DHCP-Optionen 66/67 an die Clients weiter, die den DHCP nach IP-Adressen fragen. Der DHCP-Server selbst sollte nicht ebenfalls die Optionen 66 und 67 an die Clients senden.

Am besten Du probierst es mal mit 2-3 Rechnern aus, ist ja für die ersten paar Clients kostenlos.

 

[andy_m4]

Muss es doch auch nicht.

Die Frage wäre halt, was für ein Sinn diese Lösung macht wenn man kein Remote-Desktop nutzen möchte.

 

[Daloop]

ich möchte gerne mehrere Rechner als Diskless-Clients (Linux) einrichten.

Genau das machen openthinclient und Linux Terminal Server Project. Die Clients booten per Netzwerk auf einen Linux Desktop, der nur im RAM des Clients läuft - keine HDD/SSD notwendig.

Die Frage wäre halt, was für ein Sinn diese Lösung macht wenn man kein Remote-Desktop nutzen möchte.

Was den Clients an Anwendungen mitgegeben wird, ist jedem selbst überlassen. Die Nutzung von RDP in Verbindung mit einem TS ist da nur eine der Möglichkeiten. VMware Horizon oder Citrix stehen ebenfalls zur Verfügung. Man könnte aber auch direkt auf dem Linux-Desktop arbeiten.

Vorteil OTC:
Man kann verschiedene Clients je nach verwendeter Hardware konfigurieren sowie Benutzer und deren benötigte (Netz-)Laufwerke über einen zentralen Server (Webinterface) verwalten.

 

[andy_m4]

Genau das machen openthinclient und Linux Terminal Server Project. Die Clients booten per Netzwerk auf einen Linux Desktop, der nur im RAM des Clients läuft - keine HDD/SSD notwendig.

Die Frage war halt, was diese Projekte konkret tun können. Denn einfach ein Linux booten das kriegt man ja auch so mit wenig Aufwand hin nach allem, was ich bisher so gelesen hab.

Man kann verschiedene Clients je nach verwendeter Hardware konfigurieren sowie Benutzer und deren benötigte (Netz-)Laufwerke über einen zentralen Server (Webinterface) verwalten.

So wie ich es verstanden hab, kann man via PXE/TFTP/DHCP den Clients ein Bootimage/Kernel übergeben. DHCP kann auch dafür sorgen, das ein Client-Rechner (via Mac-Adresse) auch immer die gleiche IP-Adresse bekommt. Via NFS kann ich dann auch basierend auf der IP-Adresse auch ein individuelles Root-Verzeichnis exportieren (wobei das auf dem Server ja dann nicht mal vollständig eigene Root-Verzeichnisse sein müssten, sondern man sich mit sowas wie unionfs so hinbiegen kann, das man einen gemeinsamen Root-Tree hat und nur wo PC-spezifische Dateien hat die dann halt individualisiert).

Bleibt halt die Frage nach der Nutzerverwaltung und wie man das implementiert. Auch openthinclient und Co werden da sicherlich auf etwas Vorhandenes zurückgreifen.

Generell würde ich gerne verstehen welche Basistechnologien benutzt werden und dann anhand dessen entscheiden, ob man zu sowas wie openthinclient greift was einem dann die ein oder andere Sache erleichtert/abnimmt.
Wobei ich die grundsätzliche Tendenz hab eher nicht zu einer AllInOne-Lösung zu greifen. Die sind gut, wenn die genau das liefern was man braucht. Häufig ist es aber so das man Sachen mitschleppt die man nicht braucht und wenn man Dinge zusätzlich rein bringt (in meinem Fall z.B: Authentifizierung von) das dann auch schnell Gebastel wird und Upgrades dann gerne mal zu einer Herausforderung werden.

 

[Daloop]

So wie ich es verstanden hab, kann man via PXE/TFTP/DHCP den Clients ein Bootimage/Kernel übergeben. DHCP kann auch dafür sorgen, das ein Client-Rechner (via Mac-Adresse) auch immer die gleiche IP-Adresse bekommt.

Korrekt.

Via NFS kann ich dann auch basierend auf der IP-Adresse auch ein individuelles Root-Verzeichnis exportieren (wobei das auf dem Server ja dann nicht mal vollständig eigene Root-Verzeichnisse sein müssten, sondern man sich mit sowas wie unionfs so hinbiegen kann, das man einen gemeinsamen Root-Tree hat und nur wo PC-spezifische Dateien hat die dann halt individualisiert).

Keine Ahnung welche Root-Verzeichnisse Du meinst. Die einzelnen Konfigurationen der Clients werden bei OTC in einer Datenbank gespeichert. Anwendungen werden dynamisch per SquashFS mitgegeben.

Bleibt halt die Frage nach der Nutzerverwaltung und wie man das implementiert. Auch openthinclient und Co werden da sicherlich auf etwas Vorhandenes zurückgreifen.

Über das integrierte LDAP oder Anbindung an ein Active Directory. Persistente Home-Verzeichnisse der User wie in der Wiki beschrieben. Dort findest Du auch Infos zum Funktionsprinzip sowie der verwendeten Dienste/Technologien.

 

[Findus]

Bei nem onlineshop gabs dazu mal nen Artikel wo auch dafür genutzter code veröffentlicht wurde
https://www.digitec.ch/de/page/unsere-mini-computer-leisten-grosse-arbeit-22049

 

[andy_m4]

Keine Ahnung welche Root-Verzeichnisse Du meinst.

https://en.wikipedia.org/wiki/Root_directory

Die einzelnen Konfigurationen der Clients werden bei OTC in einer Datenbank gespeichert.

Nur die Konfigurationen oder auch etwaige Konfigurationsdateien?

Anwendungen werden dynamisch per SquashFS mitgegeben.

Klingt erstmal etwas umständlich. Wenn ich eh alles was ich brauche per NFS exportiere dann klingt das zunächst wenig sinnvoll. Es gibt sicher Szenarien wo das sinnvoll sein kann.

Wenn ich richtig verstanden hab, kann man da gar nicht eine beliebige Distribution als Basis nehmen, sondern die geben ein angepasstes Debian (openthinclient OS) vor?

Über das integrierte LDAP oder Anbindung an ein Active Directory.
[....]

Ich werde mir mal das Wiki etwas zu Gemüte führen.

Bei nem onlineshop gabs dazu mal nen Artikel wo auch dafür genutzter code veröffentlicht wurde
https://www.digitec.ch/de/page/unsere-mini-computer-leisten-grosse-arbeit-22049

Wie bereits gesagt geht es explizit nicht um Thin-Clients.

 

[Daloop]

Mir ist schon klar was das Linux-Root-Verzeichnis ist, aber nicht, welches Du meintest - das vom OTC-Server oder das der Clients. Ich vermute jetzt mal letzteres. Das Filesystem des Debian-Images, welches auf den Clients läuft und dort ca. 250-300 MB Ram belegt, entspricht einem Standard-Debian. Ansonsten ist es natürlich ziemlich abgespeckt, damit die Clients relativ schnell booten. Vielleicht kann man da noch dran rumbasteln - war aber bei uns nie notwendig.

Zusätzliche Konfigurationsdateien/Scripts usw. werden ebenfalls im Manager hinterlegt und können differenziert einzelnen Clients beim Boot mitgegeben werden. Nach erfolgreichem Boot auf den Desktop können auch weitere Konsolenbefehle automatisch ausgeführt werden. Bei einigen unserer Clients legen wir so das Gateway nach dem Booten auf eine andere IP.

Ergänzung (2. Oktober 2022)

Klingt erstmal etwas umständlich. Wenn ich eh alles was ich brauche per NFS exportiere dann klingt das zunächst wenig sinnvoll. Es gibt sicher Szenarien wo das sinnvoll sein kann.

Ist aber total easy. Eine Anwendung (z. B. Free-RDP) wird samt Konfiguration nur einmal im OTC-Manager erstellt und kann dann auf beliebige Clients ausgerollt werden. Da wird nichts per NFS exportiert.

 

[andy_m4]

Ich vermute jetzt mal letzteres.

Ja. Ich dachte das sei dadurch klar, das ich von exportieren sprach. :-)

Zusätzliche Konfigurationsdateien/Scripts usw. werden ebenfalls im Manager hinterlegt und können differenziert einzelnen Clients beim Boot mitgegeben werden.

Das empfinde ich eher als Nachteil. Wenn die da in irgendeiner Datenbank liegen macht es doch das Editieren total umständlich. Wenn das einfach als Dateien vorliegt kann ich mit jedem beliebigen Texteditor ran. Ich kann auch Kommandozeilentools nutzen um semi-automatisiert zu editieren usw. usw. usw.
Auch auf der Ebene einzelner Clients zu hantieren finde ich eher unpraktisch. Ja. Manchmal braucht man das aber in meinem Fall hab ich zum Beispiel auch identische Rechner und die können dann natürlich auch ne identische Konfiguration kriegen. Klar möchte ich auch die Möglichkeit haben Konfigurationen per Client vorzunehmen, aber halt eben auch gern per Rechner-Klasse (es gibt zwar den Hardwaretyp aber die Konfiguration die man da vor nehmen kann sind doch arg begrenzt).

Und das kann man alles eigentlich ganz gut mit NFS und Overlay-Dateisystemen abbilden. Mit Bordmitteln und ohne irgendwelche Tools die irgendwas Eigenes machen.

Ansonsten ist es natürlich ziemlich abgespeckt, damit die Clients relativ schnell booten.

Naja. Die Bootgeschwindigkeit hängt in erster Linie davon ab, wieviel Dateien ich brauche. Ich kann per NFS ein richtig fetten Root-Tree exportieren. Wenn der Client nur auf einen Bruchteil davon zugreift ist er natürlich auch schnell.

Nach erfolgreichem Boot auf den Desktop können auch weitere Konsolenbefehle automatisch ausgeführt werden.

Auch das ist jetzt nix Besonderes.

Das ist aber insgesamt noch ein Problem. Nämlich das openthinclient ein nettes Tool ist aber mir irgendwie noch nicht so ganz klar ist, welchen Benefit es bringt gegenüber das ich mir einfach so die Sachen so konfiguriere wie ich sie brauche. Zumal ich mir damit ja auch eine Abhängigkeit einfange. Ich kann ja nicht einfach sagen, ich lasse das weg. Wie bei einem Konfigurationstool was mir z.B. Einstellungen in Konfigurationsdateien schreibt aber wenn ich das Tool wegwerfe sind meine Konfigurationsdateien immer noch da und können auch weiter benutzt und notfalls per Hand editiert werden.

Was ich bisher sehe ist, das es mir im Wesentlichen ein schickes Webinterface gibt und dann von mir aus auch noch die ein oder andere Sache etwas erleichtert. Aber ich sehe jetzt irgendwie noch keinen signifikanten Vorteil so a-la 'das erleichtert dies und jenes enorm.'

Ist aber total easy. Eine Anwendung (z. B. Free-RDP) wird samt Konfiguration nur einmal im OTC-Manager erstellt und kann dann auf beliebige Clients ausgerollt werden.

Die Frage ist ja, warum ich das so machen wollen würde. Weil Linux-Distributionen haben ja bereits einen Paketmanager. Warum es da noch so eine extra Lösung braucht ist mir nicht klar. Und ja. Wenn man mal ne Anwendung freigeben will ist das vielleicht noch easy. Wenn es ein dutzend Programme sind und ich mich da durch irgendeinen Maus-Parkour klicken muss statt einfach nur ein apt install programmA programmB programmC ... zu machen dann frag ich mich natürlich was das soll.

Dazu kommt ja noch ein anderes Problem. Die Programme werden ja (so wie ich es verstanden hab) per eine Art Dateisystem-Image auf die Clients übertragen. Die Clients selber haben ja keine Platten. Diese Images müssen also als RAM-Disk laufen. RAM ist aber üblicherweise arg begrenzt (vor allem weil ich ihn ja lieber für Programme nutzen würde als für RAM-Disks).

All diese Probleme hab ich nicht, wenn ich den Root-Tree einfach per NFS exportiere und der Client das wie ein normales Festplattenlaufwerk benutzt.

Wie gesagt. In bestimmten Szenarien macht das Sinn. Und openthinclient scheint ja auch eher als Thin-Client-Tool gedacht. Also eher so das man eigentlich sein Kram auf nem Terminal-Server hat und dann bietet es halt die Möglichkeit auch mal vereinzelt Programme auf den Clients lokal ausführen zu lassen. Das ist aber eigentlich nicht das Konzept was ich möchte. Ich habe keinen Terminal-Server und bei mir ist es die Regel das Programme lokal ausgeführt werden. Man kann es sich natürlich irgendwie so hinbiegen das es auch für mein Konzept passt aber eigentlich erhärtet sich eher das Gefühl das es nicht das passende Tool ist für das, was ich vorhabe.

 

[Skysnake]

Mal vorne weg ein paar Fragen.

Um wie viele Rechner geht es denn? 10, 100, 500, 1.000, 2.000 oder 10.000 Rechner?

Aus eigener Erfahrung kann ich sagen, das der Betrieb von ein paar hundert Rechnern kein Problem ist. Wenn du nur 100 oder 200 Rechner hast, dann tut das einfach. Interessant wird es erst wenn du in die Region von 1.000 Rechnern kommst. Dann wird das mit dnsmasq zum Beispiel ein Problem, weil das Ding nicht so sonderlich performant ist. Da muss man dann die Rechner über ne Minute oder so verteilt Booten. Dafür gibt es aber auch Lösungen. Dann bootet man auch paar tausend Knoten einfach.

Es ist relativ wichtig sich direkt am Anfang hin zu setzen und ALLE Randbedingungen zu notieren. Woher kommt denn aktuell eure Nutzerverwaltung usw usf.

Welches OS wollt ihr denn einsetzen? Und seid ihr bereit dafür zu bezahlen?

Wenn ich so lese was du schreibst, denke ich BrightClusterManager oder XCat was sein. Gibt da noch viele andere Lösungen von den unterschiedlichen OEMs.

Ihr müsst euch halt auch fragen, wollt/braucht ihr HA?

Was für storage wollt/habt ihr?

Seid ihr euch sicher, das ihr die Systeme diskless betreiben wollt? Je nachdem ist es deutlich performanter, wenn man statefull Knoten hat. Die installiert man dann zur Not neu.

Oder man hat ein Base Image und macht den Rest über Ansible/Pupped/etc.

Hat das PXE/Net boot schon mal jemand mit dnsmasq gemacht oder sind da irgendwelche Komplikationen zu erwarten?

Ja, das kann man machen. Prinzipiell musst du einfach nen DHCP und nen tftp Server haben. Das war es dann auch schon.

Bleibt halt die Frage nach der Nutzerverwaltung und wie man das implementiert. Auch openthinclient und Co werden da sicherlich auf etwas Vorhandenes zurückgreifen.

Naja, das ist dich recht einfach. Man nimmt LDAP oder AD oder FreeIPA oder 389 Directory Server.

Generell würde ich gerne verstehen welche Basistechnologien benutzt werden und dann anhand dessen entscheiden, ob man zu sowas wie openthinclient greift was einem dann die ein oder andere Sache erleichtert/abnimmt.

DHCP, TFTP usw. Da ist absolut nichts Spezielles dran. Linux liefert alles mit was man braucht.

Ich vermute jetzt mal letzteres. Das Filesystem des Debian-Images, welches auf den Clients läuft und dort ca. 250-300 MB Ram belegt, entspricht einem Standard-Debian. Ansonsten ist es natürlich ziemlich abgespeckt, damit die Clients relativ schnell booten. Vielleicht kann man da noch dran rumbasteln - war aber bei uns nie notwendig.

Also typische Systeme die man so provisioniert ist 90%+ der Bootzeit durch den Postscreen usw definiert. Alsobzumindwst meine Erfahrung.

All diese Probleme hab ich nicht, wenn ich den Root-Tree einfach per NFS exportiere und der Client das wie ein normales Festplattenlaufwerk benutzt.

NFS kann man machen ist aber auch nicht mega performant. Man kann da auch über parallele Filesysteme nachdenken wie

Lustre
GPFS
GLUSTER
PANASAS
....

Ich würde wirklich mal die Größe klären. Je nachdem könnt ihr zu nem OEM gehen und euch die Software dafür mit verkaufen lassen. Das gibt es dann meist (fast) für Lau.

 

[andy_m4]

Mal vorne weg ein paar Fragen.

Ja. Das ist immer ganz hilfreich. :-)

Um wie viele Rechner geht es denn? 10, 100, 500, 1.000, 2.000 oder 10.000 Rechner?

Ein vergleichsweise kleiner Kreis. Vielleicht 20. Das kann auch noch wachsen, aber bleibt aber in der Größenordnung von unter 100.

Woher kommt denn aktuell eure Nutzerverwaltung usw usf.

Bisher gibt es keine Nutzerverwaltung. Ist daher auch die Frage, wie man das macht. Einfach eine /etc/passwd wird man sinnvollerweise nicht machen.

Welches OS wollt ihr denn einsetzen?

Clientseitig Linux. Serverseitig macht das sicherlich dann auch Sinn.

Und seid ihr bereit dafür zu bezahlen?

Bereit schon. Allerdings ist jetzt nicht wirklich viel Geld da. Selbst die Hardware sind jetzt überwiegend Spenden. Kurzum: Wenn man Ausgaben minimieren könnte, wäre das nicht schlecht.

Was für storage wollt/habt ihr?

Nix besonderes. Da haben wir eher den naiven Ansatz einen (bzw. 2, damit man einen als "Backup" hat) als Server zu deklarieren und dort mehrere Platten einzubauen und als RAID-Verbund zu betreiben.

Ihr müsst euch halt auch fragen, wollt/braucht ihr HA?

Eher nicht. Ist auch nicht irgendwas Professionelles wo sonstwas von abhängt wenn das jetzt mal Stunden oder ein paar Tage nicht läuft.

Seid ihr euch sicher, das ihr die Systeme diskless betreiben wollt? Je nachdem ist es deutlich performanter, wenn man statefull Knoten hat. Die installiert man dann zur Not neu.

Der Charme bei diskless besteht ja nicht nur darin das man sich lokale Platten spart, sondern das auch die Administration einfacher wird. Den Geschwindigkeitspunkt sehe ich auch aber bisher würde ich mal sagen, das das für unseren Fall nicht wirklich dramatisch wird. Falls doch mann man ja darüber nachdenken das man doch ne lokale "Platte" nimmt und die dann einfach mit dem Master-Root-Tree synchronisiert.

Man nimmt LDAP oder AD oder FreeIPA oder 389 Directory Server.

Klingt erst mal gut. Oder wären solche Lösungen für <50 User eher oversized? Und falls ja, was wären mögliche Alternativen?

NFS kann man machen ist aber auch nicht mega performant.

Ich würde jetzt mal sagen für unsere Größenordnung performant genug. :-)

 

[Skysnake]

Der Charme bei diskless besteht ja nicht nur darin das man sich lokale Platten spart, sondern das auch die Administration einfacher wird. Den Geschwindigkeitspunkt sehe ich auch aber bisher würde ich mal sagen, das das für unseren Fall nicht wirklich dramatisch wird. Falls doch mann man ja darüber nachdenken das man doch ne lokale "Platte" nimmt und die dann einfach mit dem Master-Root-Tree synchronisiert.

Ob diskless aka stateless oder mit disk aka stateful ist egal was die Wartung anbelangt. Du kannst ja einfach neu deployn. Das ist also mehr ne Frage der Disziplin, das man Änderungen zumindest auch im Image macht und nicht nur auf dem stateful Knoten.

Allgemein booten die stateful Knoten halt etwas schneller und dad Netz ist nicht so stark belastet beim Booten. Und man hat halt x hundert MB mehr RAM frei. Zudem dauert das deployn etwas länger in die SSD als in den RAM.

Btw ich würde heutzutage immer ne SSD fürs rootfilesystem nehmen.

Klingt erst mal gut. Oder wären solche Lösungen für <50 User eher oversized? Und falls ja, was wären mögliche Alternativen?

Nö.

Ist halt nur die Frage, ob man gui und SSL will. Wenn ja, ist FreeIPA nen Blick Wert.

Die Lösungen kann man im Allgemeinen alle ziemlich simpel halten, aber auch SEHR komplex machen.

Bei 50 Rechnern bei denen unterschiedliche Leute drauf zugreifen ist das schon SEHR zu empfehlen. Selbst wenn es nur 5 Nutzer sind.

Ich würde jetzt mal sagen für unsere Größenordnung performant genug. :-)

Das hat nicht unbedingt was mit der Größe des Systems zu tun, sondern damit wie man das nutzt. Wenn man im nfa locken muss wird das schnell sehr sehr langsam.


Wie gesagt, schau dir mal xcat an. Das könnte was für euch sein.

 

[Daloop]

Die Frage ist ja, warum ich das so machen wollen würde. Weil Linux-Distributionen haben ja bereits einen Paketmanager. Warum es da noch so eine extra Lösung braucht ist mir nicht klar. Und ja. Wenn man mal ne Anwendung freigeben will ist das vielleicht noch easy. Wenn es ein dutzend Programme sind und ich mich da durch irgendeinen Maus-Parkour klicken muss statt einfach nur ein apt install programmA programmB programmC ... zu machen dann frag ich mich natürlich was das soll.

Die Clients haben natürlich keinen Paketmanager. Wäre auch sinnlos, da das OS im RAM läuft und die Clients selbst ja keine Disks zum persistenten Installieren haben. Sobald die Kisten ausgeschaltet werden, ist alles weg.

Dazu kommt ja noch ein anderes Problem. Die Programme werden ja (so wie ich es verstanden hab) per eine Art Dateisystem-Image auf die Clients übertragen. Die Clients selber haben ja keine Platten. Diese Images müssen also als RAM-Disk laufen. RAM ist aber üblicherweise arg begrenzt (vor allem weil ich ihn ja lieber für Programme nutzen würde als für RAM-Disks).

Genauso ist es. Das gesamte Client-OS belegt hier allerdings nur ca. 250 MB. Da sollte selbst bei 1 oder 2 GB RAM-Bestückung der Clients noch genug Luft für ein paar andere Programme sein.

Du hast allerdings bis jetzt noch nicht gesagt, was auf den Clients überhaupt gemacht werden soll. Vielleicht ist mein Vorschlag zur Nutzung von openthinclient dann wirklich nicht passend und Du solltest Dir die von Skysnake empfohlenen Lösungen anschauen.

Ergänzung (2. Oktober 2022)

FreeIPA

Cool, kannte ich noch gar nicht. Ist quasi das Linux-Pendant zu einem Windows-Domain Controller, oder?

 

[Skysnake]

Keine Ahnung. Kenne mich im Windowsbereich nicht aus. FreeIPA ist halt das Upstream Projekt der RedHat Lösung.

 

[andy_m4]

@Skysnake
Danke für Deinen Input.

Ob diskless aka stateless oder mit disk aka stateful ist egal was die Wartung anbelangt. Du kannst ja einfach neu deployn.

Da hast Du nicht Unrecht.

Btw ich würde heutzutage immer ne SSD fürs rootfilesystem nehmen.

Ja. Man braucht ja auch keine großen SSDs und dann wirds ja auch nicht wirklich teuer.

Ist halt nur die Frage, ob man gui und SSL will. Wenn ja, ist FreeIPA nen Blick Wert.

Ja. Das hatte ich mir jetzt nach Deiner Anregung schon mal näher angesehen. Fand ich gut.

Das hat nicht unbedingt was mit der Größe des Systems zu tun, sondern damit wie man das nutzt.

Ja. Das meinte ich auch.

Wie gesagt, schau dir mal xcat an. Das könnte was für euch sein.

Wenn Du das schon so empfiehlst, dann ist das sicherlich einen Blick wert. :-)
https://xcat.org/

Die Clients haben natürlich keinen Paketmanager. Wäre auch sinnlos, da das OS im RAM läuft und die Clients selbst ja keine Disks zum persistenten Installieren haben. Sobald die Kisten ausgeschaltet werden, ist alles weg.

Ja. Das habe ich verstanden. Ich finds halt nur unpraktisch quasi den bestehenden Paketmanager wegzuwerfen um dann irgendwie ein proprietäres eigenes Ding zu machen.
Wie gesagt. Das mag in gewissen Szenarien Sinn machen. Aber den sehe ich in meinem Anwendungsfall halt nicht.

Genauso ist es. Das gesamte Client-OS belegt hier allerdings nur ca. 250 MB. Da sollte selbst bei 1 oder 2 GB RAM-Bestückung der Clients noch genug Luft für ein paar andere Programme sein.

Ja. Und das empfinde ich als suboptimal das man quasi den RAM für RAMDisks verschwendet. Wie gesagt. Wenn man nur ein paar kleinere Programme hat ist das egal. Aber schon so was Normales wie LibreOffice und ein Browser verschlingt ja mal schnell ein halbes GB an Disk-Space (und da hab ich noch sehr wohlwollend gerechnet und nicht noch benötigte Bibliotheken etc. berücksichtigt). Vom RAM-Bedarf selbst sind die jetzt auch nicht gerade klein. Dann wirds mit 1 oder 2 GB schon eng.

Du hast allerdings bis jetzt noch nicht gesagt, was auf den Clients überhaupt gemacht werden soll.

Mehr oder minder normale Desktop-Nutzung. Also Browser, Office und noch ein paar andere Sachen.

Vielleicht ist mein Vorschlag zur Nutzung von openthinclient dann wirklich nicht passend und Du solltest Dir die von Skysnake empfohlenen Lösungen anschauen.

Ja. Trotzdem Danke für Deinen Vorschlag und für das geduldige Eingehen auf meine Fragen und Anmerkungen. openthinclient ist durchaus ein interessantes Projekt und es ist sicherlich nicht verkehrt es zu kennen.

 

[Skysnake]

Wenn Du das schon so empfiehlst, dann ist das sicherlich einen Blick wert. :-)
https://xcat.org/

Setzen wir selbst bei einigen Kunden ein. Vor allem wenn man kein HA braucht und eben "klein" - also <<1.000 Knoten - bleibt ist das wohl recht simpel und straightforward.

Ich selbst habe damit bisher noch nichts gemacht, wird sich aber ab Dezember ändern.