I have a lua script which run a sql query, processes the results and emails a report on probes by server.
I recently noticed that the report is missing probes! Investigation showed that the following query does not report all probes deployed to the robot_id:
SELECT * FROM NimsoftSLM.dbo.CM_NIMBUS_PROBE WHERE NimsoftSLM.dbo.CM_NIMBUS_PROBE.robot_id = '***' ORDER BY robot_id;
Removing and re-deploying the missing probe does not cause any changes to the CM_NIMBUS_PROBE table. However, when deploying a different probe, it does appear in the CM_NIMBUS_PROBE after a minute!
This seems unexpected behaviour - am I missing something obvious?
Help and suggestions appreciated.
I haven't used this table, actually only recently found out about it. My guess is that it depends on one of these:
You could easily check the second option by viewing the file and seeing if it's there. You can also do this by callback.. something like "inst_list_summary" to controller of the robot.
Thanks for your reply, I have spent some time this afternoon trying to understand what’s happening here!
As per your suggestion, I emptied the niscache folder and restarted the robot, to no avail.
The installed.pkg does correctly contain the probes installed.
One of the probes that is missing from the CM_NIMBUS_PROBE table is a cdm. I noted that this is not the vanilla Nimsoft cdm, but one saved back to the archive and named cdm_redhat.
I deleted it and installed the vanilla cdm probe, which consequently appeared in the CM_NIMBUS_PROBE table.
Deleting the Nimsoft probe and replacing with the tailored version causes the entry to be removed from the CM_NIMBUS_PROBE table. The tailored probe can be seen in the installed.pkg file.
So, it appears that Nimsoft does not record tailored and renamed probes in the CM_NIMBUS_PROBE table.
Would you expect this to be normal behaviour?
That does sound rather odd to me.. but I'm not quite sure what the cm_nimbus_probe is meant for (originally, anyway). But no, it's not the kind of behaviour I'd expect with the knowledge readily available.
Would be interesting to know which part actually reports the installation.. is it a callback somewhere or a message in the bus? Sounds like time for Dr. Nimbus / tcpdump...
I'm glad someone else finds the behaviour odd too!
I checked with Dr.Nimbus, and he can see the tailored probe when deployed to a robot. It’s presence is just not reflected in the CM_NIMBUS_PROBE table. Other probes can be deployed and they appear in the database ok.
Can look at getting a tcpdump, but not sure I know what to look for with regards to a possible callback though!
Thanks for your input,
dr nimbus and tcpdump were just my musings on looking further into it Unfortunately schedule looks a bit busy now to investigate myself But I would love to know how it works.
Ok, here’s what I have found.
In a nutshell, I have to deploy the vanilla ‘Nimsoft’ version of a probe. Tailor it to hearts content and drag back to the archive, ensuring the config-only checkbox is ticked and giving it a new name of course.
On the next server requiring the tailored probe, again deploy the vanilla ‘Nimsoft’ probe, but then deploy the tailored config-only version over the top.
The deployment of the original Nimsoft probe causes an entry to be written to the NimsoftSLM.dbo.CM_NIMBUS_PROBE table.
Can someone explain if this is expect behaviour. I would have thought you should be to clone the complete probe and not just config-only?
You do end up with two probe entries (one for Nimsoft probe and one for tailored one) in the pkg/inst/installed.pkg file, but I’ve seen no consequence of this.
Generally speaking it's best practice to only copy the configuration to you packages. If you need it to deploy the probe as well, you can add it to the package dependencies.
Creating your own packages with the original binaries etc will cause other trouble beside this too, such as update problems etc.