similar to: Facter operatingsystemrelease on Fedora

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:

Hello, I am running puppet server version 0.25.4-2, and since Debian squeeze is the new stable release I would like to adapt some of my modules. I have a syslog-ng module, I would like to specify another template for my squeeze server. I changed my init.pp as follow : if ($operatingsystemrelease <= 5.0.8) { $syslog_template = "syslog/syslog-ng.conf.erb" } else {

Hi all, I''ve finally gotten around to releasing Facter 1.5. As the version bump implies, this is a relatively significant release (for a 2.3k line program, anyway). Mostly, the biggest change is refactoring the code internally so that all of the functionality is split into separate classes in separate files. Also, the facts are all loaded on-demand, which provides dramatic

For the benefit of those running OEL (Oracle Enterprise Linux) or OVS, be aware that under 2.6.0rc4 facter doesn''t properly recognize OEL in /usr/lib/ruby/site_ruby/1.8/facter/operatingsystemrelease.rb. A diff for a fix is below; probably not the best fix but if you need it work now, this''ll do it for you. I''ve already filed a bug:

I found that has been fixed in Fedora and RedHat which return the version ( like 5, 7, 8 etc.. ) but in CentOS, it still return the kernel version instead. ================= Barrow Kwan ThoughtWorks, Inc. New from ThoughtWorks: Mingle, an Agile project management application. Mingle. Project Intelligence. Powerfully Simple. More at http://studios.thoughtworks.com

Hi. I have the following facts available: # facter | grep oper operatingsystem => CentOS operatingsystemrelease => 6.2 Now, if I wish to use conditionals on these facts, I have to do it like this: case $operatingsystem {} case $::operatingsystemrelease {} I''m puzzled as to why can''t I just use $operatingsystemrelease, and what do these two semicolons mean? Thank

Hi all, I''m looking at changing the operatingsystemrelease fact for Red Hat. Linux currently just uses the kernel release as the operating system release, but I''ve got a client who wants the release to have both the specific distro (e.g., AS or EL) and the release (e.g., 3 or 4). Will this particularly annoy anyone? Anyone want to help make the release string work on

Hi all I''m working on my modular recursive Makefile & svn-backed home for my Puppet manifests, custom functions, types, etc. So I''m trying to put together individual modules, test targets and so on. I have noticed that the $libdir (and probably the other configuration options too) sources from puppet.conf are not overridden by specifying --libdir=blah on the commmand line

I have 2 RHEL 5.4 systems where all facter lsb* items are missing. Any ideas? Sanitized facter output: architecture => i386 domain => missyou.edu facterversion => 1.5.7 fqdn => broken.missyou.edu hardwareisa => i686 hardwaremodel => i686 hostname => broken id => root interfaces => eth0,sit0 ipaddress => 1.2.1.5 ipaddress_eth0 => 1.2.1.5 is_virtual => true

Just upgraded to 2.7.6 and the yumrepo type does not write out our yum configs correctly, anyone experiencing this? Documentation hasn''t changed from what I can tell for this type. # facter -version 1.6.2 # puppetd --version 2.7.6 # facter architecture x86_64 # facter operatingsystem Fedora # facter operatingsystemrelease 14 ==== My manifest ==== yumrepo {

Hello guys :), I''m kind of new to Puppet and stuck in defining a conditional statement. Here my problem: I want to provide different apt/source.list for different versions of Debian, 6.0.x and 7.0.x, which also run different versions of Puppet, 2.7.x and 3.2.x. My first idea was to use facters variable operatingsystemmajrelease and define like this: file {

For 40 days and 40 nights Facter wandered in the wilderness sustained only by the occasional patch and bottle of Kool-Aid. Slightly less tanned and equally happy Facter 1.5.8 has arrived! 1.5.8 is a feature and maintenance release containing a number of fixes, updates and additional tests. You can get the release at: http://reductivelabs.com/downloads/facter/facter-1.5.8.tar.gz Please log any

I just realized that if you don''t have redhat-lsb on your (Fedora 7) box, all those lsb* facts don''t show up. Should I make redhat-lsb a requirement for the facter rpm to guard against that ? David

Facter 2.0.0rc1 is a feature release candidate with bug fixes, features and other improvements. Facter 2.0 is designed to accompany the upcoming Puppet 3.0 release and has breaking changes from Facter 1.6.x. Facter 2.0 is not backwards compatible with Puppet 2.6 or 2.7. It includes contributions from the following people: Chris Price, Daniel Black, Daniel Pittman, Garrett Honeycutt, Gary Larizza,

Hi, I''m running into a problem with the user type with puppet 0.20.1... this worked before with 0.19.x at least, not sure about 0.20. But I''ve got adduser.pp: <snip> define adduser($uid, $gid, $groups="users", $membership="minimum") { group { $name: gid => $gid, allowdupe => false, ensure

Hi all, I''m trying to get puppet working for the first time, and I''ve run into something that''s got me stumped. This is all on Solaris 10/x64. The initial startup of puppetmasterd wasn''t working, and it appeared to be related to the SSL certs not getting generated properly. I managed to trace that down to the fact that facter isn''t finding the

I just built new puppet rpm''s for Fedora (puppet-0.22.1-2) that fix the lockdir problem that many of you have encountered. The packages should show up on a mirror near you very soon. Unfortunately, I am having trouble getting to my buildsystem that I use for the RHEL versions of the RPM; I made the source rpm available on my people page[1] If you need the RPM for RHEL, you need to

I just upgraded to puppet 0.20.1 from 0.18.4 (both using the debian packages). After the upgrade, I''m getting the following error: err: Could not find type "remotefile" in file /etc/puppet/manifests/classes/kerberos.pp at line 47 Here''s the where the error is occuring: service { nfs-common: ensure => running, hasstatus => true, subscribe

Just started a "pilot" puppet server for real after messing around in VMs for the past week or so... I used the 0.24.0 since it was available, and on the test run, got this: err: Could not prefetch package provider ''yum'': Execution of ''/usr/bin/python /usr/lib/ruby/site_ruby/1.8/puppet/provider/package/yumhelper.py'' returned 512: /usr/bin/python:

I am writing my first module for ntp, I have a few different versions of Linux and also releases. The code worked when I only had one flavor of Linux but now I have four and possibly more flavors. My snippet that doesn''t work is as follows; ( I am not even sure this is the route I should be going if anyone has a better way please advise. Thank you in advance) $ntp_service = $ntpdaemon {