similar to: lsbmajdistrelease fact

Hi, I''m following http://reductivelabs.com/trac/puppet/wiki/PluginsInModules in order to use a custom fact. My modules looks like: # ls manifests/modules/network/ manifests plugins # ls manifests/modules/network/plugins/facter/primaryint.rb manifests/modules/network/plugins/facter/primaryint.rb as is said in doc. Then: Turn on pluginsync and specify factpath, so that the facts

Hello all, I use puppetmaster on a Debian Squeeze server (packaged from Debian 2.6.2-4) I am using a template for Debian Servers which works great for Lenny in order to update my sources.list automagically, here goes: deb http://ftp.ie.debian.org/debian <%= lsbdistcodename %> main contrib non-free deb http://security.debian.org/ <%= lsbdistcodename %>/updates main Now the problem

Hi, it seems that Facter 1.6.9 complains that "No LSB modules are available." on every run. This is on Ubuntu 10.04 and 12.04, probably others as well. This message (on stderr) usually comes from calling "lsb_release -v" when no additional LSB modules are installed. Facter apparently calls "lsb_release -v -s" in facter/lsbrelease.rb. This is neither fatal nor

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

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:

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 all, my name is Arnau Bria and I''m a sys admin in a center where we must deal with hundred hosts. We''re currently working with quattor, but it''s too complex for our purposes, so I''m looking for new admin tool. I''ve been playing with CFengine for few days (2 or 3) and I''ve seen some limitations that makes me thing that CFE is not our

Hi all, anyone has created the rpm packages of new versions for el4? only 5/6 at http://yum.puppetlabs.com/el/ TIA, Arnau -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For

Hi all, from http://docs.puppetlabs.com/guides/language_tutorial.html this syntax should be ok: file { [ ''foo'', ''bar'', ''foobar'' ]: owner => root, group => root, mode => 600, } I''ve this in my code: file { [ ''/software/atlas'' , ''/software/cms'' ,

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

I have set up puppet to create a facts.yaml file for mcollective using the following line: content => inline_template("<%= scope.to_hash.reject { |k,v| k.to_s =~ /(uptime.*|timestamp|.*free|macaddress.*|ipaddress)/ }.to_yaml %>"), However, it is creating a lot of unnecessary changes by reordering the facts in the yaml output as you can see in the diff output between to

Hi all, I''m in the procedure of migrating my old puppet server (puppet-2.6.14-1.el5) with mongrel to a new one (puppet-2.7.14-1.el6.noarch) with passenger. I''m facing a really strange behaviour with the catalog compilation time. I''ve 3 servers: 1.-) Centos 5.8 puppet-2.6.14-1.el5 + rubygem-mongrel-1.0.1-6.el5 Client: Compiled catalog for td055.pic.es in environment

Hi all, I''m doing a new install of my puppet server and I''m doing it like: 1.-) adding epel repo: http://fedoraproject.org/wiki/EPEL/FAQ#howtouse 2.-) yum -y install puppet-server 3.-) rm -rf /etc/puppet 4.-) copy my old puppet conf (from puppet-0.24.5 to 0.24.6) mv /etc/puppet.old /etc/puppet 5.-) start puppetmaster: [gridinstall etc]# /etc/init.d/puppetmaster start

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

Hi, I was wondering if it is possible to gain access to the nodename as a variable, in order to refer to the name or part of it inside a class. Eg: I have a lot of sites that essentially have the same configuration, except they are in different domains and have different requirements for things like resolv.conf. I can manage this by creating a node definition for each node and specifying some

Folks, I am adding a line to /etc/profile to export a FACT like this: export FACTER_system_role=<system_role>. In ubuntu, running puppet 2.6.4 and facter 1.5.8, this fact is not making it to the server. If I run sudo env | grep FACTER i see all facter related env variables there.. What could be the reason for this not working? Thanks in advance. -- You received this message because you

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

David Schmitt david wrote on Mon Jun 25 03:32:09 CDT 2007: > For the ongoing modularisation of my config I wrote a > assert_lsbdistcodename class today, which can be used for failing > parts or complete configurations if a certain variable is not set > (lsbdistcodename in this case). Please find the file attached. This is great, however I ran into something strange with this. It

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