I think this should work - but I don''t want to break production - so.. There are several firewalls involved, but I can open 8140 as needed. So if I have a master server in one subnet and a client/master in another net - here is what I am thinking. The first master is well protected, call it "A" and the 2nd is "B" which has both the client and Master server on it. I want the B client to point to A-master and be able to get updated files. But as those files are updated on B, the B-Master will service those same groups of files/configs, etc, out to a whole other group of clients.. Any issues or problems with this that anyone can think of? The reason for this is simple - the "B" Master is the only one who has access to a whole bunch of clients on the other side, but A has to get files from it''s protected subnets and push them out to B.. Ok, my head hurts now.. ~J~ -- 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 16, 2010, at 10:56 AM, Jewels wrote:> I think this should work - but I don''t want to break production - so.. > > There are several firewalls involved, but I can open 8140 as needed. > So if I have a master server in one subnet and a client/master in > another net - here is what I am thinking. > > The first master is well protected, call it "A" and the 2nd is "B" > which has both the client and Master server on it. I want the B client > to point to A-master and be able to get updated files. But as those > files are updated on B, the B-Master will service those same groups of > files/configs, etc, out to a whole other group of clients.. > > Any issues or problems with this that anyone can think of?Basically, it won''t work with a stock install without some tweaking. A client and server can not share a ssldir unless they share a CA. A simple solution is to define ssldir to be /var/lib/puppet/client_ssl in [puppetd] and /var/lib/puppet/server_ssl in [puppetmasterd]. -- 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 Thu, Sep 16, 2010 at 6:03 PM, Patrick <kc7zzv@gmail.com> wrote:> > On Sep 16, 2010, at 10:56 AM, Jewels wrote: > >> I think this should work - but I don''t want to break production - so.. >> >> There are several firewalls involved, but I can open 8140 as needed. >> So if I have a master server in one subnet and a client/master in >> another net - here is what I am thinking. >> >> The first master is well protected, call it "A" and the 2nd is "B" >> which has both the client and Master server on it. I want the B client >> to point to A-master and be able to get updated files. But as those >> files are updated on B, the B-Master will service those same groups of >> files/configs, etc, out to a whole other group of clients.. >> >> Any issues or problems with this that anyone can think of? > > Basically, it won''t work with a stock install without some tweaking. A client and server can not share a ssldir unless they share a CA. A simple solution is to define ssldir to be /var/lib/puppet/client_ssl in [puppetd] and /var/lib/puppet/server_ssl in [puppetmasterd].I reckon that if you''re doing this, you may as well set up an entirely new $vardir for the puppetmaster. I take it you''re going to be doing lots of recursive file copies from "A" to "B" which will then serve them as puppet manifests ? What''s the actual problem you''re trying to solve with this? -- 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.