icinga / ansible-icinga2 Goto Github PK

refs #12

I tried to install this ansible role but the command:

ansible-galaxy install icinga.icinga2

failed with the message:

- downloading role 'icinga2', owned by icinga [WARNING]: - icinga.icinga2 was NOT installed successfully: - sorry, icinga.icinga2 was not found on https://galaxy.ansible.com. ERROR! - you can use --ignore-errors to skip failed roles and finish processing the list.

Enable and disable the feature. Set all configuration parameters with sane defaults.

refs #12

Hi there,

what do you all think about changing the behavior of i2_custom_features to use the feature-available folder instead of the features-enabled folders and use the original icinga command "icinga2 feature enable/disable" to manage the features?

Changes needed:

i2_custom_features

• i2_custom_features need to create new feature configs inside features-available instead of features enabled.
• Maybe rename i2_custom_features to i2_create_features

I would add another variable to make it possible to name the config file other then the feature. F.e. name the file for the ApiListener "api" too.

i2_features

• i2_features need to use the icinga command to enable/disable commands instead of deleting them, directly in the folder.
• i2_feature need to get config option like i2_custom_feature, but instead of replacing the feature like i2_custom_features will do, it will regex replace lines in the exiting configs.
• Add "enabled: true/false" as config variable
• Maybe renaming i2_features to i2_manage_features

Maybe add a "disable_none_managed: true" variable to remove all conf files in features-enabled before configuring. Still not sure, how to do that without doing it on every run.

Example:

i2_manage_features:
  disable_none_managed: "true"
  api: 
    enable: true 
    config: 
      accept_commands: "true"
  notifications:  
    enable: false 

refs #12

Configuration of all IDO PostgreSQL configuration parameters. Enable and disable the feature. Additionally it can import the basic schema to a defined database. If importing is enabled, it expects an existing database, user and password.

refs #12

Is there any interest in supporting gentoo, particularly gentoo with openrc (as opposed to systemd)? I'd be happy to contribute, but first I need to know if this is important to the maintainers.

refs #12

When executing this Playbook:

- name: icinga Package
  hosts: icingaagents
  roles:
    - icinga2
  vars:
    - i2_custom_features:
      ApiListener:
        api:
          accept_command: true
          accept_config: true
    - i2_confd: []

I get this Error:

TASK [icinga2 : include icinga2-features.yml] ****************************************************************************************************************************************************************
fatal: [1.1.1.1]: FAILED! => {"msg": "The conditional check 'i2_features|flatten|length > 0' failed. The error was: Unexpected templating type error occurred on ({% if i2_features|flatten|length > 0 %} True {% else %} False {% endif %}): 'NoneType' object is not iterable\n\nThe error appears to be in '/etc/ansible/roles/icinga2/tasks/main.yml': line 21, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: include icinga2-features.yml\n  ^ here\n"}

When i change this task to "is defined":

- name: include icinga2-features.yml
  include_tasks: icinga2-features.yml
  #when: i2_features|flatten|length > 0
  when: i2_features is definded

i get:

`TASK [icinga2 : generate enabled feature configuration] ******************************************************************************************************************************************************
fatal: [1.1.1.1]: FAILED! => {"msg": "with_dict expects a dict"}

`

It looks like variable i2_features is empty when the task is executed, but i can't find a solution for that.

The Release package without i2_features works, but can't enable features. I also had some problems to understand why there is i2_features and i2_custom_features at the beginning. Why not use only one variable for both and add switches to custom_features like enable: true

Decide what’s the best method to run unit and integration tests and implement basic tests that are extended as the development continues.

Potential options:

• Molecule: https://github.com/metacloud/molecule
• Test Kitchen

Implement some basic testing with TravisCI to catch syntax, linting and gross errors.

The Icinga 2 package is installed from the official repository by default. If the official repo is not included, the operating systems default is used.

Keep the supported distributions in mind.

Take care that the Icinga process is running and is enabled after the installation. Be mindflus of RHEL/CentOS SElinux limitations.

refs #12

refs #12

refs #12

refs #12

Default configuration files should be configurable based on templates. This affects:

• icinga2.conf
  • include constants
  • include zones.conf
  • include plugins (itl, plugins, plugins-contrib, ...)
  • include features-enabled/*.conf
  • include conf.d directory or alternative
  • manage/create included config directories
• constants.conf
  • add default constants like PluginDir, NodeName etc.
  • add custom constants

Don't touch any other directory or configuration file managed by the Icinga 2 package for now. Files and directories should only be managed by Ansible if necessary.

Take care that the Icinga process is reloaded/restarted after configuration changes.

A general helper that can enable and disable features and change configuration for a feature.

Following options come to my mind:

• Use the existing icinga2_feature module. Don't know if this is sufficiant
• Extend the existing icinga2_feature module.
• Use a generic template and enable features by adding symlinks, like icinga2 does.

No specific feature options are set here.

A reload/restart of Icinga is triggered if a feature is enabled/disabled or the configuration changes.

Every specific feature allows the configuration of its settings. Some features may have extended functionality, such as importing data schemas.

Example implementation with templates: https://github.com/mkayontour/icinga2-ansible/tree/master/roles/icinga2-feature-handler
Another example implementation with templates: https://github.com/chrnie/ansible-role-icinga2

Feedback is very welcome, I don't know what's the best "ansible way" here.

Hello @flokoe

as you are the new maintainer we are happy to see some change and results on the project.
We @lbetz (maintainer of the icinga puppet module) and I want to contribute and help out on a few topics. We have some time and motivation to spare.

We had a meeting the other day and discussed a few things, which we want to change or add.
Please feel free to comment on them, add your notes and share your thoughts.

Extract the repo management into an extra role.

In future we think that the role to install and configure Icinga 2 won't be the last one.
We need to consider, that after Icinga 2, we need the following roles to cover all Icinga 2 components.

• icingaweb2
• icingadb
• icinga-redis
• maybe more?

So to keep the repo management consistent over all icinga* roles we think its best to extract the part and publish it into an separate role. Then it would be possible to use it as a dependency for the roles.

Certificate Generation for Clients/Agents

As Icinga 2 provides a few ways to generate certificates for clients, we had the discussion which way would be the best to choose. Ansible provides a key feature which enables us to easily generate certificates on the CA system.

So we suggest to generate and sign the certificates on the CA system by using delegate_to and provide them to the client.

Manage "role" in Icinga Environment

On the topic how we define a client or master in Ansible we discussed it's best to let the user choose which features to use. As many our environments are so uniq and therefore we can't define how a master, satellite or agent should look like.

So we decided we should stick with using features to design the Icinga instance.

In addition to this, the CA isn't a feature in Icinga terms, but something we need to take care like a feature.
There should be a variable to define if the system contains the Icinga 2 CA.
i2_ca = true

Icinga 2 config, objects, attributes and parser

Config Path

Icinga 2 provides the possibility to distribute monitoring over multiple locations, but also as a single instance if the monitoring environment isn't that big or there are no remote/DMZ location.

So the user need to choose if he uses a single instance or want to use Icinga 2 distributed.
In this case we thought about how we want to provide the monitoring configuration over Ansible.

First of all, the user need a variable to choose whether he wants to define the configuration in zones.d, custom.d directory or none if the API maybe is used.

i2_objects_dir: custom.d/
or
i2_objects_dir: zones.d/

Monitoring Code/Config

With this information we know now, where to put monitoring configuration files per default.
Then we need to give the user the ability to use its own structure. Of course we can generate the configuration in one big blob and dump it into the configuration directory but in case anyone want to debug something manually it won't be easy and frustrating.

So we came up with the following example:

i2_objects:
  - path: "{{ i2_objects_dir }}/satellite/hosts.conf"
    objects:
      - Host:                       #object type
          client01.localdomain:     #object name
            display_name: client01  #object attributes
            [...]
      - Host:
          client02.localdomain:
            display_name: client02
            [...]
      - Service:
          disk:
            check_command: disk
            host_name: client01.localdomain
            [...]
            apply:

For every object in this array we will prepare the path and generate the file with the defined objects.
The user can choose which objects he/she needs in the specific file, this enables complete control over the structure and configuration.

Parser

I already started to create something like a parser https://github.com/Icinga/ansible-icinga2/blob/master/templates/object_attributes.j2, because the quoting is in many cases very important.
For the Puppet module there's a custom parser provided, for Ansible it should be similar.
The parser should be working like a filter plugin and will return a string.

Basically we would try to replicate the parser from the puppet module https://github.com/Icinga/puppet-icinga2/blob/master/lib/puppet_x/icinga2/utils.rb and rewrite it for python.

Feel free to add your thoughts and comments. We would be happy to help out!

mkay

Hi,

over the past few months, this repository got slowly abandoned, therefore, I had a talk with Feu in the forum and later with @bobapple to see how I can help.

To revive this repository I would like to make a few changes or rather a basic refactoring of this repository.

This includes the following steps:

1. Housekeeping (clean up repo, remove unused files, update information/documentation)
2. Rework testing setup
3. See if refactoring of existing functionality is necessary
4. Introduce new branching strategy (just add a devel branch; the master/main branch should only contain the latest working, tagged version)
5. Start adding new features

I hope we can revive this repository and get this Ansible role working again :)

Best regards
Florian

refs #12

Under Debian the /etc/icinga2/ folder has the stats:

owner: nagios
group: nagios
mode: 0750

Because of this become is needed.

The official repository packages.icinga.com is added before installing any package. The default behavior is to add this repository, it can be disabled optionally by the user.

Keep the supported distributions in mind.

Enable and disable the feature. Set all configuration parameters with defaults from the Icinga 2 documentation.

refs #12

In the ansible_collections/icinga/icinga the role for SLES is missing. Is its possible to add SLES support?

user@host:~/.ansible/collections/ansible_collections/icinga/icinga/roles/icinga2/tasks$ ls
configure.yml features features.yml install.yml install_on_Debian.yml install_on_RedHat.yml main.yml objects.yml service.yml

The variables beginning in i2_const_ don't seem to be used anywhere.
Only the variable i2_custom_constants is.

looks like the template creates a faulty configuration for the api feature.

the variables used as mentioned in the README

i2_custom_features:
  ApiListener:
    api: 
       accept_config: true
       accept_commands: true

The result ansible creates

# cat features-enabled/ApiListener.conf 
// Ansible managed

object ApiListener "api" {
   accept_config = "True"
accept_commands = "True"
}

syntax complain

# icinga2 daemon -C
[2020-01-28 16:14:53 +0100] information/cli: Icinga application loader (version: r2.11.2-1)
[2020-01-28 16:14:53 +0100] information/cli: Loading configuration file(s).
[2020-01-28 16:14:53 +0100] information/ConfigItem: Committing config item(s).
[2020-01-28 16:14:53 +0100] critical/config: Error: Error while evaluating expression: Can't convert 'True' to a floating point number.
Location: in /etc/icinga2/features-enabled/ApiListener.conf: 4:4-4:25
/etc/icinga2/features-enabled/ApiListener.conf(2): 
/etc/icinga2/features-enabled/ApiListener.conf(3): object ApiListener "api" {
/etc/icinga2/features-enabled/ApiListener.conf(4):    accept_config = "True"
                                                      ^^^^^^^^^^^^^^^^^^^^^^
/etc/icinga2/features-enabled/ApiListener.conf(5): accept_commands = "True"
/etc/icinga2/features-enabled/ApiListener.conf(6): }

[2020-01-28 16:14:53 +0100] critical/config: 1 error
[2020-01-28 16:14:53 +0100] critical/cli: Config validation failed. Re-run with 'icinga2 daemon -C' after fixing the config.

Result expected is

cat features-enabled/ApiListener.conf 
// Ansible managed
object ApiListener "api" {
   accept_config = true
   accept_commands = true

Looks like the api follows a different syntax then the other features.

unfortunately my ansible skill is not enough to make PR. :(

Thanks for your feedback.

Configuration of all IDO MySQL configuration parameters. Enable and disable the feature. Additionally it can import the basic schema to a defined database. If importing is enabled, it expects an existing database, user and password.

refs #12

refs #12

refs #12

Hello,
when i try to install icinga2 via ansible-galaxy i get the following error 👍
icinga.icinga2 was not found on https://galaxy.ansible.com.

refs #12