Add proxy-DHCP support #73
Conversation
|
Does this accomplish the same as https://github.com/samdbmg/dhcp-netboot.xyz ? EDIT Gave it a test and got this error from docker compose: Fixed by adding this to compose.yaml: cap_add:
- NET_ADMINHowever spinning up a proxmox VM gives |
Yes and no. Yes - it offers up proxyDHCP with netboot.xyz files via dnsmasq No:
this PR supports more
Thanks for the feedback on the I was also missing the required networking configuration. The simplest way to do this is I have added a commit that documents these requirements. For reference my minimal docker-compose.yml based off the example from this repo is: services:
netbootxyz:
build: .
container_name: netbootxyz
environment:
- MENU_VERSION=2.0.82 # optional
- NGINX_PORT=80 # optional
- WEB_APP_PORT=3000 # optional
- DHCP_RANGE_START=192.168.0.1 # optional, enables DHCP Proxy mode. set to your network's DHCP range first IP.
# volumes:
# - /path/to/config:/config # optional
# - /path/to/assets:/assets # optional
ports:
- 3000:3000 # optional, destination should match ${WEB_APP_PORT} variable above.
- 69:69/udp
- 8080:80 # optional, destination should match ${NGINX_PORT} variable above.
restart: unless-stopped
cap_add:
- NET_ADMIN # required for DHCP Proxy mode.
network_mode: hostAs long as the machines/vms are on the same network proxydhcp responses should be offered up. |
|
Thanks, adding When I boot up the VM now I do see some activity in the docker logs, but nothing happens on the VM side: |
|
The error cited is saying that it's seeing a DHCP request in a range that the netboot.xyz proxydhcp dnsmasq is not configured to handle. The most likely cause is that It should be noted that i retained the project pattern of not overwriting generated config, so if |
as an aside, this is why macvlan would be preferable in some cases. it's likely you have something on port 80 or 3000 on the host already. macvlan would give the container its own mac address and functionally let it sit on the network as if it was directly connected (to get it's own IP and interact with broadcast messages). it is more involved to set up and environment specific so i think out of scope for the minimum functional examples presented in the docs here |
|
Thanks, deleting ./config/ and checking the range fixed it. Also had to go to my Proxmox VM BIOS in |
|
this looks promising |
|
@antonym an chance to have this reviewed/merged? |
|
Yeah, I looked at it a few weeks ago and it looks good, there were one or two things I wanted to bring up, but they slip my mind for the moment. I'll try and look at it once more and provide some feedback. |
|
This is great stuff. +1 to this. Hoping you get a chance to review this soon. In the meantime, I have attempted to get it working in my own setup after passing thru a sea of failed config attempts. In the process, I found a number of things that didn't quite work right or make sense... but those may well be just a result of "being new to DHCP". It ultimately did boot, but not from my LAN (after the initial Here's what I found: The default value of I assume the command is meant to retrieve something like
me@homelab-pi:~/homelab
$ ./external/start-docker-netbootxyz.sh
✔ Container netbootxyz Recreated
Attaching to netbootxyz
netbootxyz | 127.0.1.1 # hostname -iInspecting from outside the container yields similar results me@homelab-pi:~/homelab
$ hostname -i
127.0.1.1
me@homelab-pi:~/homelab
$ hostname -I | tr ' ' '\n'
192.168.11.1
172.22.0.1
172.21.0.1
172.17.0.1
172.19.0.1
172.20.0.1
172.23.0.1
172.18.0.1The Altho the manpage suggests this does not matter
I don't know enough about this setup to tell either way.
I know that version is quite old. But it was in the sample file and uncommented. (Not specifying The machine I am attempting to PXE boot really wants some files from I could find no resolution w/in
Quick fixes I can see are either of these:
But a "proper" resolution is probably going to be resolving something from that first list. |
|
I have resolved the merge conflict in this branch. It should be noted that a potential major source of indirection with this container is https://github.com/netbootxyz/docker-netbootxyz/blob/master/root/init.sh#L13 - this pattern (which I have copied in this branch for dnsmasq) checks to see if In my opinion that is a trap for users, as those files are generated from ENV variables that are able to be changed container runtime, but the files are only generated if they do not already exist. Meaning users have to manually delete the files or volume that houses them to get a refreshed config which matches the ENV the container was invoked with. I'd suggest this is non-obvious UX and could lead users to going down unexpected paths trying to debug things assuming that changing the ENV was enough. I think having the files generated with the current ENV values on each run would be preferable, but I didn't design the container and don't understand the use-case that design decision was intended to address! @david-sharer It's difficult to follow and understand your situation (the dump of info is fine but it's not the same as being at the console and able to poke it), however:
Good catch,
Per the cited man page this isn't an issue, it certainly hasn't been a problem in my testing or usage (dnsmasq seems to do a fine job of working it out in my varied environments)
I don't know anything about this, the value was in that file already but I have bumped the example MENU_VERSION in this branch.
My memory is hazy on this. I do think it's something around However 192.168.0.1 is coming from somewhere, indicating that someone in your network is responding with that and likely a cause of your issues at this point. If I'm not keen to change the flow of things around |
|
Wow that was way faster of a reply than I was expecting.
Excellent. Just making sure.
Yeah I think it's just very old behavior. Just calling it out. Thanks for updating the example!
Yes. Even in the latest I think the potential fault in Immediate (naive) thoughts on that:
I have captured these packets previously thru It did appear that the router was producing
Yes. I don't think it's the responsibility of this PR or of the I think ultimately this would have to be resolved upstream
Here's screenshots from the network dump, tho I don't expect you to do much with this.
|
This PR adds proxy-DHCP support:
What is proxy-DHCP?
Proxy-DHCP allows a secondary DHCP server to provide boot configuration (such as next-server and boot file) while the primary DHCP server continues to assign IP addresses. This is useful in environments where modifying the primary DHCP server is not feasible, or the primary DHCP server doesn't have a static IP.
How proxy-DHCP works
When a client sends out a DHCP request, the proxy-DHCP service will respond with boot options such as the next-server and boot filename, while leaving the IP address assignment to the primary DHCP server. This allows the client to chainload iPXE without requiring modifications to the existing DHCP server.
Pairs well with netboot.xyz PR #953
This PR works alongside #953, which adds support for proxy-DHCP in the iPXE menus, allowing users to press a key to select the proxy offer and load netboot.xyz from there.
How to use it
Set the
DHCP_RANGE_STARTenvironment variable to the first IP in your network’s DHCP range. This will enable the optional proxy-DHCP mode. When enabled, dnsmasq calculates the range and handles proxy requests automatically.Edit: Ensure the docker container is on the same network e.g.
--network host(or ipvlan, macvlan) so that it can receive broadcast DHCP messages and respond with its own broadcasts.Moved dnsmasq config to a file
To enable this functionality cleanly, the dnsmasq configuration has been moved into a config file, allowing for different config based on the presence of env
DHCP_RANGE_STARTand substitution of some values via envsubst.Proxy-DHCP behaviour
When
DHCP_RANGE_STARTis set, the provided dnsmasq will behave in proxy-DHCP mode (in addition to tftp), with the following key sections in the configuration:This configuration sets up the proxy-DHCP to respond only to PXE clients (non-iPXE), serving the appropriate bootloaders for BIOS, UEFI, ARM64, and Raspberry Pi clients, while iPXE clients will be served an HTTP boot script.
Dynamic IP handling with envsubst
The
CONTAINER_IPis dynamically injected into the configuration usingenvsubst, after retrieving the container’s IP address at runtime from the container itself viainit.sh. This ensures that the correct container next-server IP is set in the configuration.User experience
Users can start the container with the relevant environment variables set (
DHCP_RANGE_STARTand optionally others). When a DHCP request is detected, this container sends a proxy offer with the next-server and boot file. With PR #953, netboot.xyz will detect the proxy next-server, allowing users to presspto boot from the proxy-DHCP server.As it depends on a new env var being added
DHCP_RANGE_START, this should be backwards compatible.Docs & resources:
https://www.ipxe.org/appnote/proxydhcp
https://gist.github.com/NiKiZe/5c181471b96ac37a069af0a76688944d
https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html