Patch level of Suse Linux Enterprise Server (SLES) not reported

[hhenkel]

Running salt on centos / rhel the os release is reported with the minor version included:

osrelease: 6.4

Running the same on a SLES 11 SP3 you get:

osrelease: 11

It seems like this behavior is triggered by the python platform code:

Centos:

>>> platform.linux_distribution()
('CentOS', '6.4', 'Final')

SLES:

>>> platform.linux_distribution()
('SUSE Linux Enterprise Server ', '11', 'x86_64')

Digging through the code revealed that there is code to look in the /etc/*-release files. That would help for SLES till upstream is fixed:

# cat /etc/SuSE-release 
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 3

Almost forgot to mention, I'm running salt 0.17.1 ...

[hhenkel]

It also seems like sles is not reporting the patchlevel with the lsb release:

# lsb_release -a
LSB Version:    core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4.0-x86_64:desktop-4.0-amd64:desktop-4.0-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch
Distributor ID: SUSE LINUX
Description:    SUSE Linux Enterprise Server 11 (x86_64)
Release:        11
Codename:       n/a

Centos looks like this:

# lsb_release -a
LSB Version:    :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch
Distributor ID: CentOS
Description:    CentOS release 6.4 (Final)
Release:        6.4
Codename:       Final

[hhenkel]

Just for the record and at the risk of getting beaten...seems like facter uses the distrospecific relase files to set operatingsystemrelease:

--- CUT ---
Facter.add(:operatingsystemrelease) do
  confine :operatingsystem => %w{SLES SLED OpenSuSE}
  setcode do
    if release = Facter::Util::FileRead.read('/etc/SuSE-release')
      if match = /^VERSION\s*=\s*(\d+)/.match(release)
        releasemajor = match[1]
        if match = /^PATCHLEVEL\s*=\s*(\d+)/.match(release)
          releaseminor = match[1]
        elsif match = /^VERSION\s=.*.(\d+)/.match(release)
          releaseminor = match[1]
        else
          releaseminor = "0"
        end
        releasemajor + "." + releaseminor
      else
        "unknown"
      end
    end
  end
end
--- CUT ---

As far as I saw salt only uses these files if it fails to use the lsb relase library or the /etc/lsb-release file is not available.

[basepi]

So the problem lies with python's platform library and lsb_release, right? And you would just like a workaround until those get fixed? Sounds reasonable, and it looks like it will be fairly straightforward.

[william20111]

Yes lsb_release doesn’t give back a code name nor any indication to what service pack its running. So you don’t get the revision details like you do in redhat/centOS. Just checked this on my servers to confirm.

Where is the code that checks for this patch level in the source? I couldn’t find it..

cat /etc/issue on my SLES box gives me the service pack level

Welcome to SUSE Linux Enterprise Server 11 SP2 (i586) - Kernel \r (\l)

[hhenkel]

The code setting the grain is in grains/core.py. I think it would be better to use /etc/SuSE-release to determine the version, as it would fit with the other solutions (and it would also be more easy to parse). I also think this is easy to implement, if it still is unsolved by next week I will porbably give it a shot.

[william20111]

Makes sense! Ill have a look at the code tonight as have some spare time. And as you say it shouldn’t be that difficult.

Thanks
William

[william20111]

Knocked this together last night not sure how accurate it is as this is my first attempt at a patch. So have a couple of questions for you guys. Hope you can help.

    elif os.path.isfile('/etc/SuSE-release'):
         grains['lsb_distrib_id'] = 'SUSE'
         rel = open('/suse/etc/SuSE-release').read().split('\n')[1]
         patch = open('/suse/etc/SuSE-release').read().split('\n')[2]
         release = rel + " SP" + patch
         grains['lsb_distrib_release'] = release.group()
         grains['lsb_distrib_codename'] = codename.group()

What is standard practise to test this? Once its tested how do I attempt to merge it with development branch?

[hhenkel]

I've not contributed to salt stack, but I guess the "standard" procedure is:

• Check out the development branch of a project
• Implement your feature
• Test it locally till it does what you want it to do
• Commit it to your branch
• Open up a pull request referencing the bug / feature you want to solve.
• Wait for feedback from others
• Maybe solve the issues pointed out
• Wait that your code gets merged

I'm happy to try your code once it is clear at which lines it is added.

[basepi]

@hhenkel Nailed it. =)

[william20111]

Right tested locally got it working will create pull request and get some feedback on it.

[william20111]

Pull request in

#8629

[hhenkel]

I know that I'm kind of late....hadn't had time to check if that fixes anything for me.

For me the problem is still not fixed:

# salt-call grains.item os os_family oscodename osfullname osrelease saltversion
local:
  os: SUSE  Enterprise Server
  os_family: Suse
  oscodename: x86_64
  osfullname: SUSE Linux Enterprise Server
  osrelease: 11
  saltversion: 0.17.5

This is the actual version:

# cat /etc/SuSE-release 
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 1

Looking at the code of core.py I would say this is related to this:

# python
Python 2.6 (r26:66714, May  5 2010, 14:02:39) 
[GCC 4.3.4 [gcc-4_3-branch revision 152973]] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.linux_distribution()
('SUSE Linux Enterprise Server ', '11', 'x86_64')

As this code here ( https://github.com/saltstack/salt/blob/develop/salt/grains/core.py#L800-809) is not throwing an exception I still not see the correct information.

[hhenkel]

Okay just played around with the code (https://github.com/saltstack/salt/blob/develop/salt/grains/core.py#L800-809) and this is not the issue.

Problem is, that "/etc/lsb-release" exists but does not include useful info:

# cat /etc/lsb-release
LSB_VERSION="core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4.0-x86_64"

Therefore the "/etc/SuSE-release" code is never reached.

[william20111]

Yep just looking at it now. I cant now test this as I have actually moved jobs since submitting this don’t have nay SLES servers kicking around!

But what your saying seems to be the case. I asked a SUSE engineer about this and they have responded saying that its working as designed and its not meant to respond like the RHEL lsb. So something permanent will need to be put in for this. Maybe shift the /etc/SUSE/ check before the lsb check?

EDIT: Also this did work before for my SLES servers something been tweaked in this grain?

[basepi]

Sorry for my slowness re-opening this one.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.