Marco Moock <mm+solani@dorfdsl.de> wrote:
>Am 27.04.2024 13:54 Uhr schrieb Marc Haber:
>> >> ³ iPXE hat den großen Vorteil, dass es http spricht und den
>> >> Großteil des zu bootenden Betriebssystem so nachladen kann. Das
>> >> ist erheblich schneller als das hier traditionell eingesetzte
>> >> tftp.
>> >
>> >Warum ist tftp signifikant langsamer?
>>
>> Der Hauptgrund dürfte sein, dass tftp kein Receive Window unterstützt,
>> es wird also immer erst auf den Eingang der Quittung gewartet bevor
>> das nächste Datenpaket losgeschickt wird.
>
>Ist das bei den geringen Latenzen im internen Netz wirklich spürbar?

Größenordnungen..

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Jürgen Jänicke schrieb am 27/4/2024 12:10:

> Ups, zu früh gefreut. Leider ist es nur bei einem Neustart (Warmstart)
> ok. Bei einem richtigen Kaltstart wartet er wieder ca. 15 Sekunden im
> BIOS trotz obiger Einstellung.

Ist das BIOS/UEFI aktuell? Falls nein, Update machen.

--
Gerald

Am 27.04.24 um 18:53 schrieb Marc Haber:
> Ralph Aichinger <ralph@pi.h5.or.at> wrote:
>> Bernd Mayer <beam.bam.boom@knuut.de> wrote:
>>> Was zeigt das BIOS 15 Sekunden lang an?

Diese Frage ist IMO noch offen oder? War die Antwort "Nix"?

>> Ich bin zwar nicht der angesprochene, aber gerade im Serverbereich ist
>> 15 Sekunden Warten ohne Feedback quasi gar nix.
>
> Bei Arbeitsplatzrechnern ist "Zeit bis zum Windows-Desktop" eine
> durchaus nicht unwichtige Metrik, auch in der Presse.
Sehe ich auch so, und hier geht's ja m.W. auch um einen
Arbeitsplatz-rechner. Und ich halte diese o.g. "Metrik" für so mächtig
(= für ONU's Wichtig weil direkt meßbar) das sie ein Antrieb sein dürfte
für immer mehr... an CPU-Takt, Schnelleres RAM, SSDs und was es eben
sonst beschleunigen könnte. Und dann starten sie das ineffizienteste OS
von allen damit: Windows. ;-)

Und in den Minuten die (m)ein älterer Proliant (G5) hier braucht um
durch seine Startup-Procedere zu taumeln ist mein ebenfalls alter
Desktop (aber mit SSD) längst beim Grafischen Target "Login-Manager"
angekommen und ist am warten. Aber wenigstens wartet er "schnell" :-)

Bye/
/Kay

--
nix

Am 27.04.24 um 12:10 schrieb Jürgen Jänicke:
> Am 27.04.2024 Sa. um 10:55 schrieb Jürgen Jänicke:
>> Am 26.04.2024 Fr. um 19:48 schrieb Kay Martinen:
>>>
>>>
>>> Am 26.04.24 um 18:55 schrieb Marc Haber:
>>>> Marco Moock <mm+solani@dorfdsl.de> wrote:
>>>>> Am 26.04.2024 16:49 Uhr schrieb Jürgen Jänicke:
>>>
>>> Warum steht LAN dann überhaupt in der Bootorder? Statt an 3. Stelle
>>> sollte es überhaupt nicht auftreten - wenn man es nie braucht.
>>>
>> Ja, stimmt eigentlich. Habe jetzt LAN deaktiviert. Also steht jetzt da:
>> 1. Bootgerät: ubuntu (wegen GRUB Bootmanger)

Hast du noch einen Booteintrag für die Platte, ist da nur "ubuntu" oder
mehr, z.b. "grub" oder "EFI-Boot" o.ä.?

>> 2. Bootgerät: Removable Device

Hast du einen SD-Kartenleser im Gerät oder ein CD/DVD Laufwerk?

>> 3. Bootgerät: disabled
>> 4. Bootgerät: disabled
>>
>> Mehr braucht es ja nicht und damit funktioniert es wieder korrekt auch
>> mit deaktiven aber angestecktem Switch.
>>
> Ups, zu früh gefreut. Leider ist es nur bei einem Neustart (Warmstart)
> ok. Bei einem richtigen Kaltstart wartet er wieder ca. 15 Sekunden im
> BIOS trotz obiger Einstellung.

Und du bist dir Sicher das der nicht evtl. 15 Sekunden auf ein (Nicht
vorhandenes oder reagierendes) Removable Device wartet - statt auf das LAN?

Du könntest den 2. Punkt auch mal raus werfen und das Testen. Da es
verschiedene Geräte betrifft kann sich das ggf. überlappen. Also das er
auf ein CD/DVD Laufwerk zugreifen will und im Hintergrund schon versucht
ob das LAN aktiv ist - um bei Timeout des 2. gleich mit dem 3. weiter zu
machen. Da du 3. nun raus geworfen hast träte 2. Zu tage.

BTW. Ich hatte mal einen HP All-In-One Drucker mit Multikarten-leser.
Eines Tages hatte ich die CF-Karte einer Digitalkamera darin vergessen.
Der PC hat beim Booten eine Ewigkeit gewartet weil er den; per USB
angeschlossenen; Kartenleser als Bootgerät erkannte. Nur leider war die
CF nicht bootbar was ihn nicht interessiert hat.

Lösung: CF entfernen und/oder Booten davon im Bios aus knipsen.

Bye/
/Kay

--
nix

Am 27.04.2024 Sa. um 23:25 schrieb Kay Martinen:
>
>
> Am 27.04.24 um 12:10 schrieb Jürgen Jänicke:
>> Am 27.04.2024 Sa. um 10:55 schrieb Jürgen Jänicke:
>>> Am 26.04.2024 Fr. um 19:48 schrieb Kay Martinen:
>>>>
>>>>
>>>> Am 26.04.24 um 18:55 schrieb Marc Haber:
>>>>> Marco Moock <mm+solani@dorfdsl.de> wrote:
>>>>>> Am 26.04.2024 16:49 Uhr schrieb Jürgen Jänicke:
>>>>
>>>> Warum steht LAN dann überhaupt in der Bootorder? Statt an 3. Stelle
>>>> sollte es überhaupt nicht auftreten - wenn man es nie braucht.
>>>>
>>> Ja, stimmt eigentlich. Habe jetzt LAN deaktiviert. Also steht jetzt da:
>>> 1. Bootgerät: ubuntu (wegen GRUB Bootmanger)
>
> Hast du noch einen Booteintrag für die Platte, ist da nur "ubuntu" oder
> mehr, z.b. "grub" oder "EFI-Boot" o.ä.?
>
Nein

>>> 2. Bootgerät: Removable Device
>
> Hast du einen SD-Kartenleser im Gerät oder ein CD/DVD Laufwerk?
>
Nur SD-Kartenleser und der Slot ist leer.

>
> Und du bist dir Sicher das der nicht evtl. 15 Sekunden auf ein (Nicht
> vorhandenes oder reagierendes) Removable Device wartet - statt auf das LAN?
>
Und das nur bei ausgeschaltenen Switch?

> Du könntest den 2. Punkt auch mal raus werfen und das Testen.
>
Auch keine Änderung. Aber wie ich gestern 14:48 schrieb habe ich das
Problem nun anderweitig, rein elektro-mechanisch, gelöst.

Jürgen

Am 27.04.2024 Sa. um 22:12 schrieb Gerald E¡scher:
> Jürgen Jänicke schrieb am 27/4/2024 12:10:
>
>> Ups, zu früh gefreut. Leider ist es nur bei einem Neustart (Warmstart)
>> ok. Bei einem richtigen Kaltstart wartet er wieder ca. 15 Sekunden im
>> BIOS trotz obiger Einstellung.
>
> Ist das BIOS/UEFI aktuell? Falls nein, Update machen.
>
Ist laut Acer Website aktuell.

Jürgen

Kay Martinen <usenet@martinen.de> wrote:
>Am 27.04.24 um 18:53 schrieb Marc Haber:
>> Bei Arbeitsplatzrechnern ist "Zeit bis zum Windows-Desktop" eine
>> durchaus nicht unwichtige Metrik, auch in der Presse.
>Sehe ich auch so, und hier geht's ja m.W. auch um einen
>Arbeitsplatz-rechner. Und ich halte diese o.g. "Metrik" für so mächtig
>(= für ONU's Wichtig weil direkt meßbar) das sie ein Antrieb sein dürfte
>für immer mehr... an CPU-Takt, Schnelleres RAM, SSDs und was es eben
>sonst beschleunigen könnte.

Dabei ist der Selbttest und die Hardwareinitialisierung der Firmware
der bestimmende Faktor.

Das neue vom Kunden bereitgestellte Notebook braucht in dieser
Disziplon locker zehn Sekunden länger als sein Vorgänger. Die Zeit vom
Einschalten bis zur Abfrage der Bitlocker-PIN ist bei diesem Gerät
länger als die Zeit von der Bitlocker-PIN bis zum benutzbaren Windows.

Inzwischen habe ich mich auch daran gewöhnt, mein Getränk direkt nach
dem Einschalten zu holen. Muss mich beeilen, denn wenn man die PIN
nicht eingibt, geht der Rechner ziemlich schnell wieder aus.

Satt schneller als der alte am Windows-Desktop ist die neue Kiste
trotzdem.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Am 27.04.24 um 09:19 schrieb Marc Haber:
> Kay Martinen <usenet@martinen.de> wrote:
>> Am 26.04.24 um 18:55 schrieb Marc Haber:
>>> Das würde ich exakt andersrum vermuten.

>>> Switch aus => Link down => PXE boot klar unmöglich => kann schnell von
>>> der Platte booten.
>>
>> Denkbar wäre doch das es trotz link Down auf einen Timeout wartet weil
>> es ja möglich ist das jemand noch in dem Zeitfenster ein Kabel
>> einsteckt. Dann ist der Link da und... (s.u.)
>
> Das würde mich überraschen. Aber gut, so viel Erfahrung mit
> verschiedener Hardware habe ich da nicht.

Naja, einen Teil dieser Erfahrung verdanke ich meinem Unübersichtlichen
"Umfeld" und meiner gelegentlichen Schusseligkeit (Oh, vergessen das
Kabel zu stecken). ;)

>>> Switch an => Link Up => Mindestens DHCP-Timeout muss abgewartet werden
>>> => dauert
>>
>> Wie PXE mit DHCP interagiert weiß ich nicht. Die Klassische Methode
>> (TFTP) fragt den dhcpd nach einem bootfile. Dazu braucht dieser eine
>> entsprechende Einstellung sonst wird er das vermutlich sofort NAK'en und
>> dann kann der nächste Eintrag der Bootorder greifen.
>
> Das ist ein so interressantes Thema dass ich das gerne etwas näher
> beleuchten würde. Vermutlich kennst Du das schon alles, aber es gibt
> ja auch noch andere Leser.

Im Grunde auch nur die konfig des dhcpd und das grundlegende Prozedere
aus DHCP-Discover, -Offer und -Ack/Nak

> Ich habe das selbst noch nie mit IPv6 gemacht, daher beschränke ich
> mich im Weiteren auf IPv4.

Hier Dito weil ich IPv6 im LAN nicht wirklich brauche - und für Remote
Boot oversized hielte.

Aber hat nicht Ulli H. o.a. mal von einem Solchen (PXE, IPv6) Versuch
berichtet - und das er aus unbekannten gründen fehl schlug?

> Ein Startup eines Rechners per PXE beginnt mit einem DHCPDISCOVER. Das
> ist ein Broadcast, kommt also bei allen DHCP-Servern und DHCP-Relays
> im lokalen Netz an. Ja, das können mehrere sein.

Ja. Wobei allerdings immer geraten wird in einem Netz-Segment nur Einen
DHCPd laufen zu haben. Das zwei DHCPd (generisch gesprochen, nicht
ISC-spezifisch gemeint) sich absprechen können oder gemeinsam agieren
ist m.E. noch nicht so lange möglich.

Und wenn man solche nicht verwendet kommt es eben drauf an, wie du unten
ausführst.

> Jeder DHCP-Server (auch diejenigen, an die die DHCP-Relays das
> DHCPDISCOVER weitergeleiter haben), der sich zu einer Antwort berufen
> führt, antwortet auf das DHCPDISCOVER. Der Client bekommt also im
> zweifel mehrere DHCPOFFER-Pakete, die sich auch durchaus widersprechen
> können oder unterschiedliche Informationen beinhalten.

An diesem Punkt setzte aber früher auch das First-come-first-serve an -
jedenfalls wenn der Client keine besonderen Ansprüche stellte. Also wenn
er nur IP/Mask und GW haben will nähme er den ersten der antwortete.

Sollte sich das geändert haben oder beziehst du da spezielle
Anforderungen mit ein?

> Manche Softwaredistributionssysteme greifen an dieser Stelle ein und
> senden, wenn für konkret diesen Client eine Installation hinterlegt
> ist, ein eigenes DHCPOFFER, in dem Boot-Informationen (z.B. Boot File,
> Next Server etc) enthalten sind. Ist keine Installation hinterlegt,
> ignorieren diese Systeme das DHCPDISCOVER und überlassen die Arbeit
> dem "eigentlichen" DHCP-Server.¹

Es ist natürlich klar das ein Dhcp/Bootp-client nicht erfolgreich booten
kann wenn er ein Offer eines Servers annähme in dem kein bootfile
enthalten ist. Mit Softwaredistributionsystem meinst du jetzt andere als
nur den DHCPd, eher welche die ihn nur nutzen um neuen Clients ein ein
RIPL zu ermöglichen. Was man manuell ablegen kann das tun die halt
automagisiert.

> Derselbe Mechanismus wird gerne von IP-Telefonanlagen genutzt, hierbei
> sendet dann die Telefonanlage ein eigenes DHCPOFFER mit den speziellen
> Optionen die das Telefon erwartet.

(Nicht) im Eigenen Voice-VLAN?

> Der Client darf sich dann aus den empfangenen DHCPOFFERs dasjenige
> aussuchen, das ihm am besten in den Kram passt. Ein gerade auf PXE
> Boot wartender Client wird das OFFER nehmen, in dem Boot-Informationen
> entalten sind und alle anderen ignorieren; ein IP-Telefon wird das
> DHCPOFFER wählen, das die Optionen enthält, auf die es wartet.

Soweit klar. Works as expected! Wenn alle diese Systeme in einem
LAN-Segment zusammen stehen dann kann es ja nur so laufen das sich der
Client eines aussuchen muß. Ich bin nur nicht sicher ob das beim Client
ggf. interaktiv ausgewählt werden müßte oder ob der automagisch immer
das richtige zieht.

> Ein bereits gebootetes Betriebssystem wird im Zweifel alles nehmen was
> daherkommt, daher ist es so wichtig dass in den beiden oberen
> Sonderbeispielen weder das Softwaredistributionssystem noch die
> Telefonanlage überhaupt ein DHCPOFFER versenden. Das

Ich meine ein bereits gebootetes OS sendet mit dem Request auch den ggf.
gesetzten hostnamen mit. An dem kann der Server ihn dann z.b. auch
identifizieren falls er einen fixed-address eintrag hat.

Ein Client-gerät das erst booten will kann das m.E. nicht tun. Da bliebe
nur die HW-MAC und erweitert werden könnte das allenfalls wenn der
Client seine eigene MAC oder IP im dns abfragen würde um einen hostnamen
zu bekommen. Aber dann ist die DHCP-Sequenz m.E. schon abgelaufen.

> Distributionssystem wird schweigen wenn für einen Client keine
> Installation hinterlegt ist; die Telefonanlage kennt typischerweise
> den MAC-Adress-Range aus dem "ihre" Telefone ihre MAC-Adressen
> zugewiesen bekommen haben und wird nur diesen antworten. Auf diese
> Weise ist auch gleich der Einsatz "fremder" Telefone schwieriger, was
> im Interesse des Anlagenherstellers liegt.

Heißt: Die Vendor-ID der MAC wird von der IP-Telefonanlage verwendet um
andere Geräte aus zu sperren, sie nicht zu versorgen. Nice!

Drei Bytes entscheiden ob dein Telefon das richtige ist... ;)

> Nachdem der Client sich für ein DHCPOFFER entschieden hat, sendet er
> an den Server, von dem das OFFER gekommen ist, ein DHCPREQUEST² um ihm
> zu bestätigen, dass er der "auserwählte" ist, und mit einer weiteren
> Bestätigung seitens des Servers ist die Lease nun komplett.

Hmm. DHCPACK!

> Im PXE-Fall ist es übrigens nicht unüblich, dass die nachgeladene
> Komponente wieder "von vorne" mit DHCP anfängt, damit die Beteiligen
> dieses Bootstrap-Prozesses nicht miteinander reden müssen. Dumme
> Server vergeben an dieser Stelle eine ganz neue IP-Adresse, was
> zusammen mit langen Leasezeiten durchaus lästig sein kann (weil ein
> PXE-Boot potenziell mehrere Leases belegen kann, und so ein /24 ist
> schon ziemlich schnell voll).

Okay. Das hängt aber doch an den Lease-Zeiten die man IMO Pro Block
getrennt setzen kann.

Man sollte Remote Bootenden Clients generell keine Langen Lease-zeiten
geben es sei denn man könnte sicherstellen das der server den client
auch im gebooteten Zustand "wiedererkennt". Sonst zieht der sich eine
neue IP und landet ggf. im falschen Pool und man hat einen Client mit
zwei Leases. Das wäre aber dann ein Konfigurations-problem.

Bei PXE ändert sich doch die HW-MAC nicht nach dem remote Boot oder?
Man kann sie bei vielen Systemen ja per Software ändern aber warum
sollte man das generell tun?

> Wegen dieses stufenweisen Boots ist es nicht selten notwendig, dass
> der Server "intelligente" Entscheidungen trifft. Zum Beispiel ist
> dann, wenn die weit verbreitete Software iPXE³ zum Einsatz kommt
> üblich, dass im Server Logik wie diese hier hinterlegt ist:
>
> |if exists user-class and option user-class = "iPXE" {
> |filename "http://bootserver.example/pxe/default.ipxe";
> |} else {
> |filename "undionly.kpxe";
> |}
>
> Im Klartext bedeutet das "schaue in die vom Client übermittelte
> DHCP-Option User-Class und wenn Du daran erkennst, dass auf dem Client
> bereits ein iPXE läuft¼ schicke ihm den URL zum Weiterbooten. Sonst
> schicke sage ihm er möge iPXE aus dem Netz laden und ausführen."

bootserver.example ist hier sicher nur Beispielhaft für ein bootfile auf
einem Webserver im LAN denke ich. Mit PXE, iPXE habe ich bisher keine
notwendigen Berührungspunkte gehabt.

Mich gruselt aber dabei das ein Client der eine IP/Mask und GW bekam
dann ggf. schlicht über den Router raus ein beliebiges Bootfile aus dem
Internet abfischen könnte - mit unbekanntem Inhalt. Falsche URL oder
DNS-Fehlkonfig dürfte reichen.

> ³ iPXE hat den großen Vorteil, dass es http spricht und den Großteil
> des zu bootenden Betriebssystem so nachladen kann. Das ist erheblich
> schneller als das hier traditionell eingesetzte tftp. Außerdem kann

Öffnet aber auch die Möglichkeit beliebigen Schadcode aus dem Internet
zu ziehen - direkt beim Booten. Setzt nur Zugriff auf den
verantwortlichen DHCPd voraus. Tröstlich daran ist nur das ein bereits
Kompromittierter Router (DHCPd) das schlimmere Problem ist und Clients
normalerweise nicht so oft booten müssen.

Kay Martinen <usenet@martinen.de> wrote:
>Am 27.04.24 um 09:19 schrieb Marc Haber:
>> Ein Startup eines Rechners per PXE beginnt mit einem DHCPDISCOVER. Das
>> ist ein Broadcast, kommt also bei allen DHCP-Servern und DHCP-Relays
>> im lokalen Netz an. Ja, das können mehrere sein.
>
>Ja. Wobei allerdings immer geraten wird in einem Netz-Segment nur Einen
>DHCPd laufen zu haben. Das zwei DHCPd (generisch gesprochen, nicht
>ISC-spezifisch gemeint) sich absprechen können oder gemeinsam agieren
>ist m.E. noch nicht so lange möglich.

Die müssen sich nicht absprechen, das funktioniert einfach so. Die
Pools dürfen sich halt nicht überschneiden. Die DHCP-Server müssen
sich nur untereinander "absprechen" wenn sie beid den selben Pool
bedienen sollen.

>> Jeder DHCP-Server (auch diejenigen, an die die DHCP-Relays das
>> DHCPDISCOVER weitergeleiter haben), der sich zu einer Antwort berufen
>> führt, antwortet auf das DHCPDISCOVER. Der Client bekommt also im
>> zweifel mehrere DHCPOFFER-Pakete, die sich auch durchaus widersprechen
>> können oder unterschiedliche Informationen beinhalten.
>
>An diesem Punkt setzte aber früher auch das First-come-first-serve an -
>jedenfalls wenn der Client keine besonderen Ansprüche stellte. Also wenn
>er nur IP/Mask und GW haben will nähme er den ersten der antwortete.

Genau. Streng genommen darf er sich aussuchen was er macht. Es ist
freilich logisch, den ersten Datensatz zu nehmen der alles beinhaltet
was der Client hören möchte.

>> Manche Softwaredistributionssysteme greifen an dieser Stelle ein und
>> senden, wenn für konkret diesen Client eine Installation hinterlegt
>> ist, ein eigenes DHCPOFFER, in dem Boot-Informationen (z.B. Boot File,
>> Next Server etc) enthalten sind. Ist keine Installation hinterlegt,
>> ignorieren diese Systeme das DHCPDISCOVER und überlassen die Arbeit
>> dem "eigentlichen" DHCP-Server.¹
>
>Es ist natürlich klar das ein Dhcp/Bootp-client nicht erfolgreich booten
>kann wenn er ein Offer eines Servers annähme in dem kein bootfile
>enthalten ist. Mit Softwaredistributionsystem meinst du jetzt andere als
>nur den DHCPd, eher welche die ihn nur nutzen um neuen Clients ein ein
>RIPL zu ermöglichen. Was man manuell ablegen kann das tun die halt
>automagisiert.

Ich meine jetzt Systeme die z.B. einen neuen Client komplett ohne
menschliche Interaktion mit dem Rechner mit Betriebssystem versorgen
("unattended install").

>> Derselbe Mechanismus wird gerne von IP-Telefonanlagen genutzt, hierbei
>> sendet dann die Telefonanlage ein eigenes DHCPOFFER mit den speziellen
>> Optionen die das Telefon erwartet.
>
>(Nicht) im Eigenen Voice-VLAN?

Nicht notwendigerweise, nein. Das geht auch wenn alles in einem VLAN
ist.

>> Der Client darf sich dann aus den empfangenen DHCPOFFERs dasjenige
>> aussuchen, das ihm am besten in den Kram passt. Ein gerade auf PXE
>> Boot wartender Client wird das OFFER nehmen, in dem Boot-Informationen
>> entalten sind und alle anderen ignorieren; ein IP-Telefon wird das
>> DHCPOFFER wählen, das die Optionen enthält, auf die es wartet.
>
>Soweit klar. Works as expected! Wenn alle diese Systeme in einem
>LAN-Segment zusammen stehen dann kann es ja nur so laufen das sich der
>Client eines aussuchen muß. Ich bin nur nicht sicher ob das beim Client
>ggf. interaktiv ausgewählt werden müßte oder ob der automagisch immer
>das richtige zieht.

Eine interaktive Möglichkeit habe ich noch nie erlebt. Möglich ist es
freilich.

>> Ein bereits gebootetes Betriebssystem wird im Zweifel alles nehmen was
>> daherkommt, daher ist es so wichtig dass in den beiden oberen
>> Sonderbeispielen weder das Softwaredistributionssystem noch die
>> Telefonanlage überhaupt ein DHCPOFFER versenden. Das
>
>Ich meine ein bereits gebootetes OS sendet mit dem Request auch den ggf.
>gesetzten hostnamen mit. An dem kann der Server ihn dann z.b. auch
>identifizieren falls er einen fixed-address eintrag hat.

Ja, könnte er. Gängig ist dass der DHCP-Server dann ein DNSUPDATE
macht.

>> Distributionssystem wird schweigen wenn für einen Client keine
>> Installation hinterlegt ist; die Telefonanlage kennt typischerweise
>> den MAC-Adress-Range aus dem "ihre" Telefone ihre MAC-Adressen
>> zugewiesen bekommen haben und wird nur diesen antworten. Auf diese
>> Weise ist auch gleich der Einsatz "fremder" Telefone schwieriger, was
>> im Interesse des Anlagenherstellers liegt.
>
>Heißt: Die Vendor-ID der MAC wird von der IP-Telefonanlage verwendet um
>andere Geräte aus zu sperren, sie nicht zu versorgen. Nice!

Genau.

>> Nachdem der Client sich für ein DHCPOFFER entschieden hat, sendet er
>> an den Server, von dem das OFFER gekommen ist, ein DHCPREQUEST² um ihm
>> zu bestätigen, dass er der "auserwählte" ist, und mit einer weiteren
>> Bestätigung seitens des Servers ist die Lease nun komplett.
>
>Hmm. DHCPACK!

Ich müsste jetzt wirklich in einen Packettrace oder in den Standard
gucken um zu wissen wie das heißt.

>> Im PXE-Fall ist es übrigens nicht unüblich, dass die nachgeladene
>> Komponente wieder "von vorne" mit DHCP anfängt, damit die Beteiligen
>> dieses Bootstrap-Prozesses nicht miteinander reden müssen. Dumme
>> Server vergeben an dieser Stelle eine ganz neue IP-Adresse, was
>> zusammen mit langen Leasezeiten durchaus lästig sein kann (weil ein
>> PXE-Boot potenziell mehrere Leases belegen kann, und so ein /24 ist
>> schon ziemlich schnell voll).
>
>Okay. Das hängt aber doch an den Lease-Zeiten die man IMO Pro Block
>getrennt setzen kann.
>
>Man sollte Remote Bootenden Clients generell keine Langen Lease-zeiten
>geben es sei denn man könnte sicherstellen das der server den client
>auch im gebooteten Zustand "wiedererkennt". Sonst zieht der sich eine
>neue IP und landet ggf. im falschen Pool und man hat einen Client mit
>zwei Leases. Das wäre aber dann ein Konfigurations-problem.

Das stört aber nicht, bis auf die unnötigt belegte Adresse.

Clients mit Betriebssystem merken sich üblicherweise beim
Herunterfahren ihre IP-Adresse und schicken beim nächsten Boot direkt
ein DHCPREQUEST für ihre alte Adresse an den Server, so dass der ganze
Zirkus nur ablaufen muss wenn der Server erstmal NACK sagt.

>Bei PXE ändert sich doch die HW-MAC nicht nach dem remote Boot oder?
>Man kann sie bei vielen Systemen ja per Software ändern aber warum
>sollte man das generell tun?

Das macht man meistens wenn man fertig gebootet hat damit einen das
Net nicht wiedererkennt. In so einem Unternehmensnetz ist man
natürlich daran interessiert, dass einen das Netz wiedererkennt.

>> Wegen dieses stufenweisen Boots ist es nicht selten notwendig, dass
>> der Server "intelligente" Entscheidungen trifft. Zum Beispiel ist
>> dann, wenn die weit verbreitete Software iPXE³ zum Einsatz kommt
>> üblich, dass im Server Logik wie diese hier hinterlegt ist:
>>
>> |if exists user-class and option user-class = "iPXE" {
>> |filename "http://bootserver.example/pxe/default.ipxe";
>> |} else {
>> |filename "undionly.kpxe";
>> |}
>>
>> Im Klartext bedeutet das "schaue in die vom Client übermittelte
>> DHCP-Option User-Class und wenn Du daran erkennst, dass auf dem Client
>> bereits ein iPXE läuft¼ schicke ihm den URL zum Weiterbooten. Sonst
>> schicke sage ihm er möge iPXE aus dem Netz laden und ausführen."
>
>bootserver.example ist hier sicher nur Beispielhaft für ein bootfile auf
>einem Webserver im LAN denke ich.

Das ist der Hostname des Webservers, der das default.ipxe ausliefert.

>Mich gruselt aber dabei das ein Client der eine IP/Mask und GW bekam
>dann ggf. schlicht über den Router raus ein beliebiges Bootfile aus dem
>Internet abfischen könnte - mit unbekanntem Inhalt. Falsche URL oder
>DNS-Fehlkonfig dürfte reichen.

Es muss natürlich auch der Server willig sein, das Bootfile
auszuliefern, aber ja, das kann dann von irgendwo kommen. Den
Installer von ftp.debian.org zu booten müsste man tatsächlich mal
ausprobieren.

>> ¼ manche VMs benutzen direkt iPXE als ersten Schritt des PXE-Boots,
>> andere Systeme (wie z.b. die meisten "Bleche") wollen den ersten
>> Schritt klassisch per tftp.
>
>Ich habe hier auch noch echte ISA/PCI NICs mit Bootrom Sockel. :-)

Ich zum Glück nicht mehr.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Am 27.04.2024 Sa. um 10:02 schrieb Marcel Mueller:
> Am 26.04.24 um 16:49 schrieb Jürgen Jänicke:
>> Hallo, habe neuerdings einen LAN-Switch dem PC vorgeschalten aber der
>> ist i.d.R. aus, also ohne Stromversorgung. Wird nur bei Bedarf
>> aktiviert. 90% Netzwerkzeit läuft per WLAN.
>> Aber in dem Zustand, Switch ohne Strom, dauert das Booten wesentlich
>> länger. PC bleibt lange im BIOS, bzw. EFI, bevor es dann das
>> eigentliche OS bootet. LAN steht an 3. Stelle nach HDD und USB.
>> Ist der Switch bestromt oder das LAN-Kabel abgesteckt dann geht alles
>> wie gewohnt schnell voran.
>
> Vmtl. erkennt das System, dass das LAN angeschlossen ist, bekommt aber
> dann keine Verbindung.
>
Das heißt u.U. das der Switch selbst als Gerät erkannt wird? Oder
umgekehrt - allein das gesteckte Kabel im stromlosen Switch führt zu
dieser langen Wartezeit? Also wird das vorhandene Gerät registriert aber
da es nicht aktiv ist wird gewartet? Ok, muss ich so wohl hinnehmen.

Jürgen

Jürgen Jänicke schrieb am 29/4/2024 09:15:

> Also wird das vorhandene Gerät registriert aber
> da es nicht aktiv ist wird gewartet? Ok, muss ich so wohl hinnehmen.

Musst du nicht hinnehmen. In jedem ordentlichen BIOS/UEFI gibt es die
Möglichkeit, booten über LAN (PXE) abzuschalten.

--
Gerald

Am 29.04.2024 Mo. um 14:35 schrieb Gerald E¡scher:
> Jürgen Jänicke schrieb am 29/4/2024 09:15:
>
>> Also wird das vorhandene Gerät registriert aber
>> da es nicht aktiv ist wird gewartet? Ok, muss ich so wohl hinnehmen.
>
> Musst du nicht hinnehmen. In jedem ordentlichen BIOS/UEFI gibt es die
> Möglichkeit, booten über LAN (PXE) abzuschalten.
>
Ich schrieb bereits am Samstag(unter anderen)
"
.. . . Habe jetzt LAN deaktiviert. Also steht jetzt da:
1. Bootgerät: ubuntu (wegen GRUB Bootmanger)
2. Bootgerät: Removable Device
3. Bootgerät: disabled
4. Bootgerät: disabled
"
Aktuell ist auch das 2. Bootgerät disabled. Wo noch kann ich LAN
deaktivieren?

Jürgen

Am 29.04.24 um 09:15 schrieb Jürgen Jänicke:
>> Vmtl. erkennt das System, dass das LAN angeschlossen ist, bekommt aber
>> dann keine Verbindung.
>>
> Das heißt u.U. das der Switch selbst als Gerät erkannt wird?

Nein, einen ausgeschalteten Switch kann man nicht erkennen. Aber man
kann entweder die Schleifenimpedanz messen - ein angestecktes Gerät
führt zu einer relativ niederohmigen Verbindung der Adernpaare. Oder man
kann den gesteckten Stecker mechanisch erkennen. Letzteres hat aber den
Nachteil, dass ein eingestecktes, loses Kabel auch erkannt würde.
Außerdem ist Mechanik immer teurer als Elektronik.

> Oder
> umgekehrt - allein das gesteckte Kabel im stromlosen Switch führt zu
> dieser langen Wartezeit?

Zu einer Wartezeit führt nichts von alle dem. Dazu kommt es erst, wenn
im BIOS irgendein Programmcode meint, unbedingt auf eine aktive
Netzwerkverbindung warten zu müssen.

> Also wird das vorhandene Gerät registriert aber
> da es nicht aktiv ist wird gewartet? Ok, muss ich so wohl hinnehmen.

Ich vermute das.
Du kannst das recht leicht testen, indem du das Kabel abziehst.

Marcel

Am 29.04.2024 Mo. um 20:26 schrieb Marcel Mueller:
> Am 29.04.24 um 09:15 schrieb Jürgen Jänicke:
>>> . . . . <<<
>
>> Also wird das vorhandene Gerät registriert aber da es nicht aktiv ist
>> wird gewartet? Ok, muss ich so wohl hinnehmen.
>
> Ich vermute das.
> Du kannst das recht leicht testen, indem du das Kabel abziehst.
>
Mach ich ja nun auch so. Zuerst testweise über einen 4pol. Kippschalter,
jetzt trenne ich die 4 Leitungen (da es nur 100Mbit/s sind) aktuell per
Relais. Und Relais + Switch werden nun nur bei Bedarf zusammen
eingeschalten. Unter anderen auch von einem Raspi welcher aus der Ferne
erreichbar ist und mir dann eben wenn notwendig noch 2 weitere Geräte
startet, ans Netz bringt und auch wieder abhängt und runterfährt.

Jürgen

Am 28.04.24 um 17:23 schrieb Marc Haber:
> Kay Martinen <usenet@martinen.de> wrote:
>> Am 27.04.24 um 09:19 schrieb Marc Haber:

>>> ist ein Broadcast, kommt also bei allen DHCP-Servern und
>>> DHCP-Relays im lokalen Netz an. Ja, das können mehrere sein.

>> 1 DHCPd laufen zu haben. Das zwei DHCPd (...) sich absprechen
>> können oder gemeinsam agieren ist m.E. noch nicht so lange
>> möglich.
>
> Die müssen sich nicht absprechen, das funktioniert einfach so. Die
> Pools dürfen sich halt nicht überschneiden. Die DHCP-Server müssen
> sich nur untereinander "absprechen" wenn sie beid den selben Pool
> bedienen sollen.

Genau das meinte ich. Entweder du hast auf jedem dhcpd einen pool der
unterschiedliche IPs belegt oder es sind mindestens zwei mit gleichem
pool die sich dann aber absprechen sollten. So kann man sich immerhin
gegen ausfall des dhcp absichern ohne das alle clients neue leases brauchen.

>>> Manche Softwaredistributionssysteme greifen an dieser Stelle ein
>>> und senden, wenn für konkret diesen Client eine Installation

>> bootfile enthalten ist. Mit Softwaredistributionsystem meinst du
>> jetzt andere als nur den DHCPd, eher welche die ihn nur nutzen um
>> neuen Clients ein ein RIPL zu ermöglichen. Was man manuell ablegen
>> kann das tun die halt automagisiert.
>
> Ich meine jetzt Systeme die z.B. einen neuen Client komplett ohne
> menschliche Interaktion mit dem Rechner mit Betriebssystem versorgen
> ("unattended install").

Das dürfte z.b. beim Univention Corporate Server (UCS) möglich sein. IMO
bietet der auch Classroom-Management oder Desktop-Installationsdienste
an. Und, wie ich nachlas, scheinen Windows Server da ähnliches zu bieten.

Was mich nicht verwundern sollte. RIPL ging schon bei OS/2 IMO beim LSA4
und das ist echt lang her.

>>> Ein bereits gebootetes Betriebssystem wird im Zweifel alles
>>> nehmen was daherkommt, daher ist es so wichtig dass in den beiden
>>> oberen Sonderbeispielen weder das Softwaredistributionssystem
>>> noch die Telefonanlage überhaupt ein DHCPOFFER versenden. Das
>>
>> Ich meine ein bereits gebootetes OS sendet mit dem Request auch den
>> ggf. gesetzten hostnamen mit. An dem kann der Server ihn dann z.b.
>> auch identifizieren falls er einen fixed-address eintrag hat.
>
> Ja, könnte er. Gängig ist dass der DHCP-Server dann ein DNSUPDATE
> macht.

Bei Windows-Clients ist das m.W. eh der Default. Ab Install ist das
Häkchen in den Netzwerk-einstellungen dafür gesetzt "Adresse in DNS
registrieren".

Bin mir jetzt aber nicht sicher was dabei genau der Unterschied ist. Ob
der Win-Client nur seinen Namen sendet oder ob er frech beim Bind
anklopft und sich selbst eintragen wollte - was eher nicht sinnvoll ist.

Aber zum DNS Update braucht der dhcpd die (rndc) verbindung zum bind.
Die muß m.W. nicht auf localhost liegen. Aber ein Win-Client sollte das
nicht tun können.

>>> und mit einer weiteren Bestätigung seitens des Servers ist die
>>> Lease nun komplett.
>>
>> Hmm. DHCPACK!
>
> Ich müsste jetzt wirklich in einen Packettrace oder in den Standard
> gucken um zu wissen wie das heißt.

Mußt nur in's log schauen. Da stehen bei mir jede menge drin. Anders
geschrieben: DHCP ACK!

>>> reden müssen. Dumme Server vergeben an dieser Stelle eine ganz
>>> neue IP-Adresse, was zusammen mit langen Leasezeiten durchaus
>>> lästig sein kann (weil ein PXE-Boot potenziell mehrere Leases
>>> belegen kann, und so ein /24 ist schon ziemlich schnell voll).

>> Man sollte Remote Bootenden Clients generell keine Langen
>> Lease-zeiten geben es sei denn man könnte sicherstellen das der
>> server den client auch im gebooteten Zustand "wiedererkennt".

> Das stört aber nicht, bis auf die unnötigt belegte Adresse.

Deswegen meinte ich das man die leasezeit dafür kurz wählen sollte. Dann
ist sie schneller wieder frei.

> Clients mit Betriebssystem merken sich üblicherweise beim
> Herunterfahren ihre IP-Adresse und schicken beim nächsten Boot
> direkt ein DHCPREQUEST für ihre alte Adresse an den Server, so dass
> der ganze Zirkus nur ablaufen muss wenn der Server erstmal NACK
> sagt.

Was bei Fixed-address anhand der MAC ja normal nicht vorkommt.

>> Bei PXE ändert sich doch die HW-MAC nicht nach dem remote Boot
>> oder? Man kann sie bei vielen Systemen ja per Software ändern aber
>> warum sollte man das generell tun?
>
> Das macht man meistens wenn man fertig gebootet hat damit einen das
> Net nicht wiedererkennt. In so einem Unternehmensnetz ist man
> natürlich daran interessiert, dass einen das Netz wiedererkennt.

Du meinst damit man mit der Fertig Installierten Maschine nicht gleich
wieder die gleiche Installation neu drauf gebügelt bekommt?
Okay, da kann das dann Sinn machen. Die alternative dürfte aufwändiger
sein, dem Client einen Supplicant geben damit der Switchport ihn erkennt
und in ein anderes VLAN schiebt.

Und man muß auf dem SDS nur die MACs eintragen von den maschinen die neu
installiert werden sollen. Wenn die danach automagisch ihre MAC ändern
zu <myvendor><muster> dann kann man sie auch auseinander halten. So
lange die NIC ihrer Gesetzte MAC nicht vergißt. Sollte aber in ihrem
EEPROM stecken denke ich.

>>> Im Klartext bedeutet das "schaue in die vom Client übermittelte
>>> DHCP-Option User-Class und wenn Du daran erkennst, dass auf dem
>>> Client bereits ein iPXE läuft¼ schicke ihm den URL zum
>>> Weiterbooten. Sonst schicke sage ihm er möge iPXE aus dem Netz
>>> laden und ausführen."
>>
>> bootserver.example ist hier sicher nur Beispielhaft für ein
>> bootfile auf einem Webserver im LAN denke ich.
>
> Das ist der Hostname des Webservers, der das default.ipxe
> ausliefert.

Ich wollte mich schon früher mal mit den dhcp-options mehr auseinander
setzen. Mit user-class u.a. habe ich nur wenig experimentiert und da
ging es mir eher um die Zuordnung des Pools nach dem Client-OS.

Hab ich dann aber mit einem Retro-VLAN erschlagen.

>> Mich gruselt aber dabei das ein Client der eine IP/Mask und GW
>> bekam dann ggf. schlicht über den Router raus ein beliebiges
>> Bootfile aus dem Internet abfischen könnte -

> Es muss natürlich auch der Server willig sein, das Bootfile
> auszuliefern, aber ja, das kann dann von irgendwo kommen. Den

Nun Auth via .htaccess kann man da wohl vergessen also bliebe nur die
Allow und Deny Direktiven nach dem Netz oder IP-Bereich um den Ein zu
hegen das nicht jeder jedes file ziehen könnte. Im LAN ist das nicht das
Ding. Aber...

> Installer von ftp.debian.org zu booten müsste man tatsächlich mal
> ausprobieren.

.... DAS wäre in der Tat mal Lustig. IMO bietet der Installer auch
(uboot, debootstrap?) dienstmodule an für eine Installation aus der
Ferne. Geht das nicht sogar gescripted per Antwort-datei?

Man muß ihn halt nur erst mal gebootet bekommen und per script so weit
das er zumindest eine (remote)shell startet um weiter zu machen - IMO
sogar von einem dritt-host aus wenn ich mich richtig erinnere.

Klingt echt kompliziert aber vermutlich braucht es nur 2 Dateien. Das
image und ein antwort-file das dazu passt. Ist lange her das ich danach
bei debian.org suchte aber ich bin sicher es gibt dazu was.

Wen wunderts. ;-)

>> Ich habe hier auch noch echte ISA/PCI NICs mit Bootrom Sockel. :-)
>
> Ich zum Glück nicht mehr.

Und ich finde aktuell die NIC Kiste mit meinen 3com's nicht wieder,
bräuchte aber grad eine für einen Thin Client den ich zum LAN Router
umstricken will.

Bye/
/Kay

--
nix

Kay Martinen <usenet@martinen.de> wrote:
>Am 28.04.24 um 17:23 schrieb Marc Haber:
>> Kay Martinen <usenet@martinen.de> wrote:
>>> Am 27.04.24 um 09:19 schrieb Marc Haber:
>
>>>> ist ein Broadcast, kommt also bei allen DHCP-Servern und
>>>> DHCP-Relays im lokalen Netz an. Ja, das können mehrere sein.
>
>>> 1 DHCPd laufen zu haben. Das zwei DHCPd (...) sich absprechen
>>> können oder gemeinsam agieren ist m.E. noch nicht so lange
>>> möglich.
>>
>> Die müssen sich nicht absprechen, das funktioniert einfach so. Die
>> Pools dürfen sich halt nicht überschneiden. Die DHCP-Server müssen
>> sich nur untereinander "absprechen" wenn sie beid den selben Pool
>> bedienen sollen.
>
>Genau das meinte ich. Entweder du hast auf jedem dhcpd einen pool der
>unterschiedliche IPs belegt oder es sind mindestens zwei mit gleichem
>pool die sich dann aber absprechen sollten. So kann man sich immerhin
>gegen ausfall des dhcp absichern ohne das alle clients neue leases brauchen.

Ein kurzfristiger Ausfall des DHCP-Servers tut nicht so weh wie man
denkt, die bestehenden Clients haben mindestens die Hälfte ihrer Lease
noch vor sich, weil sie schon ab der halben Lease diese zu erneuern
versuchen. Nur neue Clients gucken ohne IP-Adresse in die Röhre.

Bei redundant ausgeführtem DHCP¹-Servern sind die Leasezeiten
potenziell erheblich kürzer als in der Konfiguration steht, da muss
man mehr aufpassen.

Und in Netzen die nur ein Default Gateway haben, ist ein redundanter
DHCP-Server im Wesentlichen nur Spielerei.

>>>> Ein bereits gebootetes Betriebssystem wird im Zweifel alles
>>>> nehmen was daherkommt, daher ist es so wichtig dass in den beiden
>>>> oberen Sonderbeispielen weder das Softwaredistributionssystem
>>>> noch die Telefonanlage überhaupt ein DHCPOFFER versenden. Das
>>>
>>> Ich meine ein bereits gebootetes OS sendet mit dem Request auch den
>>> ggf. gesetzten hostnamen mit. An dem kann der Server ihn dann z.b.
>>> auch identifizieren falls er einen fixed-address eintrag hat.
>>
>> Ja, könnte er. Gängig ist dass der DHCP-Server dann ein DNSUPDATE
>> macht.
>
>Bei Windows-Clients ist das m.W. eh der Default. Ab Install ist das
>Häkchen in den Netzwerk-einstellungen dafür gesetzt "Adresse in DNS
>registrieren".

Windows-Clients in einem AD sind so gut mit kryptografischen
Zertifikaten, Schlüsseln etc versorgt, die dürfen sich selbst ins DNS
eintragen und brauchen dazu keine Hilfe vom DHCP-Server.

Windows-Clients ohne AD, wo dieser Haken gesetzt ist, sind eine
Landplage, das flutet den DNS-Server mit Anfragen die er nur ablehnen
kann, weil der Client nicht authentifiziert ist.

>> Ich müsste jetzt wirklich in einen Packettrace oder in den Standard
>> gucken um zu wissen wie das heißt.
>
>Mußt nur in's log schauen. Da stehen bei mir jede menge drin. Anders
>geschrieben: DHCP ACK!

Dass das genau so geloggt wird wie es im Standard steht halte ich
nicht für gewährleistet. Aber es stimmt, ich hab mir das in einem
Packet Trace mal angeschaut. Aktuelles tcpdump sagt nur "request" und
"reply", wenn man das genauer wissen will muss man tatsächlich
wireshark anschmeißen.

Danke für die Motivation, ich hab dabei noch andere Dinge gesehen die
für mich lehrreich waren.

>
>>>> reden müssen. Dumme Server vergeben an dieser Stelle eine ganz
>>>> neue IP-Adresse, was zusammen mit langen Leasezeiten durchaus
>>>> lästig sein kann (weil ein PXE-Boot potenziell mehrere Leases
>>>> belegen kann, und so ein /24 ist schon ziemlich schnell voll).
>
>>> Man sollte Remote Bootenden Clients generell keine Langen
>>> Lease-zeiten geben es sei denn man könnte sicherstellen das der
>>> server den client auch im gebooteten Zustand "wiedererkennt".
>
>> Das stört aber nicht, bis auf die unnötigt belegte Adresse.
>
>Deswegen meinte ich das man die leasezeit dafür kurz wählen sollte. Dann
>ist sie schneller wieder frei.

Aber dafür ist man anfälliger bei Störungen im DHCP-Server.

Was bin ich froh dass diese ganzen Überlegungen mit IPv6 nicht mehr
notwendig sind.

>> Clients mit Betriebssystem merken sich üblicherweise beim
>> Herunterfahren ihre IP-Adresse und schicken beim nächsten Boot
>> direkt ein DHCPREQUEST für ihre alte Adresse an den Server, so dass
>> der ganze Zirkus nur ablaufen muss wenn der Server erstmal NACK
>> sagt.
>
>Was bei Fixed-address anhand der MAC ja normal nicht vorkommt.

Das kommt im Wesentlichen vor wenn der Client in ein neues Netz
gewandert ist oder so lange aus war dass seine Lease expired ist UND
die Adresse inzwischen an einen anderen Client verleast wurde.

>>> Bei PXE ändert sich doch die HW-MAC nicht nach dem remote Boot
>>> oder? Man kann sie bei vielen Systemen ja per Software ändern aber
>>> warum sollte man das generell tun?
>>
>> Das macht man meistens wenn man fertig gebootet hat damit einen das
>> Net nicht wiedererkennt. In so einem Unternehmensnetz ist man
>> natürlich daran interessiert, dass einen das Netz wiedererkennt.
>
>Du meinst damit man mit der Fertig Installierten Maschine nicht gleich
>wieder die gleiche Installation neu drauf gebügelt bekommt?

Eher damit die Accesslisten greifen können. Bei der Installation ist
es üblich dass der installierte Client sich beim
Softwaredistributionssystem mit einer Erfolgsmeldung meldet und dieses
daraufhin den Listeneinetrag löscht.

>> Installer von ftp.debian.org zu booten müsste man tatsächlich mal
>> ausprobieren.
>
>... DAS wäre in der Tat mal Lustig. IMO bietet der Installer auch
>(uboot, debootstrap?) dienstmodule an für eine Installation aus der
>Ferne. Geht das nicht sogar gescripted per Antwort-datei?

Ja, natürlich geht das auch vollautomatisch.

Sowas wird aber irgendwie immer ätzend an dem Punkt wo die
Installation zuende ist. Meist möchte man dann ja noch lokal bestimmte
Dinge machen (wie z.B. ssh-Konfiguration, Puppet-Client o.ä.
installieren, hostkeys einmelden etc), und das führt sowohl bei Debian
als auch bei Red Hat zu Monster-Einzeilern.

>
>Man muß ihn halt nur erst mal gebootet bekommen und per script so weit
>das er zumindest eine (remote)shell startet um weiter zu machen - IMO
>sogar von einem dritt-host aus wenn ich mich richtig erinnere.
>
>Klingt echt kompliziert aber vermutlich braucht es nur 2 Dateien. Das
>image und ein antwort-file das dazu passt. Ist lange her das ich danach
>bei debian.org suchte aber ich bin sicher es gibt dazu was.

Lohnt sich so oder so nur wenn das hunderte von Malen pro Woche
durchgespielt wird.

Grüße
Marc

¹ das gilt nur für den als EOL bezeichneten ISC DHCP, mit dem neuen
Kea habe ich noch keine Erfahrungen
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402