Container initialization is super confusing about icinga2 HOT 7 CLOSED

I have created a docker-compose file for this image and also created volumes to persist the configuration so far. After starting the container anew I couldn't log in with any password

Have you seen the envs ICINGAWEB2_ADMIN_PASS and ICINGAWEB2_ADMIN_USER? If you change them to your old values, all should be ok again. But do change the icingaweb2 login inside icingaweb2.

To fix my issue I added all password related environment variables to the docker-compose file. However now the icinga2 backend is not running. I guess that's due to some configs being auto generated.

Mount /var/log/icinga2 as a volume and look into startup.log file.

Is there a way to recover this installation?

Yes, there is definitely a way to recover it. You might have seen #67, there we have added new environment-variables.

Generally, I recommend looking at the README-file. We added plenty of config-options.

from icinga2.

I wonder why /opt/run does not check if the instance is already configured and tries to re-create configs and certificates upon every start?

We recreate all things which might not have been configured, but take care to only overwrite the specifics. So everything, which is settable via ENV, we will overwrite, because your ENV should hold the correct value and the container should be configured according to the ENV.

In your case, we hit a sad corner case. With #67, we started configuring the icingaadmin login via ENVs and did not hardcode it anymore. So either login via the default (icingaadmin:icinga) or set the corresponding ENVs.

from icinga2.

Ok, thanks for the insight. I think I know what happened and this might not be that much of a corner case.

1. First I started the container via "docker run..." so everything was configured by /opt/run.
2. Then I created docker volumes to persist the data and a docker-compose file without setting the ENV variables. /opt/run ran again and configured everything anew.
3. I then worked with that instance for a few days and set everything up the way I liked it.
4. Restarted again via "docker-compose" still without having any ENV variables set.

That's when I hit the problem where I couldn't log in. The default password didn't work and the one I set before for icingaadmin via the web interface/director didn't work either. That's because the docker volumes contained config files with passwords that didn't matched the ones which were configured now when I started the container again.
To fix the issue I started once more and added all ENV variables containing the passwords which were auto-generated on the last run.
The only problem now is that the icinga2 daemon does not run because upon config validation it finds values that do not match with those saved in the mysql db.

critical/config: Error: Validation failed for object 'my_icinga_server.com' of type 'Endpoint'; Attribute 'zone': Object 'a33fed3d9c94' of type 'Zone' does not exist. Location: in /var/lib/icinga2/api/packages/director/a33fed3d9c94-xxx-2/zones.d/a33fed3d9c94/agent_endpoints.conf: 6:1-6:44

So I guess I need to hunt down all occurrences of old node names and update them.

I think it makes sense to add a disclaimer to the docker description warning users that all values which are not set via ENV variables will be re-created and might clash with ones the user might have created before (or in the mean time).

from icinga2.

I think it makes sense to add a disclaimer to the docker description warning users that all values which are not set via ENV variables will be re-created and might clash with ones the user might have created before (or in the mean time).

We added these bits some days ago. PR #67 changed the paradigm how to configure and run the container. The paradigm-change was needed to fix old bugs (#40, #50 ...). I feel sorry to break old installations. Personally, I have thought about that. I neither know or see a solution to handle this properly.

• showing announcements in icingaweb2 -> too late in this case
• /etc/icina2.init is saved inside the container. -> can't tell if it's an old installation

That's because the docker volumes contained config files with passwords that didn't matched the ones which were configured now when I started the container again.

Could you elaborate please? Your icingaweb2 user credentials should not be stored in an ini-file in /etc/icingaweb2-volume. The database-credentials should get update on every boot.

critical/config: Error: Validation failed for object 'my_icinga_server.com' of type 'Endpoint'; Attribute 'zone': Object 'a33fed3d9c94' of type 'Zone' does not exist. Location: in /var/lib/icinga2/api/packages/director/a33fed3d9c94-xxx-2/zones.d/a33fed3d9c94/agent_endpoints.conf: 6:1-6:44

What about wiping /var/lib/icinga2/api/packages/director? IIRC director saves its config in its DB and /var/lib/.... just contains the generated icinga2-config-dump.

from icinga2.

That's because the docker volumes contained config files with passwords that didn't matched the ones which were configured now when I started the container again.

Could you elaborate please? Your icingaweb2 user credentials should not be stored in an ini-file in /etc/icingaweb2-volume. The database-credentials should get update on every boot.

You are right, the icingaweb2 credentials are not stored in any ini files. The database credentials couldn't be update on the next boot because the database connection passwords themselves (which were saved on the docker volume in etc/icingaweb2/) did not match the new auto-generated ones.

What about wiping /var/lib/icinga2/api/packages/director? IIRC director saves its config in its DB and /var/lib/.... just contains the generated icinga2-config-dump.

Good idea, thanks. I don't know much about Icinga yet - just started out a few days ago.

from icinga2.

You are right, the icingaweb2 credentials are not stored in any ini files. The database credentials couldn't be update on the next boot because the database connection passwords themselves (which were saved on the docker volume in etc/icingaweb2/) did not match the new auto-generated ones.

Do you mind removing your volume /etc/icingaweb2, restarting your container and then manually merging the stuff in icingaweb2. I believe in your installation there are conflicting conifg-options set.

from icinga2.

Ok, it was easier to fix than I thought in the end :)
I still had a wrong node name in constants.conf. I then deleted the exported configs under /var/lib/ichinga2/api/packages/director/
and re-exported from the director.

from icinga2.