icinga / docker-icinga2 Goto Github PK

Hello Everyone!

I'm currently trying to automatically configure icinga with this Dockerfile. Many things are working pretty good, but I'm currently dealing with the problem that I cannot enable features (in my case influxdb) automatically (instead of icinga2 feature enable influxdb). I found the PR here: #18 but this doesn't seem to be very active anymore. Is there already another way to achieve this or is this not possible at the moment? For icingaweb2 this worked pretty smooth for modules and env-variables.

Thank you in advance!

Hi,

I am currently evaluating a Icinga 2 docker setup. During my evaluation I came across the topic mail notification, currently I see no possibility to send such from a container based on this image. Is it possible to add this feature?

I found a icinga2 docker image which has this possibility, the image integrated msmtp to send mails:

https://github.com/jjethwa/icinga2#sending-notification-mails

Thanks and best regards
Michael

In the docker image 2.13.3 / bullseye libldap-common is missing.
It was installed in 2.13.2 / buster.
This results in /etc/ldap/ldap.conf not existing and check_ldap can't be configured.

We should agree on a versioning scheme for this project so we can start building a roadmap with milestones as soon as possible.

There are several versions involved and we should decide which version will be represented where.

Things to consider and things that came up in discussions within the team:

• We want to support several versions of Icinga 2 at the same time
• The base image has its versions, too. Since we're running in Docker this shouldn't make any difference and could be ignored. Nevertheless we should provide for a way to update packages aside from Icinga related tools aka build on newer base images
• We should definitely agree on a versioning scheme that works for all Icinga related containers to come. There's no need for synchronised versions, but the logic should work everywhere

It looks like a good idea to have versions for the Docker specific repositories (like this one) which are completely disconnected from the versions of the tools that are to be dockerized and the base image. The question is, should the version be in any case reflected in the tags and versions of the containers? At a first glance, I'd say no. The user cares if they are using Icinga 2.11.3 or Icinga 2.12.0 but not if the container was built with version 1.2 or version 5.13 of the Dockerfile. On the other hand, what if we need to change something on the interfaces to the outside world? By now we haven't devided on how to get configuration into the container. What if we don't choose wisely and have to change it later on?

The short version would be to just use semantic versioning for this repo (esp. the Dockerfile).

Hello,

today I wanted to try Icinga2. Since I like hosting services using containers I didn’t bother installing Icinga using packages but headed straight here. I executed the commands from the README and tried to access the published port 5665 using my web browser. This is what I was greeted with after following the steps outlined in the README:

The "master" container logged this every time I tried to access http://localhost:5665:

[2024-03-26 08:19:50 +0000] critical/ApiListener: Client TLS handshake failed (from [::ffff:192.168.65.1]:59360): http request

After 30 minutes of wondering what was wrong, I had the idea that the container would do TLS termination itself by default. This is rather unusual as a default since most images expect you to place a reverse proxy in front of them. So I tried https://localhost:5665 and was greeted with a login dialog.

The login dialog did not accept default credentials I tried - like admin/admin. A Google search brought up the auth docs but this page does not list the default login. The https://default-password.info/icinga/icinga-web-2 page suggests to use icingaadmin/icinga - which didn't work either.

This is where I'm currently stuck.

I hope this feedback helps to improve the onboarding process for new users. I can see how as developers or long-term users of Icinga the initial setup must be obvious to you. As a new user who doesn't know the ins and outs of the system it might feel very differently.

Using the image icinga/icinga2:master, which should be based on Icinga/icinga2@04704a4, --version shows r2.12.0-rc1-1 but should be v2.12.0-rc1-52-g04704a49a (which is based on git describe):

[noah@noh-mb ~/docker-icinga ]$ docker-compose exec master-1 icinga2 --version
icinga2 - The Icinga 2 network monitoring daemon (version: r2.12.0-rc1-1)

Copyright (c) 2012-2020 Icinga GmbH (https://icinga.com/)
License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl2.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

System information:
  Platform: Debian GNU/Linux
  Platform version: 10 (buster)
  Kernel: Linux
  Kernel version: 4.9.184-linuxkit
  Architecture: x86_64

Build information:
  Compiler: GNU 8.3.0
  Build host: 2fa768b72e8c
  OpenSSL version: OpenSSL 1.1.1d  10 Sep 2019

Icinga2 contains a definition for the check_nrpe command: https://github.com/Icinga/icinga2/blob/master/itl/command-plugins.conf#L2316

therefore the dependency for this command should also be installed.

E.g. check plugins.

I'm trying to bring up icinga/icinga2 and icinga/icingaweb2 with Podman; looks good so far. Could you please comment on whether these images could possibly run as rootless containers? Inspection of the Dockerfile (with USER icinga and USER www-data respectively) suggests that this could be the case; on the other hand I currently observe that mail is app. not working in a rootless instance of icinga/icinga2 (but it is working on a non-rootless instance that was started with Docker). What is your general recommendation on rootless operation of these images?

It would be tempting to run the icinga2 container without a pid namespace, i.e. with --pid=host, to allow checks to see all processes/threads on the host.

However, the entrypoint program only initializes the data dir if its own PID is 1, which is obviously not the case with --pid=host. Is there a good reason for this behaviour? Why do we ony initialize if pid==1? Why not initialize whenever the dirs don't exist?

Just /usr/lib/x86_64-linux-gnu/icinga2/sbin/icinga2 is 282.2 MiB. (?!)

The whole thing: 1GB.

Hi,

I am facing the following situation on a fresh Icinga 2 docker container (tag: 2.13.3).

sudo docker run -ti -h i2m1 -p 5666:5665 icinga/icinga2:2.12.3 bash

[2021-01-21 10:42:54 +0000] information/DockerEntrypoint: Initializing /data as we're the init process (PID 1)
[2021-01-21 10:42:54 +0000] information/DockerEntrypoint: Checking "/data/etc/icinga2"
[2021-01-21 10:42:54 +0000] information/DockerEntrypoint: Copying "/data-init/etc/icinga2" to "/data/etc/icinga2"
[2021-01-21 10:42:54 +0000] information/DockerEntrypoint: Checking "/data/var/cache/icinga2"
[2021-01-21 10:42:54 +0000] information/DockerEntrypoint: Copying "/data-init/var/cache/icinga2" to "/data/var/cache/icinga2"
[2021-01-21 10:42:54 +0000] information/DockerEntrypoint: Checking "/data/var/lib/icinga2"
[2021-01-21 10:42:54 +0000] information/DockerEntrypoint: Copying "/data-init/var/lib/icinga2" to "/data/var/lib/icinga2"
[2021-01-21 10:42:54 +0000] information/DockerEntrypoint: Checking "/data/var/log/icinga2"
[2021-01-21 10:42:54 +0000] information/DockerEntrypoint: Copying "/data-init/var/log/icinga2" to "/data/var/log/icinga2"
[2021-01-21 10:42:54 +0000] information/DockerEntrypoint: Checking "/data/var/run/icinga2"
[2021-01-21 10:42:54 +0000] information/DockerEntrypoint: Copying "/data-init/var/run/icinga2" to "/data/var/run/icinga2"
[2021-01-21 10:42:54 +0000] information/DockerEntrypoint: Checking "/data/var/spool/icinga2"
[2021-01-21 10:42:54 +0000] information/DockerEntrypoint: Copying "/data-init/var/spool/icinga2" to "/data/var/spool/icinga2"
[2021-01-21 10:42:54 +0000] information/DockerEntrypoint: Checking "/var/lib/icinga2/certs/ca.crt"
[2021-01-21 10:42:54 +0000] information/DockerEntrypoint: Looking up "dumb-init" in $PATH
[2021-01-21 10:42:54 +0000] information/DockerEntrypoint: Running "/usr/bin/dumb-init"      
icinga@i2m1:/$ /usr/lib/nagios/plugins/check_icmp -H 127.0.0.1
check_icmp: Failed to obtain ICMP socket: Operation not permitted

From a quick research this is caused by missing permission for the user. I don't know if other plugins are also affected, but I can tell that check_ping works fine for example.

icinga@i2m1:/$ /usr/lib/nagios/plugins/check_ping -H 127.0.0.1 -w 10,10% -c 20,20%
PING OK - Packet loss = 0%, RTA = 0.06 ms|rta=0.063000ms;10.000000;20.000000;0.000000 pl=0%;10;20;0

Best regards
Michael

Snippet from the output when running build.bash:

+ make test
Running tests...
Test project /i2cp/build
No tests were found!!!

Other projects use different ways of bringing configuration for Icinga 2 into the container.

Options already discussed:

• Mounting an external volume where you just put your configuration and have it loaded
• Using a reusable configuration and fill it with environment variables

Are there other ideas? Submitting more configuration via API might be doable but needs a basic configuration nonetheless.

The version information included in the latest master images is broken:

$ docker pull icinga/icinga2:master
[...]
$ docker run --rm -it icinga/icinga2:master icinga2 --version
[...]
icinga2 - The Icinga 2 network monitoring daemon (version: a0239e4)
[...]

The commit is from the icinga2 repository but the version number based on the latest tag is missing. Might be due to a shallow clone happening somewhere (and therefore tags not being available). The problem was possibly introduced in #73, but I haven't looked into this any closer.

The readme says:

Most of the following variables correspond to icinga2 node setup CLI parameters. If any of these is present and icinga2 node setup has not been run yet, it will run. Consult the node command documentation on what are which parameters for.

Which links you here: https://icinga.com/docs/icinga2/latest/doc/11-cli-commands/#cli-command-node

But that link has no information about that the parameters do (for instance --endpoint) is there documentation somewhere for icinga2 node setup?

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

Hi i use icinga2 and icingaweb2 as two different docker container, who can i use icingacli vspheredb check vm --name VMNAME to check services if the command and installation is on a different container

We agreed on having tests to ensure the containers are doing what we need. As soon as we have a first working version we should start writing tests for like we agreed in the first meeting / readme file.

This needs at least #1 to be closed to make any sense.

I have Icinga2 successfully running on my docker. However, I'm not able to login to icinga web at :5665

The information I googled on the web and Icinga website doesn't seem to provide a clue either.

Can someone advise me?

So I try to run the script and it obviously runs the Dockerfile and it fails gloriously for me.

1. libboost in build-icinga2 stage, ok I sesolve this by simply installing libboost-all-dev. Not pretty but its for a test anyway.
2. COPY --from=icinga2-git, there is no stage with that name or is there some other magic involved that somehow should resolve this?

On a sidenote:

If I just try the docker run comments it works for the paster but the agent it dont want to find a .key file

[2024-01-10 11:32:49 +0000] critical/SSL: Error loading and verifying locations in ca key file '/var/lib/icinga2/certs//ca.crt': 185090184, "error:0B084088:x509 certificate routines:X509_load_cert_crl_file:no certificate or crl found" [2024-01-10 11:32:49 +0000] critical/config: Error: Cannot make SSL context for cert path: '/var/lib/icinga2/certs//icinga-agent.crt' key path: '/var/lib/icinga2/certs//icinga-agent.key' ca path: '/var/lib/icinga2/certs//ca.crt'. Location: in /etc/icinga2/features-enabled/api.conf: 4:1-4:24 /etc/icinga2/features-enabled/api.conf(2): * The API listener is used for distributed monitoring setups. /etc/icinga2/features-enabled/api.conf(3): */ /etc/icinga2/features-enabled/api.conf(4): object ApiListener "api" { ^^^^^^^^^^^^^^^^^^^^^^^^ /etc/icinga2/features-enabled/api.conf(5): /etc/icinga2/features-enabled/api.conf(6): accept_config = false [2024-01-10 11:32:49 +0000] critical/config: 1 error [2024-01-10 11:32:49 +0000] critical/cli: Config validation failed. Re-run with 'icinga2 daemon -C' after fixing the config.

So what would be the steps to resolve this or is docker just a proof of concpt at this stage?

cheers

MArkus

I miss the documentation about this part!

./build.bash 
+ I2SRC=
+ '[' -z '' ']'
+ cat
Usage: ./build.bash /icinga2/source/dir
+ false

???

so that Compose can tell whether we actually started successfully.

Running the container for a while will produce thousands of zombie process until all check start failing

icinga   2411824 3668603  0 04:34 ?        00:00:00 [ping] <defunct>
icinga   2411826 3668603  0 04:34 ?        00:00:00 [ping] <defunct>
icinga   2412155 3668603  0 04:35 ?        00:00:00 [ping] <defunct>
icinga   2412162 3668603  0 04:35 ?        00:00:00 [ping] <defunct>
icinga   2412164 3668603  0 04:35 ?        00:00:00 [ping] <defunct>
icinga   2412560 3668603  0 04:36 ?        00:00:00 [ping] <defunct>
icinga   2412572 3668603  0 04:36 ?        00:00:00 [ping] <defunct>
icinga   2412574 3668603  0 04:36 ?        00:00:00 [ping] <defunct>
icinga   2412948 3668603  0 04:37 ?        00:00:00 [ping] <defunct>
icinga   2412952 3668603  0 04:37 ?        00:00:00 [ping] <defunct>
icinga   2412954 3668603  0 04:37 ?        00:00:00 [ping] <defunct>
icinga   2413246 3668603  0 04:38 ?        00:00:00 [ping] <defunct>
icinga   2413285 3668603  0 04:38 ?        00:00:00 [ping] <defunct>
icinga   2413287 3668603  0 04:38 ?        00:00:00 [ping] <defunct>
icinga   2413646 3668603  0 04:39 ?        00:00:00 [ping] <defunct>
icinga   2413691 3668603  0 04:39 ?        00:00:00 [ping] <defunct>
icinga   2413693 3668603  0 04:39 ?        00:00:00 [ping] <defunct>
icinga   2414028 3668603  0 04:40 ?        00:00:00 [ping] <defunct>
icinga   2414037 3668603  0 04:40 ?        00:00:00 [ping] <defunct>
icinga   2414039 3668603  0 04:40 ?        00:00:00 [ping] <defunct>
icinga   2414369 3668603  0 04:41 ?        00:00:00 [ping] <defunct>
icinga   2414375 3668603  0 04:41 ?        00:00:00 [ping] <defunct>
icinga   2414377 3668603  0 04:41 ?        00:00:00 [ping] <defunct>
icinga   2414775 3668603  0 04:42 ?        00:00:00 [ping] <defunct>
icinga   2414786 3668603  0 04:42 ?        00:00:00 [ping] <defunct>
icinga   2414788 3668603  0 04:42 ?        00:00:00 [ping] <defunct>
icinga   2415147 3668603  0 04:43 ?        00:00:00 [ping] <defunct>
icinga   2415155 3668603  0 04:43 ?        00:00:00 [ping] <defunct>
icinga   2415157 3668603  0 04:43 ?        00:00:00 [ping] <defunct>
icinga   2415449 3668603  0 04:44 ?        00:00:00 [ping] <defunct>
icinga   2415492 3668603  0 04:44 ?        00:00:00 [ping] <defunct>
icinga   2415494 3668603  0 04:44 ?        00:00:00 [ping] <defunct>
icinga   2415910 3668603  0 04:45 ?        00:00:00 [ping] <defunct>
icinga   2415968 3668603  0 04:45 ?        00:00:00 [ping] <defunct>
icinga   2415970 3668603  0 04:45 ?        00:00:00 [ping] <defunct>
icinga   2416339 3668603  0 04:46 ?        00:00:00 [ping] <defunct>
icinga   2416353 3668603  0 04:46 ?        00:00:00 [ping] <defunct>
icinga   2416355 3668603  0 04:46 ?        00:00:00 [ping] <defunct>
icinga   2416707 3668603  0 04:47 ?        00:00:00 [ping] <defunct>
icinga   2416715 3668603  0 04:47 ?        00:00:00 [ping] <defunct>
icinga   2416719 3668603  0 04:47 ?        00:00:00 [ping] <defunct>
icinga   2417270 3668603  0 04:48 ?        00:00:00 [ping] <defunct>
icinga   2417284 3668603  0 04:48 ?        00:00:00 [ping] <defunct>
icinga   2417286 3668603  0 04:48 ?        00:00:00 [ping] <defunct>
icinga   2418026 3668603  0 04:49 ?        00:00:00 [ping] <defunct>
icinga   2418897 3668603  0 04:50 ?        00:00:00 [ping] <defunct>
icinga   2418939 3668603  0 04:50 ?        00:00:00 [ping] <defunct>
icinga   2420034 3668603  0 04:51 ?        00:00:00 [ping] <defunct>
icinga   2420044 3668603  0 04:51 ?        00:00:00 [ping] <defunct>
icinga   2422232 3668603  0 04:54 ?        00:00:00 [ping] <defunct>
icinga   2423345 3668603  0 04:57 ?        00:00:00 [ping] <defunct>

There is a Basic authentication for the Webinterface, what are the Credentials? I couldnt find it anywhere.

As Icinga 2 config can be very complex, I think it would be better to generate config from templates and environment variables like the official nginx image does, instead of writing hole config files in environment variables like in the Icinga Web 2 Image.

https://github.com/nginxinc/docker-nginx/blob/1.21.6/entrypoint/20-envsubst-on-templates.sh

Templates must be stored outside of the data volume, as they could change on every start of the container.

After some debugging I have to say I'm thoroughly confused by this. :-)

% docker pull icinga/icinga2:latest
% docker run --rm icinga/icinga2:latest  icinga2 --version
icinga2 - The Icinga 2 network monitoring daemon (version: v2.13.2)
% docker pull icinga/icinga2:master
% docker run --rm icinga/icinga2:master  icinga2 --version
icinga2 - The Icinga 2 network monitoring daemon (version: r2.13.0-1)

It seems to me that :master is actually an older version than :latest. How is that intentional? Am I missing something about how docker works and am using it wrong?

This came up while trying to get the latest version of everything running to try and give feedback on resolved bug reports.

I have some custom settings that I need to set, and would like to thus customise the setup routine of the docker container.

Currently it runs some form of icinga2 node wizard, which can be customised a bit by setting some environment variables. However having a directory, where you can bind mount your own scripts into and have them start before / after the included initialisation script as needed would be much more powerful.

One of the best examples of how this can be done is - I think - the mariadb image: https://hub.docker.com/_/mariadb (see 'initialising a fresh image').

What do you think?

Due to the nature of containers on the one hand and Icinga 2 on the other hand, we have a higher risk than usual for losing CA files. (thanks to @bodsch for your feedback on this topic)

We have to make sure that every instance checks the local information about the central Icinga 2 CA.

• What to do if the container runs the config master but the CA is broken? How to detect reliably? What to do if it's broken? Output an error? Rebuild it?
• If a satellite or agent has already pulled the CA certificate but it's not valid anymore (e.g. because someone replaced the CA on the config master), pull the CA cert again and request a new certificate

In my opinion we should not:

• Check for validity in running containers on a regular basis. If the CA breaks, just restart the container
• Allow for deploying custom CA files on the config master. While it's something, some users (especially enterprise-size) sometimes request, there's no benefit from using certificates signed by a company CA safe for not having to discuss how certificates work. And there are lots of potential pitfalls when a custom certificate file is used - so I would opt against allowing replacing them.

We need a way of connecting to the database, check for the current schema and decide:

• If there's no schema at all, import the schema file
• If there's a schema but not the current one, apply all required update scripts in the correct order

So a prerequisite of the container would be to have a user who is allowed to run all .sql scripts relevant for the schema.

We shouldn't rely on lsb_release to determine which base image we are using. It's better to read /etc/os-release.

Thanks @lazyfrosch for the hint.

The built-in command check_snmp does not work because the binary snmpget is not installed.

icinga@icinga-icinga2-0:/$ /usr/lib/nagios/plugins/check_snmp -v -C xxx -H yyy ... -v
/usr/bin/snmpget -Le -t 60 -r 5 -m ...
External command error with no output (return code: 3)
icinga@icinga-icinga2-0:/$ /usr/bin/snmpget
bash: /usr/bin/snmpget: No such file or directory
icinga@icinga-icinga2-0:/$

Hi,

Whenever I run a command for starting up an Icinga2 Docker container, I receive the following error message 👍 standard_init_linux.go:211: exec user process caused "exec format error"
e.g.
docker run --rm -h icinga-host -v /data/icinga2:/data -e ICINGA_MASTER=1 icinga/icinga2 icinga2 daemon -C

I'm using the latest image version.
Please fix ASAP!

Kind regards,

Bart.

Hi Team,
What if we have snmp checks, or other checks that need specific plugins, what we should do is not posible to include those by default ?

it would be useful to add the below in the same way ICINGA_CACERT works.

ICINGA_CERT - node cert to be used to auth with master
ICINGA_CERTKEY - key to go with cert

When starting the docker container it will auto create it's own configuration via environment variables. This can be re-executed with icinga2 node wizard which also shows that the correct values are taken from the environment.

In my case, that is 'ops.my.domain' as the ICINGA_CN which leads to generated config files like this:

root@ops:/etc/icinga2# cat constants.conf
[...]
const NodeName = "ops.my.domain"
const ZoneName = "master"
const TicketSalt = "random_salt"

root@ops:/etc/icinga2# cat zones.conf
object Endpoint "ops.my.domain" {}
object Zone "master" {
	endpoints = [ "ops.my.domain" ]
}
[...]

However, when verifying the configuration via icinga2 daemon --validate this setup generates this error:

root@ops:/etc/icinga2# icinga2 daemon --validate
[2021-05-04 08:15:01 +0000] warning/Application: Failed to adjust resource limit for open file handles (RLIMIT_NOFILE) with error "Operation not permitted"
[2021-05-04 08:15:01 +0000] warning/Application: Failed adjust resource limit for number of processes (RLIMIT_NPROC) with error "Operation not permitted"
[2021-05-04 08:15:01 +0000] warning/Application: Failed to adjust resource limit for open file handles (RLIMIT_NOFILE) with error "Operation not permitted"
[2021-05-04 08:15:01 +0000] warning/Application: Failed adjust resource limit for number of processes (RLIMIT_NPROC) with error "Operation not permitted"
[2021-05-04 08:15:01 +0000] information/cli: Icinga application loader (version: r2.12.0-1)
[2021-05-04 08:15:01 +0000] information/cli: Loading configuration file(s).
[2021-05-04 08:15:01 +0000] information/ConfigItem: Committing config item(s).
[2021-05-04 08:15:01 +0000] information/ApiListener: My API identity: 9bc786c2237a
[2021-05-04 08:15:01 +0000] critical/config: Error: Endpoint object for '9bc786c2237a' is missing.
Location: in /etc/icinga2/features-enabled/api.conf: 4:1-4:24
/etc/icinga2/features-enabled/api.conf(2):  * The API listener is used for distributed monitoring setups.
/etc/icinga2/features-enabled/api.conf(3):  */
/etc/icinga2/features-enabled/api.conf(4): object ApiListener "api" {
                                           ^^^^^^^^^^^^^^^^^^^^^^^^
/etc/icinga2/features-enabled/api.conf(5): 
/etc/icinga2/features-enabled/api.conf(6):   ticket_salt = TicketSalt
[2021-05-04 08:15:01 +0000] critical/config: 1 error
[2021-05-04 08:15:01 +0000] critical/cli: Config validation failed. Re-run with 'icinga2 daemon -C' after fixing the config.

AFAIK the important bit is this:

[2021-05-04 08:15:01 +0000] information/ApiListener: My API identity: 9bc786c2237a
[2021-05-04 08:15:01 +0000] critical/config: Error: Endpoint object for '9bc786c2237a' is missing.

where it tells me that icinga seems to think it's api identity is 9bc786c2237aand that it has no endpoint configured. Where does this setting even come from? How do I override it? It doesn't seem to come from the system configuration as that is different

root@ops:/etc/icinga2# hostname
ops
root@ops:/etc/icinga2# hostname -f 
ops.my.doamin

I am missing an environment variable (or config if need be) to force icinga to assume the API identity ops.my.domain.

Maybe there is such a variable, but I can't find it in the documentation of this docker image and also not in the documentation of icinga proper. So, what do you think?

Hi all,

is there a special reason, why you hard-coded the architecture in file action-base.list

In other repos I found some kind of

echo "deb [arch=$(dpkg --print-architecture)] https://download.docker.com/linux/debian buster stable" > /etc/apt/sources.list.d/repo.list

Regards.

When looking at dockerhub, i see that there are tags for all versions, but also e.g. support-2.14.
The documentation should reflect what these tags mean and which one is the recommended one to use.

See: https://hub.docker.com/r/icinga/icinga2/tags

I am trying to use the check_dns plugin however it won't work since nslookup is missing. This should be part of the bind9-dnsutils package. Can this package be added to the image?

DNS CRITICAL - '/usr/bin/nslookup -sil' msg parsing exited with no address