Bug #1761
operatingsystemrelease fact should not rely on /etc/release on Solaris
| Status: | Closed | Start date: | 11/19/2008 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: |  James Turnbull |
% Done: | 0% |
|
| Category: | library | |||
| Target version: | 1.5.4 | |||
| Keywords: | solaris, opensolaris | Affected Facter version: | ||
| Branch: | ||||
| Votes: | 0 |
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
History
Updated by James Turnbull about 3 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.
Updated by James Turnbull about 3 years ago
- Assignee set to Andrew Wasilczuk
Updated by Martin Englund about 3 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
Updated by Martin Englund about 3 years ago
Yet another thing: zones in OpenSolaris does not have /etc/release present, so trying to get information from it will fail horribly :)
Updated by Andrew Wasilczuk about 3 years ago
- File solaris_operatingsystemrelease.patch added
I agree with Martin, both should be treated as SunOS.
Patch attached, tested on Solaris 10 and OpenSolaris.
Updated by Luke Kanies about 3 years ago
- Status changed from Needs More Information to Closed
Applied in commit:e6d987d.
Updated by Joel Shea about 3 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
Updated by Joel Shea almost 3 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
Updated by James Turnbull almost 3 years ago
Pushed in commit:94ea80731205da4503ace16a83dd418b43cd3bfb in branch master and 1.5.x.
Updated by James Turnbull almost 3 years ago
- Status changed from Re-opened to Closed
- Target version changed from 1.5.3 to 1.5.4