The values they receive for a particular module parameter does not need to have anything to do with their environment. That can come from hiera.
On Thursday, June 23, 2016, Alex Samad <a...@samad.com.au> wrote: > On 24 June 2016 at 00:16, jcbollinger <john.bollin...@stjude.org > <javascript:;>> wrote: > > > > > > 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 > > I agree but how do you make them difference for different nodes, if I > specify a group of nodes that have a specific MOTD... the nodes don't > care but ( i was using it as an example). maybe a better one would be > say smtp setup - all nodes have it, non prod must point to the non > prod smtp server. > > > > 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.. > > > > > Sorry our argument seems counter intuitive. Maybe I am miss understanding. > > For example I have had a lot of issue with winbind. (centos 6.x). So > my thought is > > production environment - has all the prod nodes. > It has a specific version of winbind, might be old but it works > > My other environments have different newer versions of winbind. > > > if you can explain how I can do that with 1 environment . happy to > learn. I haven't done a puppet setup before - which is why i'm asking > and questioning. > > > > > > > >> > >> 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. > > so environments should only really align with puppets production code > and none prod code. and by non prod code you are talking only about > puppet module code ? > > > > > > > > John > > > > -- > > You received this message because you are subscribed to a topic in the > > Google Groups "Puppet Users" group. > > To unsubscribe from this topic, visit > > https://groups.google.com/d/topic/puppet-users/mZBLZQKZ0xM/unsubscribe. > > To unsubscribe from this group and all its topics, send an email to > > puppet-users+unsubscr...@googlegroups.com <javascript:;>. > > 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. > > -- > 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 <javascript:;>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/CAJ%2BQ1PXEBMSmqdeshY9N9Q%3DeQGhyD7g3cBSx3dt8nFA8ENzajA%40mail.gmail.com > . > For more options, visit https://groups.google.com/d/optout. > -- Rob Nelson rnels...@gmail.com -- 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/CAC76iT-5rs8nQYQ7LXHfYUMZvGegG%3D3Os4FgPd%2BAKp7OaxDrWA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
