On 2014-20-05 13:02, Boyan Tabakov wrote:
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?
This suggests a design that is somewhat inside-out, the idea is that
what is *in* the environment defines what you want, not that you inside
the environment make decisions based on the name of the environment.
Typically, you benefit from setting up special environments when
developing and testing and it becomes a horrible problem when the
modules themselves have to be aware of an environment naming scheme.
Or put differently, logic inside your environment should not care what
the name of the environment is.
- henrik
--
Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/llfi8f%24e9n%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
