pihole-kubernetes
pihole-kubernetes copied to clipboard
Allow to set the local DNS
Hi Guys,
Congratulations and thanks a lot for the nice job!
I am using the following pihole image as a work-around to the known bug that does not allow to write files in the /etc/pihole folder of the container: pi-hole/docker-pi-hole#922.
tag: v5.8.1 repository: pihole/pihole Using your chart with this pihole version I could not set-up the local-dns entries since, in this case, they get written to /etc/pihole/custom.list. Unfortunately, I did not find any mention of this file in the pihole documentation... so I am not sure accepting the pull request is a good idea but this could help somebody else.
The pull request allows to write to the /etc/pihole/custom.list file using the variabl뮻e: localDns.dnsRecords: []
Thank you again for your work!!
Best Riccardo
Closes #131
~~Any changes made to /etc/pihole/custom.list via the web interface will be lost when the Chart is upgraded or modified.~~
This PR disables the option to modify the local DNS records. The GUI will show a success message but cannot change the setting. The list won't change and only an error message will be printed to the log.
The existing variables dnsmasq.customDnsEntries and dnsmasq.additionalHostsEntries can set custom DNS entries but are not shown in the webinterface.
I will test this an merge it asap! Thank you!
Hi, I tested the change and i experienced the following behavior:
- The domains I added were working, but they were not shown in the GUI
- Since the file is read-only when you mount it from an config map, you can't do any changes in the GUI anymore Was this the same when you tested it?
My approach is currently to configure dnsmasq from a configmap. This enabled me to use the GUI to add additional DNS entries If i want to.
Maybe we should add a comment to the values.yml to warn the user, that this setting will prevent them from using the GUI to do changes.
Hi, I developed this approach because, for me, the k8s services are something that I setup once and I forget: I am not going to change settings directly in the interface while it is still convenient to be able to look at all of them from there.
I think leaving the user the possibility to choose one of the two approaches is the best solution... but, as you said, advantages and drawbacks should be documented clearly.
If you decide to keep my changes, let me know and I can help... (well I can help also if you decide to delete the pull request :D)
Well, having both options is not bad. Maybe you could extend the documentation in values.yml and document, that setting this will prevent one to add entries in the GUI. If you regenrate the documentation, this change should be clear to everybody, I think.