Custom Probe/Sensor (Linux Laptops)

[doug_schulze]

As we all know (and you may have heard my spiel 100x's) we classify computers based on their Operating System, network devices primarily by their capabilities. Meaning a Windows Server OS will go into the Windows Server class, Windows desktops in the computer class, Linux OS in the Linux Server Class.....ect ect..

But what about the gray areas? I've had the recent occasion to hear from friends that have a lot of Linux based desktops and they were not so pleased with the fact that while licensing says you get all the desktops you want, servers cost. Why? they ask, do my Linux laptops incur a charge while Microsoft gets a pass?

Well, I have an answer that I hope some of my community friends can use to help them shine some light on those gray areas.

Attached is an update set that adds few things including a new question called Form Factor in the Unix Classify multi-probe

This command pulls back the enclosure type from DMIDECODE (an OOB command we already use that requires sudo)

It takes that value, matches it to a particular group and sets a classification parameter in the MultiSensor Script

so that you can trigger a specific classifier, which puts it in the computer class if  personalComputer = true

As you will see I continued to use probes/sensors, because well... Probes and Sensors for life 🙂 but I could have replicated the Linux server pattern and re-factored all the tables and such, but way to complicated for such a simple need.

Either way, hopefully, you can find this useful.

[Rob50]

This my friend is exactly what I needed. Thanks!

[Jordan Hladish1]

Doug - 

Awesome timing on this. I actually just finished completing nearly an identical configuration for Chassis Type to detect Linux Thin Client Devices for Classification to cmdb_ci_computer.

If this same functionality was to be implemented for an instance using the Linux Server Pattern rather than Probes & Sensors, what would you layout for a design layout?

Since the Pattern runs against the cmdb_ci_linux_server class specifically, I can't think of a way to implement this without adjusting some piece of the Classification process to kick off a nearly identical Linux Server pattern slightly customized to run against the cmdb_ci_computer class. 

Do you view things similar? Adjusting the Linux Server pattern as it sits doesn't seem viable since we're already Classified at that point, right?

[Jordan Hladish1]

Awesome timing on this. I was wrapping up doing just this for a client, but using Chassis Type from dmidecode to utilize the "Low Profile Desktop" type to kick Linux Thin Client Devices to the cmdb_ci_computer class. Your article was a big help in finalizing why my Sensor script wasn't working right.

Now that that's working, I'm also wrapping up an equivalent Pattern version of this functionality. It relied heavily on the same configuration aspects for Classification, but then kicks off a duplicated Linux Server Pattern with many duplicated/slimmed down Shared Libraries to Identify the record into the cmdb_ci_computer class.

I'll be posting an article similar to yours and linking it soon with screenshots. Look forward to your thoughts on it!

[Jordan Hladish1]

@doug.schulze Update Set attached, article coming soon.

Patterns:
"Linux TCD" [cmdb_ci_computer] - Infrastructure Pattern
"Linux TCD - Identity" (Shared Library)
"Linux TCD - Hardware Information" (Shared Library)
"Linux TCD - Network" (Shared Library)
"Linux TCD - Find FQDN" (Shared Library)
"Linux TCD - Distribution" (Shared Library)
"Linux TCD - Memory" (Shared Library)
"Linux TCD - Memory Modules" (Shared Library)
"Linux TCD - Network ARP Tables" (Shared Library)
"Linux TCD - CPU" (Shared Library)
"Linux TCD - Storage" (Shared Library)

* Linux TCD Classifier & Criterion

The reason that this requires so many records is because of how Linux devices are Classified by ServiceNow. The 'UNIX - Classify' Multiprobe kicks off against SSH-responsive devices. If we hit a Linux Computer that isn't a Server, we have to jump in-between the UNIX-OS Classification Probe & the Linux Server Classifier. 

To do this, we add in a new Probe ("Chassis Type" in my case) that makes a dmidecode call to find the Chassis Type of the device. A sensor takes this response and keys it against a known list of Chassis Type. If it is identifiable, it returns what the found Chassis Type was via chassisType & marks a personalComputer var to true.

The Linux TCD Classifier then kicks off the same as a Linux Server Classifier does, except also requiring chassisType == 'Thin Client Device' && personalComputer == true.

The Linux TCD Classifier kicks off a "Linux TCD" Pattern which is effectively a duplicated and stripped down Linux Server Pattern. I had copied the NDLs for the OOB Pattern replacing cmdb_ci_linux_server references to cmdb_ci_computer. I also had to duplicate a number of Shared Libraries as they make updates to cmdb_ci_linux_server directly as well. These have had a few steps stripped out that weren't applicable to TCDs in my case.

Hope this helps some others!

[doug_schulze]

This is exactly what community is all about, nice work.. Can't wait to see the article...

[lwhite]

I have a request within my organization to classify Linux medical devices (thin clients running Linux Ubuntu) as Hardware Assets. Currently these devices are being adding to the Linux Server table and Computer Table.  I tried the update set and script in this article, no changes, then ran Discovery on a limited IP range and it couldn't classify these medical devices at all.  I have set the Form Factor to active = false for the moment and reran Discovery and they are again classifying as they were before.

So my question is how do I also get these Ubuntu devices added to the Hardware Asset table (alm_hardware)?

Thank you,

Lynn

[Jordan Hladish1]

Lynn -

The way that your devices are responding for the Form Factor call is likely playing a lot into this. There are many different/similar types of Form Factors that might fit a non-Server Classification process as described in here.

I'd recommend troubleshooting to ensure that your devices are responding with that Form Factor listed here within the Payload of your ECC Queue when Quick Discovering. This will help you determine if your issue revolves around a configuration problem, or just a unique requirement from what this post outlines.

Jordan

[lwhite]

Thank you Jordan.  I was able to get these Linux medical devices added to the hardware asset table by tinkering with model categories.  I guess it's a bit of a different subject than what I originally was thinking.  Appreciate the quick feedback though.

Lynn

[Erick18]

Hi Jordan, 

Great work. I just imported the update set and ran a few discoveries. I think that I may be missing something because now all of my Linux devices including servers are being classified as "Computers". 

On the new Unix Classification for TCD, there are only two Classification Criteria. Should there be an entry for chassisType == 'Thin Client Device'? If so would I need to add additional criteria for chassisTypes of "Desktop", "Laptop", ect. Or is there somewhere else in the process that matches what type of chassisType equals a Server or Computer?

[Jordan Hladish1]

Hey Erick -

You are correct, it looks like the Classification Criteria on the Update Set I had uploaded is missing the extra record like you mentioned, nice find. You should be able to add this to the TCD classifier only because anything that wouldn't catch this 'Thin Client Device" chassisType would just continue to get classified as a Linux Server by default.

My post referenced that I had added an additional probe to the UNIX - Classify probe that was performing a dmidecode call to get the chassistype back as a variable to parse within this Classifier. Hope the Update Set at least contains that.. 

I'd recommend running a Quick Discover on an IP Address of a device you know is a TCD, and review the input record of the Classification probes to ensure you're getting a usable response back. There's a great chance that your devices respond as something slightly different than "Thin Client Device" - so this will be a good verification check.

Good luck!

[Erick18]

Hi Doug, 

I recently implemented this solution however this probe is now causing my HMC discovery to fail. I am getting an error "/bin/bash: dmidecode: command not found /bin/bash: awk: command not found - Exit status: 127". I am not sure how to proceed. Should I try to resolve the issue on the HMC to run dmidecode or is there a way to catch the error so that the unix classify multiprobe doesn't fail. 

Thanks,

Erick