----- Original Message ----- > From: "Erik Dalén" <erik.gustav.da...@gmail.com> > To: "puppet-dev" <puppet-dev@googlegroups.com> > Sent: Thursday, October 9, 2014 8:02:47 AM > Subject: Re: [Puppet-dev] How should apply behave under an ENC
> I vote for option 2 or 3. > But against 2a. I think differentiating between a config file that > specifies the default value (environment=production), and one that leaves > it out (to get the default value) seems really odd behaviour. > > Note that this whole thing only applies if you have node_terminus=exec in > the main or user sections of the config file, and your ENC actually returns > a environment. So if you want to ignore your ENC you can also just use > --node_terminus=plain on the command line. 2 or 3, but I think 3 should win. Configuring an ENC with puppet apply is probably not the most common thing or something one would enable everywhere apply is used. I found people who use masterless would have a shell script to do those runs or maybe run puppet with a specific config file - leaving normal puppet apply test.pp type behaviour as is. Either way they would enable the masterless mode used to manage the machine using a special set of steps and those steps would include enabling an ENC So for me at least if I configure apply to use an ENC then that ENC should be authoritative. > > On 6 October 2014 03:30, Felix Frank <felix.fr...@alumni.tu-berlin.de> > wrote: > >> Hi all, >> >> when we recently fixed a regression that had to do with directory >> environments and ENC (PUP-3258) I noticed that the handling is weird >> when the ENC actually picks an environment for the local machine. >> >> As far as I can tell, puppet apply ignored that until now. The apply >> command used the configured environment, replaced its :manifest setting >> with what's chosen on the commandline, and makes that the only available >> environment. >> >> >> https://github.com/puppetlabs/puppet/blob/fea22be6a957e62005cab649537b39af0d0bda74/lib/puppet/application/apply.rb#L185-190 >> >> Puppet 3.7.0 is less stringent in that regard. It retains the set of >> available environments. >> >> >> https://github.com/puppetlabs/puppet/blob/master/lib/puppet/application/apply.rb#L193 >> >> This apparently causes an error when the ENC returns an environment (any >> environment), which happens just below the linked code line in apply.rb. >> This environment is looked up, bypassing the override of the :manifest. >> I suggested a fix for this: Force the node (external or not) to use the >> overridden environment. >> >> >> https://github.com/ffrank/puppet/commit/39b78a8d25fa96c98f81227cd3ef6b48010fab68 >> >> During PR triage (sorry for vanishing suddenly, something came up), we >> got some doubts whether this was the right thing to do. It is probably >> in keeping with former behavior, but it contradicts a decision that was >> made wrt. a classic bug. >> >> http://projects.reductivelabs.com/issues/3910 >> >> When using agent, not apply, the puppet master may invoke an ENC. The >> environment returned from the classifier takes precedence over any >> :environment configuration on the agent (both file and commandline). >> This is to allow users to use their ENC in contexts that are relevant >> for security. >> >> We're now looking for feedback on whether apply should get the same >> semantics, for masterless operation. >> >> There are three alternatives here that I can see: >> >> 1. Status quo - ruthlessly override whatever the ENC specifies. >> 2. Flexible - use the ENC environment, but allow overriding it via --env >> on the commandline >> 3. Strict - always use the ENC environment (except for the overridden >> :manifest) >> >> We might even go for a 2a, that would allow config files to override the >> ENC as well (if we can easily discern such values from the defaults at >> this point in the code). >> >> Personally, I feel that the strict behavior would be very inconvenient. >> An attacker could likely circumvent the ENC after all, so the security >> aspect doesn't really apply here. >> >> My vote is for the 2nd approach. >> >> Cheers, >> Felix >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to puppet-dev+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-dev/5431F0B6.4070700%40Alumni.TU-Berlin.de >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Erik Dalén > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email > to puppet-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/CAAAzDLensoriqr9h0Gc%3DTZGFBPui_XgqjLOeThG23LLwtm_wEg%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/1395307755.5420.1412846020707.JavaMail.zimbra%40devco.net. For more options, visit https://groups.google.com/d/optout.
