Version 3.2 update MEGATHREAD

[diginc]

Known Issues

• The startup may get stuck trying to find DNS unless you set your docker run --dns 127.0.0.1 --dns 8.8.8.8.
• I had to remove my persistent data volumes of 3.1 data to get graphs working, maybe an issue with that.

Currently information is scattered in pull requests, old issues, and newer closed issues. Here's all the info on the update so far:

Current statuses of the different images and their known issues:

Debian is built and looks operational, but not released

• Point your docker run at diginc/pi-hole:debian_dev tag to beta test 3.2, report issues here.
• The new arm images are available on diginc/pi-hole-multiarch:debian_armhf
• Pull request(s): #191

Alpine needs some work still

• Pull request(s): #192 contains ongoing work for anyone interested in collaborating
• Alpine has been removed due to added work time to cut new releases

Keep an eye on https://hub.docker.com/r/diginc/pi-hole/tags/ and the above pull requests for progress

Report all issues / bugs here, no need to open a new issue.

[diginc]

Just throwing this out there, I'm having thoughts about making the a change to the default latest image tag and point to debian since it is usually much easier to upgrade then alpine.

[nsbionix]

So I pulled the 3.2 version with the following script:

!/bin/bash

IP_LOOKUP="$(ip route get 8.8.8.8 | awk '{ print $NF; exit }')" IPv6_LOOKUP="$(ip -6 route get 2001:4860:4860::8888 | awk '{ print $10; exit }')" IP="${IP:-$IP_LOOKUP}" # use $IP, if set, otherwise IP_LOOKUP IPv6="${IPv6:-$IPv6_LOOKUP}" # use $IPv6, if set, otherwise IP_LOOKUP DOCKER_CONFIGS="$(pwd)" # Default of directory you run this from, update to where ever.

echo "IP: ${IP} - IPv6: ${IPv6}"

docker run -d \ --name pihole \ -p 53:53/tcp -p 53:53/udp -p 80:80 \ --dns 127.0.0.1 \ --dns 8.8.8.8 \ -v "${DOCKER_CONFIGS}/pihole/:/etc/pihole/" \ -v "${DOCKER_CONFIGS}/dnsmasq.d/:/etc/dnsmasq.d/" \ -e ServerIP="${IP}" \ -e ServerIPv6="${IPv6}" \ --restart=always \ diginc/pi-hole-multiarch:v3.2_debian_armhf

Problems for me are the following:

[diginc]

Are you using fresh volume data or your old 3.1 data?

[nsbionix]

I deleted and used prune on every container, image and volume. After that I looked into container/image/volume with ls and everything was clear of data. Then I used the script and got the above results.

[diginc]

Can you post docker logs pihole to a https://gist.github.com (so it doesn't take up a lot of space in the thread) ?

The run script looks good to me, I'll have to see if the log has any obvious problems in it and after I'm off work I should be able to spin up my rasberryPi 2 and test this out.

[nsbionix]

https://gist.github.com/nsbionix/84f2941f1b9117ddf30b7c9aff294231

[diginc]

Looks like startup broke mid run:

ERROR: ServerIPv6 Environment variable (-101) doesn't appear to be a valid IPv6 address
TIP: If your server is not IPv6 enabled just remove '-e ServerIPv6' from your docker container

so the rest of the provisioning didn't run - however it didn't end the containers life after that error. Related PR that may resolve: #194 (no built images for this yet)

For now you can remove the IPv6 variable from the script or docker run command

[nsbionix]

I deleted the IPv6 entry and ran into a new problem when I want to fetch the new lists:

[ulm0]

About Docker-multiarch image...what about using estesp/manifest-tool in order to ease the pulling process? just running docker pull dicing/docker-pi-hole:debian and docker pull dicing/docker-pi-hole:alpine and docker will pull the image according to the architecture, either for arm or amd64.

[diginc]

I was only seeing the 'waiting 120 seconds' error when the container --dns option was not set, after I set that it seemed to work every time. It could also be a bug specific to the multiarch image. I still haven't gotten around to testing those out on actual pi hardware.

[diginc]

@klud1 That topic is more suited to #177 I will reply to your comment there.

[diginc]

Take a look at this comments run command https://github.com/diginc/docker-pi-hole/issues/196#issuecomment-350794685

On Tue, Dec 12, 2017, 1:12 PM Bas Rieter notifications@github.com wrote:

How would you set the --dns in a Docker run command?

-e DNS=192.168.2.1

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/diginc/docker-pi-hole/issues/196#issuecomment-351159566, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0-olNgAMBlWtB2RwDM9e3CiENztuXlks5s_tAVgaJpZM4Q9pH3 .

[diginc]

@nsbionix could you try removing --dns 127.0.0.1 as the primary DNS and move it to secondary?

--dns 8.8.8.8 \
--dns 127.0.0.1

The strange thing is my automated tests that do NSLookups successfully ONLY use 127.0.0.1, see conftest.py ... so this could be some other factor I'm not seeing.

[nsbionix]

rebuild the whole thing but did not work, still getting the message DNS resolution is currently unavailable

edit: so somehow and i don't know why i got to this:

error is still there when I'm trying to update. Also pihole seems not to forward/block anything and I just put it as my local DNS not in the FritzBox

edit2: Okay I feel like getting screwed over by my own pi ^^ I did literally nothing for the first edit and now after the first edit I did nothing too and pihole itself seems to work fine. Update is still not possible but the pihole itself blocks now...

[Anuskuss]

@diginc: Just throwing this out there, I'm having thoughts about making the a change to the default latest image tag and point to debian since it is usually much easier to upgrade then alpine.

What even the point in the alpine build? We bother maintaining two seperate builds which basically accomplish the same?

[diginc]

Image size is much smaller (100MB) for alpine. This isn't an issue for most modern internet connections I know, but it is nice having lean and mean docker images in general.

It is also an experiment is testing pi-hole compatibility with gcc-musl that lots of routers run and NGINX webserver instead of lighttpd. Alpine is my goto base OS for docker and nginx is my go to webserver in general, so it's partially my preferences.

RaspberryPi hardware takes significantly longer to download/unpack on then a proper x86 docker server too so there is that benefit from the size reduction to consider.

On Thu, Dec 14, 2017 at 2:14 PM Anuskuss notifications@github.com wrote:

@diginc https://github.com/diginc: Just throwing this out there, I'm having thoughts about making the a change to the default latest image tag and point to debian since it is usually much easier to upgrade then alpine .

What even the point in the alpine build? We bother maintaining two seperate builds which basically accomplish the same?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/diginc/docker-pi-hole/issues/196#issuecomment-351823346, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0-ouYDA9l5zdhJjV8iaFg-ADOzF0Xfks5tAYGcgaJpZM4Q9pH3 .

[Anuskuss]

I see you. I guess you can decide on your own, but personally I wouldn't "waste" my time with this niche case (some programs don't even have an AMD64 build because they don't want to maintain two projects).

[unixfox]

It's working fine for me with the branch debian_dev. @diginc Can you update the development branch to the lastest version of pihole?

[ulm0]

Point is...some of us might have a "good" internet connection, still there are others that don't.

[middleagedman]

I'd love to have the 3.3 version of pihole on debian. Do the easiest image first, since they build that on debian, then alpine secondary imho.

[diginc]

I've axed alpine for now, at this point I don't have the time to maintain it's differences from debian so away it goes. I've pushed a branch last_alpine_commits with the last commit before I started removing all the alpine references.

[middleagedman]

Thanks for all your work, we all really appreciate using your free time to do this. No need to make it a burden for yourself. :)

[rix1337]

@diginc perfectly reasonable decision. I ran into alpine-specific issues on my images as well. Keep it up! Pi-Hole in docker is my backup-dns if my pi-hole dies.. and it works flawlessly

[diginc]

debian released to latest tag. I may go and actually cleanup / delete the alpine tag from docker's tag listing to prevent future confusion too.

[basrieter]

What images are best to use now for rPi3?

https://hub.docker.com/r/diginc/pi-hole-multiarch/tags/ -or- https://hub.docker.com/r/diginc/pi-hole/tags/

[diginc]

I pushed a slightly older version of debian to https://hub.docker.com/r/diginc/pi-hole-multiarch/tags/ last night, pushing the latest (3.2.1) version right now.

[basrieter]

So we could use either source depending on the architecture of the system?

[diginc]

I deleted arm tag off of pi-hole repository since that is an old old version.

https://hub.docker.com/r/diginc/pi-hole-multiarch/tags/ is the latest, greatest. I just need to add it to the README and finish up the automated travis-ci build for it so I can stop running docker pushes from my development environment.

[middleagedman]

FYI.. I'm seeing issues if /etc/resolv.conf doesn't have "nameserver 127.0.0.1" in it as the first entry. I tried passing it via the DNS1= option but it looks like that does nothing and it still grabs from dhcpcd

Using custom DNS servers: 127.0.0.1 & 8.8.4.4 DNSMasq binding to default interface: eth0 Added ENV to php: "PHP_ERROR_LOG" => "/var/log/lighttpd/error.log", "ServerIP" => "192.168.1.3", "VIRTUAL_HOST" => "192.168.1.3", Using IPv4 dnsmasq: syntax check OK. ::: Testing DNSmasq config: ::: Testing lighttpd config: Syntax OK ::: All config checks passed, starting ... ::: Docker start setup complete [✗] DNS resolution is currently unavailable

more /etc/resolv.conf

Generated by dhcpcd from enp5s0.dhcp

nameserver 8.8.8.8 nameserver 8.8.4.4 nameserver 192.168.1.3 nameserver 208.67.220.220

/etc/resolv.conf.tail can replace this line

[middleagedman]

Found the solution.. Looks like it's fixed in this commit https://github.com/pi-hole/pi-hole/pull/1856/commits/1078aa499c26ba0b3dfb886c7a1a6f3d95d00591

I updated my gravity.sh file instead of the container and it starts properly now.

[diginc]

Good find, I think I was working around this by just setting a dns server in the docker run command as the known issue said:

Known Issues

• The startup may get stuck trying to find DNS unless you set your docker run --dns 127.0.0.1 --dns 8.8.8.8.
• I had to remove my persistent data volumes of 3.1 data to get graphs working, maybe an issue with that.

Manually patching that maybe a better solution.

[diginc]

Re-opening for visibility on the --dns 127.0.0.1 workaround (for now)

[middleagedman]

Yea.. I just overwrote gravity.sh with the 3.2.1 file and graphs are working, boot is working. I still get N/A on the version check, but I'm still debugging that.

[middleagedman]

Nm.. the version isn't populated until the cron.d pihole job runs daily.

And I rebuilt your docker image using export CORE_TAG='v3.3-rc1' and it starts better now without any runtime DNS= changes

Hopefully that will come out of RC soon

[DL6ER]

Nm.. the version isn't populated until the cron.d pihole job runs daily.

Yeah, I admit to have forgotten this. You can manually run

pihole updatechecker remote

This is fixed in the core code by https://github.com/pi-hole/pi-hole/pull/1878

[diginc]

211 deployed a new dev tag that has the latest development branch code for the next release on it...and maybe any bugs on dev also :)

I believe it removes the need for --dns 127.0.0.1 - I haven't tested it extensively but my docker-compose came up cleanly without it.