- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-27-2013 05:50 PM
So doing a deployment my friends had a requirement to trigger specific probes based on the type of unix device it was. Being a very secure environment they had some servers that had very restrictive shells where only specifically formatted commands would work, but we had to learn that ahead of time...
Well the first part was really easy because we have a great out of box example ESX servers.... Modifying the ESX Section of the Unix classify probe (that's an obsolete process anyway but you can create your own if you wanted), instead of asking in the multi probe esx-os echo `vmware -v`, we had it just echo $shell .. because the shell would tell us if it was a 'restricted' host (we were matching on if the output contained rksh)...Then tuning the rest of the multi-sensor scripts and sensor itself we changed it from esx = true to RS (or restricted shell) = true.
Fantastic! Now I have a ci classification parameter that I can use in a classifier that would trigger just the restricted commands and away we went...I was able to verify the result by setting a system property 'glide.discovery.debug.classification' = true where I could see the results in the log..
03/19/13 12:11:58 (969) glide.scheduler.worker.3 DEBUG Classification: ************* Classifier: AIX(RS) *************
03/19/13 12:11:58 (969) glide.scheduler.worker.3 DEBUG Classification: Value cidata.ip_address = 10.10.10.10
03/19/13 12:11:58 (969) glide.scheduler.worker.3 DEBUG Classification: Value cidata.os_domain = ABCD
03/19/13 12:11:58 (969) glide.scheduler.worker.3 DEBUG Classification: Value RS = true
03/19/13 12:11:58 (969) glide.scheduler.worker.3 DEBUG Classification: Value ip_address = 10.10.10.10
03/19/13 12:11:58 (969) glide.scheduler.worker.3 DEBUG Classification: Value cidata.dns_domain = ABCD.AB
03/19/13 12:11:58 (969) glide.scheduler.worker.3 DEBUG Classification: Value discover = CIs
03/19/13 12:11:58 (969) glide.scheduler.worker.3 DEBUG Classification: Value output = undefined /usr/bin/rksh
03/19/13 12:11:58 (969) glide.scheduler.worker.3 DEBUG Classification: Value cidata.output = undefined /usr/bin/rksh
03/19/13 12:11:58 (969) glide.scheduler.worker.3 DEBUG Classification: Value type = unix
03/19/13 12:11:58 (969) glide.scheduler.worker.3 DEBUG Classification: Value cidata.dns_name = host.domain.com
03/19/13 12:11:58 (969) glide.scheduler.worker.3 DEBUG Classification: Value cidata.name = host
Great work, we got the ci in as a restricted device and even set a parameter in the on-classification script in the classifier that set a check box that identified this particular server as a secured host...But wait....
What about the process classifiers and their probes? That was a bit of a pill, but we saw the Oracle classifiers did have a condition script where its states that the device must be a unix host to trigger the probes.. type == 'unix'...At first I thought that it was coming from the classification data above, but it wasnt..
It turns out that the type is unix actually comes from a script include called "DiscoveryPsSensor"
There's a method called getOSType()… it's manually checking for for the type of the CI to determine if it's "unix"
getOSType: function() {
var cigr = this.getCmdbRecord();
if (cigr.sys_class_name.toString() == "cmdb_ci_esx_server")
return "esx";
else
return "unix";
},
So bingo I know where i can do some magic, and remember that attribute I set for a restricted system?... well we decided to use that...
getOSType: function() {
var cigr = this.getCmdbRecord();
if (cigr.sys_class_name.toString() == "cmdb_ci_esx_server")
return "esx";
if (cigr.restricted_shell == true)
return "rs_aix";
else
return "unix";
},
So now we can manage what probes are triggered at not only the System level in the classifier, but now at the active process level. For in that condition script I can now add to the individual probes; rs_aix == true as a conditon.. just like the Oracle reference I used above...
Nothing like having 'control' .. great stuff development!
Solved! Go to Solution.
- Labels:
-
Discovery
-
Service Mapping

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-03-2015 06:13 AM
Hi All,
After enabling the sys_property glide.discovery.debug.classification and setting it to true. Run your discovery, then head to ::
In Dublin --> System Logs --> Utilities --> Log File Browser
In Eureka --> System Logs --> Utilities --> Node Log File Browser
Note the time of your discovery status, keeping in mind all times are in 24hr format and set the following ::
Start Time :: (as close to the time of discovery start)
Level :: Info
Max Rows :: 1000 should be sufficient
Thread Name :: worker
This works for me - let me know if you have any questions....
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-26-2014 11:41 PM
Hi doug,
I did enable this property in Dublin . but where to see these Process Classifier logs, enabled all logs still no success.
Checked in Discovery Logs too.
Regards
Manish
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-28-2014 08:32 AM
I haven't activated this property, but it looks like you will just find them in the Script Log Statements since the glide.scheduler.worker isn't specifically related to Discovery.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-18-2015 11:05 PM
Yeah, it seems that doesn't work for me either. I'm using Eureka. Perhaps Dublin deprecated this property?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-03-2015 11:18 AM
I think Ryan nailed it below, but I wanted to confirm that glide.discovery.debug.classification has not been deprecated.
- Tim.