[sage] automatische netzwerkgestützte Grundinstallation von Gentoo - gibts das, laeuft das?

[Andreas Jellinghaus]

Am Donnerstag, 2. Oktober 2008 11:56:45 schrieb Benedikt Stockebrand:
> das hängt vom jeweiligen Unix ab.  Die BSDs, und wenn ich mich recht
> erinnere auch Solaris, sind mit wenig Aufwand dazu zu bewegen,
> Diskless Clients zu unterstützen; bei Linux weiss ich aus dem Stand
> nicht, wie weit ich da auf existierende Sachen aufsetzen kann.

diskless ist recht schmerzlos: boot via pxe nertzwerkkarte, 
pxelinux (+bootpd+tftpd auf einem server), kernel und initramfs
per tftpd, und ab dann nfs.

die frage ist eher, wie managed man das? eine möglichkeit ist einen
baum pro rechner. heute kein problem mehr, dank großen platten.
früher gab es hacks, z.B. ein set von kernel patches, mit denen
man eine datei mehrfach hinlegen konnte, und der kernel hat
beim open("/etc/configfile") sich dann magisch das /etc/configfile.hostname
z.B. rausgesucht. kruder hack, die kernel entwickler waren dafür nie
zu begeistern, hat vor einiger zeit aber bei knappen platten echt
geholfen.

hat jemand was schöneres? heute würde ich einfach alle dateien
durch symlinks ersetzen, die ich pro rechner brauche, dann könnte
man einen gemeinsamen baum plus einen pro rechner baum mit nur den
notwendige dateien fein nutzen. oder gleich pro rechner ein eigener
baum...

> Weil ich eigentlich immer schon aus Katastrophenschutzgründen so ein
> Netboot-System im Netz zur Verfügung habe,

hmm. für den worst case, reicht da nicht eine live cd? (gibts ja viele,
bestimmt auch was über netz bootbares, wenn man das will.)

> ich mich jetzt in die Tiefen von FAI- oder JumpStart-Profilen
> einarbeite oder aus einem Shell Script nacheinander disklabel, newfs,
> ./install.sh und sed aufrufe, ist in dem Fall vom Aufwand her
> vergleichbar.

ist schon richtig, man kann alles manuell machen. eine automatische
installation ist fein, wenn man um 3 uhr nachts einen kaputten
rechner ersetzen will, und das mit wenig aufwand (z.B: mac
eintragen, auto install aktivieren) erreichen kann. spart einem
viel arbeit um so eine uhrzeit, vor allem denkarbeit, was wichtig ist,
wenn man nicht viel schlaf hatte.

> - Ich berücksichtige nur die Sachen, die ich tatsächlich brauche.
>   Hardware-RAID und Volume Manager interessieren mich seit ZFS nicht
>   mehr, obskure Treiber und jede Menge andere Sachen kann ich auch
>   weglassen.  Damit wird das ganze wirklich handhabbar.

klar, muss man im eigenen script nicht runtercoden, wenn man das nicht
braucht. umgekehrt wird dir fai da auch kein bein stellen, denke ich mir.
funktionalität, die du einfach überblättern kannst.

zudem ein wenig muss man zumindest bei linux schon wissen. selbst wenn
man neu partitioniert und alles neu erstellt, muss man sichergehen,
das der kernel nicht irgendwie meint, er hätte ein raid gefunden, das
er im hintergrund resynchronisiert. 

> - Der Einarbeitungsaufwand ist bei Shell Scripts für mich persönlich
>   geringer, als mich mit FAI, JumpStart und was auch immer
>   auseinanderzusetzen.

ein eigenes shell script schreiben geht IMO schneller, sehe ich auch so.
ein fremdes shell script verstehen lernen - glaube ich nicht. viele jahre
configure debugging haben mich gelehrt, das shell scripte fast write-only
sind, und das einarbeiten, debuggen und fixen fremden codes eine tortur
sein kann.

> - Scripts bieten mir die größtmögliche Flexibilität an den Stellen, wo
>   ich eventuell wirklich etwas Aufwand treiben will/muss.
>
> - Mindestens JumpStart hatte schon vor Jahren die Eigenschaft, sehr
>   viel Aufwand zu treiben, um ein gegebenes Profil auf der
>   vorgefundenen Hardware passend umzusetzen.  Den Aufwand erspare ich
>   mir bei den Scripts; im Zweifelsfall muss ich eben explizit angeben,
>   welche Platte wie partitioniert werden soll.

bei shell scripten sehe ich das problem, wenn man generisch werden will.
dann wird das scripte schnell zu einem monstrum, das eben auch aus
rechnern klassen macht, profile für installationen kennt, spezielle
hacks für sonderkombinationen von rechnern/klassen/profilen/etc.,
und dann wird das script lang. und lange schell scripte sind so eine
sache, debuggen ist schwer, testen aller if/else zweige hart,
und seiten effekte finden auch nicht einfach (was wird wo gestartet,
wann wieder gekillt, und was passiert im anderen if zweig? war
das absicht? etc.)

> - Ich versuche gar nicht erst, einen Paketmanager ins Spiel zu
>   bringen.  Dabei nutze ich zugegebenermaßen aus, dass die BSDs alles
>   mitbringen, um eine komplett scriptgesteuerte Core-Installation zu
>   machen, die in sich lauf- und netzwerkfähig ist, bevor überhaupt
>   irgendwelche Pakete ins Spiel kommen.

paketmanager oder source ist geschmackssache. erstmal ein lauffähiges
minimalsystem ans netz bringen, und dann sich erst in stufe zwei
den anwendungen und deren configuration zuwenden, der idee kann ich
mich voll und ganz anschliessen.

> Ist zwar schon eine Weile her, habe ich aber getan.  Und gerade weil
> sich Linux an einigen Stellen nicht so einfach verscripten lässt und
> ich auch bewusst noch nicht gesehen habe, dass eine Distribution
> Diskless Clients konsequent unterstützt, halte ich es auch für sehr
> hilfreich.

ich glaube, das es zuviel verschiedene wünsche gibt, wie eine diskless
client installation auszusehen hat. was meinst du? oder wie sollte das
scenario bei dir aussehen?

zudem: ist diskless client noch ein großes thema? oder sind mehr clients
für terminal server aktuell? (wäre ein minimal OS das nur eine gui
mit rdesktop/vnc/... hochbringt. die zu verwalten ist nicht soo wild,
oder?)

> Wenn ich mehr als eine physikalische Linux-Maschine im Einsatz hätte,
> würde ich FAI mit ziemlicher Sicherheit einsetzen; momentan ist es für
> mich aber simpler, VMs zu klonen...

früher hatte man die wahl, ob man rechner auto-installiert oder vom image
her cloned, heute das gleiche mit VMs, oder? 

Viele Grüße,

Andreas