Not getting logs to troubleshoot connection issues?

[surfrock66]

I'm setting up PhpLDAPadmin using docker compose, and I've created a writeable logs directory which I've mounted into the container. My docker compose looks like this (with redactions):

services:
  php-ldap-admin:
    image: phpldapadmin/phpldapadmin
    restart: always
    volumes:
      - /etc/pla/logs:/app/storage/logs
      - /etc/pla/sessions:/app/storage/framework/sessions
    ports:
      - 80:8080
    environment:
      APP_KEY: 'base64:++++++++='
      LDAP_HOST: 'directory.subdomain.domain.tld'
      APP_TIMEZONE: 'America/Los_Angeles'
      APP_DEBUG: 'true'
      LDAP_NAME: 'Surfrock66 LDAP'
      LDAP_CONNECTION: 'starttls'
      LDAP_LOGIN_OBJECTCLASS: 'domainAccount'
      LDAP_PORT: '389'
      LDAP_LOGIN_ATTR: 'uid'
      LDAP_BASE_DN: 'dc=subdomain,dc=domain,dc=tld'

I'm not getting anything created int he logs folder though, so I'm not able to troubleshoot the connection issues with my ldap environment. I think if I can get logs out, I'll be ok to continue to troubleshoot, but I don't understand why there's no log files being written at all?

[leenooks]

Its sounds like you have an environment problem. You might need to look at your docker container log, or get in the container and try and write a file to /app/storage/logs/ manually and see if that works. (As user www-data).

[surfrock66]

I actually tried that; I was able to write outside the container just fine (though as a weird user id, 82). I made a test.txt as www-data and it was created in the parent folder as user ID 82:

[leenooks]

Being able to write to the dir outside the container, doesnt prove anything. You should be testing whats going on inside the container.

Some other tests you can try, remove the log volume and stop/delete/restart the container - is something written in /app/storage/logs? If yes, then the problem is related to your volume mount. If no, you'll need to go do a different determination route. ie: are things starting?

edit - I just re-read your graphic, and see that you are testing inside the container - great. OK, still do the volume remove isolation test and if still no log, explore what is running.

/app $ ps -af
PID   USER     TIME  COMMAND
    1 www-data  7:05 frankenphp run --config /etc/caddy/Caddyfile --adapter caddyfile
65418 www-data  0:00 sh
67319 www-data  0:00 ps -af

[surfrock66]

Ok, removed the logs mount, and then from an exec session I'm still not seeing any log files being written. The front end is up and I can try to log in (though that fails, which is an LDAP issue I was hoping to use the logs to troubleshoot):

"APP_DEBUG" is set to true, but otherwise I am not doing anything that should modify logging. Just for testing, I also fully removed the mount line from logs then tried again, same result. It feels like the web server isn't logging in there?

[leenooks]

I just did the following:

docker run -it --rm -p 8080:8080 -e LDAP_HOST=ldap.lan -e LOG_LEVEL=debug --name pla phpldapadmin/phpldapadmin

And pointed my browser at localhost:8080, then

# docker exec -it pla sh

/app $ find storage/logs/
storage/logs/
storage/logs/.gitignore
storage/logs/laravel-2025-08-22.log

/app $ cat storage/logs/laravel-2025-08-22.log
[2025-08-22 02:46:40] production.DEBUG: MAL:Accept Language changed from [en] to [en-GB] from Browser (en-GB,en;q=0.9)
[2025-08-22 02:46:40] production.DEBUG: SVR:Getting []
[2025-08-22 02:46:40] production.DEBUG: SVR:DN CACHEABLE -
[2025-08-22 02:46:40] production.DEBUG: SVR:= Got []
...

[surfrock66]

I was mainly looking to it to troubleshoot my LDAP issues, it's fine if it's a container environment issue, just a weird quirk.

[surfrock66]

While I still think there's an issue there, I fixed my LDAP issues so it's not super pressing.

One thing though, I'm using apache as a reverse proxy, and I'm finding a ton of resources are being served over http instead of https, including javascript. My proxy is upgrading those to https which is fine, if I copy the source paths and load them I get served them over https, but the browsers (firefox and chrome) are failing to render because they disallow mixed content. I have to basically break the proxy and navigate to the source server, not the proxy server, to make it work.

Am I missing something? I don't see a config option to specify a baseurl, or to specify https inside the container, which would force the rendering to make all source paths "https" instead of "http". I've been looking for the environment variables here: https://github.com/leenooks/phpLDAPadmin/wiki/Configuration-Variables

[leenooks]

I provide an example of implementing PLA behind a proxy in the wiki. I cant help you with apache though, havent used it in decades.

[surfrock66]

I'm looking here: https://github.com/leenooks/phpLDAPadmin/blob/37b4db8a3ff0ef783b3833cfa701fc71cfc77a8f/resources/themes/architect/views/layouts/partials/htmlheader.blade.php

And the assets are provided referencing an "asset" function, which I assume is part of the framework. In my proxy setup, these are getting the url redirected, but they remain "http" and not "https".

I think this is a documented limitation of laravel; there's a mechanism to effectively allow trusted proxies, which could be configured to be an environment variable? https://laravel.com/docs/5.5/requests#configuring-trusted-proxies

[surfrock66]

I figured it out, here's my apache config in case it's useful to anyone else:

<VirtualHost *:80>
        ServerName subdomain.domain.tld
        ServerAlias subdomain.domain.tld
        ServerAlias *.subdomain.domain.tld
        Redirect permanent / https://subdomain.domain.tld
        ErrorLog ${APACHE_LOG_DIR}/error.subdomain.log
        LogLevel warn
        CustomLog ${APACHE_LOG_DIR}/access.subdomain.log combined
        LimitRequestLine 20000
</VirtualHost>

<VirtualHost *:443>
        ServerName subdomain.domain.tld
        ServerAlias subdomain.domain.tld
        ServerAlias *.subdomain.domain.tld
        RewriteEngine on 
        RewriteCond %{HTTP:Upgrade} =websocket [NC]
        RewriteCond %{HTTP:Connection} upgrade [NC]
        ProxyPass / http://DOCKERCONTAINERHOSTNAME/ upgrade=websocket
        ProxyPassReverse / http://DOCKERCONTAINERHOSTNAME/
        ProxyPreserveHost On
        ProxyRequests Off
        RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
        RequestHeader set "X-Forwarded-SSL" expr=%{HTTPS}
        ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
        <Directory "/usr/lib/cgi-bin">
                SSLOptions +StdEnvVars
                AllowOverride None
                Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
                Require all granted
        </Directory>
        ErrorLog ${APACHE_LOG_DIR}/error.subdomain.log
        LogLevel warn
        CustomLog ${APACHE_LOG_DIR}/access.subdomain.log combined
        SSLEngine on
        SSLCertificateFile /etc/ssl/certs/wildcard.domain.tld.crt
        SSLCertificateKeyFile /etc/ssl/private/wildcard.domain.tld.key
        SSLCACertificateFile /etc/ssl/certs/intermediate.domain.crt
        SSLProxyEngine          On
        SSLHonorCipherOrder On
        SSLProtocol all -SSLv2 -SSLv3
        SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK
        SSLInsecureRenegotiation off
        <FilesMatch "\.(cgi|shtml|phtml|php)$">
                SSLOptions +StdEnvVars
        </FilesMatch>
        BrowserMatch "MSIE [2-6]" \
                nokeepalive ssl-unclean-shutdown \
                downgrade-1.0 force-response-1.0
        # MSIE 7 and newer should be able to use keepalive
        BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
</VirtualHost>