Pxehost is much less featureful than Bootimus, no dashboard, and only supports netboot.xyz.
I am curious how Bootimus got udp broadcast to work via Docker on arm macOS. I could not figure that out and it’s why I released pxehost as a cross platform binary.
We need a good ISO to set up new hosts to run firecracker VMs in k3s. That would be a killer homelab tool. Tooling to make custom ISOs. And some Kairos/Talos immutable image update style tooling would be great too.
The dream is to boot via PXE once per host to setup secure k8s nodes, using just Ethernet cord, ISP router, and a windows laptop or an iPhone.
> I am curious how Bootimus got udp broadcast to work via Docker on arm macOS. I could not figure that out and it’s why I released pxehost as a cross platform binary.
Going by the Github, I'd be that it was Claude who figured it out. Which yeah, checks out.
Has anyone else noticed how readily identifiable AI generated text is? This is a very cool project, and I suppose it's hard to know for sure, but everything about the site describing the project "feels" AI generated to me.
I do not say this to detract from the value of the project or its very interesting nature, by the way. Just an orthogonal observation.
Definitely AI generated. But the project is interesting, because that space felt a bit dry to me. netboot.xyz and iventoy are cool, but for most basic use cases I always felt these things could be yet further simplified. So I guess I'll go and review the code when I find some time.
EDIT:
Found the disclosure in the repo:
>I've used Claude CLI to help with some parts of this project - mostly making the web UI pretty, as I'm NOT a frontend developer. I also used it to generate the docs, but I review them manually - no automatically-generated AI code goes into the project without review from myself.
Since when is disclosure a "should"? Nobody asks if you were stark-naked whilst coding it, high on drugs, having a bad day or any other arbitrary question.
Disclosure is something the author volunteered, its his freedom to do with HIS creation as he wishes.
There is a note on there around AI coding which gives a little more hope. But what i would expect from such a component is also a clear indication of how its security is being vetter, tested and attempted to be assured.
When using such a server, its of critical importance its secure. If someone can enter it, they can change your images, knock over a machine and get it to boot a rogue image etc.
Id be interested what thread models are taken into account. If there is any fuzzing.
Perhaps a clear list of all the third party packages it pulls in and assessment of those packages.
It sounds like a lot but actually AI can help set up a lot of tooling around this stuff to make it more managable to do a lot of thorough testing / vetting of things.
I do think its also interesting project, and ofc it might be somehting that matures over time in this regard. (i am super biassed about security also as its my domain and i've litterally seen colleagues root servers which hosted images for entire infras of companies. thats a scary vector. if you can tamper with 1 PXE boot you can overwrite firmware.
(this is not saying anything about secure boot ofc, my experiences with PXE predate that being actively deployed)
Nice, although if you already are running your own DHCP and web server, it's very easy to add a TFTP server and configure everything to serve whatever you want. So it does feel a bit like reinventing the wheel to me.
A PXE boot server has many uses. The project already mentions using it for tools like GParted, Memtest86+ and so on. Booting live OS or OS installers via netboot.xyz is also great. But you can automate things even further; at a previous job (~18 years ago) I used PXE to serve a debian installer image with a preseed file to add user accounts with SSH keys, apt install all the dependencies, and install local binaries to get machines up and running useful stuff without needing to do any manual configuration. Nowadays you'd probably just have it do a minimal install + add just an SSH key, and then let another tool like Ansible take over the rest of the provisioning.
> it's very easy to add a TFTP server and configure everything to serve whatever you want.
In your own homelab or in a small company, sure.
But the nice thing about proxyDHCP is that in a larger company, if the network engineering team hands you a subnet to play in that has DHCP forwarding configured in the router already, and you want to do PXE in it, you can just deploy your own proxyDHCP server without any extra red tape.
Or in my case, I just don't like to have configuration for a single service scattered around my network devices if I can avoid it.
Cool project! I had mistral vibecode me something similar (split into two services and run via docker compose) just a few weeks ago! I still have dome nitpicks with the result, maybe I'll switch my stack over to your solution!
PXE is one of those easy to take for granted without appreciation for how much of a PIA it is to get working sometimes.
I run a homelab PXE & NFSboot, so no hard drives in the homelab. Works great until I do something to bork it up.
I have been fine tuning setup scripts to automatically get things going for scratch, but I always find there was one more hack I didn't automate last time.
Last year I released my version of this: https://pxehost.com
Pxehost is much less featureful than Bootimus, no dashboard, and only supports netboot.xyz.
I am curious how Bootimus got udp broadcast to work via Docker on arm macOS. I could not figure that out and it’s why I released pxehost as a cross platform binary.
We need a good ISO to set up new hosts to run firecracker VMs in k3s. That would be a killer homelab tool. Tooling to make custom ISOs. And some Kairos/Talos immutable image update style tooling would be great too.
The dream is to boot via PXE once per host to setup secure k8s nodes, using just Ethernet cord, ISP router, and a windows laptop or an iPhone.
> I am curious how Bootimus got udp broadcast to work via Docker on arm macOS. I could not figure that out and it’s why I released pxehost as a cross platform binary.
Going by the Github, I'd be that it was Claude who figured it out. Which yeah, checks out.
NetBoot.xyz is one of the most sketch projects on the internet, yeah nope nope nope.
Even if self hosted?
https://netboot.xyz/docs/selfhosting/
Has anyone else noticed how readily identifiable AI generated text is? This is a very cool project, and I suppose it's hard to know for sure, but everything about the site describing the project "feels" AI generated to me.
I do not say this to detract from the value of the project or its very interesting nature, by the way. Just an orthogonal observation.
Definitely AI generated. But the project is interesting, because that space felt a bit dry to me. netboot.xyz and iventoy are cool, but for most basic use cases I always felt these things could be yet further simplified. So I guess I'll go and review the code when I find some time.
EDIT: Found the disclosure in the repo: >I've used Claude CLI to help with some parts of this project - mostly making the web UI pretty, as I'm NOT a frontend developer. I also used it to generate the docs, but I review them manually - no automatically-generated AI code goes into the project without review from myself.
I guess that's fair.
Yep, not everyone takes AI's output, and uses it verbatim. Sometimes it feels like everyone gets painted with the same brush.
Yes, that's why I think responsible people should truthfully disclose.
Since when is disclosure a "should"? Nobody asks if you were stark-naked whilst coding it, high on drugs, having a bad day or any other arbitrary question.
Disclosure is something the author volunteered, its his freedom to do with HIS creation as he wishes.
Get off your soapbox.
Moving forward, perhaps I should state that, "I was fully clothed while preparing this PR."
What a waste of good clothes. I at least vibe code in a pair raggy pair of combat shorts and an xtra-large tshirt.
There is a note on there around AI coding which gives a little more hope. But what i would expect from such a component is also a clear indication of how its security is being vetter, tested and attempted to be assured.
When using such a server, its of critical importance its secure. If someone can enter it, they can change your images, knock over a machine and get it to boot a rogue image etc.
Id be interested what thread models are taken into account. If there is any fuzzing.
Perhaps a clear list of all the third party packages it pulls in and assessment of those packages.
It sounds like a lot but actually AI can help set up a lot of tooling around this stuff to make it more managable to do a lot of thorough testing / vetting of things.
I do think its also interesting project, and ofc it might be somehting that matures over time in this regard. (i am super biassed about security also as its my domain and i've litterally seen colleagues root servers which hosted images for entire infras of companies. thats a scary vector. if you can tamper with 1 PXE boot you can overwrite firmware.
(this is not saying anything about secure boot ofc, my experiences with PXE predate that being actively deployed)
It's the staccato sentences
Yes, I wonder why the models do that so readily.
Yes, this observation has been expressed like a million times here.
Nice, although if you already are running your own DHCP and web server, it's very easy to add a TFTP server and configure everything to serve whatever you want. So it does feel a bit like reinventing the wheel to me.
A PXE boot server has many uses. The project already mentions using it for tools like GParted, Memtest86+ and so on. Booting live OS or OS installers via netboot.xyz is also great. But you can automate things even further; at a previous job (~18 years ago) I used PXE to serve a debian installer image with a preseed file to add user accounts with SSH keys, apt install all the dependencies, and install local binaries to get machines up and running useful stuff without needing to do any manual configuration. Nowadays you'd probably just have it do a minimal install + add just an SSH key, and then let another tool like Ansible take over the rest of the provisioning.
> it's very easy to add a TFTP server and configure everything to serve whatever you want.
In your own homelab or in a small company, sure.
But the nice thing about proxyDHCP is that in a larger company, if the network engineering team hands you a subnet to play in that has DHCP forwarding configured in the router already, and you want to do PXE in it, you can just deploy your own proxyDHCP server without any extra red tape.
Or in my case, I just don't like to have configuration for a single service scattered around my network devices if I can avoid it.
Alternatives to Ansible could be Nix / nixos, or bootc.
There's also https://netboot.xyz which is quite cool too.
Yeah, this project incorporates netboot.xyz apparently
It’s so sketch… anyone who trusts NetBoot.xyz is asking to be pwned. You need to serve your own iPXE files and cached ISOs.
Cool project! I had mistral vibecode me something similar (split into two services and run via docker compose) just a few weeks ago! I still have dome nitpicks with the result, maybe I'll switch my stack over to your solution!
PXE is one of those easy to take for granted without appreciation for how much of a PIA it is to get working sometimes.
I run a homelab PXE & NFSboot, so no hard drives in the homelab. Works great until I do something to bork it up.
I have been fine tuning setup scripts to automatically get things going for scratch, but I always find there was one more hack I didn't automate last time.
iPXE is on my to-learn list.
Made something similar at work a bunch of years back…. :) good to see people still thinking of this stuff and making modern versions
That being said what may be more useful is a EFI binary you can push to a motherboard that does this with a tpm key
Some projects have been around for over a decade =3
https://fogproject.org/
https://github.com/FOGProject/fogproject
Yeah all of these rely on layer 2 or dhcp relay and are really ipv4 only solutions.
Not to discount what the fog guys had… love what they made :)
Look at ironic for something better.
What we eventually ended up with after a couple of iterations was decidedly better for our use case :)
But sadly doesn’t exist in the outside world yet :(.
Could you share your case's details? It sounds like you wanted better L3/IPv6 support and figured out a clean way to achieve it.
https://github.com/danderson/netboot/tree/main/pixiecore
Performative UI unnecessary green status dot: check!
Slop websites are getting very old very fast.
https://vorpus.github.io/performativeUI/#/components/status-...
Thanks, that was funny! It seems like more of an EyebrowPill.