Puppet users - Sep 2009 - Puppetmaster be client of another puppetmaster?

Is is possible to have a puppetmaster that is a client of a different
puppetmaster? We manage our customers'' server via puppet, but one
customer
has a puppetmaster server which looks after their internal systems.
We''ve
tried the following in /etc/puppet/puppet.conf ("customer" and
"us"
replacing the domain names) on their puppetmaster:

[puppetmasterd]
certname = puppetmaster.customer.com
templatedir=/var/lib/puppet/templates

[puppetd]
server = puppetmaster.us.com
certname = puppetmaster.us.com

When we run "puppetd -t" on that server, we get:

# puppetd -t

warning: Certificate validation failed; consider using the certname
configuration option 

err: Could not retrieve catalog: Certificates were not trusted:
SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B:
certificate verify failed 

warning: Not using cache on failed catalog

Is there a way around this?

Thanks,
Keith

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Yes, its possible :)

but that would mean a CA chain, and eventually that each client can query
all puppetmasters (which I''m not sure this is what you are looking for
in).

maybe setup a different puppet.conf for your puppet master clients (With a
different ssl directory etc?)

Ohad


On Wed, Sep 9, 2009 at 12:24 AM, Keith Edmunds <kae@midnighthax.com>
wrote:
>
> Is is possible to have a puppetmaster that is a client of a different
> puppetmaster? We manage our customers'' server via puppet, but one
customer
> has a puppetmaster server which looks after their internal systems.
We''ve
> tried the following in /etc/puppet/puppet.conf ("customer" and
"us"
> replacing the domain names) on their puppetmaster:
>
> [puppetmasterd]
> certname = puppetmaster.customer.com
> templatedir=/var/lib/puppet/templates
>
> [puppetd]
> server = puppetmaster.us.com
> certname = puppetmaster.us.com
>
> When we run "puppetd -t" on that server, we get:
>
> # puppetd -t
>
> warning: Certificate validation failed; consider using the certname
> configuration option
>
> err: Could not retrieve catalog: Certificates were not trusted:
> SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B:
> certificate verify failed
>
> warning: Not using cache on failed catalog
>
> Is there a way around this?
>
> Thanks,
> Keith
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Sep 8, 9:01 pm, Ohad Levy <ohadl...@gmail.com>
wrote:
> Yes, its possible :)
>
> but that would mean a CA chain, and eventually that each client can query
> all puppetmasters (which I''m not sure this is what you are looking
for in).
I''m not sure I quite follow the logic there.  Is the theory that the
the intermediate puppetmaster will use the same certificate to
identify itself to its puppetmaster that it uses to sign (and verify)
its own clients'' certificates?  And following from that, are you
suggesting that the top level puppetmasters will then find their own
certificate in the chain of trust, for the low-level clients, and
therefore allow them to connect?

That sounds reasonable, but is it all documented / demonstrable, or
just speculative?  I don''t see any special reason why it would have to
have been implemented that way, but perhaps it falls out naturally.
> maybe setup a different puppet.conf for your puppet master clients (With a
> different ssl directory etc?)
And something along those lines would indeed seem to be a viable
solution.  More generally (and abstractly), isolate the intermediate
puppetmaster''s trust relationship with its own puppetmaster from its
relationships with its clients.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Wed, Sep 9, 2009 at 9:11 PM, jcbollinger
<John.Bollinger@stjude.org>wrote:
>
>
>
> On Sep 8, 9:01 pm, Ohad Levy <ohadl...@gmail.com> wrote:
> > Yes, its possible :)
> >
> > but that would mean a CA chain, and eventually that each client can
query
> > all puppetmasters (which I''m not sure this is what you are
looking for
> in).
>
> I''m not sure I quite follow the logic there.  Is the theory that
the
> the intermediate puppetmaster will use the same certificate to
> identify itself to its puppetmaster that it uses to sign (and verify)
> its own clients'' certificates?  And following from that, are you
> suggesting that the top level puppetmasters will then find their own
> certificate in the chain of trust, for the low-level clients, and
> therefore allow them to connect?
>
I have this setup currently, I wrote a wiki page about it at:
 http://reductivelabs.com/trac/puppet/wiki/PuppetScalability  under
Centralized Puppet Infrastructure

> That sounds reasonable, but is it all documented / demonstrable, or
> just speculative?  I don''t see any special reason why it would
have to
> have been implemented that way, but perhaps it falls out naturally.
>
> > maybe setup a different puppet.conf for your puppet master clients
(With
> a
> > different ssl directory etc?)
>
> And something along those lines would indeed seem to be a viable
> solution.  More generally (and abstractly), isolate the intermediate
> puppetmaster''s trust relationship with its own puppetmaster from
its
> relationships with its clients.
>
Yeah, that makes more sense in your setup.

Ohad

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

on my puppetmaster server I have an extra dir: /etc/puppet/client

In the /etc/puppet/puppet.conf I have a section for the client:

[puppetd]
     server = puppet.mycompany.com

     # do not change this since this machine is the server
     factsync = false

     # Where SSL certificates are kept.
     # The default value is ''$confdir/ssl''.
     # since this is the puppet server, we need a seperate dir for  
these files
     ssldir = /etc/puppet/client/ssl


---
Thanks,

Allan Marcus
505-667-5666



On Sep 8, 2009, at 10:24 AM, Keith Edmunds wrote:
>
> Is is possible to have a puppetmaster that is a client of a different
> puppetmaster? We manage our customers'' server via puppet, but one
> customer
> has a puppetmaster server which looks after their internal systems.  
> We''ve
> tried the following in /etc/puppet/puppet.conf ("customer" and
"us"
> replacing the domain names) on their puppetmaster:
>
> [puppetmasterd]
> certname = puppetmaster.customer.com
> templatedir=/var/lib/puppet/templates
>
> [puppetd]
> server = puppetmaster.us.com
> certname = puppetmaster.us.com
>
> When we run "puppetd -t" on that server, we get:
>
> # puppetd -t
>
> warning: Certificate validation failed; consider using the certname
> configuration option
>
> err: Could not retrieve catalog: Certificates were not trusted:
> SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B:
> certificate verify failed
>
> warning: Not using cache on failed catalog
>
> Is there a way around this?
>
> Thanks,
> Keith
>
> >

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Wow, the other respondents made this somewhat complicated.

I do this right now. Our "development" puppetmaster handles a bunch of
machines, but it itself is managed by our "production" puppetmaster.

We didn''t do all this certificate juggling. The development
puppetmaster (puppet.dev.internal) has server = puppet.prod.internal
in it''s puppet.conf, while the machines that point to the development
puppetmaster all have server = puppet.dev.internal in their
puppet.conf.

--Paul

On Tue, Sep 8, 2009 at 9:24 AM, Keith Edmunds<kae@midnighthax.com>
wrote:
>
> Is is possible to have a puppetmaster that is a client of a different
> puppetmaster? We manage our customers'' server via puppet, but one
customer
> has a puppetmaster server which looks after their internal systems.
We''ve
> tried the following in /etc/puppet/puppet.conf ("customer" and
"us"
> replacing the domain names) on their puppetmaster:
>
> [puppetmasterd]
> certname = puppetmaster.customer.com
> templatedir=/var/lib/puppet/templates
>
> [puppetd]
> server = puppetmaster.us.com
> certname = puppetmaster.us.com
>
> When we run "puppetd -t" on that server, we get:
>
> # puppetd -t
>
> warning: Certificate validation failed; consider using the certname
> configuration option
>
> err: Could not retrieve catalog: Certificates were not trusted:
> SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B:
> certificate verify failed
>
> warning: Not using cache on failed catalog
>
> Is there a way around this?
>
> Thanks,
> Keith
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Wed, 9 Sep 2009 11:33:21 -0700, paul.lathrop@gmail.com said:
> The development
> puppetmaster (puppet.dev.internal) has server = puppet.prod.internal
> in it''s puppet.conf, while the machines that point to the
development
> puppetmaster all have server = puppet.dev.internal in their
> puppet.conf.
Thanks, but I was essentially using that configuration, and I had the
certificate errors detailed in the original posting.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Wed, Sep 9, 2009 at 11:47 AM, Keith Edmunds<kae@midnighthax.com>
wrote:
>
> On Wed, 9 Sep 2009 11:33:21 -0700, paul.lathrop@gmail.com said:
>
>> The development
>> puppetmaster (puppet.dev.internal) has server = puppet.prod.internal
>> in it''s puppet.conf, while the machines that point to the
development
>> puppetmaster all have server = puppet.dev.internal in their
>> puppet.conf.
>
> Thanks, but I was essentially using that configuration, and I had the
> certificate errors detailed in the original posting.
In that case it is almost certainly a time synchronization issue.

--Paul

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---