Re: [Puppet Users] Re: How do I cd (change directory) with Puppet's exec?
Hi, On Thu, 5 Jul 2012 22:33:00 -0700 (PDT) Benjamin Lei benlei1...@gmail.com wrote: Specifically, when I have cd in command = .. it says it cannot find the command cd. Because it is a builtin command in the shell. Either let a shell execute your command or use the pwd (or cwd?) parameter. Best regards Hendrik Jäger signature.asc Description: PGP signature
[Puppet Users] Puppet not refreshing its session (from Vagrant maybe)?
So I have added a config in Puppet to replace my OS's old Ruby version with a newer one. Unfortunately, it seems that if I run vagrant provision again (which essentially does a puppet apply), Vagrant (or Puppet) reuses the same ssh session or bash shell or whatever it is. As such, for my configurations at least, Puppet keeps on trying to re-install the newer Ruby. How do I make it so that if I do vagrant provision it creates a new ssh session or bash shell (or whatever it is)? Because at the first run, Puppet will have completely and correctly installed the newer Ruby, and if I run puppet apply or vagrant provision, it should not rerun the install for the new Ruby. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/nXDyqXCq4CwJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Puppet not refreshing its session (from Vagrant maybe)?
This is also a big problem because I want to also install Rails and the default Ruby version on the OS won't allow me to install that gem... as such once thew newer version of Ruby is installed and Puppet tries to install Rails, it still complains about Rails requiring a higher Ruby version (=1.8.7). On Friday, July 6, 2012 12:26:06 AM UTC-7, Benjamin Lei wrote: So I have added a config in Puppet to replace my OS's old Ruby version with a newer one. Unfortunately, it seems that if I run vagrant provision again (which essentially does a puppet apply), Vagrant (or Puppet) reuses the same ssh session or bash shell or whatever it is. As such, for my configurations at least, Puppet keeps on trying to re-install the newer Ruby. How do I make it so that if I do vagrant provision it creates a new ssh session or bash shell (or whatever it is)? Because at the first run, Puppet will have completely and correctly installed the newer Ruby, and if I run puppet apply or vagrant provision, it should not rerun the install for the new Ruby. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/oog82o5hx0kJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] How to use thin_storeconfigs
Which is the right way to use thin_storeconfigs? Currently I'm about to try this: storeconfigs = true thin_storeconfigs = true Or should it be only a single line containing the 'thin_storeconfigs' directive without 'storeconfigs=true'? Thanks Bernd -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] sslv3 alert handshake failure
I have a problem on 3 out of ~40 servers that gives the following error: err: Could not request certificate: SSL_connect returned=1 errno=0 state=unknown state: sslv3 alert handshake failure From previous posts, I made sure that SSLVerifyClient is set to optional. I also cleared /var/lib/puppet/ssl/ client side, not that it should make any difference as this error is on the first run of Puppet. When I try to run Puppet from either of these 3 servers, there is nothing noted in /var/log/apache2/* server side. I have confirmed networking is ok with telnet and also checked that there is traffic with tcpdump. Puppet server is at 2.7.11 and client is also at 2.7.11 both from Ubuntu repositories. Any help would be appreciated to find why these 3 particular servers is giving me problems. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/mzcj4gN-AWQJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] sslv3 alert handshake failure
Hi, - check time on client and server - check ruby version on the 3 server which fail - check SSLDir configuration in /etc/puppet/puppet.conf on the 3 systems. Martin On 06.07.2012, at 09:57, Martinus wrote: I have a problem on 3 out of ~40 servers that gives the following error: err: Could not request certificate: SSL_connect returned=1 errno=0 state=unknown state: sslv3 alert handshake failure From previous posts, I made sure that SSLVerifyClient is set to optional. I also cleared /var/lib/puppet/ssl/ client side, not that it should make any difference as this error is on the first run of Puppet. When I try to run Puppet from either of these 3 servers, there is nothing noted in /var/log/apache2/* server side. I have confirmed networking is ok with telnet and also checked that there is traffic with tcpdump. Puppet server is at 2.7.11 and client is also at 2.7.11 both from Ubuntu repositories. Any help would be appreciated to find why these 3 particular servers is giving me problems. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/mzcj4gN-AWQJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] sslv3 alert handshake failure
Martin, Right. Time is good (NTP) on all 3 clients and server. And I double checked just now with ntpq -p (largest offset was -20). There are different time zones, but then so has the working systems different time zones. Ruby version on all 3 clients and server: ruby 1.8.7 (2011-06-30 patchlevel 352) The SSLDir line looks like this: ssldir = /var/lib/puppet/ssl on all systems (config file is copied across systems). I checked, and the standard set of directories are there and owned by Puppet. However, crl.pem is not present like on the working systems. Martinus. On Friday, 6 July 2012 09:07:46 UTC+1, Martin Alfke wrote: Hi, - check time on client and server - check ruby version on the 3 server which fail - check SSLDir configuration in /etc/puppet/puppet.conf on the 3 systems. Martin On 06.07.2012, at 09:57, Martinus wrote: I have a problem on 3 out of ~40 servers that gives the following error: err: Could not request certificate: SSL_connect returned=1 errno=0 state=unknown state: sslv3 alert handshake failure From previous posts, I made sure that SSLVerifyClient is set to optional. I also cleared /var/lib/puppet/ssl/ client side, not that it should make any difference as this error is on the first run of Puppet. When I try to run Puppet from either of these 3 servers, there is nothing noted in /var/log/apache2/* server side. I have confirmed networking is ok with telnet and also checked that there is traffic with tcpdump. Puppet server is at 2.7.11 and client is also at 2.7.11 both from Ubuntu repositories. Any help would be appreciated to find why these 3 particular servers is giving me problems. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/mzcj4gN-AWQJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/ksgzsaL9g1MJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] sslv3 alert handshake failure
On puppet master: puppet cert --clean fqdn on client: rm -fr /var/lib/puppet/ssl/* puppet agent --test check on master for signing request: puppet cert --list On 06.07.2012, at 10:25, Martinus wrote: Martin, Right. Time is good (NTP) on all 3 clients and server. And I double checked just now with ntpq -p (largest offset was -20). There are different time zones, but then so has the working systems different time zones. Ruby version on all 3 clients and server: ruby 1.8.7 (2011-06-30 patchlevel 352) The SSLDir line looks like this: ssldir = /var/lib/puppet/ssl on all systems (config file is copied across systems). I checked, and the standard set of directories are there and owned by Puppet. However, crl.pem is not present like on the working systems. Martinus. On Friday, 6 July 2012 09:07:46 UTC+1, Martin Alfke wrote: Hi, - check time on client and server - check ruby version on the 3 server which fail - check SSLDir configuration in /etc/puppet/puppet.conf on the 3 systems. Martin On 06.07.2012, at 09:57, Martinus wrote: I have a problem on 3 out of ~40 servers that gives the following error: err: Could not request certificate: SSL_connect returned=1 errno=0 state=unknown state: sslv3 alert handshake failure From previous posts, I made sure that SSLVerifyClient is set to optional. I also cleared /var/lib/puppet/ssl/ client side, not that it should make any difference as this error is on the first run of Puppet. When I try to run Puppet from either of these 3 servers, there is nothing noted in /var/log/apache2/* server side. I have confirmed networking is ok with telnet and also checked that there is traffic with tcpdump. Puppet server is at 2.7.11 and client is also at 2.7.11 both from Ubuntu repositories. Any help would be appreciated to find why these 3 particular servers is giving me problems. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/mzcj4gN-AWQJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/ksgzsaL9g1MJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] sslv3 alert handshake failure
There is nothing to clean, as puppet cert --list or puppet cert --list --all does not have an entry for those 3 particular servers. Deleting the client side ssl* makes no difference either. The client will recreate the ssl (good) and the same error pops up, without anything showing up on the master (puppet cert --list). And that is why I thought there is a communication problem. But here is the tcpdump output to show that they are talking: 09:01:57.812646 IP my_client.46516 my_server.8140: Flags [S], seq 1288389639, win 14600, options [mss 1460,sackOK,TS val 1052151283 ecr 0,nop,wscale 4], length 0 09:01:57.812700 IP my_server.8140 my_client.46516: Flags [S.], seq 300735116, ack 1288389640, win 14480, options [mss 1460,sackOK,TS val 38287565 ecr 1052151283,nop,wscale 4], length 0 09:01:57.814298 IP my_client.46516 my_server.8140: Flags [.], ack 1, win 913, options [nop,nop,TS val 1052151283 ecr 38287565], length 0 09:01:57.814686 IP my_client.46516 my_server.8140: Flags [P.], seq 1:175, ack 1, win 913, options [nop,nop,TS val 1052151283 ecr 38287565], length 174 09:01:57.814715 IP my_server.8140 my_client.46516: Flags [.], ack 175, win 972, options [nop,nop,TS val 38287566 ecr 1052151283], length 0 09:01:57.815226 IP my_server.8140 my_client.46516: Flags [P.], seq 1:8, ack 175, win 972, options [nop,nop,TS val 38287566 ecr 1052151283], length 7 09:01:57.815378 IP my_server.8140 my_client.46516: Flags [F.], seq 8, ack 175, win 972, options [nop,nop,TS val 38287566 ecr 1052151283], length 0 09:01:57.816686 IP my_client.46516 my_server.8140: Flags [.], ack 8, win 913, options [nop,nop,TS val 1052151284 ecr 38287566], length 0 09:01:57.816884 IP my_client.46516 my_server.8140: Flags [F.], seq 175, ack 9, win 913, options [nop,nop,TS val 1052151284 ecr 38287566], length 0 09:01:57.816894 IP my_server.8140 my_client.46516: Flags [.], ack 176, win 972, options [nop,nop,TS val 38287566 ecr 1052151284], length 0 As an additional note, when I stop apache and start puppetmaster with its inbuilt web server, then these 3 clients are happy. Martinus. On Friday, 6 July 2012 09:46:38 UTC+1, Martin Alfke wrote: On puppet master: puppet cert --clean fqdn on client: rm -fr /var/lib/puppet/ssl/* puppet agent --test check on master for signing request: puppet cert --list On 06.07.2012, at 10:25, Martinus wrote: Martin, Right. Time is good (NTP) on all 3 clients and server. And I double checked just now with ntpq -p (largest offset was -20). There are different time zones, but then so has the working systems different time zones. Ruby version on all 3 clients and server: ruby 1.8.7 (2011-06-30 patchlevel 352) The SSLDir line looks like this: ssldir = /var/lib/puppet/ssl on all systems (config file is copied across systems). I checked, and the standard set of directories are there and owned by Puppet. However, crl.pem is not present like on the working systems. Martinus. On Friday, 6 July 2012 09:07:46 UTC+1, Martin Alfke wrote: Hi, - check time on client and server - check ruby version on the 3 server which fail - check SSLDir configuration in /etc/puppet/puppet.conf on the 3 systems. Martin On 06.07.2012, at 09:57, Martinus wrote: I have a problem on 3 out of ~40 servers that gives the following error: err: Could not request certificate: SSL_connect returned=1 errno=0 state=unknown state: sslv3 alert handshake failure From previous posts, I made sure that SSLVerifyClient is set to optional. I also cleared /var/lib/puppet/ssl/ client side, not that it should make any difference as this error is on the first run of Puppet. When I try to run Puppet from either of these 3 servers, there is nothing noted in /var/log/apache2/* server side. I have confirmed networking is ok with telnet and also checked that there is traffic with tcpdump. Puppet server is at 2.7.11 and client is also at 2.7.11 both from Ubuntu repositories. Any help would be appreciated to find why these 3 particular servers is giving me problems. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/mzcj4gN-AWQJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/ksgzsaL9g1MJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] sslv3 alert handshake failure
On 06.07.2012, at 11:09, Martinus wrote: There is nothing to clean, as puppet cert --list or puppet cert --list --all does not have an entry for those 3 particular servers. Deleting the client side ssl* makes no difference either. The client will recreate the ssl (good) and the same error pops up, without anything showing up on the master (puppet cert --list). And that is why I thought there is a communication problem. But here is the tcpdump output to show that they are talking: 09:01:57.812646 IP my_client.46516 my_server.8140: Flags [S], seq 1288389639, win 14600, options [mss 1460,sackOK,TS val 1052151283 ecr 0,nop,wscale 4], length 0 09:01:57.812700 IP my_server.8140 my_client.46516: Flags [S.], seq 300735116, ack 1288389640, win 14480, options [mss 1460,sackOK,TS val 38287565 ecr 1052151283,nop,wscale 4], length 0 09:01:57.814298 IP my_client.46516 my_server.8140: Flags [.], ack 1, win 913, options [nop,nop,TS val 1052151283 ecr 38287565], length 0 09:01:57.814686 IP my_client.46516 my_server.8140: Flags [P.], seq 1:175, ack 1, win 913, options [nop,nop,TS val 1052151283 ecr 38287565], length 174 09:01:57.814715 IP my_server.8140 my_client.46516: Flags [.], ack 175, win 972, options [nop,nop,TS val 38287566 ecr 1052151283], length 0 09:01:57.815226 IP my_server.8140 my_client.46516: Flags [P.], seq 1:8, ack 175, win 972, options [nop,nop,TS val 38287566 ecr 1052151283], length 7 09:01:57.815378 IP my_server.8140 my_client.46516: Flags [F.], seq 8, ack 175, win 972, options [nop,nop,TS val 38287566 ecr 1052151283], length 0 09:01:57.816686 IP my_client.46516 my_server.8140: Flags [.], ack 8, win 913, options [nop,nop,TS val 1052151284 ecr 38287566], length 0 09:01:57.816884 IP my_client.46516 my_server.8140: Flags [F.], seq 175, ack 9, win 913, options [nop,nop,TS val 1052151284 ecr 38287566], length 0 09:01:57.816894 IP my_server.8140 my_client.46516: Flags [.], ack 176, win 972, options [nop,nop,TS val 38287566 ecr 1052151284], length 0 As an additional note, when I stop apache and start puppetmaster with its inbuilt web server, then these 3 clients are happy. Are the client working after you have enabled them using webrick puppetmaster? We are working with nginx and passenger and we needed the following in puppet configuration [master]: ssl_client_header = HTTP_X_CLIENT_DN ssl_client_verify_header = HTTP_X_CLIENT_VERIFY Martinus. On Friday, 6 July 2012 09:46:38 UTC+1, Martin Alfke wrote: On puppet master: puppet cert --clean fqdn on client: rm -fr /var/lib/puppet/ssl/* puppet agent --test check on master for signing request: puppet cert --list On 06.07.2012, at 10:25, Martinus wrote: Martin, Right. Time is good (NTP) on all 3 clients and server. And I double checked just now with ntpq -p (largest offset was -20). There are different time zones, but then so has the working systems different time zones. Ruby version on all 3 clients and server: ruby 1.8.7 (2011-06-30 patchlevel 352) The SSLDir line looks like this: ssldir = /var/lib/puppet/ssl on all systems (config file is copied across systems). I checked, and the standard set of directories are there and owned by Puppet. However, crl.pem is not present like on the working systems. Martinus. On Friday, 6 July 2012 09:07:46 UTC+1, Martin Alfke wrote: Hi, - check time on client and server - check ruby version on the 3 server which fail - check SSLDir configuration in /etc/puppet/puppet.conf on the 3 systems. Martin On 06.07.2012, at 09:57, Martinus wrote: I have a problem on 3 out of ~40 servers that gives the following error: err: Could not request certificate: SSL_connect returned=1 errno=0 state=unknown state: sslv3 alert handshake failure From previous posts, I made sure that SSLVerifyClient is set to optional. I also cleared /var/lib/puppet/ssl/ client side, not that it should make any difference as this error is on the first run of Puppet. When I try to run Puppet from either of these 3 servers, there is nothing noted in /var/log/apache2/* server side. I have confirmed networking is ok with telnet and also checked that there is traffic with tcpdump. Puppet server is at 2.7.11 and client is also at 2.7.11 both from Ubuntu repositories. Any help would be appreciated to find why these 3 particular servers is giving me problems. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/mzcj4gN-AWQJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups
Re: [Puppet Users] sslv3 alert handshake failure
Martin, No, the clients fail again with exactly the same error once I switch apache back on. Your configuration is slightly different than what I have: ssl_client_header = SSL_CLIENT_S_DN ssl_client_verify_header = SSL_CLIENT_VERIFY Now lets see what happens if I use your example ... Nope, those changes makes no difference. Martinus. On Friday, 6 July 2012 10:19:10 UTC+1, Martin Alfke wrote: On 06.07.2012, at 11:09, Martinus wrote: There is nothing to clean, as puppet cert --list or puppet cert --list --all does not have an entry for those 3 particular servers. Deleting the client side ssl* makes no difference either. The client will recreate the ssl (good) and the same error pops up, without anything showing up on the master (puppet cert --list). And that is why I thought there is a communication problem. But here is the tcpdump output to show that they are talking: 09:01:57.812646 IP my_client.46516 my_server.8140: Flags [S], seq 1288389639, win 14600, options [mss 1460,sackOK,TS val 1052151283 ecr 0,nop,wscale 4], length 0 09:01:57.812700 IP my_server.8140 my_client.46516: Flags [S.], seq 300735116, ack 1288389640, win 14480, options [mss 1460,sackOK,TS val 38287565 ecr 1052151283,nop,wscale 4], length 0 09:01:57.814298 IP my_client.46516 my_server.8140: Flags [.], ack 1, win 913, options [nop,nop,TS val 1052151283 ecr 38287565], length 0 09:01:57.814686 IP my_client.46516 my_server.8140: Flags [P.], seq 1:175, ack 1, win 913, options [nop,nop,TS val 1052151283 ecr 38287565], length 174 09:01:57.814715 IP my_server.8140 my_client.46516: Flags [.], ack 175, win 972, options [nop,nop,TS val 38287566 ecr 1052151283], length 0 09:01:57.815226 IP my_server.8140 my_client.46516: Flags [P.], seq 1:8, ack 175, win 972, options [nop,nop,TS val 38287566 ecr 1052151283], length 7 09:01:57.815378 IP my_server.8140 my_client.46516: Flags [F.], seq 8, ack 175, win 972, options [nop,nop,TS val 38287566 ecr 1052151283], length 0 09:01:57.816686 IP my_client.46516 my_server.8140: Flags [.], ack 8, win 913, options [nop,nop,TS val 1052151284 ecr 38287566], length 0 09:01:57.816884 IP my_client.46516 my_server.8140: Flags [F.], seq 175, ack 9, win 913, options [nop,nop,TS val 1052151284 ecr 38287566], length 0 09:01:57.816894 IP my_server.8140 my_client.46516: Flags [.], ack 176, win 972, options [nop,nop,TS val 38287566 ecr 1052151284], length 0 As an additional note, when I stop apache and start puppetmaster with its inbuilt web server, then these 3 clients are happy. Are the client working after you have enabled them using webrick puppetmaster? We are working with nginx and passenger and we needed the following in puppet configuration [master]: ssl_client_header = HTTP_X_CLIENT_DN ssl_client_verify_header = HTTP_X_CLIENT_VERIFY Martinus. On Friday, 6 July 2012 09:46:38 UTC+1, Martin Alfke wrote: On puppet master: puppet cert --clean fqdn on client: rm -fr /var/lib/puppet/ssl/* puppet agent --test check on master for signing request: puppet cert --list On 06.07.2012, at 10:25, Martinus wrote: Martin, Right. Time is good (NTP) on all 3 clients and server. And I double checked just now with ntpq -p (largest offset was -20). There are different time zones, but then so has the working systems different time zones. Ruby version on all 3 clients and server: ruby 1.8.7 (2011-06-30 patchlevel 352) The SSLDir line looks like this: ssldir = /var/lib/puppet/ssl on all systems (config file is copied across systems). I checked, and the standard set of directories are there and owned by Puppet. However, crl.pem is not present like on the working systems. Martinus. On Friday, 6 July 2012 09:07:46 UTC+1, Martin Alfke wrote: Hi, - check time on client and server - check ruby version on the 3 server which fail - check SSLDir configuration in /etc/puppet/puppet.conf on the 3 systems. Martin On 06.07.2012, at 09:57, Martinus wrote: I have a problem on 3 out of ~40 servers that gives the following error: err: Could not request certificate: SSL_connect returned=1 errno=0 state=unknown state: sslv3 alert handshake failure From previous posts, I made sure that SSLVerifyClient is set to optional. I also cleared /var/lib/puppet/ssl/ client side, not that it should make any difference as this error is on the first run of Puppet. When I try to run Puppet from either of these 3 servers, there is nothing noted in /var/log/apache2/* server side. I have confirmed networking is ok with telnet and also checked that there is traffic with tcpdump. Puppet server is at 2.7.11 and client is also at 2.7.11 both from Ubuntu repositories. Any help would be appreciated to find why these 3 particular servers is giving me problems. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit
Re: [Puppet Users] How to use thin_storeconfigs
On Fri, 2012-07-06 at 09:43 +0200, Bernd Adamowicz wrote: Which is the right way to use thin_storeconfigs? Currently I'm about to try this: storeconfigs = true thin_storeconfigs = true Or should it be only a single line containing the 'thin_storeconfigs' directive without 'storeconfigs=true'? You just need: thin_storeconfigs = true It will automatically enable storeconfigs for you. -- Brice Figureau Follow the latest Puppet Community evolutions on www.planetpuppet.org! -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] sslv3 alert handshake failure
As an additional note, when I stop apache and start puppetmaster with its inbuilt web server, then these 3 clients are happy. Ah, that triggered a memory! http://projects.puppetlabs.com/projects/1/wiki/Using_Passenger has an example Apache config stanza for the puppetmaster virtualhost. In it are the following couple of lines: # CRL checking should be enabled; if you have problems with Apache complaining about the CRL, disable the next line SSLCARevocationFile /var/lib/puppet/ssl/ca/ca_crl.pem I know it won't help understanding *why* your 3 nodes are misbehaving, but it may help workaround it. Regards, Matt. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] sslv3 alert handshake failure
Martin, Everything is worth a try ! But it did not work :( I commented out that line (SSLCARevocationFile) and restarted apache. No change on the working servers, good. No change on the broken servers, bad. Martinus. On Friday, 6 July 2012 11:02:10 UTC+1, Matthew Burgess wrote: As an additional note, when I stop apache and start puppetmaster with its inbuilt web server, then these 3 clients are happy. Ah, that triggered a memory! http://projects.puppetlabs.com/projects/1/wiki/Using_Passenger has an example Apache config stanza for the puppetmaster virtualhost. In it are the following couple of lines: # CRL checking should be enabled; if you have problems with Apache complaining about the CRL, disable the next line SSLCARevocationFile /var/lib/puppet/ssl/ca/ca_crl.pem I know it won't help understanding *why* your 3 nodes are misbehaving, but it may help workaround it. Regards, Matt. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/SJL2yF2M0xoJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] sslv3 alert handshake failure
It would also help if I call people by their right name, sorry Matt :) On Friday, 6 July 2012 11:02:10 UTC+1, Matthew Burgess wrote: As an additional note, when I stop apache and start puppetmaster with its inbuilt web server, then these 3 clients are happy. Ah, that triggered a memory! http://projects.puppetlabs.com/projects/1/wiki/Using_Passenger has an example Apache config stanza for the puppetmaster virtualhost. In it are the following couple of lines: # CRL checking should be enabled; if you have problems with Apache complaining about the CRL, disable the next line SSLCARevocationFile /var/lib/puppet/ssl/ca/ca_crl.pem I know it won't help understanding *why* your 3 nodes are misbehaving, but it may help workaround it. Regards, Matt. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/h4fXywnOnzkJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Multiple execs within a class
On Jul 6, 2012, at 12:53 AM, Mike Reed mjohn.r...@gmail.com wrote:
Hello all,
I'm looking to run multiple commands via exec within a single class like so:
class boost_install {
# This will place the gzip locally in /tmp. File is pulled from
puppet.
file { /tmp/boost_1_41_0.tar.bz2 :
source = puppet:///boost_install/boost_1_41_0.tar.bz2 ,
ensure = present ,
}
# This will extract the boost gzip to the /tmp directory.
# This will untar only if the /tmp/boost_1_41_0 directory does not
exist.
exec { tar -xjvf /tmp/boost_1_41_0.tar.bz2 :
cwd = /tmp/ ,
creates = /tmp/boost_1_41_0 ,
path= [/bin , /usr/sbin] ,
}
# This will run the boost bootstrapper. bjam should be run after this.
# This will only run if the ls command returns a 1.
# The unless will have to be redone because we have no way of
upgrading easily and this is sloppy.
exec{ /tmp/boost_1_41_0/bootstrap.sh :
unless = 'ls /usr/local/include/boost' ,
path= [/bin/ , /sbin/ , /usr/bin/ , /usr/sbin/] ,
}
# This will run the boost bjam modifier and should run only after the
bootstrap.sh has been run
# This will only run if the ls command returns a 1.
# This unless will have to be redone because we have no way of
upgrading easily and this is sloppy.
exec { /tmp/boost_1_41_0/bjam cxxflags=-fPIC install :
unless = 'ls /usr/local/include/boost' ,
path= [/bin/ , /sbin/ , /usr/bin/ , /usr/sbin/]
,
}
}
However, after running the above class, I get the following:
err: /Stage[main]/Boost_install/Exec[/tmp/boost_1_41_0/bootstrap.sh]/returns:
change from notrun to 0 failed: /tmp/boost_1_41_0/bootstrap.sh returned 1
instead of one of [0] at
/etc/puppet/modules/boost_install/manifests/init.pp:18
err: /Stage[main]/Boost_install/Exec[/tmp/boost_1_41_0/bjam cxxflags=-fPIC
install]/returns: change from notrun to 0 failed: /tmp/boost_1_41_0/bjam
cxxflags=-fPIC install returned 1 instead of one of [0] at
/etc/puppet/modules/boost_install/manifests/init.pp:21
notice: Finished catalog run in 1.31 seconds
I was under the impression that I should be getting the install returned 1
output but it's usually silent and the command doesn't run. I'm assuming
that neither the bootstrap or bjam commands should run as the
/usr/local/include/boost directories exist on the machine and I'm expecting
the ls to return a 0; which it does on the machine because those
directories exist.
I'm obviously missing something here and I'm looking for some direction.
I do suspect that this can be done in a more elegant fashion especially since
the bjam command is dependent upon the bootstrap.sh script running but I was
hoping to at least get this working.
Thanks in advance for the thoughts.
Puppet manifests do not run in a top-down manner, but instead run
semi-randomly. Because your file and exec resources need to run in a specific
order, you need to define that order specifically. You can accomplish this by
keeping the order you have and simply adding a 'require' parameter to each that
points to the previous resource.
Even better would be to convert the entire thing into a single package/rpm that
you keep in a repository and have puppet install it with a single 'package'
resource.
--
Peter Bukowinski
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Automated deployement with puppet
Hi Pete, Thanks for your reply, i thought it demand another resource type, i'll manage it with the file resource Thanks for your help, Le vendredi 6 juillet 2012 01:14:30 UTC+2, Pete a écrit : Hi Mouhcine, I find that if you can script it you can manage it with puppet and I haven't run into much I don't manage with puppet. I haven't used puppet to manage a Tomcat instance (you will likely find something on http://forge.puppetlabs.com/ for doing that though) but if you are deploying a jar file to a specific directory that's very easy with puppet using the file resource. Have you had a look through the introductory docs? If not start here http://docs.puppetlabs.com/puppet/ That explains all the basics and should get you going pretty quickly. Good luck and enjoy. Pete On 6 July 2012 00:59, mouhcine MOULOU moulou.mouhc...@gmail.com wrote: Hi , I am new to Puppet and I just started testing it on my Debian OS, I was wondering if it's possible to create an artifact that allows auto-deploying jar file without using SSH SCP? I Found some threads explaining how to deploy web application on Tomcat Server, but i need to deploy a simple Jar on my platform Thanks, Mouhcine -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/J7Os3wlMbfQJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/aub4Q-HSGQAJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: is nodes.pp a default file?
On Thursday, July 5, 2012 9:57:55 PM UTC-5, Hai wrote: Hi, is nodes.pp a default file,like sites.pp, or I have to import it in puppet.conf? If you use a nodes.pp file then you have to import it manually. Typically, that takes the form of import 'nodes.pp' at the top of your main manifest (normally site.pp). That is one of very few appropriate uses of the 'import' function, in fact. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/GbiKFHImugcJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] sslv3 alert handshake failure
From http://projects.puppetlabs.com/projects/1/wiki/Certificates_And_Security Check certificate and validity: openssl x509 -text -noout -in /var/lib/puppet/ssl/certs/hostname.tld.pem How do you specifiy the puppetmaster on the clients? Do you have a server= line in puppet.conf? How do the three clients resolv the puppetmaster? Check certificate on master (take care on AltDNS Names openssl x509 -text -noout -in /etc/puppet/ssl/certs/master.example.com.pem Check ca on master: openssl x509 -text -noout -in /etc/puppet/ssl/certs/ca.pem Simulate a SSL connection: openssl s_client -host puppet -port 8140 -cert /path/to/ssl/certs/node.domain.com.pem -key /path/to/ssl/private_keys/node.domain.com.pem -CAfile /path/to/ssl/certs/ca.pem (from http://www.masterzen.fr/2010/11/14/puppet-ssl-explained/) On 06.07.2012, at 12:20, Martinus wrote: Martin, Everything is worth a try ! But it did not work :( I commented out that line (SSLCARevocationFile) and restarted apache. No change on the working servers, good. No change on the broken servers, bad. Martinus. On Friday, 6 July 2012 11:02:10 UTC+1, Matthew Burgess wrote: As an additional note, when I stop apache and start puppetmaster with its inbuilt web server, then these 3 clients are happy. Ah, that triggered a memory! http://projects.puppetlabs.com/projects/1/wiki/Using_Passenger has an example Apache config stanza for the puppetmaster virtualhost. In it are the following couple of lines: # CRL checking should be enabled; if you have problems with Apache complaining about the CRL, disable the next line SSLCARevocationFile /var/lib/puppet/ssl/ca/ca_crl.pem I know it won't help understanding *why* your 3 nodes are misbehaving, but it may help workaround it. Regards, Matt. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/SJL2yF2M0xoJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Puppet not upgrading to newer version of Ruby
I have upgraded my default Ruby (1.8.6) to a newer one (1.8.7). But whenever I run Puppet, it seems to somehow constantly run under Ruby 1.8.6. How do I fix this? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/t9EqWaO-zxAJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: How do I cd (change directory) with Puppet's exec?
On Friday, July 6, 2012 2:10:13 AM UTC-5, Hendrik Jäger wrote: [...] let a shell execute your command [...] Which you can do fairly easily by adding provider = 'sh' to your Exec's parameters. Or if you need a non-default shell or you just like doing things the hard way, then you can use a variation on bash -c 'my command here' as your command. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/bS6ih5Uij6sJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Multiple execs within a class
On Friday, July 6, 2012 6:52:01 AM UTC-5, pmbuko wrote: Puppet manifests do not run in a top-down manner, but instead run semi-randomly. Because your file and exec resources need to run in a specific order, you need to define that order specifically. You can accomplish this by keeping the order you have and simply adding a 'require' parameter to each that points to the previous resource. Right. Even better would be to convert the entire thing into a single package/rpm that you keep in a repository and have puppet install it with a single 'package' resource. +1 In fact, boost packages in particular are available pre-built for many systems, so you might not even need to build one. Packages are far better not only for convenience, but as an administrative best practice. With very few exceptions, I do not install unpackaged software on my systems. I do build a fair number of packages, however. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/b-Fcv7d_QdQJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Node not find
Hi, my new server doesn't find his node *whereas i did the same for my
others servers and it works on them*. My key is generated and signed by my
master (i had had to add my puppetmaster in /etc/hosts).
My node :
*node 'vpsX.ovh.net' {
*
*
*
*}*
*
*
It's save in vpsX.ovh.net.pp in puppet/manifests/nodes and in my
site.pp i include nodes/* .
When i use : puppet agent --test, i got this error :
*err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Could not find default node or by name with 'vpsX.ovh.net,
vpsX.ovh, vpsX' on node vpsX.ovh.net*
*warning: Not using cache on failed catalog*
*err: Could not retrieve catalog; skipping run*
*
*
Any help would be appreciated :)*
*
*
*
*
*
*
*
*
*
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/i3QJSF8PFlUJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Have puppet store updated facts in couchdb without updating configuration
We have a test puppet environment where we use couchDB as a facts terminus. We are thinking of using facter+couch as our new inventory system and would like to be able to pull inventory without having to resolve puppet configurations on our servers (we have very strict change management procedures) Is it possible to run puppet in an inventory mode and only update facts? I appears that using --noop does not update the data in couchDB. Thanks! -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/hw8eWzV-HCYJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Node not find
On Fri, Jul 6, 2012 at 4:22 AM, pierre-emmanuel degand
pierreemmanuel.deg...@gmail.com wrote:
Hi, my new server doesn't find his node *whereas i did the same for my
others servers and it works on them*. My key is generated and signed by
my master (i had had to add my puppetmaster in /etc/hosts).
My node :
*node 'vpsX.ovh.net' {
*
*
*
*}*
*
*
It's save in vpsX.ovh.net.pp in puppet/manifests/nodes and in my
site.pp i include
did you mean import?
nodes/* .
When i use : puppet agent --test, i got this error :
*err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Could not find default node or by name with 'vpsX.ovh.net,
vpsX.ovh, vpsX' on node vpsX.ovh.net*
*warning: Not using cache on failed catalog*
*err: Could not retrieve catalog; skipping run*
*
*
Any help would be appreciated :)*
*
*
*
*
*
*
*
*
*
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/i3QJSF8PFlUJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Intermittent problem with compiling catalog on puppet 2.7.17
Hi all, Ran into a weird problem today. Puppet's been working in a non-daemonized environment for several weeks now without issue. We regularly run puppet with the --onetime flag to update our environment. This is running on Centos 6.2. Catalogs have been compiling in 1 - 5 seconds generally, and today, it's intermittently taking anywhere from 100 seconds to timing out. I've attempted to delete the yaml files and to restart the puppet master process. Restarting the process works for a few minutes, and then the timeouts begin again. Here's an example: Jul 6 11:52:58 admin2 puppet-master[5420]: Starting Puppet master version 2.7.17 Jul 6 11:53:13 admin2 puppet-master[5420]: Compiled catalog for queue2.prod.keek.com in environment production in 1.12 seconds Jul 6 11:57:45 admin2 puppet-master[5420]: Compiled catalog for queue2.prod.keek.com in environment production in 214.36 seconds Jul 6 12:01:37 admin2 puppet-master[5420]: Caught TERM; calling stop Jul 6 12:01:41 admin2 puppet-master[5536]: Reopening log files Jul 6 12:01:41 admin2 puppet-master[5536]: Starting Puppet master version 2.7.17 Jul 6 12:01:52 admin2 puppet-master[5536]: Compiled catalog for queue2.prod.keek.com in environment production in 1.08 seconds Compiling it by hand from the master always finishes quickly. This is happening across the entire environment, multiple nodes, multiple different catalogs. Help? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Have puppet store updated facts in couchdb without updating configuration
On Fri, Jul 6, 2012 at 9:01 AM, ZJE countac...@gmail.com wrote: We have a test puppet environment where we use couchDB as a facts terminus. We are thinking of using facter+couch as our new inventory system and would like to be able to pull inventory without having to resolve puppet configurations on our servers (we have very strict change management procedures) Is it possible to run puppet in an inventory mode and only update facts? I appears that using --noop does not update the data in couchDB. Have a look at facts upload. puppet help facts upload It can be run on the agents to just run facter and upload the facts to the master (using its rest terminus) Thanks! -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/hw8eWzV-HCYJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet not upgrading to newer version of Ruby
On Jul 6, 2012, at 11:01 AM, Benjamin Lei wrote: I have upgraded my default Ruby (1.8.6) to a newer one (1.8.7). But whenever I run Puppet, it seems to somehow constantly run under Ruby 1.8.6. How do I fix this? What is the output of 'which ruby' and 'which puppet'? -- Peter Bukowinski -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] puppet agent won't recognize configuration
hi all, just started using puppet and i think it's great. but i'm having a number of problems surrounding the authentication of the servers. on a fresh master, when i create a new client using the node_aws cloud provisioner (using --certname), the agent doesn't respect the generated configuration. `certname` is certainly listed under [main] in puppet.conf, so why wouldn't the agent recognize it? $ sudo puppet master --configprint certname analytics0 $ puppet master --configprint certname analytics0 $ sudo puppet agent --configprint certname analytics0 $ puppet agent --configprint certname domu-x-x-x-x-x-x.compute-1.internal $ ls -la /etc/puppet/puppet.conf -rw-r--r-- 1 root root puppet.conf this pattern also occurs with the `server` option. i've also other, unrelated but similar sudo discrepancies that i think are leading to other problems (for another post...). for instance: $ sudo puppet agent --configprint ssldir /var/lib/puppet/ssl $ puppet agent --configprint ssldir /home/ubuntu/.puppet/ssl thanks kindly! -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/ed2879tLeWEJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: puppet agent won't recognize configuration
i should add, i tried changing ownership (recursively) for /etc/puppet, to both my user, and the puppet user, to no avail. On Friday, July 6, 2012 12:35:17 PM UTC-4, catshirt wrote: hi all, just started using puppet and i think it's great. but i'm having a number of problems surrounding the authentication of the servers. on a fresh master, when i create a new client using the node_aws cloud provisioner (using --certname), the agent doesn't respect the generated configuration. `certname` is certainly listed under [main] in puppet.conf, so why wouldn't the agent recognize it? $ sudo puppet master --configprint certname analytics0 $ puppet master --configprint certname analytics0 $ sudo puppet agent --configprint certname analytics0 $ puppet agent --configprint certname domu-x-x-x-x-x-x.compute-1.internal $ ls -la /etc/puppet/puppet.conf -rw-r--r-- 1 root root puppet.conf this pattern also occurs with the `server` option. i've also other, unrelated but similar sudo discrepancies that i think are leading to other problems (for another post...). for instance: $ sudo puppet agent --configprint ssldir /var/lib/puppet/ssl $ puppet agent --configprint ssldir /home/ubuntu/.puppet/ssl thanks kindly! -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/RvmqFDQL0_AJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] can the puppet client version be older than the server's?
If I upgrade my puppet server to a new version, do I have to upgrade all the client to the same version? -- Hai Tao -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: puppet with stored configurations mysql connection error
Hi, selinux may be preventing puppetmaster from talking to mysql, try setenforce 0 also if this works and you want to leave selinux running, it looks like there is a boolean to allow this (on RHEL at least) setenforce 1 setsebool puppetmaster_use_db on Hope this helps, Derek -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/px5BZvZNnWQJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: can the puppet client version be older than the server's?
it depends on what version you were on, and which you upgraded to. the master and agent versions don't necessarily have to match, as long as the agent is *not* a more recent version than your master. discussion: https://groups.google.com/forum/?fromgroups#!topic/puppet-users/6WVfdgsEp-0 On Friday, July 6, 2012 12:51:07 PM UTC-4, Hai wrote: If I upgrade my puppet server to a new version, do I have to upgrade all the client to the same version? -- Hai Tao -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/k78B9Kf4RsEJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: on puppet master server , puppet agent can't connect to itself
On Wednesday, 4 July 2012 13:56:10 UTC-7, Clay wrote: on my puppet master server (v 2.7.17 , both server and client version) , the puppet agent can't connect to itself. other clients connected to this puppet server are working fine. the hostname is puppet.domain.com [root@puppet /]# cat /etc/puppet/puppet.conf [main] # The Puppet log directory. # The default value is '$vardir/log'. logdir = /var/log/puppet # Where Puppet PID files are kept. # The default value is '$vardir/run'. rundir = /var/run/puppet # Where SSL certificates are kept. # The default value is '$confdir/ssl'. certname = puppet.domain.com reports = store, http ,foreman reporturl = http://puppet.domain.com:3000/reports/upload modulepath = $confdir/modules manifest = $confdir/manifests/site.pp http_proxy_host = proxy.domain.com http_proxy_port = 8080 [dev] modulepath = $confdir/env/dev/modules manifest = $confdir/env/dev/manifests/site.pp [testing] modulepath = $confdir/env/testing/modules manifest = $confdir/env/testing/manifests/site.pp [agent] # The file in which puppetd stores a list of the classes # associated with the retrieved configuratiion. Can be loaded in # the separate ``puppet`` executable using the ``--loadclasses`` # option. # The default value is '$confdir/classes.txt'. classfile = $vardir/classes.txt # Where puppetd caches the local configuration. An # extension indicating the cache format is added automatically. # The default value is '$confdir/localconfig'. localconfig = $vardir/localconfig puppet agent will get a 403 Forbidden error, anyone have any suggestion what to look ? [root@puppet ]# puppet agent --test --debug debug: Puppet::Type::User::ProviderPw: file pw does not exist debug: Puppet::Type::User::ProviderUser_role_add: file roleadd does not exist debug: Failed to load library 'ldap' for feature 'ldap' debug: Puppet::Type::User::ProviderLdap: feature ldap is missing debug: Puppet::Type::User::ProviderDirectoryservice: file /usr/bin/dscl does not exist debug: /File[/etc/puppet/ssl/certificate_requests]: Autorequiring File[/etc/puppet/ssl] debug: /File[/etc/puppet/ssl/certs/ca.pem]: Autorequiring File[/etc/puppet/ssl/certs] debug: /File[/var/lib/puppet/state/graphs]: Autorequiring File[/var/lib/puppet/state] debug: /File[/etc/puppet/ssl/certs/puppet.domain.com.pem]: Autorequiring File[/etc/puppet/ssl/certs] debug: /File[/var/lib/puppet/client_yaml]: Autorequiring File[/var/lib/puppet] debug: /File[/var/lib/puppet/clientbucket]: Autorequiring File[/var/lib/puppet] debug: /File[/var/lib/puppet/state/last_run_report.yaml]: Autorequiring File[/var/lib/puppet/state] debug: /File[/etc/puppet/ssl/private_keys/puppet.domain.com.pem]: Autorequiring File[/etc/puppet/ssl/private_keys] debug: /File[/var/lib/puppet/client_data]: Autorequiring File[/var/lib/puppet] debug: /File[/var/lib/puppet/classes.txt]: Autorequiring File[/var/lib/puppet] debug: /File[/var/lib/puppet/lib]: Autorequiring File[/var/lib/puppet] debug: /File[/etc/puppet/ssl/public_keys/puppet.domain.com.pem]: Autorequiring File[/etc/puppet/ssl/public_keys] debug: /File[/etc/puppet/ssl]: Autorequiring File[/etc/puppet] debug: /File[/etc/puppet/ssl/public_keys]: Autorequiring File[/etc/puppet/ssl] debug: /File[/etc/puppet/ssl/private_keys]: Autorequiring File[/etc/puppet/ssl] debug: /File[/var/lib/puppet/state/resources.txt]: Autorequiring File[/var/lib/puppet/state] debug: /File[/var/lib/puppet/facts]: Autorequiring File[/var/lib/puppet] debug: /File[/var/lib/puppet/state]: Autorequiring File[/var/lib/puppet] debug: /File[/etc/puppet/ssl/certs]: Autorequiring File[/etc/puppet/ssl] debug: /File[/etc/puppet/ssl/private]: Autorequiring File[/etc/puppet/ssl] debug: /File[/var/lib/puppet/state/last_run_summary.yaml]: Autorequiring File[/var/lib/puppet/state] debug: /File[/etc/puppet/ssl/crl.pem]: Autorequiring File[/etc/puppet/ssl] debug: /File[/etc/puppet/puppet.conf]: Autorequiring File[/etc/puppet] debug: /File[/var/lib/puppet/state/state.yaml]: Autorequiring File[/var/lib/puppet/state] debug: Finishing transaction 69951197233260 debug: /File[/etc/puppet/ssl/crl.pem]: Autorequiring File[/etc/puppet/ssl] debug: /File[/etc/puppet/ssl/certificate_requests]: Autorequiring File[/etc/puppet/ssl] debug: /File[/etc/puppet/ssl/certs/ca.pem]: Autorequiring File[/etc/puppet/ssl/certs] debug: /File[/etc/puppet/ssl/certs/puppet.domain.com.pem]: Autorequiring File[/etc/puppet/ssl/certs] debug: /File[/etc/puppet/ssl/certs]: Autorequiring File[/etc/puppet/ssl] debug: /File[/etc/puppet/ssl/private_keys/puppet.domain.com.pem]: Autorequiring File[/etc/puppet/ssl/private_keys] debug: /File[/var/lib/puppet/state]: Autorequiring File[/var/lib/puppet] debug: /File[/etc/puppet/ssl/private_keys]: Autorequiring
[Puppet Users] Re: on puppet master server , puppet agent can't connect to itself
I don't have to have the puppet agent on the puppet server up , but when setting up puppetdb , I got this error from clients: # puppet agent --test err: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to submit 'replace facts' command for client1.domain.com to PuppetDB at puppet.domain.com:8081: 403 Forbidden from puppetdb document , seems need to get puppet agent on puppet server working first, not sure it's it's related. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/SrY-vWsBP2UJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] install require a lower version of glibc-common
I got a strange error when I installed puppet on CentOS 6.2, that it asks for a glibc-common = 2.12-1.7.el6 while I have glibc-common-2.12-1.47.el6.x86_64 installed. why 2.12-1.47 cannot be used? Error: Package: glibc-2.12-1.7.el6.i686 (base-tn60) Requires: glibc-common = 2.12-1.7.el6 Installed: glibc-common-2.12-1.47.el6.x86_64 (@anaconda-CentOS-201112102333.x86_64/6.2) glibc-common = 2.12-1.47.el6 Available: glibc-common-2.12-1.7.el6.x86_64 (base-tn60) glibc-common = 2.12-1.7.el6 -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/Wvy542iv5vsJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] install require a lower version of glibc-common
On Fri, Jul 06, 2012 at 10:21:52AM -0700, Hai wrote: I got a strange error when I installed puppet on CentOS 6.2, that it asks for a glibc-common = 2.12-1.7.el6 while I have glibc-common-2.12-1.47.el6.x86_64 installed. why 2.12-1.47 cannot be used? Sounds like you might want to: 1) yum clean all 2) reinstall puppet by whatever method you were using If that doesn't work, try pasting the command and all the output here. Also your yum repositories. Error: Package: glibc-2.12-1.7.el6.i686 (base-tn60) Requires: glibc-common = 2.12-1.7.el6 Installed: glibc-common-2.12-1.47.el6.x86_64 (@anaconda-CentOS-201112102333.x86_64/6.2) glibc-common = 2.12-1.47.el6 Available: glibc-common-2.12-1.7.el6.x86_64 (base-tn60) glibc-common = 2.12-1.7.el6 -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit [1]https://groups.google.com/d/msg/puppet-users/-/Wvy542iv5vsJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. References Visible links 1. https://groups.google.com/d/msg/puppet-users/-/Wvy542iv5vsJ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] puppetdb listening on ipv6 port 8081 , not ipv4
trying to deploy puppetdb , puppet server is RHEL 6.1 , [root@puppet ~]# rpm -qa|grep puppet puppetdb-0.9.1-2.el6.noarch puppet-dashboard-1.2.9-1.el6.noarch puppet-server-2.7.17-1.el6.noarch puppetdb-terminus-0.9.1-2.el6.noarch puppet-2.7.17-1.el6.noarch on the clients, got an error for puppetdb , client1 :~ # puppet agent --test err: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to submit 'replace facts' command for client1.domain.com to PuppetDB at puppet.domain.com:8081: 403 Forbidden warning: Not using cache on failed catalog err: Could not retrieve catalog; skipping run on the puppet server, noticed puppetdb is listening on IPv6 not ipv4, is it normal ? [root@puppet ~]# lsof -i:8081 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME java1050 puppetdb 39u IPv6 820438 0t0 TCP puppet.domain.com:tproxy (LISTEN) tried to telnet to puppet:8081, works though. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/ertxm14svw4J. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: on puppet master server , puppet agent can't connect to itself
On Fri, Jul 6, 2012 at 11:21 AM, Clay clay...@gmail.com wrote: I don't have to have the puppet agent on the puppet server up , but when setting up puppetdb , I got this error from clients: # puppet agent --test err: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to submit 'replace facts' command for client1.domain.com to PuppetDB at puppet.domain.com:8081: 403 Forbidden from puppetdb document , seems need to get puppet agent on puppet server working first, not sure it's it's related. Indeed, PuppetDB requires that SSL is working between agent and master (at least, the default setup scripts invoked when using pre-built packages assume SSL works). The error you're seeing from PuppetDB is another, separate manifestation of what I think is the same underlying problem. It appears that your master is not trusting the certificate your agent is presenting? For a conclusive test, though, it may help to temporarily disable PuppetDB and retry. If agent/master communication works, then we know the issue is between the master node and the puppetdb node. deepak -- Deepak Giridharagopal / Puppet Labs / grim_radical -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] puppet-server-3.0.0-0.1rc3.2 with foreman-1.0.0-0.4
On Wed, Jul 4, 2012 at 6:49 PM, pdpinfo pdp...@tiscali.it wrote: Hi all, just trying a lab with newest versions: - puppet-server: 3.0.0-0.1rc3.2 - passenger: 3.0.12-1 - foreman: 1.0.0-0.4 I hit problems with foreman 1.0 not able to work with Puppet 3.0. Foreman 1.0 worked correctly with puppet-server 2.7.17-1 (fresh-installed). Upgrading the package (from foreman-devel repo) to latest version, Foreman service fails with error: ... /usr/lib/ruby/site_ruby/1.8/puppet/settings.rb:278:in `convert': Error converting value for param 'hostcert': Error converting value for param 'certdir': Error converting value for param 'ssldir': Could not find value for $confdir (Puppet::Settings::InterpolationError) Any hints ? I'm guessing puppet internals changed a bit, mind opening an issue on foreman tracker ? as a work around, you could probably change lib/foreman/default_settings/loader.rb not to use Puppet settings.. Ohad Thank you -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/qQ6yvf73SvUJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] puppet-server-3.0.0-0.1rc3.2 with foreman-1.0.0-0.4
Ohad, Without poking too deeply, the Could not find value for $confdir raises an eyebrow - possible that you are referencing a global, which will be deprecated in the next major release. You'll need to fully qualify scope: http://docs.puppetlabs.com/guides/scope_and_puppet.html This should be producing warnings in 2.7 and failing when the next major release hits. -Eric -- Eric Shamow Professional Services http://puppetlabs.com/ (c)631.871.6441 On Friday, July 6, 2012 at 3:16 PM, Ohad Levy wrote: On Wed, Jul 4, 2012 at 6:49 PM, pdpinfo pdp...@tiscali.it (mailto:pdp...@tiscali.it) wrote: Hi all, just trying a lab with newest versions: - puppet-server: 3.0.0-0.1rc3.2 - passenger: 3.0.12-1 - foreman: 1.0.0-0.4 I hit problems with foreman 1.0 not able to work with Puppet 3.0. Foreman 1.0 worked correctly with puppet-server 2.7.17-1 (fresh-installed). Upgrading the package (from foreman-devel repo) to latest version, Foreman service fails with error: ... /usr/lib/ruby/site_ruby/1.8/puppet/settings.rb:278:in `convert': Error converting value for param 'hostcert': Error converting value for param 'certdir': Error converting value for param 'ssldir': Could not find value for $confdir (Puppet::Settings::InterpolationError) Any hints ? I'm guessing puppet internals changed a bit, mind opening an issue on foreman tracker ? as a work around, you could probably change lib/foreman/default_settings/loader.rb not to use Puppet settings.. Ohad Thank you -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/qQ6yvf73SvUJ. To post to this group, send email to puppet-users@googlegroups.com (mailto:puppet-users@googlegroups.com). To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com (mailto:puppet-users%2bunsubscr...@googlegroups.com). For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com (mailto:puppet-users@googlegroups.com). To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com (mailto:puppet-users+unsubscr...@googlegroups.com). For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Certificate problems.
I'm setting up a dev / test environment using a couple of Ubuntu 12.04 VMs. I have puppet installed on one of them, and am trying to get it to sync against itself to get certain things in place to distribute with the nodes. However, I am having some issues. # puppet agent --test info: Creating a new SSL key for puppet-local-master err: Could not request certificate: getaddrinfo: Name or service not known Exiting; failed to retrieve certificate and waitforcert is disabled I've tried a few things, default hostname, random ones, but I continually have getaddrinfo related errors. What's the best way to get around this? Changes on my DNS server will not be an option for me, but can do pretty much anything else as long as it can be done locally. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/6y7qGteEzmQJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: How to get an input file to a facter ?
On Friday, July 6, 2012 1:05:47 PM UTC-5, eduardo wrote: Hi john, This data are need for check a valid users on nodes. We are pretending massive load accounts by ENC. The batch (json) is prepare by external program which, in our scenario is a normal way to create accounts. But users can create new accounts by 'hand' when they log in because they have sudo, for those new ones we want to set disable (nologin). Meanwhile there are a set of user admins (we are) which should be not disable even when they are not into batch json. They are into whitelist (admin,deploy,etc,etc) , so they should be exclude at checkout for disable accounts. That is done by the facter. As you can see it's non-normal scenario. Yes. Here's what I think you're saying: 1) Your ENC is going to feed data for a large number of users to the puppetmaster, either via a class parameter or via a global variable. 2) Your custom fact is going to report to the puppemaster some or all of the known system users, excluding all users on the whitelist 3) Some class is going to combine the data from these sources to generate User resources that manage the ENC-specified and discovered users to, among other things, disable login for the users that do not appear in the first source. I still don't see the point of relying on a client-side whitelist, though. Why do you need to filter whitelisted users from the fact value on the client side? Why can't you do it on the master instead? Do you see any problem about solution based on run stages ?. As I said before, run stages cannot overcome the problem of ensuring the whitelist is up to date on the client when facter runs. Unless you can tolerate use of an outdated file, an external client-side whitelist simply will not work. If you are using pluginsync (recommended) then possibly you could cook the whitelist entries directly into the custom fact code. That's ugly, but it's your best bet for ensuring that the custom fact uses an up-to-date whitelist. Overall, though, I think your plan runs very much against the Puppet grain. I have been known sometimes to admonish folks that Puppet is not a script engine, but never before have I heard a deployment plan that tried so hard to use it as one. If you continue this way then I don't think you'll be satisfied with the result. It may be worthwhile to consider other configuration management systems. From a higher perspective, if you're fighting node admins who have sufficient privilege to manage users then you have chosen a losing game. If you give *me* that much access to a box then it's mine. Do not give administrative privileges to people you do not trust. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/b8_-nyExAwoJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Multiple execs within a class
Hey Guys,
Thank you Peter and John for your continued input into this one. I
absolutely agree with both of you about building our own packages and as
I've been working with puppet and trying to configure these systems, it's
become apparent that our own internal repository would be beneficial for a
number of reasons.
With that said, I'm quite new to the 'nix world and I suspect building out
packages/repository would take a little time and probably a few days of
googl'in. So for the very immediate future, I'd like to get this working
so I can get our initial puppet build going. packages/repository are
definitely on my list tho.
I'd like to quickly mention that the impetus behind this is that I'd like
to run this against machines that we've built up without puppet and if
possible, I'd like to refrain from things like the below manifest being run
on a machine which already has boost installed, albeit manually without
puppet.
I changed the class to the following:
class boost_install {
# This will place the gzip locally in /tmp. File is pulled from
puppet.
file { /tmp/boost_1_41_0.tar.bz2 :
source = puppet:///boost_install/boost_1_41_0.tar.bz2 ,
ensure = present ,
}
# This will extract the boost gzip to the /tmp directory.
exec { untar_boost :
command = tar -xjvf /tmp/boost_1_41_0.tar.bz2 ,
cwd = /tmp/ ,
creates = /tmp/boost_1_41_0 ,
path= [/bin , /usr/sbin] ,
require = File[/tmp/boost_1_41_0.tar.bz2] ,
}
# This will run the boost bootstrapper
exec { /tmp/boost_1_41_0/bootstrap.sh :
subscribe = Exec[untar_boost] ,
}
}
From the above code, I expect a few things to happen:
1. The exec untar_boost should only fire if /tmp/boost_1_41_0.tar.bz2
is present
2. The exec /tmp/boost_1_41_0/bootstrap.sh should only fire if the untar
boost occurs, which I believe is dependent upon the file being in that
location. (I'm thinking this will work as a temporary dependency as I'm
not sure how to make a dependency for the initial file being pulled down.
In other words, I expect the file to be pulled down on every run which I
guess is something I'll have to fix later). I'm thinking if I change from
/tmp to something like /usr/src/puppet_pkgs then the files won't be deleted
upon reboot and I can use them as a temporary placeholder until I figure
out a more elegant solution to this hack that I've put together.
I'm sorry for writing the novel above and I very much appreciate your help
and support on this one.
Cheers,
Mike
On Thursday, July 5, 2012 9:53:26 PM UTC-7, Mike Reed wrote:
Hello all,
I'm looking to run multiple commands via exec within a single class like
so:
class boost_install {
# This will place the gzip locally in /tmp. File is pulled from
puppet.
file { /tmp/boost_1_41_0.tar.bz2 :
source = puppet:///boost_install/boost_1_41_0.tar.bz2 ,
ensure = present ,
}
# This will extract the boost gzip to the /tmp directory.
# This will untar only if the /tmp/boost_1_41_0 directory does not
exist.
exec { tar -xjvf /tmp/boost_1_41_0.tar.bz2 :
cwd = /tmp/ ,
creates = /tmp/boost_1_41_0 ,
path= [/bin , /usr/sbin] ,
}
# This will run the boost bootstrapper. bjam should be run after
this.
# This will only run if the ls command returns a 1.
# The unless will have to be redone because we have no way of
upgrading easily and this is sloppy.
exec{ /tmp/boost_1_41_0/bootstrap.sh :
unless = 'ls /usr/local/include/boost' ,
path= [/bin/ , /sbin/ , /usr/bin/ ,
/usr/sbin/] ,
}
# This will run the boost bjam modifier and should run only after
the bootstrap.sh has been run
# This will only run if the ls command returns a 1.
# This unless will have to be redone because we have no way of
upgrading easily and this is sloppy.
exec { /tmp/boost_1_41_0/bjam cxxflags=-fPIC install :
unless = 'ls /usr/local/include/boost' ,
path= [/bin/ , /sbin/ , /usr/bin/ ,
/usr/sbin/] ,
}
}
However, after running the above class, I get the following:
err:
/Stage[main]/Boost_install/Exec[/tmp/boost_1_41_0/bootstrap.sh]/returns:
change from notrun to 0 failed: /tmp/boost_1_41_0/bootstrap.sh returned 1
instead of one of [0] at
/etc/puppet/modules/boost_install/manifests/init.pp:18
err: /Stage[main]/Boost_install/Exec[/tmp/boost_1_41_0/bjam cxxflags=-fPIC
install]/returns: change from notrun to 0 failed: /tmp/boost_1_41_0/bjam
cxxflags=-fPIC install returned 1 instead of one of [0] at
/etc/puppet/modules/boost_install/manifests/init.pp:21
notice:
Re: [Puppet Users] puppetdb listening on ipv6 port 8081 , not ipv4
On Fri, Jul 6, 2012 at 11:48 AM, Clay clay...@gmail.com wrote: trying to deploy puppetdb , puppet server is RHEL 6.1 , [root@puppet ~]# rpm -qa|grep puppet puppetdb-0.9.1-2.el6.noarch puppet-dashboard-1.2.9-1.el6.noarch puppet-server-2.7.17-1.el6.noarch puppetdb-terminus-0.9.1-2.el6.noarch puppet-2.7.17-1.el6.noarch on the clients, got an error for puppetdb , client1 :~ # puppet agent --test err: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to submit 'replace facts' command for client1.domain.com to PuppetDB at puppet.domain.com:8081: 403 Forbidden warning: Not using cache on failed catalog err: Could not retrieve catalog; skipping run on the puppet server, noticed puppetdb is listening on IPv6 not ipv4, is it normal ? [root@puppet ~]# lsof -i:8081 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME java1050 puppetdb 39u IPv6 820438 0t0 TCP puppet.domain.com:tproxy (LISTEN) tried to telnet to puppet:8081, works though. What does your /etc/puppetdb/conf.d/jetty.ini file look like? Don't post the whole thing, as it contains keystore/truststore passwords...but what are the host and ssl-host options set to? That's how we determine what IP to bind to for HTTP and HTTPS, respectively. deepak -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] puppetdb listening on ipv6 port 8081 , not ipv4
On Fri, Jul 6, 2012 at 11:48 AM, Clay clay...@gmail.com wrote: trying to deploy puppetdb , puppet server is RHEL 6.1 , [root@puppet ~]# rpm -qa|grep puppet puppetdb-0.9.1-2.el6.noarch puppet-dashboard-1.2.9-1.el6.noarch puppet-server-2.7.17-1.el6.noarch puppetdb-terminus-0.9.1-2.el6.noarch puppet-2.7.17-1.el6.noarch on the clients, got an error for puppetdb , client1 :~ # puppet agent --test err: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to submit 'replace facts' command for client1.domain.com to PuppetDB at puppet.domain.com:8081: 403 Forbidden warning: Not using cache on failed catalog err: Could not retrieve catalog; skipping run on the puppet server, noticed puppetdb is listening on IPv6 not ipv4, is it normal ? [root@puppet ~]# lsof -i:8081 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME java1050 puppetdb 39u IPv6 820438 0t0 TCP puppet.domain.com:tproxy (LISTEN) tried to telnet to puppet:8081, works though. Actually, if the master is getting a 403 Forbidden, then it's not connectivity that's the issue; if it couldn't connect at all, you'd get a very different error message (could not connect or the like). Does your puppetdb server have an agent running on it? And does it successfully run against your master? That should verify that there's a certificate that works for SSL between master and the puppetdb server. At that point, the issue may simply be that that the puppetdb daemon isn't choosing that certificate for some reason. deepak -- Deepak Giridharagopal / Puppet Labs / grim_radical -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] puppet-server-3.0.0-0.1rc3.2 with foreman-1.0.0-0.4
This commit may also be useful in figuring out what has changed: https://github.com/puppetlabs/puppet/commit/0cea47ec90e77e81c27ffbedbd46bb5357a45d66 (it was part of this ticket: https://projects.puppetlabs.com/issues/14609) The sample config.ru for puppet under rack was updated for Telly because of something that sounds a lot like what's happening here. HTH On Fri, Jul 6, 2012 at 12:18 PM, Eric Shamow e...@puppetlabs.com wrote: Ohad, Without poking too deeply, the Could not find value for $confdir raises an eyebrow - possible that you are referencing a global, which will be deprecated in the next major release. You'll need to fully qualify scope: http://docs.puppetlabs.com/guides/scope_and_puppet.html This should be producing warnings in 2.7 and failing when the next major release hits. -Eric -- Eric Shamow Professional Services http://puppetlabs.com/ (c)631.871.6441 On Friday, July 6, 2012 at 3:16 PM, Ohad Levy wrote: On Wed, Jul 4, 2012 at 6:49 PM, pdpinfo pdp...@tiscali.it (mailto:pdp...@tiscali.it) wrote: Hi all, just trying a lab with newest versions: - puppet-server: 3.0.0-0.1rc3.2 - passenger: 3.0.12-1 - foreman: 1.0.0-0.4 I hit problems with foreman 1.0 not able to work with Puppet 3.0. Foreman 1.0 worked correctly with puppet-server 2.7.17-1 (fresh-installed). Upgrading the package (from foreman-devel repo) to latest version, Foreman service fails with error: ... /usr/lib/ruby/site_ruby/1.8/puppet/settings.rb:278:in `convert': Error converting value for param 'hostcert': Error converting value for param 'certdir': Error converting value for param 'ssldir': Could not find value for $confdir (Puppet::Settings::InterpolationError) Any hints ? I'm guessing puppet internals changed a bit, mind opening an issue on foreman tracker ? as a work around, you could probably change lib/foreman/default_settings/loader.rb not to use Puppet settings.. Ohad Thank you -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/qQ6yvf73SvUJ. To post to this group, send email to puppet-users@googlegroups.com (mailto:puppet-users@googlegroups.com). To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com (mailto:puppet-users%2bunsubscr...@googlegroups.com). For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com (mailto:puppet-users@googlegroups.com). To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com (mailto:puppet-users+unsubscr...@googlegroups.com). For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Matthaus Litteken Release Manager, Puppet Labs -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Certificate problems.
Just as an update, I found a workaround by setting certname to the IP, but I was still wondering if this is the best solution when there isn't a real hostname on the system(s)? On Friday, July 6, 2012 2:22:51 PM UTC-5, llo...@oreillyauto.com wrote: I'm setting up a dev / test environment using a couple of Ubuntu 12.04 VMs. I have puppet installed on one of them, and am trying to get it to sync against itself to get certain things in place to distribute with the nodes. However, I am having some issues. # puppet agent --test info: Creating a new SSL key for puppet-local-master err: Could not request certificate: getaddrinfo: Name or service not known Exiting; failed to retrieve certificate and waitforcert is disabled I've tried a few things, default hostname, random ones, but I continually have getaddrinfo related errors. What's the best way to get around this? Changes on my DNS server will not be an option for me, but can do pretty much anything else as long as it can be done locally. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/S2eYHih9MRQJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: How to get an input file to a facter ?
John I really appreciate all your effort to help me. You are very close to my scenario (points 1 , 2 , 3) I still don't see the point of relying on a client-side whitelist, though. Why do you need to filter whitelisted users from the fact value on the client side? Why can't you do it on the master instead? Ok, i'm going to re-check it. If you are using pluginsync (recommended) then possibly you could cook the whitelist entries directly into the custom fact code. That's ugly, but it's your best bet for ensuring that the custom fact uses an up-to-date whitelist. Well this way i'll have to change a facter whenever whitelist change. The up-to-date is not critical between cycle agent (30 min) in this case. Overall, though, I think your plan runs very much against the Puppet grain. I have been known sometimes to admonish folks that Puppet is not a script engine, but never before have I heard a deployment plan that tried so hard to use it as one. If you continue this way then I don't think you'll be satisfied with the result. It may be worthwhile to consider other configuration management systems. Agree, i'm taking note from you and from book 'Pulling Strings with Puppet' when say : Caution ➡ Puppet is probably not ideal to populate large numbers of users and groups to provide user access for nodes and applications. Puppet is best used to populate nodes with users for running applications and services, systems administration, and management. From a higher perspective, if you're fighting node admins who have sufficient privilege to manage users then you have chosen a losing game. If you give *me* that much access to a box then it's mine. Do not give administrative privileges to people you do not trust. Agree too John , but i have not choice , it's an scenario created by my employers. Thanks you. I'm going to recheck filter whitelisted. Best Regards, eduardo. On 6 jul, 15:26, jcbollinger john.bollin...@stjude.org wrote: On Friday, July 6, 2012 1:05:47 PM UTC-5, eduardo wrote: Hi john, This data are need for check a valid users on nodes. We are pretending massive load accounts by ENC. The batch (json) is prepare by external program which, in our scenario is a normal way to create accounts. But users can create new accounts by 'hand' when they log in because they have sudo, for those new ones we want to set disable (nologin). Meanwhile there are a set of user admins (we are) which should be not disable even when they are not into batch json. They are into whitelist (admin,deploy,etc,etc) , so they should be exclude at checkout for disable accounts. That is done by the facter. As you can see it's non-normal scenario. Yes. Here's what I think you're saying: 1) Your ENC is going to feed data for a large number of users to the puppetmaster, either via a class parameter or via a global variable. 2) Your custom fact is going to report to the puppemaster some or all of the known system users, excluding all users on the whitelist 3) Some class is going to combine the data from these sources to generate User resources that manage the ENC-specified and discovered users to, among other things, disable login for the users that do not appear in the first source. I still don't see the point of relying on a client-side whitelist, though. Why do you need to filter whitelisted users from the fact value on the client side? Why can't you do it on the master instead? Do you see any problem about solution based on run stages ?. As I said before, run stages cannot overcome the problem of ensuring the whitelist is up to date on the client when facter runs. Unless you can tolerate use of an outdated file, an external client-side whitelist simply will not work. If you are using pluginsync (recommended) then possibly you could cook the whitelist entries directly into the custom fact code. That's ugly, but it's your best bet for ensuring that the custom fact uses an up-to-date whitelist. Overall, though, I think your plan runs very much against the Puppet grain. I have been known sometimes to admonish folks that Puppet is not a script engine, but never before have I heard a deployment plan that tried so hard to use it as one. If you continue this way then I don't think you'll be satisfied with the result. It may be worthwhile to consider other configuration management systems. From a higher perspective, if you're fighting node admins who have sufficient privilege to manage users then you have chosen a losing game. If you give *me* that much access to a box then it's mine. Do not give administrative privileges to people you do not trust. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more
Re: [Puppet Users] Re: Multiple execs within a class
On Jul 6, 2012, at 3:26 PM, Mike Reed wrote:
Hey Guys,
Thank you Peter and John for your continued input into this one. I
absolutely agree with both of you about building our own packages and as I've
been working with puppet and trying to configure these systems, it's become
apparent that our own internal repository would be beneficial for a number of
reasons.
With that said, I'm quite new to the 'nix world and I suspect building out
packages/repository would take a little time and probably a few days of
googl'in. So for the very immediate future, I'd like to get this working so
I can get our initial puppet build going. packages/repository are definitely
on my list tho.
I get need to prioritize your to-do list, but do it sooner rather than later. :)
I'd like to quickly mention that the impetus behind this is that I'd like to
run this against machines that we've built up without puppet and if possible,
I'd like to refrain from things like the below manifest being run on a
machine which already has boost installed, albeit manually without puppet.
I changed the class to the following:
class boost_install {
# This will place the gzip locally in /tmp. File is pulled from
puppet.
file { /tmp/boost_1_41_0.tar.bz2 :
source = puppet:///boost_install/boost_1_41_0.tar.bz2 ,
ensure = present ,
}
# This will extract the boost gzip to the /tmp directory.
exec { untar_boost :
command = tar -xjvf /tmp/boost_1_41_0.tar.bz2 ,
cwd = /tmp/ ,
creates = /tmp/boost_1_41_0 ,
path= [/bin , /usr/sbin] ,
require = File[/tmp/boost_1_41_0.tar.bz2] ,
}
# This will run the boost bootstrapper
exec { /tmp/boost_1_41_0/bootstrap.sh :
subscribe = Exec[untar_boost] ,
}
}
From the above code, I expect a few things to happen:
1. The exec untar_boost should only fire if /tmp/boost_1_41_0.tar.bz2 is
present
Correct, and because of your 'creates' parameter, it won't run again on
consecutive runs.
2. The exec /tmp/boost_1_41_0/bootstrap.sh should only fire if the untar
boost occurs, which I believe is dependent upon the file being in that
location.
Correct.
(I'm thinking this will work as a temporary dependency as I'm not sure how to
make a dependency for the initial file being pulled down. In other words, I
expect the file to be pulled down on every run which I guess is something
I'll have to fix later). I'm thinking if I change from /tmp to something
like /usr/src/puppet_pkgs then the files won't be deleted upon reboot and I
can use them as a temporary placeholder until I figure out a more elegant
solution to this hack that I've put together.
The file won't be pulled down on every run unless is gets removed from /tmp.
Because you can't count on files sticking around in /tmp, I don't like to use
it as a destination for any of my file resources. Your /usr/src/puppet_pkgs
idea is a good one -- at least until you start packaging your software
deployments. I recommend putting start using fpm on your to-do list, as well:
https://github.com/jordansissel/fpm/ -- It's a huge time-saver and makes
package creation dead-simple.
--
Peter Bukowinski
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: puppetdb listening on ipv6 port 8081 , not ipv4
here's the jetty.ini . [jetty] # Hostname to list for clear-text HTTP. Default is localhost #host = localhost # Port to listen on for clear-text HTTP. port = 8080 ssl-host = puppet.domain.com ssl-port = 8081 ... -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/85KnZBtd6P8J. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Certificate problems.
quite new with puppet myself so take this for what it's worth; if you didn't configure puppet so that it points to the correct server, it will by default look for the machine named `puppet`. presumably, if you're not modifying DNS, you'll need to reconfigure your agent to connect to the correct master (itself). you can do this either in puppet.conf, or by passing the --server option to puppet agent. your error suggests it can't find the server, so it would seem strange to me that setting certname fixed it. another option besides using the master as a agent to itself, would be to version your master configuration in git, and set up a post-receive hook to re-apply the master configuration. On Friday, July 6, 2012 4:17:15 PM UTC-4, llo...@oreillyauto.com wrote: Just as an update, I found a workaround by setting certname to the IP, but I was still wondering if this is the best solution when there isn't a real hostname on the system(s)? On Friday, July 6, 2012 2:22:51 PM UTC-5, llo...@oreillyauto.com wrote: I'm setting up a dev / test environment using a couple of Ubuntu 12.04 VMs. I have puppet installed on one of them, and am trying to get it to sync against itself to get certain things in place to distribute with the nodes. However, I am having some issues. # puppet agent --test info: Creating a new SSL key for puppet-local-master err: Could not request certificate: getaddrinfo: Name or service not known Exiting; failed to retrieve certificate and waitforcert is disabled I've tried a few things, default hostname, random ones, but I continually have getaddrinfo related errors. What's the best way to get around this? Changes on my DNS server will not be an option for me, but can do pretty much anything else as long as it can be done locally. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/CM29KqHad8YJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Certificate problems.
On 06. juli 2012 22:17, llow...@oreillyauto.com wrote: Just as an update, I found a workaround by setting certname to the IP, but I was still wondering if this is the best solution when there isn't a real hostname on the system(s)? echo 192.168.1.1 puppet | sudo tee -a /etc/hosts and read http://docs.puppetlabs.com/guides/setting_up.html#configure-dns-optional best, Jan Ivar Beddari -- http://www.uib.no/personer/Jan.Ivar.Beddari -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Access denied for user 'dashboard'@'localhost' to database 'dashboard_production'
followed the instruction for installing dashboard, and created user mysql -pmy_password -e CREATE DATABASE dashboard CHARACTER SET utf8;CREATE USER 'dashboard'@'localhost' IDENTIFIED BY 'my_password'; GRANT ALL PRIVILEGES ON dashboard.* TO 'dashboard'@'localhost'; however, I keep getting access denied error: # rake RAILS_ENV=production db:migrate (in /usr/share/puppet-dashboard) rake aborted! Access denied for user 'dashboard'@'localhost' to database 'dashboard_production' (See full trace by running task with --trace) please help! -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/l7SmiRrFLFoJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Access denied for user 'dashboard'@'localhost' to database 'dashboard_production'
On Jul 6, 2012, at 5:08 PM, Hai wrote: followed the instruction for installing dashboard, and created user mysql -pmy_password -e CREATE DATABASE dashboard CHARACTER SET utf8;CREATE USER 'dashboard'@'localhost' IDENTIFIED BY 'my_password'; GRANT ALL PRIVILEGES ON dashboard.* TO 'dashboard'@'localhost'; however, I keep getting access denied error: # rake RAILS_ENV=production db:migrate (in /usr/share/puppet-dashboard) rake aborted! Access denied for user 'dashboard'@'localhost' to database 'dashboard_production' (See full trace by running task with --trace) please help! Your created a database 'dashboard'. Make sure to put that name into the 'production:' section of your [dashboad_root]/config/database.yml file. -- Peter Bukowinski -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Intermittent problem with compiling catalog on puppet 2.7.17
Hi, a few things that come to mind: - Is DNS OK? Any NFS involved on your master? kind of seems like an underlying network related issue - Do you use storedconfigs/puppetdb? If so how's the DB looking? - Are you using passenger/apache or some other web server combo? Are there tons of processes stacked up when you see slow compilation times? -=Eric On Friday, July 6, 2012 9:10:18 AM UTC-7, Stephanie Jackson wrote: Hi all, Ran into a weird problem today. Puppet's been working in a non-daemonized environment for several weeks now without issue. We regularly run puppet with the --onetime flag to update our environment. This is running on Centos 6.2. Catalogs have been compiling in 1 - 5 seconds generally, and today, it's intermittently taking anywhere from 100 seconds to timing out. I've attempted to delete the yaml files and to restart the puppet master process. Restarting the process works for a few minutes, and then the timeouts begin again. Here's an example: Jul 6 11:52:58 admin2 puppet-master[5420]: Starting Puppet master version 2.7.17 Jul 6 11:53:13 admin2 puppet-master[5420]: Compiled catalog for queue2.prod.keek.com in environment production in 1.12 seconds Jul 6 11:57:45 admin2 puppet-master[5420]: Compiled catalog for queue2.prod.keek.com in environment production in 214.36 seconds Jul 6 12:01:37 admin2 puppet-master[5420]: Caught TERM; calling stop Jul 6 12:01:41 admin2 puppet-master[5536]: Reopening log files Jul 6 12:01:41 admin2 puppet-master[5536]: Starting Puppet master version 2.7.17 Jul 6 12:01:52 admin2 puppet-master[5536]: Compiled catalog for queue2.prod.keek.com in environment production in 1.08 seconds Compiling it by hand from the master always finishes quickly. This is happening across the entire environment, multiple nodes, multiple different catalogs. Help? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/9qwMac5k1lIJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: on puppet master server , puppet agent can't connect to itself
Thanks. I already disabled puppetdb and still got the above 403 Forbidden error, also tried remove /etc/puppet/ssl and restarted puppet master, same error. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/xz7Y8mlpxZwJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet not upgrading to newer version of Ruby
By me:
/usr/local/bin/ruby
/usr/bin/puppet
By puppet:
/usr/bin/ruby
/usr/bin/puppet
Huh that's weird :/ How do I make it so that ruby installs under /usr/bin
then?
Here's what I currently do:
exec { unload-ruby:
command = wget
ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.7-p370.tar.gz
/tmp/ruby.log tar -zxf ruby-1.8.7-p370.tar.gz /tmp/ruby.log,
cwd = /tmp,
path = /bin:/usr/bin,
#require = Package[ruby],
onlyif = ruby -v | grep 1.8.6,
}
exec { config-ruby:
command = /tmp/ruby-1.8.7-p370/configure --enable-pthread
/tmp/ruby.log,
cwd = /tmp/ruby-1.8.7-p370,
path = /bin:/usr/bin,
require = Exec[unload-ruby],
onlyif = ruby -v | grep 1.8.6,
}
exec { make-ruby:
command = make /tmp/ruby.log make install /tmp/ruby.log,
cwd = /tmp/ruby-1.8.7-p370,
path = /bin:/usr/bin,
require = Exec[config-ruby],
onlyif = ruby -v | grep 1.8.6,
}
I'm guessing I need some option in one of these?
On Fri, Jul 6, 2012 at 9:27 AM, Peter Bukowinski pmb...@gmail.com wrote:
On Jul 6, 2012, at 11:01 AM, Benjamin Lei wrote:
I have upgraded my default Ruby (1.8.6) to a newer one (1.8.7). But
whenever I run Puppet, it seems to somehow constantly run under Ruby 1.8.6.
How do I fix this?
What is the output of 'which ruby' and 'which puppet'?
--
Peter Bukowinski
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: How to get an input file to a facter ?
Hi John, I build a custom function to filter whitelisted. I didn't realized that custom functions can call facter by lookupvar. Thanks you for your suggestions. Best Regards, eduardo. On 6 jul, 16:34, eduardo erodr...@gmail.com wrote: John I really appreciate all your effort to help me. You are very close to my scenario (points 1 , 2 , 3) I still don't see the point of relying on a client-side whitelist, though. Why do you need to filter whitelisted users from the fact value on the client side? Why can't you do it on the master instead? Ok, i'm going to re-check it. If you are using pluginsync (recommended) then possibly you could cook the whitelist entries directly into the custom fact code. That's ugly, but it's your best bet for ensuring that the custom fact uses an up-to-date whitelist. Well this way i'll have to change a facter whenever whitelist change. The up-to-date is not critical between cycle agent (30 min) in this case. Overall, though, I think your plan runs very much against the Puppet grain. I have been known sometimes to admonish folks that Puppet is not a script engine, but never before have I heard a deployment plan that tried so hard to use it as one. If you continue this way then I don't think you'll be satisfied with the result. It may be worthwhile to consider other configuration management systems. Agree, i'm taking note from you and from book 'Pulling Strings with Puppet' when say : Caution ➡ Puppet is probably not ideal to populate large numbers of users and groups to provide user access for nodes and applications. Puppet is best used to populate nodes with users for running applications and services, systems administration, and management. From a higher perspective, if you're fighting node admins who have sufficient privilege to manage users then you have chosen a losing game. If you give *me* that much access to a box then it's mine. Do not give administrative privileges to people you do not trust. Agree too John , but i have not choice , it's an scenario created by my employers. Thanks you. I'm going to recheck filter whitelisted. Best Regards, eduardo. On 6 jul, 15:26, jcbollinger john.bollin...@stjude.org wrote: On Friday, July 6, 2012 1:05:47 PM UTC-5, eduardo wrote: Hi john, This data are need for check a valid users on nodes. We are pretending massive load accounts by ENC. The batch (json) is prepare by external program which, in our scenario is a normal way to create accounts. But users can create new accounts by 'hand' when they log in because they have sudo, for those new ones we want to set disable (nologin). Meanwhile there are a set of user admins (we are) which should be not disable even when they are not into batch json. They are into whitelist (admin,deploy,etc,etc) , so they should be exclude at checkout for disable accounts. That is done by the facter. As you can see it's non-normal scenario. Yes. Here's what I think you're saying: 1) Your ENC is going to feed data for a large number of users to the puppetmaster, either via a class parameter or via a global variable. 2) Your custom fact is going to report to the puppemaster some or all of the known system users, excluding all users on the whitelist 3) Some class is going to combine the data from these sources to generate User resources that manage the ENC-specified and discovered users to, among other things, disable login for the users that do not appear in the first source. I still don't see the point of relying on a client-side whitelist, though. Why do you need to filter whitelisted users from the fact value on the client side? Why can't you do it on the master instead? Do you see any problem about solution based on run stages ?. As I said before, run stages cannot overcome the problem of ensuring the whitelist is up to date on the client when facter runs. Unless you can tolerate use of an outdated file, an external client-side whitelist simply will not work. If you are using pluginsync (recommended) then possibly you could cook the whitelist entries directly into the custom fact code. That's ugly, but it's your best bet for ensuring that the custom fact uses an up-to-date whitelist. Overall, though, I think your plan runs very much against the Puppet grain. I have been known sometimes to admonish folks that Puppet is not a script engine, but never before have I heard a deployment plan that tried so hard to use it as one. If you continue this way then I don't think you'll be satisfied with the result. It may be worthwhile to consider other configuration management systems. From a higher perspective, if you're fighting node admins who have sufficient privilege to manage users then you have chosen a losing game. If you give *me* that much access to a box then it's mine. Do not give
