Hi, On Mon May 19 16:39:25 2014, jcbollinger wrote: > > > On Monday, May 19, 2014 6:06:45 AM UTC-5, Boyan Tabakov wrote: > > Hi, > > The variable I want to access is not defined in a module/class. > It's the > globally defined $::environment. Since facts are also exposed as > global > variables, the server-defined $::environment gets overridden when > there's a fact with the same name. > > So any ideas on how to avoid that? As it is, it looks like a module > can't reliably detect environment, because a (potentially malicious) > client can send an 'environment' fact with arbitrary value. > > > > If you do not trust your nodes to specify their own environment, then > you should set up an ENC that specifies the correct environment for > each node to Puppet. That can be the only thing it does. The > environment specified by an ENC will be used instead of the one (if > any) specified by the agent. > > More generally, you should avoid declaring global variables in your > Puppet manifests, and especially you should avoid declaring globals > that collide with facts or with variables provided by the master > itself. Such collisions /should/ cause catalog compilation to fail > with an error message, but conceivably could fail silently instead. > Puppet variables cannot be changed once set.
That is exactly what I try to do. Still, this is what happens (puppetmaster 3.5.1, puppet agent 3.4.3): Agent's configured environment is "agent_env". Agent also has a fact called "environment" with value "agent_env_fact". There is ENC, enforcing environment for that node to be "enc_env". The node's catalog gets compiled in the "enc_env", as it should. For example the node reports: Local environment: "agent_env" doesn't match server specified node environment "enc_env", switching agent to "enc_env". However if any of the modules use the $::environment variable, it's value is "agent_env_fact". So the agent's fact masks the real value and any modules/manifests that make decisions based on the environment can be fooled. This means that any conditionals that are based on $::environment are not reliable. It would be totally fine, if that's documented and people are discouraged to use the $::environment variable, but I could not find anything like that. So, my original question still stands: is there a reliable way to find out the current node's environment in a module/manifest? Cheers, Boyan
signature.asc
Description: OpenPGP digital signature