Weird behaviour when mounting /etc/icinga2/*

[preske87]

In standard and initial situation, e.g. when starting the container with a volume mount to /etc/icinga2, this volume is empty and on first startup the respective content will be generated. Next startup, content remains, because it is persistent.

But I noticed a weird behaviour in the following situation:

• Start from scratch
• Have a docker-compose.yml pointing to the jordan/icinga2 docker image
• in the compose file, include a mount to a custom script, e.g. ./icinga/custom_commands:/etc/icinga2/custom

When you then spin up the container, through the mount not only will the directory /etc/icinga2/custom exist, also the parent directory /etc/icinga2 will exist. Thus on startup, it will not be generated with proper content et voila, the container will die.

A workaround now is

• to start up the container a first time without the mount to /etc/icinga2/custom, but only to the empty docker volume /etc/icinga2/custom and then
• rebuild / restart the container with the additional mount

But that is only a rather nasty workaround...

Is there any way to include not only custom icingaweb modules, but custom commands? Or any other way to prepopulate the container with custom content, e.g. predefined files under /etc/icinga2/conf.d/? I was considering a complete separate file structure, e.g. /etc/icinga_custom, but either it needs to be symlinked or copied or the config needs to be made aware - and then we're back to the issue that content under /etc/icinga2 needs to be prepopulated with non-default stuff..

[jjethwa]

Hi @preske87

I'm currently away, but will be back next week. There are too many variations to handle for what a user might do, so the assumption was that if anything was under /etc/icinga2, the user had already created the correct configurations. The basic check is here: https://github.com/jjethwa/icinga2/blob/master/content/opt/setup/50-icinga2#L17 You could modify the check to ignore your custom directory or modify the icinga2 helper script to copy over the contents of /etc/icinga_custom once the defaults are copied over. I'd be happy to review a PR, but I think the best option would be to use the Director module as it's already included and has a variety of options for importing configs. Let me know what you think.

[preske87]

Hi @jjethwa , thank you for the invitation. I wanted to take the liberty to create a new branch and raise a pull request from there. But github tells me I am not allowed to create a new branch :(

Thus my idea:

Create a new file /content/opt/setup/69-post-installation-custom with following content

#!/bin/bash

if [ ! -z "$CUSTOM_POST_INSTALLATION_SCRIPT" ]
then 
    echo "Executing "$CUSTOM_POST_INSTALLATION_SCRIPT
    bash $CUSTOM_POST_INSTALLATION_SCRIPT
else
    echo "Environment variable CUSTOM_POST_INSTALLATION_SCRIPT is not set, will not execute any post installation script"
fi

Extend the table with the environment variables in README.md with this line

| `CUSTOM_POST_INSTALLATION_SCRIPT`| *unset* | Allows to specify a bash script, which is e.g. mapped through volume, which is executed at the end of the setup. Through this script it is e.g. possible to establish symlinks or copy files into default directories. |

When defining the container then, one can set this variable and have any freedom to execute code after the setup. That's I think the most flexible solution.

I happy you accept it.

[jjethwa]

Hi @preske87

That looks good, I can test it when I get back. You can create a fork of the repo, make changes to the fork, then send a PR over to this repo so you get the credit 😃

[preske87]

Thank you @jjethwa , there is the PR: #295

[jjethwa]

Thanks @preske87 I'll review it asap next week 😄

[jjethwa]

Hi @preske87

Thanks again for the PR, just merged it and a build is running now. The latest tag should be available for testing in 15-30 minutes. Really appreciate it 😄

[preske87]

Hurray, after #297 it works properly

[jjethwa]

Thanks, @preske87 you rock! 😃