After node setup with "--accept-config", ApiListener denies to accept config

[mrimann]

Describe the bug

We install icinga2 clients via some automation. Basically just adding the package repo, signing key, then install the package + configure the node + request certificate signing.

This worked like a charm in Ubuntu 16.04 and 18.04 and we ported our setup for Ubuntu 20.04 hosts. But executing the exact same node setup cli command results in an Api config that denies to accept config and commands.

To Reproduce

We execute the following command to configure the icinga2 node:

/usr/sbin/icinga2 node setup --parent_host master.domain.tld --endpoint webserver.domain.tld --zone webserver.domain.tld --trustedcert /var/lib/icinga2/certs/master.domain.tld.crt --accept-config --accept-commands --cn webserver.domain.tld

After signing the certificate of the node on the master and restarting the icinga2 client on the node, we see the following in the log file:

[2020-07-07 17:34:31 +0200] warning/ApiListener: Ignoring config update. 'api' does not accept config.
[2020-07-07 17:34:32 +0200] warning/ApiListener: Ignoring command. 'api' does not accept commands.

The config file for the api module in /etc/icinga2/features-enabled/api.conf is configured to deny the delivered config:

object ApiListener "api" {
  accept_config = false
  accept_commands = false

  ticket_salt = TicketSalt
}

Workarounds

Workaround A - manual fix

Editing /etc/icinga2/features-enabled/api.conf to be like below, then restaring the icinga2 service - everything works as is should:

object ApiListener "api" {
  accept_config = true
  accept_commands = true

  //ticket_salt = TicketSalt
}

Workaround B - automated fix

Did not try that, but applying the above mentionec correction can also be delivered via our automation. But since this worked all the years, I suspect this to be a bug in some way, and just "covering" that by automated overriding of the config files feels a bit wrong.

Expected behavior

The config should be synced from the master and the received config shall be applied and the checks starting to be executed.

Your Environment

root@webserver:~# icinga2 --version
icinga2 - The Icinga 2 network monitoring daemon (version: r2.11.2-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: Ubuntu
  Platform version: 20.04 LTS (Focal Fossa)
  Kernel: Linux
  Kernel version: 5.4.0-29-generic
  Architecture: x86_64

Build information:
  Compiler: GNU 9.2.1
  Build host: lcy01-amd64-022

Application information:

General paths:
  Config directory: /etc/icinga2
  Data directory: /var/lib/icinga2
  Log directory: /var/log/icinga2
  Cache directory: /var/cache/icinga2
  Spool directory: /var/spool/icinga2
  Run directory: /run/icinga2

Old paths (deprecated):
  Installation root: /usr
  Sysconf directory: /etc
  Run directory (base): /run
  Local state directory: /var

Internal paths:
  Package data directory: /usr/share/icinga2
  State path: /var/lib/icinga2/icinga2.state
  Modified attributes path: /var/lib/icinga2/modified-attributes.conf
  Objects path: /var/cache/icinga2/icinga2.debug
  Vars path: /var/cache/icinga2/icinga2.vars
  PID path: /run/icinga2/icinga2.pid

[Mikesch-mp]

I had the same problem with Uvuntu 20.04, because the owner of the files under /etc/icinga2/features-{available,enabled} is not nagios (which is the user for icinga2) its root after installing the packages.

Simple workaround after installing the packages is

chown -R nagios:nagios /etc/icinga2

[mrimann]

Thanks - we'll try that out.

[mrimann]

Yes, setting the permissions for /etc/icinga2/features-* seems to work (we do that automated via Puppet after the package-install).

[Al2Klimov]

@htriem Do you consider it good practice to fix https://github.com/Icinga/icinga2/issues/8111#issuecomment-659330323 at packaging level, i.e. to install that files/dirs as nagios:nagios?

[Al2Klimov]

PING

[htriem]

I've done some tests, and so far it looks like it might be a usable workaround. I don't entirely feel comfortable with this option though, using the nagios-user. I wonder about options we might have using permissions or even supplementing our docs in a way to avoid this issue.

[Al2Klimov]

I don't entirely feel comfortable with this option though, using the nagios-user.

OK. And... why exactly?

[htriem]

Honestly, it just doesn't feel right using the nagios-user when we ship a Icinga user through our packages.

[julianbrost]

Our Debian/Ubuntu packages still use the nagios user. Probably for historical reason and/or compatibility with the packages provided by Debian itself.

[Al2Klimov]

OK... details matter.

@htriem Do you consider it good practice to fix #8111 (comment) at packaging level, i.e. to install that files/dirs as $ICINGA2_USER$:$ICINGA2_GROUP$?