With versions set in /opt/otobo-docker/.env like this

OTOBO_IMAGE_OTOBO=rotheross/otobo:rel-10_0_4
OTOBO_IMAGE_OTOBO_ELASTICSEARCH=rotheross/otobo-elasticsearch:rel-10_0_4
OTOBO_IMAGE_OTOBO_NGINX=rotheross/otobo-nginx-webproxy:rel-10_0_4

it is possible to get an incomplete update to rel-10_0_6.

Symptoms:

/opt/otobo-docker# docker run -it --rm --volume otobo_opt_otobo:/opt/otobo rotheross/otobo:rel-10_0_6 copy_otobo_next
Unable to find image 'rotheross/otobo:rel-10_0_6' locally
rel-10_0_6: Pulling from rotheross/otobo

# entrypoint.sh is the old version without do_update_tasks()
root@ubuntu:/opt/otobo-docker# docker exec -t otobo_web_1 /opt/otobo_install/entrypoint.sh do_update_tasks
/opt/otobo_install/entrypoint.sh: line 44: exec: do_update_tasks: not found

In the case of 10.0.4 to 10.0.6 it results in a working installation, because there are no essential do_update_tasks.

Of course, commenting out the above settings in /opt/otobo-docker/.env and repeating the update solves the problem.

A possible improvement could be to check conflicts in version specifications and throw a warning or an error.

Cloning the correct branch of otobo-docker is a stumbling block for used. IMHO it would be more convenient if that repository would be available in https://otobo.de/en/otobo-download/.
@StefanRother-OTOBO , @svenoe : what do you think ?

Fewer capabilities are a good thing. See https://docs.docker.com/compose/compose-file/#cap_add-cap_drop .

When trying to update our otobo-docker instance using ./scripts/update.sh, the following error message is shown:

sleeping for 10s, while the database is starting up
finished with sleeping
Error: No such container: otobo_web_1
Error: No such container: otobo_web_1

Since we are running an OTOBO dev and prod environment on the same docker host, the containers have another name.

After looking at the update script and reading the manual (https://doc.otobo.org/manual/installation/stable/de/content/updating-docker.html), it seems like the docker exec calls should be replaced by docker-compose exec.

Executing the commands from the docs manually with the correct container names can be used as a workaround.

Optimise the build time, especially on docker hub.

Local builds take advantage of Docker layer caching. Therefore builds are fast when the required Debian packages and CPAN modules did not change. The subjective impression is that this does not apply for builds on Docker hub.

TODO:

• investigate whether Docker Hub takes advantage of layer caching
• if not, try to make Docker Hub do so
• as a fallback, create a base image with only the the dependencies and use that

Now that we have a scripts/devel dir, let's add some helpers:

• login
• quick setup
• run tests
• show test progress
• ...

For setting up the HTTPS terminating proxy nginx, user must currently configure the complete path to the certificate file in the environment settings OTOBO_NGINX_SSL_CERTIFICATE and OTOBO_NGINX_SSL_CERTIFICATE_KEY. This is even required when they use the same file and directory names that are mentioned in the installation manual. The setup is also error prone, as it easy to forget about specifying the complete path. So this can be improved. The requirement is that existing configs,with the complete path, continue to work as expected.

TODO:

• remove unhelpful default that is set up in the image itself
• provide sane defaults, as laid out in the installation manual, in docker-compose/override-https*.yml
• support for OTOBO_NGINX_SSL_DIR
• compatability with the current behavior
• update the installation manual

Hello,
managed to setup the Containers but the Daemon, as well as the Web Containers, won't Start and the Log, says:
"su: cannot set groups: Operation not permitted".

Im running the Docker Containers on a Debian 9 machine with the following Docker Compose:
docker-compose version 1.26.2, build eefe0d31
docker-py version: 4.2.2
CPython version: 3.7.7
Docker 19.03.13

This was suggested in https://otobo.de/en/forums/topic/centos8-firewall-externen-zugriff-auf-docker-unterbinden/ .

For firewall configuration it apparently would be desirable to be able to explicitly configure the IP via the .env file. See also https://docs.docker.com/compose/compose-file/compose-file-v3/#ports.

Thanks to Michael R..

Ich habe die Datei /opt/otobo-docker/docker-compose/otobo-override-http.yml angepasst:

services:
web:
ports:
- "192.168.10.1:${OTOBO_WEB_HTTP_PORT:-80}:5000"

Damit scheint es zu laufen.

Vielleicht könnte man das über die .env-Datei konfigurierbar machen, z.B. über eine Variable OTOBO_WEB_IP, welche standardmässig auf 0.0.0.0 gesetzt ist.

Viele Grüsse,
Michael

LetsEncrypt/certbot is very convenient for automatic renewal of SSL-certificates.

Many users are not very experienced in ordering and installing SSL-certificates.

IMHO it's worth some lines more in the docs or maybe support setup of certbot.

Also the verification (HTTP/HTTPS) should be tested, as it needs a key delivered in HTML, which needs write access.

Seems nginx needs a fullchain.pem.

Qote of `/etc/letsencrypt/live/www.mydomain.com/README

This directory contains your keys and certificates.

`privkey.pem`  : the private key for your certificate.
`fullchain.pem`: the certificate file used in most server software.
`chain.pem`    : used for OCSP stapling in Nginx >=1.3.7.
`cert.pem`     : will break many server configurations, and should not be used
                 without reading further documentation (see link below).

WARNING: DO NOT MOVE OR RENAME THESE FILES!
         Certbot expects these files to remain in this location in order
         to function properly!

We recommend not moving these files. For more information, see the Certbot
User Guide at https://certbot.eff.org/docs/using.html#where-are-my-certificates.

Nginx is not as well supported as Apache by certbot. But there should be scripts and HOWTOs somewhere.

OTOBO might need to access different data sources that are installation specific. For example an installation might need access to the list of customers in a Microsoft SQL Server database. Therefore it is convenient to add drivers for some databases in the Docker image.

For now let's go for:

• Postgresql

• Oracle (propably not feasible)

• OBDC (via unixodbc)

• SQLite

Following the docs on https://doc.otobo.org/manual/installation/stable/en/content/installation-docker.html, I'm trying to install on debian buster, which fails with Unknown capability to add: "CAP_CAP_SYS_CHROOT" and "CAP_CAP_SETUID". Please see below for details. This looks like a typo, but I have no idea where to go to try to fix it. Can someone please help out?

root@otobo01:/opt/otobo-docker# docker-compose up --detach
WARNING: The NGINX_ENVSUBST_TEMPLATE_DIR variable is not set. Defaulting to a blank string.
Creating network "otobo_default" with the default driver
Creating volume "otobo_mariadb_data" with default driver
Creating volume "otobo_opt_otobo" with default driver
Creating volume "otobo_elasticsearch_data" with default driver
Creating volume "otobo_redis_data" with default driver
Pulling elastic (rotheross/otobo-elasticsearch:latest)...
latest: Pulling from rotheross/otobo-elasticsearch
75f829a71a1c: Pull complete
12a20a45aa50: Pull complete
7d49bb9ac613: Pull complete
98dcf7a2301a: Pull complete
26d68d841d2e: Pull complete
db71e2f6acdd: Pull complete
6d58f7bd0cd7: Pull complete
161752ba6659: Pull complete
8adf2f929b9e: Pull complete
042adb24e282: Pull complete
dac7e9e91c12: Pull complete
801c7fcdc0c0: Pull complete
Digest: sha256:00a979c112f235b5e56a02425a043d18d8fa20547fe8da56b103c0fe1a6914af
Status: Downloaded newer image for rotheross/otobo-elasticsearch:latest
Pulling db (mariadb:10.5.5)...
10.5.5: Pulling from library/mariadb
d72e567cc804: Pull complete
0f3630e5ff08: Pull complete
b6a83d81d1f4: Pull complete
4bf2111ecf0e: Pull complete
9572d64978a0: Pull complete
bcc9953bffb3: Pull complete
de429570dda5: Pull complete
3652bc6ea9f9: Pull complete
6e4bf87041c8: Pull complete
9cb9bba22391: Pull complete
9de10906fc5c: Pull complete
2c3a798c7a1f: Pull complete
Digest: sha256:9d27dd15564ba13a8ffa93beee20b39b7c14218c47ea296c6e11878a77962d12
Status: Downloaded newer image for mariadb:10.5.5
Pulling redis (redis:6.0.8-alpine)...
6.0.8-alpine: Pulling from library/redis
188c0c94c7c5: Pull complete
fb6015f7c791: Pull complete
f8890a096979: Pull complete
1ab9e54597f5: Pull complete
aea83659e879: Pull complete
75cca444dec7: Pull complete
Digest: sha256:eedaa0059551597b8205b0ab33e6f23ac2da2a507e24bcb53409e0538f74da0a
Status: Downloaded newer image for redis:6.0.8-alpine
Pulling web (rotheross/otobo:latest)...
latest: Pulling from rotheross/otobo
b9a857cbf04d: Pull complete
d557ee20540b: Pull complete
3b9ca4f00c2e: Pull complete
667fd949ed93: Pull complete
4ad46e8a18e5: Pull complete
5e397b98e2c3: Pull complete
44f83e053171: Pull complete
bdb1b2f4bbc0: Pull complete
fcf4d2d1bfe7: Pull complete
0b34260fd1ba: Pull complete
4a72cd5acc1c: Pull complete
ad6cfd48ad17: Pull complete
cb56050b5c8a: Pull complete
da0b93a6801e: Pull complete
1d41f4ab2022: Pull complete
9f85f710fb1f: Pull complete
1a8f0ad9d9cb: Pull complete
704ed2b732ba: Pull complete
efd7c7199dd0: Pull complete
a7e81ee55940: Pull complete
Digest: sha256:075b0bab8ee85d7f73646993e79cf4e217e62dc50bc88e35aa735293843d600c
Status: Downloaded newer image for rotheross/otobo:latest
Pulling nginx (rotheross/otobo-nginx-webproxy:latest)...
latest: Pulling from rotheross/otobo-nginx-webproxy
45b42c59be33: Pull complete
d0d9e9ea897e: Pull complete
66e650438339: Pull complete
76a3dfe4406b: Pull complete
410ff9d97480: Pull complete
f1a49221f4c5: Pull complete
5aa86c7d3316: Pull complete
08357f5e8d11: Pull complete
472f957ac40e: Pull complete
Digest: sha256:2b2b5dbf1492b0d0da45961b6dbcf38f4424d52eb7459feb9dd5819fa7c9490d
Status: Downloaded newer image for rotheross/otobo-nginx-webproxy:latest
Creating otobo_elastic_1 ... error
Creating otobo_redis_1 ...
Creating otobo_db_1 ...

Creating otobo_db_1 ... error
Creating otobo_redis_1 ... done
ERROR: for otobo_db_1 Cannot start service db: linux spec capabilities: Unknown capability to add: "CAP_CAP_SYS_CHROOT"

ERROR: for elastic Cannot start service elastic: linux spec capabilities: Unknown capability to add: "CAP_CAP_SETUID"

ERROR: for db Cannot start service db: linux spec capabilities: Unknown capability to add: "CAP_CAP_SYS_CHROOT"
ERROR: Encountered errors while bringing up the project.

Hi,

as soon as several OTOBO environments are running on one server, the script update.sh does not work anymore, because there hardcoded the service "web" is called.

But when I set up multiple environments, I give different names to the environments.
So we have to find out in the script first what the OTOBO container is called.

Thanks,

Stefan

I think it would be nice to log slow queries by default.

To do that you could pass command line parameters to mariadb.

/opt/otobo-docker/docker-compose/otobo-base.yml:

[...]
db:
    [...]
    command: [...] --slow-query-log=ON --slow-query-log-file=<file_name> --long-query-time=<SECONDS>

It's bad enough the .env is a hidden file. Make at least the sample files visible.

I am currently trying to get OTOBO running with working Kerberos auth using docker-compose/otobo-override-https-kerberos.yml.
Unfortunately this seems to be more complicated, than it seems. Probably we need to add some more documentation about this.

What did I try:
I prepared the krb5.conf and the krb5.keytab file to make it available within the NGINX container. Of course I also added the additional ENV vars to my .env file.

What happens?
When I start the compose setup, it seems as the NGINX wouldn't even have Kerberos enabled.
A quick look into /etc/nginx/conf.d/otobo_nginx.conf showed, that Kerberus is commented out by default.
As a side note: there seems to be a bug in the template, but I didn't find the git repo for this docker image.
The line # auth_gss_keytab ${OTOBO_NGINX_KERBEROS_KEYTAB}; should probably be auth_gss_keytab /etc/krb5.keytab;, as the ENV variable is only used outside the NGINX container and used for mounting the keytab to /etc/krb5.keytab.

When trying to modify the otobo_nginx.conf within the container and restart it for debugging, the file gets overwritten by the template. In order to fix this, I tried to mount my own config as read-only into the NGINX container. Unfortunately this doesn't work as the init script within the container bails out:

nginx_1    | /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
nginx_1    | /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
nginx_1    | /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
nginx_1    | 10-listen-on-ipv6-by-default.sh: info: /etc/nginx/conf.d/default.conf is not a file or does not exist
nginx_1    | /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
nginx_1    | 20-envsubst-on-templates.sh: Running envsubst on /etc/nginx/templates/otobo_nginx.conf.template to /etc/nginx/conf.d/otobo_nginx.conf
nginx_1    | /docker-entrypoint.d/20-envsubst-on-templates.sh: 26: /docker-entrypoint.d/20-envsubst-on-templates.sh: cannot create /etc/nginx/conf.d/otobo_nginx.conf: Read-only file system

How is the intended use for this and where is the correct location to add some documentation about OTOBO with Kerberos?

Cheers, Andreas

Running the Selenium tests with HTTPS is harder than running only with HTTP. Provide a sample .env file for that case.

In my default docker install as per the instructions, I keep getting this error every 30 seconds:

2022-08-18T09:10:54.660415+08:00 redacted otobo_db_1[2520297]: 2022-08-18  1:10:54 27458 [Warning] Access denied for user 'mysql'@'10.x.x.x' (using password: NO)

otobo-base.yml there is this healthcheck - I think it needs the string "--password ${OTOBO_DB_ROOT_PASSWORD}"?

46     healthcheck:
47       test: mysqladmin ping -h db ping

According to the manpage for mysqladmin:

ping

Check whether the server is available. The return status from mysqladmin is 0 if the server is running, 1 if it is not. This is 0 even in case of an error such as Access denied, because this means that the server is running but refused the connection, which is different from the server not running.

The healthcheck works, but is currently spamming my logs.

Michael suggested this on the OTOBO Community Forum in the thread https://otobo.de/en/forums/topic/docker-logs-auf-lokalem-host-unter-centos8/.
Adding tags to the logs written by the containers can be very useful. E.g. for configuring dedicated logfiles for each service. Michael suggests:

  # service db
   logging:
      options:
        tag: "otobo_db_1"
 # service web
    logging:
      options:
        tag: "otobo_web_1"

I would suggest to remove the '_1' as there can be multiple containers per service. IMHO this can be done already for OTOBO 10.0.10.

Nginx redirect from http:// to https:// does not work

The redirect land on https://localhost

Adapt scripts/devel/generate_sample_env_files.sh so that it also generates _ .docker_compose_env_https_kerberos_. Just like the other four sample docker compose files.

Currently docker-compose/otobo-base.yml contains hardcoded patchlevel releases of the MariaDB and Redis images. It should be checked whether these images still receive security update.

Issue description

ISSUE: mysqladmin zombie processes are appearing minutely that aren't reaped. The parent process is mysqld.

• The operating system is Ubuntu Server LTS 20.04.3 LTS
• docker-compose version 1.29.2, build 5becea4c
  docker-py version: 5.0.0
  CPython version: 3.7.10
  OpenSSL version: OpenSSL 1.1.0l 10 Sep 2019
• Server: Docker Engine - Community
  Engine:
  Version: 20.10.12
  API version: 1.41 (minimum version 1.12)
  Go version: go1.16.12
  Git commit: 459d0df
  Built: Mon Dec 13 11:43:42 2021
  OS/Arch: linux/amd64
  Experimental: false
  containerd:
  Version: 1.4.12
  GitCommit: 7b11cfaabd73bb80907dd23182b9347b4245eb5d
  runc:
  Version: 1.0.2
  GitCommit: v1.0.2-0-g52b36a2
  docker-init:
  Version: 0.19.0
  GitCommit: de40ad0
• Git release rel_10-1 Otobo Docker runs with Otobo Version 10.0.15

Steps to reproduce the issue

1. Install VM with Ubuntu Server 20.04.3 LTS
2. cd /opt
3. git clone https://github.com/RotherOSS/otobo-docker.git --branch rel-10.1 --single-branch
4. sudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
5. sudo chmod +x /usr/local/bin/docker-compose
6. curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
7. sudo apt-get update
8. sudo apt-get install docker-ce docker-ce-cli containerd.io
9. cp /opt/otobo-docker/.docker_compose_env_http /opt/otobo-docker/.env
10. vi .env -> Set Database password
11. docker-compose up -d
12. Follow the Otobo Installer.pl until the end.
13. Log into root@localhost
14. zombie processes are appearing from now on
15. docker-compose restart -> all zombie processes get sigterm, but they reappear shortly

What's the expected result?

• no zombie processes like in rel-10.0

What's the actual result?

• minutely theres an additional zombie process in rel-10.1. The parent process is mysqld, the orphaned child is mysqladmin.

Additional details / screenshots

t

There should be a single source for the documentation and that is https://github.com/RotherOSS/doc-otobo-installation/blob/master/content/installation-docker.rst.

Hi,

I try to change the port inside the .env file:

OTOBO_DB_ROOT_PASSWORD=otobo_root
  
# set this var when the HTTP port is not 80
OTOBO_WEB_ROOT_HTTP_PORT=8080

# Elasticsearch options
OTOBO_ELASTICSEARCH_ES_JAVA_OPTS=-Xms512m -Xmx512m

COMPOSE_PROJECT_NAME=otobo
COMPOSE_PATH_SEPARATOR=:
COMPOSE_FILE=docker-compose/otobo-base.yml:docker-compose/otobo-override-http.yml

After starting docker-compose up -d the following error occurs:

Starting otobo_web_1     ... error

ERROR: for otobo_web_1  Cannot start service web: driver failed programming external connectivity on endpoint otobo_web_1 (20c165298f2508f8de26b7122398da16a13d1bf64f76af10e66dc5da6df448ed): Error starting userland proxy: listen tcp 0.0.0.0:80: bind: address already in use

Port 8080 is not used.

Thanks,

Stefan

Hi,

I think it's a good idea to define some health checks for our Otobo docker image. Example:

https://effective-docker.github.io/docker-healthchecks/

Another idea is to define the checks in our docker-compose file, that's, possible too!

Thanks,

Stefan

After installing with new docker-compose, 1.28.2, on docker 20.10.3, all seems to work, but when I try to connect to the server in a web browser, I get this

An Error Occurred

Access denied for user 'otobo'@'172.19.0.5' (using password: YES)

I have set a root password in .env, otherwise, nothing special. Anything that should be done here? Can't find any clues in the docs.

This warning is emitted when starting the Nginx service in a Docker-based installation. It should be suppressed as it is the regular case that NGINX_ENVSUBST_TEMPLATE_DIR is not set.

The docker setup files are fairly stable, But things like internal port numbers or required volumes are subject to change. Therefore create a tag for each OTOBO release.

TODO:

• create a tag for 10.0.4
• add creation of the tag in the otobo-docker git repository
• add instructions to the devel manual, or wherever the release procedure is documented

It's a known issue. We need to fix it with a workarround.

Although it's possible to run the database as a container, it's known that databases growths fast and usually can have performance issues due it's running inside containers.

It would be important to have a way to configure on .env file the host, database name, user and password.

This allows for more flexible setups.

Found a small issue with the minio service. It does not survive a reboot of the Docker host. Propably need to add:

restart: always

to docker-compose/otobo-minio.yml.

Originally posted by @bschmalhofer in #99 (comment)

Hi,

We add a new cronfile to /opt/otobovar/cron/ and execute bin/Cron.sh. After restart the otobo container the crontab entry is missing again. Perhaps we need to execute bin/Cron.sh again?

Thanks,

Stefan

Hello,
im stuggeling to impliment LDAP with OTOBO.
i´ve installed OTOBO with the .docker_compose_env_http
Was that a misstake?
Greetings
Steffen

Getting the message that the Daemon is not running (rel-10_1) when it is definitely running.

Checked status via ./otobo.Daemon.pl status and it shows as working fine. Stopped/started it. Same thing. I can even see its status messages scrolling by in the console.

Dear Dev

I try configuration email in otodo-docker but i got many error about email send and fetch

Install guide not available from repo url

Some new versions have been released since Docker support for OTOBO has started. Go and get those shiny new versions.

While discussing this, @svenoe and me found that allowing the users to set these versions via .env would be a good idea. Let's do this in a separate issue.

Originally posted by @bschmalhofer in #65 (comment)

The containers should not run as root.

TODO:

• otobo_db_1
• otobo_elastic_1
• otobo_nginx_1
• otobo_redis_1

Hello,

today i updated OTOBO from 10.1.4 to 10.1.5 and my otobo-db-1 container fails healthcheck. After inspecting this container i found a lot of mysqladmin defunct proceses piling up on every healthcheck.

After inspecting the logs i found that there is a command not found error and that this command is part of the database password, it looks like the healthcheck script is not escaping correctly, i have certain special characters in the database password that may be the cause.

I solved it editing "docker-compose/otobo-base.yml" and changed "mysqladmin -h db --user=root --password=${OTOBO_DB_ROOT_PASSWORD} ping" with the real pasword in single quotes.

The healthcheck script for the database should be changed to quote whatever come with ${OTOBO_DB_ROOT_PASSWORD} variable.

Testing the support for operation in a cluster is not straightforward. Furthermore we need to test at least S3 support from localstack and MinIO. There is a bit of support for localstack. So let's add setup for MinIO. Also, we need at least two web servers on separate file systems so that we can test the syncing of config, CSS, JS, and article data.

Multiple instances can be run by passing --scale web=2 to docker-compose. But in the current setup this is problematic, as the same port can't be exposed twice on the Docker host. There are at least two options to avoid this problem:

1. expose the ports on two different random ports
2. expose the web server ports via a Nginx load balancer that makes use of the round robin in the Docker DNS

Option 2. is very cheap to implement as we already have Nginx running for supporting SSL. See https://pspdfkit.com/blog/2018/how-to-use-docker-compose-to-run-multiple-instances-of-a-service-in-development/ nad

In the files .docker_compose_env_http* there are lines like:
scripts/update.sh

For use with scripts/update.sh, otovar_XXX() will be replaced

#OTOBO_IMAGE_OTOBO=otovar_REPOSITORY()otobo:otovar_TAG()

These are sample settings to be used in /opt/otobo-docker/dot_env.m4 and the ,env file is generated with scripts/devel/generate_dot_env.sh. The comment mentions scripts/update.sh, which is nonsense.

TODO:

• Fix the comment line.

Currently docker-compose 1.25 is required. This is because 1.25 is the default version of docker-compose on Ubuntu 20.04, which was the primary environment used for developing the OTOBO The goal is to support Ubuntu 18.04 which ships with docker-compose 1,17,

It looks like the only showstopper is the usage of e.g. MYSQL_ROOT_PASSWORD: ${OTOBO_DB_ROOT_PASSWORD:?err} which should bail out when a variable is not set. Support for ?err was added to docker-compose in version 1.19.

TODO:

• eliminate usage of ?err.
• update the documentation
• test on Ubuntu 18.04

Possible Mitigation: elastic/elasticsearch#81618

But we need to make sure, that the fix breaks no OTOBO functionalities.

The name otobo_selenium-chrome_1 is not sensible where there multiple instances of OTOBO running on the same server.
See https://blog.dcycle.com/blog/ae67284c/docker-compose-cp for how to adapt docker cp-

TODO:

• change docker execto docker-compose exec
• change docker cpto docker-compose cp

entrypoint.sh should print a sensible message when called without an argument.

See RotherOSS/otobo#1078 for the details.

The support data collector reports:

Warning Größe Abfrage-Cache (1048576)

Die Einstellung query_cache_size sollte genutzt werden (mehr als 10 MB aber nicht mehr als 512 MB).

So, the MariaDB query cache size should be configurable in .env
A normal setting is 33554432, so this should be the default.

The docker-compose files do have basic dependency checking configure. As far as I understand it, this only sets up the order in which the containers are started. However it looks like there is no check that the db is actually up and running before the webserver is started.
A similar situation might occur when nginx is ready but the HTTP-webserver is currently restarting.