Discovery probes - differentiating Linux workstations and servers

[David A2]

We are using the OOTB probes, and our classifier doesn't seem to be able to distinguish between Linux servers and Linux workstations. From the logs it looks like it's gathering the OS information from uname-a, but the output doesn't give any of the unique os version info. The documentation seems to say this information can come from either uname -a or cat /etc/*release, the second being the more promising area. Do I need to customize the classifier to get it to look at cat/etc/*release?

https://docs.servicenow.com/bundle/london-it-operations-management/page/product/discovery/reference/...

Data collected

The Linux classifier triggers probes that perform the discovery. Several probes are launched during discovery. See the classifier for a list of the trigger probes.

Label	Table Name	Field Name	Source
Operating System	cmdb_ci_linux_server	os	uname
OS Version	cmdb_ci_computer	os_version	uname -a or cat /etc/*release
Short description	cmdb_ci_linux_server	short_description	uname
Name	cmdb_ci_linux_server	name	DNS, NBT
Hostname	cmdb_ci_linux_server	host_name	DNS, NBT
DNS domain	cmdb_ci_linux_server	dns_domain	DNS
Start date	cmdb_ci_linux_server	start_date	uptime
Manufacturer	cmdb_ci_computer	manufacturer	dmidecode
Serial number	cmdb_ci_computer	serial_number	dmidecode

[doug_schulze · Accepted solution]

I just explained how to something similar here but for triggering specific probes. In your case, you can take the result and use the value as a classification criteria. But know in our licensing model we consider all Linux OS's as a server os that ticks a license count. If you re-classify a Linux os outside the server class you might get into a grey area in your agreements and should probably have a conversation with your Account Manager for clarification on what can and can't be done in your use case.

[doug_schulze]

OH forgot something, when looking at my multi-sensor script I'm setting a 'value' so I can call it in the probe condition script, in your case you would actually want to replicate what happens in the ESX multiprobe by setting a classification parameter.

function(result, ciData, debug, sensor) {
    var output = result.output;
    if (output === null || gs.nil(output))
        return;

    run(output, ciData, debug);


    function run(output, ciData, debug) {
        if (output.indexOf("<YOUR_LINUX_VALUE>") == -1)
            return;

        var ci_data = ciData.getData();

        if (ci_data.classify_params == undefined)
            ci_data.classify_params = {};

        ci_data.classify_params.<your_parameter> = true;
        ci_data.output += (" " + output);
    }

}		

then in the classification criteria it would be <your_parameter> equals true

[David A2]

Thanks Doug!

[Sue L]

I have had an long time (Oct 2017) issue that was moved to development regarding the (lack of flexibility) in Linux probe basically.  As it could draw in and say the actual OS for Linux, but one could not do anything with it - such as we do for Mac OS to go to computers (not servers) we have the same issue with Thin Clients - they are computers not servers.  I haven't circled back on this recently, but has this resolved yet that we can better classify?  As our Thin clients are all Ubuntu and our Linux Servers are all Red Hat.    

Please discuss if this is resolved in recent versions, thanks.