On 20.5.2014, 17:05, jcbollinger wrote:
>
>
> On Tuesday, May 20, 2014 7:36:31 AM UTC-5, Henrik Lindberg wrote:
>
> 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 de
On Tuesday, May 20, 2014 6:55:31 AM UTC-5, Jose Luis Ledesma wrote:
>
> But, who can run puppet?
>
> I mean, most puppet configurations needs root, so if someone malicious is
> a root which is the point of being able to cheat the environment? He can do
> whatever wants.
>
Yes, generally speaki
On Tuesday, May 20, 2014 7:36:31 AM UTC-5, Henrik Lindberg wrote:
>
> 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.
>
Agreed
On Tuesday, May 20, 2014 6:02:17 AM UTC-5, 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
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. Sinc
But, who can run puppet?
I mean, most puppet configurations needs root, so if someone malicious is a
root which is the point of being able to cheat the environment? He can do
whatever wants.
Regards,
Hi,
On Mon May 19 16:39:25 2014, jcbollinger wrote:
>
>
> On Monday, May 19, 2014 6:06:45 AM UTC
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
> g
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
> t
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
Sorry, replying To wrong message.
-- Laurent.
Le 9 mai 2014 19:16, "Laurent CREPET" a écrit :
> The master stores the configuration for the nodes it manages. When
> requested by a node (agent), it compiles the manifests for this node and
> send it to the node.
>
> You should probably post in eng
The master stores the configuration for the nodes it manages. When
requested by a node (agent), it compiles the manifests for this node and
send it to the node.
You should probably post in english. I'm answering after using google
translate on your message.
-- Laurent.
-- Laurent.
Le 9 mai 2014
you can use the Full qualified variable name like
::class_name::variable
Regards,
El 09/05/2014 13:15, "Boyan Tabakov" escribió:
> Hi,
>
> The puppet master sets several global variables, including $environment,
> $serverip, etc
> (
> http://docs.puppetlabs.com/puppet/latest/reference/lang_fact
Hi,
The puppet master sets several global variables, including $environment,
$serverip, etc
(http://docs.puppetlabs.com/puppet/latest/reference/lang_facts_and_builtin_vars.html).
However, looks like client facts with the same names can mask out these
variables. How can one determine reliably the c
13 matches
Mail list logo
