Wrong directory permissions if first start has additional mounted files

[mcktr]

Hi,

if I start the container for the first time and I have additional files mounted (e.g. a IDO configuration file) the data directory got wrong permissions and Icinga 2 is not able to start. You have to first start the container without any additional file mounted, afterwards you can restart the container with additional mounted files.

The following docker-compose setup does not start.

version: "3.7"

volumes:
        icinga-data:

services:
        icinga-core:
                image: icinga/icinga2:2.12.3
                restart: unless-stopped
                volumes:
                        - icinga-data:/data
                        - ./many.conf:/data/etc/icinga2/conf.d/many.conf
                        - ./ido-mysql.conf:/data/etc/icinga2/features-enabled/ido-mysql.conf
                        - ./api-users.conf:/data/etc/icinga2/conf.d/api-users.conf

Log:

icinga-core_1      | [2021-01-19 14:54:03 +0000] information/DockerEntrypoint: Initializing /data as we're the init pess (PID 1)
icinga-core_1      | [2021-01-19 14:54:03 +0000] information/DockerEntrypoint: Checking "/data/etc/icinga2"
icinga-core_1      | [2021-01-19 14:54:03 +0000] information/DockerEntrypoint: Checking "/data/var/cache/icinga2"
icinga-core_1      | [2021-01-19 14:54:03 +0000] information/DockerEntrypoint: Checking "/data/var/lib/icinga2"
icinga-core_1      | [2021-01-19 14:54:03 +0000] information/DockerEntrypoint: Checking "/data/var/log/icinga2"
icinga-core_1      | [2021-01-19 14:54:03 +0000] information/DockerEntrypoint: Checking "/data/var/run/icinga2"
icinga-core_1      | [2021-01-19 14:54:03 +0000] information/DockerEntrypoint: Checking "/data/var/spool/icinga2"
icinga-core_1      | [2021-01-19 14:54:03 +0000] information/DockerEntrypoint: Checking "/var/lib/icinga2/certs/ca.cr
icinga-core_1      | [2021-01-19 14:54:03 +0000] information/DockerEntrypoint: Looking up "dumb-init" in $PATH
icinga-core_1      | [2021-01-19 14:54:03 +0000] information/DockerEntrypoint: Running "/usr/bin/dumb-init"
icinga-core_1      | [2021-01-19 14:54:04 +0000] information/cli: Icinga application loader (version: v2.12.3)
icinga-core_1      | [2021-01-19 14:54:04 +0000] information/cli: Loading configuration file(s).
icinga-core_1      | [2021-01-19 14:54:04 +0000] critical/cli: Could not compile config files: Error: Function call '::ifstream::open' for file '/etc/icinga2/icinga2.conf' failed with error code 2, 'No such file or directory'
icinga-core_1      |
icinga-core_1      |    (0) Compiling configuration file '/etc/icinga2/icinga2.conf'
icinga-core_1      |

Permissions:

# docker-compose exec icinga-core ls -lah /data/etc/icinga2

total 16K
drwxr-xr-x 4 root root 4.0K Jan 19 14:51 .
drwxr-xr-x 3 root root 4.0K Jan 19 14:51 ..
drwxr-xr-x 2 root root 4.0K Jan 19 14:51 conf.d
drwxr-xr-x 2 root root 4.0K Jan 19 14:51 features-enabled

The directory should be recursively owned by the icinga user and group.

It should be possible to start the container from the very beginning with mounted configuration files.

Best regards Michael

[coredump17]

I also ran into this issue. Is this something that is being looked at/ reviewed?

[FibreFoX]

This looks strange, I would never think of mounting something into a different mount.

Looking at other issues like https://github.com/moby/moby/issues/26051 nested mounting has a lot of problems, so maybe having that /data mount inside a named volume seems not the right solution here.

Other issues regarding mount nesting: https://github.com/docker/for-mac/issues/5748 https://github.com/moby/moby/issues/26157 https://github.com/moby/moby/issues/40109 https://github.com/moby/moby/issues/39723

Instead of having - icinga-data:/data, did you try to just use - ./data:/data instead? @mcktr

[julianbrost]

The directory should be recursively owned by the icinga user and group.

These are parent directories of mount points for volumes you specified, so these were created by Docker, so Docker chose these permissions. Those are a fine default, but don't work out if another user should then use that directory structure.

So what could we do about this? We could run the entry point as root and try to fix things up there, but that's always something where you have to be really careful not to mess things up.

If we take a step back, I think the goal here is to add some config files unconditionally (i.e. always take that file, no matter if initializing a fresh node or running an existing instance). This could probably also be achieved by providing an additional directory where you can add custom configuration.

For now, you could try something like this as an workaround:

Mount the following file at /etc/icinga2-custom/icinga2.conf:

include "/etc/icinga2/icinga2.conf"
include_recursive "/etc/icinga2-custom/conf.d"

Then mount your custom configuration in /etc/icinga2-custom/conf.d/something.conf and set the command to icinga2 daemon -c /etc/icinga2-custom/icinga2.conf.

I think the container should provide some mechanism like this, but getting this right requires some more effort, as this should then also work for things like /etc/icinga2/zones.d/ for example.