The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Bug #1761

operatingsystemrelease fact should not rely on /etc/release on Solaris

Added by Andrew Wasilczuk over 5 years ago. Updated almost 4 years ago.

Status:ClosedStart date:11/19/2008
Priority:NormalDue date:
Assignee:James Turnbull% Done:

0%

Category:library
Target version:1.5.4
Keywords:solaris, opensolaris Affected Facter version:
Branch:

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This issue is currently not available for export. If you are experiencing the issue described below, please file a new ticket in JIRA. Once a new ticket has been created, please add a link to it that points back to this Redmine ticket.


Description

The format of /etc/release is not guaranteed to remain the same and should not be relied on. After introducing this in #1555 Facter broke on OpenSolaris:

operatingsystemrelease.rb:79: private method `chomp' called for
nil:NilClass (NoMethodError)

On OpenSolaris this fact should be set to the bi-weekly build number (uname -v). I’m not sure what this should be set to on Solaris 10, the current value seems a little made up. As far as I’m aware the proper patch level can also be obtained from uname -v on Solaris 10.

This issue has been discussed on puppet-users and osol-discuss lists: * http://groups.google.co.uk/group/puppet-users/browse_thread/thread/ee3507864af9a233?hl=en * http://ru.opensolaris.org/jive/message.jspa?messageID=299389

solaris_operatingsystemrelease.patch Magnifier (619 Bytes) Andrew Wasilczuk, 12/24/2008 01:14 pm

History

#1 Updated by James Turnbull over 5 years ago

  • Status changed from Unreviewed to Needs More Information

Okay I have a few issues here. I’ve read the threads on the mailing lists. I am still not clear on what to use here. Also the notes here indicate that neither is anyone else. Is it uname -v for both platforms? Or something else? Can/Should we distinguish between Solaris 10 and OpenSolaris (in this fact and the operatingsystem fact?)?

And a patch would be nice.

#2 Updated by James Turnbull over 5 years ago

  • Assignee set to Andrew Wasilczuk

#3 Updated by Martin Englund over 5 years ago

Talking about Solaris is actually a misnomer. It is SunOS which is the correct name – (Open)Solaris is a marketing name which takes the SunOS kernel and adds a bunch of other stuff, like Gnome, Firefox, administrative tools, etc. The resulting bundle is Solaris.

uname -r gives you the release: * 5.10 for Solaris 10 * 5.11 for OpenSolaris and Nevada

uname -v gives you different things depending on if it is a released product: * Kernel patch if it is released * Build number if it is unreleased

#4 Updated by Martin Englund over 5 years ago

Yet another thing: zones in OpenSolaris does not have /etc/release present, so trying to get information from it will fail horribly :)

#5 Updated by Andrew Wasilczuk over 5 years ago

I agree with Martin, both should be treated as SunOS.

Patch attached, tested on Solaris 10 and OpenSolaris.

#6 Updated by Luke Kanies over 5 years ago

  • Status changed from Needs More Information to Closed

Applied in commit:e6d987d.

#7 Updated by Joel Shea about 5 years ago

  • Status changed from Closed to Re-opened
  • Assignee changed from Andrew Wasilczuk to James Turnbull

Since ‘uname -v’ (on Solaris 10) returns the kernel patch-id, it should probably be the return value for the kernelversion fact.

It then seems reasonable that the operatingsystemrelease should default to the kernel release, i.e. ‘uname -r’

http://github.com/jwshea/facter/commit/658ae4bff3baff4fac5d20785816f1e51e62b740

#8 Updated by Joel Shea about 5 years ago

realist wrote:

Since ‘uname -v’ (on Solaris 10) returns the kernel patch-id, it should probably be the return value for the kernelversion fact.

It then seems reasonable that the operatingsystemrelease should default to the kernel release, i.e. ‘uname -r’

The behavior of the fix applied in “e6d987d”:http://projects.reductivelabs.com/projects/facter/repository/revisions/e6d987d333d79e11dd8782fad1286d8348419842 was also reported and confirmed as a regression on the following “puppet-user post”:http://groups.google.com/group/puppet-users/msg/01772a14474097c8

#9 Updated by James Turnbull about 5 years ago

Pushed in commit:94ea80731205da4503ace16a83dd418b43cd3bfb in branch master and 1.5.x.

#10 Updated by James Turnbull about 5 years ago

  • Status changed from Re-opened to Closed
  • Target version changed from 1.5.3 to 1.5.4

Also available in: Atom PDF