Server per PXE (pxelinux) booten

  • Hallo,


    ich würde gerne einen oder mehrere vServer bzw. Root Server per PXE (pxelinux) booten um sie mit entsprechend angepassten, vorkonfigurierten Betriebssystemen zu befruchten.


    Ist das möglich? Hat das schonmal jemand gemacht? Ich müsste dafür ja für meine Server eine PXE Bootumgebung einrichten können, oder zumindest das pxeliux.cfg Verzeichnis mit den entsprechenden Config Dateien irgendwie einem schon existierenden TFTP Server bekannt geben, der beim net boot meiner Instanzen abgefragt wird. Oder ich müsste einen eigenen, selbst gehosteten TFTP Server eintragen können, auf den dann beim net boot verwiesen wird.

  • Für dein Vorhaben brauchst du folgendes:

    1. Cloud vLAN egal welche Version (siehe https://www.netcup.de/vserver/root-server-erweiterungen.php)

    2. VPS oder Root-Server der das Cloud vLAN zugeordent bekommt

    Dort muss dann ein DHCP Server und TFTP Server laufen

    3. Weiteren VPS oder Root-Server der ins gleiche Cloud vLAN zugeordent wird und im SCP müsste dann Netzwerkboot ausgewählt werden


    Ich weiß aber nicht ob der Server im SCP dann auch über das Cloud vLAN dann Booten kann, weil man dort mit Cloud vLAN zwei Netzwerkkarten hat?
    Die Haupt Netzwerkkarte kann man im SCP leider nicht Löschen oder Deaktivieren.

  • Zitat

    1. Cloud vLAN egal welche Version (siehe https://www.netcup.de/vserver/root-server-erweiterungen.php)

    Ah interessant, das werd ich mir mal ansehen. Werd ich sowieso brauchen. Hm, 100Mbit/s in der freien Version sind ja nicht so dolle... :rolleyes:


    Zitat


    Weiß ich aber nicht weiß ob der Server im SCP dann auch über das Cloud vLAN dann Booten kann, weil man dort mit Cloud vLAN zwei Netzwerkkarten hat

    Das ist die große Preisfrage. Nur dann würde das ja funktionieren.


    Danke jedenfalls :)

  • Hm, ich hab das jetzt grad mal ausprobiert.


    Zwei vServer Mini gebucht, dann an beiden das vLAN konfiguriert. Auf dem ersten CentOS8 + DHCP + TFTP installiert und konfiguriert, so dass beide miteinander spielen und auf dem vNet Interface lauschen. Dann das netboot image von debian auf den frisch konfigurierten TFTP ausgepackt.

    Die zweite Kiste hab ich auf dem vorinstallierten Debian 8 gelassen. vLAN per dhcp zieht sich eine IP Adresse, das geht schonmal, und mit dem TFTP Client kann ich von der zweiten Kiste die Dateien runterladen, die in der ersten Kiste auf dem TFTP liegen (also den Inhalt des netboot Paketes, was ich vorher da ausgepackt hab). Bootreihenfolge der zweiten Kiste geändert und hochgefahren.... aber in der VNC Konsole kommt nur kurz die Meldung "net1 inaccessible" und er bootet von Platte.


    Wenn man während des net-boot Vorgangs rechtzeitig Ctrl-B drückt, dann kommt man in die iPXE Konsole und kann die iPXE Kommandos aufrufen. ifconf konfiguriert z.B. ein interface und ifconf net1konfiguriert bei mir das vLAN Interface auch erfolgreich, es wird eine IP gezogen. Und wenn ich dann autoboot net1 sage, fährt das netboot image von meinem TFTP Server hoch und präsentiert das Debian Installationsmenü... läuft!


    Manuell könnte man den PXE Boot also mit ein paar Klimmzügen zum Laufen bringen. Aber schön ist das nicht. Schöner wär's, wenn ich im SCP einstellen könnte, dass die Kiste vom vLAN Interface booten soll und das dann auch passiert, wenn ich sie anschalte:/.

  • Coole Sache :thumbup:

    Kannst Netcup mal Vorschlagen das es ins SCP Eingebaut wird unter Boot Reinfolge Netzwerkkarte1, Netzwerkkarte 2 und so weiter.

    Das hab ich getan. Sie meinten aber, das wäre ein zu großer Eingriff in ihre Infrastruktur und sie wollen es nicht machen. Schade:(. Für solche Dinge muss man dann wohl doch zu den "großen" Anbietern gehen...

  • Themenfremd - aber vielleicht eine Anregung. Ich wollte mal mit Fedora spielen - dafür gab es kein Image. Wenn man sich lokal mit kvm ein qcow / raw image baut & das auf den FTP schiebt ist der Hauptaufwand geschehen.
    Vom Image installiert ist dann via SCP fix - noch ein resize partition & in 10 minuten ist der Server bereit für die Ansible playbooks zur Absicherung.


    Code
    virsh destroy fedora
    
    virsh undefine fedora
    rm /home/kvm/fedora/fedora-server-34.qcow2
    
    virt-install --name fedora --ram 4096 \  --disk path=/home/kvm/fedora/fedora-server-34.qcow2,size=4,format=qcow2 \  --vcpus 2 --os-type linux --os-variant fedora29 \  --network network:enp3s0v,model=virtio --mac 52:53:54:00:00:02 \  --graphics vnc,listen=0.0.0.0,port=5902,keymap=de --console pty,target_type=serial \  -l '/home/kvm/fedora/Fedora-Server-dvd-x86_64-34-1.2.iso' \  --initrd-inject=./kickstart.cfg --extra-args "inst.ks=file:/kickstart.cfg" --noautoconsole --wait -1
  • Das hab ich getan. Sie meinten aber, das wäre ein zu großer Eingriff in ihre Infrastruktur und sie wollen es nicht machen. Schade. Für solche Dinge muss man dann wohl doch zu den "großen" Anbietern gehen...

    Es gibt ja auch Bootloader die iPXE unterstützen - dafür musst du nur eine kleine Partition auf der Festplatte des Servers opfern.

    Ist das evtl. eine Alternative?



    Ich wollte mal mit Fedora spielen - dafür gab es kein Image.

    Du kannst doch auch ISO Images einbinden und eigene ISOs hochladen.

  • Themenfremd - aber vielleicht eine Anregung. Ich wollte mal mit Fedora spielen - dafür gab es kein Image. Wenn man sich lokal mit kvm ein qcow / raw image baut & das auf den FTP schiebt ist der Hauptaufwand geschehen.

    Für 1-2 VMs geht das ja noch. Vorrausgesetzt man kriegt qemu lokal zum Laufen um das Image zu erzeugen, was auf neueren macOS oder Windows... zumindest frickelig ist.


    Mein konkreter Anwendungsfall wäre aber ein Kubernetes Cluster mit Fedora CoreOS und der Typhoon Distribution. Da zieht man mehrere VMs, also mindestens 3 Controller und 2 Worker, hoch, und das muss dann irgendwie automatisch gehen. Entweder indem man die Ignition Datei als Boot Data angibt und das ganze über eine API (mit Terraform) machen kann, oder eben mit PXE und einem matchbox Controller. Ersteres geht hier nicht und zweiteres ja leider nur so halbwegs mit manueller Intervention für jeden Host. Wenn man dann statt 2 Workern mal 20 braucht, wird's spassig.


    Naja, der Anwendungsfall ist jetzt nicht (mehr) so dringlich. Ich wäre aber trotzdem gern auf Netcup zurückgekommen, wenn sich die Notwendigkeit für sowas bei mir mal wieder ergibt.

  • Da würde sich ja eine API zum Erstellen von Servern und CloudInit anbieten.

    Das war ja auch mal im Gespräch.

    Ja, das würde ich auch gerne nehmen ;-).


    Aber eine API ist natürlich nochmal viel aufwändiger zu realisieren und zu pflegen, als PXE Boot im VLAN praktikabel zu machen. Mit letzterem könnte Netcup mit relativ geringem Einsatz schnell eine große Wirkung erzielen… und nebenbei könnten sie ja immer noch in Ruhe an einer API feilen.

  • .. ja für Kubernetes / OpenShift gibt es elegantere Wege, sehe ich ein. Wobei ich für den PXE Node mit DHCP, HAProxy, DNS, etc.. auch ne ganze Weile gebraucht habe.


    Von RedHat gibt es jetzt einen "assisted installer" - da klickst Du dir auf der WebOberfläche online dein Cluster zusammen (clustername, domain, ..) und bekommst dann ein single iso zum anbooten der Maschinen. Wenn Du nicht airgapped arbeitest tauchen die Maschinen dann in der WebOberfläche (RedHat.com) auf & du kannst kleinere Fehlerchen (NTP nicht erreichbar) online ändern. Fand ich sehr elegant - müsste in den freien Versionen ja ggf. auch gehen?


    https://www.openshift.com/blog…ster-on-metal-and-vsphere

  • Wobei ich für den PXE Node mit DHCP, HAProxy, DNS, etc.. auch ne ganze Weile gebraucht habe.

    HAProxy? Wofür den denn?


    Ansonsten mach ich das natürlich auch mit CoreOS, da läuft der Flohzirkus an Diensten in Podman Containern. Ich hab eine entsprechende Ignition zusammengebaut, das Terraform Projekt dazu findet man hier. Da fällt eine Ignition hinten raus, mit der man z.B. lokal ein qemu Image erzeugen kann. Das kann man dann bei Netcup hochladen und in einer VM verwenden, die an ein VLAN angehängt ist. Danach kann man diese Kiste benutzen um andere VMs über PXE zu bootstrappen. Das verwende ich auch für alle möglichen anderen Container-Anwendungen, und das sind bei mir mittlerweile die meisten.


    Matchbox ist schon ne coole Sache... schade dass es nur mit Ignition so wirklich funktioniert, ich könnte es mir auch gut für andere PXE Boot Umgebungen vorstellen, Kickstart Profile o.ä.


    Von RedHat gibt es jetzt einen "assisted installer" - da klickst Du dir auf der WebOberfläche online dein Cluster zusammen (clustername, domain, ..) und bekommst dann ein single iso zum anbooten der Maschinen.

    Ja, wenn man OpenShift verwenden will, ist das schon nett. Kostet bisschen was, aber das ist dann letztendlich Kubernetes, so wie es Spass macht. Solange man es nicht selber bezahlen muss ;). Allerdings ist es leider äußerst ressourcenhungrig... und es bringt viel mit, was man nicht braucht.

    Typhoon funktioniert ähnlich, nur eben mit Fedora CoreOS. Es bietet nicht alles out of the box, ist hier und da etwas frickelig, aber dafür kostet es nichts und man kann es auch auf sparsamer dimensionierten VMs laufen lassen. Für die Control Panes reichen ja z.B. auch 2GB RAM und 2 Cores. OpenShift will da auch immer gleich 4 vCPUs und 16GB RAM haben auf jedem Knoten. Plus die 2 extra Infra Knoten sind das schon 5 dicke Maschinen, die sich aufs Budget niederschlagen.