Re: [Puppet Users] external node classifier my setup

[Rob Nelson]

On Friday, June 24, 2016, Alex Samad  wrote:

> The point i was trying to make was not the how. But that a group of
> nodes will have 1 config and another a different config.  It seems
> like environments would be the way to group that.
>

Alex,

Environment is a very overloaded term. In this case, 'environment' means 'a
discrete set of puppet code and data.' It has no direct relation to
'environment' meaning 'an operational status of a set of services' (or
however one might deceive the concepts of 'production' vs 'development' vs
…). It is important not to confuse those two, or any other use of the term
environment.

The reason there is no direct relationship between those two versions of
the term is because a node that is in the operational status of production
can switch between the production environment and any other environment of
your puppet code without affecting its operational status (whether it
should is a very different question!). You may also have two nodes that are
both production nodes that receive different values for e.g. their mail
relay.

This data is better separated via hiera, where you can say "all nodes in
the Sydney datacenter use mail relay A, and all those in Perth use mail
relay B." They don't have to be in separate puppet environments for that to
occur.

Environments are more often used in your code development workflow, where
environments map to your version control branches. You branch off of
development to a branch called feature_a. None of your actual nodes check
in against either of these environments, but your CI pipeline and your
developers test against these with vagrant or similar. You maybe even take
a canary node that normally uses the puppet environment production and have
it check in against the feature_a environment instead.  When the feature
works properly, you merge feature_a->development and delete the branch
feature_a, which deletes the environment feature_a.

You repeat this for a few features, and then you merge from
development->production. Now the code that was tested in CI is being used
by the operational production nodes, which are using the operational
environment as well. Then you go back to making more feature branches and
repeat.

Along the way, a given node may check into one puppet environment 99% of
the time, but nothing prevents the node from using a different puppet
environment, for testing or urgent fixes or for any other reason. The
puppet environment can be pretty fluid without changing the data and
configuration a given node receives much if at all.

I hope that's not too confusing. You did say you haven't managed a puppet
install yet, and I think if you set something up in vagrant or a lab, some
of the concepts would become clear a lot quicker than when we discuss them
in the abstract.


-- 

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_ZScBbqvtOJ7xdkwr8--JspDnYBgKGjJ-%3DvdDp-tAcJQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: external node classifier my setup

[Alex Samad]

On 25 June 2016 at 00:32, jcbollinger  wrote:
>
>
> On Thursday, June 23, 2016 at 6:11:11 PM UTC-5, Alex Samad wrote:
>>
>> On 24 June 2016 at 00:16, jcbollinger  wrote:
>
>
> [...]
>
>>
>> > 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.
>>
>
>
> How is configuring which SMTP server a node uses fundamentally different
> from configuring a node's MOTD?  In either case you're just plugging the
> right data into the right hole.  The holes are even similar in shape: part
> or all of a particular text file in a known location (or on Windows, the
> holes are sometimes registry entries).

The point i was trying to make was not the how. But that a group of
nodes will have 1 config and another a different config.  It seems
like environments would be the way to group that.


>
> You said earlier that your master will assign nodes to environments, and at
> that time you were identifying Puppet environments with operational
> environments.  It follows that you anticipate that your master will have
> enough information to identify nodes' intended operational environments.

I believe in my environment I can do that by hostname as a general rule.

> How the master should translate that information into node configurations is
> an entirely different question, and largely orthogonal to whether Puppet
> environments are associated with operational environments.  Surely you don't
> suppose that every machine in the same operational environment will be
> configured identically to every other, so even if you do match Puppet
> environments to operational environments, that does not in itself address
> questions about how to assign configurations to nodes -- or, in Puppet
> speak, how to classify nodes.
Why can't I expect that. if I expect puppet to look after things like
MOTD, SSHD config, smtp config, firewall config. users. SOE directory
setup. Why can't I expect them to be the same. I understand that ip
address and name will be different.



>
> In fact, Puppet has several mechanisms for that, one of them being the one
> that you already plan on using to assign nodes to environments: the external
> node classifier (ENC).  Puppet also makes heavy use of external data for
> configuring nodes, generally accessed via its Hiera hierarchical data
> subsystem.  Hiera data can be used to directly classify nodes
> (hiera_include()), or to supplement classification performed primarily
> elsewhere (automated data binding, hiera(), hiera_hash(), hiera_array()).  I
> prefer to put most of the load on Hiera, myself, but the reasons for that
> would be an entirely separate discussion.

I plan to use hiera - still getting my head around that.


>
> Furthermore, how you structure your manifest set plays heavily into how
> easily this all works out.  If you are not already aware of Craig Dunn's
> "Roles and Profiles" pattern, then you should familiarize yourself with it.
> You are not obligated to use it, but I think it synergizes with your
> objectives, and it has been applied with great success in a lot of places.

I will definitely be looking at this. I had already planned on using
profiles and roles - got that from the sydney user group. I have most
of mine defined I believe. Now to work our how to implement

>
>
>>
>> > 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 

Re: [Puppet Users] Re: SRV records not working correctly

[Josh Cooper]

On Fri, Jun 24, 2016 at 8:41 AM, Martin Jackson 
wrote:

> You might need:
> pluginsource   = puppet:///plugins
> pluginfactsource   = puppet:///pluginfacts
>
> In your puppet.conf.
>

That's good advice if you're using puppet < 4 and the debug output seems to
match that (since the host in the URL is "puppet"):

Error: /File[/var/lib/puppet/facts.d]: Could not evaluate: Could not
retrieve file metadata for puppet://puppet/pluginfacts: getaddrinfo: Name
or service not known

Note that issue should be fixed in 4.0 (see
https://tickets.puppetlabs.com/browse/PUP-1035).

We've had a report of a related issue in 4.x (see
https://tickets.puppetlabs.com/browse/PUP-6297). Maybe related?


>
> On Thursday, June 23, 2016 at 3:35:42 PM UTC-5, Matthew Ceroni wrote:
>>
>> I am attempting to load balance two master servers via SRV records.
>>
>> https://gist.github.com/cyrus-mc/fefef0d07dcb6fe211ad8514ce2c710a
>>
>> As you can see at line 6 it finds 2 records for the specified SRV. At
>> line 15 it makes a connection to one of the Puppet servers.
>>
>> However at line 29 it connects to https://puppet:8140 which is the
>> default puppet server if one isn't specified.
>>
>> Further down the connection details you see it does another SRV lookup
>> (line 76), finds 2 records (as it should) and makes a connection to one of
>> them for catalog compilation.
>>
>> So SRV records appear to be working a little. Not sure what is happening
>> around line 29 to cause it to just try and connect to puppet.
>>
>> Thanks
>>
> --
> 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/c358a880-b138-4df1-bdc3-78a792809ce1%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Josh Cooper
Developer, Puppet

PuppetConf 2016 , October 17-21, San Diego,
California
*Early Birds save $350*

-
Register by June 30th

-- 
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/CA%2Bu97u%3DhqxAZcgEH4t25FcRFJg6ZFcyLZtJSJXHPCT9oJ0%2BKZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Augtool installation

[Michael Watters]

You'll need to install the package that provides augtool in order to use it.

yum provides augtool should show you what package to install.


On Friday, June 24, 2016 at 9:29:25 AM UTC-4, Shrawan Bhagwat wrote:
>
> Hi All,
>
> I have installed Augeas setup from yum repository using command yum 
> install ruby-augeas.x86_64.
>
> I have got all packages of Augeas but not able to find command Augtool.
>
> Please help!
>
> Regards,
> Shrawan
>

-- 
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/88e90a53-ce3e-4a97-b556-dc43d5b0f653%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Puppet's CA with an external issued CA-Certificate

[Christoph Fiehe]

Thanks for your fast response... Your approach sounds very interesting. I 
will give it a try.

Thank you very much.

-- 
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/5e342904-092a-4a49-a968-61b37d117216%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: SRV records not working correctly

[Martin Jackson]

You might need:
pluginsource   = puppet:///plugins
pluginfactsource   = puppet:///pluginfacts

In your puppet.conf.

On Thursday, June 23, 2016 at 3:35:42 PM UTC-5, Matthew Ceroni wrote:
>
> I am attempting to load balance two master servers via SRV records.
>
> https://gist.github.com/cyrus-mc/fefef0d07dcb6fe211ad8514ce2c710a
>
> As you can see at line 6 it finds 2 records for the specified SRV. At line 
> 15 it makes a connection to one of the Puppet servers.
>
> However at line 29 it connects to https://puppet:8140 which is the 
> default puppet server if one isn't specified. 
>
> Further down the connection details you see it does another SRV lookup 
> (line 76), finds 2 records (as it should) and makes a connection to one of 
> them for catalog compilation.
>
> So SRV records appear to be working a little. Not sure what is happening 
> around line 29 to cause it to just try and connect to puppet.
>
> Thanks
>

-- 
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/c358a880-b138-4df1-bdc3-78a792809ce1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: external node classifier my setup

[jcbollinger]

On Thursday, June 23, 2016 at 6:11:11 PM UTC-5, Alex Samad wrote:
>
> On 24 June 2016 at 00:16, jcbollinger  
> wrote: 
>

[...]
 

> > 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. 
>
>

How is configuring which SMTP server a node uses fundamentally different 
from configuring a node's MOTD?  In either case you're just plugging the 
right data into the right hole.  The holes are even similar in shape: part 
or all of a particular text file in a known location (or on Windows, the 
holes are sometimes registry entries).

You said earlier that your master will assign nodes to environments, and at 
that time you were identifying Puppet environments with operational 
environments.  It follows that you anticipate that your master will have 
enough information to identify nodes' intended operational environments.  
How the master should translate that information into node configurations 
is an entirely different question, and largely orthogonal to whether Puppet 
environments are associated with operational environments.  Surely you 
don't suppose that every machine in the same operational environment will 
be configured identically to every other, so even if you do match Puppet 
environments to operational environments, that does not in itself address 
questions about how to assign configurations to nodes -- or, in Puppet 
speak, how to *classify* nodes.

In fact, Puppet has several mechanisms for that, one of them being the one 
that you already plan on using to assign nodes to environments: the external 
node classifier (ENC) .  
Puppet also makes heavy use of external data for configuring nodes, 
generally accessed via its Hiera  
hierarchical data subsystem.  Hiera data can be used to directly classify 
nodes (hiera_include()), or to supplement classification performed 
primarily elsewhere (automated data binding, hiera(), hiera_hash(), 
hiera_array()).  I prefer to put most of the load on Hiera, myself, but the 
reasons for that would be an entirely separate discussion.

Furthermore, how you structure your manifest set plays heavily into how 
easily this all works out.  If you are not already aware of Craig Dunn's 
"Roles and Profiles" pattern , then 
you should familiarize yourself with it.  You are not obligated to use it, 
but I think it synergizes with your objectives, and it has been applied 
with great success in a lot of places.

 

> > 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. 
>


In the first place, this still has nothing to do with nodes being mindful 
of which Puppet environment they are assigned to, nor even of which 
operational environment they are assigned to.  Nodes will use whichever 
winbind (for example) is installed on them, regardless of 

[Puppet Users] Re: get one file with all server in puppet (export resource)

[Andreas Dvorak]

Thank you for the answer.
That will take some time to understand.

Andreas

-- 
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/5c80fdc9-61c6-4feb-93f5-8d8f0846b875%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Augtool installation

[Shrawan Bhagwat]

Hi All,

I have installed Augeas setup from yum repository using command yum 
install ruby-augeas.x86_64.

I have got all packages of Augeas but not able to find command Augtool.

Please help!

Regards,
Shrawan

-- 
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/08a683bd-dd7c-45ea-aaa1-e8c9529ac669%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] external node classifier my setup

[R.I.Pienaar]

>> 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.

Environments is a very big hammer for whats basically a tiny nail you're 
describing.

Suggest you look to hiera instead for a solution.

-- 
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/162870092.176.1466754501655.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Puppet's CA with an external issued CA-Certificate

[Eric Sorenson]

This is not fully supported yet, but can work with a couple of caveats - 
the question has come up a few times recently.

Can you please try my draft HOWTO documentation at this gist, and let me 
know how it works for you? You can reply here or comment on the gist if 
there are specific lines that you run into trouble with.

https://gist.github.com/ahpook/06d4cfda1d68c08bc82fbfdc40123b28

--eric0

On Thursday, June 23, 2016 at 11:17:37 PM UTC-7, Christoph Fiehe wrote:
>
> This is exactly the use case, I require in my scenario. I must have 
> several Puppet CAs, each acting as intermediate CA that has an individual 
> CA certificate signed by a single root CA. Each intermediate CA signes the 
> certificates of some puppet agents. I have created a small picture to show 
> you how the scenario should look like.The root puppetmaster acts as a 
> bootstrapping node that should set up different nodes as puppetmaster when 
> someone assignes the puppetmaster role to this new node.
>
>
>
>
> 
>
> Has anybody an idea, if this scenario can be realized with the help of 
> Puppet? The most interesting question is how Puppet behaves when you assign 
> "ca = true" to an agent node and assign "ca_server =  CA>".
>

-- 
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/d3846c57-7694-4fa7-b1e8-60dbb830f879%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Puppet's CA with an external issued CA-Certificate

[Christoph Fiehe]

This is exactly the use case, I require in my scenario. I must have several 
Puppet CAs, each acting as intermediate CA that has an individual CA 
certificate signed by a single root CA. Each intermediate CA signes the 
certificates of some puppet agents. I have created a small picture to show 
you how the scenario should look like.The root puppetmaster acts as a 
bootstrapping node that should set up different nodes as puppetmaster when 
someone assignes the puppetmaster role to this new node.





Has anybody an idea, if this scenario can be realized with the help of 
Puppet? The most interesting question is how Puppet behaves when you assign 
"ca = true" to an agent node and assign "ca_server = ".

-- 
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/c4e2777c-b21b-4923-b12c-27eaec0377ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Load Balancer for Puppet Master

[Braian Fabián Leiva]

I'm trying to setup a Load Balancer in front of some Compile Masters and 
the Puppet docs says that I can achieve that either with raw TCP proxying, 
or acting as its own SSL endpoint[1]. If I configure the LB with SSL and 
SNAT will that work? Is it better to use bridging instead?

[1] 
https://docs.puppet.com/guides/scaling_multiple_masters.html#option-3-use-a-load-balancer

-- 
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/5ddb5120-4f41-4404-9f91-c177f7651757%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.