From looking at the Facter code, it looks like the ''operatingsystemrelease'' fact is currently a mirror of the ''kernelrelease'' fact. I''d like to implement this fact so that it returns the major version of the operating system, eg: Debian Sarge: operatingsystemrelease => 3.1 Debian Etch: operatingsystemrelease => 4.0 RHEL3 update 8: operatingsystemrelease => 3.8 RHEL4 update 5: operatingsystemrelease => 4.5 CentOS 4.5: operatingsystemrelease => 4.5 default: operatingsystemrelease => kernelrelease I have access to various releases of the major OSs above, plus Solaris 10 (i386). I figure this should be easy enough, so i''m happy to tackle it as my first foray into Ruby. Thoughts? -- Mike Pountney, Information Systems Manager, Semantico, Floor 1, 21-23 Dyke Road, Brighton BN1 3FE <http://www.semantico.com/> <mailto:Mike.Pountney@semantico.com> <tel:+44-1273-358209> <fax:+44-1273-723232>
Mike Pountney <Mike.Pountney@semantico.com> writes:> From looking at the Facter code, it looks like the > ''operatingsystemrelease'' fact is currently a mirror of the > ''kernelrelease'' fact.> I''d like to implement this fact so that it returns the major version of > the operating system, eg:> Debian Sarge: operatingsystemrelease => 3.1 > Debian Etch: operatingsystemrelease => 4.0 > RHEL3 update 8: operatingsystemrelease => 3.8 > RHEL4 update 5: operatingsystemrelease => 4.5 > CentOS 4.5: operatingsystemrelease => 4.5 > default: operatingsystemrelease => kernelrelease> I have access to various releases of the major OSs above, plus Solaris > 10 (i386).> I figure this should be easy enough, so i''m happy to tackle it as my > first foray into Ruby.> Thoughts?Getting a reasonable value for operatingsystemrelease on Debian is tricky and depends a great deal on what you intend. We''re currently using the facts that we get from lsb_release, and they work for what we want to do, but that''s because we''re very careful about the possible ambiguities. Debian''s dependency management is strong enough that it''s quite normal for a Debian system to have packages installed from as many as three or four different "operating system" releases, at which point it really isn''t any of those releases in any global sense. Essentially, Debian really doesn''t manage its releases that way, and therefore that value doesn''t have a well-defined meaning. The naive approach is to just use /etc/debian_version, and that will do something reasonable for the 80% case of people running stable with no mixed sources.list files, but it''s important to be aware that the other 20% of the cases may be very confusing. What you''re getting from that file is really the version of base-files that you have installed, which may or may not have an obvious relationship to what versions of other things you have installed (like libc6, which is usually what people care about it). -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
> The naive approach is to just use /etc/debian_version, and that will do > something reasonable for the 80% case of people running stable with no > mixed sources.list files, but it''s important to be aware that the other > 20% of the cases may be very confusing. What you''re getting from that > file is really the version of base-files that you have installed, which > may or may not have an obvious relationship to what versions of other > things you have installed (like libc6, which is usually what people care > about it). >Without even going into how accurate the 80/20 split mentioned above here might be for people running pure debian systems, *everyone* running an Ubuntu system will have an /etc/debian_version file that reports back a valid Debian version number or string (when it happens to be based on testing/unstable), but this does nothing to expose which version of Ubuntu is relevant. So, checking for /etc/debian_version as a test for OS and release isn''t a very good test. I had written a couple of facts to assist with this, and then it was pointed out to me that lsb-release exists in debian sarge (and anything later) already. The facts I had added are at https://reductivelabs.com/trac/puppet/wiki/DebianUbuntu_CodenameRecipe if they will be of use to anyone reading this. I had initially added a hash lookup on debian_version to display a codename (sarge etc), and then found that ubuntu had /etc/lsb-release, so I started parsing that where appropriate, then discovered it didn''t exist on etch anyway (you run lsb-release -a instead). And then someone pointed out on that page that the lsb* facts exist anyway :)
> Without even going into how accurate the 80/20 split mentioned above > here might be for people running pure debian systems, *everyone* running > an Ubuntu system will have an /etc/debian_version file that reports back > a valid Debian version number or string (when it happens to be based on > testing/unstable), but this does nothing to expose which version of > Ubuntu is relevant. So, checking for /etc/debian_version as a test for > OS and release isn''t a very good test. >Good point, I hadn''t thought about the sheer number of debian-based distros. <blinkers off>> I had written a couple of facts to assist with this, and then it was > pointed out to me that lsb-release exists in debian sarge (and anything > later) already. >Ah-ha! I hadn''t realised this either - hence my request. I''ve put a ''package {lsb-release: }'' into my default debian_soe.pp now, so that gives me pretty much what I want. Thanks, mike