[Puppet Users] Re: Anyone know a good tool for 'watching' configurations?
Hi, I know it's been a while since this original posting but if you are still looking for a solution to 'track changes' please check out the tool we built, www.metaforsoftware.com. We just opened it up to free beta. I think it can help you. On Tuesday, January 24, 2012 8:02:03 AM UTC-8, NixFU wrote: > > Now that we have configuration management for our OS and we are > actively managing our operating systems nearly hands off we want to > now start doing some configuration mgmt of our applications. > > We don't frankly see having all our application teams use puppet or > anything else to actively manage their applications. What we would > like to do is watch the applications and know when things change. > Basically, watch the directories that the developers put their > applications into and keep a history of what changes and when. > > Does anyone have any idea on if there are any tools that can provide > the ability to watch directories for changes like that. > > I know there is auditd that can do this, as well as maybe an intrusion > detection tool like AIDE, but those solutions would involve lots of > raw data and not much human readable stuff. I suppose we could write > something to take all that data, digest it and report on it. > > But I was wondering if anyone knows of a tool that would do this type > of function and provide some human friendly data and reports etc.. > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Node definition from file (heterogeneous hostnames)
bump -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] How to indicate multiple dependency?
Are those packages defined in different files? If they are in the same
file you can just do the following
package {['pgk1', 'pkg2']:
ensure => 'installed',
} ->
file { 'file1':
...
}
If they are in different files you maybe will be able to hack something
with the "spaceship operator" but it will hard and might brake in the
future because of circular dependencies :(
--
Nikola
On Wed, May 08, 2013 at 03:52:44AM -0700, Bret Wortman wrote:
> What's the right/best way to indicate that a particular entry in a manifest
> (a file in this case) depends on successful installation of over 30
> packages, all indicated in the same manifest? I could do this, but it seems
> cumbersome:
>
> package { 'pkg1': }
> Package['pkg1'] -> File['file1']
>
> package { 'pkg2': }
> Package['pkg2'] -> File['file2']
> :
> :
> file { 'file2':
> path => '/path/to/file2',
> :
> }
>
> There must be a better way that I'm just not seeing. Thanks!
>
>
> Bret Wortman
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] hiera can't see a value on a puppet client, but the hiera app on the server can
On my server /etc/puppet/hiera.yaml is a symbolic link that points to /etc/hiera.yaml, so I don't think that's the issue. On Wednesday, May 8, 2013 11:52:04 PM UTC-7, Johan De Wit wrote: > > Hi Eric, > > By default, hiera-cli uses /etc/hiera.yaml, hiera-puppet uses > /etc/puppet/hiera.yaml as config file. That was my mistake starting using > hiera cli for testing. > > Btw, "facter --puppet region" wil also work, so no need for grep anymore. > > > On 05/09/2013 04:34 AM, Eric wrote: > > When I run puppet on a client it says it can't find a parameter in hiera, > but If I run the hiera application on my puppet master and give it the same > facts that my client has, it finds them just fine. Why is that? > > Here's how my client sees itself: > > [root@tag5-4-qa-sjc ~]# facter --puppet | grep region > region => northamerica > [root@tag5-4-qa-sjc ~]# facter --puppet | grep datacenter > datacenter => sjc > [root@tag5-4-qa-sjc ~]# facter --puppet | grep environment > environment => qa > [root@tag5-4-qa-sjc ~]# facter --puppet | grep machinetype > machinetype => tag > [root@tag5-4-qa-sjc ~]# facter --puppet | grep hostname > hostname => tag5-4-qa-sjc > > I run puppet and get this error: > > err: Could not retrieve catalog from remote server: Error 400 on SERVER: > Could not find data item ak_auth_primary in any Hiera data file and no > default supplied at /etc/puppet/manifests/site.pp:11 on node > tag5-4-qa-sjc.domain.net > > on my puppet master server: > > $ hiera ak_auth_primary region=northamerica datacenter=sjc environment=qa > > Answer: ops1-1-qa-sjc > > $ hiera ak_auth_primary region=northamerica datacenter=sjc environment=qa > machinetype=tag hostname=tag5-4-qa-sjc > > Answer: ops1-1-qa-sjc > > Is it because I'm using an older version of Puppet with Hiera? I'm not > quite ready to upgrade to version 3 yet, but I plan to. > > [root@tag5-4-qa-sjc ~]# rpm -qa | grep puppet > puppet-2.7.14-1.el6.noarch > > user@puppet-server$ sudo rpm -qa | egrep '(puppet|hiera)' > puppet-2.7.12-1.el6.noarch > puppet-dashboard-1.2.6-1.el6.noarch > hiera-1.2.1-1.el5.noarch > puppet-server-2.7.12-1.el6.noarch > hiera-puppet-1.0.0-1.el5.noarch > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users...@googlegroups.com . > To post to this group, send email to puppet...@googlegroups.com > . > Visit this group at http://groups.google.com/group/puppet-users?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > -- > Johan De Wit > > Open Source Consultant > Red Hat Certified Engineer(805008667232363) > Puppet Certified Professional 2013 (PCP006) > _ > > Open-Future Phone +32 (0)2/255 70 70 > Zavelstraat 72Fax +32 (0)2/255 70 71 > 3071 KORTENBERG Mobile +32 (0)474/42 40 73 > BELGIUM http://www.open-future.be > _ > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Puppermaster certificate expired
nobody really ever had to deal with this ? Dne pondělí, 6. května 2013 10:03:15 UTC+2 Tomáš Brandýský napsal(a): > > Hello, > > We've been running puppet for 5 years until the last week when the > certificate on the puppet server is expired. > We were looking for a procedure describing how to create a new server > certificate without a need to reconfigure certificates on puppet clients > (about 100 servers) but we couldn't find anything regarding this issue > within puppet's documentation. > Is there any best practice guidance to easily fix the problem when puppet > master certificate is expired ? > > Thank you > > Tomas > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: hiera can't see a value on a puppet client, but the hiera app on the server can
Hi Campee, On Thursday, May 9, 2013 3:34:20 AM UTC+1, Campee wrote: > > I run puppet and get this error: > > err: Could not retrieve catalog from remote server: Error 400 on SERVER: > Could not find data item ak_auth_primary in any Hiera data file and no > default supplied at /etc/puppet/manifests/site.pp:11 on node > tag5-4-qa-sjc.domain.net > > on my puppet master server: > > $ hiera ak_auth_primary region=northamerica datacenter=sjc environment=qa > > Answer: ops1-1-qa-sjc > > $ hiera ak_auth_primary region=northamerica datacenter=sjc environment=qa > machinetype=tag hostname=tag5-4-qa-sjc > > Can you test Hiera like this (on your Puppet Master), it uses the Facts cache of your node, rather than you filling in all the gaps by hand, and thus is a more thorough test: hiera -c /etc/puppet/hiera.yaml -y /var/lib/puppet/yaml/facts/ tag5-4-qa-sjc.domain.net.yaml ak_auth_primary --debug You should get some helpful debug trace through what Hiera is doing and what data files it is trying to open, in order: DEBUG: Thu May 24 13:18:53 + 2012: Hiera JSON backend starting DEBUG: Thu May 24 13:18:53 + 2012: Looking up key 'ak_auth_primary' in JSON backend DEBUG: Thu May 24 13:18:53 + 2012: Backend datadir for json is an Array, multiple data dirs to search DEBUG: Thu May 24 13:18:53 + 2012: Looking in data dir /etc/puppet/private/ DEBUG: Thu May 24 13:18:53 + 2012: Looking at hierarchy source tag5-4-qa-sjc.domain.net DEBUG: Thu May 24 13:18:53 + 2012: Cannot find datafile /etc/puppet/private/tag5-4-qa-sjc.domain.net.json, skipping DEBUG: Thu May 24 13:18:53 + 2012: Looking at hierarchy source common DEBUG: Thu May 24 13:18:53 + 2012: Cannot find datafile /etc/puppet/private/common.json, skipping DEBUG: Thu May 24 13:18:53 + 2012: Looking at hierarchy source tag5-4-qa-sjc.domain.net -Luke -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Foreman and Puppet managing templates question
Thanks for the reply. You've answered my question. I'll post back if I need anymore help. On Tuesday, May 7, 2013 3:49:38 PM UTC+1, Ashley Penney wrote: > > Foreman does replace nodes.pp. It acts as an 'ENC', the external node > classifier. We'd need more details on what you're doing with templates in > Puppet and nodes.pp to really answer this question. Are you thinking in > terms of how you'd put variables into nodes directly with Foreman? There's > space in the host page in Foreman for adding variables, under "Parameters" > if you want to add them directly. A better approach to this is to look > into Hiera, where you build a hierarchal data store that relies on various > facts to provide the appropriate contents to variables to then consume in > erb templates. > > Ideally you'd find ways to not have node specific information, but if you > did need it you'd add $::fqdn to your hiera hierarchy and then add > nodename.yaml files for each node where you listed out all the variables. > This has the big benefit of remaining version controlled, unlike parameter > entries in Foreman. > > As I said earlier, if you give some use cases we can probably explain this > all a little better to you. > > Thanks, > > > On Tue, May 7, 2013 at 9:53 AM, timo >wrote: > >> Hi, >> >> I have just started to use Foreman 1.1. I have been using Puppet for a >> while and have some custom modules and ones that have been dragged down >> from git etc. >> >> I am using nodes.pp in Puppet to assign classes and template entries to >> hosts. >> >> So is Foreman meant to eliminate my need for a nodes.pp? How do I manage >> my erb templates in Puppet without a nodes.pp? >> >> Thanks, >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to puppet-users...@googlegroups.com . >> To post to this group, send email to puppet...@googlegroups.com >> . >> Visit this group at http://groups.google.com/group/puppet-users?hl=en. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Node definition from file (heterogeneous hostnames)
Greetings Robin!
What about this solution? It's a quick-fix, but it might work well as you
want it to? Do a script which contains (see it as pseudocode):
for each hostname in hosts
do
echo "node '$hostname' {include run_script}" >>
/etc/puppet/manifests/site.pp
done
What do you other guys think of this solution? To risky to edit
/etc/puppet/manifests/site.pp with a script?
Yours,
Simon
Den torsdagen den 9:e maj 2013 kl. 09:06:23 UTC+2 skrev Robin Jonsson:
>
> bump
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: proxy required
Excuse again
This is the output of my node
puppet agent --server=puppet.x.x.x. --no-daemonize --verbose --onetime
info: Caching catalog for rlltas05a.x.x.x.x.
info: Applying configuration version '1368021386'
notice: Finished catalog run in 0.01 seconds
this is my site.pp
node 'rlltas05a' {
#include screen
#include run
include epel
}
and this is my path for epel module
/etc/puppet/modules/epel/manifests
I ve installed **
stahnma/epel with puppet module install
procedure
What is my fault?? Nothing happen on my node .an error a fault an
exception nothing...
Thank you in advance for all your precious support
Il giorno mercoledì 8 maggio 2013 11:46:45 UTC+2, Francesco ha scritto:
>
> Excuse for my question
> I ve installed module and incuded it in file site pp.
> But nothin happen
> Where can i check llog files in puppet?
> Tahnk you very much again
> Here you are site .pp
> node 'rlltas05a
> #include screen
> #include run
> include epel
>
>
>
> On Wednesday, May 8, 2013 12:39:53 AM UTC+2, Francesco wrote:
>>
>> Hy I m new to puppet.
>> I 'd like to install epel.repo on a my node and this is the module that I
>> ve created
>>
>> class epel {
>>
>> package { 'epel':
>> provider => 'rpm',
>> ensure => installed,
>> source => '
>> http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
>> '
>> }
>> }
>>
>> Now my connection on node when I try to apply configuration is the
>> following
>> info: Applying configuration version '1367962540'
>> err: /Stage[main]/Epel/Package[epel]/ensure: change from absent to
>> present failed: Execution of '/bin/rpm -i --oldpackage
>> http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm'
>> returned 1: curl: (7) couldn't connect to host
>> error: skipping
>> http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm-
>> transfer failed
>>
>> If I set a proxy on my linux server it give me error 407 (require
>> authentication)
>> How can i setup a proxy in my /etc/puppet/modules/epel/init,pp
>> I read of a params.pp , but I cannot understand how to configure it
>>
>>
>> this is my site.pp
>> node rllbck02{
>> include epel
>>
>>
>> thank you very much and good night
>>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Bug in puppetdb-ssl-setup?
Hi Jeffrey,
It is a 'bug', and a known one at that:
http://projects.puppetlabs.com/issues/17523
Feel free to watch/vote for it.
ken.
On Wed, May 8, 2013 at 7:04 PM, Jeffrey Watts wrote:
> I'm setting up PuppetDB for the first time (and on OpenSuSE, yay). After
> some tinkering I've gotten the package rebuilt and working. However, on
> first setup puppetdb-ssl-setup fails with the following message:
>
> # /usr/sbin/puppetdb-ssl-setup
> cp: cannot stat
> `/var/lib/puppet/ssl/private_keys/puppetmaster.mycompany.com.pem': No such
> file or directory
>
> I'm planning on running PuppetDB on a separate box from my Puppetmaster.
> Digging into the script a bit, the problem seems to be with the use of the
> 'puppet master' command to find the certificate information. I use a
> monolithic puppet.conf for my master and agents, so it's picking up the
> master's configuration instead of the agent's.
>
> Anyhow, this small diff seems to get me past the problem. Is this a bug?
>
> Thanks,
> Jeffrey.
>
>
> # diff -u /usr/sbin/puppetdb-ssl-setup puppetdb-ssl-setup
> --- /usr/sbin/puppetdb-ssl-setup 2013-05-06 11:04:25.0 -0500
> +++ puppetdb-ssl-setup 2013-05-08 12:57:47.423096218 -0500
> @@ -94,10 +94,10 @@
>fqdn=`facter hostname`
> fi
>
> -mycertname=`puppet master --confdir=$agent_confdir --vardir=$agent_vardir
> --configprint certname`
> -mycert=`puppet master --confdir=$agent_confdir --vardir=$agent_vardir
> --configprint hostcert`
> -myca=`puppet master --confdir=$agent_confdir --vardir=$agent_vardir
> --configprint localcacert`
> -privkey=`puppet master --confdir=$agent_confdir --vardir=$agent_vardir
> --configprint hostprivkey`
> +mycertname=`puppet agent --confdir=$agent_confdir --vardir=$agent_vardir
> --configprint certname`
> +mycert=`puppet agent --confdir=$agent_confdir --vardir=$agent_vardir
> --configprint hostcert`
> +myca=`puppet agent --confdir=$agent_confdir --vardir=$agent_vardir
> --configprint localcacert`
> +privkey=`puppet agent --confdir=$agent_confdir --vardir=$agent_vardir
> --configprint hostprivkey`
>
> pw_file=${puppetdb_confdir}/ssl/puppetdb_keystore_pw.txt
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] hiera can't see a value on a puppet client, but the hiera app on the server can
I believe you are missing a basic concept: Hiera is for the puppet MASTER, not the agent/client. >From http://docs.puppetlabs.com/hiera/1/installing.html#installing-hiera Installing Hiera If you are using Hiera with Puppet, you should install it on your puppet master server(s); it is optional and unnecessary on agent nodes. (If you are using a standalone puppet apply site, every node should have Hiera.) Also, hiera and facter are two distinctly different beasties. You can use facter-facts in your heirarchy definitions to organize your data, but info from hiera is different from info from facter. Facter operates at the agent/client level while hiera is at the puppet-master level. HTH “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin & Hobbes) - Original Message - From: "Eric" To: puppet-users@googlegroups.com Sent: Wednesday, May 8, 2013 10:34:20 PM Subject: [Puppet Users] hiera can't see a value on a puppet client, but the hiera app on the server can When I run puppet on a client it says it can't find a parameter in hiera, but If I run the hiera application on my puppet master and give it the same facts that my client has, it finds them just fine. Why is that? Here's how my client sees itself: [root@tag5-4-qa-sjc ~]# facter --puppet | grep region region => northamerica [root@tag5-4-qa-sjc ~]# facter --puppet | grep datacenter datacenter => sjc [root@tag5-4-qa-sjc ~]# facter --puppet | grep environment environment => qa [root@tag5-4-qa-sjc ~]# facter --puppet | grep machinetype machinetype => tag [root@tag5-4-qa-sjc ~]# facter --puppet | grep hostname hostname => tag5-4-qa-sjc I run puppet and get this error: err: Could not retrieve catalog from remote server: Error 400 on SERVER: Could not find data item ak_auth_primary in any Hiera data file and no default supplied at /etc/puppet/manifests/site.pp:11 on node tag5-4-qa-sjc.domain.net on my puppet master server: $ hiera ak_auth_primary region=northamerica datacenter=sjc environment=qa Answer: ops1-1-qa-sjc $ hiera ak_auth_primary region=northamerica datacenter=sjc environment=qa machinetype=tag hostname=tag5-4-qa-sjc Answer: ops1-1-qa-sjc Is it because I'm using an older version of Puppet with Hiera? I'm not quite ready to upgrade to version 3 yet, but I plan to. [root@tag5-4-qa-sjc ~]# rpm -qa | grep puppet puppet-2.7.14-1.el6.noarch user@puppet-server$ sudo rpm -qa | egrep '(puppet|hiera)' puppet-2.7.12-1.el6.noarch puppet-dashboard-1.2.6-1.el6.noarch hiera-1.2.1-1.el5.noarch puppet-server-2.7.12-1.el6.noarch hiera-puppet-1.0.0-1.el5.noarch -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en . For more options, visit https://groups.google.com/groups/opt_out . -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Bug in puppetdb-ssl-setup?
Thanks Ken!
J.
On Thu, May 9, 2013 at 7:26 AM, Ken Barber wrote:
> Hi Jeffrey,
>
> It is a 'bug', and a known one at that:
>
> http://projects.puppetlabs.com/issues/17523
>
> Feel free to watch/vote for it.
>
> ken.
>
> On Wed, May 8, 2013 at 7:04 PM, Jeffrey Watts
> wrote:
> > I'm setting up PuppetDB for the first time (and on OpenSuSE, yay). After
> > some tinkering I've gotten the package rebuilt and working. However, on
> > first setup puppetdb-ssl-setup fails with the following message:
> >
> > # /usr/sbin/puppetdb-ssl-setup
> > cp: cannot stat
> > `/var/lib/puppet/ssl/private_keys/puppetmaster.mycompany.com.pem': No
> such
> > file or directory
> >
> > I'm planning on running PuppetDB on a separate box from my Puppetmaster.
> > Digging into the script a bit, the problem seems to be with the use of
> the
> > 'puppet master' command to find the certificate information. I use a
> > monolithic puppet.conf for my master and agents, so it's picking up the
> > master's configuration instead of the agent's.
> >
> > Anyhow, this small diff seems to get me past the problem. Is this a bug?
> >
> > Thanks,
> > Jeffrey.
> >
> >
> > # diff -u /usr/sbin/puppetdb-ssl-setup puppetdb-ssl-setup
> > --- /usr/sbin/puppetdb-ssl-setup 2013-05-06 11:04:25.0 -0500
> > +++ puppetdb-ssl-setup 2013-05-08 12:57:47.423096218 -0500
> > @@ -94,10 +94,10 @@
> >fqdn=`facter hostname`
> > fi
> >
> > -mycertname=`puppet master --confdir=$agent_confdir
> --vardir=$agent_vardir
> > --configprint certname`
> > -mycert=`puppet master --confdir=$agent_confdir --vardir=$agent_vardir
> > --configprint hostcert`
> > -myca=`puppet master --confdir=$agent_confdir --vardir=$agent_vardir
> > --configprint localcacert`
> > -privkey=`puppet master --confdir=$agent_confdir --vardir=$agent_vardir
> > --configprint hostprivkey`
> > +mycertname=`puppet agent --confdir=$agent_confdir --vardir=$agent_vardir
> > --configprint certname`
> > +mycert=`puppet agent --confdir=$agent_confdir --vardir=$agent_vardir
> > --configprint hostcert`
> > +myca=`puppet agent --confdir=$agent_confdir --vardir=$agent_vardir
> > --configprint localcacert`
> > +privkey=`puppet agent --confdir=$agent_confdir --vardir=$agent_vardir
> > --configprint hostprivkey`
> >
> > pw_file=${puppetdb_confdir}/ssl/puppetdb_keystore_pw.txt
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Puppet Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to puppet-users+unsubscr...@googlegroups.com.
> > To post to this group, send email to puppet-users@googlegroups.com.
> > Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] PuppetDB issues
I seem to get this off and on, but not consistently. Is yours every run? puppet-master[7020]: Failed to submit 'replace facts' command for ue1a-devdb01.ineu.us to PuppetDB at puppet.example.com:8081: SSL_connect SYSCALL returned=5 errno=0 state=SSLv3 read finished A I am also on puppetdb 1.3.0, upgraded from 1.1. On May 8, 2013, at 8:13 AM, kl.puppetu...@gmail.com wrote: > Hi all, > > I'm setting up puppetdb to for storing facts et cetera. I installed > puppetdb-1.3.0-1.el6.noarch.rpm on my puppetdb.local host (which is > puppetized). This seems to work, service starts :). > > When I edit the settings on my puppetmaster (puppet.local), something goes > wrong. I am following the guide [1]. I put the settings (storeconfigs = true, > storeconfigs_backend=puppetdb) on my puppetmaster and restart the > puppetmaster. When I do a --onetime on a node, I get the following error: > > Error: Could not retrieve catalog from remote server: Error 400 on SERVER: > Failed to submit 'replace facts' command for gaia.local > to PuppetDB at puppetdb.local:8081: SSL_connect SYSCALL returned=5 errno=0 > state=SSLv3 read finished A > Warning: Not using cache on failed catalog > Error: Could not retrieve catalog; skipping run > > > I'm thinking the problem is that I'm using gaia.local as the host name. > Puppet.local is an alias for gaia.local. > > > Extra info: > For completeness, the error on the puppetdb is: > WARN [qtp788652058-42] [io.nio] javax.net.ssl.SSLHandshakeException: null > cert chain > > keystore.jks on the puppetdb has puppetdb.local with print > 8C:E6:D1:02:89:9E:25:D3:E8:8F:63:75:8F:85:59:B5:17:BE:F8:47 > truststore.jks on puppetdb has 'puppetdb ca' with print > 62:8F:76:CE:5C:9D:23:B0:1D:9D:7A:2F:39:5A:74:43:1D:BB:D9:1E > > $ openssl verify -CAfile /etc/puppet/ssl/ca/ca_crt.pem `puppet master > --configprint hostcert` > /etc/puppet/ssl/certs/puppetdb.kahuna.local.pem: OK > > (yes, I have the SSL certs in /etc/puppet) > > If someone could help, that would be great. I'm running in circles here. > Thanks! > kl > > [1] http://docs.puppetlabs.com/puppetdb/1.3/connect_puppet_master.html > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users+unsubscr...@googlegroups.com. > To post to this group, send email to puppet-users@googlegroups.com. > Visit this group at http://groups.google.com/group/puppet-users?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Puppermaster certificate expired
On Monday, May 6, 2013 10:03:15 AM UTC+2, Tomáš Brandýský wrote: > Hello, > > We've been running puppet for 5 years until the last week when the > certificate on the puppet server is expired. > We were looking for a procedure describing how to create a new server > certificate without a need to reconfigure certificates on puppet clients > (about 100 servers) but we couldn't find anything regarding this issue > within puppet's documentation. > Is there any best practice guidance to easily fix the problem when puppet > master certificate is expired ? > > I just discovered that our CA expires next year because of this post, thanks for that :) Anyway I think the easy way is to setup some autosigning of clients after creating a new CA. Think you will have to clean the ssl-dir on clients for this to work, though. Since we are going to make a brand new puppetmaster here sometime before our CA expires that will be my approach to make the transition smoother. /Nicolai -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Node definition from file (heterogeneous hostnames)
On Wednesday, May 8, 2013 8:38:52 AM UTC-5, Robin Jonsson wrote:
>
> Thank you for your reply.
>
> First of, we are kinda aware of that we are not using Puppet as it should
> be used with the "state management service". But Puppet seemed to be the a
> great piece of software with great capabilities.
>
> To our problem. Lets say our site.pp looks like this:
>
> #Site.pp
>
> import "nodes_script"
> import "monitor_script"
> import "run_script"
>
> node /^linuxnod\d+$/ {
>include nodes_script
> }
>
> node 'monitor.rosi.local' {
>include monitor_script
> }
>
> All works well with our modules. But we would now like to add the module
> "run_script" to some nodes that can't be "regex:ed". The nodes are present
> in a file named "hosts". Can I in some way include these nodes to the "node
> '' { include run_script }" in site.pp? So that the run_script is for
> those nodes presented in "hosts". If not, any suggestion on how we
> can achieve it?
>
>>
>>
Ah. You want just the node *names* to come from an external file, not
entire node definitions. Sorry, that's not gonna happen.
You have several options. The most similar to what you asked is to in fact
provide a whole node definition (only one is needed) for these exceptional
hosts:
import 'run_script.pp'
node
'node1.my.com',
'node2.my.com',
...
'node42.my.com' {
include run_script
}
Then 'import' that into site.pp. You will recognize that that has the form
of a list of node names, bracketed by a small amount of decoration, so it's
not too different from what you asked.
As I already said, you can also use an ENC instead of a flat file to feed
the information to Puppet, including (but not restricted to) pressing hiera
into service in that effort. For example, to fall back to hiera for
otherwise-unmatched nodes, add something like this to site.pp:
node default {
$classes = hiera('classes')
# $classes could contain 'run_script' where appropriate
include $classes
}
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Are multiple environments broken in puppet?
On Wednesday, May 8, 2013 8:06:27 PM UTC-5, James Kyle wrote: > > I started getting the following errors from my puppet master: > > > Error: Could not retrieve catalog from remote server: Error 400 on > SERVER: Invalid parameter provider at /some/module/manifests/foo.pp > > The module would vary, but the error was always the same. I started > googling, searching lists, etc. And turned up a whole bucket load of issues > that all seem related and are all unresolved: > > #17814, #13858, #12173, #8750, etc. > > Some go back over 2 years and some are current from within the last month, > but they're all linked. > > Am I mistaken/misinterpreting or do they all seem to boil down to > "environments are broken". > > If I am mistaken, what's the workaround? I was really looking forward to > mapping environments to git branches with git hooks. > I think it's fair to say that environments are a bit crippled. Principally, trouble with environments revolves around modules that provide native components (types, providers, or functions) that are not uniform across all defined environments. Where your environment-specific modules do not provide such things (and many don't), environments should work for you. These problems are unlikely to be fixed soon, as they stem from a deep architectural issue. Puppet really needs some kind of internal abstraction with which to group and separate the components associated with each environment, but it doesn't have one, and adding one would likely be a lot of work. Even if PL is persuaded to prioritize the issue, I cannot imagine a solution being released before Puppet 3.3 (and that may be overly optimistic). John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] POssible incompatibility between puppet agent 3.0.1 and puppet master 3.0.2
Dear All, I am using puppet agent v3.0.1 (On FreeBSD), trying to connect to a puppet master v3.0.2 (On Ubuntu) and the puppet agent hangs with the following debug output: *puppet agent --debug --no-daemonize* ... Debug: /File[/var/puppet/ssl/private_keys]: Autorequiring File[/var/puppet/ssl] Debug: /File[/var/puppet/ssl/private]: Autorequiring File[/var/puppet/ssl] Debug: /File[/var/puppet/ssl/private_keys/zg-3..ch.pem]: Autorequiring File[/var/puppet/ssl/private_keys] Debug: /File[/var/puppet/ssl/public_keys/zg-3..ch.pem]: Autorequiring File[/var/puppet/ssl/public_keys] Debug: Finishing transaction 17214983260 [hangs.. and a minute os so later reports..] Error: Could not request certificate: execution expired Error: Could not request certificate: execution expired These is no indication of a connection being made on the puppet master. 1. I have checked with netcat & telnet and confirmed that I able to initiate a connection from the agent to the server and exchange data. 2. The same puppet master has worked correctly with a different FreeBSD agent running Puppet v3.0.2 3. Running tcpdump during the agent run shows that some packets are going back and forth between the agent and server 4. I have run truss on the (FreeBSD) puppet agent command and saw that the agent is getting the following error (twice): read(6,0x80711c3c6,1854) ERR#35 'Resource temporarily unavailable' File handle 6 is from a 'connect' to the puppet master, with the correct IP address and port number (8140) 5. I suspect an agent/master compatibility issue, or perhaps an sl library compatibility. I don't think it's an SSL certificate (no certificate related errors) or time synchronization problem (both systems run NTP). Any hints on how to debug this? Thanks in advance, Alan Hodgkinson P.S. Please ask for any (config) information necessary to help diagnose the problem. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: agent suddenly disabled
On Tuesday, May 1, 2012 12:00:19 PM UTC-4, Eric Lake wrote: > > I am wondering what would cause a puppet client to get into a state like > this. I had a test vm do the same thing to me today. > > > Since nobody else responded first let me say thanks for posting the correct syntax - I googled the error and ended up here. Second, mine was triggered by an application filling my available hard drive space with a log file. I removed the 960 GB log file (from 3 weeks of running, lol) and rebooted and puppet refused to run anymore until doing this. So I'm assuming this is some sort of safety net to keep it from screwing up your system entirely if something goes horribly wrong, like being unable to write temp files, etc. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: High Availability of Puppet server for separate geographical location
On Thu, May 9, 2013 at 12:06 AM, John Warburton wrote: > I suppose all HA solutions are difficult Nah. A service correctly designed to be resilient can be HA with trivial investment. DNS is a good example. It may have blemishes but nobody stresses about its availability. Setup as many tiers of redundancy as you want, easily. Puppet has no need to be centralized -- a git-based puppet setup can handle it just fine. I am writing some tooling for git+puppet (search for ppg in recent posts to this list), and it's trivial to add N-tiers of redundant servers... cheers, m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: High Availability of Puppet server for separate geographical location
On Thu, May 9, 2013 at 10:42 AM, Martin Langhoff wrote: > I am writing some tooling for git+puppet (search for ppg in recent > posts to this list), and it's trivial to add N-tiers of redundant > servers... Heh, so trivial in fact that you can use round-robin DNS and it'll just work :-) I looked into adding the "feature" to ppg... then realized that git plays very well with round-robin DNS. m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: Puppermaster certificate expired
2013/5/9 Nicolai Mollerup > Anyway I think the easy way is to setup some autosigning of clients after > creating a new CA. > Think you will have to clean the ssl-dir on clients for this to work, > though. > > Since we are going to make a brand new puppetmaster here sometime before > our CA expires that will be my approach to make the transition smoother. > we are exactly at the same point: currently moving our puppetmaster on another host, struggling against CA hostname in SSL Certificates and thinking how to approach the refresh of all certificates on agents. Autosigning for some day could be a good approach for us too, since we have our racks with predefined networks IPs and master on amazon, so amazon agents can contact master via internal network. We already manage agents configuration with a puppet module, do you think we can do the SSL substitution with a recipe in puppet itself? -- *sede di PRATO* Via Mino da Fiesole, 5 - 59100*PHONE* +39 0574.5877 *FAX* +39 0574.5877.99 Azienda certificata-Sistema Qualità ISO 9001:2008 e quotata su AIM Italia di Borsa Italiana Le informazioni contenute in questa comunicazione e gli eventuali documenti allegati hanno carattere confidenziale e sono ad uso esclusivo del destinatario. Nel caso questa comunicazione Vi sia pervenuta per errore, Vi informiamo che la sua diffusione e riproduzione è contraria alla legge e preghiamo di darci prontamente avviso e di cancellare quanto ricevuto. This e-mail message and any files transmitted with it contain confidential information intended only for the person(s) to whom it is addressed. If you are not the intended recipient, you are hereby notified that any use or distribution of this e-mail is strictly prohibited, please notify the sender and delete the original message. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: hiera-gpg causing big increase in catalog compile time
Hmm..it seems like a pretty basic use case is an accompanying gpg file for each level of a hierarchy, just to store things like passwords, or sensitive data. Minimizing the use of things like hiera's 3.x data bindings to gain speed in hiera-gpg lookups feels like throwing the baby out with the bathwater. I wonder how difficult (read: secure) it would be to cache the data across calls. An md5sum could be used to determine whether the contents of a .gpg file have changed since the last lookup. Instead of decrypting each file for every call, hiera-gpg can do something like: - Calculate an md5sum of the .gpg files, and the data from these files stored in memory, redis, or wherever. - When asked for a variable, do an md5sum of the .gpg file and, if the values are the same, return the data from memory - If the hash values don't match, reload the data from the .gpg file. Seems like this would be slightly faster than having to fully decrypt the contents of each file for every parameter lookup. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Are multiple environments broken in puppet?
Hm, I started seeing this when I moved to a dynamic environment configuration and began incorporating the openstack modules. Are there workarounds or rules of thumb to avoid it while still being able to use environments? -james On Thursday, May 9, 2013 6:33:38 AM UTC-7, jcbollinger wrote: > > > > On Wednesday, May 8, 2013 8:06:27 PM UTC-5, James Kyle wrote: >> >> I started getting the following errors from my puppet master: >> >> > Error: Could not retrieve catalog from remote server: Error 400 on >> SERVER: Invalid parameter provider at /some/module/manifests/foo.pp >> >> The module would vary, but the error was always the same. I started >> googling, searching lists, etc. And turned up a whole bucket load of issues >> that all seem related and are all unresolved: >> >> #17814, #13858, #12173, #8750, etc. >> >> Some go back over 2 years and some are current from within the last >> month, but they're all linked. >> >> Am I mistaken/misinterpreting or do they all seem to boil down to >> "environments are broken". >> >> If I am mistaken, what's the workaround? I was really looking forward to >> mapping environments to git branches with git hooks. >> > > > I think it's fair to say that environments are a bit crippled. > Principally, trouble with environments revolves around modules that provide > native components (types, providers, or functions) that are not uniform > across all defined environments. Where your environment-specific modules > do not provide such things (and many don't), environments should work for > you. > > These problems are unlikely to be fixed soon, as they stem from a deep > architectural issue. Puppet really needs some kind of internal abstraction > with which to group and separate the components associated with each > environment, but it doesn't have one, and adding one would likely be a lot > of work. Even if PL is persuaded to prioritize the issue, I cannot imagine > a solution being released before Puppet 3.3 (and that may be overly > optimistic). > > > John > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: hiera not using non-root user custom fact
I was able to solve this. The facts were being communicated correctly,
however the custom facts had a additional newline at the end. So I just
needed to clean up the whitespace.
fact.last.strip
Once the fact was cleaned, hiera lookups started to work again.
On Monday, May 6, 2013 7:22:40 PM UTC-7, Corey Osman wrote:
>
> Hi,
>
> Before I begin, my environment consists of a standard master/client config
> with the exception that all my clients run under a non-root user. I have
> to use non-root so I can't simply restart under root to fix the problem.
>
> Master -> 3.1.1
> Client -> 2.7.17
>
> using mostly the hiera() function in my classes.
>
> problem:
>
> I have run into an issue today where my custom fact is not being passed to
> hiera in order to determine which hiera file to use (see hierarchy). The
> custom fact is definitely defined what it should be but its almost as if it
> has a differently scope then say a root level custom fact. Because of this
> hiera data is coming up undefined which causes my classes to fail.
>
> $myvar = hiera('var-name') --> should use custom_env and custom_release
> to help determine where the variable is defined in hiera.
>
> Are custom facts from non root users simply not relayed to hiera?
>
> :hierarchy:
> - nodes/%{::fqdn}
> - releases/%{custom_release}
> - env/%{custom_env}
> - common
>
>
>
> I have put a bandaid fix in for now which sets these variables via top
> scope assignment in one of my classes and allows me to control everything
> from hiera instead of using custom facts. However, I am not sure if this
> follows good puppet coding practices when using hiera, since I am using
> hiera to feed hiera. I don't want to have to define these variables for
> every node.
>
> bandaid fix:
> # this is a top scope variable that is currently a hack to fix an unknown
> bug with hiera and local puppet facts
> $custom_env = hiera('custom_env') --> defined under nodes/nodename
> $custom_release = hiera('custom_release') --> defined under
> nodes/nodename
> class roles::specialapp(
>
> )
>
> {
> include specialapp_profile
>
> }
>
>
> If this is a new bug, I'll be happen to file a ticket.
>
> Thanks,
>
> Corey Osman
> co...@logicminds.biz
>
>
>
>
>
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] hiera can't see a value on a puppet client, but the hiera app on the server can
I don't get how any of your points are relevant to my issue. I never said that I'm trying to run Hiera on my client. I have a puppet module with templates, and the variables in my template are looked up in Hiera on my Puppet Master server. My client is unable to apply the module because it isn't getting a valid answer back for those variables from the Puppet Master server, which I assume means that Hiera is not giving it a valid answer to pass to the client. I realize that Hiera and Facter are two separate entities, I am using Facter facts to organize my information in Hiera and I was illustrating that in my post. On Thursday, May 9, 2013 5:30:34 AM UTC-7, Ygor wrote: > > I believe you are missing a basic concept: Hiera is for the puppet > MASTER, not the agent/client. > > From http://docs.puppetlabs.com/hiera/1/installing.html#installing-hiera > > Installing Hiera > > If you are using Hiera with Puppet, you should install it on your puppet > master server(s); it is optional and unnecessary on agent nodes. (If you > are using a standalone puppet apply site, every node should have Hiera.) > > Also, hiera and facter are two distinctly different beasties. You can use > facter-facts in your heirarchy definitions to organize your data, but info > from hiera is different from info from facter. Facter operates at the > agent/client level while hiera is at the puppet-master level. > > HTH > > “Sometimes I think the surest sign that intelligent life exists elsewhere > in the universe is that none of it has tried to contact us.” > Bill Waterson (Calvin & Hobbes) > > - Original Message - > From: "Eric" > > To: puppet...@googlegroups.com > Sent: Wednesday, May 8, 2013 10:34:20 PM > Subject: [Puppet Users] hiera can't see a value on a puppet client, but > the hiera app on the server can > > > When I run puppet on a client it says it can't find a parameter in hiera, > but If I run the hiera application on my puppet master and give it the same > facts that my client has, it finds them just fine. Why is that? > > > Here's how my client sees itself: > > [root@tag5-4-qa-sjc ~]# facter --puppet | grep region > region => northamerica > [root@tag5-4-qa-sjc ~]# facter --puppet | grep datacenter > datacenter => sjc > [root@tag5-4-qa-sjc ~]# facter --puppet | grep environment > environment => qa > [root@tag5-4-qa-sjc ~]# facter --puppet | grep machinetype > machinetype => tag > [root@tag5-4-qa-sjc ~]# facter --puppet | grep hostname > hostname => tag5-4-qa-sjc > > I run puppet and get this error: > > err: Could not retrieve catalog from remote server: Error 400 on SERVER: > Could not find data item ak_auth_primary in any Hiera data file and no > default supplied at /etc/puppet/manifests/site.pp:11 on node > tag5-4-qa-sjc.domain.net > > on my puppet master server: > > $ hiera ak_auth_primary region=northamerica datacenter=sjc environment=qa > > Answer: ops1-1-qa-sjc > > $ hiera ak_auth_primary region=northamerica datacenter=sjc environment=qa > machinetype=tag hostname=tag5-4-qa-sjc > > Answer: ops1-1-qa-sjc > > Is it because I'm using an older version of Puppet with Hiera? I'm not > quite ready to upgrade to version 3 yet, but I plan to. > > [root@tag5-4-qa-sjc ~]# rpm -qa | grep puppet > puppet-2.7.14-1.el6.noarch > > user@puppet-server$ sudo rpm -qa | egrep '(puppet|hiera)' > puppet-2.7.12-1.el6.noarch > puppet-dashboard-1.2.6-1.el6.noarch > hiera-1.2.1-1.el5.noarch > puppet-server-2.7.12-1.el6.noarch > hiera-puppet-1.0.0-1.el5.noarch > > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users...@googlegroups.com . > To post to this group, send email to puppet...@googlegroups.com. > > Visit this group at http://groups.google.com/group/puppet-users?hl=en . > For more options, visit https://groups.google.com/groups/opt_out . > > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: hiera can't see a value on a puppet client, but the hiera app on the server can
Thanks for telling me about the debug option. ericc@ops1-2-qa-sjc:puppet$ hiera -c /etc/puppet/hiera.yaml ak_auth_primary region=northamerica datacenter=sjc environment=qa machinetype=qa hostname=tag5-4-qa-sjc --debug DEBUG: Thu May 09 11:04:27 -0700 2013: Hiera YAML backend starting DEBUG: Thu May 09 11:04:27 -0700 2013: Looking up ak_auth_primary in YAML backend DEBUG: Thu May 09 11:04:27 -0700 2013: Looking for data source regions/northamerica/datacenters/sjc/qa/qa/tag5-4-qa-sjc/tag5-4-qa-sjc DEBUG: Thu May 09 11:04:27 -0700 2013: Cannot find datafile /etc/puppet/hieradata/regions/northamerica/datacenters/sjc/qa/qa/tag5-4-qa-sjc/tag5-4-qa-sjc.yaml, skipping DEBUG: Thu May 09 11:04:27 -0700 2013: Looking for data source regions/northamerica/datacenters/sjc/qa/qa/qa DEBUG: Thu May 09 11:04:27 -0700 2013: Cannot find datafile /etc/puppet/hieradata/regions/northamerica/datacenters/sjc/qa/qa/qa.yaml, skipping DEBUG: Thu May 09 11:04:27 -0700 2013: Looking for data source regions/northamerica/datacenters/sjc/qa/qa DEBUG: Thu May 09 11:04:27 -0700 2013: Found ak_auth_primary in regions/northamerica/datacenters/sjc/qa/qa ops1-1-qa-sjc I ran Puppet again this morning on my client and now it works. I was thinking that this indicates that the client was caching the manifest, even though I was using the --test option when running Puppet manually on my client. It was my understanding that --test tells the Puppet client not to use a cached catalog. Any theories as to why it would work today even though I haven't changed a single thing? (honestly!) On Thursday, May 9, 2013 1:04:23 AM UTC-7, Luke Bigum wrote: > > Hi Campee, > > On Thursday, May 9, 2013 3:34:20 AM UTC+1, Campee wrote: > >> >> I run puppet and get this error: >> >> err: Could not retrieve catalog from remote server: Error 400 on SERVER: >> Could not find data item ak_auth_primary in any Hiera data file and no >> default supplied at /etc/puppet/manifests/site.pp:11 on node >> tag5-4-qa-sjc.domain.net >> >> on my puppet master server: >> >> $ hiera ak_auth_primary region=northamerica datacenter=sjc environment=qa >> >> Answer: ops1-1-qa-sjc >> >> $ hiera ak_auth_primary region=northamerica datacenter=sjc environment=qa >> machinetype=tag hostname=tag5-4-qa-sjc >> >> > Can you test Hiera like this (on your Puppet Master), it uses the Facts > cache of your node, rather than you filling in all the gaps by hand, and > thus is a more thorough test: > > hiera -c /etc/puppet/hiera.yaml -y /var/lib/puppet/yaml/facts/ > tag5-4-qa-sjc.domain.net.yaml ak_auth_primary --debug > > You should get some helpful debug trace through what Hiera is doing and > what data files it is trying to open, in order: > > DEBUG: Thu May 24 13:18:53 + 2012: Hiera JSON backend starting > DEBUG: Thu May 24 13:18:53 + 2012: Looking up key 'ak_auth_primary' in > JSON backend > DEBUG: Thu May 24 13:18:53 + 2012: Backend datadir for json is an > Array, multiple data dirs to search > DEBUG: Thu May 24 13:18:53 + 2012: Looking in data dir > /etc/puppet/private/ > DEBUG: Thu May 24 13:18:53 + 2012: Looking at hierarchy source > tag5-4-qa-sjc.domain.net > DEBUG: Thu May 24 13:18:53 + 2012: Cannot find datafile > /etc/puppet/private/tag5-4-qa-sjc.domain.net.json, skipping > DEBUG: Thu May 24 13:18:53 + 2012: Looking at hierarchy source common > DEBUG: Thu May 24 13:18:53 + 2012: Cannot find datafile > /etc/puppet/private/common.json, skipping > DEBUG: Thu May 24 13:18:53 + 2012: Looking at hierarchy source > tag5-4-qa-sjc.domain.net > > -Luke > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: High Availability of Puppet server for separate geographical location
On 5/9/2013 7:42 AM, Martin Langhoff wrote: On Thu, May 9, 2013 at 12:06 AM, John Warburton wrote: I suppose all HA solutions are difficult Nah. A service correctly designed to be resilient can be HA with trivial investment. DNS is a good example. It may have blemishes but nobody stresses about its availability. Setup as many tiers of redundancy as you want, easily. Puppet has no need to be centralized -- a git-based puppet setup can handle it just fine. I am writing some tooling for git+puppet (search for ppg in recent posts to this list), and it's trivial to add N-tiers of redundant servers... Hubris, today thy name is Martin. :-) I'd argue that people have stressed about DNS availability for just under three decades and that we are currently enjoying the fruits of that labor. Personally, I have yet to work at a company where DNS has not caused a significant outage. I do agree that the tools are there to build resilience, but implementation matters and it is a hard problem to solve in a non trivial environment. Your ppg tooling does look interesting, but there is a large trade off in functionality. You could use some other systems to collect data and push it into a repo which is then queried in order to generate data for clients... starting to sound an awful lot like centralized Puppet to me and all the problems therein regardless of transport. Ramin -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: hiera can't see a value on a puppet client, but the hiera app on the server can
Did you restart your puppetmaster process ? If you made any change to your config file (/etc/puppet/hiera.yaml) you need to restart the puppetmaster process for the updates to be in effect. I spun my wheels a bit before that sunk in for me :) “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin & Hobbes) - Original Message - From: "Campee" To: puppet-users@googlegroups.com Sent: Thursday, May 9, 2013 2:19:01 PM Subject: [Puppet Users] Re: hiera can't see a value on a puppet client, but the hiera app on the server can Thanks for telling me about the debug option. ericc@ops1-2-qa-sjc:puppet$ hiera -c /etc/puppet/hiera.yaml ak_auth_primary region=northamerica datacenter=sjc environment=qa machinetype=qa hostname=tag5-4-qa-sjc --debug DEBUG: Thu May 09 11:04:27 -0700 2013: Hiera YAML backend starting DEBUG: Thu May 09 11:04:27 -0700 2013: Looking up ak_auth_primary in YAML backend DEBUG: Thu May 09 11:04:27 -0700 2013: Looking for data source regions/northamerica/datacenters/sjc/qa/qa/tag5-4-qa-sjc/tag5-4-qa-sjc DEBUG: Thu May 09 11:04:27 -0700 2013: Cannot find datafile /etc/puppet/hieradata/regions/northamerica/datacenters/sjc/qa/qa/tag5-4-qa-sjc/tag5-4-qa-sjc.yaml, skipping DEBUG: Thu May 09 11:04:27 -0700 2013: Looking for data source regions/northamerica/datacenters/sjc/qa/qa/qa DEBUG: Thu May 09 11:04:27 -0700 2013: Cannot find datafile /etc/puppet/hieradata/regions/northamerica/datacenters/sjc/qa/qa/qa.yaml, skipping DEBUG: Thu May 09 11:04:27 -0700 2013: Looking for data source regions/northamerica/datacenters/sjc/qa/qa DEBUG: Thu May 09 11:04:27 -0700 2013: Found ak_auth_primary in regions/northamerica/datacenters/sjc/qa/qa ops1-1-qa-sjc I ran Puppet again this morning on my client and now it works. I was thinking that this indicates that the client was caching the manifest, even though I was using the --test option when running Puppet manually on my client. It was my understanding that --test tells the Puppet client not to use a cached catalog. Any theories as to why it would work today even though I haven't changed a single thing? (honestly!) On Thursday, May 9, 2013 1:04:23 AM UTC-7, Luke Bigum wrote: Hi Campee, On Thursday, May 9, 2013 3:34:20 AM UTC+1, Campee wrote: I run puppet and get this error: err: Could not retrieve catalog from remote server: Error 400 on SERVER: Could not find data item ak_auth_primary in any Hiera data file and no default supplied at /etc/puppet/manifests/site.pp:11 on node tag5-4-qa-sjc.domain.net on my puppet master server: $ hiera ak_auth_primary region=northamerica datacenter=sjc environment=qa Answer: ops1-1-qa-sjc $ hiera ak_auth_primary region=northamerica datacenter=sjc environment=qa machinetype=tag hostname=tag5-4-qa-sjc Can you test Hiera like this (on your Puppet Master), it uses the Facts cache of your node, rather than you filling in all the gaps by hand, and thus is a more thorough test: hiera -c /etc/puppet/hiera.yaml -y /var/lib/puppet/yaml/facts/ tag5-4-qa-sjc.domain.net .yaml ak_auth_primary --debug You should get some helpful debug trace through what Hiera is doing and what data files it is trying to open, in order: DEBUG: Thu May 24 13:18:53 + 2012: Hiera JSON backend starting DEBUG: Thu May 24 13:18:53 + 2012: Looking up key 'ak_auth_primary' in JSON backend DEBUG: Thu May 24 13:18:53 + 2012: Backend datadir for json is an Array, multiple data dirs to search DEBUG: Thu May 24 13:18:53 + 2012: Looking in data dir /etc/puppet/private/ DEBUG: Thu May 24 13:18:53 + 2012: Looking at hierarchy source tag5-4-qa-sjc.domain.net DEBUG: Thu May 24 13:18:53 + 2012: Cannot find datafile /etc/puppet/private/tag5-4-qa-sjc.domain.net.json, skipping DEBUG: Thu May 24 13:18:53 + 2012: Looking at hierarchy source common DEBUG: Thu May 24 13:18:53 + 2012: Cannot find datafile /etc/puppet/private/common.json, skipping DEBUG: Thu May 24 13:18:53 + 2012: Looking at hierarchy source tag5-4-qa-sjc.domain.net -Luke -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en . For more options, visit https://groups.google.com/groups/opt_out . -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more
Re: [Puppet Users] Re: hiera can't see a value on a puppet client, but the hiera app on the server can
I am running httpd + passenger. The puppetmaster service is turned off and not running. Do I need to restart httpd instead or does this not apply if you're running httpd? On Thursday, May 9, 2013 11:36:34 AM UTC-7, Ygor wrote: > > Did you restart your puppetmaster process ? > > If you made any change to your config file (/etc/puppet/hiera.yaml) you > need to restart the puppetmaster process for the updates to be in effect. > > I spun my wheels a bit before that sunk in for me :) > > > “Sometimes I think the surest sign that intelligent life exists elsewhere > in the universe is that none of it has tried to contact us.” > Bill Waterson (Calvin & Hobbes) > > - Original Message - > From: "Campee" > > To: puppet...@googlegroups.com > Sent: Thursday, May 9, 2013 2:19:01 PM > Subject: [Puppet Users] Re: hiera can't see a value on a puppet client, > but the hiera app on the server can > > Thanks for telling me about the debug option. > > ericc@ops1-2-qa-sjc:puppet$ hiera -c /etc/puppet/hiera.yaml > ak_auth_primary region=northamerica datacenter=sjc environment=qa > machinetype=qa hostname=tag5-4-qa-sjc --debug > DEBUG: Thu May 09 11:04:27 -0700 2013: Hiera YAML backend starting > DEBUG: Thu May 09 11:04:27 -0700 2013: Looking up ak_auth_primary in YAML > backend > DEBUG: Thu May 09 11:04:27 -0700 2013: Looking for data source > regions/northamerica/datacenters/sjc/qa/qa/tag5-4-qa-sjc/tag5-4-qa-sjc > DEBUG: Thu May 09 11:04:27 -0700 2013: Cannot find datafile > /etc/puppet/hieradata/regions/northamerica/datacenters/sjc/qa/qa/tag5-4-qa-sjc/tag5-4-qa-sjc.yaml, > > skipping > DEBUG: Thu May 09 11:04:27 -0700 2013: Looking for data source > regions/northamerica/datacenters/sjc/qa/qa/qa > DEBUG: Thu May 09 11:04:27 -0700 2013: Cannot find datafile > /etc/puppet/hieradata/regions/northamerica/datacenters/sjc/qa/qa/qa.yaml, > skipping > DEBUG: Thu May 09 11:04:27 -0700 2013: Looking for data source > regions/northamerica/datacenters/sjc/qa/qa > DEBUG: Thu May 09 11:04:27 -0700 2013: Found ak_auth_primary in > regions/northamerica/datacenters/sjc/qa/qa > ops1-1-qa-sjc > > I ran Puppet again this morning on my client and now it works. I was > thinking that this indicates that the client was caching the manifest, even > though I was using the --test option when running Puppet manually on my > client. It was my understanding that --test tells the Puppet client not to > use a cached catalog. > > Any theories as to why it would work today even though I haven't changed a > single thing? (honestly!) > > > On Thursday, May 9, 2013 1:04:23 AM UTC-7, Luke Bigum wrote: > > > Hi Campee, > > On Thursday, May 9, 2013 3:34:20 AM UTC+1, Campee wrote: > > > > > > I run puppet and get this error: > > err: Could not retrieve catalog from remote server: Error 400 on SERVER: > Could not find data item ak_auth_primary in any Hiera data file and no > default supplied at /etc/puppet/manifests/site.pp:11 on node > tag5-4-qa-sjc.domain.net > > on my puppet master server: > > $ hiera ak_auth_primary region=northamerica datacenter=sjc environment=qa > > Answer: ops1-1-qa-sjc > > $ hiera ak_auth_primary region=northamerica datacenter=sjc environment=qa > machinetype=tag hostname=tag5-4-qa-sjc > > > > > Can you test Hiera like this (on your Puppet Master), it uses the Facts > cache of your node, rather than you filling in all the gaps by hand, and > thus is a more thorough test: > > > hiera -c /etc/puppet/hiera.yaml -y /var/lib/puppet/yaml/facts/ > tag5-4-qa-sjc.domain.net .yaml ak_auth_primary --debug > > > You should get some helpful debug trace through what Hiera is doing and > what data files it is trying to open, in order: > > > > DEBUG: Thu May 24 13:18:53 + 2012: Hiera JSON backend starting > DEBUG: Thu May 24 13:18:53 + 2012: Looking up key 'ak_auth_primary' in > JSON backend > DEBUG: Thu May 24 13:18:53 + 2012: Backend datadir for json is an > Array, multiple data dirs to search > DEBUG: Thu May 24 13:18:53 + 2012: Looking in data dir > /etc/puppet/private/ > DEBUG: Thu May 24 13:18:53 + 2012: Looking at hierarchy source > tag5-4-qa-sjc.domain.net > DEBUG: Thu May 24 13:18:53 + 2012: Cannot find datafile > /etc/puppet/private/tag5-4-qa-sjc.domain.net.json, skipping > DEBUG: Thu May 24 13:18:53 + 2012: Looking at hierarchy source common > DEBUG: Thu May 24 13:18:53 + 2012: Cannot find datafile > /etc/puppet/private/common.json, skipping > DEBUG: Thu May 24 13:18:53 + 2012: Looking at hierarchy source > tag5-4-qa-sjc.domain.net > > > -Luke > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users...@googlegroups.com . > To post to this group, send email to puppet...@googlegroups.com. > > Visit this group at http://groups.google.com/group/puppet-users?hl=en . > For m
Re: [Puppet Users] Re: hiera can't see a value on a puppet client, but the hiera app on the server can
I use Passenger also. You need to restart the httpd for the change to kick in. Is that what happened ? “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin & Hobbes) - Original Message - From: "Campee" To: puppet-users@googlegroups.com Sent: Thursday, May 9, 2013 2:46:19 PM Subject: Re: [Puppet Users] Re: hiera can't see a value on a puppet client, but the hiera app on the server can I am running httpd + passenger. The puppetmaster service is turned off and not running. Do I need to restart httpd instead or does this not apply if you're running httpd? On Thursday, May 9, 2013 11:36:34 AM UTC-7, Ygor wrote: Did you restart your puppetmaster process ? If you made any change to your config file (/etc/puppet/hiera.yaml) you need to restart the puppetmaster process for the updates to be in effect. I spun my wheels a bit before that sunk in for me :) “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin & Hobbes) - Original Message - From: "Campee" < cam...@gmail.com > To: puppet...@googlegroups.com Sent: Thursday, May 9, 2013 2:19:01 PM Subject: [Puppet Users] Re: hiera can't see a value on a puppet client, but the hiera app on the server can Thanks for telling me about the debug option. ericc@ops1-2-qa-sjc:puppet$ hiera -c /etc/puppet/hiera.yaml ak_auth_primary region=northamerica datacenter=sjc environment=qa machinetype=qa hostname=tag5-4-qa-sjc --debug DEBUG: Thu May 09 11:04:27 -0700 2013: Hiera YAML backend starting DEBUG: Thu May 09 11:04:27 -0700 2013: Looking up ak_auth_primary in YAML backend DEBUG: Thu May 09 11:04:27 -0700 2013: Looking for data source regions/northamerica/datacenters/sjc/qa/qa/tag5-4-qa-sjc/tag5-4-qa-sjc DEBUG: Thu May 09 11:04:27 -0700 2013: Cannot find datafile /etc/puppet/hieradata/regions/northamerica/datacenters/sjc/qa/qa/tag5-4-qa-sjc/tag5-4-qa-sjc.yaml, skipping DEBUG: Thu May 09 11:04:27 -0700 2013: Looking for data source regions/northamerica/datacenters/sjc/qa/qa/qa DEBUG: Thu May 09 11:04:27 -0700 2013: Cannot find datafile /etc/puppet/hieradata/regions/northamerica/datacenters/sjc/qa/qa/qa.yaml, skipping DEBUG: Thu May 09 11:04:27 -0700 2013: Looking for data source regions/northamerica/datacenters/sjc/qa/qa DEBUG: Thu May 09 11:04:27 -0700 2013: Found ak_auth_primary in regions/northamerica/datacenters/sjc/qa/qa ops1-1-qa-sjc I ran Puppet again this morning on my client and now it works. I was thinking that this indicates that the client was caching the manifest, even though I was using the --test option when running Puppet manually on my client. It was my understanding that --test tells the Puppet client not to use a cached catalog. Any theories as to why it would work today even though I haven't changed a single thing? (honestly!) On Thursday, May 9, 2013 1:04:23 AM UTC-7, Luke Bigum wrote: Hi Campee, On Thursday, May 9, 2013 3:34:20 AM UTC+1, Campee wrote: I run puppet and get this error: err: Could not retrieve catalog from remote server: Error 400 on SERVER: Could not find data item ak_auth_primary in any Hiera data file and no default supplied at /etc/puppet/manifests/site.pp:11 on node tag5-4-qa-sjc.domain.net on my puppet master server: $ hiera ak_auth_primary region=northamerica datacenter=sjc environment=qa Answer: ops1-1-qa-sjc $ hiera ak_auth_primary region=northamerica datacenter=sjc environment=qa machinetype=tag hostname=tag5-4-qa-sjc Can you test Hiera like this (on your Puppet Master), it uses the Facts cache of your node, rather than you filling in all the gaps by hand, and thus is a more thorough test: hiera -c /etc/puppet/hiera.yaml -y /var/lib/puppet/yaml/facts/ tag5-4-qa-sjc.domain.net .yaml ak_auth_primary --debug You should get some helpful debug trace through what Hiera is doing and what data files it is trying to open, in order: DEBUG: Thu May 24 13:18:53 + 2012: Hiera JSON backend starting DEBUG: Thu May 24 13:18:53 + 2012: Looking up key 'ak_auth_primary' in JSON backend DEBUG: Thu May 24 13:18:53 + 2012: Backend datadir for json is an Array, multiple data dirs to search DEBUG: Thu May 24 13:18:53 + 2012: Looking in data dir /etc/puppet/private/ DEBUG: Thu May 24 13:18:53 + 2012: Looking at hierarchy source tag5-4-qa-sjc.domain.net DEBUG: Thu May 24 13:18:53 + 2012: Cannot find datafile /etc/puppet/private/tag5-4-qa-sjc.domain.net.json, skipping DEBUG: Thu May 24 13:18:53 + 2012: Looking at hierarchy source common DEBUG: Thu May 24 13:18:53 + 2012: Cannot find datafile /etc/puppet/private/common.json, skipping DEBUG: Thu May 24 13:18:53 + 2012: Looking at hierarchy source tag5-4-qa-sjc.domain.net -Luke -- You received this message because you are subscribed to t
Re: [Puppet Users] Re: hiera can't see a value on a puppet client, but the hiera app on the server can
I definitely did not restart httpd, but I can try that the next time I encounter this issue. On Thursday, May 9, 2013 11:48:40 AM UTC-7, Ygor wrote: > > I use Passenger also. > You need to restart the httpd for the change to kick in. > > Is that what happened ? > > “Sometimes I think the surest sign that intelligent life exists elsewhere > in the universe is that none of it has tried to contact us.” > Bill Waterson (Calvin & Hobbes) > > - Original Message - > From: "Campee" > > To: puppet...@googlegroups.com > Sent: Thursday, May 9, 2013 2:46:19 PM > Subject: Re: [Puppet Users] Re: hiera can't see a value on a puppet > client, but the hiera app on the server can > > I am running httpd + passenger. The puppetmaster service is turned off and > not running. Do I need to restart httpd instead or does this not apply if > you're running httpd? > > On Thursday, May 9, 2013 11:36:34 AM UTC-7, Ygor wrote: > > Did you restart your puppetmaster process ? > > If you made any change to your config file (/etc/puppet/hiera.yaml) you > need to restart the puppetmaster process for the updates to be in effect. > > I spun my wheels a bit before that sunk in for me :) > > > “Sometimes I think the surest sign that intelligent life exists elsewhere > in the universe is that none of it has tried to contact us.” > Bill Waterson (Calvin & Hobbes) > > - Original Message - > From: "Campee" < cam...@gmail.com > > To: puppet...@googlegroups.com > Sent: Thursday, May 9, 2013 2:19:01 PM > Subject: [Puppet Users] Re: hiera can't see a value on a puppet client, > but the hiera app on the server can > > Thanks for telling me about the debug option. > > ericc@ops1-2-qa-sjc:puppet$ hiera -c /etc/puppet/hiera.yaml > ak_auth_primary region=northamerica datacenter=sjc environment=qa > machinetype=qa hostname=tag5-4-qa-sjc --debug > DEBUG: Thu May 09 11:04:27 -0700 2013: Hiera YAML backend starting > DEBUG: Thu May 09 11:04:27 -0700 2013: Looking up ak_auth_primary in YAML > backend > DEBUG: Thu May 09 11:04:27 -0700 2013: Looking for data source > regions/northamerica/datacenters/sjc/qa/qa/tag5-4-qa-sjc/tag5-4-qa-sjc > DEBUG: Thu May 09 11:04:27 -0700 2013: Cannot find datafile > /etc/puppet/hieradata/regions/northamerica/datacenters/sjc/qa/qa/tag5-4-qa-sjc/tag5-4-qa-sjc.yaml, > > skipping > DEBUG: Thu May 09 11:04:27 -0700 2013: Looking for data source > regions/northamerica/datacenters/sjc/qa/qa/qa > DEBUG: Thu May 09 11:04:27 -0700 2013: Cannot find datafile > /etc/puppet/hieradata/regions/northamerica/datacenters/sjc/qa/qa/qa.yaml, > skipping > DEBUG: Thu May 09 11:04:27 -0700 2013: Looking for data source > regions/northamerica/datacenters/sjc/qa/qa > DEBUG: Thu May 09 11:04:27 -0700 2013: Found ak_auth_primary in > regions/northamerica/datacenters/sjc/qa/qa > ops1-1-qa-sjc > > I ran Puppet again this morning on my client and now it works. I was > thinking that this indicates that the client was caching the manifest, even > though I was using the --test option when running Puppet manually on my > client. It was my understanding that --test tells the Puppet client not to > use a cached catalog. > > Any theories as to why it would work today even though I haven't changed a > single thing? (honestly!) > > > On Thursday, May 9, 2013 1:04:23 AM UTC-7, Luke Bigum wrote: > > > Hi Campee, > > On Thursday, May 9, 2013 3:34:20 AM UTC+1, Campee wrote: > > > > > > I run puppet and get this error: > > err: Could not retrieve catalog from remote server: Error 400 on SERVER: > Could not find data item ak_auth_primary in any Hiera data file and no > default supplied at /etc/puppet/manifests/site.pp:11 on node > tag5-4-qa-sjc.domain.net > > on my puppet master server: > > $ hiera ak_auth_primary region=northamerica datacenter=sjc environment=qa > > Answer: ops1-1-qa-sjc > > $ hiera ak_auth_primary region=northamerica datacenter=sjc environment=qa > machinetype=tag hostname=tag5-4-qa-sjc > > > > > Can you test Hiera like this (on your Puppet Master), it uses the Facts > cache of your node, rather than you filling in all the gaps by hand, and > thus is a more thorough test: > > > hiera -c /etc/puppet/hiera.yaml -y /var/lib/puppet/yaml/facts/ > tag5-4-qa-sjc.domain.net .yaml ak_auth_primary --debug > > > You should get some helpful debug trace through what Hiera is doing and > what data files it is trying to open, in order: > > > > DEBUG: Thu May 24 13:18:53 + 2012: Hiera JSON backend starting > DEBUG: Thu May 24 13:18:53 + 2012: Looking up key 'ak_auth_primary' in > JSON backend > DEBUG: Thu May 24 13:18:53 + 2012: Backend datadir for json is an > Array, multiple data dirs to search > DEBUG: Thu May 24 13:18:53 + 2012: Looking in data dir > /etc/puppet/private/ > DEBUG: Thu May 24 13:18:53 + 2012: Looking at hierarchy source > tag5-4-qa-sjc.domain.net > DEBUG: Thu May 24 13:18:53 + 2012: Cannot find datafile > /etc/puppet/privat
Re: [Puppet Users] Re: hiera can't see a value on a puppet client, but the hiera app on the server can
Good luck to you. My apologies at misunderstanding you earlier. Just trying to help “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin & Hobbes) - Original Message - From: "Campee" To: puppet-users@googlegroups.com Sent: Thursday, May 9, 2013 3:02:48 PM Subject: Re: [Puppet Users] Re: hiera can't see a value on a puppet client, but the hiera app on the server can I definitely did not restart httpd, but I can try that the next time I encounter this issue. On Thursday, May 9, 2013 11:48:40 AM UTC-7, Ygor wrote: I use Passenger also. You need to restart the httpd for the change to kick in. Is that what happened ? “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin & Hobbes) - Original Message - From: "Campee" < cam...@gmail.com > To: puppet...@googlegroups.com Sent: Thursday, May 9, 2013 2:46:19 PM Subject: Re: [Puppet Users] Re: hiera can't see a value on a puppet client, but the hiera app on the server can I am running httpd + passenger. The puppetmaster service is turned off and not running. Do I need to restart httpd instead or does this not apply if you're running httpd? On Thursday, May 9, 2013 11:36:34 AM UTC-7, Ygor wrote: Did you restart your puppetmaster process ? If you made any change to your config file (/etc/puppet/hiera.yaml) you need to restart the puppetmaster process for the updates to be in effect. I spun my wheels a bit before that sunk in for me :) “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin & Hobbes) - Original Message - From: "Campee" < cam...@gmail.com > To: puppet...@googlegroups.com Sent: Thursday, May 9, 2013 2:19:01 PM Subject: [Puppet Users] Re: hiera can't see a value on a puppet client, but the hiera app on the server can Thanks for telling me about the debug option. ericc@ops1-2-qa-sjc:puppet$ hiera -c /etc/puppet/hiera.yaml ak_auth_primary region=northamerica datacenter=sjc environment=qa machinetype=qa hostname=tag5-4-qa-sjc --debug DEBUG: Thu May 09 11:04:27 -0700 2013: Hiera YAML backend starting DEBUG: Thu May 09 11:04:27 -0700 2013: Looking up ak_auth_primary in YAML backend DEBUG: Thu May 09 11:04:27 -0700 2013: Looking for data source regions/northamerica/datacenters/sjc/qa/qa/tag5-4-qa-sjc/tag5-4-qa-sjc DEBUG: Thu May 09 11:04:27 -0700 2013: Cannot find datafile /etc/puppet/hieradata/regions/northamerica/datacenters/sjc/qa/qa/tag5-4-qa-sjc/tag5-4-qa-sjc.yaml, skipping DEBUG: Thu May 09 11:04:27 -0700 2013: Looking for data source regions/northamerica/datacenters/sjc/qa/qa/qa DEBUG: Thu May 09 11:04:27 -0700 2013: Cannot find datafile /etc/puppet/hieradata/regions/northamerica/datacenters/sjc/qa/qa/qa.yaml, skipping DEBUG: Thu May 09 11:04:27 -0700 2013: Looking for data source regions/northamerica/datacenters/sjc/qa/qa DEBUG: Thu May 09 11:04:27 -0700 2013: Found ak_auth_primary in regions/northamerica/datacenters/sjc/qa/qa ops1-1-qa-sjc I ran Puppet again this morning on my client and now it works. I was thinking that this indicates that the client was caching the manifest, even though I was using the --test option when running Puppet manually on my client. It was my understanding that --test tells the Puppet client not to use a cached catalog. Any theories as to why it would work today even though I haven't changed a single thing? (honestly!) On Thursday, May 9, 2013 1:04:23 AM UTC-7, Luke Bigum wrote: Hi Campee, On Thursday, May 9, 2013 3:34:20 AM UTC+1, Campee wrote: I run puppet and get this error: err: Could not retrieve catalog from remote server: Error 400 on SERVER: Could not find data item ak_auth_primary in any Hiera data file and no default supplied at /etc/puppet/manifests/site.pp:11 on node tag5-4-qa-sjc.domain.net on my puppet master server: $ hiera ak_auth_primary region=northamerica datacenter=sjc environment=qa Answer: ops1-1-qa-sjc $ hiera ak_auth_primary region=northamerica datacenter=sjc environment=qa machinetype=tag hostname=tag5-4-qa-sjc Can you test Hiera like this (on your Puppet Master), it uses the Facts cache of your node, rather than you filling in all the gaps by hand, and thus is a more thorough test: hiera -c /etc/puppet/hiera.yaml -y /var/lib/puppet/yaml/facts/ tag5-4-qa-sjc.domain.net .yaml ak_auth_primary --debug You should get some helpful debug trace through what Hiera is doing and what data files it is trying to open, in order: DEBUG: Thu May 24 13:18:53 + 2012: Hiera JSON backend starting DEBUG: Thu May 24 13:18:53 + 2012: Looking up key 'ak_auth_primary' in JSON backend DEBUG: Thu May 24 13:18:53 + 2012: Backend datadir for json is an Array, mul
[Puppet Users] loading custom type
rhel 6.4
puppet 3.1.1
I've written a puppet module for configuring qpidd brokers. I have
installed the module in /usr/share/puppet/modules.
I can successfully configure broker artifacts (exchanges, queues, bindings,
etc), using manifests and puppet apply from the commandline.
Now I'm trying to understand how I can do the same thing from inside a ruby
script, instead of using 'puppet apply'.
I found that I can do this:
service = Puppet::Type.type(:service).new(:name=>'qpidd')
service.provider.start
I would like to be able to do the same thing with my custom types, e.g.
broker = Puppet::Type.type(:broker).new(:service_name=>"qpidd_#{area_id}",
:url=>@broker_url)
or
exch = Puppet::Type.type(:exchange).new(:name=>'test')
but in both cases, I get:
undefined method `new' for nil:NilClass (NoMethodError)
so I checked the Puppet::MetaType::Manager @types, and my custom type
doesn't show up in the list of known types.
How do I tell the manager about my custom type so it can look it up when I
use .type(:symbol) ?
thanks,
Hunter
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Running all apt source and update operations first, best practice.
I've run into several incidences where a module attempts to install a
package before the apt::source is added or an update is run. Result is a
bunch apt errors and explosions.
Basically what should be done is all the apt::sources are added and and an
update run _before_ any packages are installed to ensure you're pulling
from the repos you want.
I've gone through several iterations in my attempt to achieve that
behavior. The one that works best so far is stages and wrapper classes.
Here's a terse example of what it looks like:
class myorg::common {
include stdlib
Apt::Source {stage => "setup"}
apt::source { 'puppetlabs':
location => 'http://apt.puppetlabs.com',
repos => 'main',
key=> '4BD6EC30',
key_server => 'pgp.mit.edu',
}
Exec['apt_update'] -> Package<| title != 'ubuntu-cloud-keyring' |>
}
node 'foo.bar.com' {
include stdlib
class {'myorg::common': stage => "setup"}
}
One thing that bothers me is you have to declare the stage for
myorg::common in every node that uses it. And as the name implies, that's
every node.
Is there a way to get rid of that duplication? I've thought of node
inheritance, but the docs seem to strongly steer you away from that pattern.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Having trouble with facter - "invalid argument"
On Wed, 8 May 2013 06:49:32 -0700 (PDT)
jcbollinger wrote:
> Examining the code doesn't reveal any obvious error. Facter uses
> this:
>
> def
> self.read_sysfs_dmi_entries(path="/sys/firmware/dmi/entries/1-0/raw")
> if File.exists?(path) File.read(path)
> end
> end
>
> That /sys/firmware/... path does not appear anywhere else in Facter
> that I (and Google) can find. That suggest that either the exists?
> test or the read must be causing the error to be emitted in your
> environment, but it's not clear which, or why.
So I guess the best would be to collect the following output
% ruby --version
% ls -l /sys/firmware/dmi/entries/1-0/raw
% stat /sys/firmware/dmi/entries/1-0/raw
% ruby -e 'puts :ok if File.exists?("/sys/firmware/dmi/entries/1-0/raw")'
% ruby -e 'puts :ok if File.read("/sys/firmware/dmi/entries/1-0/raw")'
-Stefan
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: High Availability of Puppet server for separate geographical location
On Thu, May 9, 2013 at 2:31 PM, Ramin K wrote: > Hubris, today thy name is Martin. :-) Fair enough. I am happy about the tool I am writing (almost finished!) but, as the followup post makes clear, it isn't about the designe of ppg. It is about the design of git. > I'd argue that people have stressed about DNS availability for just > under three decades and that we are currently enjoying the fruits of that > labor. Personally, I have yet to work at a company where DNS has not caused > a significant outage. I am really surprised at your statement. Of course mishaps can happen, or someone can mess up configuration DNS royally. But setting up a primary and secondary setup is trivial. SMTP and LDAP are also examples where resilience was baked into the design. With those two, the quality of implementation, and complications in setup make for a lot more breakage. Compare to HTTP, databases etc where there's a whole industry of tools to make things somewhat reliable. Maybe we are talking about different things. > Your ppg tooling does look interesting, but there is a large trade > off in functionality What is the loss of functionality you see? Anything that you use in practice? (Reading here https://groups.google.com/forum/?fromgroups=#!topic/puppet-users/7ZpAMrMb2NQ I can't spot anything major, but I may be missing something...) cheers, m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: Puppermaster certificate expired
On Thu, 9 May 2013 17:10:51 +0200
Lorenzo Salvadorini wrote:
> 2013/5/9 Nicolai Mollerup
>
> > Anyway I think the easy way is to setup some autosigning of clients
> > after creating a new CA.
> > Think you will have to clean the ssl-dir on clients for this to
> > work, though.
> >
> > Since we are going to make a brand new puppetmaster here sometime
> > before our CA expires that will be my approach to make the
> > transition smoother.
> >
>
> we are exactly at the same point: currently moving our puppetmaster on
> another host, struggling against CA hostname in SSL Certificates and
> thinking how to approach the refresh of all certificates on agents.
>
> Autosigning for some day could be a good approach for us too, since
> we have our racks with predefined networks IPs and master on amazon,
> so amazon agents can contact master via internal network.
>
> We already manage agents configuration with a puppet module, do you
> think we can do the SSL substitution with a recipe in puppet itself?
>
I'd not try to remove ssl certificates during a puppetrun because I
expect that every file resource with a `source` parameter will fail
after that point and the agent would not be able to send the last report
to the old master.
We had a slightly different approach when migrating our agents to a new
master. We run puppet out of cron and the cronentry is also managed by
puppet. Now we have the following simplified puppet::agent class:
# need_migration is mostly calculated by checking the agent's
# version and the current puppetmaster
if $need_migration {
$cron_command = '/var/lib/puppet/migrate.sh'
}
else {
$cron_command = '/usr/bin/puppet agent'
}
cron { 'puppet_clientrun':
command => $cron_command
}
If an agent contacts the old puppetmaster and need_migration evaluates
to false, the agent will replace its cronjob with the migration script,
so in the next interval we run the migration script instead of the
puppet agent.
The migration script updates the puppet software, updates the server
setting in puppet.conf and erases the ssl directory (this is only done
once in case the migrate.sh is executed more than once). The migrate.sh
script will also trigger a normal puppetrun as the last step, so
the puppet agent will create new certificates. The `migrate.sh` keeps
running every hour until someones signes the new certificate request
on the new master. Once the request is signed and the agent is able to
contact the new mater, the $need_migration will evaluate to false and
the migrate.sh in cron is replaced with the normal puppet agent
invocation.
This way we keet the removal of the ssl directory completly outside of
puppet. We can also be sure that hosts that had puppet temporarily
disabled will be instructed to migrate after they contact the (old)
master again.
-Stefan
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Having trouble with facter - "invalid argument"
Here's the output for the commands you requested. Thanks again for looking
into it.
+* ruby --version*
> ruby 1.9.3p392 (2013-02-22 revision 39386) [x86_64-linux]
> +* ls -l /sys/firmware/dmi/entries/1-0/raw*
> -r 1 root root 0 May 6 10:39 /sys/firmware/dmi/entries/1-0/raw
> +* stat /sys/firmware/dmi/entries/1-0/raw*
> File: `/sys/firmware/dmi/entries/1-0/raw'
> Size: 0 Blocks: 0 IO Block: 4096 regular empty
> file
> Device: eh/14dInode: 10901 Links: 1
> Access: (0400/-r) Uid: (0/root) Gid: (0/root)
> Access: 2013-05-06 10:39:29.650499164 -0500
> Modify: 2013-05-06 10:39:29.650499164 -0500
> Change: 2013-05-06 10:39:29.650499164 -0500
> Birth: -
> + *ruby -e 'puts :ok if File.exists?("/sys/firmware/dmi/entries/1-0/raw")'
> *
> ok
> +* ruby -e 'puts :ok if File.read("/sys/firmware/dmi/entries/1-0/raw")'*
> -e:1:in `read': Invalid argument - /sys/firmware/dmi/entries/1-0/raw
> (Errno::EINVAL)
> from -e:1:in `'
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] ignoring a service that doesn't exist
I've done the following, it ended up being a bit simpler for me when I'm
not sure what random services a new CentOS install has installed and/or
enabled...
define no_service ( ) {
service { "${name}" :
ensure => stopped ,
enable => false ,
status => "stat -t /etc/rc?.d/S??${name} > /dev/null 2>&1" ,
}
}
You can then declare individual service names, or lists of service names,
each of which will be disabled and shut down if the service is enabled. If
a particular service doesn't exist, the puppet agent does nothing.
no_service { 'ip6tables' : }
no_service { [ 'nfslock' , 'portmap' , 'xyzzy' ] : }
The only caveat is, if a service is disabled (i.e. "chkconfig service off")
but the service is still running, the puppet agent won't stop it. Of
course, if you have a service which is normally off and you've only enabled
it to test something, this could be a good thing...
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] ignoring a service that doesn't exist
On Thu, 9 May 2013 13:58:45 -0700 (PDT)
John Simpson wrote:
> I've done the following, it ended up being a bit simpler for me when
> I'm not sure what random services a new CentOS install has installed
> and/or enabled...
>
> define no_service ( ) {
> service { "${name}" :
> ensure => stopped ,
> enable => false ,
> status => "stat -t /etc/rc?.d/S??${name} > /dev/null 2>&1" ,
> }
> }
>
> You can then declare individual service names, or lists of service
> names, each of which will be disabled and shut down if the service is
> enabled. If a particular service doesn't exist, the puppet agent does
> nothing.
>
> no_service { 'ip6tables' : }
> no_service { [ 'nfslock' , 'portmap' , 'xyzzy' ] : }
>
> The only caveat is, if a service is disabled (i.e. "chkconfig service
> off") but the service is still running, the puppet agent won't stop
> it. Of course, if you have a service which is normally off and you've
> only enabled it to test something, this could be a good thing...
>
you should be able to just specify `hasstatus => false`. This way
puppet will check the process list in order to get the current status
and will not run the (absent) initscript to get the status.
-Stefan
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: Puppet Dashboard 1.2.23 issue deleting node
Please apply the diff from https://github.com/puppetlabs/puppet-dashboard/pull/226 to resolve the issue. On Tue, May 7, 2013 at 6:12 AM, Klavs Klavsen wrote: > Found out anything about why this is ? Any fix ? > > deleting a node hangs puppet-dashboard here :( - I have to restart to get > it up again. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users+unsubscr...@googlegroups.com. > To post to this group, send email to puppet-users@googlegroups.com. > Visit this group at http://groups.google.com/group/puppet-users?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] equivalent way to iterate through a hash
If I have something like this in my node file:
daemontools_service::setup {
'carbon-cache':
service_name => 'carbon-cache',
extra_envs => {
"GRAPHITE_STORAGE_DIR" => "/mnt/statsd-data/graphite-storage"
"SOMETHING_ELSE" => "12345"
"FOO" => "bar"
};
'another-service':
...etc.
}
and for those "extra_envs" values I want to create files that look like
this:
carbon-cache/
env/
GRAPHITE_STORAGE_DIR
SOMETHING_ELSE
FOO
with the *contents* of those files the *values* of the keys above, then I
was hoping I could do something like this:
--
class daemontools_service {
define envdir_file ($name, $value){
file { "/var/lib/supervise/${service_name}/env/${key}" :
mode => 644,
content=> "$value",
}
}
define setup(
$service_name,
$extra_envs={},
){
create_resources(envdir_file, $extra_envs)
--
But I get the error at the create_resources() line.
can't convert String into Hash
Is this the right approach? Or is there a more idiomatic way? Is it even
possible to iterate through a hash like that in puppet? I see some
indications on the web that this approach might work.
Any suggestions would be appreciated. Thanks!
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: hiera can't see a value on a puppet client, but the hiera app on the server can
Thank you On Thursday, May 9, 2013 12:07:30 PM UTC-7, Ygor wrote: > > Good luck to you. > My apologies at misunderstanding you earlier. Just trying to help > > “Sometimes I think the surest sign that intelligent life exists elsewhere > in the universe is that none of it has tried to contact us.” > Bill Waterson (Calvin & Hobbes) > > - Original Message - > From: "Campee" > > To: puppet...@googlegroups.com > Sent: Thursday, May 9, 2013 3:02:48 PM > Subject: Re: [Puppet Users] Re: hiera can't see a value on a puppet > client, but the hiera app on the server can > > I definitely did not restart httpd, but I can try that the next time I > encounter this issue. > > On Thursday, May 9, 2013 11:48:40 AM UTC-7, Ygor wrote: > > I use Passenger also. > You need to restart the httpd for the change to kick in. > > Is that what happened ? > > “Sometimes I think the surest sign that intelligent life exists elsewhere > in the universe is that none of it has tried to contact us.” > Bill Waterson (Calvin & Hobbes) > > - Original Message - > From: "Campee" < cam...@gmail.com > > To: puppet...@googlegroups.com > Sent: Thursday, May 9, 2013 2:46:19 PM > Subject: Re: [Puppet Users] Re: hiera can't see a value on a puppet > client, but the hiera app on the server can > > I am running httpd + passenger. The puppetmaster service is turned off and > not running. Do I need to restart httpd instead or does this not apply if > you're running httpd? > > On Thursday, May 9, 2013 11:36:34 AM UTC-7, Ygor wrote: > > Did you restart your puppetmaster process ? > > If you made any change to your config file (/etc/puppet/hiera.yaml) you > need to restart the puppetmaster process for the updates to be in effect. > > I spun my wheels a bit before that sunk in for me :) > > > “Sometimes I think the surest sign that intelligent life exists elsewhere > in the universe is that none of it has tried to contact us.” > Bill Waterson (Calvin & Hobbes) > > - Original Message - > From: "Campee" < cam...@gmail.com > > To: puppet...@googlegroups.com > Sent: Thursday, May 9, 2013 2:19:01 PM > Subject: [Puppet Users] Re: hiera can't see a value on a puppet client, > but the hiera app on the server can > > Thanks for telling me about the debug option. > > ericc@ops1-2-qa-sjc:puppet$ hiera -c /etc/puppet/hiera.yaml > ak_auth_primary region=northamerica datacenter=sjc environment=qa > machinetype=qa hostname=tag5-4-qa-sjc --debug > DEBUG: Thu May 09 11:04:27 -0700 2013: Hiera YAML backend starting > DEBUG: Thu May 09 11:04:27 -0700 2013: Looking up ak_auth_primary in YAML > backend > DEBUG: Thu May 09 11:04:27 -0700 2013: Looking for data source > regions/northamerica/datacenters/sjc/qa/qa/tag5-4-qa-sjc/tag5-4-qa-sjc > DEBUG: Thu May 09 11:04:27 -0700 2013: Cannot find datafile > /etc/puppet/hieradata/regions/northamerica/datacenters/sjc/qa/qa/tag5-4-qa-sjc/tag5-4-qa-sjc.yaml, > > skipping > DEBUG: Thu May 09 11:04:27 -0700 2013: Looking for data source > regions/northamerica/datacenters/sjc/qa/qa/qa > DEBUG: Thu May 09 11:04:27 -0700 2013: Cannot find datafile > /etc/puppet/hieradata/regions/northamerica/datacenters/sjc/qa/qa/qa.yaml, > skipping > DEBUG: Thu May 09 11:04:27 -0700 2013: Looking for data source > regions/northamerica/datacenters/sjc/qa/qa > DEBUG: Thu May 09 11:04:27 -0700 2013: Found ak_auth_primary in > regions/northamerica/datacenters/sjc/qa/qa > ops1-1-qa-sjc > > I ran Puppet again this morning on my client and now it works. I was > thinking that this indicates that the client was caching the manifest, even > though I was using the --test option when running Puppet manually on my > client. It was my understanding that --test tells the Puppet client not to > use a cached catalog. > > Any theories as to why it would work today even though I haven't changed a > single thing? (honestly!) > > > On Thursday, May 9, 2013 1:04:23 AM UTC-7, Luke Bigum wrote: > > > Hi Campee, > > On Thursday, May 9, 2013 3:34:20 AM UTC+1, Campee wrote: > > > > > > I run puppet and get this error: > > err: Could not retrieve catalog from remote server: Error 400 on SERVER: > Could not find data item ak_auth_primary in any Hiera data file and no > default supplied at /etc/puppet/manifests/site.pp:11 on node > tag5-4-qa-sjc.domain.net > > on my puppet master server: > > $ hiera ak_auth_primary region=northamerica datacenter=sjc environment=qa > > Answer: ops1-1-qa-sjc > > $ hiera ak_auth_primary region=northamerica datacenter=sjc environment=qa > machinetype=tag hostname=tag5-4-qa-sjc > > > > > Can you test Hiera like this (on your Puppet Master), it uses the Facts > cache of your node, rather than you filling in all the gaps by hand, and > thus is a more thorough test: > > > hiera -c /etc/puppet/hiera.yaml -y /var/lib/puppet/yaml/facts/ > tag5-4-qa-sjc.domain.net .yaml ak_auth_primary --debug > > > You should get some helpful debug trace through what Hier
[Puppet Users] Re: [ANN] puppet-cleaner 0.3.0 released
Upgrade to 0.3.1 is advised since it fixes a serious issue in an specific
circumstance.
El lunes, 6 de mayo de 2013 00:23:38 UTC-5, Gerardo Santana Gómez Garrido
escribió:
>
> This release adds a new option for ensuring that resource titles are
> quoted.
>
> puppet-cleaner is a set of tools that help keeping puppet DSL code closer
> to puppet style guide.
>
> Two transformations are done by default and are not optional: the use of
> ${} for variable interpolation in strings and the
> replacement of double with single quotes when possible.
>
> The optional transformations are:
>
> * alignment of fat arrows (`=>`)
> * removal of unneeded quotes around boolean literals
> * reordering of `ensure` attribute to the first position
> * declaration of symbolic links by using `ensure => link` and `target`
> attributes
> * conversion of /* */ style comments to #
> * representation of file modes as a 4 digits string
> * use of quotes around resource titles
> * indentation by n spaces
> * removal of unneeded quotes around variables
> * removal of trailing white space
>
> Installation: sudo gem install puppet-cleaner
> Website: https://github.com/santana/puppet-cleaner
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Announce: cis-puppet 0.2.0 is now available
OK. I have looked thru the module and I have some comments and feedback. I am delightfully impressed with what you have here. I am a bit disappointed with the sterile naming convention by CIS Benchmark document paragraph numbers. I think it makes it tougher to maintain, but that is just my opinion. I love how you made the collection of custom facts to evaluate the “hardness” of the system. I have a suggestion to reduce the amount of code needed to implement this: Your method uses 3 pieces: A shell script, a ruby fact wrapper that calls the script, and a manifest that checks the value of the custom fact. If you use External Facts, your scripts go into /etc/facter/facts.d and are called directly without the extra Ruby wrapper ! On May 7, 2013, at 12:34 PM, Arild Jensen wrote: > Overview > > > This module implements the Center for Internet Security (CIS) Security > Configuration Benchmark for Red Hat Enterprise Linux 6 v.1.1.0 (avilable at > http://benchmarks.cisecurity.org). Each scored control has been implemented > as a class or a custom fact. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Running all apt source and update operations first, best practice.
On Thu, May 9, 2013 at 11:52 AM, James Kyle wrote:
> I've run into several incidences where a module attempts to install a
> package before the apt::source is added or an update is run. Result is a
> bunch apt errors and explosions.
>
> Basically what should be done is all the apt::sources are added and and an
> update run _before_ any packages are installed to ensure you're pulling
> from the repos you want.
>
> I've gone through several iterations in my attempt to achieve that
> behavior. The one that works best so far is stages and wrapper classes.
> Here's a terse example of what it looks like:
>
> class myorg::common {
> include stdlib
>
> Apt::Source {stage => "setup"}
>
> apt::source { 'puppetlabs':
> location => 'http://apt.puppetlabs.com',
> repos => 'main',
> key=> '4BD6EC30',
> key_server => 'pgp.mit.edu',
> }
>
> Exec['apt_update'] -> Package<| title != 'ubuntu-cloud-keyring' |>
> }
>
> node 'foo.bar.com' {
> include stdlib
>
> class {'myorg::common': stage => "setup"}
> }
>
>
> One thing that bothers me is you have to declare the stage for
> myorg::common in every node that uses it. And as the name implies, that's
> every node.
>
> Is there a way to get rid of that duplication? I've thought of node
> inheritance, but the docs seem to strongly steer you away from that pattern.
>
Doesn't the relationship do the right thing without stages? Does this work?
class myorg::common (
$staging = 'setup',
) { ...
Nan
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: Puppermaster certificate expired
On Thu, May 9, 2013 at 3:57 PM, Stefan Schulte <
stefan.schu...@taunusstein.net> wrote:
> On Thu, 9 May 2013 17:10:51 +0200
> Lorenzo Salvadorini wrote:
>
> > 2013/5/9 Nicolai Mollerup
> >
> > > Anyway I think the easy way is to setup some autosigning of clients
> > > after creating a new CA.
> > > Think you will have to clean the ssl-dir on clients for this to
> > > work, though.
> > >
> > > Since we are going to make a brand new puppetmaster here sometime
> > > before our CA expires that will be my approach to make the
> > > transition smoother.
> > >
> >
> > we are exactly at the same point: currently moving our puppetmaster on
> > another host, struggling against CA hostname in SSL Certificates and
> > thinking how to approach the refresh of all certificates on agents.
>
There's some older thread when Puppet first hit this 5 year anniversary. I
recall trying a few things, and one that only required updating the CA cert
in the environment, but there's no avoiding touching every client once the
CA cert expired.
> > Autosigning for some day could be a good approach for us too, since
> > we have our racks with predefined networks IPs and master on amazon,
> > so amazon agents can contact master via internal network.
> >
> > We already manage agents configuration with a puppet module, do you
> > think we can do the SSL substitution with a recipe in puppet itself?
> >
>
> I'd not try to remove ssl certificates during a puppetrun because I
> expect that every file resource with a `source` parameter will fail
> after that point and the agent would not be able to send the last report
> to the old master.
>
> We had a slightly different approach when migrating our agents to a new
> master. We run puppet out of cron and the cronentry is also managed by
> puppet. Now we have the following simplified puppet::agent class:
>
> # need_migration is mostly calculated by checking the agent's
> # version and the current puppetmaster
> if $need_migration {
> $cron_command = '/var/lib/puppet/migrate.sh'
> }
> else {
> $cron_command = '/usr/bin/puppet agent'
> }
>
> cron { 'puppet_clientrun':
> command => $cron_command
> }
>
> If an agent contacts the old puppetmaster and need_migration evaluates
> to false, the agent will replace its cronjob with the migration script,
> so in the next interval we run the migration script instead of the
> puppet agent.
>
> The migration script updates the puppet software, updates the server
> setting in puppet.conf and erases the ssl directory (this is only done
> once in case the migrate.sh is executed more than once). The migrate.sh
> script will also trigger a normal puppetrun as the last step, so
> the puppet agent will create new certificates. The `migrate.sh` keeps
> running every hour until someones signes the new certificate request
> on the new master. Once the request is signed and the agent is able to
> contact the new mater, the $need_migration will evaluate to false and
> the migrate.sh in cron is replaced with the normal puppet agent
> invocation.
>
> This way we keet the removal of the ssl directory completly outside of
> puppet. We can also be sure that hosts that had puppet temporarily
> disabled will be instructed to migrate after they contact the (old)
> master again.
Off the top of my head, the ssldir option + server option should allow
migration to new server while keeping two different set of ssl keys as you
move the system to another master with a different CA. A mcollective puppet
plugin that supports both option might be useful for this kind of migration.
Nan
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
