Re: [Puppet Users] RFC: Deprecate defined() function for Telly.

2012-01-19 Thread R.I.Pienaar


- Original Message -
> I'm looking for strong opinions on whether we should or shouldn't
> deprecate the defined() function for Telly, the next major Puppet
> release this year.

First choice would be to make it reliable, that seems unlikely though

+1, I'd also make the scope.classes variable private somehow for similar
reasons.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: RFC: Deprecate defined() function for Telly.

2012-01-19 Thread R.I.Pienaar


- Original Message -
> Defined() doesn't suck! It's a 100% reliable way to check what
> classes and defined types are available to the autoloader. I challenge anyone
> to find me an example of this usage that fails.

can you give an example of this use case pls?

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: RFC: Deprecate defined() function for Telly.

2012-01-19 Thread R.I.Pienaar


- Original Message -
> 
> 
> On Jan 19, 11:01 am, "R.I.Pienaar"  wrote:
> > - Original Message -
> > > Defined() doesn't suck! It's a 100% reliable way to check what
> > > classes and defined types are available to the autoloader. I
> > > challenge anyone
> > > to find me an example of this usage that fails.
> >
> > can you give an example of this use case pls?
> 
> Well... that's something I realized after I posted that, is I'm not
> sure if anyone WANTS a reliable way to test the autoloader.
> (Obviously
> people do want a way to check for resource instances, which is why
> defined() keeps getting used for that...)
> 
> But anyway! Say you make a module for a network service and you want
> it to be able to manage its own firewall rule. You know of a defined
> type for firewall rules, and you're using it, but you want your
> module
> to be portable and you know of good reasons why someone wouldn't be
> using your iptables module.
> 
> So, you can conditionally declare the rule if the defined type is
> available to the autoloader, and otherwise you don't attempt to
> manage
> the firewall and expect that the user has read the documentation and
> will make a hole for the service themselves.
> 
> if defined(firewall::iptables::rule) {
>   firewall::iptables::rule {'mysql_server':
> ...etc. etc.
>   }
> }
> 
> See? It's just a way to peek around at what the user has installed.

right, I must have missed this behavior previously, yeah this has value
and should be retained, checking for declared resources should go then

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Another Discovered/Undocumented feature of yumrepo - and a workaround

2012-01-23 Thread R.I.Pienaar


- Original Message -
> Hey there,
> 
> If you're going through all that, and are trying to get a purge-able
> directory of resources, would you find it easier to declare the
> /etc/yum.repos.d directory with purge => true, and then declare your
> repos as file declarations? An exec of 'yum -makecache' set to
> refreshonly => true could be notified by each file resource.
> 
> Does that help get what you need?

I've tried something along these lines and at least on 2.6.x if you just
remove repo files mid run the yum provider gets quite unhappy, logs about
missing files etc.

having this provider support an ensure => absent option rather than just
something that sets enable=0 in the repo would be really nice

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Anyone seeing odd agent behaviour with 2.7.10?

2012-01-26 Thread R.I.Pienaar
Looks like the code paths in Puppet::Agent changed a lot and the patch
that was applied and worked for 2.6.x would need to be different for 2.7.x

Will set up a 2.7 master and see if i can reproduce/fix

- Original Message -
> Yeah everything does work, I just really don't like seeing pink :)
> 
> Cheers,
> 
> Steph
> 
> On Thu, 26 Jan 2012 12:26:14 +
> Jonathan Gazeley  wrote:
> 
> > I am seeing the same message printed on each run, on CentOS 6.2.
> > Puppet
> > still works, so it's not critical. Just waiting for a fix :)
> > 
> > Jonathan
> > 
> > 
> > On 26/01/12 12:00, Steph Gosling wrote:
> > > Hi all,
> > >
> > > Upgraded a master and a couple of clients to 2.7.10 and now see
> > > the
> > > following when running an agent if the daemon is also running:
> > >
> > > [steph@somehost ~]$ sudo puppet agent --onetime --verbose
> > > --no-daemonize
> > > info: Caching catalog for somehost.example.com
> > > info: Applying configuration version '1327578407'
> > > notice: /Stage[main]/Mysql-server/Package[mysql-server]/ensure:
> > > created
> > > notice: /Stage[main]/Mysql-server/Service[mysqld]/ensure: ensure
> > > changed 'stopped' to 'running'
> > > notice: Finished catalog run in 20.11 seconds
> > > err: Could not remove PID file /var/run/puppet/agent.pid
> > > [steph@somehost ~]$
> > >
> > > I see that 2.7.10 fixed a bug
> > > http://projects.puppetlabs.com/issues/5246 and wonder if they're
> > > related?
> > >
> > > in 2.7.9 this would run without throwing the error, indeed in .10
> > > the
> > > onetime run completes and the agent daemon is happy too: It's
> > > just
> > > unnerving to see pink messages :) Environment is CentOS
> > > 6.2 fwiw.
> > >
> > >
> > >
> > 
> > --
> > 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+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/puppet-users?hl=en.
> > 
> 
> 
> --
> Steph Gosling 
> 
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
> 
> 

-- 
R.I.Pienaar

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Anyone seeing odd agent behaviour with 2.7.10?

2012-01-26 Thread R.I.Pienaar
On a fresh 2.7.10 install with official RPMs on CentOS 6.2 I can't reproduce 
this:

[root@dev1]# puppet agent --onetime --verbose --no-daemonize
info: Caching catalog for dev1.devco.net
info: Applying configuration version '1327583153'
notice: Finished catalog run in 0.28 seconds
[root@dev1]#

and if i run it without the --no-daemonize it creates its pid and removes
it when its done - didnt do that before



- Original Message -
> Looks like the code paths in Puppet::Agent changed a lot and the
> patch
> that was applied and worked for 2.6.x would need to be different for
> 2.7.x
> 
> Will set up a 2.7 master and see if i can reproduce/fix
> 
> - Original Message -
> > Yeah everything does work, I just really don't like seeing pink :)
> > 
> > Cheers,
> > 
> > Steph
> > 
> > On Thu, 26 Jan 2012 12:26:14 +
> > Jonathan Gazeley  wrote:
> > 
> > > I am seeing the same message printed on each run, on CentOS 6.2.
> > > Puppet
> > > still works, so it's not critical. Just waiting for a fix :)
> > > 
> > > Jonathan
> > > 
> > > 
> > > On 26/01/12 12:00, Steph Gosling wrote:
> > > > Hi all,
> > > >
> > > > Upgraded a master and a couple of clients to 2.7.10 and now see
> > > > the
> > > > following when running an agent if the daemon is also running:
> > > >
> > > > [steph@somehost ~]$ sudo puppet agent --onetime --verbose
> > > > --no-daemonize
> > > > info: Caching catalog for somehost.example.com
> > > > info: Applying configuration version '1327578407'
> > > > notice: /Stage[main]/Mysql-server/Package[mysql-server]/ensure:
> > > > created
> > > > notice: /Stage[main]/Mysql-server/Service[mysqld]/ensure:
> > > > ensure
> > > > changed 'stopped' to 'running'
> > > > notice: Finished catalog run in 20.11 seconds
> > > > err: Could not remove PID file /var/run/puppet/agent.pid
> > > > [steph@somehost ~]$
> > > >
> > > > I see that 2.7.10 fixed a bug
> > > > http://projects.puppetlabs.com/issues/5246 and wonder if
> > > > they're
> > > > related?
> > > >
> > > > in 2.7.9 this would run without throwing the error, indeed in
> > > > .10
> > > > the
> > > > onetime run completes and the agent daemon is happy too: It's
> > > > just
> > > > unnerving to see pink messages :) Environment is CentOS
> > > > 6.2 fwiw.
> > > >
> > > >
> > > >
> > > 
> > > --
> > > 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+unsubscr...@googlegroups.com.
> > > For more options, visit this group at
> > > http://groups.google.com/group/puppet-users?hl=en.
> > > 
> > 
> > 
> > --
> > Steph Gosling 
> > 
> > --
> > 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+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/puppet-users?hl=en.
> > 
> > 
> 
> --
> R.I.Pienaar
> 
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
> 
> 

-- 
R.I.Pienaar

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Anyone seeing odd agent behaviour with 2.7.10?

2012-01-26 Thread R.I.Pienaar


- Original Message -
> Is the puppet agent daemon running when you run the agent by hand?


Ah! thats it, I'll take a look

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Anyone seeing odd agent behaviour with 2.7.10?

2012-01-26 Thread R.I.Pienaar


- Original Message -
> I'm having the same thing, I use puppetd -tv all the time and now
> it's
> trying to delete a .pid at the end:
> 
> 
> err: Could not remove PID file /var/run/puppet/agent.pid
> 
> 
> It's super annoying but not fatal I suppose. I stopped the daemon
> from running and tried running puppetd again but it still gave the same
> error.

that's weird, did the daemon leave behind a pid file or somethign? my testing
werent showing this error when the daemon wasnt running.

anyway, opened https://projects.puppetlabs.com/issues/12188

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Puppet agents stop reporting after master runs out of disk space...

2012-01-30 Thread R.I.Pienaar


- Original Message -
> Thanks guys.. I'll check out mcollective.  Yeah, the root password 60
> times is a bit painful, but the ssh loop would help.  If I remember
> right, there is an API/REST call for Foreman that will give me a list
> of the hosts not responsive.
> 
> The problem here is that puppet was in memory, and running.  It just
> wasn't responsive, perhaps waiting for something to happen that never
> did.  So, checks for the process (monit/snmp/pgrep), etc would say
> that puppet is fine.
> 
> Are there any more bullet-proof ways of watch-dogging Puppet
> specifically?  Could we kill the process if catalog locks are more
> than 30 minutes old? Or are locks on the catalog even a reality? Is this
> something Puppet could do on its own, in a separate thread, or does
> it need a new process?  I'm just throwing an idea or two.

Times I've seen this happen is when the network connection to the master dies
at just the right (wrong) time so the Ruby VM gets stuck on blocking IO which
it can never recover from.  So a supervisor thread wont do - it would also be
blocked.

I've written a monitor script for puppet that uses the new last_run_summary.yaml
file to figure out if puppet has recently run and I monitor that with nagios
and nrpe.  So at least I know when this happens

https://github.com/ripienaar/monitoring-scripts/blob/master/puppet/check_puppet.rb

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] MCollective Cost?

2012-02-01 Thread R.I.Pienaar


- Original Message -
> Someone told me yesterday that collective wasn't free, New to me. Has
> something changed in the past month, or are they looking at the
> commercial version? The web site must be somewhat confusing if a new
> user thinks it costs, but it doesn't.
> 

mcollective is Apache 2 licence, Puppet Enterprise has a commercial 
web dashboard that is not.  

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] What is the fully-qualified variable name format for external and factors variable in template erb file?

2012-02-06 Thread R.I.Pienaar


- Original Message -
> There's a couple of ways to do this, but I usually take the easy
> route: assign a local variable that has the global's value in the
> related manifest.  In this case, in centrifydc's init.pp just set
> $domain=$::domain.  This will appear as a local variable in the
> template and you don't have to change your ERB at all.

use @operatingsystem in a template as you would $::operatingsystem in a 
manifest.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] class inheritance question

2012-02-07 Thread R.I.Pienaar


- Original Message -
> From: "jimbob palmer" 
> To: puppet-users@googlegroups.com
> Sent: Tuesday, February 7, 2012 11:52:23 AM
> Subject: [Puppet Users] class inheritance question
> 
> If I have a class
> 
> class something {}
> 
> and a subclass
> 
> class something::blah ($var=0) inherits something {
> class { 'something::aaa': somevar => 1, }
> class { 'something::bbb': somevar => 2, }
> }
> 
> should the classes called from the subclass inherit the parent class?
> e.g. which is good practice?
> 
> class something::bbb($somevar) inherits something {}
> or:
> class something::bbb($somevar) {}
> 
> Also, what is the best way to set $somevar in something::bbb from a
> node definition?

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

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Puppet unless behaviour with a dependency

2012-02-17 Thread R.I.Pienaar


- Original Message -
> From: "jimbob palmer" 
> To: puppet-users@googlegroups.com
> Sent: Friday, February 17, 2012 3:12:46 PM
> Subject: [Puppet Users] Puppet unless behaviour with a dependency
> 
> Is this really expected behaviour? Should the second Exec succeed
> even if the first never runs?
> 
> exec { "one":
> command => "/bin/true",
> unless => '/bin/false'
> }
> exec { "two":
> command => "/bin/true",
> require => Exec["one"],
> }

I think this is https://projects.puppetlabs.com/issues/5876

i think this is a major failure of Puppet to honour what people expect
and what the language suggests in the choice of meta param names etc
but there's some debate in that ticket

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Mcollective for OpenSUSE

2012-03-14 Thread R.I.Pienaar


- Original Message -
> From: "Douglas Garstang" 
> To: "Puppet Users" 
> Sent: Wednesday, March 14, 2012 4:25:28 PM
> Subject: [Puppet Users] Mcollective for OpenSUSE
> 
> Sorry if there's an mcollective mailing list...
> 
> So, I'm working for a company that using OpenSUSE, which in my
> opinion is a very bad idea.
> 
> Anyway, how can I get collective for OpenSUSE that doesn't involve
> using tarballs? It's not in the standard OpenSUSE repo's. Does
> someone else have a repo? Are there spec files for building RPM's in the
> tarball?

easiest is probably to clone the repo, git checkout 1.2.1 to get to the
release tag and then just 'rake rpm' which will build you a rpm for your
environment assuming you have all the dependencies

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: mcollective bits

2012-03-20 Thread R.I.Pienaar


- Original Message -
> From: "Matt Warren" 
> To: "Puppet Users" 
> Sent: Tuesday, March 20, 2012 1:47:46 PM
> Subject: [Puppet Users] Re: mcollective bits
> 
> On Mar 19, 1:45 pm, Douglas Garstang  wrote:
> > I've always found the mcollective docs
> > athttp://docs.puppetlabs.com/mcollective/reference/basic/gettingstarted...
> > very confusing.
> >
> > What _exactly_ goes on the client (i.e. the remote system)? The
> > docs
> > talk about editing both the server.cfg and the client.cfg files.
> > The
> > server.cfg file is part of the collective package and the
> > client.cfg
> > file is part of the client.cfg package. However, I though the
> > client
> > package was installed on the single querying system? As you can
> > see,
> > it's all quite confusing and the documentation doesn't clearly
> > explain
> > it.
> >
> > Doug
> 
> I had the same issue trying to comprehend the notion of which was
> client and server.  After I bit of friendly explanation, it made more
> sense.
> 
> The explanation was as follows, MCollective's notion of server/client
> "is based on which is actually the TCP/IP server, e.g. the one that
> accepts the connection request."  Meaning, each of your puppet
> "clients" runs an MCollective "server" and your central MCollective
> "client", that is the one that runs mco, initiates a connection to
> each MCollective "server" for any command you may run.  So your
> server.cfg should go out to all servers and the client.cfg should
> only
> be on one (or a handful of) server(s).

See http://docs.puppetlabs.com/mcollective/reference/basic/messageflow.html
and the screencast it links to

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Arrays from templates

2012-03-27 Thread R.I.Pienaar


- Original Message -
> From: "pablo" 
> To: puppet-users@googlegroups.com
> Sent: Tuesday, March 27, 2012 3:55:05 PM
> Subject: [Puppet Users] Arrays from templates
> 
> Hi,
> 
> I am having an issue trying to use the inline_template function to
> return an array. This is what I do:
> 
> $array = inline_template ("<%= a=['a1','b2','c3']; a %>")
> notify {"array: ${array}":}

inline_template can only return strings, not arrays or hashes.

You'll need to write a parser function

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Hash iteration order in a template not consistent

2012-03-28 Thread R.I.Pienaar


- Original Message -
> From: "Martijn Grendelman" 



> http://serverfault.com/questions/368784/puppet-and-templates-how-to-loop-sequently-and-not-randomly
> 
> which suggests to do something like
> 
> <% aliases.sort_by {|key, value| key}.each_pair do |key, val| -%>
> <% end -%>
> 
> Will it work? Is that a proper solution?

ruby hashes are not stored in predictable order so this will happen, the 
proposed
solution should work.

But as always the best is just to test it and see how it goes, it wont bite :)

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



[Puppet Users] Re: [Puppet-dev] Taking github noise away from puppet-dev list

2012-04-12 Thread R.I.Pienaar


- Original Message -
> From: "Dean Wilson" 
> To: puppet-...@googlegroups.com
> Cc: puppet-users@googlegroups.com
> Sent: Thursday, April 12, 2012 10:55:45 AM
> Subject: Re: [Puppet-dev] Taking github noise away from puppet-dev list
> 
> On 12 April 2012 08:48, Brice Figureau
>  wrote:
> 
> > Nowadays, I don't even read patches because they're either one
> > click
> > away or difficult to read in the e-mail. Worst: most of the time I
> > open
> > the "close" pull request e-mail by mistake (thinking it is the open
> > one)
> > and struggle to find the real "open" one to read the patch. (I
> > believe
> > we don't need this "close" e-mail, it just adds unnecessary noise).
> > One reason the patches are difficult to read is that all
> > sub-patches are
> > merged in one big chunk, so you're losing the author intent.
> 
> > Maybe nobody feels like me or that's because there are much more
> > patches
> > than there was before, but the dev list was a good way to stay
> > tuned on
> > what happens in the Puppet code. I just feel it isn't now anymore.
> 
> While I still read most of the patches I have to agree with what
> Brice
> has eloquently said throughout his mail. I think it has become harder
> to casually keep up as an interested observer and requires a bigger
> time investment than it used to, and that's not just because of the
> increased development output.
> 

What they said.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: function template: use of variable '$string' = BUG?

2012-04-19 Thread R.I.Pienaar


- Original Message -
> From: "Antidot SAS" 
> To: "puppet-users" 
> Sent: Thursday, April 19, 2012 12:42:02 PM
> Subject: [Puppet Users] Re: function template: use of variable '$string' = 
> BUG?
> 
> Hi,
> 
> 
> A little love about my bug? Am I the only one with this problem or
> are we thousand :D ?

Yes, this is a bug if you just dont use $string it goes away, can you file a bug
at projects.puppetlabs.com?

Quick one liner to reproduce:

% FACTER_string="foo" puppet -e 'notice(inline_template("<%= Time.now %>"))'
notice: Scope(Class[main]): foo

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] How can i make a 'file' resource depend on package installation?

2012-04-23 Thread R.I.Pienaar


- Original Message -
> From: "geog" 
> To: "Puppet Users" 
> Sent: Monday, April 23, 2012 10:11:30 AM
> Subject: [Puppet Users] How can i make a 'file' resource depend on package 
> installation?
> 
> basically i want to add to my file resource a requirements on a pre-
> installed package and if its not installed should be first installed.
> 
> file {
>require => Package["SomePackage"]
> }
> 
> I understand require is not supported in file resource is there any
> other solution to have this dependency?

Require is whats called a meta paramater - it's supported on all resource types
including File.  Same for subscribe, notify and a few others

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] querying hiera data without providing host/scope

2012-04-30 Thread R.I.Pienaar


- Original Message -
> From: "Andreas Paul" 
> To: puppet-users@googlegroups.com
> Sent: Monday, April 30, 2012 2:52:00 PM
> Subject: [Puppet Users] querying hiera data without providing host/scope
> 
> Hello there,
> 
> I need to access the following hiera data in a script:
> $ hiera -c /etc/puppet/hiera.yaml tomcats environment=development
> line=intra3
> ["tc7_test1", "tc7_test8"]
> or
> $ hiera -c /etc/puppet/hiera.yaml apache_port environment=development
> line=intra3 name=tc7_test1
> 81
> 
> The example on https://github.com/puppetlabs/hiera uses facts of a
> specific hosts.
> I don't want to specify and load each YAML file for each host,
> because the hosts are already defined for a specific line and stage
> environment:
> $ hiera -c /etc/puppet/hiera.yaml hosts environment=development
> line=intra3
> ["serverA.domain.tld", "serverB.domain.tld"]
> 
> But I can't get the hiera.lookup to work without providing a scope
> with the facts of a specific host.

In this case the scope is just a hash so the cli command:

$ hiera -c /etc/puppet/hiera.yaml hosts environment=development line=intra3

translates to:

hiera.lookup("hosts", nil, {"environment" => "development", "line" => "intra3"})

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Using fact to determine node environment

2012-05-02 Thread R.I.Pienaar


- Original Message -
> From: "John Kennedy" 
> To: puppet-users@googlegroups.com
> Sent: Wednesday, May 2, 2012 11:59:49 AM
> Subject: [Puppet Users] Using fact to determine node environment
> 
> We have a custom fact that we wrote to determine which (business)
> environment a specific server belongs to (test, stage, production).
> We want to set up puppet environments (again, test, stage, and
> production).
> Is it possible to use our custom fact to set which environment a node
> belongs to?

your only option at present is to write out puppet.conf using a template
with your fact

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Using fact to determine node environment

2012-05-02 Thread R.I.Pienaar


- Original Message -
> From: "Nigel Kersten" 
> To: puppet-users@googlegroups.com
> Sent: Wednesday, May 2, 2012 4:10:16 PM
> Subject: Re: [Puppet Users] Using fact to determine node environment
> 
> 
> 
> 
> On Wed, May 2, 2012 at 4:19 AM, R.I.Pienaar < r...@devco.net > wrote:
> 
> 
> 
> 
> 
> - Original Message -
> > From: "John Kennedy" < skeb...@gmail.com >
> > To: puppet-users@googlegroups.com
> > Sent: Wednesday, May 2, 2012 11:59:49 AM
> > Subject: [Puppet Users] Using fact to determine node environment
> > 
> > We have a custom fact that we wrote to determine which (business)
> > environment a specific server belongs to (test, stage, production).
> > We want to set up puppet environments (again, test, stage, and
> > production).
> > Is it possible to use our custom fact to set which environment a
> > node
> > belongs to?
> 
> your only option at present is to write out puppet.conf using a
> template
> with your fact
> 
> 
> 
> 
> Unless something broke it recently, I ran for years with a fact that
> returned ":environment" and didn't set it in puppet.conf at all.

yes, it broke.  You'll get a mix of files from one environment and classes
from another etc, puppet.conf is the only option now

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Using fact to determine node environment

2012-05-02 Thread R.I.Pienaar


- Original Message -
> From: "Nigel Kersten" 
> To: puppet-users@googlegroups.com
> Sent: Wednesday, May 2, 2012 4:24:06 PM
> Subject: Re: [Puppet Users] Using fact to determine node environment
> 
> 
> 
> 
> On Wed, May 2, 2012 at 8:18 AM, R.I.Pienaar < r...@devco.net > wrote:
> 
> 
> 
> 
> 
> - Original Message -
> > From: "Nigel Kersten" < ni...@puppetlabs.com >
> > To: puppet-users@googlegroups.com
> 
> 
> > Sent: Wednesday, May 2, 2012 4:10:16 PM
> > Subject: Re: [Puppet Users] Using fact to determine node
> > environment
> > 
> > 
> > 
> > 
> > On Wed, May 2, 2012 at 4:19 AM, R.I.Pienaar < r...@devco.net >
> > wrote:
> > 
> > 
> > 
> > 
> > 
> > - Original Message -
> > > From: "John Kennedy" < skeb...@gmail.com >
> > > To: puppet-users@googlegroups.com
> > > Sent: Wednesday, May 2, 2012 11:59:49 AM
> > > Subject: [Puppet Users] Using fact to determine node environment
> > > 
> > > We have a custom fact that we wrote to determine which (business)
> > > environment a specific server belongs to (test, stage,
> > > production).
> > > We want to set up puppet environments (again, test, stage, and
> > > production).
> > > Is it possible to use our custom fact to set which environment a
> > > node
> > > belongs to?
> > 
> > your only option at present is to write out puppet.conf using a
> > template
> > with your fact
> > 
> > 
> > 
> > 
> > Unless something broke it recently, I ran for years with a fact
> > that
> > returned ":environment" and didn't set it in puppet.conf at all.
> 
> yes, it broke. You'll get a mix of files from one environment and
> classes
> from another etc, puppet.conf is the only option now
> 
> 
> 
> 
> I think you're thinking of the ENC setting the environment, not a
> fact called 'environment' RI?

nope.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Using fact to determine node environment

2012-05-02 Thread R.I.Pienaar


- Original Message -
> From: "Nigel Kersten" 
> To: puppet-users@googlegroups.com
> Sent: Wednesday, May 2, 2012 4:38:38 PM
> Subject: Re: [Puppet Users] Using fact to determine node environment
> 
> 
> 
> 
> On Wed, May 2, 2012 at 8:37 AM, R.I.Pienaar < r...@devco.net > wrote:
> 
> 
> 
> 
> 
> 
> > > Unless something broke it recently, I ran for years with a fact
> > > that
> > > returned ":environment" and didn't set it in puppet.conf at all.
> > 
> > yes, it broke. You'll get a mix of files from one environment and
> > classes
> > from another etc, puppet.conf is the only option now
> > 
> > 
> > 
> > 
> > I think you're thinking of the ENC setting the environment, not a
> > fact called 'environment' RI?
> 
> nope.
> 
> 
> 
> 
> 
> Anyone got a bug # for this?

pretty sure there was one but couldnt find it so I just knocked up a quick 
test, this has been discussed to death in the past


.
├── development
│   ├── modules
│   │   └── test
│   │   ├── files
│   │   │   └── envtest
│   │   └── manifests
│   │   └── init.pp
│   └── site.pp
├── production
│   ├── modules
│   │   └── test
│   │   ├── files
│   │   │   └── envtest
│   │   └── manifests
│   │   └── init.pp
│   └── site.pp
├── puppet.conf
└── test.pp


test.pp has: include test


production init.pp has:


class test {
notify{"production test": }
file{"/tmp/envtest":
source =>"puppet:///modules/test/envtest"
}
}


development just changed the notify

when running with --enviornment this works:

% puppet apply --config puppet.conf --environment development test.pp
notice: development test
notice: /Stage[main]/Test/Notify[development test]/message: defined 'message' 
as 'development test'
notice: /Stage[main]/Test/File[/tmp/envtest]/ensure: defined content as 
'{md5}e42d5f60192d1f8f94ce446fff3113b0'
notice: Finished catalog run in 0.03 seconds
% cat /tmp/envtest 
development

% puppet apply --config puppet.conf --environment production test.pp
notice: /Stage[main]/Test/File[/tmp/envtest]/content: content changed 
'{md5}e42d5f60192d1f8f94ce446fff3113b0' to 
'{md5}6f03617bce8a5d04fe97df572f273d05'
notice: production test
notice: /Stage[main]/Test/Notify[production test]/message: defined 'message' as 
'production test'
notice: Finished catalog run in 0.03 seconds
% cat /tmp/envtest
production

same with a fact and here i am getting development code with production files:

% FACTER_environment=development puppet apply --config puppet.conf test.pp
notice: development test
notice: /Stage[main]/Test/Notify[development test]/message: defined 'message' 
as 'development test'
notice: Finished catalog run in 0.02 seconds
% cat /tmp/envtest 
production

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Using fact to determine node environment

2012-05-02 Thread R.I.Pienaar


- Original Message -
> From: "R.I.Pienaar" 
> To: puppet-users@googlegroups.com
> Sent: Wednesday, May 2, 2012 4:46:24 PM
> Subject: Re: [Puppet Users] Using fact to determine node environment
> 
> 
> 
> - Original Message -
> > From: "Nigel Kersten" 
> > To: puppet-users@googlegroups.com
> > Sent: Wednesday, May 2, 2012 4:38:38 PM
> > Subject: Re: [Puppet Users] Using fact to determine node
> > environment
> > 
> > 
> > 
> > 
> > On Wed, May 2, 2012 at 8:37 AM, R.I.Pienaar < r...@devco.net >
> > wrote:
> > 
> > 
> > 
> > 
> > 
> > 
> > > > Unless something broke it recently, I ran for years with a fact
> > > > that
> > > > returned ":environment" and didn't set it in puppet.conf at
> > > > all.
> > > 
> > > yes, it broke. You'll get a mix of files from one environment and
> > > classes
> > > from another etc, puppet.conf is the only option now
> > > 
> > > 
> > > 
> > > 
> > > I think you're thinking of the ENC setting the environment, not a
> > > fact called 'environment' RI?
> > 
> > nope.
> > 
> > 
> > 
> > 
> > 
> > Anyone got a bug # for this?
> 
> pretty sure there was one but couldnt find it so I just knocked up a
> quick test, this has been discussed to death in the past

should say I am on 2.6.x here, this may well have been fixed in 2.7.x

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] mixing source & content (templates) in concat::fragment

2012-05-02 Thread R.I.Pienaar


- Original Message -
> From: "Tim Mooney" 
> To: puppet-users@googlegroups.com
> Sent: Wednesday, May 2, 2012 7:00:30 PM
> Subject: [Puppet Users] mixing source & content (templates) in 
> concat::fragment
> 
> 
> All-
> 
> We're using puppet 2.7.11.
> 
> Our custom firewall module currently builds the RHEL
> /etc/sysconfig/iptables (and ip6tables) from multiple fragments using
> concat::fragment.
> 
> The base part of the firewall is constructed like this:
> 
> class firewall {
>include concat::setup
> 
>$firewall_config  = '/etc/sysconfig/iptables'
> 
>concat::fragment { "firewall-base":
>  target => "$firewall_config",
>  source => [
>"puppet:///modules/firewall/firewall-base.$fqdn",
>"puppet:///modules/firewall/firewall-base"
>  ],
>  order => '01',
>}
> 
>concat::fragment {"firewall-end":
>  target  => "$firewall_config",
>  content => "COMMIT\n",
>  order   => '99',
>}
> }
> 
> 
> As you can see, we use source to look for a per-box custom firewall
> base first, and then fall back to a stock firewall-base file fragment.
> 
> I want to modify this config so that the fall-back fragment comes
> from a template, rather than a file fragment.  The problem is that it
> appears I can't do this:
> 

the file type in puppet does not provide a way to do this, so unfortunately
the concat cant do it either - since its just relying on the file type

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] mixing source & content (templates) in concat::fragment

2012-05-02 Thread R.I.Pienaar


- Original Message -
> From: "Tim Mooney" 
> To: puppet-users@googlegroups.com
> Sent: Wednesday, May 2, 2012 10:39:08 PM
> Subject: Re: [Puppet Users] mixing source & content (templates) in 
> concat::fragment
> 
> In regard to: Re: [Puppet Users] mixing source & content (templates)
> in...:
> 
> >> All-
> >>
> >> We're using puppet 2.7.11.
> >>
> >> Our custom firewall module currently builds the RHEL
> >> /etc/sysconfig/iptables (and ip6tables) from multiple fragments
> >> using
> >> concat::fragment.
> >>
> >> The base part of the firewall is constructed like this:
> >>
> >> class firewall {
> >>include concat::setup
> >>
> >>$firewall_config  = '/etc/sysconfig/iptables'
> >>
> >>concat::fragment { "firewall-base":
> >>  target => "$firewall_config",
> >>  source => [
> >>"puppet:///modules/firewall/firewall-base.$fqdn",
> >>"puppet:///modules/firewall/firewall-base"
> >>  ],
> >>  order => '01',
> >>}
> >>
> >>concat::fragment {"firewall-end":
> >>  target  => "$firewall_config",
> >>  content => "COMMIT\n",
> >>  order   => '99',
> >>}
> >> }
> >>
> >>
> >> As you can see, we use source to look for a per-box custom
> >> firewall
> >> base first, and then fall back to a stock firewall-base file
> >> fragment.
> >>
> >> I want to modify this config so that the fall-back fragment comes
> >> from a template, rather than a file fragment.  The problem is that
> >> it
> >> appears I can't do this:
> >>
> >
> > the file type in puppet does not provide a way to do this, so
> > unfortunately
> > the concat cant do it either - since its just relying on the file
> > type
> 
> Thanks R.I. (and thanks for concat).  I guess I'll switch all of our
> host-specific base fragments to be a templates, even when there's no
> template code in them, and use
> 
>concat::fragment { 'firewall-base':
>  target => $firewall_config,
>  content => [
>template("firewall/firewall-base.${::fqdn}.erb"),
>template('firewall/firewall-base'),
>  ],
>  order => '01',
>}
> 

puppet does not support this either :)

what you'll get there is a concat of the 2 templates

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] hiera "environmentss" question

2012-05-02 Thread R.I.Pienaar


- Original Message -
> From: "Ramin K" 
> To: puppet-users@googlegroups.com
> Sent: Wednesday, May 2, 2012 10:51:56 PM
> Subject: Re: [Puppet Users] hiera "environmentss" question
> 
> On 5/2/2012 2:16 PM, Gary Larizza wrote:
> > I'm using the following which I copied from somewhere. Quotes
> > might
> > be part of the missing magic. Also I'm not sure you'd want a -
> > in
> > there either.
> >
> > :yaml:
> > :datadir:
> > '/home/puppet/environments/%{environment}/hieradata'
> >
> >
> > I would use double-quotes for string interpolation, but this should
> > work.  I've used this in a couple of on-site engagements, and it
> > has
> > worked well for us.
> 
> I don't think this is correct. If it were, my config should not work
> at all. In this case single or double quotes should both work. It's my
> understanding that hiera.yaml is a data file that is going to be
> parsed and then consumed by Puppet where things like variable interpolation
> would happen. There isn't any variable interpolation during the
> parsing so single quotes are more correct.

that's correct yeah

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Puppet 3.0 and Hiera

2012-05-04 Thread R.I.Pienaar


- Original Message -
> From: "Pieter van de Bruggen" 



> 
> * How should we integrate hiera_array() and hiera_hash() ?
> * How should we integrate hiera ’s “default” and “override”
> parameters?
> * How should we handle overlaps between data supplied by Hiera
> and data supplied in a parameterized class include?

Given:

class foo($something="default") { }

I think the plan was that there would be a priority order as below:

 - someone wrote in a manifest: class{"foo": something => something}
 - an ENC supplied the values for something on the class foo
 - someone did "include foo" or class{"foo": } this would consult hiera
 - if hiera does not have an answer it would default to "default"

This gives people with more complex needs than those matched by hiera
the ability to use ENCs and get exactly the data model they desire as
well as people who do not want any magical data lookup for some class
the ability to hard code values.

And at the same time it lets module authors provide out of the box
defaults that work without placing a load on module users where they
might have to read every class and set hiera values for every argument
before they can use a class if all they wanted was the default out of
the box behaviour.

Does this sound sane?

> If you’re interested in test-driving the new functionality for
> yourself, checkout out the master branch of the Puppet repository on
> Github , install Hiera (with gem install hiera ) and make the
> following configuration changes:
> 
> * Set data_binding_terminus to hiera
> * If you have a Hiera configuration file, set hiera_config to
> point to it.
> * If you don’t, create a file in ${confdir}/hiera.yaml with these
> contents:
> 
> 
> :backend:
> 
> - yaml
> 
> :yaml:
> 
> :datadir: $confdir/data
> 
> :hierarchy:
> 
> - %{certname}
> 
> - %{environment}
> 
> - global
> 
> This sets up a default hierarchy that looks for values in
> ${confdir}/data , first in the ${certname}.yml file, then in the
> ${environment}.yml file, then in global.yml .

These should probably %{::certname} etc right?

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: Puppet 3.0 and Hiera

2012-05-04 Thread R.I.Pienaar


- Original Message -
> From: "Jeremy Carroll" 
> To: puppet-users@googlegroups.com
> Sent: Friday, May 4, 2012 5:19:37 PM
> Subject: [Puppet Users] Re: Puppet 3.0 and Hiera
> 
> We use Hiera backed Puppet here at Klout. Mainly for the reasons of
> separating configuration data from puppet modules. We have had great
> success, and I welcome this change to puppet core. Reminds me of
> some of Chef's "Deep Merge" functionality. Here are a few of my
> thoughts.
> 
> 
> * Name spacing variable names is a welcome improvement. It will
> help with variable name collisions we have experienced (Ex:
> module1::hosts, module2::hosts). We currently use the
> %{calling_class}, %{calling_module} method of scoping hiera
> variables.
> * I currently like the flexibility of defining my own order for
> merging of variables in hiera.yaml. But I would like Puppet to
> formalize the merge order so everybody can use the same style
> when creating modules for reuse. Also have some methods to
> specify overrides instead of merging from top to bottom for
> hashes / arrays. Helps for configurations for systems that don't
> want to inherit everything. Chef has a lot of work for Deep
> Merging ordering that I believe Hiera would benefit from.

Do you mean you want the hierarchy to be standardised? 

can you expand this with examples please?


> * hiera_hash would be improved by sorting the hash natively. We
> currently repeat this pattern every time we use a hiera hash. We
> create a sorted array of each hash key, then iterate over the
> array to lookup values in the hash. If we fail to do this,
> puppet run re-orders the file every run as hash orders are not
> guaranteed. This causes a lot of un-necessary work and change
> notifications. Example below.

Unfortunately ruby hashes has no order so we cant sort the hashes for you :(

Things are improving in 1.9, but I do not think there is much we can do there

> 
> 
> hieradata
> 
> 
> ---
> 
> hiera_var:
> user:
> value: 'my_value'
> module/params.pp
> 
> $hiera_var = hiera_hash('hiera_var')
> $sorted_var = sort(keys($hiera_var))
> module/template/sometemplate.pp
> 
> 
> <% scope.lookupvar('module::params::sorted_var').each do |item| -%><%
> scope.lookupvar('hadoop::params::hiera_var')[item].each do
> |key,value| -%>
> <%= user %> <%= key %> <%= value %>
> <% end -%><% end -%>
> On Thursday, May 3, 2012 10:05:14 AM UTC-7, Pieter van de Bruggen
> wrote:
> 
> 
> 
> 
> 
> Greetings,
> 
> As many of you may be aware, Hiera will be tightly integrated into
> Puppet in the upcoming release of Puppet 3.0. As a final sanity
> check of this work, I’d like to open our current plan for
> integration up for feedback. This is particularly for feedback from
> existing Hiera users, but I hope to solicit good feedback from those
> not using Hiera as well.
> 
> The problem, as it currently exists, is that Puppet (core) has no
> good first-class mechanism for separating configuration data from
> manifests. Everything from $faked_namespaces__in__variable_names to
> specialty “params” classes have been tried, with varying degrees of
> success.
> 
> Hiera came along as another solution to this problem, and provided a
> useful abstraction for hierarchical data lookup, but life as a
> plugin meant that certain integrations were still difficult. Our aim
> in Puppet 3.0 is to tighten up these integrations (making Hiera more
> useful), provide first-class data separation solution (for those not
> already using Hiera), and to provide a simple and safe migration for
> those currently using Hiera.
> 
> Here’s what’s new:
> 
> * Hiera data keys can be namespaced
> 
> 
> * (e.g. 'dns::nameserver': '8.8.8.8' )
> * Namespaced data will automatically populate class parameters
> 
> * (e.g. 'dns::nameserver' will be automatically looked up for
> the $nameserver parameter when you include dns )
> 
> 
> Here’s what’s changed:
> 
> * The hiera-puppet module will no longer be required
> 
> 
> * It should, however, still continue to work
> * The heira() function (from the hiera-puppet module) will be
> superceded by the lookup() function (in Puppet core)
> * hiera_include() will not be ported; include now properly accept
> arrays, making this redundant
> 
> 
> Here’s what were still wondering about:
> 
> * How should we integrate hiera_array() and hiera_hash() ?
> * How should we integrate hiera ’s “default” and “override”
> parameters?
> * How should we handle overlaps between data supplied by Hiera
> and data supplied in a parameterized class include?
> 
> 
> If you’re interested in test-driving the new functionality for
> yourself, checkout out the master branch of the Puppet repository on
> Github , install Hiera (with gem install hiera ) and make the
> following configuration changes:
> 
> * Set data_binding_terminus to hiera
> * If you have a Hie

Re: [Puppet Users] Puppet 3.0 and Hiera

2012-05-06 Thread R.I.Pienaar

On 5 May 2012, at 17:26, Trevor Vaughan  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> With the integration of Hiera, is the extlookup functionality being 
> deprecated?
> 
> If so, I would like to ask that the team add a Hiera backend for the existing 
> extlookup data sources.
> 
> I know that it won't support hashes but it would help to break the view that 
> Puppet routinely breaks existing functionality on upgrades.


The hiera-puppet project provides a script to convert extlookup CSV to json or 
yaml, using that to migrate would be my preferred way with the extlookup 
function logging deprecation warnings

If this reflects the actual plan I don't know, I did expect the people working 
on the merging project to engage on this thread more since they know best and 
there seems to be a few points for discussion here already that needs 
clarification 


> 
> Thanks,
> 
> Trevor
> 
> On 05/03/2012 01:05 PM, Pieter van de Bruggen wrote:
>> Greetings,
>> 
>> As many of you may be aware, Hiera will be tightly integrated into Puppet
>> in the upcoming release of Puppet 3.0. As a final sanity check of this
>> work, I’d like to open our current plan for integration up for feedback.
>> This is particularly for feedback from existing Hiera users, but I hope to
>> solicit good feedback from those not using Hiera as well.
>> 
>> The problem, as it currently exists, is that Puppet (core) has no good
>> first-class mechanism for separating configuration data from manifests.
>> Everything from $faked_namespaces__in__variable_names to specialty “params”
>> classes have been tried, with varying degrees of success.
>> 
>> Hiera came along as another solution to this problem, and provided a useful
>> abstraction for hierarchical data lookup, but life as a plugin meant that
>> certain integrations were still difficult. Our aim in Puppet 3.0 is to
>> tighten up these integrations (making Hiera more useful), provide
>> first-class data separation solution (for those not already using Hiera),
>> and to provide a simple and safe migration for those currently using Hiera.
>> 
>> Here’s what’s new:
>> 
>>   - Hiera data keys can be namespaced
>>  - (e.g. 'dns::nameserver': '8.8.8.8')
>>   - Namespaced data will automatically populate class parameters
>>  - (e.g. 'dns::nameserver' will be automatically looked up for the
>>  $nameserver parameter when you include dns)
>> 
>> Here’s what’s changed:
>> 
>>   - The hiera-puppet module will no longer be required
>>  - It should, however, still continue to work
>>   - The heira() function (from the hiera-puppet module) will be superceded
>>   by the lookup() function (in Puppet core)
>>   - hiera_include() will not be ported; include now properly accept
>>   arrays, making this redundant
>> 
>> Here’s what were still wondering about:
>> 
>>   - How should we integrate hiera_array() and hiera_hash()?
>>   - How should we integrate hiera’s “default” and “override” parameters?
>>   - How should we handle overlaps between data supplied by Hiera and data
>>   supplied in a parameterized class include?
>> 
>> If you’re interested in test-driving the new functionality for yourself,
>> checkout out the master branch of the Puppet repository on
>> Github,
>> install Hiera (with gem install hiera) and make the following configuration
>> changes:
>> 
>>   - Set data_binding_terminus to hiera
>>   - If you have a Hiera configuration file, set hiera_config to point to
>>   it.
>>   - If you don’t, create a file in ${confdir}/hiera.yaml with these
>>   contents:
>> 
>> :backend:
>> 
>>   - yaml
>> 
>> :yaml:
>> 
>>   :datadir: $confdir/data
>> 
>> :hierarchy:
>> 
>>   - %{certname}
>> 
>>   - %{environment}
>> 
>>   - global
>> 
>> This sets up a default hierarchy that looks for values in ${confdir}/data,
>> first in the ${certname}.yml file, then in the ${environment}.yml file,
>> then in global.yml.
>> 
>> That should be it!  Please, let us know if you're having trouble getting
>> started, or if you have questions, concerns, thoughts, or opinions about
>> any of this.
>> 
>> Thanks!
>> 
> 
> - -- 
> Trevor Vaughan
> Vice President, Onyx Point, Inc.
> email: tvaug...@onyxpoint.com
> phone: 410-541-ONYX (6699)
> pgp: 0x6C701E94
> 
> - -- This account not approved for unencrypted sensitive information --
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.12 (GNU/Linux)
> 
> iQEcBAEBAgAGBQJPpVScAAoJECNCGV1OLcypcesIAJT9gARlmQNxR7ftUo4soR1r
> R2aCh/k2B+Wylj/xfF3o9j3gZh/1WrOLogMGThNgYT9Vcv50zCcbeFjbCTVr2bBo
> 18gtlcoJhTBeUebBk6CsFsG+sIApwja3UDbpSm49FRquCK/KI+fBV8gHhAQt9fgm
> 1P0ZXB1KU61nhqrLEpHNRmJVKBvLCwDuqEMJltMuGoysczWEv0uVROtYari1T3g+
> tNqov2EkSj5NV+Au5DeNNKviToEDn+wR7JvtXEqRdwSc142U9PnZwp8MvM+/i2+W
> RGKqg8HZuMMLEbbSnimdRnS6pCwKdgVJDPwBb+CoiZJJ0ftWCF2F9lNDjgUNjcI=
> =/h12
> -END PGP SIGNATURE-
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppe

Re: [Puppet Users] Puppet 3.0 and Hiera

2012-05-08 Thread R.I.Pienaar


- Original Message -
> From: "John Warburton" 
> To: puppet-users@googlegroups.com
> Sent: Tuesday, May 8, 2012 12:14:48 PM
> Subject: Re: [Puppet Users] Puppet 3.0 and Hiera
> 
> 
> On 8 May 2012 20:00, Derek J. Balling < dr...@megacity.org > wrote:
> 
> 
> 
> 
> On May 7, 2012, at 12:47 PM, Christopher Wood wrote:
> > Wrapper script (similar concept for anywhere with a yaml reader):
> 
> Still have to *write* the YAML files.
> 
> 
> 
> Oh yeah. This is my big motivator sticking with extlookup and not
> converting to Hiera - anyone in the team can do CSV. But YAML is
> starting to push well into the dev camp and far away from ops (IMHO)

If you want the same abilities that CSV has then this would be your YAML:

sysadmin: y...@your.com
nameservers: [1.2.3.4, 2.3.4.5]

just that simple, I think this is much clearer than CSV.  If people really are
attached to CSV i guess it would be pretty trivial to write a CSV backend for
hiera but in the past one of the big complaints I had about extlookup was CSV
files.

When extlookup was written puppet did not have hashes and so CSV was a perfect
fit, now though it does and CSV just cant store all the kinds of data we needed
so rather than provide a crippled CSV implementation I decided to skip it.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: Puppet Sites. Your thoughts?

2012-05-10 Thread R.I.Pienaar


- Original Message -
> From: "Daniel Sauble" 
> To: puppet-users@googlegroups.com
> Sent: Thursday, May 10, 2012 7:34:14 PM
> Subject: [Puppet Users] Re: Puppet Sites. Your thoughts?
> 
> On Thursday, May 10, 2012 10:39:22 AM UTC-7, windowsrefund wrote:
> 
> 
> On May 10, 12:44 pm, Daniel Sauble < djsau...@puppetlabs.com > wrote:
> > 
> > - Securely add nodes to your deployment without manually signing
> > certificates on the CA...
> > - ...so that you can have the advantages of autosigning without its
> > security problems.
> > 
> 
> I'm about to engage on a similar effort and was thinking of writing a
> puppet face to handle this job. Can you elaborate on the work flow
> and
> solution you're thinking about?
> 
> 
> 
> We're looking to implement a Puppet Face to address this need. The
> workflow currently looks like:
> 
> 
> 
> 1. Login to the site host
> 2. Generate a pre-shared key
> 3. Join a node to the site using the pre-shared key
> 4. Repeat step 3 for every node you want to add to the site
> 
> 
> 
> From the command-line, this workflow might be represented as the
> following:
> 
> node02$ ssh ad...@site02.domain.com
> Last login: Mon May 7 18:15:43 2012
> site02$ mount /media/usbdisk
> site02$ puppet site generate key > /media/usbdisk/site.key
> site02$ umount /media/usbdisk
> site02$ exit
> node02$ mount /media/usbdisk
> node02$ puppet node join site02.domain.com < /media/usbdisk/site.key
> Trying to add node02.domain.com to the site at site02.domain.com...
> 
> 
> Use `puppet site status node02.domain.com` to confirm success
> 
> To stop waiting for the command to complete, press Ctrl-C.
> 
> The command will still complete in the background. Added
> node02.domain.com to the site at site02.domain.com

Can you explain the advantages this workflow has over the current process
involving requesting a cert and signing it on the master?

It would also be great if you could send plain text mail as is the convention
on this list.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Mailing list etiquette

2012-05-16 Thread R.I.Pienaar


- Original Message -
> From: "Trevor Vaughan" 
> To: puppet-users@googlegroups.com
> Sent: Wednesday, May 16, 2012 2:42:49 PM
> Subject: Re: [Puppet Users] Mailing list etiquette
> 
> I'm going to have to push back a bit at the no top posting with the
> same reasoning as described here:
> https://lopsa.org/content/top-posting-vs-bottom-posting-stop-tilting-windmills.
> 
> Especially since most mobile mail clients top-post, it's going to be
> difficult to get this one to stick.
> 
> I personally prefer it so that I don't have to scroll past hundreds
> of lines of:
> 
> "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+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.";
> 
> If you're directly responding to something non-obvious, I do think
> that copying the relevant material up is nice but that you shouldn't
> lose the rest of the conversation for those poor folks who may be
> using Mutt as their primary mail reader (or some other non-threading
> reader).

I tend to agree top posting does sometimes make sense, my main pain point is
HTML mail which makes it hard to reply sanely for users who choose not to use
HTML mail clients or who choose to disable that feature.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Puppet facter 1.6.8 and inet6 addresses

2012-05-17 Thread R.I.Pienaar


- Original Message -
> From: "Christophe L" 
> To: puppet-users@googlegroups.com
> Sent: Thursday, May 17, 2012 2:36:49 PM
> Subject: [Puppet Users] Puppet facter 1.6.8 and inet6 addresses
> 
> Hello,
> 
> when running the command "ip a" on a debian VM, I get this
> 
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: eth0:  mtu 1500 qdisc pfifo_fast
> state UP qlen 1000
> link/ether 00:50:56:99:73:35 brd ff:ff:ff:ff:ff:ff
> inet 10.66.112.71/24 brd 10.66.112.255 scope global eth0
> inet6 fe80::250:56ff:fe99:7335/64 scope link
> valid_lft forever preferred_lft forever
> 
> But with facter run as root I don't get any inet6 adress
> 
> facter | grep addr
> 
> ipaddress => 10.66.112.71
> ipaddress_eth0 => 10.66.112.71
> ipaddress_lo => 127.0.0.1
> macaddress => 00:50:56:99:73:35
> macaddress_eth0 => 00:50:56:99:73:35
> 
> I'm using facter v1.6.8
> 
> Could you please tell me how to get the IPv6 adresse using facter ?

Facter specifically do not report link local addresses.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] starting puppetmaster - what's the best way?

2012-05-23 Thread R.I.Pienaar


- Original Message -
> From: "Sans" 
> To: puppet-users@googlegroups.com
> Sent: Wednesday, May 23, 2012 10:02:46 AM
> Subject: [Puppet Users] starting puppetmaster - what's the best way?
> 
> Dear all,
> 
> I've moved away from WEBrick to Apache/passenger on puppetmaster, so
> not /etc/init.d/ script anymore to start the master. As, (AFAIU)
> puppetmasterd is still required to be running, what's the best why
> of doing that. I don't think I should expect that apache should
> start that when httpd is [re]started or, should I? I can use
> /etc/rc.local for that but I was wondering if I'm doing it right.

yes, apache manages it under passenger for you.

you should not start the puppetmaster by hand in any way then

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Thoughts on job listings?

2012-05-30 Thread R.I.Pienaar


- Original Message -
> From: "Michael Stahnke" 
> To: puppet-users@googlegroups.com
> Sent: Wednesday, May 30, 2012 9:49:44 PM
> Subject: [Puppet Users] Thoughts on job listings?
> 
> How do folks feel about getting Puppet job listings on this list?
> I've rejected a few that we quite spammy, but when the subject matter
> really is a system admin with puppet experience, the decision becomes
> a bit different.
> 
> I'm looking for general feelings.  A simple +1 or -1 would be great.

job postings from community members looking for themselves/their employers 
with clear direct to employer contact information +1

job postings from recruiters -1

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] repeat a character in a string a certain number of times

2012-05-31 Thread R.I.Pienaar


- Original Message -
> From: "Luke Bigum" 
> To: puppet-users@googlegroups.com
> Sent: Thursday, May 31, 2012 11:44:41 AM
> Subject: [Puppet Users] repeat a character in a string a certain number of 
> times
> 
> Hi all,
> 
> This should be pretty easy to do but I can't figure it out in Puppet
> DSL or ERB. I basically want to repeat a certain character X number of
> times, like this:
> 
> $string = regsubst("x", "x", "y{30}", "EG")
> 
> To replace one 'x' with 30 y's.
> 
> Any tips?

Using ruby:

>> "foo".gsub("o", "a" * 20)
=> "f"
>> "foo".sub("o", "a" * 20)
=> "fo"

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] MCollective not all nodes answer to commands when using aes_security plugin

2012-06-07 Thread R.I.Pienaar


- Original Message -
> From: "Martin Willemsma" 
> To: "Puppet Users" 
> Sent: Thursday, June 7, 2012 7:11:41 AM
> Subject: [Puppet Users] MCollective not all nodes answer to commands when 
> using aes_security plugin
> 
> Hi,
> 
> I deployed MCollective to our Puppet clients. approx. ~ 200. Our
> platform requires the most secure setup possible, so PSK as
> securityprovider is not an option.

I'd almost always suggest SSL TLS + the ssl plugin now.

> Therefor I changed the security provider to aes_security reusing
> puppets certificates in the server.cfg as found  in the docs (1)
> Our goal is to use mcollective to offload event-driven actions to
> agents running on designated nodes from a webapplication.
> 
> e.g: send out a message to the 'platform' collective to create a DNS
> record. This message should be processed by a node that runs the
> 'DNS' agent.
> 
> One thing I noticed after switching to the aes_security plugin is the
> ping latency went up and a reply to an action does not come back from
> all the nodes. Were does this latency come from?
> If I do a mco ping on the client I expect:
> 
> - every node to respond
> - show me the   ping statistics  in the end
> - jump back to my console ready for the next command
> 
> but it does not. Instead it shows me the output for 207 nodes and
> then
> it just "HANGS" there.

> 
> This output shows pingtimes hostnames omitted
> 
> 1340.38 ms <- first reply
> 1406.25 ms
> 1456.71 ms
> 1508.19 ms
> 1550.52 ms
> 1576.07 ms
> 1601.15 ms
> 1627.40 ms
> 1653.23 ms
> 1678.26 ms
> [ .. omitted intentionally ]
> 7518.66 ms
> 7556.47 ms
> 7593.06 ms
> 7623.46 ms
> 7648.64 ms
> 7685.62 ms
> 7722.84 ms <- last reply I see on the client console


There are a few odd things here, the first reply is way too slow, the
AES plugin is computationally very heavy and not suited for large
deploys yours though is not large and even then the overhead is in the
30 to 40ms over that of the PSK plugin on first response - the effect
snow balls but this should not be the performance I expect.

Second the 'mco ping' should not run indefinitely till you stop it, it
should run for 5 seconds and then end, does yours do that with the PSK
plugin active?

Hard to guess what might be the underlying cause for the above
combination of issues - could be a very slow machine as the mco client,
could be issues on the network perhaps there are a lot of TCP
rebroadcasts or something along those lines. 

On the machines that do not respond do you see anything in their logs -
put them in debug and make sure they got the request and replied.
Anything weird on your broker?  Large CPU usage perhaps?


> 
> 
> If I check the the logfile on the client sending the command
> '/var/log/mcollective.log' the last few lines show me:
> 
> D, [2012-06-07T07:39:46.470905 #15910] DEBUG -- :
> pluginmanager.rb:83:in `[]' Returning cached plugin security_plugin
> with class MCollective::Security::Aes_security
> D, [2012-06-07T07:39:46.471029 #15910] DEBUG -- :
> aes_security.rb:202:in `deserialize' De-Serializing using marshal
> D, [2012-06-07T07:39:46.471121 #15910] DEBUG -- :
> aes_security.rb:255:in `decrypt' Decrypting message using private key
> D, [2012-06-07T07:39:46.495265 #15910] DEBUG -- :
> aes_security.rb:202:in `deserialize' De-Serializing using marshal
> D, [2012-06-07T07:39:46.495711 #15910] DEBUG -- : stomp.rb:191:in
> `receive' Waiting for a message from Stomp
> 
> I can wait forever but it does not receive
> I use (control + break) to exit out
> 
> ^C
> 
>  ping statistics 
> 207 replies max: 6877.20 min: 616.98 avg: 3912.99
> 
> Logfile shows me:
> 
> D, [2012-06-07T07:41:10.571316 #15910] DEBUG -- : client.rb:72:in
> `unsubscribe' Unsubscribing reply target for discovery
> D, [2012-06-07T07:41:10.571496 #15910] DEBUG -- :
> pluginmanager.rb:83:in `[]' Returning cached plugin connector_plugin
> with class MCollective::Connector::Stomp
> D, [2012-06-07T07:41:10.571615 #15910] DEBUG -- : stomp.rb:257:in
> `unsubscribe' Unsubscribing from /topic/mcollective.discovery.reply
> D, [2012-06-07T07:41:10.572767 #15910] DEBUG -- :
> pluginmanager.rb:83:in `[]' Returning cached plugin connector_plugin
> with class MCollective::Connector::Stomp
> D, [2012-06-07T07:41:10.572849 #15910] DEBUG -- : stomp.rb:264:in
> `disconnect' Disconnecting from Stomp
> 
> Same behavior with using any of the other commands 'get_fact' , 'rpc
> package' 'rpc service'. I'm just not able to do a search over the
> collective when using the AES plugin.
> 
> If I switch switch back to PSK replies are speedy and always come
> back. But then again this is not want.
> 
> At first I was using RabbitMQ default config. I tries some tweaking
> but did not seem to make any difference to the behaviour of mco. I
> switched to ActiveMQ 5.6 with the configfiles from puppetlabs.git.
> Set
> it up according to the docs , again played with some setttings and
> did
> not do anything at all.
> 
> tcpdumps show the node running

Re: [Puppet Users] MCollective not all nodes answer to commands when using aes_security plugin

2012-06-08 Thread R.I.Pienaar


- Original Message -
> From: "Martin Willemsma" 
> To: puppet-users@googlegroups.com
> Sent: Friday, June 8, 2012 7:11:39 AM
> Subject: Re: [Puppet Users] MCollective not all nodes answer to commands when 
> using aes_security plugin
> 
> Thanks for your response.
> One thing I noticed when using the PSK is that I indeed see the
> discovery with the progressbar. That's one thing I never see when
> using AES. Commands always come back from discovered nodes when using
> PSK.
> 
> You suggest SSL TLS, is that the same as AES provider i'm using right
> now?

identity of the client is securely established and the payload is encrypted
using industry standards, i guess it depends on your needs though

> 
> I run the client and on the same node as the rabbitmq.  Also tried
> with an activemq installation on another node in the same subnet.
> Doesn't seem to make any difference. The node running the messagebus
> is mostly idle. 4 CPUs / 4Gb ram and on the other node 2 CPU / 2 Gb
> ram. I also tried this the client on my workstation. I5 / 8 Gb ram /
> SSD disk, same behavior.
> 
> I agree that the ping times are pretty high but I could live with
> that if at least all the replies came back.

ping times that long will just prevent everything from working. there's
a fundamental problem somewhere.

> I spend quite some time making this work on our platform. I need to
> look more in-depth on the network part.
> 
> 2012/6/7 R.I.Pienaar :
> >
> >
> > - Original Message -
> >> From: "Martin Willemsma" 
> >> To: "Puppet Users" 
> >> Sent: Thursday, June 7, 2012 7:11:41 AM
> >> Subject: [Puppet Users] MCollective not all nodes answer to
> >> commands when using aes_security plugin
> >>
> >> Hi,
> >>
> >> I deployed MCollective to our Puppet clients. approx. ~ 200. Our
> >> platform requires the most secure setup possible, so PSK as
> >> securityprovider is not an option.
> >
> > I'd almost always suggest SSL TLS + the ssl plugin now.
> >
> >> Therefor I changed the security provider to aes_security reusing
> >> puppets certificates in the server.cfg as found  in the docs (1)
> >> Our goal is to use mcollective to offload event-driven actions to
> >> agents running on designated nodes from a webapplication.
> >>
> >> e.g: send out a message to the 'platform' collective to create a
> >> DNS
> >> record. This message should be processed by a node that runs the
> >> 'DNS' agent.
> >>
> >> One thing I noticed after switching to the aes_security plugin is
> >> the
> >> ping latency went up and a reply to an action does not come back
> >> from
> >> all the nodes. Were does this latency come from?
> >> If I do a mco ping on the client I expect:
> >>
> >> - every node to respond
> >> - show me the   ping statistics  in the end
> >> - jump back to my console ready for the next command
> >>
> >> but it does not. Instead it shows me the output for 207 nodes and
> >> then
> >> it just "HANGS" there.
> >
> >>
> >> This output shows pingtimes hostnames omitted
> >>
> >> 1340.38 ms <- first reply
> >> 1406.25 ms
> >> 1456.71 ms
> >> 1508.19 ms
> >> 1550.52 ms
> >> 1576.07 ms
> >> 1601.15 ms
> >> 1627.40 ms
> >> 1653.23 ms
> >> 1678.26 ms
> >> [ .. omitted intentionally ]
> >> 7518.66 ms
> >> 7556.47 ms
> >> 7593.06 ms
> >> 7623.46 ms
> >> 7648.64 ms
> >> 7685.62 ms
> >> 7722.84 ms <- last reply I see on the client console
> >
> >
> > There are a few odd things here, the first reply is way too slow,
> > the
> > AES plugin is computationally very heavy and not suited for large
> > deploys yours though is not large and even then the overhead is in
> > the
> > 30 to 40ms over that of the PSK plugin on first response - the
> > effect
> > snow balls but this should not be the performance I expect.
> >
> > Second the 'mco ping' should not run indefinitely till you stop it,
> > it
> > should run for 5 seconds and then end, does yours do that with the
> > PSK
> > plugin active?
> >
> > Hard to guess what might be the underlying cause for the above
> > combination of issues - could be a very slow machine as the mco
> > client,
> > could be issues on the network perhaps there a

Re: [Puppet Users] MCollective not all nodes answer to commands when using aes_security plugin

2012-06-09 Thread R.I.Pienaar


- Original Message -
> From: "Martin Willemsma" 
> To: puppet-users@googlegroups.com
> Sent: Saturday, June 9, 2012 4:37:05 AM
> Subject: Re: [Puppet Users] MCollective not all nodes answer to commands when 
> using aes_security plugin
> 
> I currently have two different MQ's running, one activeMQ running on
> a node and a rabbitMQ on a different one.
>  If I switch my mcollective servers from one broker to another and do
> a 'mco ping' while the nodes are registering with the other broker I
> hit a threshold somewhere.

are you saying you're trying to mix activemq and rabbitmq in the same setup?

> 
> Scenario:
> 
> I start a 'mco ping' from 2 clients simultaneously. Each client
> registered to a different broker.   Both can successfully do a ping
> to
> all  nodes.
> 
> client 1 -
> 
> 199.49 ms
> 238.21 ms
> 275.27 ms
> 312.39 ms
> 350.79 ms
> 387.84 ms
> [...]
> 2624.43 ms
> 2993.36 ms
> 
>  ping statistics 
> 50 replies max: 2993.36 min: 199.49 avg: 1030.95
> 
> client 2 -
> 
> 469.72 ms
> 492.41 ms
> 516.31 ms
> 541.34 ms
> 638.03 ms
> 664.93 ms
> [...]
> 4254.50 ms
> 4276.60 ms
> 
>  ping statistics 
> 160 replies max: 4276.60 min: 469.72 avg: 2414.46
> 
> The command does complete and ping times start way lower. I found
> some nodes with <512 Mb ram.  Could it be possible that these are causing
> problem because they are swapping and do not respond quick enough and
> somehow that reply gets lost in translation causing the mechanism to
> break?

they wont cause everything to slow down - unless they are either your client
or your broker - those slow machines will just respond slowly


> If I do a 'mco rpc service status service=ssh' on both clients
> 
> client 1 -
> 
> Determining the amount of hosts matching filter for 2 seconds  50
> 
>  * [ > ]
>  50 / 50
> 
> 
> client 2 -
> 
> Determining the amount of hosts matching filter for 2 seconds 
> warn: Could not decrypt message from client: #:
> execution expired
> warn: Ignoring a message that did not pass security validations


this might be related to not enough entropy on your machine running the
client perhaps?  is this still with AES or ...?

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] can we avoid notify/subscribe firing on a mode change?

2012-06-13 Thread R.I.Pienaar


- Original Message -
> From: "Jo Rhett" 
> To: puppet-users@googlegroups.com
> Sent: Wednesday, June 13, 2012 9:33:35 AM
> Subject: [Puppet Users] can we avoid notify/subscribe firing on a mode change?
> 
> I managed to have a booboo tonight by restarting a process which
> really shouldn't be. What I ran into was that a mode change caused
> subscribe to fire and the process to restart.
> 
> Is it just me, or should subscribe/notify only fire on content
> changes?

its just you :P

> Also given that "replace" only affects file contents, this means that
> you can never change the mode of a file for new installs only,
> either.  So it's always a risk of restarting a process.

sounds like replace should maybe be expanded to also support giving
other properties the same treatment perhaps?

> And when I slapped myself over the head on this, I seemed to remember
> a discussion about making this granular. But I've searched and
> searched and I can't find the discussion. Can someone clue-by-4 me,
> or did I misremember this?
> 
> And if I did misremember, can anyone think of a reason that I
> shouldn't file a bug over this issue?  I have thought and thought
> and I just can't find a situation where I think that changing the
> mode should cause a refresh.  Owner or group in some circumstances,
> but not many. I think that the default should be content only, with
> an option to say "any attribute".

I can think of a few, but really any case where a files mode out of the
box from say RPM prevent some other service from functioning because it
relies on this file.  File mode change -> dependant service restart.

Lots of daemons ship files like accessible only by $daemon:$daemon when
what we need is $daemon:$otherdaemon or maybe $daemon:$group_of_daemons.
You want to notice $otherdaemon that it can now read that file etc

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] What triggers a client to pull from server

2012-06-14 Thread R.I.Pienaar


- Original Message -
> From: "Alex" 
> To: puppet-users@googlegroups.com
> Sent: Thursday, June 14, 2012 9:25:13 AM
> Subject: [Puppet Users] What triggers a client to pull from server
> 
> Hi,
> 
> Installing my first Puppet master / client environment.  All working
> well so far, the master and client are communicating.
> 
> However it is not yet clear to me what triggers the client to pull
> from the master.  For instance, I can see evidence of the client having
> executed the master's site.pp file on startup, but when I make a
> change to site.pp the changes are not reflected in the client until I
> restart the client's puppet process.  I thought the Puppet client process
> would periodically pull from the server?
> 
> Maybe I'm not waiting long enough.

usually the agent runs every 30 minutes but thats configurable, you can 
look at 'puppet kick', mcollective to allow on demand triggering.

if you ssh to a particular machine running 'puppet agent --test' will force
a run and you'll see what its doing etc

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] optimize performance

2012-06-16 Thread R.I.Pienaar


- Original Message -
> From: "aabed" 
> To: puppet-users@googlegroups.com
> Sent: Saturday, June 16, 2012 5:14:40 PM
> Subject: [Puppet Users] optimize performance
> 
> hey all
> 
> 
> is there any way i can make puppet run faster
> it takes 8 seconds just to load facts and cache catalog
> 
> 
> 
> Loading facts in /var/lib/puppet/lib/facter/puppet_url.rb
> Loading facts in /var/lib/puppet/lib/facter/root_home.rb
> Loading facts in /var/lib/puppet/lib/facter/doc_url.rb
> Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb
> 
> 
> those four facters takes a lot of time how can i make it faster?

these are all custom facts probably written in house by your staff
or in modules you downloaded, they're not part of puppet so you
should look at what they do.

Except the last one which I wrote :) It's fast but it enables people
to dump all sorts of sources for facts in there and your previous
message made me think that what you have in there is quite slow.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: Correct way to handle node-specific variable values in puppet 2.7

2012-06-19 Thread R.I.Pienaar


- Original Message -
> From: "Jon Schewe" 
> To: puppet-users@googlegroups.com
> Sent: Tuesday, June 19, 2012 1:13:09 PM
> Subject: Re: [Puppet Users] Re: Correct way to handle node-specific variable 
> values in puppet 2.7
> 
> Right now I'm referencing the variable as "<%= ldap_server %>" and
> puppet is complaining on startup about dynamic scoping and telling
> me this will break. So clearly this isn't the way to go otherwise I
> wouldn't have the warning.

I think this warning is gone in a slightly newer version of 2.7.x

what version are you on?

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



[Puppet Users] Re: facter plugin requires cause catalog failure, prevent setting up new clients

2012-06-19 Thread R.I.Pienaar


- Original Message -
> From: "Jo Rhett" 
> To: puppet-users@googlegroups.com
> Cc: r...@devco.net
> Sent: Wednesday, June 20, 2012 12:05:47 AM
> Subject: facter plugin requires cause catalog failure, prevent setting up new 
> clients
> 
> There's a generic problem that I suspect that many people are bumping
> into, but I suspect it will surprise others. RIP's concat module
> includes a facter plugin which is required for the catalog to
> compile. This requires pluginsync to be enabled.
> 
> 
> Problem is when you have a brand new client, they need to get the
> puppet config which enables pluginsync before this is going to work.
> You've got stages and such set up to do all this before the module
> which uses concat is called, but it will fail compilation. Even if
> you try to limit the catalog with tags, it still needs to compile.

Just enable pluginsync from your bootstrap, its not hard and really everyone
else manages just fine, 

AFAIK its also on by default now. 

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] facter plugin requires cause catalog failure, prevent setting up new clients

2012-06-19 Thread R.I.Pienaar


- Original Message -
> From: "Jo Rhett" 
> To: puppet-users@googlegroups.com
> Sent: Wednesday, June 20, 2012 12:26:48 AM
> Subject: Re: [Puppet Users] facter plugin requires cause catalog failure, 
> prevent setting up new clients
> 
> 
> 
> On Jun 19, 2012, at 4:13 PM, R.I.Pienaar wrote:
> 
> 
> Just enable pluginsync from your bootstrap, its not hard and really
> everyone
> else manages just fine,
> 
> 
> Um, the bootstrap won't run if the catalog doesn't compile. That's
> the problem.
> 

catalog compile happens *after* pluginsync so if you enable it, it will
fetch the plugins then request catalog with the new fact attached.

by bootstrap i mean kickstart or whatever, ie. before you run puppet.

> AFAIK its also on by default now.
> 
> 
> Nope. If it was we wouldn't have this problem. Enabling it is obvious
> since we see facter plugins provided by other modules come down.
> 

ah not released yet, looks like that will be only default from 3 onward

Please dont send HTML mail.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] facter plugin requires cause catalog failure, prevent setting up new clients

2012-06-20 Thread R.I.Pienaar


- Original Message -
> From: "Felix Frank" 
> To: puppet-users@googlegroups.com
> Sent: Wednesday, June 20, 2012 9:03:48 AM
> Subject: Re: [Puppet Users] facter plugin requires cause catalog failure, 
> prevent setting up new clients
> 
> On 06/20/2012 01:34 AM, Jo Rhett wrote:
> > 
> >> by bootstrap i mean kickstart or whatever, ie. before you run
> >> puppet.
> > 
> > I should have some other system that configures my system before I
> > run
> > the software to configure my system? ;-)
> 
> Humm, I believe it's fair to assume that "most people" have some way
> of puppet provisioning that will be able to take care of this
> configuration detail.
> 
> That being said, I concur that it would be sane design to allow a
> module to compile in the absence of the custom facts etc. it may deploy to
> agents during the first run.

I agree but its also quite hard, the proposed fix is using the masters
vardir location as default for where servers must put their snippets, this
is ridiculous and not a usable fix.

There is no default really for where nodes put their vardir, we can assume
/var/lib/puppet or something but that just doesn't hold true always and
will in those cases just fail again during a run.

Pluginsync is well understood and so widely used that I think more or less
everyone has figured out how to enable it either first run or use a first
run environment that bootstraps puppet - though how you would do that without
the ability to edit the config file is a good question.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Custom facts and hyphens

2012-06-20 Thread R.I.Pienaar


- Original Message -
> From: "Steph Gosling" 
> To: puppet-users@googlegroups.com
> Sent: Wednesday, June 20, 2012 1:20:12 PM
> Subject: [Puppet Users] Custom facts and hyphens
> 
> Hi all,
> 
> Possibly related to http://projects.puppetlabs.com/issues/10146 but I
> wanted to get a second opinion.
> 
> I have a custom fact that iteratse through the disks on a
> given EC2 node and creates facts for block devices based on
> their /dev/disk/by-path/ links. I had to come up with this as a
> work-around for an existing RH bug in which a kernel upgrade can
> magically move block device names and terminally break an awful lot.
> Anyway, the fact is simple, produces output like this:
> 
> xen-vbd-2049 => /dev/xvda1
> xen-vbd-2050 => /dev/xvda2
> xen-vbd-2051 => /dev/xvda3
> 
> Those facts in conjunction with a virtual resource like this:
> 
> @disks::virtual::setlabel { "root":
> 
> devicename => "$::xen-vbd-2049",
> devicelabel=> "root",
> 
> }
> 
> lets me work around the problem on first run regardless whether that
> block device is called /dev/xvda1, /dev/xvdf1, /dev/foobarbaz1 or
> whatever
> after a reboot.
> 
> Anyway, this worked certainly in Puppet <= 2.7.14 but now breaks in
> .16
> and .17. It does appear to be variable related as the exec that is
> called by the realize is this:
> 
> debug: Exec[e2label -vbd-2049 root](provider=posix): Executing check
> 'test -e -vbd-2049'
> 
> so clearly the variable isn't being treated correctly. I tried $::
> {xen-vbd-2049} but no dice there.
> 
> Are hyphens now officially bad practice? I have a nagging half-memory
> that I read that they're not good in facts, indeed all of the normal
> facts are underscore'd but I can't remember where I read it.

They've always been a bad idea, used to be documented to be supported for
a short while but they never worked well, I think the agreement is that 
they will just not be allowed soon in any variable or class name

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] How to iterate over an array? (with a counter)

2012-06-20 Thread R.I.Pienaar


- Original Message -
> From: "James Patterson" 
> To: puppet-users@googlegroups.com
> Sent: Wednesday, June 20, 2012 10:39:02 PM
> Subject: [Puppet Users] How to iterate over an array? (with a counter)
> 
> Given an array, I'd like to iterate over it with a counter to produce
> something like this from a template:
> 
> foo.0 = ARRAYVALUE0
> foo.1 = ARRAYVALUE1
> foo.2 = ARRAYVALUE2
> 
> (where ARRAYVALUEn is replaced by the value, and the foo.n is
> incremented for each value)
> 
> The puppet templates support iteration, but I don't see how to also
> increment a counter to get the behaviour above? Is this possible?
> Thanks.

array.each_with_index do |item, index|
   ...
end

item will be each item and index will increment from 0 upward

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] How to iterate over an array? (with a counter)

2012-06-21 Thread R.I.Pienaar


- Original Message -
> From: "James Patterson" 
> To: puppet-users@googlegroups.com
> Sent: Thursday, June 21, 2012 7:31:58 AM
> Subject: Re: [Puppet Users] How to iterate over an array? (with a counter)
> 
> On Wed, Jun 20, 2012, at 10:42 PM, R.I.Pienaar wrote:
> > 
> > 
> > - Original Message -
> > > From: "James Patterson" 
> > > To: puppet-users@googlegroups.com
> > > Sent: Wednesday, June 20, 2012 10:39:02 PM
> > > Subject: [Puppet Users] How to iterate over an array? (with a
> > > counter)
> > > 
> > > Given an array, I'd like to iterate over it with a counter to
> > > produce
> > > something like this from a template:
> > > 
> > > foo.0 = ARRAYVALUE0
> > > foo.1 = ARRAYVALUE1
> > > foo.2 = ARRAYVALUE2
> > > 
> > > (where ARRAYVALUEn is replaced by the value, and the foo.n is
> > > incremented for each value)
> > > 
> > > The puppet templates support iteration, but I don't see how to
> > > also
> > > increment a counter to get the behaviour above? Is this possible?
> > > Thanks.
> > 
> > array.each_with_index do |item, index|
> >...
> > end
> > 
> > item will be each item and index will increment from 0 upward
> > 
> 
> Excellent stuff! Just what I wanted!
> 
> If I wanted to sort numerically, backwards, skip numbers, do ($i=0;
> $i<100; $i+2), etc, where should I read about that?

The best place to look is the ruby docs for Array[1] and Enumberable[2]
these are the methods available to you.

Getting used to how ruby does loops and stuff can be a bit weird, it
has a for loop but not one that lets you easily tweak the itteration
count etc, you'd probably do that with a while or until for best 
readability to people who dont know ruby very well.

http://www.tutorialspoint.com/ruby/ruby_loops.htm

[1] http://www.ruby-doc.org/core-1.9.3/Array.html
[2] http://www.ruby-doc.org/core-1.9.3/Enumerable.html

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Custom facts and hyphens

2012-06-21 Thread R.I.Pienaar


- Original Message -
> From: "Felix Frank" 
> To: puppet-users@googlegroups.com
> Sent: Thursday, June 21, 2012 10:18:50 AM
> Subject: Re: [Puppet Users] Custom facts and hyphens
> 
> On 06/21/2012 12:30 AM, Jo Rhett wrote:
> > I'm not saying that you're wrong, but I'm still struggling to see
> > this.
> > Every place that class names are used should be single quoted,
> > according
> > to your style guide. And it's very easy in a syntax to tell the
> > different between 'test-jo + 2' and 'test - jo + 2'. Those are not
> > ambiguous.
> 
> I beg to differ:
> 
> $value = 1
> $value-2 = 2
> $sum = $value-2 +2
> 
> As for class names - I don't really care one way or the other. It's
> been deprecated for so long that we rid our manifests of dashes in class
> names very early.

You probably should as class names are variable names $foo::bar vs $foo-foo::bar

> The limitation seems consistent with the PHP-like syntax, though (is
> it heresy to say this?;)

Also ruby, and this is significant, allowing people to make variable
names that they cannot use in a template is not doing them any favours
as it force them to do scope.lookupvar("foo-foo").

In the 0.24 days -'s were documented as not supported but they worked in
a few scenarios and others they didn't.  I requested then that the
parser fail on -'s but instead the docs were updated and a cycle of bug
fixes around "-" in varnames started.  This went on for countless
releases and while trying to get this to work everywhere there was this
multi year flip flop between sets of bugs with ever changing behaviour
making even small dot release upgrades a nightmare where old templates
and code suddenly produce different results.  To the point where I ended
up writing a widely used tool to diff 2 catalogs to highlight any
differences in content of files etc.

I do not think this has done anyone any favours so I very much welcome
the change if it means more certainty and stability.  I only wish the
change didnt get introduced in a release this late in 2.7.x

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: Reducing system load

2012-06-21 Thread R.I.Pienaar


- Original Message -
> From: "Len Rugen" 
> To: puppet-users@googlegroups.com
> Sent: Thursday, June 21, 2012 5:02:37 PM
> Subject: Re: [Puppet Users] Re: Reducing system load
> 
> Some thoughts from our similar environment:
> 
> 
> 1. Puppet client runs are like bugs and a light, they will tend
> to cluster together. If some client runs are slow, other clients
> wait, over time, they all end up trying to run at the same time.
> This was easily observed on the foreman "run distribution over
> the last 30 minutes" We solved by restarting the client puppet
> service weekly and using the splay option.

is this really still happening? I thought that got fixed ages ago

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Using generate() to mine a shadow file hash

2012-06-25 Thread R.I.Pienaar


- Original Message -
> From: "Rob B." 
> To: puppet-users@googlegroups.com
> Sent: Monday, June 25, 2012 2:52:51 PM
> Subject: Re: [Puppet Users] Using generate() to mine a shadow file hash
> 
> 
> Hey Christopher,
> 
> Thanks for the reply. I will give this a try this morning. As for
> your question about why we want to mine it, we want to change the
> root password in out password manager software, have that change the
> root password on the puppet master, and then have puppet distribute
> the hash everywhere. It makes it easy to keep a single root for all
> the systems we want it to manage.

quite sure this wont work, the puppet master does not run as root and so
your generate wont have access to read shadow file.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Using generate() to mine a shadow file hash

2012-06-25 Thread R.I.Pienaar


- Original Message -
> From: "R.I.Pienaar" 
> To: puppet-users@googlegroups.com
> Sent: Monday, June 25, 2012 2:53:45 PM
> Subject: Re: [Puppet Users] Using generate() to mine a shadow file hash
> 
> 
> 
> - Original Message -
> > From: "Rob B." 
> > To: puppet-users@googlegroups.com
> > Sent: Monday, June 25, 2012 2:52:51 PM
> > Subject: Re: [Puppet Users] Using generate() to mine a shadow file
> > hash
> > 
> > 
> > Hey Christopher,
> > 
> > Thanks for the reply. I will give this a try this morning. As for
> > your question about why we want to mine it, we want to change the
> > root password in out password manager software, have that change
> > the
> > root password on the puppet master, and then have puppet distribute
> > the hash everywhere. It makes it easy to keep a single root for all
> > the systems we want it to manage.
> 
> quite sure this wont work, the puppet master does not run as root and
> so your generate wont have access to read shadow file.
> 


you could use sudo of course, but it doesnt seem like a great idea :)

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] access "indexed" facter facts

2012-06-26 Thread R.I.Pienaar


- Original Message -
> From: "tobias" 
> To: puppet-users@googlegroups.com
> Sent: Tuesday, June 26, 2012 1:52:48 PM
> Subject: [Puppet Users] access "indexed" facter facts
> 
> Hi everyone,
> 
> I have a fact which looks like that: drbdconnectionstate0. You see
> the "0" at the end... Now I'd like to access this fact in a
> "dynamic" way, the "0" should be variable. I'm thinking of something
> like that: if ${drbdconnectionstate0}${drbddevice} ==
> 'Unconfigured'.
> But as you may guess, this does not work... Has anyone an idea how I
> can use such a "dynamic" facter variable?
> 
> Thanks for every help!

The puppetlabs-stdlib module has a getvar() function:

$x = getvar("${drbdconnectionstate0}${drbddevice}")

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: error after upgrading from 2.7.14-2puppetlabs1 to 2.7.17-1puppetlabs1

2012-06-28 Thread R.I.Pienaar


- Original Message -
> From: "Erik Dalén" 
> To: puppet-users@googlegroups.com
> Sent: Thursday, June 28, 2012 9:42:43 AM
> Subject: Re: [Puppet Users] Re: error after upgrading from 
> 2.7.14-2puppetlabs1 to 2.7.17-1puppetlabs1
> 
> On 28 June 2012 02:00, Jeff McCune  wrote:
> > On Wed, Jun 27, 2012 at 3:36 PM, llow...@oreillyauto.com
> >> I had originally thought that 3.X would be the change where it
> >> went from
> >> warning to error, but it looks like they pushed this out with
> >> 2.7.17 for
> >> whatever reason.
> >
> > It was never a deprecation warning as far as I can tell.  2.6.16
> > errors out, as does 2.6.7 and 2.6.12.  2.7.0 and 2.7.1 did error
> > out.
> > 2.7.3 didn't error out for whatever reason and this was the point
> > we
> > accidentally regressed to allowing hyphens in variable names.  This
> > allowance remained all the way through 2.7.14.  In 2.7.16 we
> > "fixed"
> > it again to error out with hyphens in variable names.  This
> > remained
> > in 2.7.17.
> >
> > So, I think the story is...  Don't use hyphens in variable names
> > (and
> > class names).  We accidentally allowed them from 2.7.3 through
> > 2.7.14
> > but we've gone back to it being an error.
> >
> 
> But it is only dashes in variables that produce errors in 2.7.16+,
> right? I know they are deprecated in class names as well, but they have
> worked in them for the most part since 0.24.x releases at least
> AFAIK. Ofc if they aren't allowed in variable names you shouldn't be able to
> refer to variables in classes with dashes, like
> $class-name::variable.
> 
> We unfortunately still have some classes with dashes in the names but
> no variables, so I want to know if it is safe to upgrade to 2.7.17?

It does unfortunately still allow - in class names, I think the fix for
this was half baked as you couldn't access variables in those classes
from outside of the class

docs says:

"Class names, module names, and the names of defined and custom resource
types should be restricted to lowercase alphanumeric characters and
underscores, and should begin with a lowercase letter; that is, they
should match the expression [a-z][a-z0-9_]*. Although some names that
violate these restrictions currently work, using them is not
recommended."

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] hiera questions

2012-06-28 Thread R.I.Pienaar


- Original Message -
> From: llow...@oreillyauto.com
> To: puppet-users@googlegroups.com
> Sent: Thursday, June 28, 2012 7:59:50 PM
> Subject: [Puppet Users] hiera questions
> 
> I'm starting to use hiera more, to try to clean up and better
> modularize some of our stuff.
> 
> I know you can use various facts (such as $::hostname) when defining
> the hierarchy and where to look.
> 
> We have a few variables that are set based on patterns of hostname,
> and currently we have a selector that matches the hostname against a
> regex.
> 
> Is there a clean way to move this to hiera? A straight %{hostname} in
> the hiera.yaml won't work, since then I'd have to create a .yaml per
> hostname and it'd be a hassle to
> 
> Say I have the hostnames setup like: "prefix-purpose-[A-Z]-[0-9]+"
> where prefix is a fixed value across all names, purpose describes
> whether it is a web server, app server etc.
> 
> I'd like to be able to specify things for a given
> "prefix-purpose-[A-Z]" range as well as on a "prefix-purpose" basis.
> 
> I do hope what I am asking is clear, if not I apologize.

I would make facts on the nodes for these.  Let say $role and $subrole
and then just use those in your hierarchy with %{role} and %{subrole} 
thus allowing you to set variable for all those machines there.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Optional template files?

2012-06-29 Thread R.I.Pienaar


- Original Message -
> From: "GriffaA10" 
> To: puppet-users@googlegroups.com
> Sent: Friday, June 29, 2012 3:37:29 PM
> Subject: Re: [Puppet Users] Optional template files?
> 
> Great, that's done the trick, thanks
> 
> Just one thing to note. file() takes an absolute file path (i.e.
> /etc/puppet/modules/snmp/templates/snmpd.conf.erb). Spent a few
> minutes trying to figure out the error I was getting before finally
> RTFM.

indeed, not ideal especially with environments.

Ages ago I wrote a little function to bring to template() the same behaviour
as source => [] I dont know if it still works on modern puppet but it
was handy

http://p.devco.net/27/

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Ruby custom fact question/problem

2012-06-29 Thread R.I.Pienaar


- Original Message -
> From: llow...@oreillyauto.com
> To: puppet-users@googlegroups.com
> Sent: Friday, June 29, 2012 9:05:53 PM
> Subject: [Puppet Users] Ruby custom fact question/problem
> 
> I originally started this post to ask about one problem, but in the
> process of getting the question written I learned that it was due to
> differences between 1.8.7 and 1.9.2 that had caused my problem, so I
> got that fixed.
> 
> I now have the fact successfully loading when I run puppet:
> 
> info: Loading facts in /var/lib/puppet/lib/facter/node_id.rb
> 
> However, when I run facter, I can't find node_id.
> 
> facter | grep node
> No LSB modules are available.
> 
> 
> Is there another step I am missing? Also, one thing I didn't
> understand (and so may have done wrong) is how the actual fact gets
> set. Is it simply the last variable/string used in the code?
> 

You have to pass -p or --puppet to facter on the cli to make it 
aware of facts copied out using puppet pluginsync

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



[Puppet Users] Re: Announce: 2.6.9 Released

2011-06-22 Thread R.I.Pienaar
Just wanted to follow up and say thanks for the improvement to the 
release notes after the recent thread, much more useful now!

- Original Message -
> 
> = 2.6.9 =
> 
> 2.6.9 is a maintenance release in the 2.6.x branch.
> Notable Fixes and Features
> 
> Bug #7127:
> 
> A puppet run will now stop if a prerun command fails.
> 
> Bug #650
> 
> Puppet will now honor symlinks for configuration directories
> 
> Feature #2128
> 
> Added support for hostname setting based on facts, also get facts
> before retrieving the catalog.
> 
> Bug #7139
> 
> Accept ‘/’ as a valid path in filesets
> 
> 
> CHANGELOG
> 
> 2.6.9
> 
> 98ba407 (#7127) Stop puppet if a prerun command fails
> 6996e0b Do not needlessly create multiple reports when creating a
> transaction
> caca469 (#4416) Ensure types are providified after reloading
> 413b136 (#4416) Always remove old provider before recreating it
> 98f58ce (#2128) Add WARNING for node_name_{fact,value} descriptions
> d9b5c1a (#2128) In-line docs for node_name_{fact,value}
> 3f0dbb5 (#650) Allow symlinks for configuration directories
> 1c70f0c (#2128) Add support for setting node name based on a fact
> c629958 (#2128) Get facts before retrieving catalog
> cd4fe14 (#2128) Add the ability to specify a node name
> 16b2311 (#6885) puppet agent fingerprint requires --verbose to return
> a value.
> 75e2764 (#5318) Always notice changes to manifests when compiling.
> 8b76be3 (#3836) External nodes should only capture stdout
> 90eb937 (#7139) Accept '/' as a valid path in filesets
> 729336e (#6845) Mount writes incorrect vfstab entries
> 16cf1ac (#6442) Be able to start agents --listen without
> namespaceauth.conf
> 0352402 (#3420) Nagios "name" attribute does not output correctly
> f656818 (#4487) When setting environment on a host, ensure it is a
> string.
> c306db2 (#6487) Add some testing for OS X version support in
> DirectoryService provider
> 0008b63 (#6487) Directoryservice provider will fail in future OS
> releases
> 6b18f8f Move acceptance tests from puppet-acceptance repo
> 9a5bf6e Fixed #7166 - Replaced deprecated stomp "send" method with
> "publish"
> 656eff8 (#4655) Allow stage to be set using a default class parameter
> 7f658e6 vim: Initial ftplugin and indent support
> ccbe9f3 Fixed #6681 - Remove --force-yes option from aptitude is used
> 
> --
> You received this message because you are subscribed to the Google
> Groups "Puppet Announce" group.
> To post to this group, send email to
> puppet-annou...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-announce+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-announce?hl=en.
> 
> 

-- 
R.I.Pienaar

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: Using Mcollective with Enterprise Ruby

2011-06-28 Thread R.I.Pienaar
you are using the RPMs? what version and what have you installed.

plugins.d is not where plugins go it would be /usr/share/mcollective
of /usr/libexec/mcollective depending on distro etc

- Original Message -
> As I've gotten to the point of configuring server.cfg and client.cfg,
> based on the documentation in Pro Puppet (which also references use
> of
> RPMs), it seems we have some configuration issues -- perhaps about
> standards of where things need to be located.
> 
> The book refers to a non-existent directory, /usr/share/mcollective/
> plugins.  The RPMs create /etc/mcollective/plugin.d (empty).   Thus,
> when you start the server, it fails with the following errors:
> 
> 
> E, [2011-06-28T16:16:19.419481 #25040] ERROR -- : pluginmanager.rb:
> 111:in `loadclass' Failed to load Mcollective::Facts::Yaml_facts:
> no such file to load -- mcollective/facts/yaml_facts.rb
> E, [2011-06-28T16:16:19.419708 #25040] ERROR -- : pluginmanager.rb:
> 111:in `loadclass' Failed to load Mcollective::Connector::Stomp: n
> o such file to load -- mcollective/connector/stomp.rb
> E, [2011-06-28T16:16:19.419891 #25040] ERROR -- : pluginmanager.rb:
> 111:in `loadclass' Failed to load Mcollective::Security::Psk: no s
> uch file to load -- mcollective/security/psk.rb
> E, [2011-06-28T16:16:19.420036 #25040] ERROR -- : pluginmanager.rb:
> 111:in `loadclass' Failed to load Mcollective::Registration::Agent
> list: no such file to load -- mcollective/registration/agentlist.rb
> I, [2011-06-28T16:16:19.420433 #25040]  INFO -- : mcollectived:31 The
> Marionette Collective 1.2.0 started logging at info level
> 
> 
> I could be mistaken.  What's missing?
> 
> 
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
> 
> 

-- 
R.I.Pienaar

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: Using Mcollective with Enterprise Ruby

2011-06-30 Thread R.I.Pienaar


- Original Message -
> Where is the plugins directory supposed to be installed/located?

on redhat, /usr/libexec/mcollective/mcollective/agent, application, etc.

this differs between distros based on whatever the distro policies have
to say etc.

A detailed install guide for plugins exist that explains how it works:

http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/InstalingPlugins

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Definition parameter defaulting to the definition's own $title?

2011-07-15 Thread R.I.Pienaar


- Original Message -
> Hi,
> 
> Maybe I'm going nuts, but I could have sworn reading about a trick or
> new feature which allowed to have a definition parameter get a
> default value of the definition's own $title (instead of having the hack
> around the limitation with selectors and intermediate variables later on).

try $name, that should do it, came in somewhere mid 2.6.x series

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: puppet custom fuction run as user pupprt?

2011-07-15 Thread R.I.Pienaar


- Original Message -
> 
> 
> On Jul 14, 11:57 am, PBWebGuy  wrote:
> > You bring up a good point and I wanted to ask this question
> > anyways.
> > To the best of my knowledge, functions run on the master and facts
> > run
> > on the node.  If that is the case, it perplexes me that functions
> > get
> > sync'd to the node in the /var/lib/puppet/lib... directory.  That
> > is
> > unless functions can then be used in a fact which is something that
> > I
> > have yet to test.  Do you have any clarification?
> 
> 
> If you want an authoritative answer, then the question might be
> better
> posed on the dev list.
> 
> I speculate, however, that functions in modules are synced to nodes
> as a harmless side effect of the overall plugin sync mechanism.  Since
> they *are* synced to nodes, it should be possible to use them (their
> Ruby implementations, that is) in custom facts.  But again, the kinds
> of things you want a Puppet function for tend to be quite different
> from the kinds of things you want a fact for, so the likelihood that
> such a capability would be useful seems small.

they are also usable in running manifests using puppet apply on nodes.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Extlookup() Docs

2011-08-03 Thread R.I.Pienaar


- Original Message -
> So the new extlookup that can apparently read YAML files, here:
> 
> 
> http://www.devco.net/archives/2011/05/28/pluggable_extlookup_for_puppet.php
> 
> 
> Are there any docs on how to actually install? I need a _little_ more
> than a reference to the source code on github
> 

its not in puppet core and probably wont be, a more complete system is @ 
http://www.devco.net/archives/tag/hiera

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Extlookup() Docs

2011-08-03 Thread R.I.Pienaar


- Original Message -
> 
> On Wed, Aug 3, 2011 at 10:21 AM, R.I.Pienaar < r...@devco.net > wrote:
> 
> 
> 
> 
> 
> 
> 
> - Original Message -
> > So the new extlookup that can apparently read YAML files, here:
> > 
> > 
> > http://www.devco.net/archives/2011/05/28/pluggable_extlookup_for_puppet.php
> > 
> > 
> > Are there any docs on how to actually install? I need a _little_
> > more
> > than a reference to the source code on github
> > 
> 
> its not in puppet core and probably wont be, a more complete system
> is @ http://www.devco.net/archives/tag/hiera
> 
> 
> 
> 
> I realise it's not integrated into puppet. Hence the reason for
> asking how to integrate into puppet. In the previous version of
> extlookup, before that one was integrated into puppet, you would
> copy extlookup.rb to a path on the client. How do you do it with
> this one?

you can pluginsync out the extlookup.rb but the util/* stuff has to
be copied into the ruby libdir cos pluginsync is broken/incomplete

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Extlookup() Docs

2011-08-03 Thread R.I.Pienaar


- Original Message -
> 
> > 
> > its not in puppet core and probably wont be, a more complete system
> > is @ http://www.devco.net/archives/tag/hiera
> > 
> > 
> > 
> > 
> > I realise it's not integrated into puppet. Hence the reason for
> > asking how to integrate into puppet. In the previous version of
> > extlookup, before that one was integrated into puppet, you would
> > copy extlookup.rb to a path on the client. How do you do it with
> > this one?
> 
> you can pluginsync out the extlookup.rb but the util/* stuff has to
> be copied into the ruby libdir cos pluginsync is broken/incomplete
> 
> 
> 
> 
> 
> 
> 
> Thanks, but...
> 
> 
> I have no idea what 'pluginsync out the extlookup.rb' stuff' means...
> 
> 
> Not really sure about what the rest of that statement means either...

A simple google search for 'puppet pluginsync' suggests that this is 
incredibly well documented.

Maybe you just didn't try to help yourself first before asking others 
to spoon feed you?

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Extlookup() again.

2011-08-03 Thread R.I.Pienaar


- Original Message -
> Argh, just realized I left something out of those paths, should be:


This all works exactly as extlookup also worked, nothing new there.

The general behavior is well documented even in the Puppet core docs

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Extlookup() again.

2011-08-03 Thread R.I.Pienaar


- Original Message -
> Ok, so am I getting 'DougBobBill' when I use $test_var =
> extlookup('testkey', '---', 'settings') on this file?

how are you examining this value?

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Does Node Inheritance work for people?

2011-08-05 Thread R.I.Pienaar


- Original Message -
> On 08/05/2011 09:33 AM, Nigel Kersten wrote:
> > We have a bunch of problems people regularly run into with node
> > inheritance, and it's something we'd like to find a better solution
> > for.
> >
> Let me guess:
> 
>  - nodes are not classes
>  - node scope is not global scope
> 
> Is there something else that trips people up?

node default {
  $foo = 1

  notify{$foo: }
}

node foo inherits default {
  $foo = 2
}

this will print 1, inheritance is badly designed since this is a common pattern 
 

But also now I think $foo should be considered a top level variable in 2.7
when its not, making node variables more or less useless.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Dynamic lookup of $var

2011-08-18 Thread R.I.Pienaar


- Original Message -
> On 8/18/2011 12:08 PM, Gary Larizza wrote:
> > On Thu, Aug 18, 2011 at 9:06 AM, Darren Chamberlain
> >  wrote:
> > > $operatingsystem is a facter variable, of course.  How are these
> > > supposed to be referenced?
> >
> > They're referenced like this:  $::operatingsystem
> 
> This works, thanks.
> 
> While I haven't tested using facts in templates yet,
> http://blog.penumbra.be/2011/08/dynamic-lookup-is-deprecated-when-using-facts-in-templates/
> implies that I'm going to have the same problem there, as well.
>  Tom's solution is really unwieldy, though, and having to create local
> variables for every fact in every class that calls a template is
> going to lead to a lot of problems.

I concur, I think the way this change is exposed in templates is extremely 
user unfriendly, I'm personally avoiding moving to any version of puppet that
force me to lookupvar() every variable use in a template or to create a ton of
in-class variables as suggested

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Puppet Error during Yum execution

2011-08-25 Thread R.I.Pienaar


- Original Message -

> plugins: fastestmirror
> Could not retrieve mirrorlist
> http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=os
> error was
> 12: Timeout on
> http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=os:
> (28, '')

Your machine cant talk to the mirror list.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: Announce: Dashboard 1.2.0 is available now

2011-08-29 Thread R.I.Pienaar


- Original Message -
> 
> On Aug 28, 7:07 am, Toni Birrer  wrote:
> > While I agree that it's annoying that the puppet dashboard doesn't
> > run
> > with the ruby included in RHEL, i suggest you have a look at the
> > Ruby
> > Version Manager (RVM)http://beginrescueend.com/
> > Makes running the latest 1.8.x and 1.9.x versions of Ruby a breeze
> > on
> > any OS you might use.
> >
> > I'm running puppet on hundreds of CentOS 5 hosts using rvm.
> 
> Personally, I wouldn't touch RVM with a ten-foot pole.  For one
> thing,
> I insist on installing software only from native packages.  For
> another, RVM requires manually switching among various Ruby versions
> -- useful for developers, I'm sure, but not so much for running
> system
> software.
> 
> But one could, indeed, package a more recent Ruby oneself.  In this
> particular case, it is likely that the RHEL or CentOS 6 source RPM
> for Ruby 1.8.7 will build with little or no change on CentOS 5.

As has already been done by the CentOS maintainer:

http://centos.karan.org/el5/ruby187/

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Custom Facts

2011-09-02 Thread R.I.Pienaar


- Original Message -
> 
> At the end of the day, this all seems to be a limitation with
> mcollective. It can only read facts from one source, either facter
> or a yaml file. I believe facter is the current source, and people
> have written scripts that rely on that. I can write a custom fact,
> but then the issue becomes that I don't know if it's possible
> for a custom fact written in ruby and dropped into
> $module/lib/puppet can access variables defined in the node.
> 

using the yaml file built by a template method that was linked to
any variables you set at the node level, top scope or in the class
that creates the yaml file is put in the yaml file.

Therefore you can use these files in mcollective filters, so if you
just set variables in the node to do whatever you want they will show
up in the yaml file and be usable.

As the wiki says:

"plus it lets you get any in-scope variables (for example, parameters from your 
external node classifier) available as mcollective filters for free."

http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/FactsFacterYAML

Mcollective thus gets a combination of facts, variables etc all in one
place.  You can even create many yaml files and it will read the lot for
you, one local the node, one by puppet, maybe even with facter -y etc.

and if all this fails, you can trivially write your own fact source that
does whatever you want.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: Custom Facts

2011-09-03 Thread R.I.Pienaar


- Original Message -
> Btw, Rip or anyone, any suggestion on how to sort alphabetically the
> scope variables so that the generated yaml doesn't change at (almost)
> every puppet run?
> 
> content  => inline_template("<%= scope.to_hash.reject { |k,v| k.to_s
> =~ /(uptime_seconds|timestamp|free)/ }.to_yaml %>")

no, unfortunately the usual method for doing this with yaml doesnt work
in puppet, probably because of their yaml not being normal yaml.

http://snippets.dzone.com/posts/show/5811

maybe one of the devs can say, I tried various methods non that I didnt
consider a hack would work.

I also filed a bug to see if certain resources can be excluded from reporting
but this got no love

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] hiera_hash explanation?

2011-09-06 Thread R.I.Pienaar


- Original Message -
> Hi
> I want to create parametrized class with hash parameter from
> hiera .yaml file
> 
> so i got
> hiera.yaml
> backends:  - yaml
>- json
>- puppet
> :hierarchy: - %{host}
> - common
> :json:
> :datadir: /etc/puppet/hiera
> :yaml:
> :datadir: /etc/puppet/hiera
> 
> :puppet:
> :datasource: data
> 
> common.yaml
> ---
>  mailserver:
>   uid: 8
>   gid: 8
> 
> and
> init.pp
> 
> class dovecot($mailserver = hiera_hash("mailserver"))
> {
> notice("${mailserver[uid]}")
> notice("${mailserver[gid]}")
> }
> 
> 
> i cant get values uid,gid from hash $mailserver
> how can i do that?
> or how to better debug why it is not working??

just do hiera("mailserver")

hiera_hash is a special lookup that builds a hash based on data found
at many levels of the hierarchy, if you have a single key with a array
or hash in it, then just look it up with hiera()

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: The require function

2011-09-06 Thread R.I.Pienaar


- Original Message -
> > class platform::common {
> >file {
> >'/etc/somedir':
> >ensure => directory;
> > }
> > 
> > class webapp::common {
> >require "platform::common"
> >file {
> >"/etc/somedir/configfile":
> ># stuff here.
> >}
> > }
> > 
> > When puppet runs, it's trying to apply the file
> > /etc/somedir/configfile _before_ /etc/somedir. This seems to
> > contradict the behaviour the documentation describes.
> 
> Suggest you try this...
> class webapp::common {
>include platform::common
>file {
>"/etc/somedir/configfile":
>require => Class["platform::common"],
># stuff here.
>}
> }

files auto require their parents, it's not even needed to do
the require => or require()

He's not showing actual code, log lines or errors.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: The require function

2011-09-06 Thread R.I.Pienaar


- Original Message -
> 
> 
> That's a feature in newish versions, right?

no, it's been there for ages and ages.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: The require function

2011-09-07 Thread R.I.Pienaar


- Original Message -
> On Sep 6, 8:54 pm, "R.I.Pienaar"  wrote:
> > - Original Message -
> >
> > files auto require their parents, it's not even needed to do
> > the require => or require()
> >
> >
> Could you please explain what exactly does it mean? Cheers!!

Given 2 file resources:

file{"/foo": ensure => directory}
file{"/foo/bar": content => "hello world"}

Puppet knows that it would be dumb to create /foo/bar before /foo
it also knows it would be tedious to add require statements all the
time. 

So it does the right thing, it adds the require statement for you
and you will never have a case where it creates them in the wrong 
order unless you made some mistake.

-- 
R.I.Pienaar

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: The require function

2011-09-07 Thread R.I.Pienaar


- Original Message -
> Thanks for the explanation. It turns out that I already use my stuff
> the very same way, only without understanding the significance.
> 
> Two related question though:
>   a. Does order matter? Like:
> 
>   file{"/foo/bar": content => "hello world"}
>   file{"/foo": ensure => directory}

no it does not,

> 
>   b. Can it be uses the same way across the modules? Like, specifying
> "file{"/foo": ensure => directory}" in module-A and "file{"/foo/bar":
> content => "hello world"}" in module-B?
> 
> Thanks again, in advance. cheers!!

yup

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] DNS Zone serial numbers

2011-09-09 Thread R.I.Pienaar


- Original Message -
> > and the template will include the zone delegation record.  What I'm
> > trying
> > to figure out is how to generate the serial numbers.
> 
> I'd forego the MMDDxxx format and use either UNIX epoch time
> which
> is auto-incrementing anyway, or store an integer counter (in a file)
> and
> increment that each time your zone changes.
> 
> (Do note, though, that if you do move away from MMDDxxx, you'll
>  probably have to "reset" your zones' SOA serial numbers so that
>  slave
>  servers don't miss out on zone transfers. [1].)
> 
> Hope that helps a bit (from the DNS point of view), and I cannot
> really
> give you a good answer from the Puppet-point-of-view.

the puppet problem is if you generate the serial you should only generate
it if the content of the rest of the file changes, this is pretty hard without
a type/provider.

I have some code to increment serials the way you want with mmddxx but 
dont have an immediate answer to how to use that without writing a type

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Facter variable $puppetversion

2011-09-09 Thread R.I.Pienaar


- Original Message -
> 'notice' is a function. It runs on the server. Try using the 'notify'
> resource instead.

but surely those two variables would be based on the facts and not some
master state?

notify would run on the node yes, but the resolution of variable to string
would still happen on the master.

somethings very fishy.


> > (hoping this post doesn't offend Mr Pienaar)

the detailed problem description without the drama is a huge improvement,
thank you

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Facter variable $puppetversion

2011-09-09 Thread R.I.Pienaar


- Original Message -
> On Fri, Sep 9, 2011 at 4:43 PM, Ken Barber 
> wrote:
> > What does:
> >
> > puppet -e 'notice("$puppetversion")'
> >
> > Show on the _client_? I know its probably obvious but you never
> > know.
> >
> 
> Actually, it's not obvious. I didn't know you could do that. Never
> seen it documented anywhere...

> notice: Scope(Class[main]): 2.7.3
> notice: Finished catalog run in 0.21 seconds

if you change the notice() in your manifests to notify{"${puppetversion} on 
${fqdn}":}
and run puppet agent --test on the node, does it still give the wrong version?

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Facter variable $puppetversion

2011-09-09 Thread R.I.Pienaar


- Original Message -
> On Fri, Sep 9, 2011 at 4:50 PM, R.I.Pienaar  wrote:
> >
> >
> > - Original Message -
> >> On Fri, Sep 9, 2011 at 4:43 PM, Ken Barber 
> >> wrote:
> >> > What does:
> >> >
> >> > puppet -e 'notice("$puppetversion")'
> >> >
> >> > Show on the _client_? I know its probably obvious but you never
> >> > know.
> >> >
> >>
> >> Actually, it's not obvious. I didn't know you could do that. Never
> >> seen it documented anywhere...
> >
> >> notice: Scope(Class[main]): 2.7.3
> >> notice: Finished catalog run in 0.21 seconds
> >
> > if you change the notice() in your manifests to
> > notify{"${puppetversion} on ${fqdn}":}
> > and run puppet agent --test on the node, does it still give the
> > wrong version?
> 
> Changing the notice line to:
> notice ("fqdn = ${fqdn}, puppetversion = ${puppetversion}")
> 
> still gives (on the master):
> Sep  9 16:52:09 sv2admin1 puppet-master[14087]:
> (Scope(Class[Puppet::Setup])) fqdn = hproxy10.h.foo.com,
> puppetversion
> = 0.25.5
> 
> I assume you mean't to use notify(), not notify{}  ?

no, i did mean use notify :)

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Facter variable $puppetversion

2011-09-09 Thread R.I.Pienaar


- Original Message -
> On Fri, Sep 9, 2011 at 4:55 PM, R.I.Pienaar  wrote:
> >
> >
> > - Original Message -
> >> On Fri, Sep 9, 2011 at 4:50 PM, R.I.Pienaar  wrote:
> >> >
> >> >
> >> > - Original Message -
> >> >> On Fri, Sep 9, 2011 at 4:43 PM, Ken Barber 
> >> >> wrote:
> >> >> > What does:
> >> >> >
> >> >> > puppet -e 'notice("$puppetversion")'
> >> >> >
> >> >> > Show on the _client_? I know its probably obvious but you
> >> >> > never
> >> >> > know.
> >> >> >
> >> >>
> >> >> Actually, it's not obvious. I didn't know you could do that.
> >> >> Never
> >> >> seen it documented anywhere...
> >> >
> >> >> notice: Scope(Class[main]): 2.7.3
> >> >> notice: Finished catalog run in 0.21 seconds
> >> >
> >> > if you change the notice() in your manifests to
> >> > notify{"${puppetversion} on ${fqdn}":}
> >> > and run puppet agent --test on the node, does it still give the
> >> > wrong version?
> >>
> >> Changing the notice line to:
> >> notice ("fqdn = ${fqdn}, puppetversion = ${puppetversion}")
> >>
> >> still gives (on the master):
> >> Sep  9 16:52:09 sv2admin1 puppet-master[14087]:
> >> (Scope(Class[Puppet::Setup])) fqdn = hproxy10.h.foo.com,
> >> puppetversion
> >> = 0.25.5
> >>
> >> I assume you mean't to use notify(), not notify{}  ?
> >
> > no, i did mean use notify :)
> 
> Ok, using notify{}, the client now says:
> 
> Sep  9 17:13:38 hproxy10 puppet-agent[30537]: 0.25.5 on
> hproxy10.h.foo.com
> Sep  9 17:13:38 hproxy10 puppet-agent[30537]:
> (/Stage[main]/Puppet::Setup/Notify[0.25.5 on
> hproxy10.h.foo.com]/message) defined 'message' as '0.25.5 on
> hproxy10.h.foo.com'

stumped, this is totally f'd up :)

how do you create the node? with an ENC or with node foo {} blocks?

> I know I'll get slammed for asking, but where is the use of notify{}
> in this manner documented? I didn't know you could do that. WHat does
> notify do? As far as the docs are concerned, it's a resource type.

yeah so notice() is a function, functions run on the puppet master and 
so you find them in the syslog or whatever.  They get evaluated at compile
time

But this doesnt help if you wanted to log on the node, or give someone 
running puppetd --test some interactive feedback *on the node*

types and providers are the only thing that really 'runs' on a node, so
notify being a resource means you can emit text to the client side and it
shows what would be the result of the compiled catalog.



-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Facter variable $puppetversion

2011-09-09 Thread R.I.Pienaar


- Original Message -
> On Fri, Sep 9, 2011 at 5:18 PM, Eric Shamow 
> wrote:
> > Notify is a resource, notice() is a function. So notice() is
> > evaluated on the server, whereas notify{} is evaluated on the
> > client.
> >
> > My suspicion is that you somehow have two versions of the client
> > binary hanging around. Perhaps one that is running when you
> > execute "puppet" at the shell, and another running in the
> > background.
> >
> > Per Ken's question - how are you launching Puppet? Is it as a
> > service? Or are you running it from a cron job?
> 
> I know that notice() is a function, and notify{} is a resource. The
> documentation says that much. However, it doesn't really go beyond
> that. The documentation
> provides examples of how to use notify{} to notify another resource
> when it changes, but I don't believe it gives you any indication
> whatsoever that you can use it in a stand alone fashion like this.
> Where is that use documented? How would anyone except the core puppet
> developers know that you could even do this?

I think you are confusing

server{"foo": notify => Service["bar"]}

with the resource called notify that you can see documented here:

http://docs.puppetlabs.com/references/stable/type.html#notify


> 
> I'm launching puppet with 'service puppet restart'. What libraries?
> If you know their names I can search for them.

on the node in question, did you perhaps have a puppet installed by 
rubygem and then later with rpm/deb, or always only used the one method
and upgraded that using the same

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: Facter variable $puppetversion

2011-09-13 Thread R.I.Pienaar


- Original Message -
> On Tue, Sep 13, 2011 at 1:45 AM, Luke Bigum 
> wrote:
> > Err, what is that 0.25-5 doc folder and what RPM owns it?
> >
> > rpm -qf /usr/share/doc/puppet-0.25.5
> >
> > If nothing owns it, you've pretty much proved your system has old
> > Puppet artefacts lying around. Personally I wouldn't trust any of
> > the
> > content in /usr/lib/ruby now. Is this a production system? Anything
> > else use Ruby on it?
> >
> > I'd start to get heavy handed as this point:
> >
> > tar -cvzf /tmp/usrlibruby.tar.gz /usr/lib/ruby (take a backup)
> > yum remove ruby puppet facter (remove all your RPMs)
> > find /usr/lib/ruby (what's left in your Ruby libdir?)
> > locate puppet (again, what's left over, should be almost nothing
> > but /
> > var/lib/puppet, /var/run stuff and config files)
> >
> > Now you could try reinstall and compare your backed up version of
> > /usr/
> > lib/ruby with your new one.
> >
> > On Sep 12, 11:47 pm, Douglas Garstang 
> > wrote:
> >
> >> [root@hproxy11 ~]# locate puppet
> > ...
> >> /usr/share/doc/puppet-0.25.5
> 
> So... this doesn't make sense.
> 
> I just did this on the client:
> 
> rpm --erase puppet
> rpm --erase facter
> find / -name "*facter*" -exec rm -rf {} \;
> find / -name "*puppet*" -exec rm -rf {} \;
> 
> And then reinstalled puppet and facter, cleaned the certs etc, and
> restarted puppet.
> 
> Problem persists...

maybe these rogue files didnt come from rpm? then it wouldnt know to remove
them.

Given how much time has been spent on this, I think you should try and install
a blank from scratch centos box and install the rpms on it and see how that 
rolls.

-- 
R.I.Pienaar

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Software inventory

2011-09-21 Thread R.I.Pienaar


- Original Message -
> its also pretty easy to programatically access the information, which
> could make parsing it easier:
> 
> >require 'puppet'
> >Puppet::Type.type(:package).instances

the puppetral mcollective agent does something similar in a generic fashion
so you can just query the network and gather this info.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] run puppet service type with specific user

2011-09-24 Thread R.I.Pienaar


- Original Message -
> Hi,
> 
> 
> is it possible to use the service resource type with a specific user
> ?
> So that the service is started with that given user instead of the
> puppet user starting it...

puppet runs as root, your rc script should do the right thing and run
the service as the right user

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] run puppet service type with specific user

2011-09-24 Thread R.I.Pienaar


- Original Message -
> Thanks for the reply.
> 
> 
> I modified the rc script to run as a user.
> But now I'm facing the following problem:
> I have to include some nasty puppet code for adding the service
> before i can use the service resource type.
> And the service resource type returns ok, but the service is in fact
> not started.
> When i do it manually, it requires a password for that user.
> So, I tried to manage the user with puppet and provided a password,
> but get the message:
> Provider useradd does not support features manages_passwords; not
> managing attribute password
> I know this is a problem with Puppet and CentOS, but I have
> ruby-shadow and shadow-utils installed on my CentOS 6.0 VM.
> 
> 
> I also don't know if this is going to help with starting the service.
> I want to use the service type to start the service with a specific
> user, but without asking for a password.

you should use su in your script to switch users to the one the service
should run as.

consider what will happen when your server starts up? the rc script runs
and then what? ask you for a password? thats not good.

the rc script has to do what it should without interaction, its not a puppet
problem.

all you should need to do is copy the working rc script into the init.d dir
and use the service resource to enable it and ensure its running.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] issues with puppet service and mco puppetd

2011-09-26 Thread R.I.Pienaar


- Original Message -
> Ok so we are running puppet agent via cron jobs and have the puppet
> agent set to the following:
>service { "pe-puppet-agent":
>  enable => false,
>  ensure => stopped,
>  hasstatus  => true,
>  hasrestart => true,
>   }
> so i need to get something out to all of out servers urgently and
> used MCO to run "mco puppetd runonce -I mycomputer" and that works and
> all, but on the client side that runs "/opt/puppet/bin/ruby1.8
> /opt/puppet/ sbin/puppetd --onetime --splaylimit 120 --splay" which in turns
> starts the puppet agent service and then it reads my manifest and says that
> agent should be stopped. So how can i get MCO to work like i need it
> to, but also not interfere with the "ensure => stopped" of my
> manifest?
> 
> FYI, everytime that i run the MCO command, i get "Caught TERM;
> calling stop", which i am assuming is due to thge fact that it is stopping
> the service.

the RC script is incorrectly reporting any puppet instance as one started using
the RC script, I don't notice this with the opensource RPM distro maybe its 
something
PE specific.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: issues with puppet service and mco puppetd

2011-09-27 Thread R.I.Pienaar


- Original Message -
> OK  so you will have to for give me here. I am not sure what RC
> means, but is what you're saying is that the PE version puppet is likely
> causing the issue?

the script in /etc/init.d (or your OS equivelant) that starts puppet and
is used to check it's status.

if puppet is running - but have not been started using the service - 
then the service script should not report it as running. 

This is with the opensource rpm:

# puppet agent --test

now switch to a different window while that runs:

# service puppet status
puppetd is stopped


yours should do the same

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: issues with puppet service and mco puppetd

2011-09-27 Thread R.I.Pienaar


- Original Message -
> OK here is my output for the different commands with "puppet agent --
> test" running:
> 
> # service pe-puppet-agent status
> * could not access PID file for agent
> 
> # service --status-all | grep puppet
> [ - ] pe-puppet-agent
> 
> # ps aux | grep puppet
> /opt/puppet/bin/ruby1.8 /usr/local/bin/puppet agent --test
> 
> -
> Now when i run "mco puppetd runonce -I " from the puppet
> master here is what i get when i run it again:
> 
> # service pe-puppet-agent status
> * agent is running
> 
> # service --status-all | grep puppet
> [ + ] pe-puppet-agent
> 
> # ps aux | grep puppet
> /opt/puppet/bin/ruby1.8 /opt/puppet/sbin/puppetd --onetime --
> splaylimit 120 --splay

right, that's different my bad should have thought of that difference.

Indeed mine also does report the daemon as running in that case - not sure
what the best approach is, but the rc script should probably not be reporting
that as running, thats the only way you're going to be able to have both 
ensure stopped and and a mcollective triggered run on the same machine

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Foreach loop?

2011-09-29 Thread R.I.Pienaar


- Original Message -
> Hi all,
> 
> One of my facter variables returns an array of disks presently
> connected
> to the system. I want to have something in my manifest that loops
> around
> the array and adds a Nagios check for each disk.
> 
> In perlish pseudocode, I imagine something like this:
> 
> @disks = sda,sdb,sdc
> 
> foreach $disk in @disks {
>  @@nagios_service { "check_disk_${disk}":
>  check_command => "check_disk!${disk}",
>  host_name => "$fqdn",
>  service_description => "Disk ${disk} status",
>  }
> }
> 
>  From what I can gather, a straightforward foreach isn't possible in
> puppet 2.6.6. Is there a workaround or a better way of achieving
> this?

If you made a defined type you can do it.

here's a very simple one that loops an array and create 'notify' resources:

define print {
   notify{"the message is: ${name}": }
}

print{["one", "two", "three"]: }

this would be the same as making these resources by hand:

notify{"the message is: one": }
notify{"the message is: two": }
notify{"the message is: three": }

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Dealing with sensitive data

2011-10-03 Thread R.I.Pienaar


- Original Message -
> Sure, but that doesn't really address the issue (at least not
> out-of-box). Hiera puts your data outside your manifests, but at
> least in our case it's still in revision control. Are you putting
> your Hiera data elsewhere? If so, how do you control access to it?

it would be pretty trivial to create an encrypted hiera backend that
can only be decrypted by machines that have a key stored on their disks.

You'd check into SCM the encrypted file and on your masters store the decrypt
key

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Fwd: FW: Hiera Issue

2011-10-04 Thread R.I.Pienaar


- Original Message -
> 
> 
> Would appreciate any advice, there is not a lot of info on hiera and
> I'm currently stuck not able to perform a puppet run on the client.

That means the puppet parser function isnt installed correctly

> -- Forwarded message --
> From: "Gregory Caldwell" < gregory.caldw...@us.icap.com >
> Date: Oct 3, 2011 3:56 PM
> Subject: FW: Hiera Issue
> To: "Greg Caldwell" < greg.caldwe...@gmail.com >
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> From: Gregory Caldwell
> Sent: Monday, October 03, 2011 3:55 PM
> To: puppet-users@googlegroups.com
> Cc: Gregory Caldwell
> Subject: Hiera Issue
> 
> 
> 
> I keep getting this issue with hiera, and cannot perform a puppet
> run..
> 
> 
> 
> err: Could not retrieve catalog from remote server: Error 400 on
> SERVER: Unknown function hiera_include at
> /etc/puppet/manifests/site.pp:16 on node pup
> 
> 
> 
> hiera run seems to return the correct values but will not allow a
> puppet run
> 
> 
> 
> hiera -a global_classes $args --config /etc/puppet/hiera.yaml –debug
> 
> DEBUG: Mon Oct 03 15:48:35 -0400 2011: Hiera YAML backend starting
> 
> DEBUG: Mon Oct 03 15:48:35 -0400 2011: Looking up global_classes in
> YAML backend
> 
> ["user::accounts::include "]
> 
> 
> 
> Has anyone seen this issue on puppet 2.6.9?
> 
> 
> 
> Portion of site.pp file
> 
> 
> 
> node default {
> 
> $region = extlookup( "value" )
> 
> $hostgroup = extlookup( "value" )
> 
> $site = extlookup( "value" )
> 
> hiera_include( "global_classes" )
> 
> 
> 
> and yaml is:
> 
> 
> 
> ---
> 
> global_classes: - user::accounts::include
> 
> **
> 
> This communication and all or some of the information contained
> therein may be confidential and is subject to our Terms and
> Conditions. If you have received this communication in error, please
> destroy all electronic and paper copies and notify the sender
> immediately. Unless specifically indicated, this communication is
> not a confirmation, an offer to sell or solicitation of any offer to
> buy any financial product, or an official statement of ICAP or its
> affiliates. Non-Transactable Pricing Terms and Conditions apply to
> any non-transactable pricing provided. All terms and conditions
> referenced herein available at www.icapterms.com . Please notify us
> by reply message if this link does not work.
> 
> **
> 
> 
> 
> 
> 
> 
> 
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
> 

-- 
R.I.Pienaar

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Fwd: FW: Hiera Issue

2011-10-04 Thread R.I.Pienaar


- Original Message -
> 
> 
> How do I resolve or troubleshoot this issue? I am running puppet
> 2.6:9 on red hat 5:6 with the following packages:
> 
> rubygem-hiera-0:2:0-1
> rubygem-hiera-puppet-0.2.0-1

I dont believe the hiera_include() function has been released as a
gem yet, you'll need to grab the latest from github.

Don't really have time atm to do a new release that includes it all

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] RFC: Being able to exclude resources from reporting.

2011-10-05 Thread R.I.Pienaar


- Original Message -
> So, my essential point is that if that file did change – and it
> genuinely did – we should report that back, and provide better tools
> to filter it on the server side.  The advantage of filtering on the
> client rather than the server is minimal, given we compress the data
> transmitted, so you are talking about a few bytes of network traffic,
> total.

yes, the main concern isnt that it is or isnt in the report its that its
being reported on, mailed out, shown as red on dashboard etc

ditto for output on --test though that we can shut up generally with the 
loglevel meta parameter

> 
> Would you be equally satisfied if we allowed you to annotate that the
> resource was expected to change every time, and then alerted you only
> if it *didn't* change on a given run?  (...or just never displayed
> that change to you?)

I think there's a lot of files that changes frequently but not always
and it would be worth excluding those so more flexibility would be useful

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



  1   2   3   4   5   6   7   >