search

gcgarner / IOTstack

docker stack for getting started on IOT on the Raspberry PI
GNU General Public License v3.0
1.5k stars 578 forks source link

nodered is unable to install new modules, DNS issue #215

Closed dawnstrider closed 3 years ago

dawnstrider commented 3 years ago

Using the IOTStack script to define a stack for my Raspberry Pi 3B+

Included applications:

After docker stack is up and running (all OK) I try to install another module using the node-red UI. Output of the "npm install ..." command is always the same:

2020-11-16T13:19:50.801Z npm install --no-audit --no-update-notifier --no-fund --save --save-prefix=~ --production node-red-contrib-onvif@1.0.1 2020-11-16T13:19:59.628Z [err] npm 2020-11-16T13:19:59.630Z [err]
2020-11-16T13:19:59.630Z [err] ERR! 2020-11-16T13:19:59.631Z [err]
2020-11-16T13:19:59.631Z [err] code 2020-11-16T13:19:59.631Z [err] EAI_AGAIN 2020-11-16T13:19:59.633Z [err] npm 2020-11-16T13:19:59.633Z [err]
2020-11-16T13:19:59.634Z [err] ERR! 2020-11-16T13:19:59.634Z [err]
2020-11-16T13:19:59.634Z [err] errno 2020-11-16T13:19:59.635Z [err] EAI_AGAIN 2020-11-16T13:19:59.646Z [err] npm 2020-11-16T13:19:59.647Z [err]
2020-11-16T13:19:59.647Z [err] ERR! request to https://registry.npmjs.org/node-red-contrib-onvif failed, reason: getaddrinfo EAI_AGAIN registry.npmjs.org registry.npmjs.org:443 2020-11-16T13:19:59.675Z [err] 2020-11-16T13:19:59.676Z [err] npm ERR! A complete log of this run can be found in: 2020-11-16T13:19:59.676Z [err] npm 2020-11-16T13:19:59.676Z [err] ERR! /data/.npm/_logs/2020-11-16T13_19_59_650Z-debug.log 2020-11-16T13:19:59.693Z rc=1

I want to use pihole as the DNS/DHCP server for my network. Apparently, the other docker containers of the stack do not use it tho.

dawnstrider commented 3 years ago

ok after reading up on the official doc of pihole at https://docs.pi-hole.net/docker/DHCP/ it looks like there is no simple way to use pi-hole inside a docker stack as both DNS and DHCP server. Bummer.. Still open for ideas/solutions.

Paraphraser commented 3 years ago

First, please see This repository is dormant.

Second, you can use PiHole running inside docker for DNS (certainly for its blocking function, and probably to be authoritative for a local domain if you have no other choice) but the one device on your network that should never use PiHole for DNS is the RPi running PiHole inside Docker. The basic problem is this. To make it work you have to change /etc/resolvconf.conf to point to 127.0.0.1. At some future time your RPi reboots. At boot time, docker isn't running and neither is PiHole so there's no DNS resolution. Even when the stack is being brought up, there's no way of saying "bring up PiHole first, wait for it to stabilise, then bring up the other containers" so it's pot luck as to whether any given container can resolve names until the dust settles. Meanwhile, all manner of things (docker, Raspbian) come over "all helpful" with fallback measures so you can wind up with DNS seeming to work but it's not actually coming from where you think it is.

PiHole inside Docker is a great ad blocker - for every device on your network except the RPi it is running on. I haven't tried it but I t's probably a reasonable DNS server for a local domain but, again, just not for the RPi it is running on. Not only do you have the boot time chicken-and-egg problem but Docker is not multicast-aware so PiHole can't participate in mDNS. You can probably get past that by running PiHole in host mode but, to my way of thinking, if host mode is the answer, Docker is the wrong question.

I can't see that PiHole will ever be useful as a DHCP server running inside Docker. It arrives far too late at reboot time to be of any real use.

If I wanted to use PiHole in a full all-features mode, I'd buy another RPi, install a canned PiHole image, and dedicate it to that task.

Personally, my router is my DHCP server, and I have a local DNS (bind9 running on a Mac) which is authoritative for a local domain. Most devices in the house use the RPi running PiHole as their primary DNS. The exceptions are the Mac and the RPi running PiHole, and both of those use the Mac for all queries. For queries directed to PiHole by other devices, it either blocks, or forwards any unqualified name or fully qualified name in the local domain to the Mac, otherwise forwards to 8.8.8.8 and friends. The Mac answers authoritatively for the local domain, else forwards to 8.8.8.8 and friends.

To use NodeRed (running in a container alongside PiHole) as an example, a query for another container name like "mosquitto" will be answered by Docker. If Docker can't answer, the query will wind up at the Mac which will either answer for the local domain or relay to 8.8.8.8 etc. PiHole doesn't get involved.

It's simple. It's predictable. It's reliable. It survives reboots.

Hope this helps.

dawnstrider commented 3 years ago

Thanks for the very detailed story. I was never planning to go as deep as you did with your setup. I have several differences in my network which sadly do not allow me to do what you did, meaning my router can be a DHCP server, but if it is, it is also hardcoded to be the DNS so that sucks for starters. Of course, not a problem that money couldn't solve but money doesn't fall from the sky in my case.

I am currently experimenting with most of the stack running in docker and pi-hole running as a direct install on the PI, which seems to do the trick.

I will take your feedback and try to implement some of it in my place, also I will check out the other repository for the fork of this one.

Thanks again for the effort you put into your answer.