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