On Tuesday, July 15, 2014 2:09:57 PM UTC-5, randal cobb wrote: > > Hello, all... > > I have a scenario where all of our developers (spread geographically > around the world) use a VMWare or VirtualBox VM on their local desktop to > develop portions of a single product. I've seemed to inherit this > nightmare of a process and believe I can make it much simpler, quicker, and > cleaner using Puppet. Currently, they have to download an 80Gb VM image > from a single server in the US; so, because of the massive size of the VM, > most developers never upgrade their VMs to the latest image. I know that > Puppet can fix this for me, but I have a few questions I'm hoping y'all can > help answer (I've used puppet for a few months to manage some > infrastructure servers, so concepts aren't alien to me). Here are my > questions: > > Supposed I have 200 different machines (VMs) sitting on each developer's > desktop (rather in their VMware hypervisor)... > 1) can they all have the same certname, so I only have to maintain a > single node.pp manifest? >
Yes, they can. I'm doubtful of the wisdom of this idea, but there is no actual constraint against nodes using the same cert. As far as the master is concerned, all the machines using that cert are the same machine. With that said, it is by no means necessary for nodes to share identities in order to share configuration. There are multiple ways to make all your machines share the same node block -- for instance, you can give them distinct certnames that fit a consistent pattern, so that you can use a regex node name to match them all. Or you could use the 'default' node block to match them all. Or if you're serving *only* these machines then you don't actually need node blocks at all -- just put all the declarations at the top level of site.pp. > 2) If so, how are SSL certs maintained, given there would be 200 different > VMs trying to use the same set of certs. Or, does that even matter from a > node perspective? > If you want the VMs to share certs, then you would set it up in the master VM image. Then people would automatically get it with the VM. There are alternatives, but none that I would recommend. > 3) If not, do I REALLY have to maintain 200 different manifests; all > identical to each other? > No. See above. > > I've been able to put together a single node.pp file that sets up > everything for them, so they only download a 2.8Gb bare VM image and puppet > does the rest. But, when firing up subsequent VMs, of course the client > gets all confused because the generated certs don't match up. > > As I said, you can set up Puppet inside the master VM image, certs and all. Then it won't generate new certs. This is a pretty natural approach, provided that you actually want all the VM instances to share certs. If you don't want that, then you probably need to ensure that every VM instance uses a distinct certname. There is a config setting where by which you can specify which certname that instance should use. The default is to use the machine's hostname, but if cloning a VM results in an instance with the same hostname then you must ensure either that they share a cert or that they use different certnames. > Any suggestions for a better solution, or workaround to this one? (I've > thought about using NAT and a fixed MAC address, but with so many > developers out there, I'm sure some will re-create MAC addresses at some > point during their initial setup, or change their networking type for the > VM and start flooding the network with duplicated mac errors). > > Use UUIDs for certnames if there's nothing else you can be confident will be unique. Set up a UUID server if need be, though you could probably just distribute a little UUID generator instead of centralizing. John -- 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/af74bbd4-fd8c-42af-9c01-eb90bc11a753%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
