DX Unified Infrastructure Management

 View Only
Expand all | Collapse all

Tech Tip: robot/probe version checker and report tool

  • 1.  Tech Tip: robot/probe version checker and report tool

    Posted Apr 06, 2022 01:41 AM
    Edited by Luc Christiaens May 15, 2024 06:43 AM
      |   view attached

    If there is something common between all clients I visited in the past it is the difficulty they had to have a clear view on what probes/packages and their versions that were installed in their environment.
    Via the good old Infrastructure Manager we could drag and drop a new version of a probe, but it was not always easy to see/check the total picture/results.
    The attached tool, available in Perl source and compiled format, will try to get the highest available version from your LOCAL & WEB archive and compare this with the information available in the centralized table: cm_nimbus_package.
    To help you create specific target reports you have several:
    - sql filter parameters: -lo, -lh, -lr and -lp
    - on the output of the created sql query you can apply regex parameters where you can filter on: origin, hub, robot, package, os_major_os_minor, user_tag1 and user_tag2

    - html report with in red all robot/probe that have lower versions installed
    - PU txt file with commands ready to be executed to upgrade the probes (they are NEVER executed/deployed/upgraded automatically)

    This example was run with parameters -ex"n"
    (-ex"n" is to report also the probes that have a correct version installed)
    In the PU txt file you can find:

    Doc file is also included in package/attachment
    Remarks, suggestions, problems and questions are very welcome.

    In version 2.1, takes a totally other approach than previous versions.  
    Initially we started, in 1.0, from a list of probes installed on robots coming from cm_nimbus_probe, but this had the limitation that we didn't see/report all installed non-probe packages. (java, app_disco_, c++ distrib,..)

    In version 2.6 we replaced the time consuming callback on each robot  by using the SQL table: cm_nimbus_package

    Version 2.0:
    - Via the 4 available SQL selection parameters we create a list of servers 
    - for each selected server we issue a controller callback: inst_list_summary
    - on this packages list we will apply the regex filters and create a report and when needed PU commands (in a txt file)
    Version 2.3:
    - some additional code to recognize test fixes and hot fixes
    - -dp: delete package parameter, this make it possible to remove, in a controlled way, packages in your environment
    - nimsoft_generic.pm can now be located in the same directory as the tool or in perl/lib

    Version 2.5:

    -option -wa"y" will try to access: support.nimsoft.com:443 directly to report on available versions in web archive (see above screenshot where the CDM probe has version 7.20 available in web archive).  If somebody find the exact customization actions/steps to open this access in a closed environment, please let me/us know.

    Version 2.6:

    • replace the time consuming callback: inst_list_summary by the central SQL table: cm_nimbus_package.
    • -lp was Limit Probe and is now Limit Package sql filter
    • new parameter -ci"y" that will flag&report exceptions. Default is -ci"y" (check ignore)
    • new/updated parameter -dp can help you to solve these exceptions by generating: inst_pkg_remove commands
    • -lo & -oi/-oe use origin from cm_computer_system, this is the updated origin, also if you use origin enrichment

    This latest version is posted lower (nimsoft_check_packages_version_v2.6.zip)

    #uim #package #check #tool #perl #commandline #report #version #installed #probe #upgrade   ​​​​​​​​​​


  • 2.  RE: Tech Tip: robot/probe version checker and report tool

    Posted Apr 06, 2022 09:51 AM
    Very nice.

    I invented a similar wheel a couple months ago when I discovered a significant inconsistency that occurs in the installed version information. There are several sources to identify version (_status callback, get_probes callback, getrobots, local log files, vesions.txt, installed.pkg, cm_nimbus_robot, cm_nimbus_probe, etc.). And, while Nimsoft isn't an outlier in this regard, any time you have many places the same information is stored it is bound to be wrong at times. I have observed (not proven but observed) three events that confound this - if you downgrade a probe install the version information will get out of sync, if you install a package with a dependency and the install of the dependency fails, the version of the dependency will sometimes be recorded as a successful install, and if you have a package with multiple tabs and the first tab is successful and a subsequent tab is not then the package will get recorded as a successful install.

    Because of this, in my tool, I added the additional check where for each installed probe I issued the _status callback and compared that version (the one returned by the running probe) to what discovery_server populated in cm_nimbus_probe. 

    The results were a little disturbing as I found, across about 7k robots, about 250 cases where the installed version inventory value didn't match the running probe.

    Might not be a big deal for some but consider the log4j issue recently where you have to identify the systems that have a probe version with an exploit and you have to ask the question about generating the list of systems that are vulnerable - is a one in 300 probes (250 failures in 7,000 robots with an average of 10 probes) or 1 in 30 affected robots error in the list acceptable? Probably not.

    Fixing the inconsistency is a **** matter of redeploying the mismatched probe again (except in the downgrade scenario - there it was necessary to install the latest version).

    Back to the tool, a question, how do you deal with version strings like 9.34HF1? Most places in Nimsoft, this data is stored as a number and so the fix number is lost.

  • 3.  RE: Tech Tip: robot/probe version checker and report tool

    Posted Apr 07, 2022 05:19 AM
    Hi Garin,
    Thanks for your valuable input.
    - adding a callback, like probe_list to a controller, seems to return the correct version info with HF included. Very good tip, I will add this 
    - for the version info from local archive I was/am struggling with this HF info because the build number is not following correctly incremental (sometimes it does and for other probes it doesn't)
    Therefor I opened an idea.
    But this morning i had a new idea to solve this problem.  When replacing version 9.32hf2 by 9.321 and 9.32_hf3 by 9.323 the version to deploy would be correct. (now i need only to add the callback to obtain the correct installed version)
    So I hope to have soon an updated version with the extra callback + document better the (strange) logic in obtaining probe/package versions

  • 4.  RE: Tech Tip: robot/probe version checker and report tool

    Posted Apr 06, 2022 12:17 PM

    We've created a grafana dashboard with that information

    You select the HUB, then robot and it shows you the probe installed and their version.

    We also present the robot version with graph

    You could also modify the query to select a specific probe and it could you show the same graph but for the cdm probe instead of the robot.

    You can filter on every columns and export it as csv if you want.

    We use the /uimapi endpoint to build the dashboard.


  • 5.  RE: Tech Tip: robot/probe version checker and report tool

    Posted Apr 06, 2022 12:24 PM

    Running curl -X GET "https://<operatorconsole>/uimapi/archive/list" -H "accept: application/json" will list every packages inside the archive so you can compare it with the data from the result of running curl -X GET "https://<operatorconsole>/uimapi/hubs/<domain>/<hub>/<robot> -H "accept: application/js