PXE Algemeen

Uit Wiki Facet
Naar navigatie springenNaar zoeken springen

Generiek boot proces

Het boot proces van de BCLD bestaat uit het laden van de kernel en een initrd image (Linux machine).

Voor de BCLD geldt dat het initrd image tevens het root filesystem is. Een initrd wordt (vaak) voornamelijk gebruikt om het uiteindelijke root filesystem te vinden. Hierbij moet u denken aan het laden van de benodigde drivers om de opslag te vinden of het initialiseren/mounten van filesystems met een complexere layout zoals bijv. software RAID of BTRFS volumes die meerdere schijven omvatten.

Gezien de BCLD helemaal uit RAM draait, wordt de initrd tevens als root filesystem gebruikt. Dit verkleint de complexiteit.

In de laatste images zit nog maar één archief, wat direct het root filesystem is. Het is belangrijk dat de kernel en initrd geladen worden en de juiste parameters mee gegeven worden.

Let op: Vergeet niet de juiste afname URL mee te geven aan de BCLD. Voor de online afname-omgeving is dat https://afname.facet.onl/facet-afname. Voor de offline afname-omgeving is dat https://IP-AdresFAO/facet-afname.

PXE boot

Er zijn vele bootloaders die linux kernels kunnen laden en starten. Voor PXE boot denken wij dat iPXE (ipxe.org) de makkelijkste is, gezien er voor de syntax veel documentatie op hun website te vinden is.

Daarbij geeft iPXE mogelijkheden om de images o.a. van een webserver binnen te halen en laat deze ook de voortgang van de download zien in percentages. Dit geeft een duidelijk beeld van hoelang het duurt om het bestand binnen te halen.

Om via PXE te booten is er ondersteuning nodig van de DHCP server, met name voor de DHCP opties 66 en 67. Optie 66 geeft het adres van de TFTP server aan, optie 67 geeft het bestand aan welke geladen dient te worden.

Nu is er met iPXE een zogenaamd chainloading probleem. Na het laden van de iPXE boot loader zal deze wederom een DHCP request doen. De DHCP server moet dit af kunnen vangen, anders blijft iPXE zich zelf laden:

1. iPXE laden.
2. Doet een nieuwe DHCP request.
3. Ontvangt via optie 67 weer dat iPXE geladen moet worden.
4. Download zichzelf opnieuw en start dan.

Met DHCP policies kunt u dit ondervangen. De DHCP server kijkt dan of de request van een normale, niet iPXE client komt. Wijzen optie 66 en 67 naar de iPXE loader, maar komen als de request van een iPXE cliënt af, dan wijzen we deze naar het benodigde configuratie bestand.

Indien u met zowel BIOS als EFI systemen te maken heeft wordt het iets complexer. Een bootloader voor BIOS heeft namelijk een andere binaire vorm dan een bootlader voor een EFI systeem.

Door middel van policies wordt gekeken of de DHCP request afkomstig is van een iPXE client. Indien dit het geval is, verwijzen we naar het configuratie bestand voor iPXE. Indien de request niet afkomstig is van een iPXE client, testen we of de request afkomt van een BIOS of een EFI systeem en verwijzen naar de juiste iPXE loader voor het gebruikte systeem. Deze laadt iPXE en doet vervolgens weer een DHCP request.

Deze request is dan afkomstig van een iPXE client en de DHCP server verwijst in dat geval optie 67 naar de configuratie en indien nodig optie 66 ook. Optie 67 kan in dit geval een http URL bevatten bijvoorbeeld http://10.0.0.1/ipxe-config.txt en optie 66 is dan niet nodig. Indien het alleen een bestandsnaam bevat zal optie 66 wel nodig zijn. Deze dient dan te verwijzen naar de TFTP server waarop het genoemde bestand in optie 67 te vinden is.

Indien uw omgeving alleen EFI of BIOS systemen bevat kunt u deze laatste test overslaan. U moet in dat geval altijd naar of de EFI of de BIOS versie verwijzen. Wij raden u aan de test, indien mogelijk, altijd te implementeren. Het is robuuster voor het geval er toch een keer een ander type systeem in het netwerk staat.



Voorbeeld configuratie MS DHCP server

Voor de policies is minimaal een 2012 server nodig. Voor 2012 zijn niet alle benodigde opties in Microsoft DHCP beschikbaar voor het aanmaken van de policies. Voor het testen van de client is een zogenaamde ‘User Class’ nodig. Voor het testen of het EFI of BIOS betreft een ‘Vendor Class’. Vendor classes kunnen pas aangemaakt worden sinds 2012. Zonder vendor classes kunt u geen onderscheid maken op basis van EFI of BIOS systemen.


== Aanmaken DHCP classes ==
Voor het aanmaken van de classes klikt u rechts op het ‘IPv4’ gedeelte in de DHCP configuratie console. Hier ziet u dan de opties ‘Define User Classes’ en ‘Define Vendor Classes’. We maken eerst de ‘User Class’ aan.

1. Rechtsklik op ‘IPv4’ en kies voor ‘Define User Classes’.
2. Klik op Add in het venster dat verschijnt.
3. Vul bij ‘Display name’ en bij ‘Description’ een herkenbare naam in. Wij gebruiken hiervoor ‘iPXE’ en ‘iPXE clients’.
4. In het veld daaronder typt u in het ‘ASCII’ deel ‘iPXE’

Als deze is aangemaakt moet u nog 2 vendor classes aanmaken.

1. Rechtsklik hiervoor weer op IPv4 en kies nu voor ‘Define Vendor Classes’.
2. Klik op ‘Add’ in het venster dat verschijnt.
3. Doe dit 2 keer en vul de benodigde velden in.

We hebben nu de classes beschikbaar die nodig zijn voor de policies.


== Aanmaken policies iPXE ==

De policies kunnen nu aangemaakt worden binnen de scope of op globaal niveau. Wat voor u het handigste is, hangt af van uw inrichting. In dit voorbeeld maken wij ze aan onder de scope zelf.

1. Onder de scope configuratie in de DHCP console ziet u policies staan. Rechtsklik deze en kies voor ‘New policy’. Geef de policy een logische naam, zoals bijvoorbeeld ‘iPXE Config’ en klik op ‘Next’.
2. U moet nu de condities voor de policy opgeven. Klik op ‘Add’. Zet ‘Criteria’ op ‘User Class’ en de ‘Operator’ op ‘Equals’. Bij ‘Value’ kiest u voor ‘iPXE’. U klikt op ‘Add’ en daarna op ‘OK’. Klik op ‘Next’ om naar het volgende venster te gaan.
3. Het is normaliter niet nodig om een separaat deel van de range uit de scope te gebruiken, zet derhalve bij de ‘Do you want to configure an IP address range for the policy’ op ‘No’ en klik op ‘Next’.
4. Nu kunt u de opties opgeven die nodig zijn voor deze policy. Deze zijn afhankelijk van waar u de configuratie wilt laden. In dit voorbeeld ga wij er van uit dat u een webserver heeft staan met IP adres 10.0.0.1 en de configuratie in de root van deze webserver te vinden is met de bestandsnaam ‘ipxe.php’. Zet derhalve optie ‘067 Bootfile Name’ aan en verwijs deze naar ‘http://10.0.0.1/ipxe.php’ en klik daarna op ‘Next’ en dan op ‘Finish’. Het is belangrijk dat deze policy bovenaan blijft staan.


Als de policies om te testen of het een EFI of BIOS systeem betreft, erboven komen te staan blijft er verwezen worden naar de respectievelijke iPXE versies. Gezien die tests het ook gewoon doen als de iPXE client boot (die stuurt ook mee of het EFI of BIOS systeem betreft).


== BIOS of EFI ==

1. Rechtsklik weer op ‘Policies’ onder de DHCP scope en kies voor ‘New policy’. Dit dient 2x te gebeuren, 1x voor de BIOS en 1x voor de EFI systemen.
2. Geef de policy een herkenbare naam, bijv. ‘BIOS’ of ‘EFI’ en klik op ‘Next’.
3. In het volgende scherm dienen de condities weer ingevoerd te worden, klik op ‘Add’, zet ‘Criteria’ op ‘Vendor Class’ en ‘Operator’ op ‘Equals’. Selecteer bij ‘Value’ vervolgens of de BIOS of EFI class die eerder aangemaakt zijn. Afhankelijk van of u de BIOS of EFI policy aan het aanmaken bent. Zet het vinkje bij ‘Append wildcard(*)’. Klik daarna op ‘Add’. Dit vinkje is belangrijk, er staat achter de opgegeven waardes vaak nog meer informatie en de policy matcht niet als de wildcard er niet achter staat!
4. Klik op ‘Next’, beantwoord de vraag ‘Do you want to configure an IP address range for the policy’ weer met ‘No’ en klik op ‘Next’.
5. Stel wederom opties 66 en 67 in. In ons voorbeeld hebben we een TFTP server welke op IP adres 10.0.0.1 draait. Hierop staan 2 iPXE binaries, 1 voor BIOS met de naam ‘undionly.kpxe’ en 1 voor EFI met de naam ‘ipxe-x86_64.efi’. In beide gevallen stelt u optie ‘066 Boot Server Host Name’ in op ‘10.0.0.1’ (IP adres van de TFTP server). U stelt optie ‘067 Bootfile Name’ in op ‘undionly.kpxe’ voor de BIOS policy en op ‘ipxe-x86_64.efi’ voor de EFI policy. Klik op ‘Next’ en ‘Finish’.

Als het goed is ziet u onder ‘Policies’, na het aanmaken van zowel de BIOS als EFI policies en de eerdere iPXE policy.

Let op dat de iPXE policy bovenaan staat, deze moet als eerste getest worden!

Bij ‘Scope Options’ staan de ingestelde gegevens.

Voorbeeld configuratiebestand iPXE

We gaan er hier vanuit dat de kernel (vmlinuz bestand) en initrd (initrd bestand) in de root van de webserver staan en dus te downloaden zijn via http://10.0.0.1/vmlinuz en http://10.0.0.1/initrd. Dit is met een browser in het netwerk te testen.

#!ipxe

kernel http://10.0.0.1/vmlinuz initrd=initrd rhgb bcld.url=http://afname.url

initrd http://10.0.0.1/initrd

boot


Dit dient in een tekstbestand te staan wat als DHCP optie 67 meegegeven wordt in het iPXE client. In het voorbeeld betrof het http://10.0.0.1/ipxe.php.

Op de kernel regel worden enkele parameters meegegeven aan de kernel. initrd=initrd vertelt de kernel de bestandsnaam van de initrd. Het stuk achter de = dient overeen te komen met de bestandsnaam van de initrd. Echter bcld.url vertelt het systeem wat de afname URL is. Deze kunt u verwijzen naar een interne FAO, de URL van uw test omgeving of welke andere URL dan ook.


== In een bestaande WDS/SCCM omgeving ==

Als u dit opzet in een bestaande WDS of SCCM omgeving loopt u waarschijnlijk tegen problemen aan. Dit komt omdat de WDS of SCCM server ook reageert op de DHCP requests en deze verwijzen naar hun eigen boot images.

Er zijn 2 manieren om dit op te lossen afhankelijk van uw inrichting.

Optie 1: Indien WDS of SCCM in hetzelfde VLAN staan moet u de configuratie aanpassen

Voor WDS kan het reageren op DHCP requests uitgezet worden.
1. Open hiervoor de WDS management console.
2. Rechtsklik op de server.
3. Kies voor ‘Properties’.
4. Ga naar het ‘PXE Response’ tabblad en zet de ‘PXE Response Policy’ op ‘Do not respond to any client computers’. Als alternatief kunt u de ‘PXE Response Delay’ instellen op 10 seconden, WDS reageert dan te laat.

In het SCCM geval kan de response niet uitgeschakeld worden. Als u dit doet functioneren andere delen van SCCM ook niet meer en valt er niet meer door te booten naar een werkende SCCM.

Om die reden zetten we bij SCCM altijd de response delay veel hoger.
1. Ga in de System Center Configuration Manager client naar ‘Administration | Distribution Points’.
2. Rechtsklik op de server in het rechter deel, kies voor ‘Properties’.
3. Ga naar het ‘PXE’ tabblad. Zet de ‘Specify the PXE server response delay (seconds)’ hier op 10. De server reageert dan te laat waardoor het boot proces iPXE al heeft opgestart.

Optie 2: WDS of SCCM in een ander VLAN In dit geval maakt u waarschijnlijk gebruik van de IP helpers in de router voor de DHCP requests. Deze worden niet alleen naar de DHCP server geleid, maar ook naar de WDS of SCCM server. U hoeft in dit geval niets aan te passen in de WDS of SCCM omgeving. U dient wel de IP adres(sen) van de WDS en/of SCCM servers uit de helpers te halen zodat de requests alleen naar de DHCP server(s) zelf gaan.

Hierdoor zal de cliënt geen reactie ontvangen van de WDS of SCCM server op de DHCP request.


== WDS of SCCM booten ==

U wilt uiteraard nog wel kunnen booten naar de WDS of SCCM omgeving. U kunt booten vanuit iPXE naar deze omgevingen. De configuratie is anders afhankelijk van WDS of SCCM (ze gebruiken andere loaders).

Voor WDS kunt u de volgende iPXE configuratie gebruiken:

#!ipxe

set netX/next-server 10.234.234.12
iseq ${platform} efi && imgexec tftp://${netX/nextserver}/
boot\\x64\\wdsmgfw.efi || imgexec tftp://${netX/nextserver}/
boot\\x86\\wdsnbp.com
boot

We gaan er hier vanuit dat 10.234.234.12 uw WDS server is.

Voor SCCM kunt u de volgende iPXE configuratie gebruiken:

#!ipxe
set netX/next-server 10.234.234.13
iseq ${platform} efi && imgexec tftp://${netX/nextserver}/
smsboot\\x64\\wdsmgfw.efi || imgexec tftp://${netX/nextserver}/
smsboot\\x86\\wdsnbp.com
boot

10.234.234.13 is in dit geval het adres van de SCCM server.

In beide voorbeelden vindt er in iPXE een test plaats die controleert of het een BIOS of EFI boot betreft. In een BIOS boot probeert het wdsnbp.com te laden voor WDS en SCCM. In een EFI boot wdsmgfw.efi. Zoals u kunt zien zijn de paden op de TFTP server echter aanzienlijk anders tussen de twee producten. De Microsoft TFTP server kan niet met de gebruikelijke forward slashes overweg (in ieder geval niet zonder registry modificatie) en de backslashes moeten geëscapet worden in de iPXE configuratie.

Hieronder een basis opzet van menu’s. Deze iPXE voorbeelden booten direct naar de genoemde voorbeelden en laten geen menu zien.

== Voorbeeld configuratie met menu’s == Onderstaand is een voorbeeld configuratie voor iPXE, waarin de BCLD geboot kan worden en doorgegaan kan worden naar SCCM.

#!ipxe set menu-timeout 10000
set submenu-timeout ${menu-timeout}

:start
menu iPXE Boot Menu
item --gap -- ------------------- BCLD Official
Releases -------------------

item --key b bcldstable Latest Stable BCLD

item --gap -- ------------------ Alternative Boot
Options ------------------

item --key r reboot Reboot System
item --key x exit Exit iPXE
item --key s shell Drop to iPXE Shell
item --gap -- ----------------------- Custom Entries
-----------------------
item --key w SCCM SCCM

choose --default WDS --timeout 10000 selected || reboot

goto ${selected}

:bcldstable
kernel http://10.0.0.1/vmlinuz initrd=initrd rhgb bcld.url=http://afname.url
initrd http://10.0.0.1/initrd
boot

:reboot
reboot
goto start

:exit
exit
goto start

:shell
echo Type 'exit' to get back to the menushell
shell
goto start

:SCCM
set netX/next-server 10.234.234.13
iseq ${platform} efi && imgexec tftp://${netX/nextserver}/
smsboot\\x64\\wdsmgfw.efi || imgexec tftp://${netX/nextserver}/
smsboot\\x86\\wdsnbp.com
boot

goto start

Als u niets doet start na 10 seconden vanzelf de SCCM entry op. Er zijn tevens hotkeys te gebruiken in plaats van de cursor pijltjes + enter om een entry te selecteren. In het voorbeeld gaat het om ‘b’ voor de BCLD, ‘r’ voor reboot, ‘x’ voor exit, ‘s’ voor (iPXE) shell en ‘w’ voor SCCM.