date:20130911

Hi all,

I'm having some issues getting hiera to check out a subdirectory in it's 
hierarchy,

I've set a custom fact to reveal what my working environment is. Puppet 3 / 
PE3.0.1

i.e. facter -p my_env shows test

My hiera.yaml has an extract like the following;

:hierarchy:
  - defaults
  - %{::clientcert}
  - %{::my_env}/common
  - common


I have a hieradata/test/common.yaml file with the required data I'm after.

If I run a hiera -d for the variable I'm after, my datadir is found, but I 
can see that it only tries to parse defaults.yaml and common.yaml, but 
neither clientcert or my_env directories are searched or mentioned in the 
debug output.

I've tried with and without the ::

If I place my key pair in either defaults, or common, it's found 
successfully.

( Indeed, if I run facter clientcert, nothing is actually returned?? This 
is the default in the hiera.conf file I see. clientcert, rather than fqdn?? 
)

Does anybody have the correct syntax for Puppet 3 hiera to search in a 
subdirectory as above?

Thanks Steven

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Puppet environments versus the PE console?

Hi,

I was wondering if it's possible to use (puppet.conf) environments within 
the classes in the PE console? I saw this link, but wondered if there had 
been any updates or other experiences from anybody?

http://projects.puppetlabs.com/issues/6608

Thanks,

Steven

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] An assortment of 2.x agents out there...a Puppet 3 PM, and Satellite to lend a hand? Agent update / migration approach?

Hi,

We have a fairly large number of 2.x FOS puppet agents out there in RH5, 6 
and Solaris 10 server land. We've just installed PE3 on RH6.4, and trying 
to work out how to migrate all of the agents across.

We have a new Satellite in the mix to lend a hand if necessary.

I'm curious to see how others have addressed this one.

I was thinking that we should be creating a separate channel on Satellite 
to accommodate the Puppet EL5, EL6 and Solaris 10 Sparc software firstly. 
Then maybe use FPM to assist with the creation of an RPM and PKGs, 
including an answers files to point the new agent at the new PE3 server. 
Package to be signed on Satellite and deplyed out to clients to do the 
upgrade magic

My fear is that the old agent will not come off cleanly, or something else 
bad may happen.

Does anybody have any ideas or strategies on this one?

Thanks again!

Steven

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Setting up an HA Puppet console using HAProxy

Hi all,

I'm trying to set up an HA Puppet 3 (PE3) console. My goal is to use 
HAProxy to present the puppet VIP, and have two load balance Puppet Masters 
in behind.

My plan goes along the following lines. The first PM would be the active CA 
*and* console. Port 443 and 8140 will need to be handled by HAProxy, but 
I'm not certain how this should be set up.

Database and MCollective aside, I understand the process for setting up the 
2nd server is similar to the first, but we need a ca_server = false in the 
puppet.conf as we should only have one CA active.

If I load balance 8140 to both boxes, that will mean that regular Puppet 
traffic may be OK, but the agent CSR will be round robin distributed to the 
2ndary which is not running an active CA...hmmm. Not good.

Maybe update the apache code to make SSL certificate magic run on a 
different port, or?

Does anybody have any advice on what to do with regards to the secondary 
console, which I'm assuming must be passive whilst the first is running?

I suppose my question is around how to set up a load balanced pair of 
Puppet Masters (PE3), using HAProxy. Any experiences, or guides? 

My brain is hurting.

Thanks

Steven

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Offering Puppet As A Service

2013-09-11 Thread Josh

We have several internal customers that we would like to start offering 
Puppet as a Service to.  Our central group would manage Puppet masters, 
ENC, etc.  But, we want other independent groups to be able to use our 
Puppet services.

Is anyone currently doing this?  If so, how are you handling segregation of 
manifests?  Are you creating multiple environments for each internal 
customers (perhaps with one common environment shared amongst all for base 
configuration).

Any suggestions would be greatly appreciated.

Thanks,

Josh

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Custom Fact undefined in manifests

2013-09-11 Thread David Thompson


On 9/10/13 5:49 PM, Denmat wrote:


On 11/09/2013, at 1:38, David Thompson dthomp...@waisman.wisc.edu
mailto:dthomp...@waisman.wisc.edu wrote:


I'm working with custom facts with facter 1.7.2.  I've created a fact
file with an ntp configuration fact in it:

# grep ntp_conf /etc/facter/facts.d/myfacts.txt
puppet:///modules/ntp/DEFAULT/ntp_conf

facter knows the fact is there:

# facter -p v_ntp__ntp_conf
puppet:///modules/ntp/DEFAULT/ntp_conf

...but puppet thinks the variable is undefined:

# cat /tmp/notify.pp
notify{$hardwaremodel:}
notify{$v_ntp__ntp_conf:}


For completeness, I'll add that I get the same result regardless of 
whether I refer to the custom fact as $v_ntp__ntp_conf or 
$::v_ntp__ntp_conf, regardless of whether I try to expand the custom 
fact in a string or use it in a conditional test.


Based on the lack of response, it looks like I should open a bug report?

David


[root@sazabi facts.d]# puppet apply /tmp/notify.pp
Notice: x86_64
Notice: /Stage[main]//Notify[x86_64]/message: defined 'message' as
'x86_64'
Notice: undef
Notice: /Stage[main]//Notify[undef]/message: defined 'message' as 'undef'
Notice: Finished catalog run in 0.28 seconds

What am I missing here?  Thanks!

--
You received this message because you are subscribed to the Google
Groups Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send
an email to puppet-users+unsubscr...@googlegroups.com
mailto:puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com
mailto:puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.


--
You received this message because you are subscribed to the Google
Groups Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send
an email to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.



--
David Thompson
Waisman Center Brain Imaging and Behavior Lab
1500 Highland Ave. Room T133
Madison, WI  53705-2280
(608) 265-6608
dthompson (at) waisman (dot) wisc (dot) edu

--
You received this message because you are subscribed to the Google Groups Puppet 
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Ordering and templates question/issue



On Tuesday, September 10, 2013 8:53:10 AM UTC-5, sjr wrote:

 Hi John,

 thanks for your answer, first of all I must say I just wanted to 
 experiment and learn, it's not like I'm going to put such awful hacks :-) 
 in productionmostly because I guess it's easy they can be changed over 
 the time as they are not part of puppet DSL and so, it can be harder to 
 maintain and for other colleagues to understand.

 OK, now to the point...I forgot to include the node definition, sorry 
 about that, it looks like:

 node hostname {
   class {'test1': }
   test1::print {'test11':
 message = 'test11',
   }
   test1::print {'test12':
 message = 'test13',
   }
   test1::print {'test13':
 message = 'test13',
   }

 So I understand that when you say I haven't defined any resource it's 
 because I forgot to mention that part, right?



Yes.

 

 If so, why the define types are not showing up in the file?



You have not fully appreciated the implications of the evaluation-order 
dependency of scope.catalog.resources.  The defined-type instances are not 
showing up in the file because their declarations have not yet been 
evaluated when the template is evaluated.  Overall evaluation order is 
difficult to predict, and it is not stable with respect changes in your 
manifest set.  I cannot emphasize strongly enough how important it is to 
avoid evaluation-order dependencies in your Puppet code.

 

 Also, as you can see in the content of the file I included in my previous 
 message, Class[test1] was declared and showed in the content of the file, 
 but the File resource itself was not there when the template was built.



Of course it wasn't.  The value of the File's 'content' parameter is 
generated by evaluating the template via the template() function (on the 
master, during catalog compilation, the same as all Puppet functions are 
executed).  Puppet must compute the values of the resource's parameters 
before it can add the resource to the catalog.

 


 I have the feeling the template is evaluated before all this resources are 
 present in the catalog...am I wrong? Is that expected behavior?



As described above, in this case the template will reliably be evaluated 
before the File because the template evaluation is subsidiary to the File's 
declaration.  Also, it happens that the template is evaluated before the 
three declarations of Test1::Print instances, but you should not 
over-interpret that result.  In particular, you should not use it to try to 
predict evaluation order within other manifest sets.  That should not be a 
problem, however, since you will be carefully avoiding code for which 
evaluation order males any difference.  Right?


John

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Ordering and templates question/issue



On Wednesday, September 11, 2013 8:35:07 AM UTC-5, jcbollinger wrote:

 males any difference



makes, that is. 

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Custom Fact undefined in manifests



On Wednesday, September 11, 2013 8:07:59 AM UTC-5, David Thompson wrote:

 On 9/10/13 5:49 PM, Denmat wrote: 

  On 11/09/2013, at 1:38, David Thompson 
  dtho...@waisman.wisc.edujavascript: 
  mailto:dtho...@waisman.wisc.edu javascript: wrote: 
  
  I'm working with custom facts with facter 1.7.2.  I've created a fact 
  file with an ntp configuration fact in it: 
  
  # grep ntp_conf /etc/facter/facts.d/myfacts.txt 
  puppet:///modules/ntp/DEFAULT/ntp_conf 
  
  facter knows the fact is there: 
  
  # facter -p v_ntp__ntp_conf 
  puppet:///modules/ntp/DEFAULT/ntp_conf 
  
  ...but puppet thinks the variable is undefined: 
  
  # cat /tmp/notify.pp 
  notify{$hardwaremodel:} 
  notify{$v_ntp__ntp_conf:} 

 For completeness, I'll add that I get the same result regardless of 
 whether I refer to the custom fact as $v_ntp__ntp_conf or 
 $::v_ntp__ntp_conf, regardless of whether I try to expand the custom 
 fact in a string or use it in a conditional test. 

 Based on the lack of response, it looks like I should open a bug report? 



Lack of response?  This is a volunteer community forum, not a paid 
technical support service.  Give it some time.

Before you open a bug report, you should make sure that the file containing 
your custom fact(s) is readable by the Puppet agent service.  That facter 
can read the file when you run it from the command line does not prove 
that.  Even though the agent runs as a privileged user (or should), access 
could still be blocked in various ways, such as

   1. Mandatory access controls (a.k.a. SELinux in enforcing mode) could 
   allow you to read the file, but prevent the agent service from doing so.
   2. If /etc/facter/facts.d is on an NFS-mounted filesystem that performs 
   root-squashing, then the agent may have less permissions on it than you, 
   personally, do.

There are probably other means.

Also, make sure Puppet is using the same Facter that you are using from the 
command line.  If you have multiple versions installed then all manner of 
havoc might ensue.  You might get multiple versions by installing them from 
gem or from source into different Ruby libraries, or into different parts 
of the same Ruby lib.


John

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Custom Fact undefined in manifests

2013-09-11 Thread David Thompson


On 9/11/13 8:54 AM, jcbollinger wrote:


Lack of response?  This is a volunteer community forum, not a paid
technical support service.  Give it some time.


No offense intended.  I'm continually impressed by the effort made by 
the volunteers who watch this lists and provide so much help.



Before you open a bug report, you should make sure that the file
containing your custom fact(s) is readable by the Puppet agent service.
That facter can read the file when you run it from the command line does
not prove that.  Even though the agent runs as a privileged user (or
should), access could still be blocked in various ways, such as

 1. Mandatory access controls (a.k.a. SELinux in enforcing mode) could
allow you to read the file, but prevent the agent service from doing so.
 2. If /etc/facter/facts.d is on an NFS-mounted filesystem that performs
root-squashing, then the agent may have less permissions on it than
you, personally, do.

There are probably other means.

Also, make sure Puppet is using the same Facter that you are using from
the command line.  If you have multiple versions installed then all
manner of havoc might ensue.  You might get multiple versions by
installing them from gem or from source into different Ruby libraries,
or into different parts of the same Ruby lib.


All good ideas.  An strace of  puppet agent --test (and/or the test 
manifest above) shows that puppet is able to read the fact file (and, 
yes, it's on the local disk), and the the version of facter being loaded 
is the correct (and only) one (in my case, the RPM version 1.7.2, from 
/usr/lib/ruby/site_ruby/1.8/facter.rb and friends), and still show the 
custom facts as undef.


Even if I reduce my custom facts to a single file containing a single 
trivial line (somefact=somevalue), the custom fact shows up in facter 
but not in puppet.


I also get the same result when I pass the fact as yaml.  I tried json, 
but got an error about missing the json gem, even though I have the 
puppetlabsdep rubygem-json RPM installed.


--
David Thompson
Waisman Center Brain Imaging and Behavior Lab
1500 Highland Ave. Room T133
Madison, WI  53705-2280
(608) 265-6608
dthompson (at) waisman (dot) wisc (dot) edu

--
You received this message because you are subscribed to the Google Groups Puppet 
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: getting array of hostnames of clients



On Wednesday, September 11, 2013 2:49:50 AM UTC-5, Steve Wray wrote:

 I need to get an array of hostnames of clients of the puppet server.

 There doesn't seem to be a simple way to do this so I've tried a few 
 methods.

 I've tried a curl expression in a fact like this:

 curl -s -k -H Accept: yaml 
 https://localhost:8140/production/facts_search/search?facts.nodetypet=testnodes



In other words, this is intended to retrieve the desired information via 
the master's REST API.  I'm not quite making the connection here, however: 
how is putting that expression into a fact supposed to achieve your result?

Do you mean you have a custom fact that executes that command and parses 
the YAML result to produce the desired array?  That seems odd, because in 
that case 'localhost' probably would not resolve to the correct machine (it 
would be the client, not the master), and because the result is not a 
property of the node.

Or do you mean that you pass the command itself as a literal fact value, 
which the master executes locally to extract the result?  Again in that 
case the value is not a property of the node, so it doesn't appear to make 
much sense to use a fact.  Also, it would be a serious security risk for 
the master to execute commands provided by clients.

 

 where I've got a nodetype fact which works fine for me.

 Now, this used to work but doesn't any more. Between it working and now 
 I've changed to using puppetdb. I'm not sure if theres a connection.

 The error returned is:

 Caught NoMethodError: undefined method `' for nil:NilClass



There could be a connection.  I have lately seen some evidence that 
puppetdb may not reliably escape fact values when it stores them.  That 
would be a serious flaw, but I cannot confirm its existence.

Alternatively, if you have also updated your master, then it may be that 
the data returned by the REST call has changed in form or content.  Do you 
get what you expect if you run it from the command line?

 


 The next thing I tried was to get each interesting node to create a file 
 on the puppetmaster server. So I now have a bunch of files in /tmp/ with 
 distinctive names which contain only the hostname of that puppet client.



Yuck.

 


 I have a fact which is supposed to cat these together and, with luck, turn 
 them into an array at some time. What I currently have is this:



Facts are properties of target nodes, and their values are evaluated 
there.  Dropping a bunch of files on the master could allow the Puppet 
agent to collect data from them into a fact when it runs on the Puppet 
master server, but it cannot do anything for agents running on other 
nodes.  Do you need the information on nodes other than the master?

 

 require 'facter'
 Facter.add(nodelist) do
   setcode do
 path=/tmp
 if File.exists?(path)  File.directory?(path)  ! Dir[path + 
 '/*'].empty?
 output = Facter::Util::Resolution.exec(/bin/cat 
 /tmp/testnode*).split('\n').join(',')
 else
   output = empty
 end
 output
   end
 end

 but this isn't getting anything in the fact at all, not even empty. 
 Running that cat command on the commandline returns exactly what I would 
 expect.



If you're not getting the fact at all, even after you restart the agent 
(though that should not be necessary), then I conclude that the fact has 
not been synced to the client.

 


 If I run facter on the commandline like this:
 FACTERLIB=/etc/puppet/modules/smokeping_prep/lib/facts facter  nodelist

 I get the list I expect.



On *which* command line?  You could have the fact installed on the master, 
but not synced to clients.

 


 On each node I have this:
   @@file { testnode-{$::fqdn}:
 ensure = file,
 path = /tmp/testnode-$::fqdn.txt,
 mode = 640, owner = root,
 tag = 'testnodes',
 content = $::hostname
 ,
   }

 On the puppetmaster node definition I have this:
   File | tag == testnodes |

   file { 'nodelist':
 path = '/tmp/nodelist',
 content = 
 $::nodelist
 
 }
 }

 and I was expecting a file /tmp/nodelist to contain the text from the fact 
 $::nodelist but the file is empty.



   1. You are collecting the Files only on the master, therefore only the 
   master's $::nodelist fact could provide the information you want.
   2. Facts are evaluated before catalog compilation, therefore even the 
   master's $::nodelist fact would be perpetually one cycle behind.
   
 


 So, sorry, but I have three questions:

 1. why isn't that curl getting the facts? Why is it getting this NoMethod 
 error?



Beats me.  It might help for you to explain more fully how you are using 
it, and to present the curl output actually generated.

 

 2. why isn't that new nodelist fact working? If a fact has an error where 
 does this get logged?



See my discussion above for possibilities.  Any log output would show up in 
the agent's log destination, which by default is the regular system log.  
On the agent.

 

 3. Is there an easier way to

[Puppet Users] Re: Offering Puppet As A Service

2013-09-11 Thread Jeffrey Miller

Thanks for raising the question! One of the primary points I explored at 
this year's PuppetConf was to see what others were doing in this area and 
figure out what is possible with the puppet in its current state. Your 
mileage may vary on this... and keep in mind we are in the exploration 
stages of how to do this and that I work in a university environment...

We setup separate environments for groups based on administrative domain 
boundaries (i.e. common sets of admins). Access to the environments is done 
at the code repository level and then the repositories are pulled into the 
puppet masters. This prevents modules/manifests from spilling over and 
affecting servers that a particular set of admins don't (and shouldn't) 
manage. We are currently moving to three layers modules for puppet masters 
to parse: a common set of modules, an org set of modules, and then the 
environment set of modules. The common set of modules primarily comes from 
the puppet forge. The second layer of org modules are placed where we 
have overlaps of admins and/or services across multiple environments but 
where those methods/modules are not (or should not) be available for all 
environments site wide... (think University - College - Department... 
disparate system monitoring tool preferences for groups... etc.). The last 
layer of modules would be the modules found in the environment itself.

Currently, I am working on how to provide access to PuppetDB and a 
reporting dashboard that respects the administrative boundaries. PuppetDB 
does not support environments (yet... there is an open feature request for 
that) so separate PuppetDBs need to be setup along some administrative 
boundary partition scheme... it looks like the ORG layer will suffice for 
that and those ENVs that aren't in an ORG would get a separate PuppetDB if 
needed. One of the major problems that I see with this are how you do a 
site wide look at the PuppetDB information for those operations that need 
it as well as mimicking federated queries using multiple PuppetDB backends. 
But, if it works, then the ORGs or groups can have their separate instances 
of puppet-dashboard or whatever web front end they want to use, and we 
won't have to worry about some complex convoluted way of putting access 
control in there... standard web access methods will work. PuppetDB will be 
key though in order to be able to automate this beast as much as possible 
as things progress.


Other things on the to explore/figure out list for me are:
 - ENC? do groups of admins actually want this? provide via 
puppet-dashboard? theforeman? someotherwhizbangmethod?
 - dynamic branching git repositories being served side by side with more 
traditional static environment repositories
 - hiera availability for use in environments
 - automated horizontal scaling of puppet masters to handle additional 
loads as more systems are added in (hiera again likely key)
 - figure out how mcollective and subcollectives can fit into the mix... if 
at all...
 - using CI (Jenkins likely) to provide a more robust capability of 
checking manifests/modules before they get pushed out to puppet masters
 - ??
 - profit!

There is a lot more in the ??... but this seems like a long enough response 
for now. :)   It seems that setting up Puppet-as-a-Service is doable so 
that all the various administrative groups (and the auditors) will be 
happy. 

-Jeffrey





On Wednesday, September 11, 2013 7:27:25 AM UTC-5, Josh wrote:

 We have several internal customers that we would like to start offering 
 Puppet as a Service to.  Our central group would manage Puppet masters, 
 ENC, etc.  But, we want other independent groups to be able to use our 
 Puppet services.

 Is anyone currently doing this?  If so, how are you handling segregation 
 of manifests?  Are you creating multiple environments for each internal 
 customers (perhaps with one common environment shared amongst all for base 
 configuration).

 Any suggestions would be greatly appreciated.

 Thanks,

 Josh


-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Re: Offering Puppet As A Service

2013-09-11 Thread Josh Baird

Thanks for the detailed reply.  I envision a setup similar to yours.

We will be using Foreman for ENC, reporting, etc.  The Foreman can already
handle segregation of organizations/units/locations with ACLs very nicely
so it should be a good fit for this type of scenario. In addition, we can
easily allow customer's to provision their own servers/VM's etc.

I haven't even began to think about the PuppetDB stuff, but I do envision
separate prod/dev/qa environments for each administrative team or
customer in our organization.  I'm not sure we would need separate
instances of PuppetDB.  Perhaps we will have a common/org layer as well
which will pull in modules that are common to each and every customer in
our environment.

Josh


On Wed, Sep 11, 2013 at 10:57 AM, Jeffrey Miller millerjl1...@gmail.comwrote:

 Thanks for raising the question! One of the primary points I explored at
 this year's PuppetConf was to see what others were doing in this area and
 figure out what is possible with the puppet in its current state. Your
 mileage may vary on this... and keep in mind we are in the exploration
 stages of how to do this and that I work in a university environment...

 We setup separate environments for groups based on administrative domain
 boundaries (i.e. common sets of admins). Access to the environments is done
 at the code repository level and then the repositories are pulled into the
 puppet masters. This prevents modules/manifests from spilling over and
 affecting servers that a particular set of admins don't (and shouldn't)
 manage. We are currently moving to three layers modules for puppet masters
 to parse: a common set of modules, an org set of modules, and then the
 environment set of modules. The common set of modules primarily comes from
 the puppet forge. The second layer of org modules are placed where we
 have overlaps of admins and/or services across multiple environments but
 where those methods/modules are not (or should not) be available for all
 environments site wide... (think University - College - Department...
 disparate system monitoring tool preferences for groups... etc.). The last
 layer of modules would be the modules found in the environment itself.

 Currently, I am working on how to provide access to PuppetDB and a
 reporting dashboard that respects the administrative boundaries. PuppetDB
 does not support environments (yet... there is an open feature request for
 that) so separate PuppetDBs need to be setup along some administrative
 boundary partition scheme... it looks like the ORG layer will suffice for
 that and those ENVs that aren't in an ORG would get a separate PuppetDB if
 needed. One of the major problems that I see with this are how you do a
 site wide look at the PuppetDB information for those operations that need
 it as well as mimicking federated queries using multiple PuppetDB backends.
 But, if it works, then the ORGs or groups can have their separate instances
 of puppet-dashboard or whatever web front end they want to use, and we
 won't have to worry about some complex convoluted way of putting access
 control in there... standard web access methods will work. PuppetDB will be
 key though in order to be able to automate this beast as much as possible
 as things progress.


 Other things on the to explore/figure out list for me are:
  - ENC? do groups of admins actually want this? provide via
 puppet-dashboard? theforeman? someotherwhizbangmethod?
  - dynamic branching git repositories being served side by side with more
 traditional static environment repositories
  - hiera availability for use in environments
  - automated horizontal scaling of puppet masters to handle additional
 loads as more systems are added in (hiera again likely key)
  - figure out how mcollective and subcollectives can fit into the mix...
 if at all...
  - using CI (Jenkins likely) to provide a more robust capability of
 checking manifests/modules before they get pushed out to puppet masters
  - ??
  - profit!

 There is a lot more in the ??... but this seems like a long enough
 response for now. :)   It seems that setting up Puppet-as-a-Service is
 doable so that all the various administrative groups (and the auditors)
 will be happy.

 -Jeffrey





 On Wednesday, September 11, 2013 7:27:25 AM UTC-5, Josh wrote:

 We have several internal customers that we would like to start offering
 Puppet as a Service to.  Our central group would manage Puppet masters,
 ENC, etc.  But, we want other independent groups to be able to use our
 Puppet services.

 Is anyone currently doing this?  If so, how are you handling segregation
 of manifests?  Are you creating multiple environments for each internal
 customers (perhaps with one common environment shared amongst all for base
 configuration).

 Any suggestions would be greatly appreciated.

 Thanks,

 Josh

  --
 You received this message because you are subscribed to a topic in the
 Google Groups Puppet Users group.
 To unsubscribe from this

Re: [Puppet Users] Re: getting array of hostnames of clients

http://docs.puppetlabs.com/references/latest/configuration.html#reportdir gives 
a list of certnames. 

I use FQDN for my certname, so ... 


“Sometimes I think the surest sign that intelligent life exists elsewhere in 
the universe is that none of it has tried to contact us.” 
Bill Waterson (Calvin  Hobbes) 

- Original Message -
From: jcbollinger john.bollin...@stjude.org 
To: puppet-users@googlegroups.com 
Sent: Wednesday, September 11, 2013 10:50:59 AM 
Subject: [Puppet Users] Re: getting array of hostnames of clients 




On Wednesday, September 11, 2013 2:49:50 AM UTC-5, Steve Wray wrote: 


I need to get an array of hostnames of clients of the puppet server. 


There doesn't seem to be a simple way to do this so I've tried a few methods. 


I've tried a curl expression in a fact like this: 



curl -s -k -H Accept: yaml 
https://localhost:8140/production/facts_search/search?facts.nodetypet=testnodes 






In other words, this is intended to retrieve the desired information via the 
master's REST API. I'm not quite making the connection here, however: how is 
putting that expression into a fact supposed to achieve your result? 

Do you mean you have a custom fact that executes that command and parses the 
YAML result to produce the desired array? That seems odd, because in that case 
'localhost' probably would not resolve to the correct machine (it would be the 
client, not the master), and because the result is not a property of the node. 

Or do you mean that you pass the command itself as a literal fact value, which 
the master executes locally to extract the result? Again in that case the value 
is not a property of the node, so it doesn't appear to make much sense to use a 
fact. Also, it would be a serious security risk for the master to execute 
commands provided by clients. 


blockquote



where I've got a nodetype fact which works fine for me. 


Now, this used to work but doesn't any more. Between it working and now I've 
changed to using puppetdb. I'm not sure if theres a connection. 


The error returned is: 


Caught NoMethodError: undefined method `' for nil:NilClass 

/blockquote



There could be a connection. I have lately seen some evidence that puppetdb may 
not reliably escape fact values when it stores them. That would be a serious 
flaw, but I cannot confirm its existence. 

Alternatively, if you have also updated your master, then it may be that the 
data returned by the REST call has changed in form or content. Do you get what 
you expect if you run it from the command line? 


blockquote





The next thing I tried was to get each interesting node to create a file on the 
puppetmaster server. So I now have a bunch of files in /tmp/ with distinctive 
names which contain only the hostname of that puppet client. 
/blockquote



Yuck. 


blockquote




I have a fact which is supposed to cat these together and, with luck, turn them 
into an array at some time. What I currently have is this: 



/blockquote



Facts are properties of target nodes, and their values are evaluated there. 
Dropping a bunch of files on the master could allow the Puppet agent to collect 
data from them into a fact when it runs on the Puppet master server, but it 
cannot do anything for agents running on other nodes. Do you need the 
information on nodes other than the master? 


blockquote




require 'facter' 

Facter.add(nodelist) do 
setcode do 
path=/tmp 
if File.exists?(path)  File.directory?(path)  ! Dir[path + '/*'].empty? 
output = Facter::Util::Resolution.exec(/bin/cat 
/tmp/testnode*).split('\n').join(',') 
else 
output = empty 
end 
output 
end 
end 


but this isn't getting anything in the fact at all, not even empty. Running 
that cat command on the commandline returns exactly what I would expect. 
/blockquote



If you're not getting the fact at all, even after you restart the agent (though 
that should not be necessary), then I conclude that the fact has not been 
synced to the client. 


blockquote




If I run facter on the commandline like this: 
FACTERLIB=/etc/puppet/modules/smokeping_prep/lib/facts facter nodelist 



I get the list I expect. 
/blockquote



On which command line? You could have the fact installed on the master, but not 
synced to clients. 


blockquote




On each node I have this: 

@@file { testnode-{$::fqdn}: 
ensure = file, 
path = /tmp/testnode-$::fqdn.txt, 
mode = 640, owner = root, 
tag = 'testnodes', 
content = $::hostname 
, 
} 


On the puppetmaster node definition I have this: 

File | tag == testnodes | 



file { 'nodelist': 
path = '/tmp/nodelist', 
content =  
$::nodelist 
 
} 
} 


and I was expecting a file /tmp/nodelist to contain the text from the fact 
$::nodelist but the file is empty. 


/blockquote



1. You are collecting the Files only on the master, therefore only the 
master's $::nodelist fact could provide the information you want. 
2. Facts are evaluated before catalog compilation, therefore even the 
master's

[Puppet Users] Using Puppet for remote config management of offline machines?

2013-09-11 Thread Brad Smith

Hello all,

I'm working with a Kenya-based non-profit (tunapanda.org) that uses OSS to 
provide computing resources to schools where bandwidth is either 
nonexistent or prohibitively expensive. We provide a customized 
Edubuntu/LTSP setup which will host local versions of useful online 
resources like Kahn Academy (via ka-lite), Wikipedia (via Wikipedia For 
Schools), etc. 

I'm serving as a sort of Linux/tech advisor to them, and am looking into 
ways to provide updates to configuration files on classroom servers that...

   - Are not physically accessible to me
   - Are not online (local reps can download updates to a USB drive and 
   bring it to the server)
   - Do not have much in the way of local technical expertise, so 
   deployment will need to be fairly straightforward/scriptable

I don't have much experience with tools like Puppet, Chef, etc, but after 
reading through some of the docs, it sounds like Puppet might be able to do 
exactly what I want. Before I put too much effort into it, I hope I can run 
my ideas by y'all for a sanity check and ask some questions: 

   1. If I maintained a master image configured via a set of Puppet 
   manifests, could I just periodically put those manifests online, have 
   someone in Kenya download them to a USB drive, copy them to the server, and 
   run puppy apply... on them? 
   2. If they first backed up the server's previous set of manifests, would 
   they be able to roll back changes in case of a problem?
   3. Is there a better approach? Any other suggestions for things 
   (including tools other than Puppet) to look at?

Thanks in advance to anyone who can help!

--Brad 

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Is it possible to install actual OS using puppet?

2013-09-11 Thread Rastio Hodul

Hi,
ideally I would like to crate bootable USB stick with, say, Ubuntu + Puppet 
on it. I would then use this USB stick on a blank computer to boot to it 
and install new OS (Ubuntu+WhateverIWant) on that blank computer. I know I 
can do WhateverIWant part, but can I install actual OS?

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] puppetdb query not working as expected

2013-09-11 Thread hai wu

Hi Ken,

Yes, using postgresql here. It turns out I have another script pushing
facts (without custom facts) into puppetdb, which messed up with puppetdb
query outputs. After fixing that script, things are ok now here.

Thanks,


On Wed, Sep 11, 2013 at 5:29 AM, Ken Barber k...@puppetlabs.com wrote:

  Running puppet only at around 4am once a day here. And I noticed that
  puppetdb query not working as expected, if using it to query nodes based
 on
  some custom fact value.
 
  During the days, things are working fine. But if I ran the same query at
  around say 3am (searching nodes based on some custom fact's value), then
 it
  would not be able to return node information. But if I ran puppet on that
  node at that time, then I could see the node showing up in the query
 output
  right away. And if I ran puppetdb query based on custom fact after 5am,
 then
  it is working as expected.

 Is there any errors associated with this failure, if so can you supply
 it? In particular - do you get anything of interest in your
 puppetdb.log? This could be a performance tuning issue, if so we
 usually log queries over 10 seconds to puppetdb.log for example.

 Are you using PostgreSQL?

 ken.

 --
 You received this message because you are subscribed to the Google Groups
 Puppet Users group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to puppet-users+unsubscr...@googlegroups.com.
 To post to this group, send email to puppet-users@googlegroups.com.
 Visit this group at http://groups.google.com/group/puppet-users.
 For more options, visit https://groups.google.com/groups/opt_out.


-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Looking for tips for transitioning to Puppet Enterprise

2013-09-11 Thread Rich Burroughs

Dan,

You can do those things from the PE console but you don't have to. You can
assign classes to nodes the old school way too. It's really up to you
whether you prefer to do those kinds of things through the UI or in your
Puppet code.



On Wednesday, September 11, 2013, Dan White wrote:

 I have bee using Open Source Puppet for about two years now -- and I have
 enjoyed the ride so far.

 I want to spin up a demo PE-Master because we are also spinning up a big
 VMWare driven virtualization push and I want to try the Cloud Provisioning.
  If it works for me as well as everything else has to date, I will have no
 trouble making the pitch to The Customer to go for PE licensing.

 The difficulty I am having is transitioning from nodes defined under
 /etc/puppet/manifests/nodes to nodes defined in the PE console.

 I think I have to somehow add all my modules into the console and then I
 can assign them to nodes.

 Is that in the right direction ?

 “Sometimes I think the surest sign that intelligent life exists elsewhere
 in the universe is that none of it has tried to contact us.”
 Bill Waterson (Calvin  Hobbes)

 --
 You received this message because you are subscribed to the Google Groups
 Puppet Users group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to puppet-users+unsubscr...@googlegroups.com javascript:;.
 To post to this group, send email to 
 puppet-users@googlegroups.comjavascript:;
 .
 Visit this group at http://groups.google.com/group/puppet-users.
 For more options, visit https://groups.google.com/groups/opt_out.


-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Looking for tips for transitioning to Puppet Enterprise

I have bee using Open Source Puppet for about two years now -- and I have 
enjoyed the ride so far.

I want to spin up a demo PE-Master because we are also spinning up a big VMWare 
driven virtualization push and I want to try the Cloud Provisioning.  If it 
works for me as well as everything else has to date, I will have no trouble 
making the pitch to The Customer to go for PE licensing.

The difficulty I am having is transitioning from nodes defined under 
/etc/puppet/manifests/nodes to nodes defined in the PE console.

I think I have to somehow add all my modules into the console and then I can 
assign them to nodes.

Is that in the right direction ?

“Sometimes I think the surest sign that intelligent life exists elsewhere in 
the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin  Hobbes)

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Nagios Puppet Module - Multiple Service File Permissions Issues

2013-09-11 Thread phundisk

I am using the nagios puppet module to create and manage services via 
stored configurations.  The original module, stored all service cheks in 
one file and this was causing my puppet run on my nagios server to take 30+ 
minutes.  I have read here (
http://pieter.barrezeele.be/2009/05/11/puppet-and-nagios/) that if you 
split up the services files into multiple, puppet can run faster since it 
doesn't have to look through one huge file.  I would like to split this up 
by host.  (i.e. nagios_service_$::fqdn.cfg)  One issue I am running into, 
is that the file that is created  using the target method has the 
permissions of root:root 600, and thus nagios will crash when trying to 
read it since it does not have permissions.  The original nagios_service 
file is controlled via the following...  

I could add each hostname below, but that does not scale well.  Is there 
another way in which this can be more easily managed?

 file{[ ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_command.cfg,
  
 ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_contact.cfg,
  
 ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_contactgroup.cfg,
   ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_host.cfg,
  
 ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_hostdependency.cfg,
  
 ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_hostescalation.cfg,
  
 ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_hostextinfo.cfg,
  
 ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_hostgroup.cfg,
  
 ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_hostgroupescalation.cfg,
  
 ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_service.cfg,
  
 ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_servicedependency.cfg,
  
 ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_serviceescalation.cfg,
  
 ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_serviceextinfo.cfg,
  
 ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_servicegroup.cfg,
  
 ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_timeperiod.cfg ]:
ensure = file,
replace = false,
notify = Service['nagios'],
mode = 0644, owner = root, group = 0;
}



-- 
_
This email and any files transmitted with it are confidential and intended 
solely for the addressee.  If you received this email in error, please do 
not disclose the contents to anyone; kindly notify the sender by return 
email and delete this email and any attachments from your system.

© 2011 Currensee Inc. is a member of the National Futures Association (NFA) 
Member ID 0403251 | Over the counter retail foreign currency (Forex) 
trading may involve significant risk of loss. It is not suitable for all 
investors and you should make sure you understand the risks involved before 
trading and seek independent advice if necessary. Performance, strategies 
and charts shown are not necessarily predictive of any particular result 
and past performance is no indication of future results. Investor returns 
may vary from Trade Leader returns based on slippage, fees, broker spreads, 
volatility or other market conditions.

Currensee Inc | 54 Canal St 4th Floor | Boston, MA 02114 | +1.617.624.3824

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Purge puppet's reports

OK, but the reports live on the puppetmaster.  How do you get a list of 
hostnames to apply to this resource definition ?

On Sep 10, 2013, at 10:12 PM, Andrew wrote:

 Using tidy to clean up logs, this is pretty self-explanatory, so I wont 
 bother explaining :)
 
 case $hostname {
 /^puppet$/: {
 tidy { 'puppet::reports':
  path = '/var/lib/puppet/reports',
  matches = '*',
  age = '14d',
  backup = false,
  recurse = true,
  rmdirs = true,
  type = 'ctime',
  }
  # notify { debug: tidy command should run now: }
 }
 }
 
 
 
 Ciao,
 Andrew.
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Puppet Users group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to puppet-users+unsubscr...@googlegroups.com.
 To post to this group, send email to puppet-users@googlegroups.com.
 Visit this group at http://groups.google.com/group/puppet-users.
 For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] default data lookup w/ hiera2? Data in Modules

2013-09-11 Thread Henrik Lindberg


Thank you for the feedback, very good comments.

See more inline...

On 2013-11-09 11:02, robbyt wrote:

I am reading over the release notes for Puppet 3.3, and buried under
data in modules is a link to ARM-9.
There is a good chance that I don't get it - Puppet is moving pretty
fast these days and I am still trying to get caught up with all of the
changes.

I have only read the latest Puppet code and the ARM docs- I have not
tried it on a real system yet. However, I am concerned about the
usefullness of the default lookup syntax. I find the examples in the ARM
document a bit obtuse.
https://github.com/puppetlabs/armatures/blob/master/arm-9.data_in_modules/index.md#lookup-with-default

With hiera1, we can (very simply) do:
   hiera(namespace::key_name, default value )

Hiera2 requires some more work:
$x = lookup('something')
  $looked_up = $x ? { undef = 'nothing', default = $x }

This is ugly. Checking if variables are undefined, and then setting them
to a default is what we did in bash. Not good.



The challenge here was to have a function that works for 3x as well as 
for what is being worked on for 4x (where the data-in-modules 
supposedly is on by default along parser future). When we reach that 
point, it is possible to reference a type directly without having to 
encode it in a string. i.e. it will be possible to do like this:


lookup('mykey', Integer)

For 3.x this was not possible and the signature of the lookup function 
is now lookup(String key, String type), or just lookup(String key), and 
thus difficult to handle both type and default value as optional (given 
two strings, it that key and type or key and default).


We have a couple of options before 4x:
a) Add a third argument, and if a default is wanted, type must be specified.

b) Add the ability to pass arguments as a hash, it can either be a third 
argument, or used instead of the type argument. (i.e. giving arguments 
by name instead).


The first is simple to add, the second does not work well unless the 
future parser is also used.


Examples:
   # a
   lookup('mykey', 'Integer', 42)

   # b (requires future parser since 3x does not support direct passing
   # of a hash
   lookup('mykey', 'Integer', { default = 42})
   lookup('mykey', { type = 'Integer', default = 42})

   # In 4x. this will is possible:
   lookup('mykey', 'Integer', 42)
   lookup('mykey', Integer, 42)
   lookup('mykey', 42)
   lookup('mykey', Integer)

If future parser is used, it is also possible to use a lambda, there is 
no need to first assign variable and then check - i.e.


$x = lookup('something') {|$x| $x ? {
  undef = 'nothing', default = $x }

which is just slightly better, but still bulky.

I am in favor of adding the 3d argument for default, and until 4x the 
lookup must then also use type.


What do you think about that?



On the positive side, the lookup function adds a static type checker,
but it also fails to be completely useful because we cannot (?) define
our own static types or validators. If we had the ability to define our
own type check via lambda or other function, this would be useful. We
could do complex validation on data, more than just 'string' or 'array'.

I would like to see something like:
lookup(namespace::key_name, custom_validator_function)

Where the custom_validator_function could be any puppet parser function
OR since we now worship the**great *λ, *we should be able to use an
anonymous function in-place to validate the input (and in this
fictitious example, set a default value):
lookup(namespace::key_name, |$val| {$val or default value} )



There is a short and a long answer.

Short answer, the lookup already takes a lambda which can do validation 
and handle default value. This works now with --parser future.


Longer answer. The idea is to support specification of types in the 
Puppet Language. Your example would be


lookup('namespace::key', SomeNamespace::SomeType)

Puppet Types is described in ARM-7 
(https://github.com/puppetlabs/armatures/blob/master/arm-7.puppet_types/puppet_types.md).


ARM-7 may need a revision since the work on Type in ARM-9 took the type 
system a bit further.




To sum it up, as someone who writes a lot of Puppet DSL code, I find the
hiera1 syntax much more useful than the lookup syntax in ARM-9.



Does adding a 3d argument to lookup for default cut it for you?

Regards
- henrik


--
You received this message because you are subscribed to the Google Groups Puppet 
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Custom Fact undefined in manifests

2013-09-11 Thread Denmat

Hi,

Do you have stdlib module installed?

http://puppetlabs.com/blog/module-of-the-week-puppetlabsstdlib-puppetlabs-standard-library-part-3

On 12/09/2013, at 1:12, David Thompson dthomp...@waisman.wisc.edu wrote:

On 9/11/13 8:54 AM, jcbollinger wrote:

Lack of response? This is a volunteer community forum, not a paid
technical support service. Give it some time.

No offense intended. I'm continually impressed by the effort made by the
volunteers who watch this lists and provide so much help.

Before you open a bug report, you should make sure that the file
containing your custom fact(s) is readable by the Puppet agent service.
That facter can read the file when you run it from the command line does
not prove that. Even though the agent runs as a privileged user (or
should), access could still be blocked in various ways, such as

1. Mandatory access controls (a.k.a. SELinux in enforcing mode) could
allow you to read the file, but prevent the agent service from doing so.
2. If /etc/facter/facts.d is on an NFS-mounted filesystem that performs
root-squashing, then the agent may have less permissions on it than
you, personally, do.

There are probably other means.

Also, make sure Puppet is using the same Facter that you are using from
the command line. If you have multiple versions installed then all
manner of havoc might ensue. You might get multiple versions by
installing them from gem or from source into different Ruby libraries,
or into different parts of the same Ruby lib.

All good ideas. An strace of puppet agent --test (and/or the test
manifest above) shows that puppet is able to read the fact file (and, yes,
it's on the local disk), and the the version of facter being loaded is the
correct (and only) one (in my case, the RPM version 1.7.2, from
/usr/lib/ruby/site_ruby/1.8/facter.rb and friends), and still show the custom
facts as undef.

Even if I reduce my custom facts to a single file containing a single trivial
line (somefact=somevalue), the custom fact shows up in facter but not in
puppet.

I also get the same result when I pass the fact as yaml. I tried json, but
got an error about missing the json gem, even though I have the puppetlabsdep
rubygem-json RPM installed.

--
David Thompson
Waisman Center Brain Imaging and Behavior Lab
1500 Highland Ave. Room T133
Madison, WI 53705-2280
(608) 265-6608
dthompson (at) waisman (dot) wisc (dot) edu

--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an
email to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Looking for tips for transitioning to Puppet Enterprise