Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
PXE-Boot mit casper und casper-rw
126 views
Skip to first unread message
Helmut Hullen
Sep 20, 2012, 7:59:00 AM9/20/12
to
Hallo alle miteinander,
ich versuche derzeit, die beiden c't-Projekte "desinfec't" und "surfix"
per PXE-Boot bereitzutstellen.
"Im Prinzip" gibt es daf�r eine Anleitung, und sie funktioniert auch "im
Prinzip". Was mir allerdings fehlt, ist die Speicherung von �nderungen,
bei "desinfec't" beispielsweise die Speicherung der Signaturdateien.
Beim Booten vom USB-Stick reicht es, eine Datei "casper-rw" anzulegen,
die dann im "persistent"-Umfeld mit eingebunden wird und alle �nderungen
dauerhaft �bernimmt.
Beim PXE-Boot habe ich versuchsweise ebenfalls eine solche Datei
angelegt und auf dem PXE-Server "neben" dem Verzeichnis "casper"
abgelegt - sie wird nicht eingebunden.
Die Suche nach weiteren Informationen hat bisher nichts gebracht,
leider.
Was m�sste ich definieren, damit auch eine solche "casper-rw"-Datei
eingebunden wird?
(Am Rande: wenn ich einerseits PXE-Boot mache und andererseits einen
USB-Stick mit einer solchen Datei eingest�pselt habe, dann wird die
Datei eingebunden - ist aber nicht die L�sung, die ich anstrebe)
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me".
ich versuche derzeit, die beiden c't-Projekte "desinfec't" und "surfix"
per PXE-Boot bereitzutstellen.
"Im Prinzip" gibt es daf�r eine Anleitung, und sie funktioniert auch "im
Prinzip". Was mir allerdings fehlt, ist die Speicherung von �nderungen,
bei "desinfec't" beispielsweise die Speicherung der Signaturdateien.
Beim Booten vom USB-Stick reicht es, eine Datei "casper-rw" anzulegen,
die dann im "persistent"-Umfeld mit eingebunden wird und alle �nderungen
dauerhaft �bernimmt.
Beim PXE-Boot habe ich versuchsweise ebenfalls eine solche Datei
angelegt und auf dem PXE-Server "neben" dem Verzeichnis "casper"
abgelegt - sie wird nicht eingebunden.
Die Suche nach weiteren Informationen hat bisher nichts gebracht,
leider.
Was m�sste ich definieren, damit auch eine solche "casper-rw"-Datei
eingebunden wird?
(Am Rande: wenn ich einerseits PXE-Boot mache und andererseits einen
USB-Stick mit einer solchen Datei eingest�pselt habe, dann wird die
Datei eingebunden - ist aber nicht die L�sung, die ich anstrebe)
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Message has been deleted
Detlef Bosau
Oct 18, 2012, 10:31:20 AM10/18/12
to
Am 18.10.2012 13:38, schrieb Frank Boehm:
>> dauerhaft übernimmt.
>
> Dafuer hab ich eine Erklaerung gefunden:
> http://www.heise.de/security/foren/S-Re-Desinfect-im-Netz/forum-196560/msg-22589267/read/
>
> Es werden nur lokale block devices fuer eine Suche nach einem
> persistent Ort verwendet, es kommt nie zu einer Suche im Netz auf dem
> nfs server.
Wobei ich bezweifle, daß beim PXE Boot überhaupt ein NFS Server zum
Tragen kommt.
PXE selber greift auf TFTP zurück, danach wird (zumal IIRC M$ seine
Finger im Spiel gehabt hat) zumindest bei der Windows Remote
Installation IIRC der Lan-Manager genommen, also das alte SMB Filesystem
von Dos/Windows etc.
>
> Helmut Hullen <Hel...@hullen.de> wrote:
>
>> Beim Booten vom USB-Stick reicht es, eine Datei "casper-rw" anzulegen,
>> die dann im "persistent"-Umfeld mit eingebunden wird und alle Änderungen
>
>> Beim Booten vom USB-Stick reicht es, eine Datei "casper-rw" anzulegen,
>> dauerhaft übernimmt.
>
> Dafuer hab ich eine Erklaerung gefunden:
> http://www.heise.de/security/foren/S-Re-Desinfect-im-Netz/forum-196560/msg-22589267/read/
>
> Es werden nur lokale block devices fuer eine Suche nach einem
> persistent Ort verwendet, es kommt nie zu einer Suche im Netz auf dem
> nfs server.
Wobei ich bezweifle, daß beim PXE Boot überhaupt ein NFS Server zum
Tragen kommt.
PXE selber greift auf TFTP zurück, danach wird (zumal IIRC M$ seine
Finger im Spiel gehabt hat) zumindest bei der Windows Remote
Installation IIRC der Lan-Manager genommen, also das alte SMB Filesystem
von Dos/Windows etc.
>
Message has been deleted
Helmut Hullen
Oct 18, 2012, 2:28:00 PM10/18/12
to
Hallo, Frank,
Du meintest am 18.10.12:
>> Wobei ich bezweifle, daß beim PXE Boot überhaupt ein NFS Server zum
>> Tragen kommt.
> Schau lieber selber nach.
>> PXE selber greift auf TFTP zurück, danach wird (zumal IIRC M$ seine
>> Finger im Spiel gehabt hat) zumindest bei der Windows Remote
>> Installation IIRC der Lan-Manager genommen, also das alte SMB
>> Filesystem von Dos/Windows etc.
> Der Kernel und eine kleine initrd werden per pxe uebermittelt. Aber
> ein ca. 1GB grosses Image mit den eigentlichen Files in einem
> squashfs wird danach von der initrd per nfs gemountet.
> Wenn wir schon beim Haarespalten sind, eigentlich ist es keine initrd
> sondern initramfs.
Und wenn ich die jetzigen Möglichkeiten von PXElinux usw. richtig
erkannt habe: NFS oder FTP oder HTTP oder smbfs/cifs. Habe ich was
vergessen?
Du meintest am 18.10.12:
>> Wobei ich bezweifle, daß beim PXE Boot überhaupt ein NFS Server zum
>> Tragen kommt.
>> PXE selber greift auf TFTP zurück, danach wird (zumal IIRC M$ seine
>> Finger im Spiel gehabt hat) zumindest bei der Windows Remote
>> Installation IIRC der Lan-Manager genommen, also das alte SMB
>> Filesystem von Dos/Windows etc.
> ein ca. 1GB grosses Image mit den eigentlichen Files in einem
> squashfs wird danach von der initrd per nfs gemountet.
> Wenn wir schon beim Haarespalten sind, eigentlich ist es keine initrd
> sondern initramfs.
Und wenn ich die jetzigen Möglichkeiten von PXElinux usw. richtig
erkannt habe: NFS oder FTP oder HTTP oder smbfs/cifs. Habe ich was
vergessen?
Detlef Bosau
Oct 18, 2012, 3:29:25 PM10/18/12
to
Am 18.10.2012 18:02, schrieb Frank Boehm:
> Das Prinzip nur einen kleinen Teil ueber pxe zu laden und den grossen
> Rest vom geladenen Linux Kernel mit Linux Treibern per nfs mount zu
> holen ist alt und wurde bei ltsp bis einschl. Version 4.2 auch schon
> durchgefuehrt.
Richtig.
PXE ist, schrieb ic schon, nicht linuxpsezifisch. Es geht im
wesentlichen um eine standardisierte Umgebung für remoteboot.
> Detlef Bosau <detlef...@web.de> wrote:
>>>
>>> Es werden nur lokale block devices fuer eine Suche nach einem
>>> persistent Ort verwendet, es kommt nie zu einer Suche im Netz auf dem
>>> nfs server.
>>
>> Wobei ich bezweifle, daß beim PXE Boot überhaupt ein NFS Server zum
>> Tragen kommt.
>
> Schau lieber selber nach.
>>>
>>> Es werden nur lokale block devices fuer eine Suche nach einem
>>> persistent Ort verwendet, es kommt nie zu einer Suche im Netz auf dem
>>> nfs server.
>>
>> Wobei ich bezweifle, daß beim PXE Boot überhaupt ein NFS Server zum
>> Tragen kommt.
>
>
>> PXE selber greift auf TFTP zurück, danach wird (zumal IIRC M$ seine
>> Finger im Spiel gehabt hat) zumindest bei der Windows Remote
>> Installation IIRC der Lan-Manager genommen, also das alte SMB Filesystem
>> von Dos/Windows etc.
>
>> PXE selber greift auf TFTP zurück, danach wird (zumal IIRC M$ seine
>> Finger im Spiel gehabt hat) zumindest bei der Windows Remote
>> Installation IIRC der Lan-Manager genommen, also das alte SMB Filesystem
>> von Dos/Windows etc.
>
> Der Kernel und eine kleine initrd werden per pxe uebermittelt. Aber ein
Wenn Du das bei Linux so machst. PXE ist nicht Linux-spezifisch.
> Das Prinzip nur einen kleinen Teil ueber pxe zu laden und den grossen
> Rest vom geladenen Linux Kernel mit Linux Treibern per nfs mount zu
> holen ist alt und wurde bei ltsp bis einschl. Version 4.2 auch schon
> durchgefuehrt.
Richtig.
PXE ist, schrieb ic schon, nicht linuxpsezifisch. Es geht im
wesentlichen um eine standardisierte Umgebung für remoteboot.
Juergen Ilse
Oct 18, 2012, 3:35:11 PM10/18/12
to
Hallo,
Frank Boehm <frab...@gmx.de> wrote:
aber in der Praxis voellig unbrauchbar ...
> Schau lieber selber nach.
PXE sdelnst benoetigt AFAIK kein NFS, der ueber PXE geladene Kernel
fuer seine Initialisierung (bs das root-FS gemountet ist) dagegen
ggfs. schon, und das meinte ich mit "korrekt aber in der Praxis
unbrauchbar": PXE benoetigt kein NFS, das ueber PXE gestartet
System bei seiner Initialisierung im Falle von Linux schon, aber
da den Anwender nicht interessiert, ob das ueber PXE gestartete
System nun wegen fehlgeschlagenem PXE oder wegewm fehlgeschlagener
Kernel-Initialisierung nicht hochkommt, ist das im Endeffekt in
der Praxis voellig irrelevant.
>> PXE selber greift auf TFTP zurück, danach wird (zumal IIRC M$ seine
>> Finger im Spiel gehabt hat) zumindest bei der Windows Remote
>> Installation IIRC der Lan-Manager genommen, also das alte SMB Filesystem
>> von Dos/Windows etc.
Bei Windows vermutlich ja, bei anderen Systemen nichr unbedingt.
Ser Teil des Bootvoegangs ist genaugenommen kein Teil von PXE mehr,
sondern Teil der Initialisierung des ueber PXE gestarteten Systems.
> Der Kernel und eine kleine initrd werden per pxe uebermittelt. Aber ein
andere Methoden als NFS gemountet werden, auch wenn das sicher eher
"unuebliche Installationen" waeren ...
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.
Frank Boehm <frab...@gmx.de> wrote:
> Detlef Bosau <detlef...@web.de> wrote:
>> > Es werden nur lokale block devices fuer eine Suche nach einem
>> > persistent Ort verwendet, es kommt nie zu einer Suche im Netz auf dem
>> > nfs server.
>> Wobei ich bezweifle, daß beim PXE Boot überhaupt ein NFS Server zum
>> Tragen kommt.
Das ist fast so etwas wie eine Margematikerantwort: im Pronzip korrekt,
>> > Es werden nur lokale block devices fuer eine Suche nach einem
>> > persistent Ort verwendet, es kommt nie zu einer Suche im Netz auf dem
>> > nfs server.
>> Wobei ich bezweifle, daß beim PXE Boot überhaupt ein NFS Server zum
>> Tragen kommt.
aber in der Praxis voellig unbrauchbar ...
> Schau lieber selber nach.
PXE sdelnst benoetigt AFAIK kein NFS, der ueber PXE geladene Kernel
fuer seine Initialisierung (bs das root-FS gemountet ist) dagegen
ggfs. schon, und das meinte ich mit "korrekt aber in der Praxis
unbrauchbar": PXE benoetigt kein NFS, das ueber PXE gestartet
System bei seiner Initialisierung im Falle von Linux schon, aber
da den Anwender nicht interessiert, ob das ueber PXE gestartete
System nun wegen fehlgeschlagenem PXE oder wegewm fehlgeschlagener
Kernel-Initialisierung nicht hochkommt, ist das im Endeffekt in
der Praxis voellig irrelevant.
>> PXE selber greift auf TFTP zurück, danach wird (zumal IIRC M$ seine
>> Finger im Spiel gehabt hat) zumindest bei der Windows Remote
>> Installation IIRC der Lan-Manager genommen, also das alte SMB Filesystem
>> von Dos/Windows etc.
Ser Teil des Bootvoegangs ist genaugenommen kein Teil von PXE mehr,
sondern Teil der Initialisierung des ueber PXE gestarteten Systems.
> Der Kernel und eine kleine initrd werden per pxe uebermittelt. Aber ein
> ca. 1GB grosses Image mit den eigentlichen Files in einem squashfs wird
> danach von der initrd per nfs gemountet.
> Wenn wir schon beim Haarespalten sind, eigentlich ist es keine initrd
> sondern initramfs.
Bei entsprechend konfiguriertem Kernel koennte / sicherlich auch auf
> danach von der initrd per nfs gemountet.
> Wenn wir schon beim Haarespalten sind, eigentlich ist es keine initrd
> sondern initramfs.
andere Methoden als NFS gemountet werden, auch wenn das sicher eher
"unuebliche Installationen" waeren ...
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.
Juergen Ilse
Oct 18, 2012, 4:02:57 PM10/18/12
to
>> > Es werden nur lokale block devices fuer eine Suche nach einem
>> > persistent Ort verwendet, es kommt nie zu einer Suche im Netz auf dem
>> > nfs server.
>> Wobei ich bezweifle, daß beim PXE Boot überhaupt ein NFS Server zum
>> Tragen kommt.
Das ist fast so etwas wie eine Mathematikerantwort: im Prinzip korrekt,
>> > persistent Ort verwendet, es kommt nie zu einer Suche im Netz auf dem
>> > nfs server.
>> Wobei ich bezweifle, daß beim PXE Boot überhaupt ein NFS Server zum
>> Tragen kommt.
aber in der Praxis voellig unbrauchbar ...
> Schau lieber selber nach.
PXE selbst benoetigt AFAIK kein NFS, der ueber PXE geladene Kernel
> Schau lieber selber nach.
fuer seine Initialisierung (bs das root-FS gemountet ist) dagegen
ggfs. schon, und das meinte ich mit "korrekt aber in der Praxis
unbrauchbar": PXE benoetigt kein NFS, das ueber PXE gestartet
System bei seiner Initialisierung im Falle von Linux schon, aber
da den Anwender nicht interessiert, ob das ueber PXE gestartete
System nun wegen fehlgeschlagenem PXE oder wegewm fehlgeschlagener
Kernel-Initialisierung nicht hochkommt, ist das im Endeffekt in
der Praxis voellig irrelevant.
ggfs. schon, und das meinte ich mit "korrekt aber in der Praxis
unbrauchbar": PXE benoetigt kein NFS, das ueber PXE gestartet
System bei seiner Initialisierung im Falle von Linux schon, aber
da den Anwender nicht interessiert, ob das ueber PXE gestartete
System nun wegen fehlgeschlagenem PXE oder wegewm fehlgeschlagener
Kernel-Initialisierung nicht hochkommt, ist das im Endeffekt in
der Praxis voellig irrelevant.
>> PXE selber greift auf TFTP zurück, danach wird (zumal IIRC M$ seine
>> Finger im Spiel gehabt hat) zumindest bei der Windows Remote
>> Installation IIRC der Lan-Manager genommen, also das alte SMB Filesystem
>> von Dos/Windows etc.
>> Finger im Spiel gehabt hat) zumindest bei der Windows Remote
>> Installation IIRC der Lan-Manager genommen, also das alte SMB Filesystem
>> von Dos/Windows etc.
Detlef Bosau
Oct 19, 2012, 5:14:30 AM10/19/12
to
Am 18.10.2012 22:02, schrieb Juergen Ilse:
> Bei Windows vermutlich ja, bei anderen Systemen nichr unbedingt.
> Ser Teil des Bootvoegangs ist genaugenommen kein Teil von PXE mehr,
> sondern Teil der Initialisierung des ueber PXE gestarteten Systems.
>
Im Grunde ist das alles tiefste Historie.
> Bei Windows vermutlich ja, bei anderen Systemen nichr unbedingt.
> Ser Teil des Bootvoegangs ist genaugenommen kein Teil von PXE mehr,
> sondern Teil der Initialisierung des ueber PXE gestarteten Systems.
>
Es war von Anfang an immer die Frage, ob man über Ethernet Ethernet,
Ethernet oder Ethernet macht. (Kleines Augenzwinkern an unseren
"Möchtergern IT Fachmann", den mit der unsagbar vielen praktischen
Erfahrung, was Ethernet, Ethernet und Ethernet ist, und was das mit
Ethernet zu tun hat. Monsieur hält sich ja auch für Linux-"erfahren".)
IIRC gab es da vor 20 Jahren Netzwerkkarten, die dann mal gerade
"packetdriver" mitgeliefert haben, und als dann an der Uni die ersten
Netware-Server reingestellt wurden, ging das Geprügel los.
Äußerlich kam dann der ganz Krust mit ODI und NDIS und tralala dazu.
Wenn ich es richtig vermute, ich habe den PXE Standard nicht im Original
gesehen, hätte man bei PXE doch zunächst mal nichts anderes als eine
definierte Schnittstelle zwischen BIOS und (Ethernet-)Karte,
möglicherweise die Verabredung, über Ethernet dann auch Ethernet zu
machen und weder Ethernet noch Ethernet, und dann hätte man zum
"normalen" ISA BIOS ein paar ganz rudimentäre Erweiterungen, daß das
Zeug IP Pakete senden und empfangen kann, daß das Zeug UDP kann und man
eben gerade BOOTP und TFTP darauf aufsetzt.
Und vermutlich hat man sich dann darauf geeinigt (was vor 20 Jahren
nicht selbstverständlich war, aber unser megaerfahrene IT Fachmann wird
das aus der Praxis gerne erläutern), daß beim booten immer mit Ramdisk
gearbeitet wird.
Damit hätte man remoteboot weitgehend generisch, es wäre halt nur die
eigentliche Schnittstelle BIOS - Netzwerkkarte standardidisiert, der
Rest wäre generisch im BIOS.
Aber wie gesagt, das ist tiefste Historie und das ist, auch wenn es mit
Getöse und Getröte daherkommt und unser Möchtegern-IT-ler jetzt wieder
von "Einsatz" und "Weiterbildung" schwadronieren wird, ganz uralter Wein
in neuen Schläuchen.
Das, was da zum x-ten Mal neu aufgegossen wird, ist über 20 Jahre alt.
Message has been deleted
Message has been deleted
Message has been deleted
Helmut Hullen
Oct 19, 2012, 6:38:00 AM10/19/12
to
Hallo, Frank,
Du meintest am 19.10.12:
>> Und wenn ich die jetzigen Möglichkeiten von PXElinux usw. richtig
>> erkannt habe: NFS oder FTP oder HTTP oder smbfs/cifs. Habe ich was
>> vergessen?
> So regelmaessig lese ich die syslinux liste gar nicht mit, um alle
> aktuellen Features zu kennen. Es ist schon beeindruckend was die
> Jungs da alles auf die Beine stellen. Meine aktuelle Version ist iirc
> bei pxelinux.0-3.81 und jetzt muessten die kurz vor 4.0 stehen.
4.06 ist "fast fertig", 4.05 läuft insgesamt sauber.
Viele schnuckelige Ergänzungen ... nur des öfteren "sparsam"
dokumentiert.
Ich benutze PXE-Boot derzeit vor allem, um bei meinen Rechnern im LAN
mal eben "auf die Schnelle" mit was anderem zu booten als mit dem, was
für den Normalfall auf der Festplatte liegt. Ersetzt Booten von CD und
Booten von USB-Stick, erspart also u.a. die Sucherei.
Du meintest am 19.10.12:
>> Und wenn ich die jetzigen Möglichkeiten von PXElinux usw. richtig
>> erkannt habe: NFS oder FTP oder HTTP oder smbfs/cifs. Habe ich was
>> vergessen?
> aktuellen Features zu kennen. Es ist schon beeindruckend was die
> Jungs da alles auf die Beine stellen. Meine aktuelle Version ist iirc
> bei pxelinux.0-3.81 und jetzt muessten die kurz vor 4.0 stehen.
4.06 ist "fast fertig", 4.05 läuft insgesamt sauber.
Viele schnuckelige Ergänzungen ... nur des öfteren "sparsam"
dokumentiert.
Ich benutze PXE-Boot derzeit vor allem, um bei meinen Rechnern im LAN
mal eben "auf die Schnelle" mit was anderem zu booten als mit dem, was
für den Normalfall auf der Festplatte liegt. Ersetzt Booten von CD und
Booten von USB-Stick, erspart also u.a. die Sucherei.
Detlef Bosau
Oct 19, 2012, 7:23:40 AM10/19/12
to
Am 19.10.2012 09:35, schrieb Frank Boehm:
> Wobei ich schon mal ein Linux Image von einem Windows Server mounten
> liess. War dann eine etwas groessere initrd mit Samba notwendig.
> Funktionierte aber gut.
Und sollte mit heutigen Rechnern nicht mehr nötig sein.
Die heutigen Rechner haben genügend Speicher, um eine
Installationsramdisk unterzubringen.
Samba und NFS sind da unnötiger Aufwand.
> Wobei ich schon mal ein Linux Image von einem Windows Server mounten
> liess. War dann eine etwas groessere initrd mit Samba notwendig.
> Funktionierte aber gut.
Und sollte mit heutigen Rechnern nicht mehr nötig sein.
Die heutigen Rechner haben genügend Speicher, um eine
Installationsramdisk unterzubringen.
Samba und NFS sind da unnötiger Aufwand.
Message has been deleted
Detlef Bosau
Oct 19, 2012, 11:47:47 AM10/19/12
to
Am 19.10.2012 16:29, schrieb Frank Boehm:
>
> Notwendiger Aufwand!
>
> Du und ich gehen sicherlich von grundsaetzlich unterschiedlicher
> vorhandener Hardware aus.
>
Möglicherweise. Und ich habe hier auch manches Altmetall rumstehen.
Die Frage ist nur, wie lange man noch Runen und alte Keltenfunde
heiligen möchte - oder sich dann doch mal um wenigstens mittelalte
Hardware gemüht.
Ich habe hier auf einem Rechner mit 128 MByte Speicher auch kein Ubuntu
Linux mehr installieren können - ich habe es nicht bis zum Exzess
analysiert, denke aber mal, daß das RAM für das Installationsfilesystem
zu klein ist.
Nun, das ist ein Symptom unseres heutigen Rumasens mit Ressourcen.
Früher haben selbst komfortable Installationsimages vielleicht 30, 40
MByte gehabt.
Können wir nur noch in Gigabyte denken?
> Helmut und Ich kennen beide sehr genau die von uns verwendete Hardware.
>
> Genuegend RAM damit etwas derartig grosses
> -rw-r--r-- 1 root root 870M 2012-10-18 16:45 filesystem.squashfs.new
> in einer Ramdisk vorgehalten werden kann haben viele der von uns
> betreuten Rechner nicht, bzw. dann bliebe kein Platz mehr zum Arbeiten.
>
> Es kann auch nicht jeder Rechner ueber 512MB grosse Dateien per PXE
> uebers Netz holen. Oft ist es auch deutlich langsamer dieselbe
Ja. Remoteboot geht auch _ETWAS_ kleiner. Ich sprach von Hardware, die
nicht mal eine Floppy ins RAM bekam, also die Uralt-Netware Clients, die
zum Teil mit nicht mal 1 MByte RAM auskommen mussten.
Wenn ich mich ganz dunkel an die ersten Remoteboot Geschichten unter
Linux erinnere, war da mal von Ramdisks von vielleicht 4 MByte die Rede?
Gut, unser "IT Fachmann" wird mir das sicher genauer erklären, aber von
derartigen Größenordungen redete man vor 20 Jahren.
> Datenmenge per PXE zu holen, als spaeter von einem gebooteten OS mit
> NFS oder Samba.
Oder eben einem lokalen Filesystem in einer Ramdisk. Und da haben noch
vor 10 Jahren 128 MByte komfortabelst gereicht.
>
> Allein Images in der Groesse in eine Ramdisk zu laden dauert da viel
> zu lange. Es wird auch gar nicht alles benoetigt.
Kommt darauf an, was man alles reinschmeißt.
>
> PXE fuer Kernel+initrd und notwendigen Rest per NFS, Samba braucht
> wenig Platz und Zeit bis zum Desktop, ist erprobt und funktioniert.
Das ist der gute alte Remoteboot von vor 20 Jahren, IIRC mal Gero
Kuhlmann aus Hannover fragen, wenn sich jemand mit sowas auskennt, dann
der.
Der debugt Dir den PXE Krust vermutlich auch am Binärcode....
>
> Aber selbst ein neuer Rechner braucht deutlich laenger fuer die reine
> Ramdisk Lösung bis zum Desktop. Der spaetere Geschwindigkeitsvorteil
> beim arbeiten ist auch vernachlaessigbar.
>
> Been there, done it.
Die Frage ist doch, was Du mit dem Geraffel überhaupt willst, nun kenne
ich das Heise-Projekt nicht, aber was ich gesehen habe, waren unattended
installations vor allem von Winodws, das geht mittlerweile wohl ganz gut
und wird auch leidlich unterstützt.
Sowas ist z.B. in Schulen nützlich, wenn Schüler ihren Rechner mal
richtig vergurken dürfen - und mann das Ding dann von Geisterhand wieder
richten will.
Ob man mit sowas "normal arbeiten" will, ist eine andere Frage.
>
> Notwendiger Aufwand!
>
> Du und ich gehen sicherlich von grundsaetzlich unterschiedlicher
> vorhandener Hardware aus.
>
Möglicherweise. Und ich habe hier auch manches Altmetall rumstehen.
Die Frage ist nur, wie lange man noch Runen und alte Keltenfunde
heiligen möchte - oder sich dann doch mal um wenigstens mittelalte
Hardware gemüht.
Ich habe hier auf einem Rechner mit 128 MByte Speicher auch kein Ubuntu
Linux mehr installieren können - ich habe es nicht bis zum Exzess
analysiert, denke aber mal, daß das RAM für das Installationsfilesystem
zu klein ist.
Nun, das ist ein Symptom unseres heutigen Rumasens mit Ressourcen.
Früher haben selbst komfortable Installationsimages vielleicht 30, 40
MByte gehabt.
Können wir nur noch in Gigabyte denken?
> Helmut und Ich kennen beide sehr genau die von uns verwendete Hardware.
>
> Genuegend RAM damit etwas derartig grosses
> -rw-r--r-- 1 root root 870M 2012-10-18 16:45 filesystem.squashfs.new
> in einer Ramdisk vorgehalten werden kann haben viele der von uns
> betreuten Rechner nicht, bzw. dann bliebe kein Platz mehr zum Arbeiten.
>
> Es kann auch nicht jeder Rechner ueber 512MB grosse Dateien per PXE
> uebers Netz holen. Oft ist es auch deutlich langsamer dieselbe
Ja. Remoteboot geht auch _ETWAS_ kleiner. Ich sprach von Hardware, die
nicht mal eine Floppy ins RAM bekam, also die Uralt-Netware Clients, die
zum Teil mit nicht mal 1 MByte RAM auskommen mussten.
Wenn ich mich ganz dunkel an die ersten Remoteboot Geschichten unter
Linux erinnere, war da mal von Ramdisks von vielleicht 4 MByte die Rede?
Gut, unser "IT Fachmann" wird mir das sicher genauer erklären, aber von
derartigen Größenordungen redete man vor 20 Jahren.
> Datenmenge per PXE zu holen, als spaeter von einem gebooteten OS mit
> NFS oder Samba.
Oder eben einem lokalen Filesystem in einer Ramdisk. Und da haben noch
vor 10 Jahren 128 MByte komfortabelst gereicht.
>
> Allein Images in der Groesse in eine Ramdisk zu laden dauert da viel
> zu lange. Es wird auch gar nicht alles benoetigt.
Kommt darauf an, was man alles reinschmeißt.
>
> PXE fuer Kernel+initrd und notwendigen Rest per NFS, Samba braucht
> wenig Platz und Zeit bis zum Desktop, ist erprobt und funktioniert.
Das ist der gute alte Remoteboot von vor 20 Jahren, IIRC mal Gero
Kuhlmann aus Hannover fragen, wenn sich jemand mit sowas auskennt, dann
der.
Der debugt Dir den PXE Krust vermutlich auch am Binärcode....
>
> Aber selbst ein neuer Rechner braucht deutlich laenger fuer die reine
> Ramdisk Lösung bis zum Desktop. Der spaetere Geschwindigkeitsvorteil
> beim arbeiten ist auch vernachlaessigbar.
>
> Been there, done it.
Die Frage ist doch, was Du mit dem Geraffel überhaupt willst, nun kenne
ich das Heise-Projekt nicht, aber was ich gesehen habe, waren unattended
installations vor allem von Winodws, das geht mittlerweile wohl ganz gut
und wird auch leidlich unterstützt.
Sowas ist z.B. in Schulen nützlich, wenn Schüler ihren Rechner mal
richtig vergurken dürfen - und mann das Ding dann von Geisterhand wieder
richten will.
Ob man mit sowas "normal arbeiten" will, ist eine andere Frage.
Helmut Hullen
Oct 19, 2012, 12:35:00 PM10/19/12
to
Hallo, Frank,
Du meintest am 19.10.12:
[...]
Du meintest am 19.10.12:
>> Die heutigen Rechner haben genügend Speicher, um eine
>> Installationsramdisk unterzubringen.
>>
>> Samba und NFS sind da unnötiger Aufwand.
> Notwendiger Aufwand!
> Du und ich gehen sicherlich von grundsaetzlich unterschiedlicher
> vorhandener Hardware aus.
> Du und ich gehen sicherlich von grundsaetzlich unterschiedlicher
> vorhandener Hardware aus.
> Helmut und Ich kennen beide sehr genau die von uns verwendete
> Hardware.
Eben - "heutige Rechner" mögen für heute übliche Installationen genug
> Hardware.
Speicher haben. Ich habe hier auch noch 2 Rechner mit jeweils 384 MByte
RAM; das war 1996 auch "genügend Speicher".
PXE-Boot per Diskette, klitzekleine CLI-Live-CD - passt.
Detlef Bosau
Oct 19, 2012, 1:48:52 PM10/19/12
to
Am 19.10.2012 18:35, schrieb Helmut Hullen:ehr genau die von uns verwendete
>
> Eben - "heutige Rechner" mögen für heute übliche Installationen genug
> Speicher haben. Ich habe hier auch noch 2 Rechner mit jeweils 384 MByte
> RAM; das war 1996 auch "genügend Speicher".
>
> PXE-Boot per Diskette, klitzekleine CLI-Live-CD - passt.
Das sollte normalerweise sogar heute noch genügend Speicher sein.
Daß das einige Linux-Flavours "differenzierter" seheh, erscheint mir
nicht eben überzeugend.
>
> Eben - "heutige Rechner" mögen für heute übliche Installationen genug
> Speicher haben. Ich habe hier auch noch 2 Rechner mit jeweils 384 MByte
> RAM; das war 1996 auch "genügend Speicher".
>
> PXE-Boot per Diskette, klitzekleine CLI-Live-CD - passt.
Daß das einige Linux-Flavours "differenzierter" seheh, erscheint mir
nicht eben überzeugend.
0 new messages