On Tuesday, September 2, 2014 11:14:27 AM UTC-5, Nigel Kersten wrote: > > > > > On Wed, Aug 27, 2014 at 8:10 AM, jcbollinger <john.bo...@stjude.org > <javascript:>> wrote: > >> >> >> On Tuesday, August 26, 2014 6:24:57 PM UTC-5, Nigel Kersten wrote: >> > [...]
> >> I am well aware of all the old hilarity surrounding determining the >> environment from which to serve various bits, but I was unaware that the >> resolution involved agents requesting their environment from the master. >> That implies that the master *still* relies on the agent to correctly >> specify (echo back) the environment from which to serve those bits, else >> why would the agent need to know? >> >> If that's really what's happening then it's a poor design (which I guess >> is why I supposed it *wasn't* what was happening). If the master is >> authoritative for a piece of information -- as it is for nodes' >> environments -- then it should not rely on relaying that information back >> to itself through an external actor -- that undermines its >> authoritativeness for the information. Moreover, to the extent that the >> master does have such a reliance, it leaves Puppet open to malicious >> manipulation of the requested environment. >> >> So, um, are you sure? >> > > Yes. The bit of info we haven't mentioned is that if the client and > server environments don't match, and the server is set to be authoritative, > then it triggers the client to do a new pluginsync and run with the server > environment. > > Tracking back to older tickets, there's a succinct description here from > Daniel Pittman: > > http://projects.puppetlabs.com/issues/16753 > > (which has related tickets for the rest of the change) > > "The reason this was removed was to support the changes that made the ENC > authoritative over the agent environment. As part of that we had a > bootstrapping problem: the agent had an idea of the environment to request, > used that in pluginsync, and then as part of the request for the catalog. > > If that idea was wrong, the catalog would be returned from the correct, > ENC specified environment, but it would have been generated with the wrong > set of plugins – including custom facts. So, the agent would detect that, > pluginsync to the new environment in the catalog, and compile a new catalog. > > That fixed the problem, but was inefficient – every agent run with an > incorrect environment would mean two catalog compilations, and doubling > master load in a common situation (ENC says !production, agent run from > cron) was pretty unacceptable. > > So, instead, the agent was changed to query the master for node data about > itself – and to use the environment that came back from that." > > What I'm hearing is that the master, when it is set authoritative, does rely on the agent's self-specified environment for plugin sync, but for catalog requests it uses that data only to verify that the agent knows the correct environment to request. That's better, but it still means that plugins cannot be secured against access from other environments. I suppose the issue there is that the determination of a node's environment may depend on its facts, which may depend on its environment.... I guess it was judged better to open the possibility of infinite looping than to foreclose the possibility of choosing an environment based on custom fact values. And I also suppose that the agent requests its last-assigned environment prior to plugin-sync, to avoid syncing twice every time when the ENC overrides the agent's self-specified environment. I still don't like it. If the master desires that the agent first sync plugins from its last-assigned environment, then why does it make the agent jump through hoops and create extra network traffic to do that? It should look like this instead: Agent: Please give me the plugins *for your best guess as to my correct environment* [which I think should be 'bar'] Master: Here you are. These are the plugins for environment 'foo'. Agent: Here are my facts for environment 'foo' [even though I think my environment should be 'bar']. Please give me my catalog. (option 1) Master: Here you are. (option 2) Master: Oops, you're right, your environment should be 'bar'. Please sync again. [...] (option 3) Master: Oops, your environment should be 'plugh'. Please sync again. [...] Agent: Thank you. Now please give me the content of File['/etc/example'] in environment 'foo'|'bar'|'plugh' (option 1) Master: Here you are. (option 2) Master: You're daft. I already told you your environment was <other environment>. Go away. Not only does that eliminate one network request, but it also allows plugins to be better secured. John -- 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/9485a701-0e25-43a9-b51a-c2e444766e4b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
