Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Icinga2 Module uses incorrect paths #45867

Closed
Nick2253 opened this issue Feb 5, 2018 · 2 comments

Comments

Projects
None yet
2 participants
@Nick2253
Copy link

commented Feb 5, 2018

Description of Issue/Question

Icinga2 changed the paths for certificates starting in version 2.8. The paths are hardcoded in the Icinga2 module, and refer to the paths for versions 2.7 and prior.

https://www.icinga.com/docs/icinga2/latest/doc/16-upgrading-icinga-2/#upgrading-to-2-8-certificate-paths

Suggestion to Fix

We could update the module and hardcode the new paths. However, this could break installs for old versions. In a perfect world, we'd be able to determine the paths automatically based on the version number.

Another option is to give the user control of the path (either create a different version of the module for the new versions, create a flag for the new paths, or an option to directly select the path). I'm not a fan of this option because it requires the user to micromanage the command/state as clients are upgraded (and is therefore no longer portable). This is especially problematic in a mixed environment.

I'm pretty comfortable doing the fixing, but I'm not sure what the best direction is. If we do want to autodetect the version, a canonical example of a different module that does it would be helpful for best practices.

Versions Report

This is an issue for the current version, and appears to still be an issue in Oxygen. As of the latest Oxygen commit in Github, the old paths were still hardcoded.

@garethgreenaway

This comment has been minimized.

Copy link
Member

commented Feb 6, 2018

@Nick2253 Thanks for the report. The paths should definitely be configurable with defaults based one standard locations. If there is a way to determine the version of icinga2 installed, perhaps with a CLI argument to a binary, that would be one way to determine the appropriate default locations by version. And we would definitely welcome a PR with this fix. Thanks!

@Nick2253

This comment has been minimized.

Copy link
Author

commented Feb 12, 2018

I'm working through the changes here, and I just had a quick question about best practices. I can get the version directly from the icinga binary, but I'm not sure where I should put the logic to get this version and determine the default paths. Should that go in the __virtual___ function?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.