AW: [Puppet Users] Undo

2012-04-17 Thread Bernd Adamowicz
I'm not aware of any undo functions in Puppet. I think the only thing you can 
do is do create a proper user configuration for your Suse and Solaris boxes and 
let Puppet fix it.

Bernd

Von: puppet-users@googlegroups.com [mailto:puppet-users@googlegroups.com] Im 
Auftrag von root
Gesendet: Dienstag, 17. April 2012 20:55
An: puppet-users@googlegroups.com
Betreff: [Puppet Users] Undo

So.. I am evaluating Puppet Enterprise 2.5.  I was messing with Live Management 
and I cloned a user account to all my nodes instead of just one.  This 
overwrote the account settings on all my Solaris and SUSE with the account data 
from a RHEL server.  I'd like to know how I would undo this, please.


--
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/bFlN11NuA3sJ.
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.

-- 
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] Case statements in a file directive

2012-04-17 Thread Peter Bukowinski
Looks like you're missing a question mark in the selector in your source 
parameter. It should look like this:

source => $::architecture ? {
 /(i386|i586|i686)/ => "puppet:///files/32/usr/local/nagios/libexec",
x86_64 => "puppet:///files/64/usr/local/nagios/libexec",
}

--
Peter

On Apr 17, 2012, at 7:44 PM, Geoff Davis wrote:

> Yup, I fat-fingered my response.
> 
> On Apr 17, 2012, at 4:10 PM, Denmat  wrote:
> 
>>>  /(i386|i586|i686/) => 
>> should be
>>>  /(i386|i586|i686)/ => 
>> shouldn't it?
>> 
>> Den
>> On 18/04/2012, at 9:01, Forrie  wrote:
>> 
>>> So, it's choking on this still at the line with the conditional:
>>> 
>>> Apr 17 18:58:17 test-system puppet-agent[7590]: Could not retrieve
>>> catalog from remote server: Error 400 on SERVER: Could not parse for
>>> environment production: Syntax error at '{'; expected '}' at /etc/
>>> puppet/manifests/classes/nagios-client-test.pp:20 on node test-
>>> system.my-domain.com
>>> 
>>> The brackets look balanced to me.
>>> 
>>> 
>>>  file { "/usr/local/nagios/libexec":
>>>  require => File['/usr/local/nagios'],
>>>  ensure  => directory,
>>>  owner   => 'root',
>>>  group   => 'root',
>>>  mode=> 655,
>>>  recurse => true,
>>>  source  => $::architecture {
>>>  /(i386|i586|i686/) => "puppet:///files/32/usr/local/
>>> nagios/libexec",
>>>  x86_64 => "puppet:///files/64/usr/local/
>>> nagios/libexec",
>>>  }
>>>  }

-- 
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: Case statements in a file directive

2012-04-17 Thread Geoff Davis
Yup, I fat-fingered my response.

On Apr 17, 2012, at 4:10 PM, Denmat  wrote:

>>   /(i386|i586|i686/) => 
> should be
>>   /(i386|i586|i686)/ => 
> shouldn't it?
> 
> Den
> On 18/04/2012, at 9:01, Forrie  wrote:
> 
>> So, it's choking on this still at the line with the conditional:
>> 
>> Apr 17 18:58:17 test-system puppet-agent[7590]: Could not retrieve
>> catalog from remote server: Error 400 on SERVER: Could not parse for
>> environment production: Syntax error at '{'; expected '}' at /etc/
>> puppet/manifests/classes/nagios-client-test.pp:20 on node test-
>> system.my-domain.com
>> 
>> The brackets look balanced to me.
>> 
>> 
>>   file { "/usr/local/nagios/libexec":
>>   require => File['/usr/local/nagios'],
>>   ensure  => directory,
>>   owner   => 'root',
>>   group   => 'root',
>>   mode=> 655,
>>   recurse => true,
>>   source  => $::architecture {
>>   /(i386|i586|i686/) => "puppet:///files/32/usr/local/
>> nagios/libexec",
>>   x86_64 => "puppet:///files/64/usr/local/
>> nagios/libexec",
>>   }
>>   }
>> 
>> 
>> -- 
>> 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.
>> 
> 
> -- 
> 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.

-- 
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: Case statements in a file directive

2012-04-17 Thread Denmat
>/(i386|i586|i686/) => 
should be
>/(i386|i586|i686)/ => 
shouldn't it?

Den
On 18/04/2012, at 9:01, Forrie  wrote:

> So, it's choking on this still at the line with the conditional:
> 
> Apr 17 18:58:17 test-system puppet-agent[7590]: Could not retrieve
> catalog from remote server: Error 400 on SERVER: Could not parse for
> environment production: Syntax error at '{'; expected '}' at /etc/
> puppet/manifests/classes/nagios-client-test.pp:20 on node test-
> system.my-domain.com
> 
> The brackets look balanced to me.
> 
> 
>file { "/usr/local/nagios/libexec":
>require => File['/usr/local/nagios'],
>ensure  => directory,
>owner   => 'root',
>group   => 'root',
>mode=> 655,
>recurse => true,
>source  => $::architecture {
>/(i386|i586|i686/) => "puppet:///files/32/usr/local/
> nagios/libexec",
>x86_64 => "puppet:///files/64/usr/local/
> nagios/libexec",
>}
>}
> 
> 
> -- 
> 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.
> 

-- 
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: Case statements in a file directive

2012-04-17 Thread Forrie
So, it's choking on this still at the line with the conditional:

Apr 17 18:58:17 test-system puppet-agent[7590]: Could not retrieve
catalog from remote server: Error 400 on SERVER: Could not parse for
environment production: Syntax error at '{'; expected '}' at /etc/
puppet/manifests/classes/nagios-client-test.pp:20 on node test-
system.my-domain.com

The brackets look balanced to me.


file { "/usr/local/nagios/libexec":
require => File['/usr/local/nagios'],
ensure  => directory,
owner   => 'root',
group   => 'root',
mode=> 655,
recurse => true,
source  => $::architecture {
/(i386|i586|i686/) => "puppet:///files/32/usr/local/
nagios/libexec",
x86_64 => "puppet:///files/64/usr/local/
nagios/libexec",
}
}


-- 
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: Having trouble getting puppet to set users/groups to a defined state

2012-04-17 Thread Steve Roberts
On Apr 17, 6:25 am, jcbollinger  wrote:
> On Apr 16, 10:03 pm, Steve Roberts  wrote:
> > I thought one of the key ideas for puppet was the ability to define a
> > manifest and puppet would make the machine look like that manifest.
>
> That is correct.  Another key idea, however, is that Puppet does not
> manage resources that are not declared in the target node's
> manifests.  Yet another is that it avoids doing unusual things without
> specific instruction to do so.  Occasionally two or more of these
> clash.

I follow you and I get it can be a hard problem to get "right"

> In this case, you need to recognize that Puppet identifies groups (and
> users) by their names, just as the OS's tools do.  Indeed, the only
> other alternative, gid (uid) is unsuitable because the OS does not
> require it to be unique.  When you change the name of one of a Group
> declaration in one of your manifests, therefore, that doesn't
> correspond to changing the name field of an existing group record on
> the client.  Instead, it corresponds to managing an entirely different
> group, leaving the other unmanaged.

I follow it is using the useradd utils to manage things andso refs by
name.

> > I checked the group resource documentation and didn't see an option to
> > say 'force' or something.
>
> It is spelled "allowdupe", but it would be better to clean up the mess
> than to make a bigger one.  Add this to your manifest to do so:

well, allowdupe doesn't fix the issue only masks it.  I knew about
taht attribute but
it just adds a duped group instead of making right the user/group.

> group { 'txuser':
>   ensure => 'absent',
>   before  => Group['tuser']
> }

Yes for this specific case it would do it.  and I actually have a tiny
manifest to do just that as I was checking the behavior of this test
case.

> > I'm thinking would also be a problem if someone locally edited /etc/
> > passwd and /etc/group the manifest would also fail.
>
> That is possible.  That general class of problems is one of many
> reasons to avoid sharing management responsibilities for any given set
> of resources among multiple agents (including humans).  If it does
> happen, then the failure is probably good, because it signals admins
> that there is something they need to investigate.

Well, I'm not worried about when the human has been told they can make
changes but rather when a human (or bad tool) makes a change nad it
slips through the cracks initially and goes boom later.

> Puppet also has a mechanism by which you can ensure that otherwise-
> unmanaged resources of some types are all ensured absent.  That's both
> very powerful and very dangerous, and I advise you to avoid it at
> least until you have more experience with Puppet.  To that end, I'm
> leaving it as an exercise to determine just what the mechanism is.

I may have to poke on how puppet does that.  we actually do an
absolute /etc/passwd (and friends) in our current conf man system.
and yes it does have its pitfalls too.

-- 
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] function template: use of variable '$string' = BUG?

2012-04-17 Thread Antidot SAS
Hi everyone,



I am using puppet setup with gem:
--
root@linux-install:/tmp# facter |egrep -i "pupp|lsbdistdescription"


lsbdistdescription => Debian GNU/Linux 6.0.4 (squeeze)
puppetversion => 2.7.9
root@linux-install:/tmp# gem list puppet

*** LOCAL GEMS ***

puppet (2.7.9)
--

I think I found a bug but was not able to see if it was declared, here is
the puppet file:

root@linux-install:/tmp# cat test.pp
$string = 'A bug?
'


$test_var = 'test'

file { '/tmp/bug':
path=> '/tmp/bug',
ensure  => present,
content => template('test.erb'),
}
root@linux-install:/tmp# cat /etc/puppet/templates/test.erb
# puppet file
# Here is a sample
Here is a value: <%= test_var %>
root@linux-install:/tmp# puppet apply test.pp


notice: /Stage[main]//File[/tmp/bug]/ensure: created
notice: Finished catalog run in 0.21 seconds
root@linux-install:/tmp# cat /tmp/bug


A bug?
root@linux-install:/tmp#


Is that normal? Bug?


Regards,
JM

-- 
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: how to get ruby-shadow installed before trying to make users,groups

2012-04-17 Thread Steve Roberts
On Apr 16, 9:52 pm, Paul Hinze  wrote:
> I've run into this too, and worked around it by considering
> ruby-shadow as a "prerequisite" for puppet, and therefore taking
> responsibility for that package up to my bootstrapping scripts. IOW,
> it is one of the short list of packages that need to be there for
> puppet to run successfully. In my case, that means adding it to a
> Debian pre-seed config.
>
> I'd be curious to know if there's any other way to work around
> provider dependencies like these in a cleaner way though.

probably what I am going to end up doing as well.  in my cause just
add to my anaconda list (for physical and VMware based machines) or to
my openVZ post deployment.

-- 
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: how to get ruby-shadow installed before trying to make users,groups

2012-04-17 Thread Steve Roberts
On Apr 17, 7:08 am, Michael Stahnke  wrote:
> Much of this depends on *how* you install puppet.  If you use yum or
> apt, I think shadow is pulled in as a dep (I know it is for rpm).  If
> you use gems, I'm quite sure it's not. If you're on mac or Windows you
> can use the native packages and get password management without
> shadow.
>
> What platforms are you on?

cents5 and rhel5

the EPEL rpms do require ruby-shadow.  but the ones from
yum.puppetlabs.com do not.

we are using the puppetlab ones for two reasons:
1) they are 2.7 (EPEL is 2.6)
2) puppetlabs HIGHLY recommended we go with theirs and not EPEL rpms.

-- 
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: Question regarding multi-OS NTP manifest

2012-04-17 Thread Jesse
Ooops, forgot the default page:

 file { 'default.html':
  path   => "${docu_root}/default.html",
  source => "puppet:///modules/apache2/default.html",
  ensure => file,
  require => Package["$webservice_name"],


-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/dqZp4afWNP4J.
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: Question regarding multi-OS NTP manifest

2012-04-17 Thread Jesse

On Tuesday, April 17, 2012 1:34:02 AM UTC-4, Wil Cooley wrote:
>
> On Apr 15, 4:44 pm, Jesse  wrote: 
>
> > case $operatingsystem { 
> > centos, redhat: { $ntp = "ntp" } 
> > debain, ubuntu: { $ntp = "ntpd" } 
>
> This is backwards; centos/redhat should be 'ntpd' and debian/ubuntu 
> should be 'ntp'. 
>
>
After spending over an hour trying to figure out my mistake, of course I 
notice the errant "d" after I post to the group. Thanks for confirming!
 

> > if $ntp == 'ntp' { 
> >   service { 'ntp': 
> > name   => $ntp, 
> > ensure => running, 
> > enable => true, 
> > hasrestart => true, 
> > hasstatus  => true, 
> >   }} 
> > 
> > else { 
> > service { 'ntpd': 
> >   name   => $ntp, 
> >   ensure => running, 
> >   enable => true, 
> >   hasstatus  => true, 
> >   hasrestart => true, 
> > } 
> >   } 
>
> This conditional is redundant. I think it's better to use one resource 
> name and change the "name" attribute with the variable as you have 
> done (although I would a more explicit variable name like 
> '$ntp_service'): 
>
> service { 'ntp': 
>   name => $ntp_service, 
>   ... 
> } 
>
>  
Thank you, I"ll use that idea in my next manifest. 

 
>
> err: /Stage[main]//Service[ntp]/ensure: change from stopped to running 
> > failed: Could not start Service[ntp]: Execution of '/sbin/service ntp 
> > start' returned 1:  at /root/learning-manifests/ntp.pp:24 
>
> This is because of the reversal I mentioned above; it should be 'ntpd' 
> on CentOS, not 'ntp'. 
>
> > When I run the vanilla script, everything configures correctly and 
> > ntp(d) is started. Why is my second script using /sbin when it seems 
> > that it should be using /etc/init.d/? 
>
> Have you tried 'man service'? '/sbin/service' is a way of running init 
> scripts with a sanitized environment and is the preferred way of 
> running init scripts rather than doing so directly. 
>
> http://linux.die.net/man/8/service


I'll read up on this as well. I've created another manifest based on the 
lesson plan, this time for an Apache install that is OS sensitive, with a 
custom 404 and a generic landing page. I think this part is wrong:

file { '$webservice_name.conf':
  path=> "/etc/${webservice_name}/conf/${webservice_name}.conf",

Since in Debian/Ubuntu it would be

file { '$webservice_name.conf':
  path=> "/etc/${webservice_name}/${webservice_name}.conf",

but I'm not sure how to parse that out. Here's it in entirety (Debian side 
commented out as per the Puppetlabs instructions to test only for EL/CentOS 
or fail):

#init.pp
class httpd {
case $operatingsystem {
  centos, redhat: {
$webservice_name = 'httpd'
$conf_file= '/etc/httpd/conf/httpd.conf'
$docu_root= '/var/www/html'
$404page  = '404page.redhat.centos.html'
  }
  #  debian, ubuntu {
  # $webservice_name = 'apache2'
  # $conf_file= '/etc/apache2/apache2.conf'
  # $docu_root= /var/www/'
  # $404page  = '404page.debian.ubuntu.html'
  #}
  default: { fail("Uncrecognized operatingsystem for webserver")}
  }
package { '$webservice_name'
  ensure => installed,
}
file { '$webservice_name.conf':
  path=> "/etc/${webservice_name}/conf/${webservice_name}.conf",
  source  => "puppet:///modules/apache2/${conf_file}",
  ensure  => file,
  require => Package['$service_name'],
}
service { 'ntp':
  name  => $service_name,
  ensure=> running,
  enable=> true,
  subscribe => File['${webservice_name.conf}'],
}
file { '404page.html':
  path=> '$docu_root/404page.html
  source  => "puppet:///modules/apache2/${404page}",
  ensure  => file,
  require => Package["$webservice_name"],
}
}

I figured I could start another topic, but I didn't want to clutter the 
board.

Cheers!


Jesse

On Tuesday, April 17, 2012 1:34:02 AM UTC-4, Wil Cooley wrote:
>
> On Apr 15, 4:44 pm, Jesse  wrote: 
>
> > case $operatingsystem { 
> > centos, redhat: { $ntp = "ntp" } 
> > debain, ubuntu: { $ntp = "ntpd" } 
>
> This is backwards; centos/redhat should be 'ntpd' and debian/ubuntu 
> should be 'ntp'. 
>
> > if $ntp == 'ntp' { 
> >   service { 'ntp': 
> > name   => $ntp, 
> > ensure => running, 
> > enable => true, 
> > hasrestart => true, 
> > hasstatus  => true, 
> >   }} 
> > 
> > else { 
> > service { 'ntpd': 
> >   name   => $ntp, 
> >   ensure => running, 
> >   enable => true, 
> >   hasstatus  => true, 
> >   hasrestart => true, 
> > } 
> >   } 
>
> This conditional is redundant. I think it's better to use one resource 
> name and change the "name" attribute with the variable as you have 
> done (although I would a more explicit variable name like 
> '$ntp_service'): 
>
> service { 'ntp': 
>   name => $ntp_service, 
>   ... 
> } 
>
>
> > err: /Stage[ma

Re: [Puppet Users] Re: Case statements in a file directive

2012-04-17 Thread Geoff Davis
The $:: business is to force the variable look up to be in the top scope. It 
didn't fix have anything to do with the conditional, I just put it there for 
correctness.

In this case, you are using a variable that is set by facter, so it appears in 
the top scope. Variables that you set yourself can be in the top scope if you 
put them in site.pp, or in a class scope if you declare them inside of a class. 
There's also a node scope.

While referring to variables with explicit scoping is not required in the 
current version of puppet, there are some major upcoming changes to how Puppet 
makes variables available to different parts of your code. You'll most likely 
get a compiler warning if you don't use it in the 2.7 series, and it just won't 
work in the next version of Puppet.

This page on variable scope is worth reading: 
http://docs.puppetlabs.com/guides/scope_and_puppet.html

Geoff Davis
Scripps Institution of Oceanography
gada...@ucsd.edu, (858) 822-5756



On Apr 17, 2012, at 12:31 PM, Forrie wrote:

> Thank you, I appreciate it.Still learning all the interesting
> nuances of this syntax.  I'm not yet familiar with this $::
> 
> 
> -- 
> 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.

-- 
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] Determining if hiera (or any function) is installed on a node

2012-04-17 Thread Geoff Davis
Cool, thanks for the quick response.

In the meantime, it might be helpful to ship a default hiera.yaml in the 
PuppetLabs packages.

I'm using the Vagrant boxes from vstone.eu [1], and he's just pulling your 
Puppet packages from yum.puppetlabs.com. [2]

Version in my VM is:
puppet.noarch   2.7.13-1.el6puppetlabs

[1] http://packages.vstone.eu/vagrant-boxes/
[2] http://packages.vstone.eu/vagrant-boxes/CHANGELOG

Geoff Davis
Scripps Institution of Oceanography
gada...@ucsd.edu, (858) 822-5756



On Apr 17, 2012, at 12:32 PM, Gary Larizza wrote:

> And here's the bug to track --> http://projects.puppetlabs.com/issues/10367
> 
> On Tue, Apr 17, 2012 at 12:31 PM, Eric Shamow  wrote:
> As a +1 on this (and as the guy who wrote safe_hiera) --
> 
> It shouldn't be a function, the safety should be wrapped into hiera.  But 
> yes, this will get you the right syntax so you can just search/replace 
> safe_hiera for hiera once it's fixed.
> 
> -Eric
> 
> -- 
> 
> Eric Shamow
> Professional Services
> http://puppetlabs.com/
> (c)631.871.6441
> 
> On Tuesday, April 17, 2012 at 12:29 PM, Gary Larizza wrote:
> 
>> Hey Geoff,
>> 
>> We actually had a talk about this.  There is this code that will help catch 
>> that scenario FOR NOW -->  https://github.com/puppetlabs/hiera-puppet/pull/23
>> 
>> I believe this is a bug and should DEFINITELY be fixed in source.  Until 
>> then, the 'safe_hiera()' function allows you to make this check.  
>> 
>> 
>> 
>> On Tue, Apr 17, 2012 at 12:21 PM, Geoff Davis  wrote:
>>> Alas that doesn't work as the manifest fails to compile properly without 
>>> the /etc/puppet/hiera.yaml file being there.
>>> 
>>> Nan's code does provide defaults for the hiera lookups similar to what you 
>>> are doing below, but the compiler balks before they are even evaluated.
>>> 
>>> Here's the version of staging/init.pp that generated the error below: 
>>> https://github.com/nanliu/puppet-staging/blob/5e1a8763ae36c2ea21c0a5b6a1f0e586e077f0fd/manifests/init.pp
>>> 
>>> Note that all of the hiera calls have defaults.
>>> 
>>> Geoff Davis
>>> Scripps Institution of Oceanography
>>> gada...@ucsd.edu, (858) 822-5756
>>> 
>>> 
>>> 
>>> On Apr 17, 2012, at 12:14 PM, Gary Larizza wrote:
>>> 
 Hey Geoff,
 
 I see that as two separate steps (Is Hiera enabled and is Hiera 
 configured).  I think the function satisfies the former, but you might 
 want to write your own check for the latter (as each person probably 
 interprets 'configured' differently).  You could do a check like:
 
 if function_available('hiera') and hiera('hiera_enabled', false) {
   
 } else {
   
 }
 
 This would do a hiera lookup for a parameter 'hiera_enabled' that could be 
 set in your common/global.yaml file (while defaulting to false if it's not 
 found).
 
 
 
 On Tue, Apr 17, 2012 at 12:09 PM, Geoff Davis  wrote:
> I've found a potential issue, but I'm not sure if this is within the 
> scope of function_available or not.
> 
> The vagrant basebox I'm using actually does ship with puppet-hiera, but 
> there's no /etc/puppet/hiera.yaml
> 
> Thus, even though function_available('hiera') returns true, the function 
> isn't actually usable:
> 
> Hiera config file /etc/puppet/hiera.yaml not readable at 
> /tmp/vagrant-puppet/modules-0/staging/manifests/init.pp:31 on node 
> centos-6-vagrant.vagrantup.com
> 
> Is there a way to check whether the function is actually usable as well?
> 
> Geoff Davis
> Scripps Institution of Oceanography
> gada...@ucsd.edu, (858) 822-5756
> 
> 
> 
> On Apr 17, 2012, at 11:56 AM, Ken Barber wrote:
> 
>> I'm going to review this now. Its destined for master, so someone from
>> the release team can probably comment on the next major release
>> schedule for stdlib.
>> 
>> On Tue, Apr 17, 2012 at 7:35 PM, Geoff Davis  wrote:
>>> That's what I'm looking for. I'll fold in that branch into my testing 
>>> until
>>> it goes mainline.
>>> 
>>> Any ETA on it going mainline?
>>> 
>>> 
>>> On Apr 17, 2012, at 11:14 AM, Nigel Kersten wrote:
>>> 
>>> 
>>> 
>>> On Tue, Apr 17, 2012 at 11:08 AM, Geoff Davis  wrote:
 
 I'm doing some work on module development inside of a Vagrant VM of 
 CentOS
 6.2. This VM has the community version of Puppet installed (2.7.13 I 
 think),
 but that doesn't include Hiera by default.
 
 My module is dependent on Nan Liu's puppet-staging module, which 
 requires
 hiera. This puts me into the proverbial chicken and egg problem of not
 having a puppet function but also not being able to install it with 
 puppet,
 since my manifests don't compile due to the hiera function not being
 available.
 
 Right now, I'm doing a manual bootstrap 

Re: [Puppet Users] Determining if hiera (or any function) is installed on a node

2012-04-17 Thread Gary Larizza
And here's the bug to track --> http://projects.puppetlabs.com/issues/10367

On Tue, Apr 17, 2012 at 12:31 PM, Eric Shamow  wrote:

> As a +1 on this (and as the guy who wrote safe_hiera) --
>
> It shouldn't be a function, the safety should be wrapped into hiera.  But
> yes, this will get you the right syntax so you can just search/replace
> safe_hiera for hiera once it's fixed.
>
> -Eric
>
> --
>
> Eric Shamow
> Professional Services
> http://puppetlabs.com/
> (c)631.871.6441
>
> On Tuesday, April 17, 2012 at 12:29 PM, Gary Larizza wrote:
>
> Hey Geoff,
>
> We actually had a talk about this.  There is this code that will help
> catch that scenario FOR NOW -->
> https://github.com/puppetlabs/hiera-puppet/pull/23
>
> I believe this is a bug and should DEFINITELY be fixed in source.  Until
> then, the 'safe_hiera()' function allows you to make this check.
>
>
>
> On Tue, Apr 17, 2012 at 12:21 PM, Geoff Davis  wrote:
>
> Alas that doesn't work as the manifest fails to compile properly without
> the /etc/puppet/hiera.yaml file being there.
>
> Nan's code does provide defaults for the hiera lookups similar to what you
> are doing below, but the compiler balks before they are even evaluated.
>
> Here's the version of staging/init.pp that generated the error below:
> https://github.com/nanliu/puppet-staging/blob/5e1a8763ae36c2ea21c0a5b6a1f0e586e077f0fd/manifests/init.pp
>
> Note that all of the hiera calls have defaults.
>
> Geoff Davis
> Scripps Institution of Oceanography
> gada...@ucsd.edu, (858) 822-5756
>
>
>
> On Apr 17, 2012, at 12:14 PM, Gary Larizza wrote:
>
> Hey Geoff,
>
> I see that as two separate steps (Is Hiera enabled and is Hiera
> configured).  I think the function satisfies the former, but you might want
> to write your own check for the latter (as each person probably interprets
> 'configured' differently).  You could do a check like:
>
> if function_available('hiera') and hiera('hiera_enabled', false) {
>   
> } else {
>   
> }
>
> This would do a hiera lookup for a parameter 'hiera_enabled' that could be
> set in your common/global.yaml file (while defaulting to false if it's not
> found).
>
>
>
> On Tue, Apr 17, 2012 at 12:09 PM, Geoff Davis  wrote:
>
> I've found a potential issue, but I'm not sure if this is within the scope
> of function_available or not.
>
> The vagrant basebox I'm using actually does ship with puppet-hiera, but
> there's no /etc/puppet/hiera.yaml
>
> Thus, even though function_available('hiera') returns true, the function
> isn't actually usable:
>
> Hiera config file /etc/puppet/hiera.yaml not readable at
> /tmp/vagrant-puppet/modules-0/staging/manifests/init.pp:31 on node
> centos-6-vagrant.vagrantup.com
>
> Is there a way to check whether the function is actually usable as well?
>
> Geoff Davis
> Scripps Institution of Oceanography
> gada...@ucsd.edu, (858) 822-5756
>
>
>
> On Apr 17, 2012, at 11:56 AM, Ken Barber wrote:
>
> I'm going to review this now. Its destined for master, so someone from
> the release team can probably comment on the next major release
> schedule for stdlib.
>
> On Tue, Apr 17, 2012 at 7:35 PM, Geoff Davis  wrote:
>
> That's what I'm looking for. I'll fold in that branch into my testing until
> it goes mainline.
>
> Any ETA on it going mainline?
>
>
> On Apr 17, 2012, at 11:14 AM, Nigel Kersten wrote:
>
>
>
> On Tue, Apr 17, 2012 at 11:08 AM, Geoff Davis  wrote:
>
>
> I'm doing some work on module development inside of a Vagrant VM of CentOS
> 6.2. This VM has the community version of Puppet installed (2.7.13 I
> think),
> but that doesn't include Hiera by default.
>
> My module is dependent on Nan Liu's puppet-staging module, which requires
> hiera. This puts me into the proverbial chicken and egg problem of not
> having a puppet function but also not being able to install it with puppet,
> since my manifests don't compile due to the hiera function not being
> available.
>
> Right now, I'm doing a manual bootstrap of a new vagrant box with a
> dedicated Puppet manifest that calls another one of Nan's modules,
> puppet-hiera, to install hiera on the Vagrant VM, but I'd rather use the
> same manifest for both bootstrap and module testing. I don't care if it
> takes two passes to converge, I just don't want a freshly booted Vagrant
> box
> to complain because it can't compile it's manifest.
>
> Is there a relatively foolproof way to determine if Puppet has a function
> available to it or not? Is there a "has_function" function available in the
> Puppet DSL, or is there a check that I could roll into a fact that works
> cross-platform and between Puppet Enterprise and Community?
>
>
> There's a pending pull request in the stdlib module for adding a
> function_available function
>
> https://github.com/puppetlabs/puppetlabs-stdlib/pull/59
>
>
>
> --
> 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 grou

[Puppet Users] Re: Case statements in a file directive

2012-04-17 Thread Forrie
Thank you, I appreciate it.Still learning all the interesting
nuances of this syntax.  I'm not yet familiar with this $::


-- 
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] Determining if hiera (or any function) is installed on a node

2012-04-17 Thread Eric Shamow
As a +1 on this (and as the guy who wrote safe_hiera) --

It shouldn't be a function, the safety should be wrapped into hiera.  But yes, 
this will get you the right syntax so you can just search/replace safe_hiera 
for hiera once it's fixed.

-Eric 

-- 

Eric Shamow
Professional Services
http://puppetlabs.com/
(c)631.871.6441


On Tuesday, April 17, 2012 at 12:29 PM, Gary Larizza wrote:

> Hey Geoff,
> 
> We actually had a talk about this.  There is this code that will help catch 
> that scenario FOR NOW -->  https://github.com/puppetlabs/hiera-puppet/pull/23 
> 
> I believe this is a bug and should DEFINITELY be fixed in source.  Until 
> then, the 'safe_hiera()' function allows you to make this check.   
> 
> 
> 
> On Tue, Apr 17, 2012 at 12:21 PM, Geoff Davis  (mailto:gada...@ucsd.edu)> wrote:
> > Alas that doesn't work as the manifest fails to compile properly without 
> > the /etc/puppet/hiera.yaml file being there.
> > 
> > Nan's code does provide defaults for the hiera lookups similar to what you 
> > are doing below, but the compiler balks before they are even evaluated.
> > 
> > Here's the version of staging/init.pp that generated the error below: 
> > https://github.com/nanliu/puppet-staging/blob/5e1a8763ae36c2ea21c0a5b6a1f0e586e077f0fd/manifests/init.pp
> >  
> > 
> > Note that all of the hiera calls have defaults.
> > 
> > Geoff Davis
> > Scripps Institution of Oceanography
> > gada...@ucsd.edu (mailto:gada...@ucsd.edu), (858) 822-5756 
> > (tel:%28858%29%20822-5756)
> > 
> > 
> > 
> > On Apr 17, 2012, at 12:14 PM, Gary Larizza wrote:
> > > Hey Geoff,
> > > 
> > > I see that as two separate steps (Is Hiera enabled and is Hiera 
> > > configured).  I think the function satisfies the former, but you might 
> > > want to write your own check for the latter (as each person probably 
> > > interprets 'configured' differently).  You could do a check like: 
> > > 
> > > if function_available('hiera') and hiera('hiera_enabled', false) {
> > >   
> > > } else {
> > >   
> > > }
> > > 
> > > This would do a hiera lookup for a parameter 'hiera_enabled' that could 
> > > be set in your common/global.yaml file (while defaulting to false if it's 
> > > not found).
> > > 
> > > 
> > > 
> > > On Tue, Apr 17, 2012 at 12:09 PM, Geoff Davis  > > (mailto:gada...@ucsd.edu)> wrote:
> > > > I've found a potential issue, but I'm not sure if this is within the 
> > > > scope of function_available or not.
> > > > 
> > > > The vagrant basebox I'm using actually does ship with puppet-hiera, but 
> > > > there's no /etc/puppet/hiera.yaml 
> > > > 
> > > > Thus, even though function_available('hiera') returns true, the 
> > > > function isn't actually usable:
> > > > 
> > > > Hiera config file /etc/puppet/hiera.yaml not readable at 
> > > > /tmp/vagrant-puppet/modules-0/staging/manifests/init.pp:31 on node 
> > > > centos-6-vagrant.vagrantup.com (http://centos-6-vagrant.vagrantup.com/) 
> > > > 
> > > > Is there a way to check whether the function is actually usable as well?
> > > > 
> > > > Geoff Davis
> > > > Scripps Institution of Oceanography
> > > > gada...@ucsd.edu (mailto:gada...@ucsd.edu), (858) 822-5756 
> > > > (tel:%28858%29%20822-5756)
> > > > 
> > > > 
> > > > 
> > > > On Apr 17, 2012, at 11:56 AM, Ken Barber wrote:
> > > > > I'm going to review this now. Its destined for master, so someone from
> > > > > the release team can probably comment on the next major release
> > > > > schedule for stdlib.
> > > > > 
> > > > > On Tue, Apr 17, 2012 at 7:35 PM, Geoff Davis  > > > > (mailto:gada...@ucsd.edu)> wrote:
> > > > > > That's what I'm looking for. I'll fold in that branch into my 
> > > > > > testing until
> > > > > > it goes mainline.
> > > > > > 
> > > > > > Any ETA on it going mainline?
> > > > > > 
> > > > > > 
> > > > > > On Apr 17, 2012, at 11:14 AM, Nigel Kersten wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Tue, Apr 17, 2012 at 11:08 AM, Geoff Davis  > > > > > (mailto:gada...@ucsd.edu)> wrote:
> > > > > > > 
> > > > > > > I'm doing some work on module development inside of a Vagrant VM 
> > > > > > > of CentOS
> > > > > > > 6.2. This VM has the community version of Puppet installed 
> > > > > > > (2.7.13 I think),
> > > > > > > but that doesn't include Hiera by default.
> > > > > > > 
> > > > > > > My module is dependent on Nan Liu's puppet-staging module, which 
> > > > > > > requires
> > > > > > > hiera. This puts me into the proverbial chicken and egg problem 
> > > > > > > of not
> > > > > > > having a puppet function but also not being able to install it 
> > > > > > > with puppet,
> > > > > > > since my manifests don't compile due to the hiera function not 
> > > > > > > being
> > > > > > > available.
> > > > > > > 
> > > > > > > Right now, I'm doing a manual bootstrap of a new vagrant box with 
> > > > > > > a
> > > > > > > dedicated Puppet manifest that calls another one of Nan's modules,
> > > > > > > puppet-hiera, to install hiera on the Vagrant VM, but I'd rather 
> > > > > > >

Re: [Puppet Users] Determining if hiera (or any function) is installed on a node

2012-04-17 Thread Gary Larizza
Hey Geoff,

We actually had a talk about this.  There is this code that will help catch
that scenario FOR NOW -->
https://github.com/puppetlabs/hiera-puppet/pull/23

I believe this is a bug and should DEFINITELY be fixed in source.  Until
then, the 'safe_hiera()' function allows you to make this check.



On Tue, Apr 17, 2012 at 12:21 PM, Geoff Davis  wrote:

> Alas that doesn't work as the manifest fails to compile properly without
> the /etc/puppet/hiera.yaml file being there.
>
> Nan's code does provide defaults for the hiera lookups similar to what you
> are doing below, but the compiler balks before they are even evaluated.
>
> Here's the version of staging/init.pp that generated the error below:
> https://github.com/nanliu/puppet-staging/blob/5e1a8763ae36c2ea21c0a5b6a1f0e586e077f0fd/manifests/init.pp
>
> Note that all of the hiera calls have defaults.
>
> Geoff Davis
> Scripps Institution of Oceanography
> gada...@ucsd.edu, (858) 822-5756
>
>
>
> On Apr 17, 2012, at 12:14 PM, Gary Larizza wrote:
>
> Hey Geoff,
>
> I see that as two separate steps (Is Hiera enabled and is Hiera
> configured).  I think the function satisfies the former, but you might want
> to write your own check for the latter (as each person probably interprets
> 'configured' differently).  You could do a check like:
>
> if function_available('hiera') and hiera('hiera_enabled', false) {
>   
> } else {
>   
> }
>
> This would do a hiera lookup for a parameter 'hiera_enabled' that could be
> set in your common/global.yaml file (while defaulting to false if it's not
> found).
>
>
>
> On Tue, Apr 17, 2012 at 12:09 PM, Geoff Davis  wrote:
>
>> I've found a potential issue, but I'm not sure if this is within the
>> scope of function_available or not.
>>
>> The vagrant basebox I'm using actually does ship with puppet-hiera, but
>> there's no /etc/puppet/hiera.yaml
>>
>> Thus, even though function_available('hiera') returns true, the function
>> isn't actually usable:
>>
>> Hiera config file /etc/puppet/hiera.yaml not readable at
>> /tmp/vagrant-puppet/modules-0/staging/manifests/init.pp:31 on node
>> centos-6-vagrant.vagrantup.com
>>
>> Is there a way to check whether the function is actually usable as well?
>>
>> Geoff Davis
>> Scripps Institution of Oceanography
>> gada...@ucsd.edu, (858) 822-5756
>>
>>
>>
>> On Apr 17, 2012, at 11:56 AM, Ken Barber wrote:
>>
>> I'm going to review this now. Its destined for master, so someone from
>> the release team can probably comment on the next major release
>> schedule for stdlib.
>>
>> On Tue, Apr 17, 2012 at 7:35 PM, Geoff Davis  wrote:
>>
>> That's what I'm looking for. I'll fold in that branch into my testing
>> until
>>
>> it goes mainline.
>>
>>
>> Any ETA on it going mainline?
>>
>>
>>
>> On Apr 17, 2012, at 11:14 AM, Nigel Kersten wrote:
>>
>>
>>
>>
>> On Tue, Apr 17, 2012 at 11:08 AM, Geoff Davis  wrote:
>>
>>
>> I'm doing some work on module development inside of a Vagrant VM of CentOS
>>
>> 6.2. This VM has the community version of Puppet installed (2.7.13 I
>> think),
>>
>> but that doesn't include Hiera by default.
>>
>>
>> My module is dependent on Nan Liu's puppet-staging module, which requires
>>
>> hiera. This puts me into the proverbial chicken and egg problem of not
>>
>> having a puppet function but also not being able to install it with
>> puppet,
>>
>> since my manifests don't compile due to the hiera function not being
>>
>> available.
>>
>>
>> Right now, I'm doing a manual bootstrap of a new vagrant box with a
>>
>> dedicated Puppet manifest that calls another one of Nan's modules,
>>
>> puppet-hiera, to install hiera on the Vagrant VM, but I'd rather use the
>>
>> same manifest for both bootstrap and module testing. I don't care if it
>>
>> takes two passes to converge, I just don't want a freshly booted Vagrant
>> box
>>
>> to complain because it can't compile it's manifest.
>>
>>
>> Is there a relatively foolproof way to determine if Puppet has a function
>>
>> available to it or not? Is there a "has_function" function available in
>> the
>>
>> Puppet DSL, or is there a check that I could roll into a fact that works
>>
>> cross-platform and between Puppet Enterprise and Community?
>>
>>
>>
>> There's a pending pull request in the stdlib module for adding a
>>
>> function_available function
>>
>>
>> https://github.com/puppetlabs/puppetlabs-stdlib/pull/59
>>
>>
>>
>>
>> --
>>
>> 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.
>>
>>
>>
>> --
>>
>> 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 thi

Re: [Puppet-dev] Re: [Puppet Users] Telly: Nagios types moving into Module

2012-04-17 Thread Stefan Heijmans
Hi,
>
> What will be the option(s) for Puppet users with no internet connection 
(not allowed), if things start to depend more on PMT and Puppet Forge?
Will we be able to make a local repo and do something like a 'puppet module 
localinstall' ?



-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/mt4aK9XjSnYJ.
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] Determining if hiera (or any function) is installed on a node

2012-04-17 Thread Geoff Davis
Alas that doesn't work as the manifest fails to compile properly without the 
/etc/puppet/hiera.yaml file being there.

Nan's code does provide defaults for the hiera lookups similar to what you are 
doing below, but the compiler balks before they are even evaluated.

Here's the version of staging/init.pp that generated the error below: 
https://github.com/nanliu/puppet-staging/blob/5e1a8763ae36c2ea21c0a5b6a1f0e586e077f0fd/manifests/init.pp

Note that all of the hiera calls have defaults.

Geoff Davis
Scripps Institution of Oceanography
gada...@ucsd.edu, (858) 822-5756



On Apr 17, 2012, at 12:14 PM, Gary Larizza wrote:

> Hey Geoff,
> 
> I see that as two separate steps (Is Hiera enabled and is Hiera configured).  
> I think the function satisfies the former, but you might want to write your 
> own check for the latter (as each person probably interprets 'configured' 
> differently).  You could do a check like:
> 
> if function_available('hiera') and hiera('hiera_enabled', false) {
>   
> } else {
>   
> }
> 
> This would do a hiera lookup for a parameter 'hiera_enabled' that could be 
> set in your common/global.yaml file (while defaulting to false if it's not 
> found).
> 
> 
> 
> On Tue, Apr 17, 2012 at 12:09 PM, Geoff Davis  wrote:
> I've found a potential issue, but I'm not sure if this is within the scope of 
> function_available or not.
> 
> The vagrant basebox I'm using actually does ship with puppet-hiera, but 
> there's no /etc/puppet/hiera.yaml
> 
> Thus, even though function_available('hiera') returns true, the function 
> isn't actually usable:
> 
> Hiera config file /etc/puppet/hiera.yaml not readable at 
> /tmp/vagrant-puppet/modules-0/staging/manifests/init.pp:31 on node 
> centos-6-vagrant.vagrantup.com
> 
> Is there a way to check whether the function is actually usable as well?
> 
> Geoff Davis
> Scripps Institution of Oceanography
> gada...@ucsd.edu, (858) 822-5756
> 
> 
> 
> On Apr 17, 2012, at 11:56 AM, Ken Barber wrote:
> 
>> I'm going to review this now. Its destined for master, so someone from
>> the release team can probably comment on the next major release
>> schedule for stdlib.
>> 
>> On Tue, Apr 17, 2012 at 7:35 PM, Geoff Davis  wrote:
>>> That's what I'm looking for. I'll fold in that branch into my testing until
>>> it goes mainline.
>>> 
>>> Any ETA on it going mainline?
>>> 
>>> 
>>> On Apr 17, 2012, at 11:14 AM, Nigel Kersten wrote:
>>> 
>>> 
>>> 
>>> On Tue, Apr 17, 2012 at 11:08 AM, Geoff Davis  wrote:
 
 I'm doing some work on module development inside of a Vagrant VM of CentOS
 6.2. This VM has the community version of Puppet installed (2.7.13 I 
 think),
 but that doesn't include Hiera by default.
 
 My module is dependent on Nan Liu's puppet-staging module, which requires
 hiera. This puts me into the proverbial chicken and egg problem of not
 having a puppet function but also not being able to install it with puppet,
 since my manifests don't compile due to the hiera function not being
 available.
 
 Right now, I'm doing a manual bootstrap of a new vagrant box with a
 dedicated Puppet manifest that calls another one of Nan's modules,
 puppet-hiera, to install hiera on the Vagrant VM, but I'd rather use the
 same manifest for both bootstrap and module testing. I don't care if it
 takes two passes to converge, I just don't want a freshly booted Vagrant 
 box
 to complain because it can't compile it's manifest.
 
 Is there a relatively foolproof way to determine if Puppet has a function
 available to it or not? Is there a "has_function" function available in the
 Puppet DSL, or is there a check that I could roll into a fact that works
 cross-platform and between Puppet Enterprise and Community?
 
>>> 
>>> There's a pending pull request in the stdlib module for adding a
>>> function_available function
>>> 
>>> https://github.com/puppetlabs/puppetlabs-stdlib/pull/59
>>> 
>>> 
>>> 
>>> --
>>> 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.
>>> 
>>> 
>>> --
>>> 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.
>> 
>> -- 
>> 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 
>> puppe

Re: [Puppet Users] Determining if hiera (or any function) is installed on a node

2012-04-17 Thread Gary Larizza
Hey Geoff,

I see that as two separate steps (Is Hiera enabled and is Hiera
configured).  I think the function satisfies the former, but you might want
to write your own check for the latter (as each person probably interprets
'configured' differently).  You could do a check like:

if function_available('hiera') and hiera('hiera_enabled', false) {
  
} else {
  
}

This would do a hiera lookup for a parameter 'hiera_enabled' that could be
set in your common/global.yaml file (while defaulting to false if it's not
found).



On Tue, Apr 17, 2012 at 12:09 PM, Geoff Davis  wrote:

> I've found a potential issue, but I'm not sure if this is within the scope
> of function_available or not.
>
> The vagrant basebox I'm using actually does ship with puppet-hiera, but
> there's no /etc/puppet/hiera.yaml
>
> Thus, even though function_available('hiera') returns true, the function
> isn't actually usable:
>
> Hiera config file /etc/puppet/hiera.yaml not readable at
> /tmp/vagrant-puppet/modules-0/staging/manifests/init.pp:31 on node
> centos-6-vagrant.vagrantup.com
>
> Is there a way to check whether the function is actually usable as well?
>
> Geoff Davis
> Scripps Institution of Oceanography
> gada...@ucsd.edu, (858) 822-5756
>
>
>
> On Apr 17, 2012, at 11:56 AM, Ken Barber wrote:
>
> I'm going to review this now. Its destined for master, so someone from
> the release team can probably comment on the next major release
> schedule for stdlib.
>
> On Tue, Apr 17, 2012 at 7:35 PM, Geoff Davis  wrote:
>
> That's what I'm looking for. I'll fold in that branch into my testing until
>
> it goes mainline.
>
>
> Any ETA on it going mainline?
>
>
>
> On Apr 17, 2012, at 11:14 AM, Nigel Kersten wrote:
>
>
>
>
> On Tue, Apr 17, 2012 at 11:08 AM, Geoff Davis  wrote:
>
>
> I'm doing some work on module development inside of a Vagrant VM of CentOS
>
> 6.2. This VM has the community version of Puppet installed (2.7.13 I
> think),
>
> but that doesn't include Hiera by default.
>
>
> My module is dependent on Nan Liu's puppet-staging module, which requires
>
> hiera. This puts me into the proverbial chicken and egg problem of not
>
> having a puppet function but also not being able to install it with puppet,
>
> since my manifests don't compile due to the hiera function not being
>
> available.
>
>
> Right now, I'm doing a manual bootstrap of a new vagrant box with a
>
> dedicated Puppet manifest that calls another one of Nan's modules,
>
> puppet-hiera, to install hiera on the Vagrant VM, but I'd rather use the
>
> same manifest for both bootstrap and module testing. I don't care if it
>
> takes two passes to converge, I just don't want a freshly booted Vagrant
> box
>
> to complain because it can't compile it's manifest.
>
>
> Is there a relatively foolproof way to determine if Puppet has a function
>
> available to it or not? Is there a "has_function" function available in the
>
> Puppet DSL, or is there a check that I could roll into a fact that works
>
> cross-platform and between Puppet Enterprise and Community?
>
>
>
> There's a pending pull request in the stdlib module for adding a
>
> function_available function
>
>
> https://github.com/puppetlabs/puppetlabs-stdlib/pull/59
>
>
>
>
> --
>
> 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.
>
>
>
> --
>
> 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.
>
>
> --
> 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.
>
>
>  --
> 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.
>



-- 

Gary Larizza
Professional Services Engineer
Puppet Labs

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

Re: [Puppet Users] Determining if hiera (or any function) is installed on a node

2012-04-17 Thread Geoff Davis
I've found a potential issue, but I'm not sure if this is within the scope of 
function_available or not.

The vagrant basebox I'm using actually does ship with puppet-hiera, but there's 
no /etc/puppet/hiera.yaml

Thus, even though function_available('hiera') returns true, the function isn't 
actually usable:

Hiera config file /etc/puppet/hiera.yaml not readable at 
/tmp/vagrant-puppet/modules-0/staging/manifests/init.pp:31 on node 
centos-6-vagrant.vagrantup.com

Is there a way to check whether the function is actually usable as well?

Geoff Davis
Scripps Institution of Oceanography
gada...@ucsd.edu, (858) 822-5756



On Apr 17, 2012, at 11:56 AM, Ken Barber wrote:

> I'm going to review this now. Its destined for master, so someone from
> the release team can probably comment on the next major release
> schedule for stdlib.
> 
> On Tue, Apr 17, 2012 at 7:35 PM, Geoff Davis  wrote:
>> That's what I'm looking for. I'll fold in that branch into my testing until
>> it goes mainline.
>> 
>> Any ETA on it going mainline?
>> 
>> 
>> On Apr 17, 2012, at 11:14 AM, Nigel Kersten wrote:
>> 
>> 
>> 
>> On Tue, Apr 17, 2012 at 11:08 AM, Geoff Davis  wrote:
>>> 
>>> I'm doing some work on module development inside of a Vagrant VM of CentOS
>>> 6.2. This VM has the community version of Puppet installed (2.7.13 I think),
>>> but that doesn't include Hiera by default.
>>> 
>>> My module is dependent on Nan Liu's puppet-staging module, which requires
>>> hiera. This puts me into the proverbial chicken and egg problem of not
>>> having a puppet function but also not being able to install it with puppet,
>>> since my manifests don't compile due to the hiera function not being
>>> available.
>>> 
>>> Right now, I'm doing a manual bootstrap of a new vagrant box with a
>>> dedicated Puppet manifest that calls another one of Nan's modules,
>>> puppet-hiera, to install hiera on the Vagrant VM, but I'd rather use the
>>> same manifest for both bootstrap and module testing. I don't care if it
>>> takes two passes to converge, I just don't want a freshly booted Vagrant box
>>> to complain because it can't compile it's manifest.
>>> 
>>> Is there a relatively foolproof way to determine if Puppet has a function
>>> available to it or not? Is there a "has_function" function available in the
>>> Puppet DSL, or is there a check that I could roll into a fact that works
>>> cross-platform and between Puppet Enterprise and Community?
>>> 
>> 
>> There's a pending pull request in the stdlib module for adding a
>> function_available function
>> 
>> https://github.com/puppetlabs/puppetlabs-stdlib/pull/59
>> 
>> 
>> 
>> --
>> 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.
>> 
>> 
>> --
>> 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.
> 
> -- 
> 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.

-- 
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] Undo

2012-04-17 Thread root
So.. I am evaluating Puppet Enterprise 2.5.  I was messing with Live 
Management and I cloned a user account to all my nodes instead of just 
one.  This overwrote the account settings on all my Solaris and SUSE with 
the account data from a RHEL server.  I'd like to know how I would undo 
this, please.  
 
 

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/bFlN11NuA3sJ.
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] Determining if hiera (or any function) is installed on a node

2012-04-17 Thread Ken Barber
I'm going to review this now. Its destined for master, so someone from
the release team can probably comment on the next major release
schedule for stdlib.

On Tue, Apr 17, 2012 at 7:35 PM, Geoff Davis  wrote:
> That's what I'm looking for. I'll fold in that branch into my testing until
> it goes mainline.
>
> Any ETA on it going mainline?
>
>
> On Apr 17, 2012, at 11:14 AM, Nigel Kersten wrote:
>
>
>
> On Tue, Apr 17, 2012 at 11:08 AM, Geoff Davis  wrote:
>>
>> I'm doing some work on module development inside of a Vagrant VM of CentOS
>> 6.2. This VM has the community version of Puppet installed (2.7.13 I think),
>> but that doesn't include Hiera by default.
>>
>> My module is dependent on Nan Liu's puppet-staging module, which requires
>> hiera. This puts me into the proverbial chicken and egg problem of not
>> having a puppet function but also not being able to install it with puppet,
>> since my manifests don't compile due to the hiera function not being
>> available.
>>
>> Right now, I'm doing a manual bootstrap of a new vagrant box with a
>> dedicated Puppet manifest that calls another one of Nan's modules,
>> puppet-hiera, to install hiera on the Vagrant VM, but I'd rather use the
>> same manifest for both bootstrap and module testing. I don't care if it
>> takes two passes to converge, I just don't want a freshly booted Vagrant box
>> to complain because it can't compile it's manifest.
>>
>> Is there a relatively foolproof way to determine if Puppet has a function
>> available to it or not? Is there a "has_function" function available in the
>> Puppet DSL, or is there a check that I could roll into a fact that works
>> cross-platform and between Puppet Enterprise and Community?
>>
>
> There's a pending pull request in the stdlib module for adding a
> function_available function
>
> https://github.com/puppetlabs/puppetlabs-stdlib/pull/59
>
>
>
> --
> 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.
>
>
> --
> 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.

-- 
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-dev] Re: [Puppet Users] Telly: Nagios types moving into Module

2012-04-17 Thread Kelsey Hightower
On Tue, Apr 17, 2012 at 2:28 PM, Walter Heck  wrote:

> Yeah, right after that email I saw the 2.7.14rc1 release notes and
> answered my own question, my apologies :)


No worries, we're here to help.

-- 
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] Determining if hiera (or any function) is installed on a node

2012-04-17 Thread Geoff Davis
That's what I'm looking for. I'll fold in that branch into my testing until it 
goes mainline.

Any ETA on it going mainline?

On Apr 17, 2012, at 11:14 AM, Nigel Kersten wrote:

> 
> 
> On Tue, Apr 17, 2012 at 11:08 AM, Geoff Davis  wrote:
> I'm doing some work on module development inside of a Vagrant VM of CentOS 
> 6.2. This VM has the community version of Puppet installed (2.7.13 I think), 
> but that doesn't include Hiera by default.
> 
> My module is dependent on Nan Liu's puppet-staging module, which requires 
> hiera. This puts me into the proverbial chicken and egg problem of not having 
> a puppet function but also not being able to install it with puppet, since my 
> manifests don't compile due to the hiera function not being available.
> 
> Right now, I'm doing a manual bootstrap of a new vagrant box with a dedicated 
> Puppet manifest that calls another one of Nan's modules, puppet-hiera, to 
> install hiera on the Vagrant VM, but I'd rather use the same manifest for 
> both bootstrap and module testing. I don't care if it takes two passes to 
> converge, I just don't want a freshly booted Vagrant box to complain because 
> it can't compile it's manifest.
> 
> Is there a relatively foolproof way to determine if Puppet has a function 
> available to it or not? Is there a "has_function" function available in the 
> Puppet DSL, or is there a check that I could roll into a fact that works 
> cross-platform and between Puppet Enterprise and Community?
> 
> 
> There's a pending pull request in the stdlib module for adding a 
> function_available function 
> 
> https://github.com/puppetlabs/puppetlabs-stdlib/pull/59
> 
> 
> 
> -- 
> 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.

-- 
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-dev] Re: [Puppet Users] Telly: Nagios types moving into Module

2012-04-17 Thread Walter Heck
Yeah, right after that email I saw the 2.7.14rc1 release notes and
answered my own question, my apologies :)

On Wed, Apr 18, 2012 at 02:26, Kelsey Hightower  wrote:
> On Tue, Apr 17, 2012 at 2:19 PM, Walter Heck  wrote:
>>
>>
>> On Apr 18, 2012 1:39 AM, "Nigel Kersten"  wrote:
>>
>> > Absolutely. This is the functionality we'll have available in Puppet.
>> >
>> > # puppet module list
>> > /etc/puppetlabs/puppet/production/modules
>> > └── nigelkersten-testmac (v0.0.2)
>> > /opt/puppet/share/puppet/modules
>> > ├── puppetlabs-pe_accounts (v1.0.2)
>> > ├── puppetlabs-pe_compliance (v0.0.6)
>> > ├── puppetlabs-pe_mcollective (v0.0.43)
>> > └── puppetlabs-stdlib (v2.3.1)
>>
>> Just checking since that example mentions puppet enterprise modules: this
>> will be in the community edition as well, right?
>
> Yep, the next release of Puppet open source will have it baked in.
>
> --
> Kelsey Hightower
> Solutions Engineer
> Puppet Labs
> 1-678-471-9501
>
> --
> 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.



-- 
Walter Heck

--
follow @walterheck on twitter to see what I'm up to!
--
Check out my new startup: Server Monitoring as a Service @ http://tribily.com
Follow @tribily on Twitter and/or 'Like' our Facebook page at
http://www.facebook.com/tribily

-- 
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-dev] Re: [Puppet Users] Telly: Nagios types moving into Module

2012-04-17 Thread Kelsey Hightower
On Tue, Apr 17, 2012 at 2:19 PM, Walter Heck  wrote:

>
> On Apr 18, 2012 1:39 AM, "Nigel Kersten"  wrote:
>
> > Absolutely. This is the functionality we'll have available in Puppet.
> >
> > # puppet module list
> > /etc/puppetlabs/puppet/production/modules
> > └── nigelkersten-testmac (v0.0.2)
> > /opt/puppet/share/puppet/modules
> > ├── puppetlabs-pe_accounts (v1.0.2)
> > ├── puppetlabs-pe_compliance (v0.0.6)
> > ├── puppetlabs-pe_mcollective (v0.0.43)
> > └── puppetlabs-stdlib (v2.3.1)
>
> Just checking since that example mentions puppet enterprise modules: this
> will be in the community edition as well, right?
>
Yep, the next release of Puppet open source will have it baked in.

-- 
Kelsey Hightower
Solutions Engineer
Puppet Labs
1-678-471-9501

-- 
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-dev] Re: [Puppet Users] Telly: Nagios types moving into Module

2012-04-17 Thread Walter Heck
On Apr 18, 2012 1:39 AM, "Nigel Kersten"  wrote:

> Absolutely. This is the functionality we'll have available in Puppet.
>
> # puppet module list
> /etc/puppetlabs/puppet/production/modules
> └── nigelkersten-testmac (v0.0.2)
> /opt/puppet/share/puppet/modules
> ├── puppetlabs-pe_accounts (v1.0.2)
> ├── puppetlabs-pe_compliance (v0.0.6)
> ├── puppetlabs-pe_mcollective (v0.0.43)
> └── puppetlabs-stdlib (v2.3.1)

Just checking since that example mentions puppet enterprise modules: this
will be in the community edition as well, 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] Determining if hiera (or any function) is installed on a node

2012-04-17 Thread Nigel Kersten
On Tue, Apr 17, 2012 at 11:08 AM, Geoff Davis  wrote:

> I'm doing some work on module development inside of a Vagrant VM of CentOS
> 6.2. This VM has the community version of Puppet installed (2.7.13 I
> think), but that doesn't include Hiera by default.
>
> My module is dependent on Nan Liu's puppet-staging module, which requires
> hiera. This puts me into the proverbial chicken and egg problem of not
> having a puppet function but also not being able to install it with puppet,
> since my manifests don't compile due to the hiera function not being
> available.
>
> Right now, I'm doing a manual bootstrap of a new vagrant box with a
> dedicated Puppet manifest that calls another one of Nan's modules,
> puppet-hiera, to install hiera on the Vagrant VM, but I'd rather use the
> same manifest for both bootstrap and module testing. I don't care if it
> takes two passes to converge, I just don't want a freshly booted Vagrant
> box to complain because it can't compile it's manifest.
>
> Is there a relatively foolproof way to determine if Puppet has a function
> available to it or not? Is there a "has_function" function available in the
> Puppet DSL, or is there a check that I could roll into a fact that works
> cross-platform and between Puppet Enterprise and Community?
>
>
There's a pending pull request in the stdlib module for adding a
function_available function

https://github.com/puppetlabs/puppetlabs-stdlib/pull/59

-- 
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] Determining if hiera (or any function) is installed on a node

2012-04-17 Thread Geoff Davis
I'm doing some work on module development inside of a Vagrant VM of CentOS 6.2. 
This VM has the community version of Puppet installed (2.7.13 I think), but 
that doesn't include Hiera by default.

My module is dependent on Nan Liu's puppet-staging module, which requires 
hiera. This puts me into the proverbial chicken and egg problem of not having a 
puppet function but also not being able to install it with puppet, since my 
manifests don't compile due to the hiera function not being available.

Right now, I'm doing a manual bootstrap of a new vagrant box with a dedicated 
Puppet manifest that calls another one of Nan's modules, puppet-hiera, to 
install hiera on the Vagrant VM, but I'd rather use the same manifest for both 
bootstrap and module testing. I don't care if it takes two passes to converge, 
I just don't want a freshly booted Vagrant box to complain because it can't 
compile it's manifest.

Is there a relatively foolproof way to determine if Puppet has a function 
available to it or not? Is there a "has_function" function available in the 
Puppet DSL, or is there a check that I could roll into a fact that works 
cross-platform and between Puppet Enterprise and Community?

-- 
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] Announce: Puppet 2.7.14rc1 Available

2012-04-17 Thread Matthaus Litteken
Puppet 2.7.14rc1 is a maintenance release candidate for Puppet in the
2.7.x series.

This release is on the heels of Puppet 2.7.13 because our regular
monthly release for April got preempted by our security release.

Downloads are available:
 * Source http://downloads.puppetlabs.com/puppet/puppet-2.7.14rc1.tar.gz

## Community MVP for this release: Dominic Cleal for
 #11988 and #13204 - Augeas provider improvements

## Puppet 2.7.14rc1 Highlights ##

## Features ##
Puppet Module Tool Face - the module tool has seen a host of
improvements including dependency resolution, environment handling,
and searching the forge. There are more details available at
http://docs.puppetlabs.com/puppet/2.7/reference/modules_installing.html

## Bug Fixes ##
Better warnings about scoping
Make new scoping look through inherited scopes

Previous to this commit, Puppet would look through a given scope
hierarchy and give deprecation warnings when a value was found in either
an inherited class scope or included class scope, when it should only
give the warning in the case of the included class scope.

This commit makes the new-scope behavior also examine inherited scopes,
though continuing to ignore included scopes.

Implement newlookupvar() to replace dynamic scope

lookupvar() is shifted to oldlookupvar() and newlookupvar() is added. An
intermediary lookupvar() function will query both and if the answer
varies then it will throw a deprecation warning for dynamic scoping. The
intermediary and old lookup functions may be removed at a later date,
thus completing the transition.

A test case has been introduced to detect dynamic scoping and the
deprecation warning. Slight modifications to the spec test scoping
objects were made to bring them more in line with the real world.

All scope tests pass. When oldlookupvar is replaced, the deprecated
dynamic scoping test case will fail and all other scope test cases will
pass.


Augeas Improvements
(#11988) Work around Augeas reload bug when changing save modes

After saving a file in one save mode and switching to another,
Augeas realise
to reload the file when Augeas#load is called again.  Work around this by
explicitly reloading all files we saved while using the first save mode.

(#11988) Don't overwrite symlinks in augeas provider

Previously, if not running with `force` set, we would try to write the
file in SAVE_NEWFILE mode to create a .augnew file with the
changes. We determined whether there were changes to be made based on
that file (and used it to show a diff). When it came time to actually
make the changes, we would simply move the .augnew file over the file
being managed. Unfortunately, if the file being managed were a symlink,
this would clobber it.

There was a fallback path in the case of force (or older versions of
augeas not supporting SAVE_NEWFILE) in which we would make the
changes in SAVE_OVERWRITE mode as normal. Now, the behavior is a
combination of the two; we still use SAVE_NEWFILE to determine whether
changes need to be made and to show a diff, but then remove the .augnew
file and always run again in SAVE_OVERWRITE mode to save the changes.
This effectively delegates the behavior of preserving the file, etc.
to augeas, so we don't duplicate effort or bugs.

(#13204) Don't ignore missing PATH.augnew files

The original fix for #13204 may have masked other potential bugs if the
PATH.augnew file was missing.  It simply tested for the file
existance and not
only when duplicate save events occurred.

This change de-duplicates the list of save events instead, so if a
bug appeared
where PATH.augnew was genuinely missing, the error wouldn't be squashed.

(#13204) Workaround duplicate Augeas save events

Bug #264 in Augeas causes duplicate save events to be returned when editing
under /boot in newfile mode.  Because we loop around these events,
diffing and
unlinking the files, this causes an ENOENT error when we process
the same event
twice.

This commit checks that the file we intend to operate on exists.

(#7592) Remove redundant call to String#to_s

Previously, the augeas provider made calls like the following:

 @aug.get(key).to_s

Since the Augeas#get method returns a String not an array, the to_s
call is redundant. (Note the #match method does return an array.)

The augeas tests were stubbing the #get method to return an array in
some places (and a string in others). Prior to 1.9.2, ruby will
automatically convert ["foo"].to_s to "foo", so everything worked as
expected. However, under 1.9.2, ["foo"].to_s becomes "[\"foo\"]".

These failures weren't noticed earlier, because our 1.9.2@allFeatures
jenkins nodes do not have ruby-augeas installed. In other words, tests
that require Puppet.

Re: [Puppet-dev] Re: [Puppet Users] Telly: Nagios types moving into Module

2012-04-17 Thread Nigel Kersten
On Tue, Apr 17, 2012 at 10:34 AM, Tim Mooney  wrote:

> In regard to: Re: [Puppet-dev] Re: [Puppet Users] Telly: Nagios types...:
>
>
>  Todd, welcome and I feel your pain.  Trust me, I pushed every way I
>> could to use native packages as our module deliver mechanism.  However
>> we have some odd requirements that make things not work as well with
>> RPM (or deb, or gems).  Basically we need a mechanism to allow
>> multiple versions installed into separate environments (paths on
>> disk).
>>
>
> You make a compelling argument for why this doesn't map well to native
> packaging tools.  While it is possible to have multiple copies of an RPM
> installed simultaneously, it would be a kludge in this case.
>
>
>  Something like pm2rpm and pm2deb is very likely something we'll need
>> to make the lives of Puppet Users happy.
>>
>
> Now that puppet has drug me into the ruby world, I've started down the
> path of RPM packaging of gems.  gem2rpm helped me get started.  Having
> something that works very similar to that would be a big help to those
> that are experienced with ruby & gems.
>
> Whatever you choose, though, there needs to be a way for admins to query
> a client and find out
>
>- what puppet modules are installed
>- where each instance of the module is installed
>- what "version" is present in each instance


Absolutely. This is the functionality we'll have available in Puppet.

# puppet module list
/etc/puppetlabs/puppet/production/modules
└── nigelkersten-testmac (v0.0.2)
/opt/puppet/share/puppet/modules
├── puppetlabs-pe_accounts (v1.0.2)
├── puppetlabs-pe_compliance (v0.0.6)
├── puppetlabs-pe_mcollective (v0.0.43)
└── puppetlabs-stdlib (v2.3.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-dev] Re: [Puppet Users] Telly: Nagios types moving into Module

2012-04-17 Thread Tim Mooney

In regard to: Re: [Puppet-dev] Re: [Puppet Users] Telly: Nagios types...:


Todd, welcome and I feel your pain.  Trust me, I pushed every way I
could to use native packages as our module deliver mechanism.  However
we have some odd requirements that make things not work as well with
RPM (or deb, or gems).  Basically we need a mechanism to allow
multiple versions installed into separate environments (paths on
disk).


You make a compelling argument for why this doesn't map well to native
packaging tools.  While it is possible to have multiple copies of an RPM
installed simultaneously, it would be a kludge in this case.


Something like pm2rpm and pm2deb is very likely something we'll need
to make the lives of Puppet Users happy.


Now that puppet has drug me into the ruby world, I've started down the
path of RPM packaging of gems.  gem2rpm helped me get started.  Having
something that works very similar to that would be a big help to those
that are experienced with ruby & gems.

Whatever you choose, though, there needs to be a way for admins to query
a client and find out

- what puppet modules are installed
- where each instance of the module is installed
- what "version" is present in each instance

Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing & Infrastructure  701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164

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

2012-04-17 Thread Jeff McCune
On Tue, Apr 17, 2012 at 3:52 AM, Afroz Hussain  wrote:
> Thanks a lot Jeff,
>
> yes, It is an warning but still I am not able to access the dashboard,
> Pasted the error:
>

I'm unable to decode this message in a timely manner.  =)

Could you please paste the details of the error, perhaps with
screenshots, to http://gist.github.com and send a link to the gist?

I'm not really able to troubleshoot without this information.

Thanks,
-Jeff

-- 
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] file type with links => follow uses wrong permissions if not explicit

2012-04-17 Thread Adam Heinz
I think I've hit a minor permissions bug using
puppet-2.6.13-2.el6.noarch from EPEL on CentOS 6.  In order to
reproduce production bugs on a test environment, I use puppet to copy
the latest backup to a test server, followed by the remainder of the
puppet-driven configuration necessary.  I just started using symlinks,
so I added links => follow to the file type.

File {
group => root,
owner => root,
}

file { "/var/lib/mysql/backups/current.sql.gz":
backup  => false,
links   => follow,
source  => "puppet:///files/backups/current.sql.gz",
}

When I kicked puppet on the test machine, it set the file permissions
to the permissions of the link itself, not the file the link pointed
to.

Apr 17 10:55:37 test1 puppet-agent[1807]:
(/Stage[main]/Testserver/File[/var/lib/mysql/backups/current.sql.gz]/mode)
mode changed '644' to '777'

So the obvious workaround is to explicitly set the permissions on the
file type, instead of relying on puppet to preserve the permissions of
the source file.

puppetmaster # ls -l /var/lib/mysql/backups
-rw-r--r-- 1 root root  4330512 Apr 17 00:22 2012-04-17.sql.gz
lrwxrwxrwx 1 root root   14 Apr 17 10:45 current.sql.gz -> 2012-04-17.sql.gz

Put in a bug for this?  (I don't currently appear to have permissions to do so.)

-- 
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 get ruby-shadow installed before trying to make users,groups

2012-04-17 Thread Michael Stahnke
On Mon, Apr 16, 2012 at 9:52 PM, Paul Hinze  wrote:
> On Mon, Apr 16, 2012 at 4:55 PM, Steve Roberts  wrote:
>> But since the provider has already clipped the attributes they don't
>> get set in the first run.
>>
>> when run a second time the attributes do get set correctly, but that
>> seems a bit kludgy to have to run puppet twice to get the desired
>> affect.
>
> I've run into this too, and worked around it by considering
> ruby-shadow as a "prerequisite" for puppet, and therefore taking
> responsibility for that package up to my bootstrapping scripts. IOW,
> it is one of the short list of packages that need to be there for
> puppet to run successfully. In my case, that means adding it to a
> Debian pre-seed config.
>
> I'd be curious to know if there's any other way to work around
> provider dependencies like these in a cleaner way though.
>

Much of this depends on *how* you install puppet.  If you use yum or
apt, I think shadow is pulled in as a dep (I know it is for rpm).  If
you use gems, I'm quite sure it's not. If you're on mac or Windows you
can use the native packages and get password management without
shadow.

What platforms 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.
>

-- 
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: Having trouble getting puppet to set users/groups to a defined state

2012-04-17 Thread jcbollinger


On Apr 16, 10:03 pm, Steve Roberts  wrote:
> I'm hoping I'm just missing something simple.
>
> I ran across this in my deployment setup and have replicated in a
> simple set of manifests.  command output and the manifests below.
>
> basically start with a user/group name but it had the name was
> misspelled 'txuser'
>
> so correct it to 'tuser' but puppet errors out saying the gid is a
> dupe.
>
> I thought one of the key ideas for puppet was the ability to define a
> manifest and puppet would make the machine look like that manifest.


That is correct.  Another key idea, however, is that Puppet does not
manage resources that are not declared in the target node's
manifests.  Yet another is that it avoids doing unusual things without
specific instruction to do so.  Occasionally two or more of these
clash.

In this case, you need to recognize that Puppet identifies groups (and
users) by their names, just as the OS's tools do.  Indeed, the only
other alternative, gid (uid) is unsuitable because the OS does not
require it to be unique.  When you change the name of one of a Group
declaration in one of your manifests, therefore, that doesn't
correspond to changing the name field of an existing group record on
the client.  Instead, it corresponds to managing an entirely different
group, leaving the other unmanaged.


> I checked the group resource documentation and didn't see an option to
> say 'force' or something.


It is spelled "allowdupe", but it would be better to clean up the mess
than to make a bigger one.  Add this to your manifest to do so:

group { 'txuser':
  ensure => 'absent',
  before  => Group['tuser']
}


> I'm thinking would also be a problem if someone locally edited /etc/
> passwd and /etc/group the manifest would also fail.


That is possible.  That general class of problems is one of many
reasons to avoid sharing management responsibilities for any given set
of resources among multiple agents (including humans).  If it does
happen, then the failure is probably good, because it signals admins
that there is something they need to investigate.

Puppet also has a mechanism by which you can ensure that otherwise-
unmanaged resources of some types are all ensured absent.  That's both
very powerful and very dangerous, and I advise you to avoid it at
least until you have more experience with Puppet.  To that end, I'm
leaving it as an exercise to determine just what the mechanism is.


John

-- 
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: collecting resources for iteration in a template

2012-04-17 Thread Jonathon Anderson
On Tuesday, April 17, 2012 11:14:15 AM UTC+3, Luke Bigum wrote:
>
> Just in case you haven't seen it, RIP's original concat module: 
> https://github.com/ripienaar/puppet-concat


I hadn't seen it.  Thank you for the pointer.  Like I said, this is 
basically what we're doing now; but It's probably better to use that than 
to re-implement this for every fragment-concatenating module we have.  If I 
end up not being able to find a compilation-time solution, this is probably 
the best avenue left.

tl;dr, once again, RIP has already thought of that!

~jonathon

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/336Pr6j-eg8J.
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: Requiring defines from other classes in a fact

2012-04-17 Thread Boudewijn Ector
On 04/17/2012 07:14 AM, Wil Cooley wrote:
> On Apr 16, 2:39 pm, Boudewijn Ector 
> wrote:
>
>> Very very simple, except for the fact that I want to add the
>> dependency for the mysql::database too. I'm using this excellent
>> module for managing mysql:https://github.com/camptocamp/puppet-mysql
>>
>> Is there a neat way to do something like this
>>
>>   service{"openca":
>>...
>>requires => [Package["openca"],mysql::database["openca"]],
>>   }
>>
>> I already tried doing this, and also tried dependency chaining, but
>> just can't get it to work at all.
> You've almost got it here; you need to use reference syntax for the
> mysql::database resource just like you do for the package:
>
> requires => [Package["openca"],Mysql::Database["openca"]],
>
> Wil
>
Hi Wil,

That worked pretty well. Should have tried that, but it was already
pretty late ;-).

Thanks!

Boudewijn

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

2012-04-17 Thread Luke Bigum
Yes, your Puppet Master can be an Agent, it just talks to itself. Most 
people manage Puppet Agent and Master configuration with Puppet itself - 
get it to manage it's own config and restart itself when it changes. 
This means you only need a bunch of text files - your modules and 
manifests - to rebuild your entire infrastructure.


On 17/04/12 12:18, Kukki wrote:
Thanks guys that was really very helpful and did clear lots of 
concepts in my mind for puppet. Absolutely brilliant that means that 
with collective I can even launch the instances on EC2 aswel and can 
even run the required services on demand within the boxs.
One thing I also like to know say puppet master connected to 20 boxs 
in a cluster and all the agents are connected to master and are 
running in daemon mode and  doing well,but if i need to do some 
changes or update few things in an admin box itself (i.e Box with 
puppet master) so how do i do that?  do i need to install puppet 
client aswel where puppet master is running to do the required job or 
puppet master can be use to configure itself? If yes then how.

Regards,
On 17 April 2012 09:07, Luke Bigum > wrote:


Overdue,

Walter is right in that you will need to look to another tool,
such as MCollective. Puppet is not the best at orchestrating
operations across multiple servers. It can reacting to things on
one machine, like an Apache servers' config file updating, but
there's nothing in core Puppet that's going to have your Varnish
servers react to this event.

MCollective is a job scheduling frame work that can do what you're
after and integrates with Puppet quite well. Other products are
Func and RunDeck.

-Luke


On 17/04/12 00:54, Walter Heck wrote:

If you are not running your agents in daemon mode, you can
have a look
at mcollective. It allows you to define a set of servers that
you want
to do a puppet run on.

cheers,

Walter

On Tue, Apr 17, 2012 at 05:31, OverDue
Oceanmailto:overdueoc...@gmail.com>>
 wrote:

Hi Guys, Let me Introduce myself as  self learner and very
new to
puppet and I am sure that now on I am staying here in this
group for
long and keep asking questions,

I am sorry if my message annoys you or if its a bit
childish please
forgive me but i believes that if you want to learn you
should ask,

My Question is :

I have a server running puppet Master and 8 clients are
connected with
Master and every half an hour clients pulls up there
configuration if
requires from master and update themselves, but if need to
restart
Apache on 4 of them and have to restart varnish in the
remaining 4 all
in a sudden then how i will do that? do I need to wait for
the next
half an hour that clients connects with master and restart
the service
or is there any other way for doing so?

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





-- 
Luke Bigum


Information Systems
Ph: +44 (0) 20 3192 2520 
luke.bi...@lmax.com  | http://www.lmax.com
LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN


FX and CFDs are leveraged products that can result in losses exceeding
your deposit.  They are not suitable for everyone so please ensure you
fully understand the risks involved.  The information in this
email is not
directed at residents of the United States of America or any other
jurisdiction where trading in CFDs and/or FX is restricted or
prohibited
by local laws or regulations.

The information in this email and any attachment is confidential
and is
intended only for the named recipient(s). The email may not be
disclosed
or used by any person other than the addressee, nor may it be
copied in
any way. If you are not the intended recipient please notify the
sender
immediately and delete any copies of this message. Any unauthorised
copying, disclosure or distribution of the material in this e-mail is
strictly forbidden.

LMAX operates a multilateral trading facility.  Authorised and
regulated by the Financial Services A

Re: [Puppet Users] Puppet Learner

2012-04-17 Thread Kukki
Thanks guys that was really very helpful and did clear lots of concepts in
my mind for puppet. Absolutely brilliant that means that with collective I
can even launch the instances on EC2 aswel and can even run the required
services on demand within the boxs.

One thing I also like to know say puppet master connected to 20 boxs in a
cluster and all the agents are connected to master and are running in
daemon mode and  doing well,but if i need to do some changes or update few
things in an admin box itself (i.e Box with puppet master) so how do i do
that?  do i need to install puppet client aswel where puppet master is
running to do the required job or puppet master can be use to configure
itself? If yes then how.

Regards,
On 17 April 2012 09:07, Luke Bigum  wrote:

> Overdue,
>
> Walter is right in that you will need to look to another tool, such as
> MCollective. Puppet is not the best at orchestrating operations across
> multiple servers. It can reacting to things on one machine, like an Apache
> servers' config file updating, but there's nothing in core Puppet that's
> going to have your Varnish servers react to this event.
>
> MCollective is a job scheduling frame work that can do what you're after
> and integrates with Puppet quite well. Other products are Func and RunDeck.
>
> -Luke
>
>
> On 17/04/12 00:54, Walter Heck wrote:
>
>> If you are not running your agents in daemon mode, you can have a look
>> at mcollective. It allows you to define a set of servers that you want
>> to do a puppet run on.
>>
>> cheers,
>>
>> Walter
>>
>> On Tue, Apr 17, 2012 at 05:31, OverDue Ocean
>>  wrote:
>>
>>> Hi Guys, Let me Introduce myself as  self learner and very new to
>>> puppet and I am sure that now on I am staying here in this group for
>>> long and keep asking questions,
>>>
>>> I am sorry if my message annoys you or if its a bit childish please
>>> forgive me but i believes that if you want to learn you should ask,
>>>
>>> My Question is :
>>>
>>> I have a server running puppet Master and 8 clients are connected with
>>> Master and every half an hour clients pulls up there configuration if
>>> requires from master and update themselves, but if need to restart
>>> Apache on 4 of them and have to restart varnish in the remaining 4 all
>>> in a sudden then how i will do that? do I need to wait for the next
>>> half an hour that clients connects with master and restart the service
>>> or is there any other way for doing so?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Puppet Users" group.
>>> To post to this group, send email to puppet-users@googlegroups.com.
>>> To unsubscribe from this group, send email to puppet-users+unsubscribe@*
>>> *googlegroups.com .
>>> For more options, visit this group at http://groups.google.com/**
>>> group/puppet-users?hl=en
>>> .
>>>
>>>
>>
>>
>
> --
> Luke Bigum
>
> Information Systems
> Ph: +44 (0) 20 3192 2520
> luke.bi...@lmax.com | http://www.lmax.com
> LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN
>
>
> FX and CFDs are leveraged products that can result in losses exceeding
> your deposit.  They are not suitable for everyone so please ensure you
> fully understand the risks involved.  The information in this email is not
> directed at residents of the United States of America or any other
> jurisdiction where trading in CFDs and/or FX is restricted or prohibited
> by local laws or regulations.
>
> The information in this email and any attachment is confidential and is
> intended only for the named recipient(s). The email may not be disclosed
> or used by any person other than the addressee, nor may it be copied in
> any way. If you are not the intended recipient please notify the sender
> immediately and delete any copies of this message. Any unauthorised
> copying, disclosure or distribution of the material in this e-mail is
> strictly forbidden.
>
> LMAX operates a multilateral trading facility.  Authorised and regulated
> by the Financial Services Authority (firm registration number 509778) and
> is registered in England and Wales (number 06505809). Our registered
> address is Yellow Building, 1A Nicholas Road, London, W11
> 4AN.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users+unsubscribe@**
> googlegroups.com .
> For more options, visit this group at http://groups.google.com/**
> group/puppet-users?hl=en
> .
>
>

-- 
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.googl

[Puppet Users] Functionality provided puppet dashboard.

2012-04-17 Thread mangesh sawant
Hi All,

can we use puppet dashboard for following requirements.

1.   List all the nodes with the role they play.
2.   View the binary versions on the nodes and also the node
status.
3.   Ability to start / stop a node.
4.   Have an interface to view logs from all nodes  - Logs
generated by services running on nodes.

i.e in short can we control/view status/view logs of services running
on other nodes/machines using puppet dashboard.

Thanks,
Mangesh.

-- 
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 get ruby-shadow installed before trying to make users,groups

2012-04-17 Thread Paul Hinze
On Mon, Apr 16, 2012 at 4:55 PM, Steve Roberts  wrote:
> But since the provider has already clipped the attributes they don't
> get set in the first run.
>
> when run a second time the attributes do get set correctly, but that
> seems a bit kludgy to have to run puppet twice to get the desired
> affect.

I've run into this too, and worked around it by considering
ruby-shadow as a "prerequisite" for puppet, and therefore taking
responsibility for that package up to my bootstrapping scripts. IOW,
it is one of the short list of packages that need to be there for
puppet to run successfully. In my case, that means adding it to a
Debian pre-seed config.

I'd be curious to know if there's any other way to work around
provider dependencies like these in a cleaner way though.

-- 
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: collecting resources for iteration in a template

2012-04-17 Thread Jonathon Anderson
On Tuesday, April 17, 2012 8:46:33 AM UTC+3, Wil Cooley wrote:
>
> Have you considered instead using something like the "file fragment 
> pattern"? Basically, you add 'notifiy' to sysctl::variable resources 
> to notify an exec that rebuilds sysctl.conf [...]


Yeah, that's what we're already doing.  I just dislike distributing a 
script to do something that, in my opinion, should be part of assembling 
the catalog in the first place.  It's also stateful (to the state at which 
the fragment is first distributed), and, thus, fragile.  (A failure 
rebuilding once will not be repaired on subsequent runs unless the 
fragments or the script change.)

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/EWxjREZK9RMJ.
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: collecting resources for iteration in a template

2012-04-17 Thread Luke Bigum
Just in case you haven't seen it, RIP's original concat module: 
https://github.com/ripienaar/puppet-concat


It hides a lot of the concatenation implementation detail in defined 
types and the temporary file fragments are stored under /var/lib/puppet/.


On 17/04/12 06:46, Wil Cooley wrote:

On Apr 16, 1:45 am, Jonathon Anderson  wrote:

I have a `sysctl::variable` defined type that creates files in
`/etc/sysctl.d`.  Some operating systems (*cough*SLES10*cough*) don't read
sysctl settings from `/etc/sysctl.d`, though, and expect all settings to be
in a single file, `/etc/sysctl.conf`.  For such operating systems, I'd like
to define the content of that file with a template that references the
values of the `sysctl::variable`s.

In the Puppet DSL I can collect all fragments with language like
`Sysctl::Variable<| |>`.  How can I do something similar in a template such
that I can access the variable names and values?  For example:

Have you considered instead using something like the "file fragment
pattern"? Basically, you add 'notifiy' to sysctl::variable resources
to notify an exec that rebuilds sysctl.conf from sysctl.d (basically
"cat /etc/sysctl.d/*.conf>  /etc/sysctl.conf").

http://projects.puppetlabs.com/projects/puppet/wiki/Generating_a_config_file_from_fragments

(I'm not sure the special concatenation script is really necessary;
you can have the exec notify the service to reload if necessary and
the 'for' loop is unnecessary with shell wildcards. At least, that's
how we do it at work.)

Wil




--
Luke Bigum

Information Systems
Ph: +44 (0) 20 3192 2520
luke.bi...@lmax.com | http://www.lmax.com
LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN


FX and CFDs are leveraged products that can result in losses exceeding
your deposit.  They are not suitable for everyone so please ensure you
fully understand the risks involved.  The information in this email is not
directed at residents of the United States of America or any other
jurisdiction where trading in CFDs and/or FX is restricted or prohibited
by local laws or regulations.

The information in this email and any attachment is confidential and is
intended only for the named recipient(s). The email may not be disclosed
or used by any person other than the addressee, nor may it be copied in
any way. If you are not the intended recipient please notify the sender
immediately and delete any copies of this message. Any unauthorised
copying, disclosure or distribution of the material in this e-mail is
strictly forbidden.

LMAX operates a multilateral trading facility.  Authorised and regulated 
by the Financial Services Authority (firm registration number 509778) and
is registered in England and Wales (number 06505809). 
Our registered address is Yellow Building, 1A Nicholas Road, London, W11

4AN.

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

2012-04-17 Thread Luke Bigum

Overdue,

Walter is right in that you will need to look to another tool, such as 
MCollective. Puppet is not the best at orchestrating operations across 
multiple servers. It can reacting to things on one machine, like an 
Apache servers' config file updating, but there's nothing in core Puppet 
that's going to have your Varnish servers react to this event.


MCollective is a job scheduling frame work that can do what you're after 
and integrates with Puppet quite well. Other products are Func and RunDeck.


-Luke

On 17/04/12 00:54, Walter Heck wrote:

If you are not running your agents in daemon mode, you can have a look
at mcollective. It allows you to define a set of servers that you want
to do a puppet run on.

cheers,

Walter

On Tue, Apr 17, 2012 at 05:31, OverDue Ocean  wrote:

Hi Guys, Let me Introduce myself as  self learner and very new to
puppet and I am sure that now on I am staying here in this group for
long and keep asking questions,

I am sorry if my message annoys you or if its a bit childish please
forgive me but i believes that if you want to learn you should ask,

My Question is :

I have a server running puppet Master and 8 clients are connected with
Master and every half an hour clients pulls up there configuration if
requires from master and update themselves, but if need to restart
Apache on 4 of them and have to restart varnish in the remaining 4 all
in a sudden then how i will do that? do I need to wait for the next
half an hour that clients connects with master and restart the service
or is there any other way for doing so?

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







--
Luke Bigum

Information Systems
Ph: +44 (0) 20 3192 2520
luke.bi...@lmax.com | http://www.lmax.com
LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN


FX and CFDs are leveraged products that can result in losses exceeding
your deposit.  They are not suitable for everyone so please ensure you
fully understand the risks involved.  The information in this email is not
directed at residents of the United States of America or any other
jurisdiction where trading in CFDs and/or FX is restricted or prohibited
by local laws or regulations.

The information in this email and any attachment is confidential and is
intended only for the named recipient(s). The email may not be disclosed
or used by any person other than the addressee, nor may it be copied in
any way. If you are not the intended recipient please notify the sender
immediately and delete any copies of this message. Any unauthorised
copying, disclosure or distribution of the material in this e-mail is
strictly forbidden.

LMAX operates a multilateral trading facility.  Authorised and regulated 
by the Financial Services Authority (firm registration number 509778) and
is registered in England and Wales (number 06505809). 
Our registered address is Yellow Building, 1A Nicholas Road, London, W11

4AN.

--
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 get ruby-shadow installed before trying to make users,groups

2012-04-17 Thread Luke Bigum

Hi Steve,

This is a long standing 'chicken and egg' situation with Puppet 
installing dependencies for it's own providers. There was an issue I 
thought I was watching, but I can't find it now to quote it to you.


People do different things: they either put up with the 2 pass approach, 
or for more involved providers they write a Fact to say whether the 
system the Agent is running on has the necessary requirements and then 
selectively defines resources.


-Luke

On 16/04/12 22:55, Steve Roberts wrote:

I know I need to have ruby-shadow installed to get puppet to be able
to manage shadow file based passwords.

so tried to code that up in a puppet manifest like this:
===
class strobenet {

   package { 'ruby-shadow':
 ensure =>  'present',
   }

   user { 'tuser':
 ensure   =>  'present',
 comment  =>  'Test User',
 gid  =>  '302',
 home =>  '/home/tuser',
 password =>  '***',
 password_max_age =>  '99000',
 password_min_age =>  '5',
 shell=>  '/bin/tcsh',
 uid  =>  '302',
   }
   group { 'tuser':
 ensure =>  'present',
 gid=>  '302',
   }

   Package['ruby-shadow'] ->  User<| |>
}
===

the problem is that when it runs the first time the puppet User
provider says it can't handle manages_passwords and
manages_password_age during init and so clips those attributes.

Then it goes to apply the actual resources and does the package first,
then the user.

But since the provider has already clipped the attributes they don't
get set in the first run.

when run a second time the attributes do get set correctly, but that
seems a bit kludgy to have to run puppet twice to get the desired
affect.




--
Luke Bigum

Information Systems
Ph: +44 (0) 20 3192 2520
luke.bi...@lmax.com | http://www.lmax.com
LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN


FX and CFDs are leveraged products that can result in losses exceeding
your deposit.  They are not suitable for everyone so please ensure you
fully understand the risks involved.  The information in this email is not
directed at residents of the United States of America or any other
jurisdiction where trading in CFDs and/or FX is restricted or prohibited
by local laws or regulations.

The information in this email and any attachment is confidential and is
intended only for the named recipient(s). The email may not be disclosed
or used by any person other than the addressee, nor may it be copied in
any way. If you are not the intended recipient please notify the sender
immediately and delete any copies of this message. Any unauthorised
copying, disclosure or distribution of the material in this e-mail is
strictly forbidden.

LMAX operates a multilateral trading facility.  Authorised and regulated 
by the Financial Services Authority (firm registration number 509778) and
is registered in England and Wales (number 06505809). 
Our registered address is Yellow Building, 1A Nicholas Road, London, W11

4AN.

--
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 puppet augeas and hash keys ?

2012-04-17 Thread Luke Bigum

On 16/04/12 21:08, puppetguest wrote:

Hi,

if possible can someone post a working example please ?

I am using hiera =>  puppet =>  augeas.

cat myserver.yaml
---
myserver:
   "Birthday": '1'
   "Debug": '5'

The no. of settings will change, so i would like to use a hash here.


The hiera lookup works already:


hiera -c /etc/puppet/hiera.yaml -h myserver

{"Debug"=>"5", "Birthday"=>"1"}


I can save a single value via hiera =>  puppet =>  augeas sucessfully
when i know its variable name.

What i am searching for is the proper syntax to use 'hiera_hash'
and save all settings into augeas with 'set $name $value' coming from
the yaml-file.

In perl it would be have been like this:
foreach $key (keys %hash){
 print "$key $hash{$key}\n";
}

Thank you


Just to jump on you before you start, Puppet has no concept of loops, so 
your Perl example doesn't translate. However, there are some other 
approaches to the problem.


What would suit you best is the create_resources function: 
http://docs.puppetlabs.com/references/2.7.9/function.html#createresources


Your manifest would look something like this:

**
define augeas_wrapper (key, value) {
  augeas{ "some_file":
changes => [ "set $key $val" ]
  }
}

$augeas_hash = hiera_hash($fqdn)

create_resources('augeas_wrapper', $augeas_hash)
**

Make sure that hiera_hash returns a hash in the format that 
create_resources is expecting.


-Luke

--
Luke Bigum

Information Systems
Ph: +44 (0) 20 3192 2520
luke.bi...@lmax.com | http://www.lmax.com
LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN


FX and CFDs are leveraged products that can result in losses exceeding
your deposit.  They are not suitable for everyone so please ensure you
fully understand the risks involved.  The information in this email is not
directed at residents of the United States of America or any other
jurisdiction where trading in CFDs and/or FX is restricted or prohibited
by local laws or regulations.

The information in this email and any attachment is confidential and is
intended only for the named recipient(s). The email may not be disclosed
or used by any person other than the addressee, nor may it be copied in
any way. If you are not the intended recipient please notify the sender
immediately and delete any copies of this message. Any unauthorised
copying, disclosure or distribution of the material in this e-mail is
strictly forbidden.

LMAX operates a multilateral trading facility.  Authorised and regulated 
by the Financial Services Authority (firm registration number 509778) and
is registered in England and Wales (number 06505809). 
Our registered address is Yellow Building, 1A Nicholas Road, London, W11

4AN.

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