similar to: ANNOUNCE: Facter 1.5

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

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

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

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 {

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:

I am trying to streamline the current distribution specific setup and creation of VE''s within OpenVZ with puppet. My first attempt has gone horribly wrong as you will see below. Here''s the script I wrote to replace the redhat specific setup that OpenVZ used: [jleggett@lxp6d15m3 scripts]$ cat redhat-add_ip.sh #!/bin/bash # # Debug - take out later set -x

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''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 =

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 installed the 2.6.2 puppet and facter 1.5.8 gems and tried to run puppet, but it failed with the following message: err: Could not run Puppet configuration client: Could not retrieve local facts: uninitialized constant Facter::IPAddress Then I tried running facter alone: # facter /usr/lib64/ruby/vendor_ruby/1.8/facter/ipmess.rb:19: uninitialized constant Facter::IPAddress (NameError) After

Does anyone have any insight into this error message? err: Could not retrieve catalog from remote server: Error 400 on SERVER: The fact named fact_stomp_server does not appear to be a valid hostname. The value of '''' does not match ''^[a-zA-Z0-9.-]+$''. A common cause of this problem is running puppet agent as a normal user instead of root, or the fact is

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all We''re currently looking at the next release of Facter and the future direction of the tool. I''d like to try and prompt some discussions on facter and what people want from it. As a starter here''s some (although not all) of the ideas we''ll be working through: 1. Namespaces - add a namespace or tiered

I''m running puppet 0.24.6 on CentOS 5.2 from a puppetmaster on a virtual server to a variety of client servers both virtual and metal running either CentOS 5.2 or Fedora Core 10. I want to extend this to servers running RHEL 5 (and 6) in the near future. My problem is I have puppet set up with all repositories (mirrored locally using cobbler) included in one file in

Hello, I''m new to puppet and facter. Initially we are planning on using facter/puppet to inventory machines (Mac, Ubuntu, and RHEL). We plan on writing a number of custom facts. Obviouly some of the facts will only be specific to some OSs. I know there is a "confine" method, but it confuses me. It seems the confine statement in some of the recipes and in the Turnbull book is

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 {

Hello, I try to install puppet on freebsd 6.X. All is well but i cannot get the certificte to install and be recognized. I run .19.3. I run the puppetd --test --waitforcert 60 then sign and then i got: err: No certificate; running with reduced functionality. info: Creating a new SSL key at /usr/local/.aqadmin/puppet/conf/ssl/private_keys/xxxxxxxxxxxxxx.pem info: Creating a new certificate

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

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

Hi all, I''ve noticed that facter version superior from epel do not display lsbmajdistrelease fact: # facter lsbmajdistrelease 5 # rpm -qa|grep facter facter-1.5.5-1.el5 # cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.5 (Tikanga) # facter lsbmajdistrelease # cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.5 (Tikanga) # rpm -qa|grep facter