On Thursday, June 23, 2016 at 1:30:37 AM UTC-5, Alex Samad wrote: > > Hi > > So I am a bit of a newbie. My assumption was to setup using a master > puppet server. But I wanted to make sure that environment was handled > by the master puppet - I have control over that and I might not be > able to exclude control over the managed box from other users (dam > developers !). > >
I'm inclined to agree that central control is to be preferred. Do be aware, however, that control over node environment is mostly a *management* feature, not a *security* feature. Your master can control what resources it records in nodes' catalogs, but those nodes' admins can disable Puppet, make it run in --noop mode, make it present false facts to the master, and many other things. Do not grant privileges to people whom you do not trust, and do not trust anyone any more than you need to do. > I wanted some way to test what I was doing was correct. > > And you found one. > " > If your nodes care deeply about which Puppet environment they are > assigned to, then you are doing something wrong. > " > > so I am planning on having atleast a production, sim , inf, non prod > and a dev environment. > > I would presume a box would want to know which environment they are > in, because in prod they might be on a certain rpm / module or > certain config - lets say for example MOTD. > > But i might be wrong ? > > In the first place, I recommend *not* using multiple Puppet environments unless you have a Puppet-related reason for doing so. The prime reason in this category would be that you want to allow for use of different versions of the same Puppet modules to be used with one group of nodes than with another. When no such reason applies, environments do not provide a benefit commensurate with the extra complication and work they involve. In the second place, yes, you're wrong. The Puppet environment to which a node is assigned affects the details of the catalogs built for it, which in turn affects those nodes' configurations. The *master* makes decisions based on node environment, but nodes need not and should not care why they are configured as they are. For example, nodes do not need to know or care about the meaning of the contents of their MOTD; they just need to present the text -- whatever it is -- to users when they log in and when they ask for it. Likewise, they do not need to know why they are configured to access a particular database server, why they have the particular vhosts configured that they do, why they have the particular users and passwords they have, why they mount the particular remote file systems they mount, *etc*.. > My thought had been to align production environment with production > server, infra with infra servers and non prod non infra in the non > prod environment. > Even if you ignore my advice and do that, what I'm saying is that you should not identify Puppet's sense of "environment" with any external concept going by the same name. I maintain that nodes probably don't need to be explicitly aware of the label of their operational environment, either, but especially if you're exerting central control over Puppet environments, there is no reason for nodes to care how Puppet labels those environments. 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/df3051e0-c516-4e17-8835-9ebabb82ae5e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
