Weird caching issue with PHPLDAPADMIN_LDAP_HOSTS

[stefandesu]

Hi, I think I found a weird caching issue with the environment variable PHPLDAPADMIN_LDAP_HOSTS. Here's my docker-compose file:

version: "3"
services:
  openldap:
    image: osixia/openldap
    networks:
      - traefik
    environment:
      LDAP_ORGANISATION: "${LDAP_ORG}"
      LDAP_DOMAIN: "${LDAP_DOMAIN}"
      LDAP_BASE_DN: "${LDAP_BASEDN}"
      LDAP_ADMIN_PASSWORD: "${LDAP_ADMIN_PASS}"
    hostname: openldap
    volumes:
      - ./data/ldap:/var/lib/ldap
      - ./data/slapd.d:/etc/ldap/slapd.d
    restart: always
  phpldapadmin:
    image: osixia/phpldapadmin
    networks:
      - traefik
    environment:
      PHPLDAPADMIN_LDAP_HOSTS: "openldap"
      PHPLDAPADMIN_HTTPS: "false"
    labels:
      - traefik.enable=true
      - traefik.frontend.rule=Host:ldapadmin.${DOMAIN}
    restart: always
networks:
  traefik:
    external:
      name: traefik_webgateway

The issue is that even if I change PHPLDAPADMIN_LDAP_HOSTS in the docker-compose file, the phpLDAPadmin site still shows and uses the old host. Only after I renamed the phpldapadmin service to phpldapadmin2, it finally got the change and it works now (took me an hour because I didn't get it...). As you can see, I haven't mounted any volumes in the phpldapadmin service, so there should be no persistent data, and the environment variable is empty if I echo it on the console. What is going on?

By the way, I thought that this might be the cause for problems described in #12.

[fanuch]

Can confirm the same.
Also using docker-compose and traefik if it matters.

I thought it was reading configs off the volume bind, but even after removing the volume I experience the same issue.

Removing the container (or renaming as mentioned) allows the PHPLDAPADMIN_LDAP_HOSTS environmental variable to load.

[stefandesu]

Now that I've gathered more experience with Docker and Compose over the last few months, I actually think that this is a normal limitation in Docker Compose and rebuilding the container is necessary to reflect changes in docker-compose.yml. From the docker-compose restart docs:

If you make changes to your docker-compose.yml configuration these changes are not reflected after running this command.

For example, changes to environment variables (which are added after a container is built, but before the container’s command is executed) are not updated after restarting.

docker-compose up -d should rebuild the container and reflect changes in docker-compose.yml. (I can't actually remember, but chances are pretty good that I only tried using restart and not up when I created the issue.)

If anyone can confirm this, I'll close the issue.

[fanuch]

I was exclusively using the up command and not the restart.

While your suggestion sounds good, the admin container was rebuilt each time the PHPLDAPADMIN_LDAP_HOSTS was changed, as changes would be detected over by docker-compose.

I can poke around at it a little more to see if there is an edge case I may have been experiencing.

Thanks for your reply!

[cskwrd]

I have just run into this myself! I have also found the answer 😃!

The issue is due to either this line in the Dockerfile or this line in the startup script, depending on your perspective.

What happens is when the container is created, an anonymous (unnamed) volume is created to persist all of the phpLDAPadmin data. The config.php file storing the server's config is placed in this volume after all of the provide env/config transforms have been applied. This volume isn't removed when you make changes to the compose file and then run docker compose up or docker compose restart, so when startup.sh is executed the existing config.php is detected and the config transforms are skipped.

In my own compose file, I have given a name to this volume so I know it is there, and will just remove the volume as needed to refresh my config.

I have opened #83 to make a note in the project README, instead of making an attempt at some sort of bug fix. I am not familiar with the project nor dockerfiles to provide an ideal solution.

[fanuch]

Well discovered @cskwrd!

As far as a fix, I believe it would be closer to a standard if the project didn't create anonymous volumes but rather suggested a volume map to the host filesystem; seeing as this is meant to be a dockerized solution.

Could be as simple as removing that line from the Dockerfile and modifying the README to include:

... -v $(PWD)/data/:/var/www/phpldapadmin/ ...

or:

...
volumes:
  - $(PWD)/data/:/var/www/phpldapadmin/ 
...

I never had success using this project so I might leave that to someone else to test and PR if this is a valid solution.