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


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to