Anyone have any luck with 'silent' / 'auto' installs of Windows clients using the Icinga2Agent.psm1 module?

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

    I've been tinkering with the PS shell script that is available that can help with auto installs: Icinga2Agent.psm1Icinga2Agent.psm1

    It needs to be copied to the server in a certain location.

    Next you write a little PS script that does the install by calling the module with certain params:

    1. Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
    2. Import-Module Icinga2Agent
    3. $icinga = Icinga2AgentModule
    4. $icinga = Icinga2AgentModule `-AgentName 'BOB' `-Ticket 'a830e7dad8e793d8cde06dfc9139951a18fbe048' `-ParentZone 'master' `-InstallAgentVersion '2.5.4' `-ParentEndpoints 'centicinga25.mycorp.corp' `-CAServer 'centicinga25.mycorp.corp' `-DownloadUrl 'http://centicinga25.mycorp.corp/'
    5. exit $icinga.installIcinga2Agent()

    I managed to get that going, the client pulls the executable from my own server (and not from the web), does the req for a cert and the signing seems to work as well. As a result the service is running.... But then what?

    My 1st observation is that if I start the wizard, I asks me to fill out all the info again, whereas if just plainly installed, it shows me that the service is running and I can 'examine' or 'reconfig' the configuration

    In any case, when I run on the master

    1. icinga2 node list

    The new client never shows... This may be rooted in the fact that I am still very weak on the concept of satellites, zones, endpoints and nodes and that the client is not setup to be a satellite

    In any case, I installed a client via the normal GUI way (icinga2 node list; icinga 2 node update-config) and compared the settings on the master and that of the 2 clients to each other.

    The clients are very different in setup, some settings from constant.conf are now in icinga2.conf for instance. I also noted that conf.d is NOT included as well as the windows-plugins are left out.

    I also found that the endpoint of the server is defined, but no IP and port are giving.

    The furthest I got was to finally have the client show up (in repository.d) and being checked. I also managed to get the services showing but they would stay in 'pending' mode forever.

    Obviously my main issue is that I am building it as a bottom up client which I don't even want but that is what I know. I still haven't figured out how one would build a top down client.

    Anyone any luck with this module? There are only a few posts detailing it's existence...

    I've been looking at this for 2 long days now, enabled logging, disabled firewalls etc... I am currently at a loss. ?(?(?(

    Thanks everyone!

  • Hi,

    after silent installation of the icinga 2 windows agent via Icinga2Agent.psm1 you should be able to autodiscover this agent by running 'icinga 2 node update-config' on the master.

    The host and port attributes of the endpoint object determine if the agent actively tries to connect to the master (…monitoring-master-clients)

    If your services stay in pending I guess you have some issues with your sercice templates...

    Top down or bottom up is determined by where you place your check config (service checks, templates, checkcommands etc.) If you place it on your master you have top down then you have to sync at least custom configurations like your own checkcommands to the agents.
    If you place it on the agent you have bottom up then you have to import the config on the master and will be copied to your repository.d on the master.

    But all I wrote is just my understanding. I'm not really sure if this is really correct...

    best regards,

  • After hacking away at it for a few days, I managed to get this resolved! 8o

    I wrote a program that runs on the server and takes a list of hosts as input.

    Then, for every host:

    • A ZIP file is created and stored on the MASTER which can be downloaded onto a WINDOWS client. (My clients do not have internet access)
    • Client installs full automatically with just a double click
    • Appropriate ports are opened in the CLIENT F/W
    • Zone and Host configs are added to the MASTER
    • Via APPLY rules several checks are added. MASTER sets them, CLIENT executes them

    Only manual step needed is a reload. I didn't want to automate this since I've seen that checks get interrupted resulting in a 'recovery' email.... (I am planning on writing my own restart prog which inhibits emailing for say 5 minutes)

    Since I do not have/want full control over the servers I will rely on my dev's to do these installs (+ it's way too much work, too many hosts). They just have to download the ZIP, unzip it and double click the installer which I named "Installer.bat" :)

    The whole install process is now fully automated end-end. The Icinga 2 certificate is requested, signed and stored based on pre-created ticket info which was compiled in the installer. My custom config is installed and the Icinga process on the client is stopped/restarted

    The Icinga2 client install itself was actually the easy part, the key really was in my (lack of) understanding of "bottom up" versus "top down" modes.

    Top down is the way to go, basically the server decides what checks need to be done, but the client executes them. This gives you control if you do not have/want to be doing things on your clients.