similar to: Conditional statement =,<,> etc.

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:

Currently, facter returns the kernel version as both the kernel and operatingsystemrelease facts. I would like to change that so that on Fedora, operatingsystemrelease is the release number (5,6,7 etc.) or ''Rawhide'' ... are there any objections to making that change ? David

Was wanting to go and kick the openstack tires and was wondering if anyone has loaded up the RDO version. Wasn't sure if any of the issues that were seen early on have been corrected or what needs to be done for installation on a centos 7 host? Thanks.

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. 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

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 {

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 {

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

Hi, i want to use Puppet to install all packages from a webserver (no repository) . Therefore I wrote following Script: class install_package { case "$operatingsystem" { SLES: { notify {"${operatingsystem} ${operatingsystemrelease} detected":} notify {"Installing $packagename now:":}

Hi All, In the example42 modules, I noticed the following is done: # Calculate OS version (without using lsb facts) $ossplit=split($operatingsystemrelease, ''[.]'') $osver=$ossplit[0] I''ve been using $lsbmajdistrelease in all my configs. Is there any particular reason why I might want to use the above instead? (apart from the dependency on redhat-lsb, which is

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

My manifest includes this snippet class app_client_openbsd { $app_client_pkgs_obsd = [ ''glib2-2.24.1p2'', ''gtar-1.23p1'' ] package { "${app_client_pkgs_obsd}": ensure => ''installed'', source => "http://${installserver}/openbsd/${operatingsystemrelease}/packages/${hardwaremodel}/${name}.tgz", } This

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

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:

Hello Puppet list, I am taking over the puppet configuration of a sysadmin who left, and am having troubles deploying puppet to a new node. We are using puppet v2.7.3 both on the client and the puppetmaster, on Ubuntu 10.10. The node asks for a certificate fine, and I signed it on the puppetmaster. For the following logs extract I ve replaced the FQDN of my node by puppet.example.com. When doing

I''m trying to write a script that runs command based on version of Redhat OS. For example, if the RHEL version is 6.0, it will run command. I was able to write file read script in ruby that would read file and execute but it didn''t seem to work in puppet script. Has anyone done something like this? $redhat_version_file = "/etc/redhat-release" $redhat_version =

Just started a rollout of centos 6.x across our Puppet deployment (100-odd servers). what fact would people suggest I use to distinguish 5.x from 6.x (quite a lot of subsystems are different between major releases)? lsb* facts don''t seem to be present on centos 6 - is this an EPEL bug, or have they just been removed in Facter? Thanks! -- You received this message because you are

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

Hi all, I''m trying to work with hiera database in puppet and i''m having problems using %{variables} because they don''t get the values and i don''t know why. file hiera.yaml: cat hiera.yaml --- :backends: - yaml - puppet :hierarchy:- nodes/%{domain}/%{hostname} - os/%{operatingsystem}/%{operatingsystemrelease} -

I''m re-posting this because I''m not sure that it got through the first time. If someone could at least echo back that this is reaching the list, I''d appreciate it. (I''m new to the list.) Sometimes (with variable frequency) storeconfigs stores the wrong data in the fact_values table. This has the end result that exported resources, when collected, have