ordyn-net

ordyn-net is the local PXE and network utility service for Ordyn.

It is enrolled through an edge node, so the Ordyn server does not require a direct network connection to it.

Responsibilities

• send Wake-on-LAN packets
• perform ping checks
• run IPAM network scans and lightweight service probes
• provide PXE boot support for OS installations

Runtime configuration

Ordyn sends signed runtime configuration to a net node when the net node connects and when relevant configuration changes.

Background probe targets are resolved from approved endpoint network interfaces. A target is included when the endpoint's effective net node matches the connected net node, the interface has an IP address, and ICMP or common protocol probing is enabled on that interface.

Net-node routing can be assigned directly to an endpoint or inherited from folder and tenant assignments. Direct endpoint assignments override folder and tenant routing.

Probe results are reported back to Ordyn and shown on endpoint interface panels. They can also create IPAM observations for the probed address.

The endpoint background probe interval controls how often reachable targets are checked. It defaults to 60 seconds and can be configured from 30 to 3,600 seconds. Unreachable targets use retry delays of 2, 4, 8, and 10 minutes. A successful probe returns the target to the configured interval.

IPAM scans

ordyn-net executes IPAM network scans for networks configured in Inventory > IPAM.

Ordyn sends the network CIDR and the network probe settings to the selected net node. A scan can include:

• ICMP reachability checks, when ICMP probing is enabled for the network
• common protocol probes, when common protocol probing is enabled for the network

Common protocol probes are passive reachability and banner checks. HTTP and HTTPS probes collect lightweight metadata such as the response server header and page title. HTTPS probes accept invalid certificates so internal devices can still be identified.

Current common protocol probes are:

Port	Protocol
21	FTP
22	SSH
23	Telnet
80	HTTP
443	HTTPS
445	SMB
631	IPP
3389	RDP
5900	VNC
8080	HTTP alternate
8443	HTTPS alternate

The net node reports scan start, positive result batches, progress, and completion while remaining available for other commands. By default, it can run two IPAM network scans at the same time.

The scan covers usable IPv4 addresses only. Network and broadcast addresses are skipped for /0 through /30; /31 and /32 include every address. Ordyn applies the configured maximum-address limit before the scan starts.

The scan results are sent back to Ordyn as IPAM observations. Ordyn reconciles those observations into the IPAM address table. Reachable hosts appear in IPAM even when they are not endpoints. If an endpoint already owns an address, its identity takes precedence while scan telemetry and discovered services remain available in IPAM.

PXE

When a device reaches iPXE through a Net node, an active waiting PXE job takes priority and starts immediately. A known endpoint without an active PXE job continues normal boot. An unknown device creates a pending PXE request and waits for a decision for up to five minutes. Approval creates a staged endpoint and starts a compatible provisioning job during the current boot. Rejection or expiration stops that boot attempt.

The Endpoints sidebar shows a shortcut while an unknown-device request is waiting. Known-endpoint normal boots and MAC conflicts are recorded in the PXE request audit without appearing in the pending queue.

See Pending PXE Requests for the decision workflow and PXE Request Audit for retained history.

OS image kinds

The current provisioning stack uses four distinct image kinds:

• pxe_bootstrap_image
  • the firmware-to-iPXE bootstrap layer
  • uploaded as:
    • one upstream ipxeboot.tar.gz archive
    • explicit BIOS and UEFI x64 bootstrap paths
• wimboot_image
  • the standalone wimboot binary
  • used by the WinPE boot-image build pipeline
• boot_image
  • the iPXE-to-operating-system boot layer
  • Windows boot images must contain:
    • wimboot
    • BCD
    • boot.sdi
    • boot.wim
  • Linux boot images must contain:
    • a Linux installer kernel
    • a Linux installer initrd
    • a distribution-signed UEFI shim
    • kernel arguments containing {{ ordyn.install_answer_file_url }}
• os_image
  • the Windows install media used later by the installer runtime

iPXE

For Ordyn PXE boot, the upstream artifacts come from the iPXE release archive published in the official v2.0.0 release:

• iPXE v2.0.0 release

• upload the provided ipxeboot.tar.gz

• BIOS PXE:

  • typically undionly.kpxe

• UEFI x64:

  • typically ipxe.efi
  • or snponly.efi if that works better on your hardware
  • for Secure Boot, typically x86_64-sb/snponly-shim.efi or x86_64-sb/ipxe-shim.efi

• wimboot

  • Download from https://ipxe.org/wimboot
  • uploaded separately
  • used by the WinPE boot path and by the WinPE build job

snponly.efi is also valid. This is a firmware and NIC compatibility choice, not an Ordyn-specific requirement.

Some UEFI firmware requests /ipxe.efi after starting the Secure Boot shim because it cannot identify the original shim filename. For these devices, enable Secure Boot firmware compatibility fallback on the PXE bootstrap image and use one of these supported file pairs in the same archive directory:

• snponly-shim.efi with snponly.efi to use the firmware SNP network driver
• ipxe-shim.efi with ipxe.efi to use iPXE's native network driver

Ordyn serves the corresponding signed second stage when the firmware uses the fallback request, preserving the driver selected by the configured shim. After changing the setting, sync the PXE bootstrap image to every affected net node. See iPXE issue #1684 for upstream tracking of the firmware behavior.

iPXE can briefly display Verification failed: Security Policy Violation while loading a kernel under Secure Boot even when the subsequent shim handoff succeeds. If the installer continues after the shim is loaded, this message is cosmetic. See iPXE issue #1653 for upstream tracking.

The ipxeboot.tar.gz archive contains the iPXE boot files. Upload it as an OS image with the PXE bootstrap kind.

After creating the image, select it on the net node detail page and choose Sync PXE bootstrap image.

Debian netboot files

For Debian PXE installation, create a Linux boot image and upload the Debian installer netboot files:

• linux as the Linux kernel
• initrd.gz as the Linux initrd
• bootnetx64.efi as the Linux Secure Boot shim

Upload all three files from the same Debian amd64 netboot installer tree. The Linux Secure Boot shim is required for every Linux boot image, including environments where Secure Boot is currently disabled. Ordyn includes the shim command in every Linux iPXE script; iPXE skips the shim download when the client uses BIOS, Secure Boot is disabled, or the selected kernel does not require it.

The distribution shim in the Linux boot image is separate from the iPXE bootstrap shim configured in DHCP. The iPXE bootstrap shim starts the signed iPXE binary. The distribution shim authorizes the handoff from iPXE to the selected Linux installer kernel.

Debian publishes these files in its netboot installer tree. See:

• Debian PXE boot install guide
• Debian preseed appendix
• iPXE UEFI Secure Boot guide
• iPXE shim command

Set the Linux boot image kernel arguments to include the install answer file URL placeholder. A typical Debian preseed boot line is:

auto=true priority=critical interface=auto netcfg/dhcp_timeout=60 preseed/url={{ ordyn.install_answer_file_url }}

Ordyn replaces {{ ordyn.install_answer_file_url }} with a temporary URL served by the assigned net node for the current PXE run. Debian also accepts url= as the short form of preseed/url=. Keep the complete kernel argument value on one line.

Linux installation jobs use PXE boot endpoint as the installation step. Configure that step with the Linux boot image, operating system, and install answer file. Do not add Install OS image; that step runs Windows installation workflows in WinPE.

A typical Linux job sequence is:

1. PXE boot endpoint
2. post-install steps that run on the newly installed agent

The running job shows generated Wait for endpoint enrollment and Wait for agent instruction readiness steps between these authored steps.

Configure each Linux operating-system entry with its distribution, release codename, and architecture. Debian PXE supports amd64, arm64, and armhf. Ordyn selects the newest approved Debian agent release that exactly matches all three values and stages that package on the assigned cache node before publishing the PXE configuration.

Linux install answer files can use these placeholders:

• {{ endpoint.id }}
• {{ endpoint.hostname }}
• {{ ordyn.endpoint_id }}
• {{ ordyn.enrollment_token }}
• {{ ordyn.edge_host }}
• {{ ordyn.agent_install_command }}

Every Linux install answer file must contain exactly one {{ ordyn.agent_install_command }} placeholder in its d-i preseed/late_command directive. Ordyn replaces it with a managed command that downloads the staged Debian package, installs it in the target system, and enrolls the agent with the session-bound token. Install answer files are limited to 1 MiB.

For example:

d-i preseed/late_command string \
    {{ ordyn.agent_install_command }}

Linux kernel arguments must be a single line without control characters and must include {{ ordyn.install_answer_file_url }}.

Debian 13 (Trixie) amd64 install answer file example

The following preseed is a starting point for a Debian 13 server installed through DHCP. It uses LVM on the first disk detected by Debian Installer and installs the standard and SSH server tasks.

Destructive partitioning

This example erases the first disk returned by list-devices disk. Disk discovery order is not a stable hardware identity and can include USB storage, SAN devices, or another unintended disk. Use this selection only when the first detected disk is the intended installation target. For systems where multiple disks may be present, replace the dynamic selection with an explicit d-i partman-auto/disk string /dev/... value after verifying the device. Ordyn does not inspect or validate the selected disk.

Debian Installer documents this dynamic selection in its advanced preseed options.

Before saving the file, replace example.internal and REPLACE_WITH_SHA512_CRYPT_HASH. Generate a SHA-512 crypt password hash with mkpasswd -m sha-512. Adapt locale, keyboard, mirror, time zone, package selection, partitioning, and boot-loader settings to the target environment.

### Localization
d-i debian-installer/locale string en_US.UTF-8
d-i keyboard-configuration/xkb-keymap select us

### Network
d-i netcfg/choose_interface select auto
d-i netcfg/hostname string {{ endpoint.hostname }}
d-i netcfg/get_domain string example.internal
d-i netcfg/wireless_wep string

### Debian mirror
d-i mirror/country string manual
d-i mirror/http/hostname string deb.debian.org
d-i mirror/http/directory string /debian
d-i mirror/http/proxy string

### Clock and time zone
d-i clock-setup/utc boolean true
d-i time/zone string UTC
d-i clock-setup/ntp boolean true

### Local user
d-i passwd/root-login boolean false
d-i passwd/user-fullname string Ordyn Administrator
d-i passwd/username string ordynadmin
d-i passwd/user-password-crypted password REPLACE_WITH_SHA512_CRYPT_HASH

### Whole-disk LVM partitioning
d-i partman/early_command string \
    debconf-set partman-auto/disk "$(list-devices disk | head -n1)"
d-i partman-auto/method string lvm
d-i partman-auto-lvm/guided_size string max
d-i partman-lvm/device_remove_lvm boolean true
d-i partman-md/device_remove_md boolean true
d-i partman-lvm/confirm boolean true
d-i partman-lvm/confirm_nooverwrite boolean true
d-i partman-auto/choose_recipe select atomic
d-i partman-partitioning/confirm_write_new_label boolean true
d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true

### Package selection
d-i apt-setup/cdrom/set-first boolean false
tasksel tasksel/first multiselect standard, ssh-server
d-i pkgsel/include string ca-certificates
d-i pkgsel/upgrade select safe-upgrade
popularity-contest popularity-contest/participate boolean false

### Boot loader and completion
d-i grub-installer/only_debian boolean true
d-i grub-installer/with_other_os boolean true
d-i grub-installer/bootdev string default
d-i finish-install/reboot_in_progress note

### Install and enroll the managed Ordyn Agent
d-i preseed/late_command string \
    {{ ordyn.agent_install_command }}

Use the Debian preseed example for additional settings and architecture-specific guidance.

Building a Windows PE image

For licensing reasons Ordyn can't ship a built Windows PE image, but it enables you to easily build it yourself.

For this purpose, install the Windows ADK with the Windows PE Extension on an endpoint running the Ordyn agent. A dedicated build endpoint is recommended to make sure the built image is trustworthy.

You may download the Windows ADK & Windows PE add-on for Windows ADK here: https://learn.microsoft.com/en-us/windows-hardware/get-started/adk-install

After installing the ADK, you can build a Windows PE Image using a Ordyn Job with the task Build WinPE boot image.

This task will directly use the Windows ADK on the endpoint, upload any required files, built the image and upload it back to the Ordyn server.

This image will contain the selected Ordyn Agent Release and allow communicating with the Windows PE environment from Ordyn and automatic enrollment of Windows endpoints deployed with this image.

PXE flow

The implemented bootstrap flow is:

1. DHCP/PXE infrastructure points the client at ordyn-net
2. ordyn-net serves the staged BIOS or UEFI bootstrap file from pxe_bootstrap_image over TFTP
3. that bootstrap reaches iPXE
4. iPXE loads the dynamic boot.ipxe script from ordyn-net
5. that script loads the boot_image assets directly from the assigned cache node over signed HTTPS URLs
6. Windows boot images start WinPE and launch the Ordyn Agent
7. Linux boot images start the Linux installer and fetch the configured install answer file from the net node

For Linux PXE jobs, Ordyn records when iPXE requests the boot script and when the installer retrieves the install answer file. The PXE configuration remains available until the session-bound enrollment token is consumed or the provisioning session expires. Consuming that token completes the provisioning session. A Wait for endpoint enrollment step only succeeds after this token has been consumed and the newly installed endpoint connects.

Linux PXE has these operational limits:

• Linux installation does not run an Ordyn preboot runtime. After the install answer file is retrieved, installer progress is not reported until the installed agent enrolls.
• Kernel, initrd, and distribution shim architecture, Debian release, preseed, mirror, and target firmware compatibility are operator-managed and are not cross-validated.
• The Debian installer must trust the TLS certificate used by the net-node install-answer-file URL.
• A Linux boot image supports one kernel, one initrd, and one distribution shim. Required firmware must be embedded in those assets or obtained by the installer.

Cache certificate trust

During PXE boot, iPXE downloads boot assets from the assigned cache node. If the cache node uses HTTPS with a certificate that is not publicly trusted by iPXE, the download can fail before the selected operating system installer starts. Use a publicly trusted certificate for cache nodes that serve PXE boot assets, or make sure the selected iPXE build trusts the certificate chain used by the cache node.

Deployment

Prerequisites:

• Docker installation
• Cosign installation
• Traefik installation

Checkout the Net deployment folder from the Ordyn compose repository:

if [ ! -d /opt/ordyn-compose/.git ]; then
  git clone --filter=blob:none --sparse https://github.com/ordyn-project/compose.git /opt/ordyn-compose
fi
cd /opt/ordyn-compose
git sparse-checkout add net

Create the environment file:

cd /opt/ordyn-compose/net
cp .env.example .env

Create the net node in Ordyn and copy the generated runtime values into .env:

The net node's public base URL must use HTTPS. Its certificate chain must be trusted by iPXE, WinPE, and any Linux installer that downloads provisioning data.

SERVICE_DOMAIN=ordyn-net.example.com
ORDYN_NET_SERVICE_CLIENT_ID=<service-client-id>
ORDYN_NET_EDGE_HOST=ordyn-edge.example.com
ORDYN_NET_HTTP_BIND=172.17.0.1:8080
ORDYN_NET_SMB_USERNAME=<generated-smb-username>
ORDYN_NET_SMB_PASSWORD=<generated-smb-password>
ORDYN_NET_INSTALL_MEDIA_CACHE_PATH=/var/lib/ordyn-net/install-media-cache
ORDYN_NET_LOG_LEVEL=info

Start the service:

docker compose pull
python3 /opt/cosign-docker-verify/verify.py

Continue with docker compose up -d only when the Net image verifies successfully and no failed verification message appears.

docker compose up -d

The container remains running while it waits for its first enrollment.

Issue a service-client enrollment token scoped to the net node. Enroll the service once:

printf '%s' '<enrollment-token>' | docker compose exec -T net ordyn-net enroll --token-stdin

After the enrollment command succeeds, the Net service begins normal operation automatically. A container restart is not required.

The Net service uses host networking because PXE, TFTP, and SMB need to be reachable directly on the local network. Public boot handoff is routed through Traefik over HTTPS. The default ORDYN_NET_HTTP_BIND=172.17.0.1:8080 is an internal listener on the Docker host bridge; Traefik terminates HTTPS and forwards to it without exposing that listener on every host interface.

The net node detail page shows connection state, version, current certificate serial, certificate expiration, enrollment timestamps, runtime state, and net-node runtime settings. Admins can enable or disable the net node from the edit dialog and revoke the current certificate. A revoked certificate requires the net node to enroll again before it can connect. See service-client certificate lifetime and renewal for planned renewal and recovery after expiration.

The container bootstraps a built-in writable SMB share automatically. The default share name is ordyn-install and the default local staging root is /var/lib/ordyn-net/install-media. The built-in Samba account defaults to uid/gid 999:998, overridable with ORDYN_NET_SMB_UID and ORDYN_NET_SMB_GID.

Install media cache

Windows installation media can be cached on each net node. The cache stores the verified, extracted install source by its SHA-256 checksum. The first use of an image is a cache miss and downloads and extracts it. Later uses of the same checksum are cache hits and reuse the prepared source without downloading or extracting it again.

Each installation session receives its own writable source directory. Changes made while preparing one Windows installation do not modify the cached source or another active installation session.

Configure the cache from the net node create or edit form:

• Enable install-media caching controls whether Windows install sources use the cache.
• Cache capacity (GiB) controls the maximum logical size of cached images. The default is 50 GiB.

When the configured capacity is exceeded, the net node removes the least recently used images after preparing the current session. Disabling the cache bypasses it for new sessions but keeps existing entries available for a later re-enable or manual clear.

The net node detail page shows:

• enabled state and configured capacity
• logical cache usage and image count
• cumulative cache hits and misses since the service started
• last activity, pruning, and clear timestamps

Users with the Update net nodes permission can select Clear cache while the net node is connected. The action requires confirmation. Active installation sessions keep their isolated source directories.

Set ORDYN_NET_INSTALL_MEDIA_CACHE_PATH to place the persistent cache on another local path. The default is /var/lib/ordyn-net/install-media-cache. Size the volume for the configured cache capacity plus a complete copy for every active session. The cache works on any writable filesystem available to the net node, including ext4, and does not require special filesystem features.

For WinPE/SMB troubleshooting, ordyn-net also supports ORDYN_NET_DEBUG_PRESERVE_INSTALL_MEDIA_SESSIONS=true. When enabled, staged install-media session directories are not cleaned up after provisioning results or PXE config refreshes, which makes it possible to inspect or manually test the SMB share contents after a failed run. This should only be enabled temporarily, because extracted Windows install media will accumulate on disk.

Install workflow execution

install_os_image executes the OS image install_steps inside the installer environment before Windows Setup starts:

1. activate installer session
2. receive the SMB UNC path and credentials for the extracted install source
3. map the SMB share and stage answer-file/bootstrap artifacts into that install source
4. execute the OS image install_steps
5. launch Windows Setup

Caveats:

• reboot/resume control flow is not supported inside the installer workflow
• exit-code mappings can classify command and script results, but they do not add installer reboot/resume control flow

The generated install-source preparation step reports separate download, extraction, and session-copy progress. Its completed result is labeled Cache hit, Cache miss, or Cache disabled so operators can see how the source was prepared.

Windows install local admin variables

Ordyn supports two system endpoint variables for Windows local-admin provisioning:

• windows.local_admin_username
• windows.local_admin_password

Current behavior:

• if windows.local_admin_username is unset, Ordyn defaults it to Administrator
• if windows.local_admin_password is unset, Ordyn generates a random password during installer-session creation and persists it back as an endpoint-level variable assignment
• if an endpoint already has a windows.local_admin_password value, Ordyn reuses that existing password on later installs

Available Windows answer file placeholders:

The shipped default Windows answer file uses these values to either:

• set the built-in Administrator password, or
• create a custom local admin user and add it to the local Administrators group

WinPE build script override

The WinPE boot-image build normally runs the standard PowerShell script shipped with the agent:

• agent/src/runtime/assets/build-winpe-boot-image.ps1

For host-local testing or troubleshooting, you can create your own custom endpoint variable definition with this exact key:

• windows.winpe.build_script_override_path

Ordyn does not create this variable for you automatically. It is just a documented convention key. If you create that custom variable definition yourself and assign a value through the Variables tabs, the WinPE build runtime will:

1. read that host-local file path on the Windows build machine
2. copy that file into the per-run build workspace as build-winpe-boot-image.ps1
3. execute the copied workspace version instead of the embedded script

If the variable does not exist, is unset, or resolves to an empty string, the embedded agent script is used.

Important constraints:

• the value must be a host-local absolute path on the Windows build endpoint
• Ordyn does not validate that path, because it only exists on the target host
• if the configured file does not exist or is unreadable on the host, the WinPE build job fails clearly
• this is a testing and troubleshooting option, not a signed artifact mechanism

WinPE install troubleshooting logging

For WinPE OS-install troubleshooting, you can create your own custom endpoint variable definition with this exact key:

• windows.winpe.debug_logging_enabled

If you create a variable override for this and assign a truthy value through the Variables tabs, the WinPE installer runtime will enable verbose local logging for that install session.

Important constraints:

• the extra logging is intended for local WinPE troubleshooting only
• when enabled, WinPE logs sensitive material locally, including the SMB password used for the install-source share mapping
• those secret-bearing logs are not reported back to ordyn-net or Ordyn, but anyone with local WinPE console or log-file access can read them
• leave this variable unset or false for normal installs

Prepared endpoints and claim rules

The intended endpoint lifecycle for PXE/install is:

1. an admin creates a prepared endpoint
2. the admin seeds one or more endpoint network interfaces with MAC addresses
3. the admin starts a normal install_os_image run for that endpoint
4. Ordyn exposes that MAC to ordyn-net as a valid PXE target for that install run

This rule is important:

• a MAC match only authorizes PXE installer admission when there is an actual started waiting OS install run for that prepared endpoint

So a prepared endpoint with a MAC address but no waiting install run is not claimable by PXE just because the MAC exists in Ordyn.

For non-PXE flows, prepared endpoints can also be claimed by a bound enrollment token created specifically for that endpoint.

Detailed boot handoff

The exact handoff from PXE into WinPE is:

1. endpoint firmware starts a PXE boot
2. DHCP tells the client to fetch the initial bootstrap file from ordyn-net
3. ordyn-net serves the staged BIOS or UEFI bootstrap binary from pxe_bootstrap_image over TFTP
4. that bootstrap reaches an iPXE environment
5. iPXE requests the dynamic boot.ipxe script from ordyn-net
6. ordyn-net matches the client by MAC address against active waiting install targets
7. the PXE configuration for that target contains:
   • the one-time boot/session metadata for that waiting install target
   • the signed cache URLs for the boot_image assets
   • the install-image metadata for the later installer phase
8. ordyn-net generates boot.ipxe on the fly from that config
9. the generated script tells iPXE where to fetch:
   • wimboot
   • BCD
   • boot.sdi
   • boot.wim
   • and forces those logical filenames with iPXE initrd -n ... so wimboot sees the canonical WinPE filenames even when the signed cache URLs are opaque UUID-based paths
10. iPXE downloads those files from cache and boots WinPE
11. WinPE starts ordyn-agent-winpe
12. ordyn-agent-winpe activates against ordyn-net and receives the installer-session payload for that specific target

That MAC match is not based on all prepared endpoints. It is based only on prepared endpoints that currently have a waiting installer session behind them.

The WinPE asset URLs are selected for the active install target and provided through boot.ipxe, which ordyn-net renders for that request.

The signed cache URLs for the WinPE assets originate in Ordyn:

1. Ordyn resolves a ready Windows boot_image asset set on the assigned cache node
2. Ordyn generates signed cache download URLs for wimboot, BCD, boot.sdi, and boot.wim
3. Ordyn sends those URLs to ordyn-net inside the signed PXE configuration
4. ordyn-net uses that trusted payload to render boot.ipxe
5. iPXE downloads the WinPE assets from cache using those signed URLs

iPXE validates the HTTPS certificate presented by the cache node before downloading those assets. Certificates from private or internal certificate authorities are commonly not trusted by iPXE builds, which can make the boot fail at the cache download step. Use a publicly trusted cache-node certificate for PXE boot paths unless your iPXE build is prepared to trust your private certificate chain.

For the optional ordyn-net-base-url.txt handoff file, ordyn-net injects it by plain filename rather than Windows/System32/.... wimboot places injected files in the expected WinPE system location, and startnet.cmd reads %SystemRoot%\System32\ordyn-net-base-url.txt from there after boot.

So the download authorization for the WinPE asset fetch itself is carried by the signed cache URLs.

DHCP requirements

Ordyn does not manage DHCP. You must configure your DHCP server to point PXE clients at ordyn-net.

At minimum DHCP must provide:

• next-server / TFTP server address
• boot filename for BIOS clients
• boot filename for UEFI x64 clients

Those filenames must exactly match the configured bootstrap paths from the selected pxe_bootstrap_image.

Typical filenames are:

• BIOS: undionly.kpxe
• UEFI x64: ipxe.efi

An example isc-dhcpd style configuration looks like:

next-server 192.168.1.10;

if exists user-class and option user-class = "iPXE" {
  filename "";
} elsif option arch = 00:07 or option arch = 00:09 {
  filename "ipxe.efi";
} else {
  filename "undionly.kpxe";
}

Notes:

• 192.168.1.10 should be the LAN address of your ordyn-net host
• the exact UEFI architecture matching rules depend on your DHCP server and environment
• if you choose snponly.efi instead of ipxe.efi, DHCP must hand out snponly.efi instead
• DHCP must hand out the exact uploaded filename, not a derived alias

If your DHCP server supports separate policies for BIOS and UEFI, that is the simplest model for Ordyn.

Security note

The PXE boot path does not give iPXE a way to verify Ordyn-generated signatures on the boot_image asset set during firmware boot.

The security model is:

• Ordyn signs the configuration that tells ordyn-net which boot assets to expose
• ordyn-net verifies and serves that signed configuration
• iPXE then downloads the referenced WinPE boot assets from the assigned cache node over signed Ordyn URLs

However, iPXE itself does not verify an Ordyn signature on wimboot, BCD, boot.sdi, or boot.wim before executing the boot chain.

That means the integrity of this process relies on:

• trust in the local provisioning network
• trust in the assigned cache node and signed URL issuance
• integrity of the files and cache distribution path

:::