Feature #11082

operatingsystemrelease for Solaris

Added by John Warburton 6 months ago. Updated 5 days ago.

Status:Closed Start date:11/29/2011
Priority:Normal Due date:
Assignee:Stefan Schulte % Done:

0%
Category:library
Target version:2.0.0
Keywords: Affected Facter version:
Branch:https://github.com/stschulte/facter/tree/feature/master/11082
Votes: 1

Description

We need to know what release of Solaris installed. We have code (below) which parses /etc/release, which maybe others would like to see in future versions of facter rather than returning kernelversion

Code is clunky, as my ruby is pretty basic, but should go into lib/facter/operatingsystemrelease.rb. Ideally the regexp should not need the extra “ustring” search, but I haven’t worked out how to cater for when the “_u” is not present – which is why I’m not prepared to submit a patch

The values returned work correctly with the versioncmp function

    releasefile = "/etc/release"
    File::open(releasefile, "r") do |f|
        line = f.readline.chomp

        line =~ /s(\d+)[s|x]*.* [SPARC|X86]/
        relstring = $1

        # sometimes the _u is not there on the initial release
        line =~ /s\d+[s|x]*_u(\d+).* [SPARC|X86]/
        ustring = $1
        if (ustring.nil?)
            operatingsystemrelease = relstring
        else
            operatingsystemrelease = relstring + "_u#{ustring}"
        end

Note that this regexp has been tested against all /etc/release entries from Solaris 8 to Solaris 10 U10 (SPARC & x86) per Support Document How to Determine the Release and Default Kernel Version in the Solaris Operating System [ID 1002239.1] (you need an Oracle support account to view this file). I do not have a Solaris 11 server to validate Solaris 11

Here are my test results:

Solaris 8 s28_38shwp2 SPARC ==> 28
Solaris 8 6/00 s28s_u1wos_08 SPARC ==> 28_u1
Solaris 8 10/00 s28s_u2wos_11b SPARC ==> 28_u2
Solaris 8 1/01 s28s_u3wos_08 SPARC ==> 28_u3
Solaris 8 4/01 s28s_u4wos_08 SPARC ==> 28_u4
Solaris 8 7/01 s28s_u5wos_08 SPARC ==> 28_u5
Solaris 8 10/01 s28s_u6wos_08a SPARC ==> 28_u6
Solaris 8 2/02 s28s_u7wos_08a SPARC ==> 28_u7
Solaris 8 HW 12/02 s28s_hw1wos_06a SPARC ==> 28
Solaris 8 HW 5/03 s28s_hw2wos_06a SPARC ==> 28
Solaris 8 HW 7/03 s28s_hw3wos_05a SPARC ==> 28
Solaris 8 2/04 s28s_hw4wos_05a SPARC ==> 28
Solaris 9 s9_58shwpl3 SPARC ==> 9
Solaris 9 9/02 s9s_u1wos_08b SPARC ==> 9_u1
Solaris 9 12/02 s9s_u2wos_10 SPARC ==> 9_u2
Solaris 9 4/03 s9s_u3wos_08 SPARC ==> 9_u3
Solaris 9 8/03 s9s_u4wos_08a SPARC ==> 9_u4
Solaris 9 12/03 s9s_u5wos_08b SPARC ==> 9_u5
Solaris 9 4/04 s9s_u6wos_08a SPARC ==> 9_u6
Solaris 9 9/04 s9s_u7wos_09 SPARC ==> 9_u7
Solaris 9 9/05 s9s_u8wos_05 SPARC ==> 9_u8
Solaris 9 9/05 HW s9s_u9wos_06b SPARC ==> 9_u9
Solaris 10 3/05 s10_74L2a SPARC ==> 10
Solaris 10 3/05 HW1 s10s_wos_74L2a SPARC ==> 10
Solaris 10 3/05 HW2 s10s_hw2wos_05 SPARC ==> 10
Solaris 10 1/06 s10s_u1wos_19a SPARC ==> 10_u1
Solaris 10 6/06 s10s_u2wos_09a SPARC ==> 10_u2
Solaris 10 11/06 s10s_u3wos_10 SPARC ==> 10_u3
Solaris 10 8/07 s10s_u4wos_12b SPARC ==> 10_u4
Solaris 10 5/08 s10s_u5wos_10 SPARC ==> 10_u5
Solaris 10 10/08 s10s_u6wos_07b SPARC ==> 10_u6
Solaris 10 5/09 s10s_u7wos_08 SPARC ==> 10_u7
Solaris 10 10/09 s10s_u8wos_08a SPARC ==> 10_u8
Oracle Solaris 10 9/10 s10s_u9wos_14a SPARC ==> 10_u9
Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC ==> 10_u10
Solaris 10 3/05 HW1 s10x_wos_74L2a X86  ==> 10
Solaris 10 1/06 s10x_u1wos_19a X86 ==> 10_u1
Solaris 10 6/06 s10x_u2wos_09a X86  ==> 10_u2
Solaris 10 11/06 s10x_u3wos_10 X86  ==> 10_u3
Solaris 10 8/07 s10x_u4wos_12b X86  ==> 10_u4
Solaris 10 5/08 s10x_u5wos_10 X86  ==> 10_u5
Solaris 10 10/08 s10x_u6wos_07b X86  ==> 10_u6
Solaris 10 5/09 s10x_u7wos_08 X86 ==> 10_u7
Solaris 10 10/09 s10x_u8wos_08a X86 ==> 10_u8
Oracle Solaris 10 9/10 s10x_u9wos_14a X86 ==> 10_u9
Oracle Solaris 10 8/11 s10x_u10wos_17b X86 ==> 10_u10

Related issues

related to Facter - Refactor #11308: general operatingsystemrelease fact should be deprecated Needs Decision 12/09/2011

History

#1
Updated by Ken Barber 6 months ago

  • Category set to library
  • Status changed from Unreviewed to Accepted
  • Target version set to 1.6.x

Hey thanks John – this looks quite good actually.

If you can see your way to putting this into a github merge request that would be awesome, at least it would save us some time either way and you would be able to keep full credit on the patch. There are some contributor instructions here:

https://github.com/puppetlabs/facter/blob/master/CONTRIBUTING.md

Also usually for us to accept code submissions we require users to read and sign our CLA:

https://projects.puppetlabs.com/contributor_licenses/sign

Cheers :–).

#2
Updated by Stefan Schulte 6 months ago

  • Status changed from Accepted to In Topic Branch Pending Review
  • Branch set to https://github.com/stschulte/facter/tree/feature/1.6.x/11082

I simplified the code and made sure that it is still returning the same output that John provided in his test results.

#3
Updated by Ken Barber 6 months ago

Nice one :–). You got a pull request somewhere lying around? I can always pull from your branch its no biggie.

#4
Updated by Stefan Schulte 6 months ago

Hi Ken! Pull request created: https://github.com/puppetlabs/facter/pull/104

#5
Updated by Ken Barber 6 months ago

Did you get my comments on the pull request? Github notifications aren’t to be trusted :–).

#6
Updated by Stefan Schulte 6 months ago

  • Status changed from In Topic Branch Pending Review to Tests Insufficient
  • Assignee set to Stefan Schulte

I thoght I’d get the notifications by mail, but I guess I have to check my settings. And you are right, I should add some failure testing.

There is one additional thing worth mentioning: Before the change facter will set the operatingsystemrelease fact to the same value as the kernelrelease fact if we do not have a specific operatingsystemrelease.

So if some one used operatingsystemrelease to check against 5.10 or whatever it will not work in the future.

#7
Updated by Ken Barber 6 months ago

  • Target version changed from 1.6.x to 186

There is one additional thing worth mentioning: Before the change facter will set the operatingsystemrelease fact to the same value as the kernelrelease fact if we do not have a specific operatingsystemrelease.

So if some one used operatingsystemrelease to check against 5.10 or whatever it will not work in the future.

Huh. I didn’t realise that. Which means this can’t be a 1.6.x update as it breaks backwards compatibility – so lets change the target in that case then …

I still think having a proper ‘operatingsystemrelease’ with the update included is a positive thing however.

#8
Updated by Stefan Schulte 6 months ago

  • Status changed from Tests Insufficient to In Topic Branch Pending Review

I added some tests and just learned about a special behaviour of facter:

If we have more than one operatingsystemrelease fact that suits our system, facter will iterate over all instances until one is not returning nil or “”. So if the newly added operatingsystemrelease fact does return nil (release string cannot be parsed) or raises an exception (file is not present or empty) the next operatingsystemrelase fact is picked. And that is currently the one that just returns the kernelrelease fact.

This behaviour is now reflected in the tests but I cannot say I like it. I’d prefer to deprecate the operatingsystemrelease fact that returns the kernelrelease fact. Like printing a warning ‘operatingsystemrelease fact is not yet implemented for your system. Please use the kernelrelease fact instead. The value of the operatingsystemrelease fact may change in the future’

In the end the operatingsystemrelease fact would either return the correct value or nothing but not try to find something in between.

#9
Updated by Ken Barber 5 months ago

  • Status changed from In Topic Branch Pending Review to Code Insufficient

I added some tests and just learned about a special behaviour of facter:

Cheers mate. Can you rebase it off master? I just closed your pull request and marked this as Code Insufficient (which isn’t quite true – there just isn’t a more appropriate status) – reopen and change the ticket status when you’re ready.

If we have more than one operatingsystemrelease fact that suits our system, facter will iterate over all instances until one is not returning nil or “”. So if the newly added operatingsystemrelease fact does return nil (release string cannot be parsed) or raises an exception (file is not present or empty) the next operatingsystemrelase fact is picked. And that is currently the one that just returns the kernelrelease fact.

This behaviour is now reflected in the tests but I cannot say I like it. I’d prefer to deprecate the operatingsystemrelease fact that returns the kernelrelease fact. Like printing a warning ‘operatingsystemrelease fact is not yet implemented for your system. Please use the kernelrelease fact instead. The value of the operatingsystemrelease fact may change in the future’

In the end the operatingsystemrelease fact would either return the correct value or nothing but not try to find something in between.

I see your point and have some thoughts on it – lets cut another ticket as ‘Needs Decision’ and we’ll debate it there shall we?

#10
Updated by Stefan Schulte 5 months ago

  • Status changed from Code Insufficient to In Topic Branch Pending Review
  • Branch changed from https://github.com/stschulte/facter/tree/feature/1.6.x/11082 to https://github.com/stschulte/facter/tree/feature/master/11082

I’ve rebased on master and opened a new pull request: https://github.com/puppetlabs/facter/pull/110

I’ve also created a new issue about deprecating the generl operatingsystem release fact: #11308

#11
Updated by Ken Barber 5 months ago

So I’ve tested the code – and it all looks good and works on my Solaris 10 system as well.

One thing that is bothering me is the revision numbers for Solaris 8 … I don’t remember Sun ever officially calling Solaris 8 “2.8”. I believe the 2 was dropped after 2.6.x. I wasn’t sure about this, but found a reference to this in wikipedia (no supporting reference though):

http://en.wikipedia.org/wiki/Solaris_(operating_system)#Version_history

I also found an image of the old media kit:

http://media.photobucket.com/image/solaris%208%20media%20kit/tritecsystems/Solaris-8.jpg

I know the internal /etc/release file has ‘28’ but this is just an internal representation (Sun did this kind of weird stuff a lot internally) and doesn’t reflect the marketing release numbers. I’ve been a Solaris admin for some years and I wouldn’t have called it Solaris 2.8 – so I guess my point is it might be weird to other admins as well.

What does everyone think?

#12
Updated by Daniel Pittman 4 months ago

  • Status changed from In Topic Branch Pending Review to Merged - Pending Release

Ken Barber wrote:

One thing that is bothering me is the revision numbers for Solaris 8 … I don’t remember Sun ever officially calling Solaris 8 “2.8”. I believe the 2 was dropped after 2.6.x. I wasn’t sure about this, but found a reference to this in wikipedia (no supporting reference though):

What does everyone think?

I think this is a valid consideration, but the change is more correct than the previous state of the code, and after a month with no feedback I would rather move forward and then fix up the problem – if it really is one – when it is discovered.

Truth be told, our OS version facts are pretty arbitrary identifiers anyhow, so I don’t think a mismatch there would be such a big deal.

#13
Updated by Ken Barber 4 months ago

  • Target version changed from 186 to 2.0.0

#14
Updated by Matthaus Litteken 5 days ago

  • Status changed from Merged - Pending Release to Closed

Released in facter 2.0.0rc1

Also available in: Atom PDF