On Tue, Jun 30, 2009 at 2:03 PM, engle<kurt.en...@gmail.com> wrote: > > Well, that is what we are doing right now. However, when dealing with > potentially hundred of machines, this gets a little awkward and > unmanageable. We are a school district and spend most of the summer > imaging hundreds of Macs. This is the case every summer. As these > machines change their function during the year, they will have to be > re-imaged thus prompting action on the cert. If we could just image > them with a cert already installed, then there would be no issue.
Why can't you do this? Pre-generate all the certs, and add them in as part of your imaging process? Alternatively, stop the mapping between serial and certname, and use a UUID or something for the certname, and work out some way of cleaning out your obsolete certificates. > > The timing of when a device gets re-imaged and when the cert is > deleted is key and hard to achieve in our environment. We do not have > the expertise throughout our staff to allow a sudo operation to delete > the cert. > > What is the process of using a common cert on all the puppet clients? > I would like to test this out to see if it would work for our > environment. > > Thanks > > -kurt > > On Jun 30, 11:36 am, Mike Renfro <ren...@tntech.edu> wrote: >> On 6/30/2009 1:26 PM, engle wrote: >> >> > So, would it be best to use a single cert for all of the clients or is >> > there a better way to deal with this sort of setup? >> >> Run >> >> puppetca --clean host.to.be.imaged >> >> on the puppetmaster as it's being imaged? If you're doing the reimaging, >> should just be one extra step in your procedure. If you're not the one >> doing the reimaging, can you set up a sudo entry on the puppetmaster to >> allow the other folks to clean old certs? Or set up a simple web form to >> clean a particular cert? >> >> Other than that, I guess another option would be to save the puppet ssl >> directory before the client drive gets reformatted, and restore it back >> to the drive before puppet starts up again. >> >> I'd be wary of using the same certs on multiple systems unless they were >> in an isolated environment (and possibly even then). Same reason as for >> not using the same ssh host key for all your systems. >> >> -- >> Mike Renfro / R&D Engineer, Center for Manufacturing Research, >> 931 372-3601 / Tennessee Technological University > > > -- Nigel Kersten nig...@google.com System Administrator Google, Inc. --~--~---------~--~----~------------~-------~--~----~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---