Re: [Puppet Users] Packages on fedora19
Greetings, I'm (along with Mike + a few others) one of the Fedora package maintainers for Puppet Facter. A number of people have reported good results with the latest release of 3.1.1 in F19. Of course, PL's repos are ideal for the latest version, but the vanilla version in Fedora proper will also work as a stop-gap measure. -Sam On Thu, Jul 4, 2013 at 11:28 PM, Pete Brown rendhal...@gmail.com wrote: On 5 July 2013 02:43, Matthaus Owens matth...@puppetlabs.com wrote: Brian, Yes, there have been some changes to ruby in fedora 19. We will probably need to tweak the spec we build against before we will get a clean build on f19. There are some details here: http://fedoraproject.org/wiki/Features/Ruby_2.0.0#New_Packaging_Guidelines and http://fedoraproject.org/wiki/Packaging:Ruby Yeah that's going to ram the proverbial spanner in the works. I am happy to run up a test vm here and help out if it's needed. On Wed, Jul 3, 2013 at 4:44 PM, Brian Pitts br...@polibyte.com wrote: I tried an installation earlier today and received this error: Resolving Dependencies -- Running transaction check --- Package puppet.noarch 0:3.2.2-1.fc18 will be installed -- Processing Dependency: ruby(abi) = 1.8 for package: puppet-3.2.2-1.fc18.noarch -- Processing Dependency: ruby-rgen for package: puppet-3.2.2-1.fc18.noarch -- Running transaction check --- Package puppet.noarch 0:3.2.2-1.fc18 will be installed -- Processing Dependency: ruby(abi) = 1.8 for package: puppet-3.2.2-1.fc18.noarch --- Package ruby-rgen.noarch 0:0.6.5-1.fc18 will be installed -- Finished Dependency Resolution Error: Package: puppet-3.2.2-1.fc18.noarch (puppetlabs-products) Requires: ruby(abi) = 1.8 It looks like there's no package providing ruby(api). $ repoquery --whatprovides 'ruby(abi)' $ repoquery --provides ruby ruby = 2.0.0.247-11.fc19 ruby(runtime_executable) = 2.0.0 ruby(x86-32) = 2.0.0.247-11.fc19 ruby = 2.0.0.247-11.fc19 ruby(runtime_executable) = 2.0.0 ruby(x86-64) = 2.0.0.247-11.fc19 $ repoquery --provides ruby-libs libruby.so.2.0 ruby(release) = 2.0.0 ruby-libs = 2.0.0.247-11.fc19 ruby-libs(x86-32) = 2.0.0.247-11.fc19 libruby.so.2.0()(64bit) ruby(release) = 2.0.0 ruby-libs = 2.0.0.247-11.fc19 ruby-libs(x86-64) = 2.0.0.247-11.fc19 On 07/03/2013 06:24 PM, Pete Brown wrote: I was just wondering the same thing. My dev environment runs in Fedora 18 and I almost upgraded yesterday but thought some testing was in order first. I am likely to do what I did last time and try installing the versions from the previous release. I will be running up a Fedora 19 vm and install puppet from the Fedora 18 repo shortly and will let you know how it goes. If I can find srpms I may rebuild them and see how that goes. :) On 4 July 2013 06:04, Tony G. tony...@gmail.com wrote: Howdy! Probably this is being worked but just throwing it out there as f19 is already out, I guess the package for it will be soon available on http://yum.puppetlabs.com/fedora/ ? Thanks! -- Tony http://tonyskapunk.net -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out. -- All the best, Brian Pitts -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out. -- Matthaus Owens Release Manager, Puppet Labs Join us at PuppetConf 2013, August 22-23 in San Francisco - http://bit.ly/pupconf13 Register now and take advantage of the Early Bird discount - save 25%! -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group,
[Puppet Users] Deploying system configurations with another tool?
Hi, Let's imagine there is a daemon named foobard, which has it's configuration snippets in /etc/foobar.d/*.conf Applications are deployed via some tool other than puppet, for example Jenkins or Capistrano, and developers want to be able to also push system configs for specific deamon(s) via their deployment system. Now, this poses a problem for me, because I'm used to manage configuration files via puppet. How do you guys solve this kind of issues? Also, CM aside, there is a standing security issue. Deployment is run via unprivileged account, which now has to be able somehow inject potentially malicious configuration files into /etc. Any input is appreciated. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] How to force generation of ca_crl.pem?
I have a standard Puppet 2.7 configuration installed from Gem on Ubuntu 12.04, running behind Apache. I'm testing the reprovisioning of the puppet master from scratch in Vagrant and ran into a little snug - apache configuration points to a puppet ca_crl.pem file which doesn't exist, so apache refuses to start. Have you tried just using 'puppet cert generate mymaster_name' to populate the initial certificates? I don't have a 2.7.x around, but for 3.x it repopulates all the missing certificates it seems including ca_crl.pem. The puppet master documentation says that it'll automatically generate this file if it isn't present, but I need a way to get it generated automatically before apache tries to start. Yes, and it does - when you start it standalone using webrick (ie. puppet master --no-daemonize --debug --log console ... or something will probably do the trick). But the SSL offloading to Apache kind of breaks this as you've mentioned. ken. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] How to force generation of ca_crl.pem?
If it helps I did a bit of a Gist walkthrough of the full cert recreation etc. using puppet cert generate here: https://gist.github.com/kbarber/5934100 ... On Fri, Jul 5, 2013 at 1:00 PM, Ken Barber k...@puppetlabs.com wrote: I have a standard Puppet 2.7 configuration installed from Gem on Ubuntu 12.04, running behind Apache. I'm testing the reprovisioning of the puppet master from scratch in Vagrant and ran into a little snug - apache configuration points to a puppet ca_crl.pem file which doesn't exist, so apache refuses to start. Have you tried just using 'puppet cert generate mymaster_name' to populate the initial certificates? I don't have a 2.7.x around, but for 3.x it repopulates all the missing certificates it seems including ca_crl.pem. The puppet master documentation says that it'll automatically generate this file if it isn't present, but I need a way to get it generated automatically before apache tries to start. Yes, and it does - when you start it standalone using webrick (ie. puppet master --no-daemonize --debug --log console ... or something will probably do the trick). But the SSL offloading to Apache kind of breaks this as you've mentioned. ken. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Deploying system configurations with another tool?
On 05.07.2013 13:37, Jakov Sosic wrote: Hi, Let's imagine there is a daemon named foobard, which has it's configuration snippets in /etc/foobar.d/*.conf Applications are deployed via some tool other than puppet, for example Jenkins or Capistrano, and developers want to be able to also push system configs for specific deamon(s) via their deployment system. Now, this poses a problem for me, because I'm used to manage configuration files via puppet. How do you guys solve this kind of issues? Any input is appreciated. One of the big arguments for puppet is the unifying aspect of devs and ops to use the same tool/language/process, which improves cooperation, agility and quality of the work. This indicates that your application deployment should be integrated into your puppet manifests and those manifests should be integrated into the application development/release cycle. Another big point in puppet's favor is that it doesn't want to be the be-all-end-all. If there's a tool that is better suited to a task (the prime example being package managers) then *please* use that. This indicates that if capistrano is a good match for your organization's application deployment (especially in the area of orchestration across nodes and rollback it leaves puppet in the dust), then you should leverage those capabilities. You write this poses a problem for me, because I'm used to manage configuration files via puppet. While that may just be lost in translation, it does sound like your problem is of a much more personal and a less technical level. In that case you really need to get rid of the us-against-them attitude and find solutions that enable the organization as a whole to repeatably deliver more value faster while reducing the associated risks. Also, CM aside, there is a standing security issue. Deployment is run via unprivileged account, which now has to be able somehow inject potentially malicious configuration files into /etc. This is a non-issue as the deployment process will always be able to push the changes it needs into the system. So a subversion (no pun intended) of the deployment process will always be a death knell, independent of the used tool. So either the devs have the need and right to modify those configuration files, or they don't. If they have the need and right, then they also share the responsibility for the system. Regards, David -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Deploying system configurations with another tool?
On 07/05/2013 02:46 PM, David Schmitt wrote: One of the big arguments for puppet is the unifying aspect of devs and ops to use the same tool/language/process, which improves cooperation, agility and quality of the work. This indicates that your application deployment should be integrated into your puppet manifests and those manifests should be integrated into the application development/release cycle. But how are they integrated in your environment? What would you do in my case? Another big point in puppet's favor is that it doesn't want to be the be-all-end-all. If there's a tool that is better suited to a task (the prime example being package managers) then *please* use that. This indicates that if capistrano is a good match for your organization's application deployment (especially in the area of orchestration across nodes and rollback it leaves puppet in the dust), then you should leverage those capabilities. And that's exactly why are we using another tool for the job. You write this poses a problem for me, because I'm used to manage configuration files via puppet. While that may just be lost in translation, it does sound like your problem is of a much more personal and a less technical level. In that case you really need to get rid of the us-against-them attitude and find solutions that enable the organization as a whole to repeatably deliver more value faster while reducing the associated risks. 'you need to find solutions' is a thing I already now. If I didn't know that, I wouldn't have asked the question in the first place. On the other hand, one thing I didn't ask about was online psychotherapy... Did I offend you some how with my OP? If I did, I'm really sorry, that was not my intention. This is a non-issue as the deployment process will always be able to push the changes it needs into the system. So a subversion (no pun intended) of the deployment process will always be a death knell, independent of the used tool. So either the devs have the need and right to modify those configuration files, or they don't. If they have the need and right, then they also share the responsibility for the system. Yeah, but things have to stay pretty tight. For example: if you enable some user account to push files into dot-d directory, not-if-but-when that account gets broken into, you have a possibility of privilege escalation. So, allowing the write privilege for that directory obviously is not a good choice. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Multiple Puppet agents on one node?
Hi, Sorry to revive this old thread, but I'm trying to do the same thing and running into two minor problems.. I would like to rename the puppet command to something like puppet3. We're running two versions while we're migrating from 2.7 to 3.x However, when I try to do a symlink I get the following error. Error: Unknown Puppet subcommand 'puppet3' See 'puppet help' for help on available puppet subcommands ie puppet agent -t - everything is normal puppet3 agent -t - calls puppet3 /opt/puppet3.2/bin/puppet I do not have any problems with puppet colliding with puppet 2 but I'd like to use a shortcut vs using the /path/to/puppet3/bin/.puppet. Is there a way to do this? I looked at the command_line.rb but I hope it doesn't require too much hacking to get something like this to work. I would also want to run a daemon for the puppet3 version. Please advise. Thank you. On Thursday, February 21, 2013 2:00:24 AM UTC-8, R.I. Pienaar wrote: - Original Message - From: Michael Hüttermann mic...@huettermann.net javascript: To: puppet...@googlegroups.com javascript: Sent: Thursday, February 21, 2013 9:37:35 AM Subject: Re: [Puppet Users] Multiple Puppet agents on one node? thank you for your opinion. I've somehow lost the last post, sorry for bothering you again with the same strange question. It's easily done by just giving each agent their own libdir and config file. In fact if you just ran puppet agent as non root it would use ~/.puppet as its work dirs and it will just work. of course you're pretty limited in what you can do then - only stuff non root can do -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Updating a pkgdmg package
Hello guys, I tried to update VirtualBox on my machine using puppet but I fall in an issue with query. https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/package/pkgdmg.rb#L116 In this code its only look if the file exist and ignore the source value. So, if I update the source to a new version it doesn't update the package. Can we check for the file and the source? If this is dangerous, can we have another property to tell that this package is updatable? Regards, Felipe -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] puppet agent does nothing after upgrade from 2.7.20 to 3.2.2
Hello, I'm looking at upgrading my Puppet masters to 3.2.2. My entire environment is currently running puppet 2.7.20, and the masters are all running under Passenger. I've started by upgrading one of the masters to 3.2.2, and now I'm finding that when I run puppet agent -t on any client pointed at that server, nothing happens. Even though something should happen because I've deliberately, manually changed ownership on some files that Puppet is managing! [sysadmin@sv4-prx-t1 ~]$ sudo puppet agent -t Info: Retrieving plugin Info: Caching catalog for sv4-prx-t1.services.webroot Info: Applying configuration version '1372989755' Notice: Finished catalog run in 0.67 seconds [sysadmin@sv4-prx-t1 ~]$ sudo puppet agent -t Info: Retrieving plugin Info: Caching catalog for sv4-prx-t1.services.webroot Info: Applying configuration version '1372989777' Notice: Finished catalog run in 0.65 seconds [sysadmin@sv4-prx-t1 ~]$ sudo puppet agent -t Info: Retrieving plugin Info: Caching catalog for sv4-prx-t1.services.webroot Info: Applying configuration version '1372990557' Notice: Finished catalog run in 0.68 seconds The only thing I can see changing is that the configuration version number keeps incrementing I'm not seeing any errors in /var/log/messages on either client or master, nor errors in the Apache logs on the master. What could possibly cause this? thanks, Jim -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Puppet 3.2 and Hiera: problem of order and tagged function
Hello everybody,
I'm testing Puppet 3.2 and Hiera (installed with http://apt.puppetlabs.com)
on Debian Wheezy. Here is my /etc/puppet/manifests/site.pp file :
---
stage { one: }
stage { two: }
Stage['one'] - Stage['two']
hiera_include('classes')
---
Here is the init.pp file of my one module :
---
class one ($stage = one) {
notify {Class one is done:
message = Class one is loaded.
}
}
---
And here is the init.pp file of my two module :
---
class two ($stage = two) {
if tagged(one) {
$var = YES
}
else {
$var = NO
}
notify {Class two is done:
message = The value of var is $var.
}
}
---
If I use this yaml file for my host :
---
---
classes:
- one
- two
---
then everything is ok ($var == YES) :
---
# puppet agent --test
Info: Retrieving plugin
Info: Caching catalog for shinken.domaine.priv
Info: Applying configuration version '1373027591'
Notice: Class one is loaded.
Notice: /Stage[one]/One/Notify[Class one is done]/message: defined
'message' as 'Class one is loaded.'
Notice: The value of var is YES.
Notice: /Stage[two]/Two/Notify[Class two is done]/message: defined
'message' as 'The value of var is YES.'
Notice: Finished catalog run in 0.16 seconds
---
*But* if I use this yaml file for my host (change the order):
---
---
classes:
- two
- one
---
then $var == NO :
---
# puppet agent --test
Info: Retrieving plugin
Info: Caching catalog for shinken.domaine.priv
Info: Applying configuration version '1373027591'
Notice: Class one is loaded.
Notice: /Stage[one]/One/Notify[Class one is done]/message: defined
'message' as 'Class one is loaded.'
Notice: The value of var is NO.
Notice: /Stage[two]/Two/Notify[Class two is done]/message: defined
'message' as 'The value of var is NO.'
Notice: Finished catalog run in 0.12 seconds
---
Yet, with Stage['one'] - Stage['two'], the classed are loaded in the
good order.
1) Is it normal ?
2) I would like to have $var == YES whatever the order of classes in the
yaml file. Is it possible ?
Thanks in advance.
--
François Lafont
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Puppet 3.2 and Hiera: problem of order and tagged function
On 05.07.2013 14:53, francois.lafont.1...@gmail.com wrote:
Hello everybody,
Yet, with Stage['one'] - Stage['two'], the classed are loaded in the
good order.
1) Is it normal ?
Yes.
2) I would like to have $var == YES whatever the order of classes in
the yaml file. Is it possible ?
tagged() (and all other functions) are parse-order dependent. The stage
definition only establishes an application order. The recommended way
forward is to express the configuration dependency explicitly like so:
class meta($one = true) {
if $one {
include one
}
class { 'two': one = $one }
}
or to directly integrate this into the class two. This depends on your
actual use case.
Regards, David
--
You received this message because you are subscribed to the Google Groups Puppet
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Certificate errors
OK, I managed to solve my issue by following Reinstalling puppetDB from sourcehttp://docs.puppetlabs.com/puppetdb/latest/install_from_source.html#step-3-option-b-manually-create-a-keystore-and-truststore(Step 3 Option B) even if /usr/sbin/puppetdb-ssl-setup (option A) did state that the configuration was okay. Regards On Wednesday, July 3, 2013 5:54:49 PM UTC+2, yannig rousseau wrote: Hi all, I launched a Puppet service a few month ago and it did function pretty well for some time. Last week, I tried to clean old entries but I think I deleted too much information as I can no more synchronize my clients. I get a certificate error : *[root@REBITPUPPET01 ~]# puppet agent --test Warning: Unable to fetch my node definition, but the agent run will continue: Warning: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=rebitpuppet01.cegedim] Info: Retrieving plugin Error: /File[/var/lib/puppet/lib]: Failed to generate additional resources using 'eval_generate: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=rebitpuppet01.cegedim] Error: /File[/var/lib/puppet/lib]: Could not evaluate: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=rebitpuppet01.cegedim] Could not retrieve file metadata for puppet://rebitpuppet01.cegedim/plugins: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=rebitpuppet01.cegedim]* I tried a lot of things following the different threads but I only managed to mess a little bit more with my server :-( At least, I know my truststore should be wrong as *keytool -list -keystore /etc/puppetdb/ssl/truststore* and *openssl x509 -noout -in /var/lib/puppet/ssl/ca/ca_crt.pem -fingerprint* do not match. The only thing is that I do not have the first idea on how to solve this... Any idea ? Puppetmaster, dashboard puppedb are on the same server (Distro = RHEL5.9) I get the same error even on the puppetmaster server. Regards -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Deploying system configurations with another tool?
On 05.07.2013 15:13, Jakov Sosic wrote: On 07/05/2013 02:46 PM, David Schmitt wrote: One of the big arguments for puppet is the unifying aspect of devs and ops to use the same tool/language/process, which improves cooperation, agility and quality of the work. This indicates that your application deployment should be integrated into your puppet manifests and those manifests should be integrated into the application development/release cycle. But how are they integrated in your environment? What would you do in my case? In the environments I support everything is deployed through puppet. This leads to a big unification in dev/test environments. Through vagrant the complete stack can be tested locally before pushing to code review. From there the code travels through gerrit and jenkins until it is deployed to the puppetmaster. Did I offend you some how with my OP? If I did, I'm really sorry, that was not my intention. At no point I was offended by your words. I noticed a weakness in your explanation and frankly (even ruthlessly) addressed it. Please accept my apology for my rudeness. This is a non-issue as the deployment process will always be able to push the changes it needs into the system. So a subversion (no pun intended) of the deployment process will always be a death knell, independent of the used tool. So either the devs have the need and right to modify those configuration files, or they don't. If they have the need and right, then they also share the responsibility for the system. Yeah, but things have to stay pretty tight. For example: if you enable some user account to push files into dot-d directory, not-if-but-when that account gets broken into, you have a possibility of privilege escalation. What is the risk of having an attacker who breaks into the deployment user (which should only do deployment and nothing else), but is not able to achieve root directly? A kernel exploit would yield root. Exploiting a running daemon over the network is out, since the deployment user doesn't run daemons (use locked down sudo to trigger service restarts). One possibility would be a symlink race against one of the deployment scripts to subvert the deployed code. Without knowing your actual threat profile, I'd say that that would be pretty unusual for an attacker to custom craft such a local cross-user exploit against a locally developed script set. So, allowing the write privilege for that directory obviously is not a good choice. It's a very fine line to walk. Perhaps an API (even a little script that does syntax checks and/or auditing) might suffice. Regards, David -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Deploying system configurations with another tool?
- Original Message - | On 07/05/2013 02:46 PM, David Schmitt wrote: | | One of the big arguments for puppet is the unifying aspect of devs | and | ops to use the same tool/language/process, which improves | cooperation, | agility and quality of the work. This indicates that your | application | deployment should be integrated into your puppet manifests and | those | manifests should be integrated into the application | development/release | cycle. | | But how are they integrated in your environment? What would you do in | my | case? In my environment we choose the right tool for the job, point blank. We put as much into puppet as we can, but we understand that it isn't the be-all-end-all tool. Understanding where the lines of delineation are is an important aspect to configuration management. It does require some extra work to ensure that we're not stepping over each others toes all the time, but it also helps each group understand what each other is trying to achieve. Where we can make use of puppet instead of some other tool we decide during a meeting so everyone knows who's responsible for what. | Another big point in puppet's favor is that it doesn't want to be | the | be-all-end-all. If there's a tool that is better suited to a task | (the | prime example being package managers) then *please* use that. This | indicates that if capistrano is a good match for your | organization's | application deployment (especially in the area of orchestration | across | nodes and rollback it leaves puppet in the dust), then you should | leverage those capabilities. | | And that's exactly why are we using another tool for the job. Assuming there have been the proper discussions made this is not an issue whatsoever. In fact it's good. snip | This is a non-issue as the deployment process will always be able | to | push the changes it needs into the system. So a subversion (no pun | intended) of the deployment process will always be a death knell, | independent of the used tool. So either the devs have the need and | right | to modify those configuration files, or they don't. If they have | the | need and right, then they also share the responsibility for the | system. | | Yeah, but things have to stay pretty tight. For example: if you | enable | some user account to push files into dot-d directory, not-if-but-when | that account gets broken into, you have a possibility of privilege | escalation. | | So, allowing the write privilege for that directory obviously is not | a | good choice. Whether that push has been done via puppet or some other tool is irrelevant. If the account is compromised it's been compromised. You need to ask yourself if using puppet vs some other tool changes this fact in *ANY* way. If something is wrong, it was wrong from the time of deployment and has therefore *ALWAYS* been wrong. I don't know of any tool that can stop this. Mitigate maybe, but stop it entirely, not a chance. Just my 2c. -- James A. Peltier Manager, IT Services - Research Computing Group Simon Fraser University - Burnaby Campus Phone : 778-782-6573 Fax : 778-782-3045 E-Mail : jpelt...@sfu.ca Website : http://www.sfu.ca/itservices “A successful person is one who can lay a solid foundation from the bricks others have thrown at them.” -David Brinkley via Luke Shaw -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] how do you update packages on windows?
I use chocolatey provider, but that's because I wrote it :) Check out chocolatey on github, the provider is on the forge, and see if it meets your needs. Rismoney -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: Are multiple environments broken in puppet?
On Wednesday, July 3, 2013 11:40:15 PM UTC-7, David Schmitt wrote: On 03.07.2013 00:26, Jakov Sosic wrote: On 05/09/2013 03:33 PM, jcbollinger wrote: That exactly is the problem. Ruby does not provide a internal partitioning for namespaces. So, depending on who hits your puppetmaster first, if your ruby code is not the same across environments, one of those will load and be used for everything. I'm not sure I get it. We are using multiple environments in our setup and haven't seen issues yet. Our puppetmaster has this in the config: modulepath = /u0/puppet/$environment/modules manifestdir = /u0/puppet/$environment/manifests and so forth, for all the various bits of config. Everything has to be duplicated per environment. we store the configs in subversion, then to create a new environment you can just svn copy production to a new branch and specify it during agent runs to test new code. for example like: puppet agent --test --environment=foo --noop since everything has to be duplicated, it seems like we avoid namespace issues. There's no cross-environment dependencies. am I missing something? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] how do you update packages on windows?
It isn't perfect, but the next version of chocolatey coming out soon will have more support for puppet built in it. -- Rob Reynolds *Join us at PuppetConf 2013, August 22-23 in San Francisco - * http://bit.ly/pupconf13 On Fri, Jul 5, 2013 at 12:08 PM, Rich Siegel rismo...@gmail.com wrote: I use chocolatey provider, but that's because I wrote it :) Check out chocolatey on github, the provider is on the forge, and see if it meets your needs. Rismoney -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Puppet 3.2 and Hiera: problem of order and tagged function
Le vendredi 5 juillet 2013 17:43:47 UTC+2, David Schmitt a écrit :
2) I would like to have $var == YES whatever the order of classes in
the yaml file. Is it possible ?
tagged() (and all other functions) are parse-order dependent. The stage
definition only establishes an application order.
Ok, thank you for the distinction between parse-order and application
order, I keep that in mnd. In these conditions, I think the tagged()
function loosing interest.
The recommended way
forward is to express the configuration dependency explicitly like so:
class meta($one = true) {
if $one {
include one
}
or to directly integrate this into the class two. This depends on your
actual use case.
Sorry, but I tried to understand your example but I didn't. Do I have to
put the meta class in the yaml file of my host? If yes, I don't see why
it solves the problem. Sorry. I'm a puppet beginner.
In fact, I'll explain the purpose of my post. I have choose a simplied
example.
I have a class named monitoring (but in my example it's the two class)
in which I want to define some variables according to some other classes
are used or not by the host. I show you :
class monitoring {
# if the host uses the http class $http = http else $http = NONE
# if the host uses the mysql class $mysql = mysql else $mysql = NONE
# etc.
}
I thought tagged() function will make the job but, as you explain me, it's
order-dependent. I'll try to think about your example...
--
François Lafont
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: puppet agent does nothing after upgrade from 2.7.20 to 3.2.2
Answered my own question --- it was the change to the rack config.ru file http://docs.puppetlabs.com/puppet/3/reference/whats_new.html#puppet-master-web-server-changes On Thursday, July 4, 2013 7:25:09 PM UTC-7, jdsy...@gmail.com wrote: Hello, I'm looking at upgrading my Puppet masters to 3.2.2. My entire environment is currently running puppet 2.7.20, and the masters are all running under Passenger. I've started by upgrading one of the masters to 3.2.2, and now I'm finding that when I run puppet agent -t on any client pointed at that server, nothing happens. Even though something should happen because I've deliberately, manually changed ownership on some files that Puppet is managing! [sysadmin@sv4-prx-t1 ~]$ sudo puppet agent -t Info: Retrieving plugin Info: Caching catalog for sv4-prx-t1.services.webroot Info: Applying configuration version '1372989755' Notice: Finished catalog run in 0.67 seconds [sysadmin@sv4-prx-t1 ~]$ sudo puppet agent -t Info: Retrieving plugin Info: Caching catalog for sv4-prx-t1.services.webroot Info: Applying configuration version '1372989777' Notice: Finished catalog run in 0.65 seconds [sysadmin@sv4-prx-t1 ~]$ sudo puppet agent -t Info: Retrieving plugin Info: Caching catalog for sv4-prx-t1.services.webroot Info: Applying configuration version '1372990557' Notice: Finished catalog run in 0.68 seconds The only thing I can see changing is that the configuration version number keeps incrementing I'm not seeing any errors in /var/log/messages on either client or master, nor errors in the Apache logs on the master. What could possibly cause this? thanks, Jim -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Fwd: [Module team] Much ado about modules
Hello! Now that Puppetlabs has a module team we thought we should start trying to keep the community informed as to what we're doing and why on earth we're doing it. I wanted to put together a short update (I'm aiming to do these every friday) as to where we stand. This was our first week working full-time on Modules, and I spent a good chunk of time this week filling in paperwork, meeting people I've only seen on IRC, and trying to get up to speed with internal systems and tools. This slowed us down a little. We focused specifically on puppetlabs-mysql and puppetlabs-apt this week to try and get the PR/issue count under control. To give you an idea of the progress we've made: puppetlabs-mysql: Closed/merged 20 PRs. puppetlabs-apt: Closed/merged 18 PRs. We're going to continue iterating over different modules each week to deal with the enormous backlog of PRs and issues and keep bashing these into shape until we're caught up with all the community submissions. We appreciate each and every PR you send us (unless you forgot specs, which makes me shout at a puppy) and hopefully we'll be able to shorten the cycle of merging them as this work goes forward. As a result of this week's work we have released: http://forge.puppetlabs.com/puppetlabs/apt/1.2.0 http://forge.puppetlabs.com/puppetlabs/mysql/0.8.0 Thanks, -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Node not showing in the PE console
I have a Ubuntu 12.04 server running PE 2.8.2. I have a Fedora 18 node that I would like to manage. I installed the F18 node using a kickstart installation. During this install I enabled the puppetlabs repo and installed puppet from the puppetlabs repo. One of the post installation tasks executed the following command: puppet agent -t --server server name. Everything seemed to install ok. I did get a certificate request that I could see and Accept on the PE console. After accepting the cert, the node never shows up in the PE console. I have verified DNS and networking info multiple times and everything is in order. I am wondering if the puppet agent from the puppetlabs repo works with Puppet Enterprise. Or am I all wrong and should be using the Puppet Enterprise installer on the nodes? I would assume then the Red Hat installer would be used on a Fedora node? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Deploying system configurations with another tool?
On 07/05/2013 06:19 PM, David Schmitt wrote: In the environments I support everything is deployed through puppet. This leads to a big unification in dev/test environments. Through vagrant the complete stack can be tested locally before pushing to code review. From there the code travels through gerrit and jenkins until it is deployed to the puppetmaster. Nice one, but currently not achievable in my case :( Yeah, social problems are always thougher to surpass then the technological ones. At no point I was offended by your words. I noticed a weakness in your explanation and frankly (even ruthlessly) addressed it. Please accept my apology for my rudeness. Explanation was definitely weak, but situation is really far from 'we' vs 'them'... Both teams want the best possible solution. What is the risk of having an attacker who breaks into the deployment user (which should only do deployment and nothing else), but is not able to achieve root directly? Because one of the daemons that is supposed to be controlled this was is supervisor. And allowing unprivileged user to put stuff with no limits at all into dot-d is really only a command away from privilege escalation to root... It's a very fine line to walk. Perhaps an API (even a little script that does syntax checks and/or auditing) might suffice. One thing that did cross my mind is to allow deployment process to push specific files to specific locations on puppet master. That way, after the files are injected into master, all the deployment tool has to do afterwards is to initiate agent run on each node. What do you think about that idea? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: Are multiple environments broken in puppet?
On 2013-07-05 19:02, Brian Hicks wrote: On Wednesday, July 3, 2013 11:40:15 PM UTC-7, David Schmitt wrote: On 03.07.2013 00:26, Jakov Sosic wrote: On 05/09/2013 03:33 PM, jcbollinger wrote: That exactly is the problem. Ruby does not provide a internal partitioning for namespaces. So, depending on who hits your puppetmaster first, if your ruby code is not the same across environments, one of those will load and be used for everything. I'm not sure I get it. We are using multiple environments in our setup and haven't seen issues yet. Our puppetmaster has this in the config: modulepath = /u0/puppet/$environment/modules manifestdir = /u0/puppet/$environment/manifests and so forth, for all the various bits of config. Everything has to be duplicated per environment. we store the configs in subversion, then to create a new environment you can just svn copy production to a new branch and specify it during agent runs to test new code. for example like: puppet agent --test --environment=foo --noop since everything has to be duplicated, it seems like we avoid namespace issues. There's no cross-environment dependencies. am I missing something? This only applies to custom types and providers which do not get loaded by (the) puppet (parser) but are ruby scripts which get loaded by directly by the ruby process. Sorry if I was unclear on that point. Regards, David -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] how do you update packages on windows?
Oh, I'm sooo looking forward to that! Regards, David On 2013-07-05 19:19, Rob Reynolds wrote: It isn't perfect, but the next version of chocolatey coming out soon will have more support for puppet built in it. -- Rob Reynolds *Join us at PuppetConf 2013, August 22-23 in San Francisco - * http://bit.ly/pupconf13 On Fri, Jul 5, 2013 at 12:08 PM, Rich Siegel rismo...@gmail.com mailto:rismo...@gmail.com wrote: I use chocolatey provider, but that's because I wrote it :) Check out chocolatey on github, the provider is on the forge, and see if it meets your needs. Rismoney -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com mailto:puppet-users%2bunsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com mailto:puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Deploying system configurations with another tool?
On 2013-07-05 20:49, Jakov Sosic wrote: It's a very fine line to walk. Perhaps an API (even a little script that does syntax checks and/or auditing) might suffice. One thing that did cross my mind is to allow deployment process to push specific files to specific locations on puppet master. That way, after the files are injected into master, all the deployment tool has to do afterwards is to initiate agent run on each node. What do you think about that idea? If the deployment user can push to the puppetmaster it only increases the attack surface. Another idea: the configurations get deployed to a central (git) repo and puppet pulls the updates from there. That way the deployment process never touches the puppet master, the dot.d is still under developer control, but not reachable from the local deployment UID. If that's the level of paranoia you need to apply, don't forget to audit other attack vectors like init scripts, setuid binaries and things that can be affected by subverting the application itself. Regards, David -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Trying and failing to get SSL working
I've been banging my head against the wall over trying to get activemq and mcollective working through Puppet. So far, I've been able to get it working with no SSL at all, then I got mcollective working with SSL. I'm trying now to get ActiveMQ working with SSL, but I'm having no luck at all. I don't know what keys are supposed to go where. Does anyone here have a Vagrant Box set up with Puppet installing and configuring ActiveMQ and Mcollective? I found the Mcollective Vagrant git repo at https://github.com/ripienaar/mcollective-vagrant.git, but this does not include ActiveMQ or SSL setups. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Fwd: [Module team] Much ado about modules
On Fri, Jul 5, 2013 at 11:05 AM, Ashley Penney ashley.pen...@puppetlabs.com wrote: Now that Puppetlabs has a module team we thought we should start trying to keep the community informed as to what we're doing and why on earth we're doing it. I wanted to put together a short update (I'm aiming to do these every friday) as to where we stand. This was our first week working full-time on Modules, and I spent a good chunk of time this week filling in paperwork, meeting people I've only seen on IRC, and trying to get up to speed with internal systems and tools. This slowed us down a little. Hi! I'm glad to hear this is prioritized. We focused specifically on puppetlabs-mysql and puppetlabs-apt this week to try and get the PR/issue count under control. To give you an idea of the progress we've made: puppetlabs-mysql: Closed/merged 20 PRs. puppetlabs-apt: Closed/merged 18 PRs. We're going to continue iterating over different modules each week to deal with the enormous backlog of PRs and issues and keep bashing these into shape until we're caught up with all the community submissions. We appreciate each and every PR you send us (unless you forgot specs, which makes me shout at a puppy) and hopefully we'll be able to shorten the cycle of merging them as this work goes forward. As a result of this week's work we have released: http://forge.puppetlabs.com/puppetlabs/apt/1.2.0 http://forge.puppetlabs.com/puppetlabs/mysql/0.8.0 Would it be possible for the module team to review Alessandro's The handy grail of modules standards thread and set a variable name standard moving forward? It doesn't even need to be quite as comprehensive, but some basic standard to start. We use quite a few modules as upstream, and would love to see some consistency even if it means breaking changes. Thanks again, and look forward to the great things coming out of the module team. Nan -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] How to force generation of ca_crl.pem?
Thanks very much Ken, I'm away from the comp for the weekend, I'll try these and get back to you as soon as I can. On Friday, 5 July 2013 22:08:37 UTC+10, Ken Barber wrote: If it helps I did a bit of a Gist walkthrough of the full cert recreation etc. using puppet cert generate here: https://gist.github.com/kbarber/5934100 ... On Fri, Jul 5, 2013 at 1:00 PM, Ken Barber k...@puppetlabs.comjavascript: wrote: I have a standard Puppet 2.7 configuration installed from Gem on Ubuntu 12.04, running behind Apache. I'm testing the reprovisioning of the puppet master from scratch in Vagrant and ran into a little snug - apache configuration points to a puppet ca_crl.pem file which doesn't exist, so apache refuses to start. Have you tried just using 'puppet cert generate mymaster_name' to populate the initial certificates? I don't have a 2.7.x around, but for 3.x it repopulates all the missing certificates it seems including ca_crl.pem. The puppet master documentation says that it'll automatically generate this file if it isn't present, but I need a way to get it generated automatically before apache tries to start. Yes, and it does - when you start it standalone using webrick (ie. puppet master --no-daemonize --debug --log console ... or something will probably do the trick). But the SSL offloading to Apache kind of breaks this as you've mentioned. ken. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
