Posts by YevgenyTr

This forum was archived to /woltlab and is now in read-only mode.

    Hi,
    Sorry for the late response.


    1. There are both template and object that is related to the template (not confusing enough, eh?). The notification object is an apply rule.

    Code: zones.d/icinga2.orbotech.org/notification_templates.conf
    1. template Notification "service-alert" {
    2. command = "service-by-mail"
    3. period = "always"
    4. }


    Then the apply rule:


    2. "enable_notification => true" should work as it is. What is the full error you get?



    "system it" was probably a typo I made. I meant assign it. :)

    Hi,
    I have a host running RHEL 5.1 32bit that crush on SSL setup attempt.
    Some details first:

    Code
    1. LSB Version: :core-3.1-ia32:core-3.1-noarch:graphics-3.1-ia32:graphics-3.1-noarch
    2. Distributor ID: RedHatEnterpriseServer
    3. Description: Red Hat Enterprise Linux Server release 5.1 (Tikanga)
    4. Release: 5.1
    5. Codename: Tikanga



    Code
    1. icinga2-bin-2.4.10-1.el5.centos
    2. icinga2-common-2.4.10-1.el5.centos
    3. icinga-rpm-release-5-1.el5.centos
    4. icinga2-2.4.10-1.el5.centos
    Code
    1. openssl-devel-0.9.8b-8.3.el5_0.2
    2. openssl-0.9.8b-8.3.el5_0.2

    When the agent is installed fist, it can run without problems, yet after I run "icinga2 node wizard", it fails to start.
    I checked the crash log report and it says:



    I did some googling and found bugs related to Ubuntu some versions ago, but nothing on RHEL 5 family and I use the latest packages from the Icinga repo.


    Any suggestions?


    Thanks in advanced,
    Yevgeny

    UPDATE:
    It looks like a problem related SSL CA signing.
    When I created the certificates for the master it was not trusting it's self generating certificate.


    Now every satellite can connect and execute the service checks.

    Hi isuarezm,
    If you still having problems, I will try to explain to you how I did myself.
    I'm not sure that this is the best way, but it works for me right now. I'm still testing some components.


    The steps are:

    • Download and extract the send e-mail script from here to /opt/sendemail. I prefer this tool more that the one Icinga2 provides by default.
    • Icinga2 Director doesn't (I will probably won't in the future) use environment variables from Icinga2 core, so you will need to use a special command script that works with parameters instead. You can read more about this at this blog (Use Google translate).
    • I changed and cleaned up the two scripts to fit my needs the following way:




    Inside the director you will need to create the custom commands as notification type commands.
    Object type => Object , Command type => Notfication Plugin Command


    Then fill the details as described in the blog screenshot to map the parameters into run-time macros of Icinga2.
    Eventually, it should look like this:

    Then, when we defined out command, we need to use them for out notifications.
    Create a time period inside the Director (see details in the blog) like:


    Now we can use the notification commands and the time period to apply them to a notification rule.
    Go to notification settings inside the Director and create notification object for host and for service (remember we have two commands).
    Create one template for host and one for services, where you use your custom command and time period.
    Next step is to assign and apply rule. Just use the "Enable notification => True" system it globally.
    This way we send notification for all our hosts that we defined to notification true in the host template (and service template too).


    Now create a failing service and see if you get any e-mail.

    OK, I will try to sum up what I have done so far and what are the results.
    I followed the guide on the Github page for reference.


    Actions order:
    1. Created an agent based template.
    2. Created host object import the agent based check template.
    3. Created agent-based service template.
    3. Created service object using the agent based template using the check_load command.
    4. Added the check_load service to the host object created before.
    5. Installed icinga2 and nagios-plugins packages.
    6. Ran the kick-start shell script generated by Director on the hosts (had to change user from "nagios" to "icinga'), replace icinga2.conf and restarted the icinga2 daemon.


    Result:
    1. The host object and the service appear in the Icinga2 web interface.
    2. The service for check_load indicates that the host is reachable on the service tab (check source), yet the check is executed one time and doesn't retry after.
    3. On the check plugin output I get "Remote Icinga instance 'roger-wilco' is not connected to 'icinga2'" message.


    I hope it's clear enough.
    Thank you for your time in helping me with this simple, but annoying issue.

    That's what I did.
    After creating the service I added it to the host (host -> service -> add). This way the service appeared for the host.
    I also did an SSL check like it's explained here and it seems be OK.


    I will try to tun the "icinga2 node wizard" by hand now it see if it will change anything.

    BTW, I forgot to mention that I did a simple agent-based service like in the example with "check_load".
    I created a template for agent-based check:


    Code
    1. zones.d/director-global/service_templates.conf
    2. template Service "agent-service" {
    3. enable_notifications = true
    4. command_endpoint = host_name
    5. }

    And then the service importing this template:

    It's 5666 or 5665?

    Shell-Script
    1. /etc/init.d/icinga2 status
    2. Icinga 2 status: Running
    3. netstat -lntp | grep 56
    4. tcp 0 0 0.0.0.0:5665 0.0.0.0:* LISTEN 4741/icinga2



    Oh man, IPtables was running on the host (shame shame shame).
    Yet the error message is the same....


    Now, I get on host:


    Code
    1. 2016-07-06 17:09:07 +0300] information/ApiListener: New client connection for identity 'icinga2' (unauthenticated)
    2. [2016-07-06 17:10:12 +0300] information/ApiListener: New client connection for identity 'icinga2' (unauthenticated)
    3. [2016-07-06 17:11:07 +0300] information/JsonRpcConnection: No messages for identity 'icinga2' have been received in the last 60 seconds.
    4. [2016-07-06 17:11:07 +0300] warning/JsonRpcConnection: API client disconnected for identity 'icinga2'
    5. [2016-07-06 17:11:27 +0300] information/ApiListener: New client connection for identity 'icinga2' (unauthenticated)
    6. [2016-07-06 17:12:22 +0300] information/JsonRpcConnection: No messages for identity 'icinga2' have been received in the last 60 seconds.
    7. [2016-07-06 17:12:22 +0300] warning/JsonRpcConnection: API client disconnected for identity 'icinga2'
    8. [2016-07-06 17:12:42 +0300] information/ApiListener: New client connection for identity 'icinga2' (unauthenticated)



    and on master:


    Hello,
    I'm setting up a agent based host check using the guide found at Github, but have some issues completing the procedure.
    I created an "agent" host template:

    Code
    1. zones.d/director-global/host_templates.conf
    2. template Host "Icinga agent" {
    3. check_command = "ping4"
    4. }



    Choosing "yes" on "Icinga2 agent".
    Then created a host object which import this template that created this way:

    Then install Icinga2 agent and Nagios plugins package (CentOS 6.7) and restart the agent daemon, but Icinga2 show that:


    Quote

    Remote Icinga instance 'roger-wilco' is not connected to 'icinga2'

    And I don't see anything weird in the logs file neither that can point to a SSL issue or communication problem.
    On the host the log is filled with:

    Code
    1. [2016-07-06 16:23:22 +0300] information/ConfigObject: Dumping program state to file '/var/lib/icinga2/icinga2.state'

    lines through all the time.


    On the master:


    What could be wrong and what can I check from here?

    Hello,
    You mentioned in the 1.1.0 release notes that:


    Quote
    • All components required to deploy notifications are now available. ENV for commands is still missing, however it's pretty easy to work around this

    Does this mean I will need to setup up e-mail notification using the guide here?
    What will happen next, when notifications will able to work with environment variables like the way it's configured in /etc/icinga2 config files?


    Thanks in advanced,
    Yevgeny