----- Original Message ----- > From: "Erik Dalén" <[email protected]> > To: "puppet-dev" <[email protected]> > 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 <[email protected]> > 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 [email protected]. >> 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 [email protected]. > 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 [email protected]. 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.
