Linux OSRelease field incomplete for some Red Hat 7 servers

[norbro]

The Linux-specific field tblLinuxSystem.OSRelease correctly displays the complete Red Hat release for all of our RHEL5 or RHEL6 servers, e.g.:

Asset Type: Linux
OS: Red Hat Enterprise Linux Server release 6.9 (Santiago)

However, for most of our RHEL7 servers, the exact release level is not displayed, e.g.:

Asset Type: Linux
OS: Red Hat Enterprise Linux

Whereas for other RHEL7 servers, the release number is complete... e.g.:

Asset Type: Linux
OS: Red Hat Enterprise Linux Server 7.4 (Maipo)

The only pattern I see (is it pure coincidence?) is that for our RHEL7 servers, OSRelease is displayed properly when installed on a physical server, but not on a VM.

Is this a known issue, or would anybody know the reason for this difference?

Thanks!
Normand

[norbro · Accepted solution]

After opening a ticket with Lansweeper's technical support, I gathered the following information:

On Linux servers generally, Lansweeper scans gather OS information by filtering the information returned by the following command:

cat /etc/*release

On Linux RHEL7 servers, a new file (/etc/os-release) was added to those previously existing (i.e., /etc/redhat-release and /etc/system-release). Lansweeper seems to be "catching" OS information from the new file (because it's first in alphabetical order?), and specifically from the following line in /etc/os-release -- which is why the OS release doesn't appear when it's incomplete there:

PRETTY_NAME="Red Hat Enterprise Linux"

For some unknown reason, OS information on that line is incomplete only on certain Linux RHEL7 servers (seemingly, VMs are more probable candidates...).

Workaround: edit that specific line in /etc/os-release, replacing the value with the complete OS information, e.g.:

PRETTY_NAME="Red Hat Enterprise Linux Server release 7.4 (Maipo)"

Unfortunately, each OS upgrade replaces /etc/os-release, so the workaround might have to be applied repeatedly, for instance in the cron.weekly routine.

Permanent solution? Lansweeper support promises they will be developing a new feature enabling Linux scans customization. However, no delivery date was given. Such a feature would allow us, for instance, to always refer to /etc/redhat-release, which seems to always return the complete OS information, regardless of the RHEL.

Hope this will help someone!

[norbro]

Further to @fjca's comment, I checked "OS release" files on our Red Hat servers, with the following results.

Under Red Hat 5: Only /etc/redhat-release exists and contains the complete information, which is properly read by LS, e.g.:

Red Hat Enterprise Linux Server release 5.11 (Tikanga)

Under Red Hat 6: /etc/system-release is added, but it's only a redirect to /etc/redhat-release - it still contains the complete information, which is properly read by LS, e.g.:

Red Hat Enterprise Linux Server release 6.9 (Santiago)

Under Red Hat 7:

• three "OS release" files are listed:

[root@sofe-bd-prod01 etc]# ll *-release
-rw-r--r-- 1 root root 513 Aug 2 10:05 os-release
-rw-r--r-- 1 root root 52 Jun 28 14:36 redhat-release
lrwxrwxrwx 1 root root 14 Aug 2 10:02 system-release -> redhat-release

• /etc/redhat-release still contains the complete information, which is properly read by LS, e.g.:

Red Hat Enterprise Linux Server release 7.4 (Maipo)

• /etc/os-release contains many lines, the following looking very much like the value which is read by LS:

PRETTY_NAME="Red Hat Enterprise Linux"

Then again, I don't understand why LS doesn't always read the same value, i.e. the one listed in /etc/redhat-release, since that file is present on ALL Linux servers and contains the complete information needed.

So, back to my previous question: What is the "default/scanned location" mentioned earlier by @Charles.X where LS gets its value for Linux releases???

[fjca]

I just checked and on my case, all Centos 7 machines, both Virtual and Physical, are listed as "CentOS Linux 7 (Core)", only my older CentOS 6 machines have the correct version.

I did a quick find on /etc/, and it seems that on CentOS 6, Lansweeper is getting the info from /etc/redhat-release or /etc/centos-release or /etc/system-release (the rc.sysinit scripts for instance use that).

But on CentOS 7, it seems it is looking only/first at /etc/os-release, and even them to the PRETY_NAME tag.
I've edited that file/line on a test server, did a rescan, and it reflected the changes, so the source of that information seems to be correct...

/etc/os-release does not exist on our (mininal) Centos 6 machines, so it could be the case that Lansweeper starts by there, or that file has a higher priority in getting the oslevel information. So in CentOS 7 it gets that info first, and doesn't try other methods...

I've checked the commands used by LS to get Unix/Linux info, info here:

https://www.lansweeper.com/kb/160/linux-and-unix-scanning-requirements.html

And none of them (well, the Linux ones, there are Solaris and AIX commands there also) list os-releases, at least the ones on my (once again, mininal) CentOS 6/7 installs...

So, please check the relevant information on /etc/os-release in your machines...

[norbro]

Hi Charles,

On both VMs and physical servers, the information is located in the same file, i.e. /etc/redhat-release, and the contents are identical on both:

> cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.4 (Maipo)

User permissions on the file are the same on both types of servers:

> ls -l /etc/redhat-release
-rw-r--r-- 1 root root 52 Jun 28 14:36 /etc/redhat-release

Also, the Scanning Credentials used on both VMs and physical servers are identical (an SSH user's credential is provided with sudo rights), and there are no errors detected while scanning any of the Red Hat 7 Linux servers.

I'm new with Lansweeper, so could you shed any more light on where Lansweeper gets this OS information from? It may help me pinpoint the cause.

[Esben_D]

When information is scanned but not displayed correctly this is usually due to one of the following two reasons:

• The information missing is not stored on the asset or not in the default/scanned location
  
• The information is present but Lansweeper does not scan it correctly.

I would recommend checking if the information is stored on the VMs is identical to the physical machines.