Highlighted
Honored Contributor.
Honored Contributor.
483 views

Inventory Scanner changing Infrastructure discovery of Node Operating System

Jump to solution

On some of my Linux systems, particularly running 7.1, but not exclusively or always, when the scanner runs it changes the Node Operating System from "release 7.1..XX" to "release release".  I can see it in the CI_history for the device.  The unaffected nodes may or may not have run the scanner.  I found a script which might potentially be the cause, ParseEnrichedScanFile.py, but the names it uses for attributes aren't the attributes name so I am not quite sure.

We are running UCMDB 10.22 on Windows.

Has anyone else seen something like this or would have an solution?  I haven't been able to directly correlate something about a node that keeps the correct value and a node which changes it.

Thanks,
Mel

Tags (1)
0 Likes
1 Solution

Accepted Solutions
Highlighted
Honored Contributor.
Honored Contributor.

Dong-xu

I found that piece of code and that is the problem.  The text "release" which they put is meaningless, but the value from the call is also release, so the result is "release release" in the field.

I think I have found a work around.  I commented out that section, since the connection by shell already correctly fills in the attribute.  I cleared cache and reran the connection and it replaced "release release" with the correct value.  If I don't clear cache the connection by shell won't update the attribute, though I don't know why.

 

Mel

View solution in original post

0 Likes
6 Replies
Highlighted
Outstanding Contributor.
Outstanding Contributor.

I have seen this behavior with CentOS 7.x and related it to a change in the file /etc/redhat-release. The value in the file looks like: CentOS Linux release 7.2.1511 (Core)

The addition of the word Linux makes the parse script grab the word release as the actual release version. I have reported it in QCCR1H115624 and it has been fixed for version 10.3x

0 Likes
Highlighted
Honored Contributor.
Honored Contributor.

John,

Not sure if the situation is as described in the QCCR.  The host connection by SHELL returns the correct value.  The discovery by SCANNER overwrites the value with "release release".  I found where it is done in ParseEnrichedScanFile on lines 828-829 if statement.  I first changed the "release " to "release MAF " and that is what showed up.  I then commented out the if and changed the elif to if.  All that is fine, but...

Apparently, if you modify an attribute manually or even by enrichment, connection by SHELL won't update the field.  Maybe UCMDB assumes if the field is updated outside of discovery, UCMDB discovery will no longer update the field.

I hope that is not true or some knows another way to erase my "release release" so tne next host connection by shell will update the field or some other workaround.

Mel

0 Likes
Highlighted
Honored Contributor.
Honored Contributor.

In trying to resolve the problem does anyone know how to access  a shell command from one of the scanner python scripts.  If I could do that I can work around the problem.

The problem is a known problem, but requires an upgrade to CP24 or higher.  Our CM process is very long and I need a solution quicker.

Thanks,
Mel

0 Likes
Highlighted
Respected Contributor.
Respected Contributor.

Hi Mel,

Please provide more info on what you'd like to do, we'll give you the options. there are commands to access the shell, but i'd like to know what you want to do with it first, to be sure.

 

0 Likes
Highlighted
Super Contributor.
Super Contributor.

HI Mel

I don't know whether you are talking about the "host_osrelease" (Node Operating System Release) property. If yes, you can take a look.
You metioned "ParseEnrichedScanFile on lines 828-829" I can not check this in the lab, because we may on different CP.

But you can try to check the function "mapOsRelease" in the ParseEnrichedScanFile.py.
There you can find out the logic like:

if (unixtype == 'Linux' or unixtype == 'XenServer'):
return "release " + getNodeValues("hwOSHostVersion", root)[0]

I have no idea about why we put a "release " as a prefix here, but seems we can modify this to adapt your requirement.


Dong-xu
Micro Focus Support
If you find this or any post resolves your issue, please be sure to mark it as an accepted solution.Click the KUDOS star on the left to say 'Thanks'

0 Likes
Highlighted
Honored Contributor.
Honored Contributor.

Dong-xu

I found that piece of code and that is the problem.  The text "release" which they put is meaningless, but the value from the call is also release, so the result is "release release" in the field.

I think I have found a work around.  I commented out that section, since the connection by shell already correctly fills in the attribute.  I cleared cache and reran the connection and it replaced "release release" with the correct value.  If I don't clear cache the connection by shell won't update the attribute, though I don't know why.

 

Mel

View solution in original post

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.