Closed samuellazea closed 9 months ago
This app in general does not require host level networking in Docker at it's core it is a simple http and tftp server. I saw some discussion about needing to run it on a Synology in that mode. Can you explain a bit more? Does Syno not let you define the udp tag in their interface?
@thelamer I don't know what you mean with the udp tag. I can take some screenshots of the interface if you like but what I did was take the docker-compose part and spin up the container using the compose part
` netboot: image: linuxserver/netbootxyz container_name: netboot environment:
The "./netboot/app.js:/app/app.js:rw" I use to rewrite the port to 3001 and the "/config/nginx/site-confs/default:rw" I use to overwrite port 80 to something else.
If you can point me in the direction of what exact info you need I can provide anything needed. Thanks lots in advance
What I am saying is that you should not have to use host level networking for functionality. Swapping ports using normal Docker forwards should prove functional on any system, it is just that the TFTP port can never change as TFTP ipxe clients have not sense of port when connecting.
simply using -p 3001:3000
and -p 8080:80
should achieve what you are looking for.
What led you to believe this needed to be run with Host level networking? Synology has a baked in TFTP server, but as long as it is disabled it will not conflict with a -p 69:69/udp
port map being set on this container.
@thelamer
After doing some more digging and research I stumbled on this page: https://gist.github.com/pedrolamas/db809a2b9112166da4a2dbf8e3a72ae9
Basically Synology has something different then normal hosts and some ip tables rules need to be changed if I need to run the container on docker network instead of host network.
It basically boils down to this commands:
iptables -t nat -A PREROUTING ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER iptables -t nat -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
After I did this manually on the Synology then I could pxe boot from the container network instead of host. But this is more as a hack then a fix cause this will get overwritten every reboot
Apologies for reviving an old discussion thread, but I just wanted to note that despite the shortcomings/issues with Synology that I've seen people report in a few places, the easiest fix is to simply configure the builtin Synology TFTP server to serve its files from the shared folder where the netboot.xyz
docker menu files are located.
In my case I configured the docker image to store config
and assets
in /docker/netbootxyz/config
and /docker/netbootxyz/assets
, respectively. I didn't expose UDP port 69 on the docker container (since I want the Synology to handle that), and finally pointed the builtin Synology TFTP server to serve its content from /docker/netbootxyz/config/menus
. That's all that was needed to get everything working.
Now the Synology takes care of all the TFTP stuff and the webapp is used to manage the app (via exposed port 3000) and serve local assets (via exposed port 8080). No need to use host networking. Bridge networking works just fine with this setup.
Apologies for reviving an old discussion thread, but I just wanted to note that despite the shortcomings/issues with Synology that I've seen people report in a few places, the easiest fix is to simply configure the builtin Synology TFTP server to serve its files from the shared folder where the
netboot.xyz
docker menu files are located.In my case I configured the docker image to store
config
andassets
in/docker/netbootxyz/config
and/docker/netbootxyz/assets
, respectively. I didn't expose UDP port 69 on the docker container (since I want the Synology to handle that), and finally pointed the builtin Synology TFTP server to serve its content from/docker/netbootxyz/config/menus
. That's all that was needed to get everything working.Now the Synology takes care of all the TFTP stuff and the webapp is used to manage the app (via exposed port 3000) and serve local assets (via exposed port 8080). No need to use host networking. Bridge networking works just fine with this setup.
It's is not a Synology problem, is the way TFTP works and recommending to strip parts of the software to avoid the fact that the port could be configured somehow (environment var is the way to go) is not the best aproach.
Understanding the above discussion, I'd like to raise another voice in support of making the webapp port configurable.
Grafana uses port 3000
as their default webapp host port, which conflicts with this project's default config as well.
If you're using host
networking, which may be required in certain circumstances then there's no way to prevent this overlap. As a result, you'd have to temporarily stop OTHER services to run this one, which is arbitrarily silly, given that all of the other port definitions can be overridden.
https://github.com/netbootxyz/webapp/blob/master/app.js#L352
Wonderful, thank you 😎 Shall I open a PR to fix the omission of this from the documentation, or how would you like to address this 😄
It's in the docs:
https://github.com/netbootxyz/docker-netbootxyz/?tab=readme-ov-file#parameters
This was added in https://github.com/netbootxyz/docker-netbootxyz/commit/c4014a0a6e0c25b774390a77ab9ac98dc006e2cd
Closing this out.
Appreciate the follow up.
I was noting that the documentation site (https://netboot.xyz/docs/docker) appears to be missing the reference to the recently-added option. There are only 2 mentions of 'webapp port' on the docker instructions page, and both are in reference to the -p
port definition.
I'll be happy to open a PR for those docs, if you wish.
Thanks!
Hello,
Is there a way to make the port 3000 that is currently hardcoded in the app dynamic? Would like if possible to configure it using like enviroment variable and if not set to default to 3000. I ask this cause if using network (host) the port is already used by other applications. In my particular case I could only get pxe to work using network host.
Getting more into configuration I already tested a change of the port in file /app/app.js. I modified this part:
// Spin up application on port 3000 http.listen(3000, function(){ console.log('listening on *:3000'); });
to
// Spin up application on port 3001 http.listen(3001, function(){ console.log('listening on *:3001'); });
and this proved to work nicely when I rebooted the container.
If this change could be made available this would help other people also with having more flexibility and I would appreciate it much