similar to: facter question

I am trying to come up with a workable solution in managing numerous Mac workstations allowing a high degree of flexibility with regards to certs. My puppet environment is setup to application installation on machines that have been ''imaged'' with a base OS and the puppet and facter apps. So, when a Mac is ''imaged'' and subsequently re-booted, puppet is run at

Reminder for Mac Puppeteers going to WWDC How about we meet for lunch at noon on Tuesday. Let''s try to get the table closet to the Odwalla refrigerator, just for reference. We can get more specific on this list on the 8th after we verify the set up. I might even get there a little earlier and put down "reserved" tags. --- Thank you, Allan Marcus Solutions Architect Central

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

Group - I''m putting a presentation together for $work (a large .gov) and I want to make sure I get my facts (pun intended) straight ... Are the following steps for Facter-Client-Server interaction correct (I have a feeling not): 1. Client puppet run is initiated (via regular schedule, puppetrun, or puppetd) 2. The client contacts the server and downloads any custom facts it does not

I just got approval to deploy puppet to about 1500 Macs! Now I have to actually do it. I''m considering two options. We have a security tool we use that is a Mac application and is already installed on all our Macs. Since it''s a Mac app, it''s basically a folder (a .app folder). I''m wondering if I can just install puppet into the .app directory, that way

packages.debian.org is lagging in terms of what it''s showing, but.... $ rmadison -u debian {puppet,facter} | grep unstable puppet | 0.25.4-1 | unstable | source, all facter | 1.5.7-1 | unstable | source, all they''re both up there now. -- nigel -- You received this message because you are subscribed to the Google Groups "Puppet Users" group.

Sometimes "facter --yaml" doesn''t list all the values specified on the command line. I can''t find rhyme nor reason why. Here''s a demo to show what I mean: # facter --version 1.5.7 # facter --yaml fqdn macaddress lsbdistcodename --- fqdn: my.host.name.example.com lsbdistcodename: squeeze macaddress: "00:00:00:00:00:00" We had been using the above

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, I''ve noticed that defining multiple facts in one file is possible, and puppet can make use of them correctly, but when trying to call with facter --puppet they are not shown, do I need something special to make them work as any other single custom fact? Master is running 2.6.7 This is a custom fact with two facts in it: [modules/foobar/lib/facter/foobar.rb ] require

Hi, I run into problems with the ipaddress fact using the latest Facter gem (1.6.4, 1.6.5) on SLES11. The versions and gems I use work perfectly fine on SLES10 SP3. The problem: running "facter" without arguments results in an error, even though the erroring fact "ipaddress" is ok. test:~ # cat /etc/SuSE-release SUSE Linux Enterprise Server 11 (x86_64) VERSION = 11 PATCHLEVEL

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

I could swear this worked fine earlier.. Now facter, and hence puppet, do not see the domain name anymore: What could cause this? C:\Temp>facter --version 1.6.2 C:\Temp>facter | findstr kernel kernel => windows kernelmajversion => 6.1 kernelrelease => 6.1.7601 kernelversion => 6.1.7601 C:\Temp>facter fqdn NCS-VDI-05.none C:\Temp>facter hostname NCS-VDI-05

I''m trying to load custom facts via /etc/facter/facts.d/* according to instructions on http://docs.puppetlabs.com/guides/custom_facts.html#structured-data-facts I must have missed a setting somewhere because I get nothing. The first clue may be that /etc/facter didn''t exist. I had to create it manually. Is there a setting or search path I need to create? Details: puppet

Not sure if this is another issue cropping up with 0.24.1 but I''m getting the following: info: Loading fact raid /etc/puppet/facts/location.rb:5: private method `split'' called for nil:NilClass (NoMethodError) from /usr/lib/ruby/site_ruby/1.8/facter.rb:510:in `call'' from /usr/lib/ruby/site_ruby/1.8/facter.rb:510:in `value'' from

I''ve just committed Facter 1.3.8. All of the work for this release was done by James Turnbull, so everyone should thank him for getting it done. Here''s the changelog: Fixed Rdoc::usage bug on CentOS 5 - closed Puppet #753 and Facter #40 Added support to return multiple interfaces and their IP addresses and MAC addressess as facts. Returns

Hello, Since i use facter 1.5.5 i got error running it by hand. It still work in puppet but i loosed the hability to run it from the command line: (aqadmin)> /var/lib/gems/1.8/gems/facter-1.5.5/bin/facter /var/lib/gems/1.8/gems/facter-1.5.5/bin/facter:50:in `require'': no such file to load -- facter (LoadError) from /var/lib/gems/1.8/gems/facter-1.5.5/bin/facter:50

Quick and dirty: --- lib/facter.rb (revision 203) +++ lib/facter.rb (working copy) @@ -989,6 +989,18 @@ %x{/usr/sbin/scutil --get LocalHostName} end end + Facter.add(:interfaces) do + confine :kernel => :linux + setcode do + %x{/sbin/ifconfig -a -s}.split($/)[1..-1].collect {|line|

Hi all, I am creating a recipe for rhel boxes which needs to determine what type of install is present (server or client). I thought I would use the facter fact lsbdistid for this purpose but when I run "facter lsbdistid" from the command line nothing is returned. If I just run facter and grep for lsbdistid, what I am looking for is returned. Does anyone know why this might be?

I just started getting this error on some machines after a yum update from centos 5.2 to centos 5.3. Does anyone know what it means? Since I''m not a ruby person, I''m not sure how to debug this, but it looks to me like facter is having trouble parsing information about my interfaces. # facter /usr/lib/ruby/site_ruby/1.8/facter/ipmess.rb:19: uninitialized constant

Hi all, I''m trying to find a better way to implement this, but I can''t think of. I have a jdk module that requires to create a symlink to whatever version is the one installed. Say I install jdk-6u35, it will create something like /usr/java/jdk_1.6.35. I would like to create a symlink /usr/java/jdk whose target would be /usr/java/jdk_1.6.35. The point here isn''t to ask