Extend Image: Add own Config + Enable LDAP Auth

[Avalarion]

Hey Jordan, Hey Guys and Girls,

I love this image and would totally love to use this for a few of my projects. As I need some stuff on a regular base I am not able to manage a whole instance of icinga2 manually. I would love to have one folder where I am able to include or exclude additional stuff.

Sure, I am able to write a small script, extend this image, but I would love to create a pull request to make this available to everyone.

So, first question:

• I would create one folder outside of /etc/icinga2 so I am able to mount it separatly and add include_recursive "${MyNewFolder}" to icinga2.conf.

Would that suite your approach, or is there a better solution for that? This way I would be able to have the application of icinga in a docker container and the configuration of all tests in an git repository ( for example ).

Additionally I need LDAP for all my instances so all of my co workers are able to just login and use this instance. Which seams to be no problem at all ( https://docs.icinga.com/icinga2/latest/doc/icingaweb/chapter/authentication#authentication-configuration-ldap-authentication ).

So second question:

• I would love create one config file and mount this as volume to have the configuration available.

Would that fit you as well or do I need to think on another solution? Is there perhaps a better way?

Greetings from Germany,

Bastian

[bebehei]

Are you familiar with docker? If not, you can read their volume-tutorial.

At the end of the day, you only have to mount the volumes /etc/icinga2/ and /etc/icingaweb2/ into your container. If those folders never have been mounted before, the container deploys initial configuration. Later on, you can add your own configuration, too. So there is no need to have an extra include_recursive.

I think most of the questions are solved just by mounting those two volumes.

Additionally I need LDAP for all my instances

LDAP ist not supported in an automatic manner. You're able to configure this manual: After first bootup, login to icingaweb2 and define manually an additional authentication-backend to match your LDAP-Server.

Greets from Stuttgart.

[bebehei]

Also, if you think there is a need for automatic LDAP support, create a new PR. On my own setup I don't use LDAP, and therefore I cannot add LDAP-Support myself without testing.

[Avalarion]

Hey ho,

yep, I am familiar with docker, but the initial reason for having an additional folder with configuration is because else I would have the need to configure things like mysql config within my git repository and not from the icinga2 image... So I am in the need of something, that is not part of the image so I am able to drop the whole image if required but have my git repo outside. And as far as I know a volume inside a volume is not possible.

So, now LDAP:

I would add this as optional feature like graphite. Perhaps only one config file that you are able to mount, if it is mounted LDAP will be loaded on start up, if it is not mounted LDAP will not be loaded so you will not be forced to use it.

[bebehei]

yep, I am familiar with docker, but the initial reason for having an additional folder with configuration is because else I would have the need to configure things like mysql config within my git repository and not from the icinga2 image...

Ok, let me explain the container to you:

1. Start the container with icinga2/icingaweb2 folders mounted.
   • container will add initial configuration, if you
2. Add your icinga2 configuration, by either:
   • Copy your git-folder manually into conf.d of the icinga2-volume.
   • Merge your git-folder into the root of your icinga2-volume and add all files into .gitignore, which are not relevant and only used for the container.
3. In your case, too: Add your icingaweb2-configuration neccessary to speak with your local LDAP-Server.
4. Restart the container, have fun! 😃

I would add this as optional feature like graphite. Perhaps only one config file that you are able to mount, if it is mounted LDAP will be loaded on start up, if it is not mounted LDAP will not be loaded so you will not be forced to use it.

Yep, full ACK. It should be something optional. But instead of using files, use ENVs instead. Files are not easy to update and confuse the setups. Feel free to add PRs. At least the code inside the image has to work.

[jjethwa]

Hi @Avalarion

I agree with with @bebehei as this will get you to a good starting point with the default container configs + your specific configurations which you can store in git. I think that will be cleaner and require less management on your side.

For LDAP, the required modules are already installed so you should be good to go once you drop in your config using the volume 😄

[Avalarion]

Hey Guys,

I get your point, but I am not able to do this with a single "git" task...

If I'll use git for the conf.d folder no temporary configuration file will be created on start up as the folder exists and apt-get is not required to create the basic files. Also the database configuration is not created ( for example ).

A solution would be to add the whole /etc/icinga2 folder to git, but that would not separate monitoring configuration from application configuration and to separate that makes sense.

Another solution would be to manually copy my /etc/icinga2/conf.d but that would force me to do manually work I would love to skip...

So the last solution in my opinion would be some kind of flag to drop /etc/icinga2/conf.d/* and add something like /etc/icingaConf. I would add this folder to git and have all the configuration in git but the build part of the icinga2 container will not be disturbed.

But back to your solution. Please tell me what I did wrong or where I think in a wrong direction, but right now I am sure that we need to have an additional folder that can be mounted and not check

1.) Folder Structure in Git:

➜ docker.newIcinga git:(master) ls -R docker-compose.yml icinga

./icinga: etc

./icinga/etc: icinga2

./icinga/etc/icinga2: conf.d

./icinga/etc/icinga2/conf.d: api-user.conf app.conf commands.conf groups.conf notifications.conf services.conf timeperiods.conf api-users.conf apt.conf downtimes.conf hosts.conf satellite.conf templates.conf users.conf

2.) Docker Compose Part

➜ docker.newIcinga git:(master) cat docker-compose.yml version: '2' services: icinga2: image: jordan/icinga2 restart: on-failure:5 hostname: icinga2 ports: - 2009:80 environment: - ICINGA2_FEATURE_GRAPHITE=1 - ICINGA2_FEATURE_GRAPHITE_HOST=graphite - ICINGA2_FEATURE_GRAPHITE_PORT=2003 - ICINGA2_FEATURE_GRAPHITE_URL=http://graphite - ICINGAWEB2_ADMIN_USER=Test - ICINGAWEB2_ADMIN_PASS=Test volumes: - ./icinga/cache:/var/cache/icinga2 - ./icinga/certs:/etc/apache2/ssl:ro - ./icinga/etc/icinga2:/etc/icinga2 - ./icinga/etc/icingaweb2:/etc/icingaweb2 - ./icinga/lib/icinga:/var/lib/icinga2 - ./icinga/lib/mysql:/var/lib/mysql - ./icinga/lib/php5/sessions:/var/lib/php5/sessions - ./icinga/log/apache2:/var/log/apache2 - ./icinga/log/icinga2:/var/log/icinga2 - ./icinga/log/icingaweb2:/var/log/icingaweb2 - ./icinga/log/mysql:/var/log/mysql - ./icinga/spool:/var/spool/icinga2 graphite: image: bebehei/graphite:latest restart: on-failure:5 hostname: graphite volumes: - ./graphite/lib:/var/lib/graphite - ./graphite/log/apache:/var/log/apache2 - ./graphite/log/graphite:/var/log/graphite - ./graphite/log/carbon:/var/log/carbon

Greetings,

Bastian

[jjethwa]

Hi @Avalarion

I understand your point about wanting to separate application configurations from monitoring configuration. Personally, I like to keep the entire configuration directory/directories in source control since I would need both application configuration and my personal monitoring configuration in order to get things running. It might require me to sync application configs if a major release touches them, but I think it's better to keep track of them as they usually find a way to bite you in the future 😛

Lets us know what you think. If that does not suit your needs, we can add the include directive as you suggested.