Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I just want to throw this question out there.

I have 2 geographical locations, A and B. There is an OOB network that connects A and B together, that is management devices in location A can ping management devices in location B and vice versa. Each location has a production network. However the production network in location A cannot ping management devices in location B and production devices in location B cannot ping management devices in location A.

I am implementing puppet, and have a question around the architecture. I am thinking about having a puppet master in Location A and a puppet slave in location B. I would like 1 management dashboard which will give me visibility of all nodes in both production networks. I would want the puppet clients in location A which are in the production network to be able to only speak with the puppet master in location A and the puppet clients in location B which are in the production network to only speak with the puppet slave in location B.

I am assuming this in fact is fairly easy to set up. I would make the client puppet.conf file pint to the correct location, and as the puppet servers are in a master slave setup, the dashboard will be able to grab the data from both servers and collate all the information into the one dashboard.

Will this work?

share|improve this question

1 Answer 1

up vote 0 down vote accepted

It's harder to implement than it really ought to be, but it's definitely possible to centralize your manifests, modules, certificate authority, and dashboard functions without requiring the client nodes to ever communicate with the "central" puppet master.

  • Centralize your manifests and modules using a version control system, keeping it synchronized on both puppet master servers.
  • Certificate API requests from the clients in site B will need to be proxied by the site B puppet master over to the site A puppet master, as it will be the central certificate authority.
  • Site B's puppet master should be configured to send run reports over to the Dashboard service on the Site A master (and optionally inventory data to a central inventory service to make it accessible in the dashboard).

Much of the same ground is covered in further detail by my answer here, as well.

It's a bit of a daunting task to configure all of this to work seamlessly, but you should be able to get there - let me know what questions you have about what's needed.

share|improve this answer
    
Cool - sorry for the late reply and thanks for the answer. I am currently setting this up and finding it really difficult. Many problems and many issues that need to be resolved. For example, I could not get puppet-server 3.0.1 & passenger 3.0.18 to work with ruby 1.9.3 and could with 1.8.7. I cannot get multiple puppet masters set up as I am hitting issues with CA set up. I am following the documentation but it's very pieced together. I came across your post earlier. I am going to use this forum to see if I can make any progress. Cheers - Oli –  Oli Dec 13 '12 at 18:24

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.