/opt/dote not present after container startup

[pedropombeiro]

I have created the following script to create the pihole container, but it seems that my UDM Pro has somewhat different behavior in a couple aspects. /dev/fd0 isn't present on my system (I'm on UniFi OS 1.10.4), and if I run the script below and list /opt, only pihole is present. Shouldn't it be present after container initialization?

#!/bin/sh

cat > Dockerfile <<EOF
FROM pihole/pihole:latest
ENV DOTE_OPTS="-s 127.0.0.1:5053"
RUN echo -e  "#!/bin/sh\ncurl -fsSLo /opt/dote https://github.com/chrisstaite/DoTe/releases/latest/download/dote_arm64\nchmod +x /opt/dote\n/opt/dote \\\$DOTE_OPTS -d\n" > /etc/cont-init.d/10-dote.sh
EOF

podman pull pihole/pihole:latest
podman build -t localhost/pihole:latest --format docker -f Dockerfile
rm Dockerfile
podman stop pihole
podman rm pihole
podman run -d --network dns --restart always \
    --name pihole \
    -e TZ="Europe/Zurich" \
    -v "/mnt/data/etc-pihole/:/etc/pihole/" \
    -v "/mnt/data/pihole/etc-dnsmasq.d/:/etc/dnsmasq.d/" \
    -v "/mnt/data/pihole/hosts:/etc/hosts:ro" \
    --dns=127.0.0.1 \
    --hostname pihole \
    -e DOTE_OPTS="-s 127.0.0.1:5053 -m 10" \
    -e VIRTUAL_HOST="pihole" \
    -e PROXY_LOCATION="pihole" \
    -e ServerIP="192.168.6.253" \
    -e PIHOLE_DNS_="127.0.0.1#5053" \
    -e IPv6="False" \
    localhost/pihole:latest

If I try executing the script steps inside the container, I get the following:

# docker exec -ti pihole bash
root@pihole:/# # curl -fsSLo /opt/dote https://github.com/chrisstaite/DoTe/releases/latest/download/dote_arm64
# chmod +x /opt/dote
# /opt/dote $DOTE_OPTS -d
/opt/dote: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

[chrisstaite]

Interesting, it seems your container has a different version of openssl in it. I haven't updated my pihole for a while, so perhaps they've updated it. I'll take a look

[pedropombeiro]

I just noticed that the commands were not running inside the container, as I'm being dumped out of the container by docker exec.

[chrisstaite]

Yes, that makes sense to why the prompt looked so weird. Try using sh rather than bash.

[chrisstaite]

You could also try

podman exec -ti pihole /bin/ls -l /opt

[pedropombeiro]

So I had to resort to downloading the dote binary from outside the docker build routine and COPY it inside. This is probably because my container DNS was not functional during the build process and therefore the curl call failed. In any case, I think this approach is preferrable as it makes errors more evident to the user, and he doesn't end up with a non-functional container:

#!/bin/sh

set -e

tmpdir="$(mktemp -d)"
curl -sSLo "${tmpdir}/dote" https://github.com/chrisstaite/DoTe/releases/latest/download/dote_arm64

cat > "${tmpdir}/Dockerfile" <<EOF
FROM pihole/pihole:latest
ENV DOTE_OPTS="-s 127.0.0.1:5053"
COPY dote /opt/dote
RUN chmod +x /opt/dote && echo -e  "#!/bin/sh\n/opt/dote \\\$DOTE_OPTS -d\n" > /etc/cont-init.d/10-dote.sh
EOF

podman pull pihole/pihole:latest
podman build -t pihole:latest --format docker -f "${tmpdir}/Dockerfile" "${tmpdir}"
rm -rf "${tmpdir}"

set +e

podman stop pihole
podman rm pihole
podman run -d --network dns --restart always \
    --name pihole \
    -e TZ="Europe/Zurich" \
    -v "/mnt/data/etc-pihole/:/etc/pihole/" \
    -v "/mnt/data/pihole/etc-dnsmasq.d/:/etc/dnsmasq.d/" \
    -v "/mnt/data/pihole/hosts:/etc/hosts:ro" \
    --dns=127.0.0.1 \
    --hostname pihole \
    -e DOTE_OPTS="-s 127.0.0.1:5053 --forwarder 1.1.1.1:853 --connections 10 --hostname cloudflare-dns.com --pin XdhSFdS2Zao99m31qAd/19S0SDzT2D52btXyYWqnJn4=" \
    -e VIRTUAL_HOST="pihole" \
    -e PROXY_LOCATION="pihole" \
    -e ServerIP="192.168.6.253" \
    -e PIHOLE_DNS_="127.0.0.1#5053" \
    -e IPv6="False" \
    pihole:latest

[chrisstaite]

It's good to ensure your machine has DNS so that you can download containers etc. You can do that by setting the DNS for your WAN to a service you want then the DNS for your LAN to the pihole.

[pedropombeiro]

I did have the WAN DNS set to 1.1.1.1/1.0.0.1, the problem is that the 127.0.0.1 resolver was not functional so it was failing to resolve github.com at startup. As I said, better to perform the download at build time rather than runtime.