Re: [Puppet Users] the issues with thias/fooacl: filesystem ACL
On Thu, May 19, 2016 at 5:04 PM, Sans <r.santanu@gmail.com> wrote: Hi there, > > Is anyone using thias/fooacl > <https://forge.puppet.com/thias/fooacl/license> module? I use it for > WordPress, to give www-data read access to wp-config.php and few other > files. Every time puppet runs, the file becomes unreadable: > > # file: wp-config.php > # owner: root > # group: root > user::r-- > user:www-data:r-- #effective:--- > group::--- > mask::--- > other::--- > > eventually breaking the whole site. Any idea why that's happening? And/or > how can I fix that? Really appreciate any help on this. > > If the file changes, fooacl on its own won't notice the change and won't reset the ACLs. You need to notify the class to ensure it does catch this. We have something like this for ours that we put after the fooacl resource: File[] ~> Class['::fooacl'] Hopefully this helps. -- Ken Lareau -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CALR_H%3DsTpx_SKybUpC1FfkvpMeybONh4tqEoVJ35z_qOuiLDug%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Trying to manage proper replication for PostgreSQL with Puppet
I'm not sure if anyone here will be able to help, but I feel I need to give it a shot, so... My team is in the process of getting ready to use PostgreSQL, but before that I need to ensure that our Puppet infrastructure can manage the systems properly, which means making sure replication stays working even when a box needs to be rebuilt. I'm using the PuppetLabs 'postgresql' module which seems pretty thorough, but I don't believe it's sufficient to actually handle recovery from a rebuild, so I'm asking here to see if anyone's already gone through this process before and could give some pointers, perhaps? The plan is to use the latest release (9.5.1) which is supposed to make this easier, but digging around the web hasn't turned up anything useful so far. Might someone be able to help? I can give more details as needed. (Apologies if this is off-topic for this list in any way.) Thanks in advance. -- Ken Lareau -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CALR_H%3Dtj7q%3DojnVEuoQSV%2BZ3N355z6%3DWm4c9OhDHfCnUU7eaQg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Looking for solution on working configuration for new testing Puppet servers in existing environments
systems). Hopefully this made sense and I can find someone who can give advice on how to proceed with this issue. Thanks in advance. - Ken Lareau -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Looking for solution on working configuration for new testing Puppet servers in existing environments
Eric, Thank you for the response, and yes, our current configuration and security requirements have made things a bit difficult at the moment. Fortunately we do already have an ENC which does access an access-controlled database and does have the environment information in it, though we still do pass '--environment' due to this not working long ago... and looking at the first issue ticket you mention, this could be a problem as our developers are allowed to connect their own VMs to the development Puppet server but can easily choose to point '--environment' to whatever they please. In actuality, they can do that now (and it would probably work), so the problem is already there, though I would definitely not want to make it worse. :) Right now our ENC only has a minimal amount of information in it, but the plan is to eventually populate it with more and reduce the amount of work the Puppet configuration has to do itself, as you suggested below. From the brief exchange on IRC this morning, the indication seems to be moving to a single CA should be the follow-up to this, and I think this is doable, though I'm still uncertain what the best path is to handle this. Once that's done, I can then look into improving the security of our systems (as in actually making it secure rather than what it really is right now). Thank you for your input. - Ken Lareau On Wed, Apr 18, 2012 at 7:56 AM, Eric Sorenson eric.soren...@me.com wrote: Hi Ken, thanks for posting. It seems like you have introduced some tension between the security requirements (clients which are in a particular environment must not be able to retrieve other environments) and the need to have widespread testing with good coverage. From what I understand you've managed this now by having different CA certificates for each environment, but -- as it sounds like you realise -- that is pretty problematic. I'd suggest you can end-run around a lot of this trouble by using an external node classifier to set and enforce client environment, so regardless of what the --environment string says from the client, each of the masters will consistently enforce policy. You don't have to go all-in to node class/parameter assignment in the ENC because static configs are merged with the output. A prerequisite is that you need to have some source of truth which the ENCs can consult to determine the disposition of each node that connects, but that source-of-truth could be an access-controlled database (maybe you already have one?) that is, in general, going to be a better place to put business logic (which nodes should be able to access each environment, and even perhaps some of the conditional logic in your manifests) than Puppet itself. This isn't without its own set of problems and might not be a panacea but I think would help a lot of your use case. Some relevant reading: http://docs.puppetlabs.com/guides/external_nodes.html https://projects.puppetlabs.com/issues/3910 https://projects.puppetlabs.com/issues/12869 Hope this helps - Eric Sorenson - N37 17.255 W121 55.738 - http://twitter.com/ahpook - On Tuesday, April 17, 2012 7:34:43 PM UTC-7, Ken Lareau wrote: Hello folks, After some conversation on #puppet on Freenode IRC, Eric Sorenson requested I repost the information and question here, so I am doing so and hopefully it will all make sense... We currently have a well-established and relatively complex Puppet setup in place at my company and I'm in the process of trying to streamline changes as well as implement better testing to ensure minimal disruption or issues when making those changes. Some information on the current situation: - There are currently three environments: development, staging, production. These are controlled via the '--environment' setting for puppet in each client. All clients only belong to one environment and do not move between them. - We have a single Puppet configuration to manage all environments. Various conditional statements based on environment, application type, hostname, etc. control what each client receives for its configuration. - There are separate servers for each environment for security reasons (primarily sensitive information that can only exist in the production environment). - The Puppet configuration maintained via a Git repo, currently on a single branch. - Each person on the admin team checks out own copy of the repo, make changes, commits the changes, then updates each environment on the Puppet servers for the changes to take effect. There are several issues with this process, unfortunately: - Every so often a configuration mistake will adversely affect an entire environment, and much of the time is only noticed _after_ the changes are pushed out. As a result, local changes tend to be made in the development environment for testing and sometimes aren't committed for a long time, leaving discrepancies between the environments which can lead
Re: [Puppet Users] Re: Looking for solution on working configuration for new testing Puppet servers in existing environments
Trevor, Thank you for the response; I believe you got the idea pretty well and while your suggestion makes sense, it is something we definitely can't follow through with right now; our configuration is massive and complex and having to maintain three different yet similar sets of configuration would be difficult and reduce our response time to necessary user changes (of which we get anywhere from 5-10 a day). It's just not feasible without a complete reworking of how we do things right now, and not at the top of our priority lists. I do appreciate the input, however. Thank you. - Ken Lareau On Wed, Apr 18, 2012 at 12:28 PM, Trevor Smith trevor.c.sm...@gmail.comwrote: I'll take a stab at some of this. Hopefully I'm correctly understanding your issue. Am I correct in the following? : You define 3 environments development, staging, and production. These environments are defined as such in Puppet but they are also separate environments within your network, for the sake of clarity I'll call them zones from here out? Each zone has a Puppet Master server. Each Puppet Master server has three environments defined development, staging, and production. Each environment has the full git repository with the applicable branch checked out. The clients in each zone connect to the Puppet Master in their zone and pull their configs from the corresponding environment. So a staging_zone_client connects to staging_zone_master and pulls from the staging_environment. If that's correct then: You already have three separate Puppet Masters so the environments are redundant. As configured staging_zone_client can pull from production_environment using --environment. One fix could be to define only the production environment on each zone's Puppet Master and check out the applicable branch in only the production environment. As long as you never check out the production branch in development or staging then clients from those zones couldn't pull the settings for production zone as it's just not available. As long as they cannot connect to the other zone's Puppet Master, preventable by network segmentation, certs etc... Within each zone you could then define environments such as development and testing for conducting those activities within each zone. So you'd have staging/dev and staging/test branches checked out in those environments. I guess you could extend that and create environments for each admin within each zone that would allow the admin to use the --environment option for clients to test their work within a zone. This would result in a lot of environments, and probably a lot of branches, but you wouldn't need a test Puppet Master for each admin. I'd think this would introduce the problem of making it difficult to reuse modules between zones as I'd think you'd end up basically managing three completely different branches. Unless the sensitive data you're worried about is not being stored in your puppet repo and you have no issues merging changes made to the production branch into the development and testing branches, plus your admins will have a lot of different topic branches to deal with. Long run you'd probably want to move zone specific settings out of your modules and use something like hiera so you can standardize your modules across zones and just pull in the location settings using hiera. Hope I understood your problems correctly and this is helpful.. On Tuesday, April 17, 2012 10:34:43 PM UTC-4, Ken Lareau wrote: Hello folks, After some conversation on #puppet on Freenode IRC, Eric Sorenson requested I repost the information and question here, so I am doing so and hopefully it will all make sense... We currently have a well-established and relatively complex Puppet setup in place at my company and I'm in the process of trying to streamline changes as well as implement better testing to ensure minimal disruption or issues when making those changes. Some information on the current situation: - There are currently three environments: development, staging, production. These are controlled via the '--environment' setting for puppet in each client. All clients only belong to one environment and do not move between them. - We have a single Puppet configuration to manage all environments. Various conditional statements based on environment, application type, hostname, etc. control what each client receives for its configuration. - There are separate servers for each environment for security reasons (primarily sensitive information that can only exist in the production environment). - The Puppet configuration maintained via a Git repo, currently on a single branch. - Each person on the admin team checks out own copy of the repo, make changes, commits the changes, then updates each environment on the Puppet servers for the changes to take effect. There are several issues with this process, unfortunately: - Every
