Re: [Puppet Users] Certificate verify fails without indications
Jason, you could try to set one Redhat 4 node as master and verify if it works correctly with another RH4 agent, so you can establish if the problem is about RH4 agents or RH6 master.. On 14 February 2013 19:45, binaryred binary...@gmail.com wrote: On my puppet master, I uninstalled my puppet RPM, downloaded the tarball for puppet 3.1.0, modified the source for the certificate_signer.rb, and ran 'ruby install.db'. It installed the modified certificate_signer.rb file and runs just fine on the master (as it did before), but my client RHEL4 boxes still don't want to talk to the puppet master server correctly. I'm still getting the same error. Jason On Thursday, February 14, 2013 12:54:36 PM UTC-5, binaryred wrote: Yeah, I just replaced my server name with that. I've got RHEL5 and RHEL6 machines talking to my puppet master just fine. On Thursday, February 14, 2013 12:18:19 PM UTC-5, Felix.Frank wrote: On 02/14/2013 05:20 PM, binaryred wrote: Any other suggestions? Yeah, actually... err: Could not send report: certificate verify failed: [certificate signature failure for /CN=puppetmaster.example.com http://puppetmaster.example.**com http://puppetmaster.example.com] Is the name of your master puppetmaster.example.com? Are you sure your puppetca is set up properly? Regards, Felix -- 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: .erb templates are not properly parsed.
Dear John,
Thanks for your response.
Since I have a large environment setup I was trying to automatize all
setups from puppet, being as much simple as I can.
For example, let's think that I have a puppet server and more than 1000
puppet nodes. So I edit nodes.pp and I declare server1 and I assign it an
apache2 module, a bind9 module and an ssh module.
Once this is working I try and create a shorewall firewall erb template for
its rules file, so that it can automatically detect which modules are
declared on the host, and write the relevant lines in the rules file to
open the appropriate ports depending on that. In this example, the erb
template for shorewall rules would be something like:
# This file is centrally mantained by puppet, built from a template located
at #
# Path to file #
% if classes.include?('apache') -%
HTTP(ACCEPT)net$FW
% end -%
% if classes.include?('bind') -%
DNS/ACCEPT net $FW
% end -%
% if classes.include?('ssh') -%
SSH/ACCEPT net:someips $FW
% end -%
But this does not work for me. Could you provide me another clean and smart
way of achieving that? (Our goal would be not having to declare the whole
bunch of servers more than once, even in the nodes.pp file or in any other
place).
El jueves, 14 de febrero de 2013 17:35:50 UTC+1, Marc Bolós escribió:
Dear,
I've been using puppet for some time now. Usually when I have a problem I
read all documentation refered to the problem I have.
Recently I was trying to write a puppet erb template, that checks if host
has one class defined, and if it has then writes some text to cron.
After a lot of googleing, I found that the best way to do this was:
% if classes.include?( 'class1' ) -%
Some text
% end -%
And this worked.
But when I try on the same erb file to look for other classes, then it
only processes 1:
% if classes.include?( 'class1' ) -%
Some text
% end -%
% if classes.include?( 'class2' ) -%
Blah Blah Blah
% end -%
I can find only Some text inside file. But this host has class2 also
declared. If I remove if classes.include of class1, and leave alone class2
text, then I can see the text of class2.
Did anyone had this issue before?
Thanks for your time.
--
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: PuppetDB KahaDB db.data leak
Ken, here's my data from our (small) production environment: root@puppet:/var/lib/puppetdb/mq/localhost/KahaDB# du -sk * 23648 db-996.log 32 db.data 36 db.redo 0 lock root@puppet:/var/lib/puppetdb/mq/localhost/KahaDB# ps auxw | grep java USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND puppetdb 5320 0.5 16.0 1144504 163876 ? Sl Feb11 30:05 /usr/bin/java -XX:OnOutOfMemoryError=kill -9 %p -Xmx192m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/puppetdb/puppetdb-oom.hprof -jar /usr/share/puppetdb/puppetdb.jar services -c /etc/puppetdb/conf.d root@puppet:/var/lib/puppetdb/mq/localhost/KahaDB# dpkg -s puppetdb | grep Version Version: 1.1.1-1puppetlabs1 Regards, Martijn Op woensdag 13 februari 2013 19:00:40 UTC+1 schreef Ken Barber het volgende: Hi all, I've been looking at a potential problem, as documented here: http://projects.puppetlabs.com/issues/19241 -- 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] Puppet Automatic Resource State changing...
Morning all, Firstly, apologies for the length of this post, however I thought it probably most useful to fully outline the challenge and the desired result... Ok, so we're in the process of Puppetizing our Oracle/NetApp platform for Live/DR running. The current manual process, upon setting up a new database, a set of volumes are created to contain the various Oracle DB elements, and these are then SnapMirror'd to the DR site. This SnapMirror process requires a period of time to copy the base data over... This time period is directly relational to the amount of data required... I.e. a copy of 20Gb may take an hour, 200Gb may take 10 hours... During this period, the SnapMirror resource is in an 'initializing' state. Once the data copy is complete, then the resource will change to an 'initialized' state. The next step in the process is then to break the relationship so that the DR end can be used in a R/W mode... Now, in order to Puppetize this, I need to be able to replicate the above behaviour... I've got Puppet to create and initialize the relationship, and that works as expected. However Puppet doesn't currently care about the relationship state. Now that's easy enough to add in as a new property against the type/provider. However what I'm struggling to understand is how, or if it's even possible, to automate the switch from 'Initialized' state to a 'Broken' state upon completion of the initialization stage??? Now these databases definitions are currently driven from a YAML backend which maintains information such as database name, volume information, primary netapp controller, replication netapp controller, etc... Currently, this YAML file is just a file on the puppet master... However there are ambitions to move this into a more dynamic backend, such as CouchDB or similar... So that opens the possibility to automatically update the YAML resource state.. However Puppet still needs to be able to support updating that backend based on the information it gets from the actual resource... So to flow it out: 1. Create a new database in backend - 2. Puppet creates volumes on primary - 3. Data is added to volumes - 4. Backend updated to indicate replication is required - 5. Puppet creates volumes on Secondary and adds Snapmirror relationship - 6. Snapmirror initializes in background - 7. Puppet periodically runs against network device and checks resource state - 8. Backend resource state is updated following each run? - 9. Snapmirror initialization completes - 10. Puppet runs, detects new resource state and then triggers break? 11. Backend resource state updated to 'broken'? Now 1 to 7 above are fine, but 8 to 11 are where I get a bit unsure... So, that's the challenge... Am I barking up the wrong tree, or is this something that Puppet could manage? Cheers in advance for any responses. Regards Gavin -- 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] Relize uses buy groups membership
I have been tinkering off and on with this. Try setting up a few users with more than one entry in groups The double equal sign operator might work for this. If I get a chance to re-visit that sandbox, I will reply to this thread again. Using Puppet 3 helps. “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: Kubes pkubat.ml...@freepricealerts.com To: puppet-users@googlegroups.com Sent: Friday, February 15, 2013 12:12:59 AM Subject: [Puppet Users] Relize uses buy groups membership Hello, I have created my users via virtual definitions and hiera. Now I want to realize the virutal users by groups. I have an trying the following syntax: User::Virtual | groups == wheel | BTW: This works fine: User::Virtual | title == bsmith | Is the there a comparison for in for the spaceship operator? As group is an array. Any other ideas how to realize a entire group of admins? 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 . -- 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] Certificate verify fails without indications
Luigi, Thanks for the suggestion, however I've already done that in some sense. Here's my FULL situation: I was running a puppet 2.6.6 master on a RHEL5 machine with lots of RHEL4,5,6 machines (mostly RHEL5) connecting to it. The clients are all running puppet 0.25.5 and working just fine. I've built a new puppet server on a RHEL6 machine, running 3.1.0. I copied over the SSL certs from the old puppet master so that when the clients connect to the new server, they 'just work', and pretty much that has worked great for me. I certainly plan to upgrade the clients to the latest version of puppet I can, but for now they are working fine. EXCEPT for the RHEL4 machines. I tried the version of puppet that was on them first (0.25.5), and when that didn't work, I found some puppet 2.7 packages (and dependencies) to install, but they don't seem to work any better. So the short story is, that the RHEL 4 clients can talk to my old puppet master, but not the new one, while everything else talks to the new puppet master just fine. Jason On Friday, February 15, 2013 5:03:32 AM UTC-5, Luigi Martin Petrella wrote: Jason, you could try to set one Redhat 4 node as master and verify if it works correctly with another RH4 agent, so you can establish if the problem is about RH4 agents or RH6 master.. On 14 February 2013 19:45, binaryred bina...@gmail.com javascript:wrote: On my puppet master, I uninstalled my puppet RPM, downloaded the tarball for puppet 3.1.0, modified the source for the certificate_signer.rb, and ran 'ruby install.db'. It installed the modified certificate_signer.rb file and runs just fine on the master (as it did before), but my client RHEL4 boxes still don't want to talk to the puppet master server correctly. I'm still getting the same error. Jason On Thursday, February 14, 2013 12:54:36 PM UTC-5, binaryred wrote: Yeah, I just replaced my server name with that. I've got RHEL5 and RHEL6 machines talking to my puppet master just fine. On Thursday, February 14, 2013 12:18:19 PM UTC-5, Felix.Frank wrote: On 02/14/2013 05:20 PM, binaryred wrote: Any other suggestions? Yeah, actually... err: Could not send report: certificate verify failed: [certificate signature failure for /CN=puppetmaster.example.com http://puppetmaster.example.**com http://puppetmaster.example.com] Is the name of your master puppetmaster.example.com? Are you sure your puppetca is set up properly? Regards, Felix -- 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 javascript:. To post to this group, send email to puppet...@googlegroups.comjavascript: . 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] Re: Installing on SLES 11.2?
There should be no reason to add any repo's other then systemsmanagement:puppet for dependencies. The deps should be created as packages links to the which ever development repo they reside in. Any discussion regarding this should be taken off the puppet list and moved onto the opensuse-buildservice list or directed at the repository maintainers. -- Later, Darin On Fri, Feb 15, 2013 at 1:46 AM, Niels Abspoel abo...@gmail.com wrote: For the ruby depencies you need the following repositories on SLE_11_SP2: devel:languages:ruby:backports/SLE_11_SP2 and of course: SUSE:SLE-11:SP2/standard See for more information: https://build.opensuse.org/project/repositories?project=systemsmanagement%3Apuppet Hope this helps. Op vrijdag 15 februari 2013 02:18:33 UTC+1 schreef JB Bell het volgende: I've been unable to get puppet installed on SLES 11.2 by the recommended method. I've set up the repo at http://download.opensuse.org/repositories/systemsmanagement:/puppet/SLE_11_SP2/, but when I do zypper install puppet I get multiple dependency errors, e.g.: Problem: nothing provides rubygems needed by rubygem-hiera-1.1.2-8.1.x86_64 I had a prior install of puppet kind of working without that repo, but I need to have the ruby-shadow package. A good number of articles and bug reports online talk about this, and supposedly that repo is the solution. I don't find any docs at all on the official puppetlabs site, and the old wiki references a repo that doesn't seem to exist anymore; at any rate, it's for SLES 10.2. Any clues? I don't want to have to install from source--we have dozens of SLES servers. Thanks for any help you can provide. Ideally I'd like a step-by-step for SLES, but anything would be good. J B Bell Test Environment Professional Ericsson ITTE 4333 Still Creek Drive Burnaby, BC V5C 6S6, Canada Phone +1 778.373.7150 jb@ericsson.com www.ericsson.com -- 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] Certificate verify fails without indications
Jason, for the reasons we wrote before in prevoius messages (especially what Matt Black said), Puppet 3.1.0 will never work with an agent that run openssl library version 0.9.7 (which is the version running on RH4) Even if you had master with Puppet 2.7.x working correctly with RH4 nodes, it is perfectly clear that upgrading to puppet 3.1.0 (without modifying certificate_signer.rb) the connection with RH4 agent will fail rising the error you have. If you correctly modified certificate_signer.rb and re-installed puppet with the modified source, maybe you have ALSO ANOTHER problem somewhere else, but in that case I can't figure where... On 15 February 2013 13:54, binaryred binary...@gmail.com wrote: Luigi, Thanks for the suggestion, however I've already done that in some sense. Here's my FULL situation: I was running a puppet 2.6.6 master on a RHEL5 machine with lots of RHEL4,5,6 machines (mostly RHEL5) connecting to it. The clients are all running puppet 0.25.5 and working just fine. I've built a new puppet server on a RHEL6 machine, running 3.1.0. I copied over the SSL certs from the old puppet master so that when the clients connect to the new server, they 'just work', and pretty much that has worked great for me. I certainly plan to upgrade the clients to the latest version of puppet I can, but for now they are working fine. EXCEPT for the RHEL4 machines. I tried the version of puppet that was on them first (0.25.5), and when that didn't work, I found some puppet 2.7 packages (and dependencies) to install, but they don't seem to work any better. So the short story is, that the RHEL 4 clients can talk to my old puppet master, but not the new one, while everything else talks to the new puppet master just fine. Jason On Friday, February 15, 2013 5:03:32 AM UTC-5, Luigi Martin Petrella wrote: Jason, you could try to set one Redhat 4 node as master and verify if it works correctly with another RH4 agent, so you can establish if the problem is about RH4 agents or RH6 master.. On 14 February 2013 19:45, binaryred bina...@gmail.com wrote: On my puppet master, I uninstalled my puppet RPM, downloaded the tarball for puppet 3.1.0, modified the source for the certificate_signer.rb, and ran 'ruby install.db'. It installed the modified certificate_signer.rb file and runs just fine on the master (as it did before), but my client RHEL4 boxes still don't want to talk to the puppet master server correctly. I'm still getting the same error. Jason On Thursday, February 14, 2013 12:54:36 PM UTC-5, binaryred wrote: Yeah, I just replaced my server name with that. I've got RHEL5 and RHEL6 machines talking to my puppet master just fine. On Thursday, February 14, 2013 12:18:19 PM UTC-5, Felix.Frank wrote: On 02/14/2013 05:20 PM, binaryred wrote: Any other suggestions? Yeah, actually... err: Could not send report: certificate verify failed: [certificate signature failure for /CN=puppetmaster.example.com http://puppetmaster.example.**c**omhttp://puppetmaster.example.com] Is the name of your master puppetmaster.example.com? Are you sure your puppetca is set up properly? Regards, Felix -- 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=enhttp://groups.google.com/group/puppet-users?hl=en . For more options, visit https://groups.google.com/**groups/opt_outhttps://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.
[Puppet Users] Re: Relize uses buy groups membership
Thanks. I am using 3.1 Thanks On Friday, February 15, 2013 12:12:59 AM UTC-5, Kubes wrote: Hello, I have created my users via virtual definitions and hiera. Now I want to realize the virutal users by groups. I have an trying the following syntax: User::Virtual | groups == wheel | BTW: This works fine: User::Virtual | title == bsmith | Is the there a comparison for in for the spaceship operator? As group is an array. Any other ideas how to realize a entire group of admins? 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] Certificate verify fails without indications
I will try to work with the certificate_signer.rb file and see if I can get it to work. Thanks for the help! Jason On Friday, February 15, 2013 8:21:28 AM UTC-5, Luigi Martin Petrella wrote: Jason, for the reasons we wrote before in prevoius messages (especially what Matt Black said), Puppet 3.1.0 will never work with an agent that run openssl library version 0.9.7 (which is the version running on RH4) Even if you had master with Puppet 2.7.x working correctly with RH4 nodes, it is perfectly clear that upgrading to puppet 3.1.0 (without modifying certificate_signer.rb) the connection with RH4 agent will fail rising the error you have. If you correctly modified certificate_signer.rb and re-installed puppet with the modified source, maybe you have ALSO ANOTHER problem somewhere else, but in that case I can't figure where... On 15 February 2013 13:54, binaryred bina...@gmail.com javascript:wrote: Luigi, Thanks for the suggestion, however I've already done that in some sense. Here's my FULL situation: I was running a puppet 2.6.6 master on a RHEL5 machine with lots of RHEL4,5,6 machines (mostly RHEL5) connecting to it. The clients are all running puppet 0.25.5 and working just fine. I've built a new puppet server on a RHEL6 machine, running 3.1.0. I copied over the SSL certs from the old puppet master so that when the clients connect to the new server, they 'just work', and pretty much that has worked great for me. I certainly plan to upgrade the clients to the latest version of puppet I can, but for now they are working fine. EXCEPT for the RHEL4 machines. I tried the version of puppet that was on them first (0.25.5), and when that didn't work, I found some puppet 2.7 packages (and dependencies) to install, but they don't seem to work any better. So the short story is, that the RHEL 4 clients can talk to my old puppet master, but not the new one, while everything else talks to the new puppet master just fine. Jason On Friday, February 15, 2013 5:03:32 AM UTC-5, Luigi Martin Petrella wrote: Jason, you could try to set one Redhat 4 node as master and verify if it works correctly with another RH4 agent, so you can establish if the problem is about RH4 agents or RH6 master.. On 14 February 2013 19:45, binaryred bina...@gmail.com wrote: On my puppet master, I uninstalled my puppet RPM, downloaded the tarball for puppet 3.1.0, modified the source for the certificate_signer.rb, and ran 'ruby install.db'. It installed the modified certificate_signer.rb file and runs just fine on the master (as it did before), but my client RHEL4 boxes still don't want to talk to the puppet master server correctly. I'm still getting the same error. Jason On Thursday, February 14, 2013 12:54:36 PM UTC-5, binaryred wrote: Yeah, I just replaced my server name with that. I've got RHEL5 and RHEL6 machines talking to my puppet master just fine. On Thursday, February 14, 2013 12:18:19 PM UTC-5, Felix.Frank wrote: On 02/14/2013 05:20 PM, binaryred wrote: Any other suggestions? Yeah, actually... err: Could not send report: certificate verify failed: [certificate signature failure for /CN=puppetmaster.example.com http://puppetmaster.example.**c**omhttp://puppetmaster.example.com] Is the name of your master puppetmaster.example.com? Are you sure your puppetca is set up properly? Regards, Felix -- 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=enhttp://groups.google.com/group/puppet-users?hl=en . For more options, visit https://groups.google.com/**groups/opt_outhttps://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...@googlegroups.com javascript:. To post to this group, send email to puppet...@googlegroups.comjavascript: . 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: multiple nodes
On Thursday, February 14, 2013 5:02:22 PM UTC-6, Michael Hüttermann wrote: Hello, in case you want to manage a node with multiple masters (that may manage different aspects of that system): is it possible to run multiple puppet agent daemons on one node (listening to different masters) or to configure one agent daemon to listen to multiple masters? It should be possible -- with some work -- to arrange for multiple agents to run independently on the same node. It might help to hack the agent a little, but I can think of at least one way to do it without changes to Puppet. In such a configuration, the different agents could be made to talk to different masters. Pete has it right, however: this is a terrible idea. Your are asking for pain and grief, wailing, gnashing of teeth, burning sulfur, etc.. 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] Running Puppet Agent from the system crontab
Found this out the hard way :) Thought I would share. For reasons I will not go into, I am running puppet agent by cron using the system crontab -- /etc/crontab and /etc/cron.d/* In those, you have to define your environment. Thru trial and error, I found what I believe is the minimum environment settings for my systems: These are Red Hat Enterprise 5 running Puppet 2.7.20 The top of my /etc/cron.d/puppet.cron is : # /etc/cron.d/puppet.cron: Run Puppet Agent in a non-daemon mode SHELL=/bin/bash PATH=/bin:/usr/bin # minute hour day-of-month month day-of-week user-to-run-as TheCommand Of course I am using a template with %= scope.function_fqdn_rand([60]) % to get a random minute for each server. “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin Hobbes) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] shared header across multiple defined types via concat
Hi Felix, On Thu, Feb 14, 2013 at 7:07 AM, Felix Frank felix.fr...@alumni.tu-berlin.de wrote: So basically you want all generated files to use the same header template? Hmm. This is correct. I believe what you want is another defined type that represents the header snippet for a specific pam config file and declares a concat::fragment $name-header or somesuch. Each of the other defined types then contains an instance of this new type, probably not passing more than the name. I've tried this approach and the problem you run into is when defining multiple pam::limits you create a duplicate declaration caused by pam::header being called for each instance. It attempts to create multiple headers. -- Later, Darin -- 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: puppet client 0.22.1-1 unable to communicate with master on 3.0.2-1
Can http://rvm.io build a local ruby for you on that system? Hello David, apologies for the belated response on this .. But no, rvm is not an option because it has a bash shell version dependency that dapper (or any of the nearby distros, up to feisty) cannot satisfy .. so, it does seem like the only solution would be a full manual build of ruby = 1.8.7 BTW, I made a mistake in the very first copy and paste I made to open up this thread .. please, help me delete your previous comments to hide my blushes .. ;-) -- 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: roles, profiles, and hiera
On Thursday, February 14, 2013 1:45:36 PM UTC-6, Chad Huneycutt wrote:
Thanks, John. I think you are right that puppet should support it,
but I am pretty sure it does not. I chatted with RI, and it seems
that the classname is not exposed, so when the puppet backend does
the lookup, it figures out the classname and sets the 'calling_class'
variable before it interprets the hierarchy. I am going to try to
hack the same thing into the yaml backend, as well as file a bug (or
+1 one) about it.
Yes, R.I. was explaining the current state of the code, as is also
summarized in the PL bug tracker. In addition to issue 14985, which we
discussed above, there is http://projects.puppetlabs.com/issues/16730,
which speaks directly to how %{calling_class} and %{calling_module} could
be used in hiera.yaml in Puppet 2.7, whereas Puppet 3 apparently regressed
on that. That issue has been marked as a duplicate of 14985, however; I
mention it to give you confidence about which issue to watch / vote up
(14985). Also to confirm that PL not only agrees that there's an issue,
but has a solution in flight.
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: .erb templates are not properly parsed.
On Friday, February 15, 2013 4:18:20 AM UTC-6, Marc Bolós wrote:
Dear John,
Thanks for your response.
Since I have a large environment setup I was trying to automatize all
setups from puppet, being as much simple as I can.
For example, let's think that I have a puppet server and more than 1000
puppet nodes. So I edit nodes.pp and I declare server1 and I assign it an
apache2 module, a bind9 module and an ssh module.
Once this is working I try and create a shorewall firewall erb template
for its rules file, so that it can automatically detect which modules are
declared on the host, and write the relevant lines in the rules file to
open the appropriate ports depending on that. In this example, the erb
template for shorewall rules would be something like:
# This file is centrally mantained by puppet, built from a template
located at #
# Path to file #
% if classes.include?('apache') -%
HTTP(ACCEPT)net$FW
% end -%
% if classes.include?('bind') -%
DNS/ACCEPT net $FW
% end -%
% if classes.include?('ssh') -%
SSH/ACCEPT net:someips $FW
% end -%
But this does not work for me. Could you provide me another clean and
smart way of achieving that? (Our goal would be not having to declare the
whole bunch of servers more than once, even in the nodes.pp file or in any
other place).
El jueves, 14 de febrero de 2013 17:35:50 UTC+1, Marc Bolós escribió:
Dear,
I've been using puppet for some time now. Usually when I have a problem I
read all documentation refered to the problem I have.
Recently I was trying to write a puppet erb template, that checks if host
has one class defined, and if it has then writes some text to cron.
After a lot of googleing, I found that the best way to do this was:
% if classes.include?( 'class1' ) -%
Some text
% end -%
And this worked.
But when I try on the same erb file to look for other classes, then it
only processes 1:
% if classes.include?( 'class1' ) -%
Some text
% end -%
% if classes.include?( 'class2' ) -%
Blah Blah Blah
% end -%
I can find only Some text inside file. But this host has class2 also
declared. If I remove if classes.include of class1, and leave alone class2
text, then I can see the text of class2.
Did anyone had this issue before?
Thanks for your time.
There are basically two good ways to approach this:
1. Have your service modules (apache2, bind9, ssh) each export an
appropriate fragment of the FW configuration (using fragment resource types
provided by the Puppet::Concat add-in module), or
2. use the same data or logic by which you chose to include those
modules on a given node in the first place to drive which sections are
included in the FW config file.
If there are nodes on which you do not configure a firewall, then as a
variation on option (1), you can declare the fragments as virtual
resources, to be realized only on those nodes with FW.
There are a lot of ways you could do (2), but one might be
manifests/site.pp:
node somenode {
$service_modules = hiera_array('service_modules')
include $service_modules
include firewall
}
modules/firewall/manifests/init.pp
class firewall {
$service_modules = hiera_array('service_modules')
# other classes
file { 'firewall-rules-filename':
# other properties
content = template('config.erb')
}
}
modules/firewall/templates/config.erb
% if @service_modules.include?('apache2') -%
# config-for-apache2
% end -%
% if @service_modules.include?('bind9') -%
# config-for-bind9
% end -%
% if @service_modules.include?('ssh') -%
# config-for-ssh
% end -%
Yes, that template looks a lot like your original. The key difference is
the data source on which it is drawing: not a list of classes that *have
been *assigned by that point in the catalog compilation process, but rather
a list of relevant classes that *will have been* assigned by the end of
catalog compilation. Furthermore, it's all based on on the same data, so
there is no risk of your module list falling out of sync with your firewall
config.
Although I use hiera in the example, I hope you recognize that that's an
implementation detail (albeit a convenient one), not an essential element.
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.
Re: [Puppet Users] shared header across multiple defined types via concat
Hi,
it's paramount that you generate a unique $name for each invocation of
your defined type, e.g.
pam::header { limits-$name: }
You can take advantage of the fact that the calling defines have
unique names of their own.
HTH,
Felix
On 02/15/2013 03:31 PM, Darin Perusich wrote:
I believe what you want is another defined type that represents the
header snippet for a specific pam config file and declares a
concat::fragment $name-header or somesuch. Each of the other defined
types then contains an instance of this new type, probably not passing
more than the name.
I've tried this approach and the problem you run into is when defining
multiple pam::limits you create a duplicate declaration caused by
pam::header being called for each instance. It attempts to create
multiple headers.
--
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: Referencing resource from another class
Thanks a lot John, the explanation was really helpful.
On Thursday, February 14, 2013 4:32:38 PM UTC+2, jcbollinger wrote:
On Thursday, February 14, 2013 5:10:43 AM UTC-6, Andriy Yurchuk wrote:
Found out that it's very simple: subscribe = Class['module::class_2']
On Thursday, February 14, 2013 12:20:30 PM UTC+2, Andriy Yurchuk wrote:
class module::class_1 {
service {
ensure = running,
hasrestart = true,
subscribe = File[/tmp/myfile],
}
}
class module::class_2 {
file { '/tmp/myfile':
source = 'puppet:///file_server/my_file',
}
}
Having those two classes, how do I correctly write the subscribeparameter
in
class_1 so that it used the file resource from class_2?
Although you can subscribe to the whole class, that's often not what you
want, as it really means subscribing to every resource declared by that
class. If only one resource is declared then that's no problem, but many
classes are more complicated.
A very important point here is that resources are global once they are
declared. Any resource, declared anywhere, can declare a relationship to
any other resource, declared anywhere else, and the sites of the
declarations do not factor into the syntax. The syntax in your example is
correct.
On the other hand, it is important to ensure that resources are declared
before references to them are used. If a resource declared in one class is
going to declare a relationship to a resource declared in a different one,
then you must make sure that the latter class is parsed before the former
one's resource declaration. As long as the latter class is not
parametrized, the easiest and best way to accomplish that is for the former
class to 'include' the latter at the top of its body:
class module::class_1 {
include 'module::class_2'
service {
ensure = running,
hasrestart = true,
subscribe = File[/tmp/myfile],
}
}
That also has the advantage of documenting the dependency between the two
classes. For it to work properly, however, you should arrange your classes
each in its own file, laid out in the way the autoloader expects.
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: .erb templates are not properly parsed.
Dear John, I will try as you suggested, but it's pretty clear that this will work. Thanks a lot for your time. El jueves, 14 de febrero de 2013 17:35:50 UTC+1, Marc Bolós escribió: Dear, I've been using puppet for some time now. Usually when I have a problem I read all documentation refered to the problem I have. Recently I was trying to write a puppet erb template, that checks if host has one class defined, and if it has then writes some text to cron. After a lot of googleing, I found that the best way to do this was: % if classes.include?( 'class1' ) -% Some text % end -% And this worked. But when I try on the same erb file to look for other classes, then it only processes 1: % if classes.include?( 'class1' ) -% Some text % end -% % if classes.include?( 'class2' ) -% Blah Blah Blah % end -% I can find only Some text inside file. But this host has class2 also declared. If I remove if classes.include of class1, and leave alone class2 text, then I can see the text of class2. Did anyone had this issue before? Thanks for your time. -- 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: Daemonize puppet agent but disable periodic runs
Hi, have you made sure you pass the --listen option alongside --no-client? On 02/14/2013 11:21 AM, Andriy Yurchuk wrote: This works, but this disables the ability to push configs via MCollective, i.e. mco puppet runall/runonce do not work. On Wednesday, February 13, 2013 5:51:56 PM UTC+2, Vaidas Jablonskis wrote: You would have to run your agent daemon wiht '--no-client' parameter. See 'man puppet.conf'. On Wednesday, 13 February 2013 13:49:06 UTC, Andriy Yurchuk wrote: I need puppet agent daemon running because I need to access agent's REST API (http://docs.puppetlabs.com/guides/rest_api.html#the-agent-rest-api http://docs.puppetlabs.com/guides/rest_api.html#the-agent-rest-api). But I don't need the agent to run periodic checks. Is there any way to either access REST API without daemonizing agent (I suspect this id not possible) or disable periodic runs while running agent as a daemon? -- 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: Daemonize puppet agent but disable periodic runs
There is a ignoreschedules option for puppet agent (http://docs.puppetlabs.com/references/latest/configuration.html#ignoreschedules), but it does not seem to work. Even if it is set to true the agent is being run every runinterval seconds. On Thursday, February 14, 2013 12:21:39 PM UTC+2, Andriy Yurchuk wrote: This works, but this disables the ability to push configs via MCollective, i.e. mco puppet runall/runonce do not work. On Wednesday, February 13, 2013 5:51:56 PM UTC+2, Vaidas Jablonskis wrote: You would have to run your agent daemon wiht '--no-client' parameter. See 'man puppet.conf'. On Wednesday, 13 February 2013 13:49:06 UTC, Andriy Yurchuk wrote: I need puppet agent daemon running because I need to access agent's REST API (http://docs.puppetlabs.com/guides/rest_api.html#the-agent-rest-api). But I don't need the agent to run periodic checks. Is there any way to either access REST API without daemonizing agent (I suspect this id not possible) or disable periodic runs while running agent as a daemon? -- 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: PuppetDB API permissions
My biggest concern is that nodes can access other nodes resources stored in PuppetDB, which effectively means that parameters like passwords and other sensitive information is exposed. If the data is not exported this shouldn't be the case ordinarily. It actually is the case. For example a file resource does not have to be exported for its content to be stored in puppetdb. Yup agreed ... which is what I was trying to say here, probably not very clearly though: Obviously though if your content is uncontrolled it is possible for someone to use a function from the puppet master to query data (FYI - functions run on the puppetmaster, not the agents). I think just a simple separation would be sufficient. So that nodes by default wouldn't be able to access data from other environments. I would also be nice to be able easily query PuppetDB API by environment, something like: /v2/environment/nodes or /v2/nodes?environment=environment. So in this case for true separation the puppet master would need to declare to the PuppetDB what environment it is constrained too. Interesting problem, as confining PuppetDB access down to a certificate would then not be enough to constrain this for security purposes, as we don't hand out per environment Puppet master certificates :-). Today, the way to do it would be - separate puppet master (each with their own certificate) and separate PuppetDB instance, with whitelists only allowing the master on a particular environment to talk to a PuppetDB on the same environment. This may or not be desirable ... but there are other levels of security separation that might deem this necessary beyond PuppetDB. Hiera data is an example of other data one would want to separate (especially hiera-gpg stored data). That is, if one truly wanted to keep environments separate for security reasons - running completely separate hosts/clusters for each environment for this would provide better guarantees to that end, not just at an application level. With each environment maintaining its own CA, master, puppetdb and hiera sources etc. ken. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: Daemonize puppet agent but disable periodic runs
Yes, I had --no-client and listen = true in puppet.conf. With these settings the agent does not respond to MCollective calls. On Friday, February 15, 2013 5:29:44 PM UTC+2, Felix.Frank wrote: Hi, have you made sure you pass the --listen option alongside --no-client? On 02/14/2013 11:21 AM, Andriy Yurchuk wrote: This works, but this disables the ability to push configs via MCollective, i.e. mco puppet runall/runonce do not work. On Wednesday, February 13, 2013 5:51:56 PM UTC+2, Vaidas Jablonskis wrote: You would have to run your agent daemon wiht '--no-client' parameter. See 'man puppet.conf'. On Wednesday, 13 February 2013 13:49:06 UTC, Andriy Yurchuk wrote: I need puppet agent daemon running because I need to access agent's REST API ( http://docs.puppetlabs.com/guides/rest_api.html#the-agent-rest-api http://docs.puppetlabs.com/guides/rest_api.html#the-agent-rest-api). But I don't need the agent to run periodic checks. Is there any way to either access REST API without daemonizing agent (I suspect this id not possible) or disable periodic runs while running agent as a daemon? -- 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] Trying to install a specific version of Java on Redhat
I should have added to my post that I've tried adding that 1: as well to
the ensure line with the same results.
Any other ideas?
I've tried this workaround:
exec { upgrade java:
command = yum -d 1 -e 1 upgrade
java-1.6.0-sun-1:1.6.0.39-1jpp.4.el5_9.x86_64
java-1.6.0-sun-devel-1:1.6.0.39-1jpp.4.el5_9.x86_64 -y,
path= /usr/bin/
}
...but it then runs every single time the puppet agent runs:
notice: /Stage[main]/Java/Exec[upgrade java]/returns: executed successfully
On Thursday, February 14, 2013 4:52:17 AM UTC-7, Felix.Frank wrote:
Hi,
please take note that
On 02/14/2013 02:32 AM, Sean LeBlanc wrote:
ensure = '1.6.0.39-1jpp.4.el5_9',notice:
...this version is unlike...
/Stage[main]/Java/Package[java-1.6.0-sun.x86_64]/ensure: ensure changed
'1.6.0.33-1jpp.1.el5_8' to '1:1.6.0.39-1jpp.4.el5_9'
...this version. Notice the leading 1:
HTH,
Felix
--
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] Name or service not known issue
Felix - d) add a server= entry to your puppet.conf This needs to be a fully qualified domain name (FQDN) - correct? Thanks in advance, Adam On Friday, June 10, 2011 7:44:46 AM UTC-5, Felix.Frank wrote: Hi, you need to do one of these: a) create a DNS entry for puppet pointing to your master b) create a hosts entry for puppet pointing to your master c) specify the --server parameter with an address resolving to your master d) add a server= entry to your puppet.conf HTH, Felix On 05/27/2011 10:39 AM, Sumith Sudhakaran wrote: Hi, When I am trying update from puppet client, getting error like blow *err: Could not request certificate: getaddrinfo: Name or service not known puppetd --test output:- err: Could not request certificate: getaddrinfo: Name or service not known Exiting; failed to retrieve certificate and waitforcert is disabled* Please help to solve the same.. -- / Regards/// / Sumith/// -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet...@googlegroups.comjavascript: . To unsubscribe from this group, send email to puppet-users...@googlegroups.com javascript:. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To 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] Puppet agent daemon not seeing a Facter fact
Hi all, first post here... reposting this from Stack Overflow as it didn't
get much traction there...
I am using puppet to read a fact from facter, and based on that I apply a
different configuration to my modules.
Problem:
the puppet agent isn't seeing this fact. Running puppet agent --test
interactively
works as expected. Even running it non-interactively from a script seems to
work fine. Only the agent *daemon* is screwing up.
Process:
I am deploying an Ubuntu-based app stack on EC2. Using userdata
(#cloud-config), I set an environment variable in /etc/environment:
export FACTER_tl_role=development
then immediately in #cloud-config, i source /etc/environment. only THEN i
apt-get install puppet (i moved away from using package: puppet to
eliminate ambiguity in the sequence of #cloud-config steps)
Once the instance boots, I confirm that the fact is available: running facter
tl_role returns development. I then check /var/log/syslog, and apparently
the puppet agent is not seeing this fact - I know this because it's unable
to compile the catalog, and there's nothing (blank) where I'm supposed to
be seeing the value of the variable set depending on this fact.
However, running puppet agent --test interactively compiles and runs the
catalog just fine. even running this from the #cloud-config script
(immediately after installing puppet) also works just fine.
How do I make this fact available to the puppet agent? Restarting the agent
service makes no difference, it remains unaware of the custom fact.
Rebooting the instance also makes no difference.
here's some code:
EC2 userdata:
#cloud-config
puppet:
conf:
agent:
server: puppet.foo.bar
certname: %i.%f
report: true
runcmd:
- sleep 20
- echo 'export FACTER_tl_role=development' /etc/environment
- . /etc/environment
- apt-get install puppet
- puppet agent --test
Main puppet manifest:
# /etc/puppet/manifests/site.pp
node default {
case $tl_role {
'development': { $sitedomain = dev.foo.bar}
'production': { $sitedomain = new.foo.bar}
}
class {code : sitedomain = $sitedomain}
class {apache::site : sitedomain = $sitedomain}
class {nodejs::grunt-daemon : sitedomain = $sitedomain}
And then I see failures where $sitedomain is supposed to be, so $tl_role
appears to be not set.
Any ideas? This is exploding my brain
--
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] Installation from the scratch
Hi all, I'm trying to understand how puppet works, and my idea is to learn installing a new environment from the scratch. I have the following: Master: cat /etc/debian_version 6.0.6 puppet --version 3.1.0 cat /etc/hosts 127.0.1.1 puppetmaster.domain.namepuppetmaster puppet Client: cat /etc/SuSE-release SUSE Linux Enterprise Server 11 (x86_64) VERSION = 11 PATCHLEVEL = 2 puppet --version 2.6.12 cat /etc/hosts 127.0.0.1 puppetclient01.domain.name puppetclient01 192.168.203.128 puppet puppetmaster.domain.name puppet agent --test info: Creating a new SSL key for puppetclient01.domain.name warning: peer certificate won't be verified in this SSL session warning: peer certificate won't be verified in this SSL session info: Creating a new SSL certificate request for puppetclient01.domain.name info: Certificate Request fingerprint (md5): 88:B5:17:BF:DD:39:90:ED:0D:1A:9D:3C:A7:51:8C:D3 warning: peer certificate won't be verified in this SSL session warning: peer certificate won't be verified in this SSL session warning: peer certificate won't be verified in this SSL session Exiting; no certificate found and waitforcert is disabled Once I sign it in the server…. puppetclient01:~ # puppet agent --test warning: peer certificate won't be verified in this SSL session info: Caching certificate for puppetclient01.domain.name err: Could not retrieve catalog from remote server: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed warning: Not using cache on failed catalog err: Could not retrieve catalog; skipping run puppet agent --test err: Could not retrieve catalog from remote server: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed warning: Not using cache on failed catalog err: Could not retrieve catalog; skipping run -- In this point is where i'm struck right now, i have deleted several times all certificates both hosts and i'm getting the same kind of error. And this is the ouput if i try to do it in the same server. -- puppet agent --test Warning: Unable to fetch my node definition, but the agent run will continue: Warning: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=puppetmaster.domain.name] Info: Retrieving plugin Error: /File[/var/lib/puppet/lib]: Failed to generate additional resources using 'eval_generate: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=puppetmaster.domain.name] Error: /File[/var/lib/puppet/lib]: Could not evaluate: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=puppetmaster.domain.name] Could not retrieve file metadata for puppet://puppetmaster.domain.name/plugins: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=puppetmaster.domain.name] Error: Could not retrieve catalog from remote server: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=puppetmaster.domain.name] Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run Error: Could not send report: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=puppetmaster.domain.name] Thanks -- -- This email is sent on behalf of Northgate Information Solutions Limited and its associated companies (Northgate) and is strictly confidential and intended solely for the addressee(s). If you are not the intended recipient of this email you must: (i) not disclose, copy or distribute its contents to any other person nor use its contents in any way or you may be acting unlawfully; (ii) contact Northgate immediately on +44 (0)1442 232424 quoting the name of the sender and the addressee then delete it from your system. Northgate has taken reasonable precautions to ensure that no viruses are contained in this email, but does not accept any responsibility once this email has been transmitted. You should scan attachments (if any) for viruses. -- -- 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
[Puppet Users] Re: .erb templates are not properly parsed.
Dear John,
I tryed as you suggested but I think I'm doing something wrong.
I can also see this line is same:
$service_modules = hiera_array('service_modules')
It is correct?
Where do I define array of modules? where you write service_modules?
Regards.
manifests/site.pp:
node somenode {
$service_modules = hiera_array('service_modules')
include $service_modules
include firewall
}
modules/firewall/manifests/init.pp
class firewall {
$service_modules = hiera_array('service_modules')
# other classes
file { 'firewall-rules-filename':
# other properties
content = template('config.erb')
}
}
modules/firewall/templates/config.erb
% if @service_modules.include?('apache2') -%
# config-for-apache2
% end -%
% if @service_modules.include?('bind9') -%
# config-for-bind9
% end -%
% if @service_modules.include?('ssh') -%
# config-for-ssh
% end -%
El viernes, 15 de febrero de 2013 16:09:38 UTC+1, jcbollinger escribió:
On Friday, February 15, 2013 4:18:20 AM UTC-6, Marc Bolós wrote:
Dear John,
Thanks for your response.
Since I have a large environment setup I was trying to automatize all
setups from puppet, being as much simple as I can.
For example, let's think that I have a puppet server and more than 1000
puppet nodes. So I edit nodes.pp and I declare server1 and I assign it an
apache2 module, a bind9 module and an ssh module.
Once this is working I try and create a shorewall firewall erb template
for its rules file, so that it can automatically detect which modules are
declared on the host, and write the relevant lines in the rules file to
open the appropriate ports depending on that. In this example, the erb
template for shorewall rules would be something like:
# This file is centrally mantained by puppet, built from a template
located at #
# Path to file #
% if classes.include?('apache') -%
HTTP(ACCEPT)net$FW
% end -%
% if classes.include?('bind') -%
DNS/ACCEPT net $FW
% end -%
% if classes.include?('ssh') -%
SSH/ACCEPT net:someips $FW
% end -%
But this does not work for me. Could you provide me another clean and
smart way of achieving that? (Our goal would be not having to declare the
whole bunch of servers more than once, even in the nodes.pp file or in any
other place).
El jueves, 14 de febrero de 2013 17:35:50 UTC+1, Marc Bolós escribió:
Dear,
I've been using puppet for some time now. Usually when I have a problem
I read all documentation refered to the problem I have.
Recently I was trying to write a puppet erb template, that checks if
host has one class defined, and if it has then writes some text to cron.
After a lot of googleing, I found that the best way to do this was:
% if classes.include?( 'class1' ) -%
Some text
% end -%
And this worked.
But when I try on the same erb file to look for other classes, then it
only processes 1:
% if classes.include?( 'class1' ) -%
Some text
% end -%
% if classes.include?( 'class2' ) -%
Blah Blah Blah
% end -%
I can find only Some text inside file. But this host has class2 also
declared. If I remove if classes.include of class1, and leave alone class2
text, then I can see the text of class2.
Did anyone had this issue before?
Thanks for your time.
There are basically two good ways to approach this:
1. Have your service modules (apache2, bind9, ssh) each export an
appropriate fragment of the FW configuration (using fragment resource
types
provided by the Puppet::Concat add-in module), or
2. use the same data or logic by which you chose to include those
modules on a given node in the first place to drive which sections are
included in the FW config file.
If there are nodes on which you do not configure a firewall, then as a
variation on option (1), you can declare the fragments as virtual
resources, to be realized only on those nodes with FW.
There are a lot of ways you could do (2), but one might be
manifests/site.pp:
node somenode {
$service_modules = hiera_array('service_modules')
include $service_modules
include firewall
}
modules/firewall/manifests/init.pp
class firewall {
$service_modules = hiera_array('service_modules')
# other classes
file { 'firewall-rules-filename':
# other properties
content = template('config.erb')
}
}
modules/firewall/templates/config.erb
% if @service_modules.include?('apache2') -%
# config-for-apache2
% end -%
% if @service_modules.include?('bind9') -%
# config-for-bind9
% end -%
% if @service_modules.include?('ssh') -%
# config-for-ssh
% end -%
Yes, that template looks a lot like your original. The key difference is
the data source on which it is drawing: not a list of classes that
Re: [Puppet Users] shared header across multiple defined types via concat
On Fri, Feb 15, 2013 at 10:12 AM, Felix Frank
felix.fr...@alumni.tu-berlin.de wrote:
Hi,
it's paramount that you generate a unique $name for each invocation of
your defined type, e.g.
pam::header { limits-$name: }
You can take advantage of the fact that the calling defines have
unique names of their own.
Right, that was my dump mistake. It still doesn't take away from the
fact that the header will be added multiple times.
HTH,
Felix
On 02/15/2013 03:31 PM, Darin Perusich wrote:
I believe what you want is another defined type that represents the
header snippet for a specific pam config file and declares a
concat::fragment $name-header or somesuch. Each of the other defined
types then contains an instance of this new type, probably not passing
more than the name.
I've tried this approach and the problem you run into is when defining
multiple pam::limits you create a duplicate declaration caused by
pam::header being called for each instance. It attempts to create
multiple headers.
--
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] shared header across multiple defined types via concat
Ah, now I see where you're coming from. Turns out the virtual resource is a good idea then after all. To make this work, I believe you have to - not declare the virtual resource in the central class - do declare one virtual header snippet per defined type - realize the header snippet in the same defined type - not try and override any of its parameters Of course, the specific header snippets can still not share the same name. I hope that doesn't pose a problem. HTH, Felix On 02/15/2013 05:53 PM, Darin Perusich wrote: Right, that was my dump mistake. It still doesn't take away from the fact that the header will be added multiple times. -- 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] Trying to install a specific version of Java on Redhat
On 02/15/2013 05:39 PM, Sean LeBlanc wrote:
I should have added to my post that I've tried adding that 1: as well
to the ensure line with the same results.
Any other ideas?
Have you run that catalog with the --debug flag? It would be interesting
to see just what the provider is trying to do and how it fails.
I've tried this workaround:
exec { upgrade java:
command = yum -d 1 -e 1 upgrade
java-1.6.0-sun-1:1.6.0.39-1jpp.4.el5_9.x86_64
java-1.6.0-sun-devel-1:1.6.0.39-1jpp.4.el5_9.x86_64 -y,
path= /usr/bin/
}
...but it then runs every single time the puppet agent runs:
This can work, but you should then define a condition such as
unless = rpm -q java-sun-1.6.0-sun | grep -q 39-1jpp
It's a pretty gross workaround though ;-) I'd be interested to learn why
the provider won't manage to do what you want.
Cheers,
Felix
--
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: PuppetDB API permissions
Thanks Ken. It get your point and it totally makes sense. On 15 February 2013 15:36, Ken Barber k...@puppetlabs.com wrote: My biggest concern is that nodes can access other nodes resources stored in PuppetDB, which effectively means that parameters like passwords and other sensitive information is exposed. If the data is not exported this shouldn't be the case ordinarily. It actually is the case. For example a file resource does not have to be exported for its content to be stored in puppetdb. Yup agreed ... which is what I was trying to say here, probably not very clearly though: Obviously though if your content is uncontrolled it is possible for someone to use a function from the puppet master to query data (FYI - functions run on the puppetmaster, not the agents). I think just a simple separation would be sufficient. So that nodes by default wouldn't be able to access data from other environments. I would also be nice to be able easily query PuppetDB API by environment, something like: /v2/environment/nodes or /v2/nodes?environment=environment. So in this case for true separation the puppet master would need to declare to the PuppetDB what environment it is constrained too. Interesting problem, as confining PuppetDB access down to a certificate would then not be enough to constrain this for security purposes, as we don't hand out per environment Puppet master certificates :-). Today, the way to do it would be - separate puppet master (each with their own certificate) and separate PuppetDB instance, with whitelists only allowing the master on a particular environment to talk to a PuppetDB on the same environment. This may or not be desirable ... but there are other levels of security separation that might deem this necessary beyond PuppetDB. Hiera data is an example of other data one would want to separate (especially hiera-gpg stored data). That is, if one truly wanted to keep environments separate for security reasons - running completely separate hosts/clusters for each environment for this would provide better guarantees to that end, not just at an application level. With each environment maintaining its own CA, master, puppetdb and hiera sources etc. ken. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- Vaidas Jablonskis -- 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] Require with Templates
Hello,
What's the problem with this syntax:
package { 'redhat-lsb':
ensure = present,
before = File['/etc/yum.repos.d/rpmforge.repo'],
}
file { '/etc/yum.repos.d/rpmforge.repo':
mode = 644,
owner = root,
content = template(base/rpmforge.repo.erb),
require = Package[redhat-lsb],
}
The before and require its not working, 'Cause I still getting this
message:
Could not retrieve catalog from remote server: Error 400 on SERVER: Failed
to parse template base/rpmforge.repo.erb: Could not find value for
'lsbmajdistrelease' at
4:/etc/puppet/modules/base/templates/rpmforge.repo.erb at
/etc/puppet/modules/base/manifests/repository.pp:23
I'm using lsbmajdistrelease to discover the verstion of CentOS, but I've
noticed that some hosts has broken, because the package redhat-lsb is
missing. If I install the package with yum, everything works well, but I
would like to solve this with puppet.
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] Trying to install a specific version of Java on Redhat
On Friday, February 15, 2013 10:39:10 AM UTC-6, Sean LeBlanc wrote: I should have added to my post that I've tried adding that 1: as well to the ensure line with the same results. Curiouser and curiouser. The 1: is an epoch number, as you probably recognize. I was a bit surprised that Puppet would require you to include it, but very surprised to find out that it fails even if you do. I do think it likely that the epoch number is what's tripping up Puppet, but that doesn't make it any less a bug. I recommend you file a ticket. Until that's fixed, your best available solution is probably to use 'latest', and to control the package version by controlling the contents of the repositories that your clients rely upon. To the extent that that implies keeping local (pseudo-)mirrors of the repositories you use, that's worth your while anyway. 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] Errors when running 'puppet agent --test' command
Hello, First of all I am new to the Puppet technology. I am trying to get my puppet agent (windows) to reach my puppet master (Linux) server. In this tutorial: http://docs.puppetlabs.com/learning/agent_master_basic.html It claims to test your puppet agent you need to use the 'puppet agent --test' command. My result when I tried this is: C:\Program Files (x86)\Puppet Labs\Puppet Enterprise\binpuppet agent --test info: Retrieving plugin err: /File[C:/ProgramData/PuppetLabs/puppet/var/lib]: Failed to generate additio nal resources using 'eval_generate: Error 500 on SERVER: h1Passenger error #2 /h1 An error occurred while trying to access '/var/opt/lib/pe-puppetmaster/config.ru ': Cannot stat '/var/opt/lib/pe-puppetmaster/config.ru': Permission denied (13) pApache doesn't have read permissions to that file. Please fix the relevant fil e permissions./p err: /File[C:/ProgramData/PuppetLabs/puppet/var/lib]: Could not evaluate: Error 500 on SERVER: h1Passenger error #2/h1 An error occurred while trying to access '/var/opt/lib/pe-puppetmaster/config.ru ': Cannot stat '/var/opt/lib/pe-puppetmaster/config.ru': Permission denied (13) pApache doesn't have read permissions to that file. Please fix the relevant fil e permissions./p Could not retrieve file metadata for puppet://puppet.corp.loc al/plugins: Error 500 on SERVER: h1Passenger error #2/h1 An error occurred while trying to access '/var/opt/lib/pe-puppetmaster/config.ru ': Cannot stat '/var/opt/lib/pe-puppetmaster/config.ru': Permission denied (13) pApache doesn't have read permissions to that file. Please fix the relevant fil e permissions./p info: Loading facts in C:/ProgramData/PuppetLabs/puppet/var/lib/facter/concat_ba sedir.rb info: Loading facts in C:/ProgramData/PuppetLabs/puppet/var/lib/facter/custom_au th_conf.rb info: Loading facts in C:/ProgramData/PuppetLabs/puppet/var/lib/facter/facter_do t_d.rb info: Loading facts in C:/ProgramData/PuppetLabs/puppet/var/lib/facter/pe_versio n.rb info: Loading facts in C:/ProgramData/PuppetLabs/puppet/var/lib/facter/puppet_va rdir.rb info: Loading facts in C:/ProgramData/PuppetLabs/puppet/var/lib/facter/root_home .rb err: Could not retrieve catalog from remote server: Error 500 on SERVER: h1Pas senger error #2/h1 An error occurred while trying to access '/var/opt/lib/pe-puppetmaster/config.ru ': Cannot stat '/var/opt/lib/pe-puppetmaster/config.ru': Permission denied (13) pApache doesn't have read permissions to that file. Please fix the relevant fil e permissions./p warning: Not using cache on failed catalog err: Could not retrieve catalog; skipping run err: Could not send report: Error 500 on SERVER: h1Passenger error #2/h1 An error occurred while trying to access '/var/opt/lib/pe-puppetmaster/config.ru ': Cannot stat '/var/opt/lib/pe-puppetmaster/config.ru': Permission denied (13) pApache doesn't have read permissions to that file. Please fix the relevant fil e permissions./p Does anyone have any idea of what is wrong and what I need to do to be able to connect my agent to the master? Thanks, Eban Bisong -- 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] Require with Templates
Hello Nan, So this is the problem: I think that puppet must fail on the fist attempt, but install the package to be sucess on the second try. But not, it always failing: Feb 15 16:37:49 alog228 puppet-agent[18960]: Starting Puppet client version 2.7.9 Feb 15 16:37:57 alog228 puppet-agent[18960]: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to parse template base/rpmforge.repo.erb: Could not find value for 'lsbmajdistrelease' at 4:/etc/puppet/modules/base/templates/rpmforge.repo.erb at /etc/puppet/modules/base/manifests/repository.pp:23 on node alog228 Feb 15 16:37:57 alog228 puppet-agent[18960]: Using cached catalog Feb 15 16:37:57 alog228 puppet-agent[18960]: Could not retrieve catalog; skipping run Feb 15 17:08:00 alog228 puppet-agent[18960]: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to parse template base/rpmforge.repo.erb: Could not find value for 'lsbmajdistrelease' at 4:/etc/puppet/modules/base/templates/rpmforge.repo.erb at /etc/puppet/modules/base/manifests/repository.pp:23 on node alog228 Feb 15 17:08:00 alog228 puppet-agent[18960]: Using cached catalog Feb 15 17:08:00 alog228 puppet-agent[18960]: Could not retrieve catalog; skipping run Feb 15 17:27:05 alog228 puppet-agent[18960]: Caught TERM; calling stop Feb 15 17:27:06 alog228 puppet-agent[21508]: Reopening log files Feb 15 17:27:06 alog228 puppet-agent[21508]: Starting Puppet client version 2.7.9 Feb 15 17:27:08 alog228 puppet-agent[21508]: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to parse template base/rpmforge.repo.erb: Could not find value for 'lsbmajdistrelease' at 4:/etc/puppet/modules/base/templates/rpmforge.repo.erb at /etc/puppet/modules/base/manifests/repository.pp:23 on node alog228 I saw your module, sounds really nice! Did you know if it works with puppet 2.7.9? Thanks!! Em sexta-feira, 15 de fevereiro de 2013 17h11min14s UTC-2, Nan Liu escreveu: You can't update fact information during a puppet run. Puppet either have or don't have lsb facts when applying the catalog, installing the package to satisfy the dependency won't help that particular puppet run (only the next one). I also find redhat-lsb package to be hideously large dependency for answering such a basic fact. Here's one possible work around (as long you don't need lsbrelease): https://forge.puppetlabs.com/nanliu/lsb -- 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: Errors when running 'puppet agent --test' command
err: Could not retrieve catalog from remote server: Error 500 on SERVER: Passenger error #2 An error occurred while trying to access '/var/opt/lib/pe-puppetmaster/ config.ru': Cannot stat '/var/opt/lib/pe-puppetmaster/config.ru': Permission denied (13)Apache doesn't have read permissions to that file. Please fix the relevant file permissions. Seems... fairly straightforward, no? On Friday, February 15, 2013 11:13:36 AM UTC-8, Eban Bisong wrote: Hello, First of all I am new to the Puppet technology. I am trying to get my puppet agent (windows) to reach my puppet master (Linux) server. In this tutorial: http://docs.puppetlabs.com/learning/agent_master_basic.html It claims to test your puppet agent you need to use the 'puppet agent --test' command. My result when I tried this is: C:\Program Files (x86)\Puppet Labs\Puppet Enterprise\binpuppet agent --test info: Retrieving plugin err: /File[C:/ProgramData/PuppetLabs/puppet/var/lib]: Failed to generate additio nal resources using 'eval_generate: Error 500 on SERVER: h1Passenger error #2 /h1 An error occurred while trying to access '/var/opt/lib/pe-puppetmaster/ config.ru ': Cannot stat '/var/opt/lib/pe-puppetmaster/config.ru': Permission denied (13) pApache doesn't have read permissions to that file. Please fix the relevant fil e permissions./p err: /File[C:/ProgramData/PuppetLabs/puppet/var/lib]: Could not evaluate: Error 500 on SERVER: h1Passenger error #2/h1 An error occurred while trying to access '/var/opt/lib/pe-puppetmaster/ config.ru ': Cannot stat '/var/opt/lib/pe-puppetmaster/config.ru': Permission denied (13) pApache doesn't have read permissions to that file. Please fix the relevant fil e permissions./p Could not retrieve file metadata for puppet://puppet.corp.loc al/plugins: Error 500 on SERVER: h1Passenger error #2/h1 An error occurred while trying to access '/var/opt/lib/pe-puppetmaster/ config.ru ': Cannot stat '/var/opt/lib/pe-puppetmaster/config.ru': Permission denied (13) pApache doesn't have read permissions to that file. Please fix the relevant fil e permissions./p info: Loading facts in C:/ProgramData/PuppetLabs/puppet/var/lib/facter/concat_ba sedir.rb info: Loading facts in C:/ProgramData/PuppetLabs/puppet/var/lib/facter/custom_au th_conf.rb info: Loading facts in C:/ProgramData/PuppetLabs/puppet/var/lib/facter/facter_do t_d.rb info: Loading facts in C:/ProgramData/PuppetLabs/puppet/var/lib/facter/pe_versio n.rb info: Loading facts in C:/ProgramData/PuppetLabs/puppet/var/lib/facter/puppet_va rdir.rb info: Loading facts in C:/ProgramData/PuppetLabs/puppet/var/lib/facter/root_home .rb err: Could not retrieve catalog from remote server: Error 500 on SERVER: h1Pas senger error #2/h1 An error occurred while trying to access '/var/opt/lib/pe-puppetmaster/ config.ru ': Cannot stat '/var/opt/lib/pe-puppetmaster/config.ru': Permission denied (13) pApache doesn't have read permissions to that file. Please fix the relevant fil e permissions./p warning: Not using cache on failed catalog err: Could not retrieve catalog; skipping run err: Could not send report: Error 500 on SERVER: h1Passenger error #2/h1 An error occurred while trying to access '/var/opt/lib/pe-puppetmaster/ config.ru ': Cannot stat '/var/opt/lib/pe-puppetmaster/config.ru': Permission denied (13) pApache doesn't have read permissions to that file. Please fix the relevant fil e permissions./p Does anyone have any idea of what is wrong and what I need to do to be able to connect my agent to the master? Thanks, Eban Bisong -- 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] Puppet from the scratch
Have you verified that the time on the servers is consistent? On Fri, Feb 15, 2013 at 5:01 AM, F.Calero hipo...@gmail.com wrote: Hi all, I'm trying to start with it from the scratch and i'm getting struck at this point: puppetclient01:~ # cat /etc/SuSE-release SUSE Linux Enterprise Server 11 (x86_64) VERSION = 11 PATCHLEVEL = 2 puppetclient01:~ # cat /etc/hosts 127.0.0.1 puppetclient01.user.arinso puppetclient01 192.168.203.128 puppet puppetmaster.user.arinso puppetclient01:~ # puppet agent --test info: Creating a new SSL key for puppetclient01.domain.name warning: peer certificate won't be verified in this SSL session warning: peer certificate won't be verified in this SSL session info: Creating a new SSL certificate request for puppetclient01.domain.name info: Certificate Request fingerprint (md5): 88:B5:17:BF:DD:39:90:ED:0D:1A:9D:3C:A7:51:8C:D3 warning: peer certificate won't be verified in this SSL session warning: peer certificate won't be verified in this SSL session warning: peer certificate won't be verified in this SSL session Exiting; no certificate found and waitforcert is disabled Once i sign the new node certificate on the puppetmaster. puppetclient01:~ # puppet agent --test warning: peer certificate won't be verified in this SSL session info: Caching certificate for puppetclient01.domain.name err: Could not retrieve catalog from remote server: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed warning: Not using cache on failed catalog err: Could not retrieve catalog; skipping run I have tried to delete all certificates on the server and client, it didn’t solve any. 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. -- 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: Puppet agent daemon not seeing a Facter fact
On Friday, February 15, 2013 9:56:09 AM UTC-6, Eugene Brodsky wrote: Hi all, first post here... reposting this from Stack Overflow as it didn't get much traction there... I am using puppet to read a fact from facter, and based on that I apply a different configuration to my modules. Problem: the puppet agent isn't seeing this fact. Running puppet agent --test interactively works as expected. Even running it non-interactively from a script seems to work fine. Only the agent *daemon* is screwing up. You seem to be assuming that the daemon will have the environment of a login shell, and that when it runs Facter it will provide its own full environment to the child process. Neither of those is a safe assumption. There are several ways to reliably provide custom facts to Puppet. The customary way is to write a bona fide Facter pluginand distribute it via Puppet's automatic pluginsync mechanism, and that's what I would recommend. If you want something simpler, however, then you might want to check out this plugin: https://github.com/ripienaar/facter-facts/tree/master/facts-dot-d. 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] bug #1238 fixed?
http://projects.puppetlabs.com/issues/1238 I was doing some random noodling this afternoon, and this bug seems to have stopped biting me, both with apply and with a master. Strange thing is, the ticket isn't closed and there's no mention of it in the roadmap. Can anyone else confirm that this is now working? -- 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] Trying to install a specific version of Java on Redhat
On Feb 15, 2013, at 1:45 PM, jcbollinger john.bollin...@stjude.org wrote:
Curiouser and curiouser. The 1: is an epoch number, as you probably
recognize. I was a bit surprised that Puppet would require you to include
it, but very surprised to find out that it fails even if you do. I do think
it likely that the epoch number is what's tripping up Puppet, but that
doesn't make it any less a bug. I recommend you file a ticket.
Check the epoch of the two packages. The epoch overrides all other version
comparison logic. If they have the same epoch, RPM considers them to be the
same version. I had that problem with the Oracle JDK RPMs. They all have the
epoch set to 2000, so it's impossible to either upgrade or install both
versions concurrently. I think rpm -qip package will show it, but if not
you can do rpm -qp --queryformat='%{EPOCH}\n' package.
--
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] Require with Templates
On Fri, Feb 15, 2013 at 11:30 AM, Tiago Cruz tiago.tuxkil...@gmail.comwrote: Hello Nan, So this is the problem: I think that puppet must fail on the fist attempt, but install the package to be sucess on the second try. But not, it always failing: Feb 15 16:37:49 alog228 puppet-agent[18960]: Starting Puppet client version 2.7.9 Feb 15 16:37:57 alog228 puppet-agent[18960]: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to parse template base/rpmforge.repo.erb: Could not find value for 'lsbmajdistrelease' at 4:/etc/puppet/modules/base/templates/rpmforge.repo.erb at /etc/puppet/modules/base/manifests/repository.pp:23 on node alog228 Feb 15 16:37:57 alog228 puppet-agent[18960]: Using cached catalog Feb 15 16:37:57 alog228 puppet-agent[18960]: Could not retrieve catalog; skipping run Feb 15 17:08:00 alog228 puppet-agent[18960]: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to parse template base/rpmforge.repo.erb: Could not find value for 'lsbmajdistrelease' at 4:/etc/puppet/modules/base/templates/rpmforge.repo.erb at /etc/puppet/modules/base/manifests/repository.pp:23 on node alog228 Feb 15 17:08:00 alog228 puppet-agent[18960]: Using cached catalog Feb 15 17:08:00 alog228 puppet-agent[18960]: Could not retrieve catalog; skipping run Feb 15 17:27:05 alog228 puppet-agent[18960]: Caught TERM; calling stop Feb 15 17:27:06 alog228 puppet-agent[21508]: Reopening log files Feb 15 17:27:06 alog228 puppet-agent[21508]: Starting Puppet client version 2.7.9 Feb 15 17:27:08 alog228 puppet-agent[21508]: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to parse template base/rpmforge.repo.erb: Could not find value for 'lsbmajdistrelease' at 4:/etc/puppet/modules/base/templates/rpmforge.repo.erb at /etc/puppet/modules/base/manifests/repository.pp:23 on node alog228 Two different manifests (in two different environments) need to exist, one to install the facter dependency, the second for the template. Putting them in the same deployment will always result in a catalog compilation error since the master doesn't have the required fact, and the client will not receive a catalog to install the package to fulfill the fact. I saw your module, sounds really nice! Did you know if it works with puppet 2.7.9? It should, facts are usually not sensitive to Puppet version. Thanks, 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: roles, profiles, and hiera
On Friday, February 15, 2013 6:37:10 AM UTC-8, jcbollinger wrote:
On Thursday, February 14, 2013 1:45:36 PM UTC-6, Chad Huneycutt wrote:
Thanks, John. I think you are right that puppet should support it,
but I am pretty sure it does not. I chatted with RI, and it seems
that the classname is not exposed, so when the puppet backend does
the lookup, it figures out the classname and sets the 'calling_class'
variable before it interprets the hierarchy. I am going to try to
hack the same thing into the yaml backend, as well as file a bug (or
+1 one) about it.
Yes, R.I. was explaining the current state of the code, as is also
summarized in the PL bug tracker. In addition to issue 14985, which we
discussed above, there is http://projects.puppetlabs.com/issues/16730,
which speaks directly to how %{calling_class} and %{calling_module} could
be used in hiera.yaml in Puppet 2.7, whereas Puppet 3 apparently regressed
on that. That issue has been marked as a duplicate of 14985, however; I
mention it to give you confidence about which issue to watch / vote up
(14985). Also to confirm that PL not only agrees that there's an issue,
but has a solution in flight.
This is very good to hear. A few of weeks ago I was told about the
calling_* vars in #puppet IRC when I was looking to solve basically the
same sort of task.
then when I tried to use them this past weekend and it didn't work, I
asked in #puppet again if there was an issue, and folks acted like I was
crazy for thinking calling_{class,module} were supposed to work.
Looking forward to having the issue resolved.
--
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.
