Resolve pi.hole/localhost as FQDN

Expected Behaviour:

I'd like to have the pihole instance to report with it's fully qualified domain name in the API/WebUI, rather than pi.hole or localhost.
I am running the official container image:

The container is running with podman version 4.1.1 on a RHEL 8.6. Following is the podman/docker-compose file that is being used:

version: "3"

services:
  pihole.example.com:
    container_name: 'pihole.example.com'
    hostname: 'pihole.example.com'
    image: 'pihole/pihole:latest'
    logging:
      driver: 'journald'
    ports:
      - "172.31.4.102:53:53/tcp"
      - "172.31.4.102:53:53/udp"
      - "127.0.0.1:8080:80/tcp"
    environment:
      TZ: 'Europe/Berlin'
      FTLCONF_LOCAL_IPV4: '172.31.4.102'
      CUSTOM_CACHE_SIZE: '10000'
      FLTCONF_PIHOLE_PTR: 'HOSTNAMEFQDN'
    volumes:
      - '/container/pihole.example.com/pihole:/etc/pihole:Z'
      - '/container/pihole.example.com/dnsmasq.d:/etc/dnsmasq.d:Z'
      - '/container/pihole.example.com/logs:/var/log:Z'
    restart: 'unless-stopped'
    cap_add:
      - CAP_AUDIT_WRITE
      - CAP_SYS_NICE
      - CAP_CHOWN
    deploy:
      resources:
        limits:
          memory: 2048M
        reservations:
          memory: 2048M

Is there a way to change the behavior so pihole will show itself with it's FQDN?

Actual Behaviour:

In the WebUI/API pihole is shown as either pi.hole or localhost, instead of pihole.example.com. All other hosts are properly shown with FQDN.

https://docs.pi-hole.net/ftldns/configfile/#pihole_ptr

And since you are running a dockered Pi-hole, configure FTLCONF_PIHOLE_PTR as an Advanced Environment Variable to apply jfb's suggestion:to a Docker container, see specifically:

Variable Default Value Description
FTLCONF_[SETTING] unset As per documentation Customize pihole-FTL.conf with settings described in the FTLDNS Configuration page. For example, to customize LOCAL_IPV4, ensure you have the FTLCONF_LOCAL_IPV4 environment variable set.

That's exactly what I applied already (please see the above codeblock for the FLTCONF_PIHOLE_PTR environment variable). I further also provided the domain (as suggested in the documentation) via:

[root@container pihole]# cat /container/pihole.example.com/dnsmasq.d/99-hostname.conf 
domain=example.com

Sorry, I forgot to mention that in the first post.

I am mounting /container/pihole.example.com/dnsmasq.d to /etc/dnsmasq.d and thus would expect that pihole would pick up that change actually.
Nothing in the startup logs indicate however, if those environment variables are actually taken into consideration.
I would have expected that they'll end up in /container/pihole.example.com/pihole/pihole-FTL.conf, but they don't:

[root@container pihole]# cat /container/pihole.example.com/pihole/pihole-FTL.conf 
REPLY_ADDR4=172.31.3.47
LOCAL_IPV4=172.31.3.47
RATE_LIMIT=1000/60

Please note, that I have also mounted /container/pihole.example.com/pihole to /etc/pihole.
I tried adding PIHOLE_PTR directly to /container/pihole.example.com/pihole/pihole-FTL.conf, but that didn't work out either.

I have created a debug log, maybe that helps in pinning down the issue. Probably it's something configuration-wise on my end that doesn't work out.

Thanks for your help guys!

Debug log: https://tricorder.pi-hole.net/23R5Hf1x/

I'm not sure if this is causing some problems, but why are you mounting the volumes using the :Z flag?

Did you try without any flags?

Of course - sorry for not assessing your docker-compose thoroughly enough. :pray:

That REPLY_ADDR4 line is peculiar.
Your docker-compose shows you've correctly and exclusively provided FTLCONF_LOCAL_IPV4, which supersedes the now deprecated REPLY_ADDR4 - so that line shouldn't be there at all.

This rings a bell, as we've had reports about Portainer installations holding on to environment variable values even between container rebuilds/restarts (e.g. see Pihole Portainer/Docker 5.8.1 startup error? - #7 by ptruman or Pihole on Docker always shows old Docker Tag value - #2 by rdwebdesign).

I'm not familiar with Podman, but in addition to rdwebdesign's suggestion to drop the Z flag (which may only be required in SELinux contexts), I'd probably look for ways to clear those env vars with Podman, in case it would do something similar to Portainer.

@rdwebdesign I am using the Z flag to indicate a bind mount, that is private and unshared (see Use bind mounts | Docker Documentation). Since I am running on a RHEL machine, naturally SELinux is enabled and thus I need to provide this flag. Nevertheless, I temporarily "disabled" SELinux (using setenforce 0, which sets the SELinux mode to permissive, thus it is not blocking anything; it merely logs what would have been blocked) and tried running without any flags with the very same outcome, unfortunately.

@Bucking_Horn Podman is in simple terms basically docker without a daemon (in a nutshell, please see Podman for a more thorough explanation).
I checked whether there are any environment variables within the container that should not be there anymore and also verified whether environment variables are actually getting set and applied.
I added SKIPGRAVITYONBOOT: 1 to my docker-compose file to see if pihole would react to it: Yes indeed, pihole skipped updating the gravity database on boot.
Next, I checked which environment variables are actually available simply using env within the container and sorting it for better readability:

[root@container pihole]# podman exec -it pihole.example.com env | sort
container=podman
CUSTOM_CACHE_SIZE=10000
DNSMASQ_USER=pihole
FLTCONF_PIHOLE_PTR=HOSTNAMEFQDN
FTL_CMD=no-daemon
FTLCONF_LOCAL_IPV4=172.31.4.102
HOME=/root
HOSTNAME=pihole.example.com
IPv6=True
PATH=/opt/pihole:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PHP_ENV_CONFIG=/etc/lighttpd/conf-enabled/15-fastcgi-php.conf
PHP_ERROR_LOG=/var/log/lighttpd/error-pihole.log
phpver=php
PIHOLE_DOCKER_TAG=2022.09.4
PIHOLE_INSTALL=/etc/.pihole/automated install/basic-install.sh
S6_BEHAVIOUR_IF_STAGE2_FAILS=2
S6_CMD_WAIT_FOR_SERVICES_MAXTIME=0
S6_KEEP_ENV=1
S6_OVERLAY_VERSION=v3.1.1.2
SKIPGRAVITYONBOOT=1
TERM=xterm
TZ=Europe/Berlin
[root@container pihole]# 

When I remove the environment variable FLTCONF_PIHOLE_PTR: HOSTNAMEFQDN from the docker-compose file and restart the container, I can see it is indeed gone:

[root@container pihole]# podman exec -it pihole.example.com env | sort
container=podman
CUSTOM_CACHE_SIZE=10000
DNSMASQ_USER=pihole
FTL_CMD=no-daemon
FTLCONF_LOCAL_IPV4=172.31.4.102
HOME=/root
HOSTNAME=pihole.example.com
IPv6=True
PATH=/opt/pihole:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PHP_ENV_CONFIG=/etc/lighttpd/conf-enabled/15-fastcgi-php.conf
PHP_ERROR_LOG=/var/log/lighttpd/error-pihole.log
phpver=php
PIHOLE_DOCKER_TAG=2022.09.4
PIHOLE_INSTALL=/etc/.pihole/automated install/basic-install.sh
S6_BEHAVIOUR_IF_STAGE2_FAILS=2
S6_CMD_WAIT_FOR_SERVICES_MAXTIME=0
S6_KEEP_ENV=1
S6_OVERLAY_VERSION=v3.1.1.2
SKIPGRAVITYONBOOT=1
TERM=xterm
TZ=Europe/Berlin
[root@container pihole]# 

What I cannot tell is whether pihole makes actually use of these; With SKIPGRAVITYONBOOT I could clearly tell that pihole honored it since it skipped updating the gravity database. For FLTCONF_PIHOLE_PTR I am unable to tell obviously.Technically the environment variables are there, but I don't know if they are getting used. Is there a way to determine which values have been applied to pihole's runtime configuration (possibly with source, eg: from env, from conf file, etc)?

Regarding the variable REPLY_ADDR4 in the pihole-FTL.conf: That is most likely an oversight on my end, as I tried different things to apply the settings back then when I moved to a container-based install from a Raspberry Pi and must have forgotten to remove it ultimately. I removed it now from the configuration file and couldn't spot any difference, however.

Further, S6_KEEP_ENV caught my eye and tried setting it to it's default value (which is 0, according to GitHub - just-containers/s6-overlay: s6 overlay for containers (includes execline, s6-linux-utils & a custom init)), but then the following is seen in the container logs:

s6-rc: info: service legacy-services successfully started
Stopping pihole-FTL
pihole-FTL: no process found
Stopping pihole-FTL
pihole-FTL: no process found
Stopping pihole-FTL
pihole-FTL: no process found
Stopping pihole-FTL

Presumably this happens due to no environment variables being present once pihole starts and switches to the user pihole (at least that is happening according to the container logs): [i] pihole-FTL (no-daemon) will be started as pihole

Anyway, I am really out of ideas - your help is highly appreciated! :slight_smile:

bump, anyone that experienced the same issue?

I don't want to appear precocious, but isn't this a typo?

Shouldn't it say FTL?

3 Likes

I was typing out a reply to this comment thread, but then I saw @mag 's response and realise that everybody else (including myself) involved in this thread needs a new pair of glasses :slight_smile:

Original Reply

This function is run on every container startup:

docker-pi-hole/src/s6/debian-root/usr/local/bin/bash_functions.sh at a9ecd4e7a20ccdd5b404aa70169f11b938f3e70d · pi-hole/docker-pi-hole · GitHub

Which, in turn, calls:

docker-pi-hole/src/s6/debian-root/usr/local/bin/bash_functions.sh at a9ecd4e7a20ccdd5b404aa70169f11b938f3e70d · pi-hole/docker-pi-hole · GitHub

addOrEditKeyValPair is a helper script sourced from:

pi-hole/advanced/Scripts/utils.sh at 7fd062c4d80a6b481ec252ba401dd37f5223f46b · pi-hole/pi-hole · GitHub

So the value of FTLCONF_PIHOLE_PTR should definitely be making it into the config file

Thanks for the hint @mag. Unfortunately, it does not make any difference.
As I stated initially, I also added the value directly to the pihole-FTL.conf (without the FTL/FLT prefix of course), but that didn't work out either.
I hoped so much I was just too stupid to type and @mag fixed it with his eagle eyes, but unfortunately that's not the case :frowning:

So, I set up an entirely new container only to ensure that the issue is not some permissions issue or something around that lines.
The outcome is, that the queries show up as localhost rather than pihole.example.com.
I used the following docker-compose.yml:

version: "3"

services:
  pihole.example.com:
    container_name: 'pihole.example.com'
    hostname: 'pihole.example.com'
    image: 'pihole/pihole:latest'
    logging:
      driver: 'journald'
    ports:
      - "172.31.4.102:5344:53/tcp"
      - "172.31.4.102:5344:53/udp"
      - "9999:80/tcp"
    environment:
      TZ: 'Europe/Berlin'
      FTLCONF_LOCAL_IPV4: '172.31.4.102'
      FTLCONF_PIHOLE_PTR: 'HOSTNAMEFQDN'
      CUSTOM_CACHE_SIZE: '10000'
      SKIPGRAVITYONBOOT: 1
    volumes:
      - '/container/pihole.example.com/pihole:/etc/pihole:Z'
      - '/container/pihole.example.com/dnsmasq.d:/etc/dnsmasq.d:Z'
      - '/container/pihole.example.com/logs:/var/log:Z'
    restart: 'unless-stopped'
    cap_add:
      - CAP_AUDIT_WRITE
      - CAP_SYS_NICE
      - CAP_CHOWN
    deploy:
      resources:
        limits:
          memory: 2048M
        reservations:
          memory: 2048M

I do have the following custom files in dnsmasq.d on the guest machine:
99-edns.conf:

edns-packet-max=1232

99-hostname.conf:

domain=example.com

99-local_servers.conf (domains are obfuscated):

server=/a.example.com/2.31.172.in-addr.arpa/172.31.2.1
server=/b.example.com/3.31.172.in-addr.arpa/172.31.3.1
server=/c.example.com/4.31.172.in-addr.arpa/172.31.4.1
server=/d.example.com/5.31.172.in-addr.arpa/172.31.5.1
server=/e.example.com/6.31.172.in-addr.arpa/172.31.6.1
server=/f.example.com/10.31.172.in-addr.arpa/172.31.10.3
server=/g.example.com/172.31.3.1

I can see that the pihole-FTL.conf file indeed contains the environment variables from the docker-compose.yml file:

#; Pi-hole FTL config file
#; Comments should start with #; to avoid issues with PHP and bash reading this file
LOCAL_IPV4=172.31.4.102
PIHOLE_PTR=HOSTNAMEFQDN

Unfortunately, the outcome is ultimately almost the same: localhost is now used instead of pi.hole to refer to the pihole instance.

Have you possibly already tried ommitting the fqdn notation as hostname?
So just putting

instead?
Just an idea as I've not seen an fqdn being used as a host's name before (and do not do that myself).

I just tried removing FQDN from the servicename, containername and hostname, but unfortunately, it does not change anything :frowning:

I guess that's expected - requests originating from a loopback address (127.0.0.1) will always be shown as localhost.