@Felix, actually the net=host option is a feature that would require an update to the corresponding Rockon json file. Once that’s added, and the Rockon is reinstalled, then you could run the dhcp server within pi-hole.
@Flox, I think unless the macvlan docker network (if I understand that correctly from the documentation) is implemented on Rockstor, the net=host option seems to be the most user-friendly approach; as we know it wouldn’t be the only Rockon that has to rely on it.
As I understand it from the documentation you’re completely right, but I was concerned, if anyone has the time and the knowledge to update this. So for me for now the second option also sounds great.
But I don’t really understand the configuration of the rocket lans🙈
@Felix, the changes are, I think, not so involved for the Rockon definition. If you want to, you could copy the below extract to a json file (e.g.: json_test.json), and place that in the /opt/rockstor/rockons-metastore directory (create it if it doesn’t exist. After a refresh in the Rockons screen that would show up as a pi-hole Test instance (you would want to uninstall the current pi-hole Rockon, and you could conceivably use the same configuration shares, but I leave that up to you of course).
If that works for you, then we can add the change permanently to the Rockon. Here is the adjusted version on github:
It installs fine for me and seems to be working, but since I am not the expert here, maybe you can test this. Finally, the normal UI button will not work anymore, since the Web Port is now defined differently than before (a change that has been coming to pihole for some time apparently), so you will have to put the web address in like this http://[SERVERIP]:[Web-Port]/Admin (if the port you choose during the setup up is 80, you don’t have to add that in there).
The way we’ve been addressing this kind of situation so far has been to create a "port" object with the "ui": true flag. Even if docker ignores this setting due to the host networking, Rockstor will use that to build the “webUI link” button. The inconvenience is that the user needs to set this port to the same value as the WEB_PORT environment variable for Pi-Hole. @Hooverdan, do I get this right about the WEB_PORT variable (my thoughts are based on the following doc: https://github.com/pi-hole/docker-pi-hole#advanced-variables)?
@Flox, yes. In reading some other forums, due to the net=host flag the explicit port mapping is rendered useless (as per dockers standard), the best option seemed to be to define the explicit webui port variable. In the test version I removed those previously set up port mappings. @phillxnet that’s why the UI piece didn’t work anymore.
However, for now we could “ask” the user to populate the same port twice and enable the Jo link on the Rockon page again, until we find a more elegant to for example designate any port or environment variable to represent the UI port definition. Or…down the line make the macvlan network part of the Rocknet functionality, so this won’t be necessary…
I can put the port object back in, test it a bit and create a PR for it.
I have not checked how I can do this through pihole Config itself (but the link to the port object would still be required for the Rockon UI link to work.
Yeah, I think it’s a necessary evil for now, unfortunately, and a less inconvenient solution than not having a UI button. Once we have our next Stable, I’m hoping to start addressing our Rock-On-related backlog to improve this sort of things.
Agreed; that was the intent. Rocknets were too big of a change to add too many things at once so it was focused on bridge networks at first, leaving the rest for a later time. This is the first very popular recommendation for a macvlan solution I see though, so it’s really nice to see a very approachable use for it… motivating the support for that as well.
That would perfect, thank you so much!
Yeah I’m afraid the port object is indeed the only way to have a UI button created for now.