[BUG] Wrong home directory in scheduler docker image

[Arakmar]

What happened?

During some investigation about Let's Encrypt failures (not related), I noticed this warning :

[LETS-ENCRYPT.NEW.CERTBOT] [43] [ℹ ] - unable to cache publicsuffix.org-tlds.{'urls': ('https://publicsuffix.org/list/public_suffix_list.dat', 'https://raw.githubusercontent.com/publicsuffix/list/master/public_suffix_list.dat'), 'fallback_to_snapshot': True} in /var/cache/nginx/.lexicon_tld_set/publicsuffix.org-tlds/de84b5ca2167d4c83e38fb162f2e8738.tldextract.json. This could refresh the Public Suffix List over HTTP every app startup. Construct your TLDExtractwith a writablecache_diror setcache_dir=None to silence this warning. [Errno 13] Permission denied: '/var/cache/nginx/.lexicon_tld_set'

After looking at the container, the /var/cache/nginx directory seems to be missing.
According to the Dockerfile of the scheduler, /var/cache/nginx was used because it's the home directory of the "scheduler" user.

I think the home dir should be /var/cache/bunkerweb instead. It already exists and has proper permissions.

How to reproduce?

Generate a Let's Encrypt cert with dns challenge (don't know if it happens with http challenge)

Configuration file(s) (yaml or .env)

Relevant log output

[LETS-ENCRYPT.NEW.CERTBOT] [43] [ℹ ] - unable to cache publicsuffix.org-tlds.{'urls': ('https://publicsuffix.org/list/public_suffix_list.dat', 'https://raw.githubusercontent.com/publicsuffix/list/master/public_suffix_list.dat'), 'fallback_to_snapshot': True} in /var/cache/nginx/.lexicon_tld_set/publicsuffix.org-tlds/de84b5ca2167d4c83e38fb162f2e8738.tldextract.json. This could refresh the Public Suffix List over HTTP every app startup. Construct your `TLDExtract` with a writable `cache_dir` or set `cache_dir=None` to silence this warning. [Errno 13] Permission denied: '/var/cache/nginx/.lexicon_tld_set'

BunkerWeb version

1.6.0-rc2

What integration are you using?

Docker

Linux distribution (if applicable)

No response

Removed private data

• I have removed all private data from the configuration file and the logs

Code of Conduct

• I agree to follow this project's Code of Conduct

[TheophileDiot]

Hi @Arakmar, thank you for bringing this to our attention. It does seem like an oversight on our part, and we truly appreciate you taking the time to report it.