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. 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.
