Problem configuring clients with node wizard command

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

    Hello, and thanks in advance for any input!


    I'm new to Icinga2. I worked with Nagios about a year ago, briefly. I'm glad to see that this fork resolves a couple of the things I didn't like about Nagios, and I'm really excited to start using it!


    I have a basic monitoring server already configured, with Icinga 2 and Icinga Web 2. It's still pretty much just "out of the box" Icinga, which is configured to monitor 8 hosts at the moment (just ping-based "host alive" checks).


    I'm now moving on to cofiguring agent-based monitoring. What I can gather from the documentation is that a "distributed monitoring" setup is the preferred way to do this, outlined in this guide: https://docs.icinga.com/icinga…d-monitoring-setup-master


    I've followed that guide very closely, and have retraced my steps a couple times to make sure they were correctly applied. I can elaborate more as needed, but am not sure exactly what details may be useful.


    The issue I'm running into is when running the "icinga2 node wizard" command on the Client. After entering the appropriate responses, I get the following error message:


    Code
    1. information/base: Writing private key to '/etc/icinga2/pki/widow.key'.
    2. information/base: Writing X509 certificate to '/etc/icinga2/pki/widow.crt'.
    3. information/cli: Fetching public certificate from master (10.1.2.151, 5665):
    5. critical/TcpSocket: Invalid socket: Connection timed out
    6. critical/pki: Cannot connect to host '10.1.2.151' on port '5665'
    7. critical/cli: Peer did not present a valid certificate.


    For reference, sentinel is the hostname of my Icinga2 Master, and widow is the hostname of my Client.

    I've tried to work through some basic troubleshooting steps, but am not sure where all to look. Here's what I've checked/confirmed:


    on sentinel (Master) :

    /var/lib/icinga2/ca exists

    /etc/icinga2/pki/ contains the following: ca.crt sentinel.crt sentinel.csr sentinel.key

    /etc/icinga2/features-enabled/api.conf looks like this:


    /etc/icinga2/constants.conf looks like this:


    And here's as far as I've made it through the client-side setup:

    Ran command

    Code
    1. icinga2 pki ticket --cn widow --salt 5c705675de2073c913074db389bde90e

    (The guide didn't indicate I need to add --salt, but the command gave me an error when I didn't)

    Added the client-pki-ticket user to /etc/icinga2/conf.d/api-users.conf as indicated:

    Code
    1. object ApiUser "client-pki-ticket" {
    2. password = "bea1GY1beb7ba1481t0eadfsa9dc6ea"
    3. permissions = [ "actions/generate-ticket" ]
    4. }

    Went back into the Master node, and ran the curl command to retrieve ticket:

    Code
    1. curl -k -s -u client-pki-ticket:97NdDW7egtZsm3XW -H 'Accept: application/json' -X POST 'https://192.168.1.151:5665/v1/actions/generate-ticket' -d '{ "cn": "widow" }'

    I noticed this didn't give any text output. if I understood the documentation right, I should have received a ticket number for having done this, so at this point I believe I've done something wrong


    I did check that my master node is listening on 5665 with the following:

    Code
    1. netstat -an | grep 5665
    2. tcp 0 0 192.168.1.151:5665 0.0.0.0:* LISTEN

    This is the point I tried the icinga2 node wizard command, and got the results posted in the first code box. I'm not sure what else to check. Any assistance would be greatly appreciated!

    For me, it looks like you have mixed some things.


    Assumptions:

    Master has just been set up and is able to execute local checks; Displays these in IcingaWeb2.

    icinga2 node wizard has been run at the master. Mode has been given as Master, CN has been chosen to be the machines FQDN.

    Master has Hostname and Endpoint-Name sentinel, as well as the IP 10.1.2.151

    The Client is named Widow.

    We want the Client to connect to the Master, not vice versa.

    Process should be

    At the master create / modify the zones.conf file to contain the clients zone:

    At the master, run The Below Commands

    Code
    1. $ mkdir /etc/icinga2/zone.d/global-templates
    2. $ mkdir /etc/icinga2/zone.d/widow
    4. $ icinga2 pki ticket --cn 'widow'
    5. 2483cf6f158c06f362b2f2a7ea29b72b25d14d17
    7. $ icinga2 feature list
    8. Disabled features: compatlog debuglog gelf graphite influxdb livestatus opentsdb perfdata statusdata syslog
    9. Enabled features: api checker command ido-mysql mainlog notification


    At the Client, run:


    You see, creating the ticket at the master and pasting it here at the client is enough, you do not need to fiddle with api.conf and curl.


    Modifications At The Windows Client


    zones.conf


    Now continue with the attached document, starting at:

    Create An Interrim Windows Service At The Master, To Verify Top Down Replikation


    Yes - the document is for setting up a windows client, but at that point we are behind the windows specific things so from that paragraph on

    it will work for both linux and windows.

    Thank you very much for your advice! Unfortunately, I seem to still have the same issue after applying the steps you outlined.


    The assumptions you listed about my setup are all correct


    I applied the steps on the Master (Sentinel) as you indicated, and then also did a systemctl restart icinga2.


    I also issued the command "icinga2 object list | grep widow" to ensure that the zone object was successfully applied:

    Code
    1. Object 'widow' of type 'Zone':
    2. * __name = "widow"
    3. * endpoints = [ "widow" ]
    4. * name = "widow"
    5. * templates = [ "widow" ]

    I'm confused about the creation of the two directories in /etc/icinga2/zone.d - After applying all of your steps, these still seem to be empty/not in use. They were created, however


    I ran the command "icinga2 pki ticket --cn 'widow'", and noted the ticket number generated for future use.


    The output of icinga2 feature list is identical to the one you posted.


    At this point, I issue the command "icinga2 node wizard" on the Client (Widow), but receive the same issue as before:

    There isn't currently any firewall blocking this traffic, these two machines are on the same LAN, so the communication between them doesn't even cross any routers.


    I'm jut having a hard time knowing how to diagnose what the problem is - There is network connectivity between the two servers, port 5665 isn't blocked, and the Api is listening on that port. The CA has been setup, and has certificates to issue (as far as I can tell) - What other troubleshooting/diagnostic steps am I missing?

    The post was edited 1 time, last by Anubis ().

    Try to connect to 192.168.1.151:5665 using openssl s_client - that merely is the same operation.

    https://docs.icinga.com/icinga…ooting-cluster-ssl-errors


    If you're running into connection timeouts, use tcpdump on the master node and see if there's packets on port 5665 (also explained in the troubleshooting docs).

    It turned out to be quite simple - Thank you both for your help, and for pointing me in the right direction. The diagnostic steps you listed were what helped me figure this out


    This specific issue was caused by Ubuntu's host-based firewall (on the Master node). I resolved it with the following commands:


    sudo ufw allow 5665

    sudo ufw reload


    After doing so, I could proceed with the node wizard on the client.



    Edit: Made it through the rest of the setup without any issues - I now have one host checking disk usage, as outlined in the examples in the guide from the documentation. Thanks again so much for your help! Really happy with this software, and glad there's a supportive community to get involved with!

    The post was edited 3 times, last by Anubis: Found the place I can mark as resolved, removing that comment. ().