I am trying to come up with a workable solution in managing numerous Mac workstations allowing a high degree of flexibility with regards to certs. My puppet environment is setup to application installation on machines that have been ''imaged'' with a base OS and the puppet and facter apps. So, when a Mac is ''imaged'' and subsequently re-booted, puppet is run at startup, a cert is created and autosigned (I know that is not recommended...but...) and queries are performed on our LDAP database and apps are installed based upon the Mac''s membership in various groups. My issue is with machines that need to be re-imaged. I am not real well versed on how certs and CA''s function, but the newly imaged device fails to get a new cert from the CA(puppetmaster) and the CA complains that it has a cert for the device that does not match the request. 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? Thanks for any replies, Kurt Engle --~--~---------~--~----~------------~-------~--~----~ 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 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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
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. 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--~--~---------~--~----~------------~-------~--~----~ 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 Tue, Jun 30, 2009 at 2:03 PM, engle<kurt.engle@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 nigelk@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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Pre-generating all the certs would be very time consuming with hundreds of machines to deal with. Also, we would need to create a specific image for each machine which would be an even bigger nightmare from my understanding. We used the serial number as the hostname since the serial number on the device does not change. Uuidgen generates a new string each time it is run. What I am trying to accomplish is the ability to have a device communicate with the puppetmaster server without need of intervention from me. I need to be able to have a tech at a remote location completely re-image a device and run puppet without having to wait for me do do something with the certs. Is there a way to install a ''generic'' cert on all the clients that I can make part of my image so that no matter what happens to the client, it will always have the correct cert? -kurt On Tue, Jun 30, 2009 at 2:24 PM, Nigel Kersten <nigelk@google.com> wrote:> > On Tue, Jun 30, 2009 at 2:03 PM, engle<kurt.engle@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 > nigelk@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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Tue, Jun 30, 2009 at 3:19 PM, Kurt Engle<kurt.engle@gmail.com> wrote:> Pre-generating all the certs would be very time consuming with hundreds of > machines to deal with. Also, we would need to create a specific image for > each machine which would be an even bigger nightmare from my understanding.No. I''m suggesting that you hook this in as a post-action for your imaging process. Simple to do with NetRestore or DeployStudio or any of the common Mac imaging programs. If you already have an asset database, you could query serials there and pre-generate them regularly on your CA. It''s not a time consuming process at all to generate hundreds of certs.> We used the serial number as the hostname since the serial number on the > device does not change. Uuidgen generates a new string each time it is run. > > What I am trying to accomplish is the ability to have a device communicate > with the puppetmaster server without need of intervention from me. I need to > be able to have a tech at a remote location completely re-image a device and > run puppet without having to wait for me do do something with the certs. > > Is there a way to install a ''generic'' cert on all the clients that I can > make part of my image so that no matter what happens to the client, it will > always have the correct cert?Why not switch your CA to autosign then? It sounds like you''re needing to subvert the cert signing process. The best solution is going to depend a lot on your imaging process. How is it currently done?> > -kurt > > On Tue, Jun 30, 2009 at 2:24 PM, Nigel Kersten <nigelk@google.com> wrote: >> >> On Tue, Jun 30, 2009 at 2:03 PM, engle<kurt.engle@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 >> nigelk@google.com >> System Administrator >> Google, Inc. >> >> > > > > >-- Nigel Kersten nigelk@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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Nigel, part of the problem is that I do not have a good understanding of what happens during the whole cert process and what will break or make a trust between the client and the server. Our imaging process takes an OS base image with a few apps that include Puppet and Facter and installs it on the make. This over the network. When the Mac reboots it sets the hostname of the computer to the Mac''s serial number and auto starts puppet. I do have my puppetmaster (CA) set to autosign certs iliminating my intervention. This process is working well. The issue comes up when I have to re-image a device. The client is wiped completely and everything including puppet is re-installed. However, if I don''t clear the cert on the puppetmaster, the communication fails when the device comes back on-line. It seems that if I could create a ''generic'' cert and make it part of the image and instruct the puppet client to always use this cert, then it would not matter if the client was re-imaged or not. Correct? Or am I missing something? Then I could also turn off the ''autosign'' function and then only the machines that I have imaged with the generic cert would be able to talk to the puppetmaster. Thanks for your replies and help with this. -kurt On Tue, Jun 30, 2009 at 3:25 PM, Nigel Kersten <nigelk@google.com> wrote:> > On Tue, Jun 30, 2009 at 3:19 PM, Kurt Engle<kurt.engle@gmail.com> wrote: > > Pre-generating all the certs would be very time consuming with hundreds > of > > machines to deal with. Also, we would need to create a specific image for > > each machine which would be an even bigger nightmare from my > understanding. > > No. I''m suggesting that you hook this in as a post-action for your > imaging process. Simple to do with NetRestore or DeployStudio or any > of the common Mac imaging programs. > > If you already have an asset database, you could query serials there > and pre-generate them regularly on your CA. It''s not a time consuming > process at all to generate hundreds of certs. > > > > We used the serial number as the hostname since the serial number on the > > device does not change. Uuidgen generates a new string each time it is > run. > > > > What I am trying to accomplish is the ability to have a device > communicate > > with the puppetmaster server without need of intervention from me. I need > to > > be able to have a tech at a remote location completely re-image a device > and > > run puppet without having to wait for me do do something with the certs. > > > > Is there a way to install a ''generic'' cert on all the clients that I can > > make part of my image so that no matter what happens to the client, it > will > > always have the correct cert? > > Why not switch your CA to autosign then? It sounds like you''re needing > to subvert the cert signing process. > > The best solution is going to depend a lot on your imaging process. > How is it currently done? > > > > > -kurt > > > > On Tue, Jun 30, 2009 at 2:24 PM, Nigel Kersten <nigelk@google.com> > wrote: > >> > >> On Tue, Jun 30, 2009 at 2:03 PM, engle<kurt.engle@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 > >> nigelk@google.com > >> System Administrator > >> Google, Inc. > >> > >> > > > > > > > > > > > > > -- > Nigel Kersten > nigelk@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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Tue, Jun 30, 2009 at 6:36 PM, Kurt Engle<kurt.engle@gmail.com> wrote:> Our imaging process takes an OS base image with a few apps that include > Puppet and Facter and installs it on the make. This over the network. When > the Mac reboots it sets the hostname of the computer to the Mac''s serial > number and auto starts puppet. I do have my puppetmaster (CA) set to > autosign certs iliminating my intervention. This process is working well.What if you add an ssh key to the base OS image, and a script to be run that contacts the puppet server using the ssh key, and clears any cert that may exist for that client. (It could also add the newly created cert..) You can set the ssh server to recognize that when that key (from the base image) is used, the only command that may be run is /usr/sbin/puppetca. That way, when the machine is reimaged, after its first boot it takes care of the certification issue. Then, once puppet is running on the machine, you could have it remove the ssh key and the startup script. --~--~---------~--~----~------------~-------~--~----~ 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 Tue, Jun 30, 2009 at 4:32 PM, Michael Semcheski<mhsemcheski@gmail.com> wrote:> > On Tue, Jun 30, 2009 at 6:36 PM, Kurt Engle<kurt.engle@gmail.com> wrote: >> Our imaging process takes an OS base image with a few apps that include >> Puppet and Facter and installs it on the make. This over the network. When >> the Mac reboots it sets the hostname of the computer to the Mac''s serial >> number and auto starts puppet. I do have my puppetmaster (CA) set to >> autosign certs iliminating my intervention. This process is working well. > > What if you add an ssh key to the base OS image, and a script to be > run that contacts the puppet server using the ssh key, and clears any > cert that may exist for that client. (It could also add the newly > created cert..) You can set the ssh server to recognize that when > that key (from the base image) is used, the only command that may be > run is /usr/sbin/puppetca. > > That way, when the machine is reimaged, after its first boot it takes > care of the certification issue. Then, once puppet is running on the > machine, you could have it remove the ssh key and the startup script.I like this idea. You could even turn off autosign then. -- Nigel Kersten nigelk@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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Thanks for the suggestions. Wouldn''t I achieve the same outcome with using a single cert for all machines without the need for special scripts to delete certs from the server and delete files from the client? Also, with respect to autosign... would I really be able to turn it off using the SSH method below? Doesn''t the client still have to ask the server for a cert after it has been re-imaged? With a single cert, it seems that the client would already have a cert that I have distributed with the image and therefore, would not have to ask for a cert and autosign could be turned off. -kurt On Tue, Jun 30, 2009 at 4:47 PM, Nigel Kersten <nigelk@google.com> wrote:> > On Tue, Jun 30, 2009 at 4:32 PM, Michael Semcheski<mhsemcheski@gmail.com> > wrote: > > > > On Tue, Jun 30, 2009 at 6:36 PM, Kurt Engle<kurt.engle@gmail.com> wrote: > >> Our imaging process takes an OS base image with a few apps that include > >> Puppet and Facter and installs it on the make. This over the network. > When > >> the Mac reboots it sets the hostname of the computer to the Mac''s serial > >> number and auto starts puppet. I do have my puppetmaster (CA) set to > >> autosign certs iliminating my intervention. This process is working > well. > > > > What if you add an ssh key to the base OS image, and a script to be > > run that contacts the puppet server using the ssh key, and clears any > > cert that may exist for that client. (It could also add the newly > > created cert..) You can set the ssh server to recognize that when > > that key (from the base image) is used, the only command that may be > > run is /usr/sbin/puppetca. > > > > That way, when the machine is reimaged, after its first boot it takes > > care of the certification issue. Then, once puppet is running on the > > machine, you could have it remove the ssh key and the startup script. > > I like this idea. You could even turn off autosign then. > > > > -- > Nigel Kersten > nigelk@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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Wed, Jul 1, 2009 at 9:02 AM, Kurt Engle<kurt.engle@gmail.com> wrote:> Thanks for the suggestions. > > Wouldn''t I achieve the same outcome with using a single cert for all > machines without the need for special scripts to delete certs from the > server and delete files from the client?I like being able to still revoke an individual certificate centrally.> Also, with respect to autosign... > would I really be able to turn it off using the SSH method below? Doesn''t > the client still have to ask the server for a cert after it has been > re-imaged? With a single cert, it seems that the client would already have a > cert that I have distributed with the image and therefore, would not have to > ask for a cert and autosign could be turned off. >I think the plan would be to ship an ssh key on the image and do: * ssh to puppet CA, generate cert * copy certificate(s) to client Then the client wouldn''t need to ask for a certificate.> -kurt > > > On Tue, Jun 30, 2009 at 4:47 PM, Nigel Kersten <nigelk@google.com> wrote: >> >> On Tue, Jun 30, 2009 at 4:32 PM, Michael Semcheski<mhsemcheski@gmail.com> >> wrote: >> > >> > On Tue, Jun 30, 2009 at 6:36 PM, Kurt Engle<kurt.engle@gmail.com> wrote: >> >> Our imaging process takes an OS base image with a few apps that include >> >> Puppet and Facter and installs it on the make. This over the network. >> >> When >> >> the Mac reboots it sets the hostname of the computer to the Mac''s >> >> serial >> >> number and auto starts puppet. I do have my puppetmaster (CA) set to >> >> autosign certs iliminating my intervention. This process is working >> >> well. >> > >> > What if you add an ssh key to the base OS image, and a script to be >> > run that contacts the puppet server using the ssh key, and clears any >> > cert that may exist for that client. (It could also add the newly >> > created cert..) You can set the ssh server to recognize that when >> > that key (from the base image) is used, the only command that may be >> > run is /usr/sbin/puppetca. >> > >> > That way, when the machine is reimaged, after its first boot it takes >> > care of the certification issue. Then, once puppet is running on the >> > machine, you could have it remove the ssh key and the startup script. >> >> I like this idea. You could even turn off autosign then. >> >> >> >> -- >> Nigel Kersten >> nigelk@google.com >> System Administrator >> Google, Inc. >> >> > > > > >-- Nigel Kersten nigelk@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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Wed, Jul 1, 2009 at 12:02 PM, Kurt Engle<kurt.engle@gmail.com> wrote:> Wouldn''t I achieve the same outcome with using a single cert for all > machines without the need for special scripts to delete certs from the > server and delete files from the client? Also, with respect to autosign... > would I really be able to turn it off using the SSH method below?The client creates a cert and then gives it to the server. You tell the server to authorize it or not. But that process doesn''t necessarilly require manual intervention. It is very scriptable. The ssh method I described would be able to do all of that, and it would probably be simpler to implement than you realize, assuming the freshly imaged machines could ssh to the puppetmaster. The script would be something like this... HOSTNAME=`hostname -f` ssh puppetmaster "/usr/sbin/puppetca --clear $HOSTNAME" puppetd -w 90 ssh puppetmaster "/usr/sbin/puppetca -s $HOSTNAME" Then add a module that removes that script from the machine. In the example I gave above, I can''t remember the specific options that puppetca requires, but I think its close. Again, all you need to do is add the ssh key to the base image, and add it to the authorized_keys on the puppetmaster. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
I''m about to deal with the same issue. This certainly isn''t a Mac only issue. The way I see it a "puppetca --clean <machineName> needs to be executed on the server. I figure either a puppet admin has to do it, which it labor intensive, or a script can do it. I haven''t figured out a way for the script to know which certs to clear though. I was thinking of setting up an authenticated web page that would allow field techs to submit a FQDN to a list, then a cron job on the server would check the list every X minutes and clear those certs. What do other shops do? Please let us know. --- Thanks, Allan Marcus 505-667-5666 On Jun 30, 2009, at 12:26 PM, engle wrote:> > I am trying to come up with a workable solution in managing numerous > Mac workstations allowing a high degree of flexibility with regards to > certs. > > My puppet environment is setup to application installation on machines > that have been ''imaged'' with a base OS and the puppet and facter apps. > So, when a Mac is ''imaged'' and subsequently re-booted, puppet is run > at startup, a cert is created and autosigned (I know that is not > recommended...but...) and queries are performed on our LDAP database > and apps are installed based upon the Mac''s membership in various > groups. > > My issue is with machines that need to be re-imaged. I am not real > well versed on how certs and CA''s function, but the newly imaged > device fails to get a new cert from the CA(puppetmaster) and the CA > complains that it has a cert for the device that does not match the > request. > > 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? > > Thanks for any replies, > > Kurt Engle > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Well, the suggestion to have the client do it via a SSH command is a good one and is working for me. Thanks to Michael and Nigel for pointing me in this direction. I just need to formalize the process in my environment. However (there is always a however). I am still a little shaky on the whole cert process. One thing that I have noticed is that I can run a ''puppetca -c <host>'' on the server, but the client <host> is still able to communicate with the server and get its catalog. I do not understand how that could be. -kurt On Thu, Jul 2, 2009 at 8:56 AM, Allan Marcus <allan@lanl.gov> wrote:> > I''m about to deal with the same issue. This certainly isn''t a Mac only > issue. > > The way I see it a "puppetca --clean <machineName> needs to be > executed on the server. > > I figure either a puppet admin has to do it, which it labor intensive, > or a script can do it. I haven''t figured out a way for the script to > know which certs to clear though. I was thinking of setting up an > authenticated web page that would allow field techs to submit a FQDN > to a list, then a cron job on the server would check the list every X > minutes and clear those certs. > > What do other shops do? Please let us know. > > --- > Thanks, > > Allan Marcus > 505-667-5666 > > > > On Jun 30, 2009, at 12:26 PM, engle wrote: > > > > > I am trying to come up with a workable solution in managing numerous > > Mac workstations allowing a high degree of flexibility with regards to > > certs. > > > > My puppet environment is setup to application installation on machines > > that have been ''imaged'' with a base OS and the puppet and facter apps. > > So, when a Mac is ''imaged'' and subsequently re-booted, puppet is run > > at startup, a cert is created and autosigned (I know that is not > > recommended...but...) and queries are performed on our LDAP database > > and apps are installed based upon the Mac''s membership in various > > groups. > > > > My issue is with machines that need to be re-imaged. I am not real > > well versed on how certs and CA''s function, but the newly imaged > > device fails to get a new cert from the CA(puppetmaster) and the CA > > complains that it has a cert for the device that does not match the > > request. > > > > 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? > > > > Thanks for any replies, > > > > Kurt Engle > > > > > > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
It appears the ssh keys would have to be for the puppet user on the puppetmasterd server. How can I be assured that the key is not used for evil? Would I need to write a bunch of fugly stuff in my sshd_config to limit what the puppet user can do via the ssh command? any examples? --- Thanks, Allan Marcus 505-667-5666 On Jul 1, 2009, at 10:19 AM, Michael Semcheski wrote:> > On Wed, Jul 1, 2009 at 12:02 PM, Kurt Engle<kurt.engle@gmail.com> > wrote: >> Wouldn''t I achieve the same outcome with using a single cert for all >> machines without the need for special scripts to delete certs from >> the >> server and delete files from the client? Also, with respect to >> autosign... >> would I really be able to turn it off using the SSH method below? > > The client creates a cert and then gives it to the server. You tell > the server to authorize it or not. But that process doesn''t > necessarilly require manual intervention. It is very scriptable. > > The ssh method I described would be able to do all of that, and it > would probably be simpler to implement than you realize, assuming the > freshly imaged machines could ssh to the puppetmaster. > > The script would be something like this... > > HOSTNAME=`hostname -f` > ssh puppetmaster "/usr/sbin/puppetca --clear $HOSTNAME" > puppetd -w 90 > ssh puppetmaster "/usr/sbin/puppetca -s $HOSTNAME" > > > Then add a module that removes that script from the machine. > > In the example I gave above, I can''t remember the specific options > that puppetca requires, but I think its close. > > Again, all you need to do is add the ssh key to the base image, and > add it to the authorized_keys on the puppetmaster. > > >--~--~---------~--~----~------------~-------~--~----~ 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, Jul 2, 2009 at 12:21 PM, Allan Marcus<allan@lanl.gov> wrote:> Would I need to write a bunch of fugly stuff in my sshd_config to > limit what the puppet user can do via the ssh command? any examples?You put the client''s key in /root/.ssh/authorized_keys. All you need to do is prepend this to it: command="/usr/sbin/puppetca",no-pty,no-port-forwarding Check the documentation for your version of sshd to be sure. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
nice! Would this directive also stop scp, sftp, or anything else I can''t think of? --- Thanks, Allan Marcus 505-667-5666 On Jul 2, 2009, at 10:24 AM, Michael Semcheski wrote:> > On Thu, Jul 2, 2009 at 12:21 PM, Allan Marcus<allan@lanl.gov> wrote: >> Would I need to write a bunch of fugly stuff in my sshd_config to >> limit what the puppet user can do via the ssh command? any examples? > > You put the client''s key in /root/.ssh/authorized_keys. All you need > to do is prepend this to it: > > command="/usr/sbin/puppetca",no-pty,no-port-forwarding > > Check the documentation for your version of sshd to be sure. > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
What about just running a "puppetca --clean --all" every night? Not pretty, but would it work? -Allan --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
from what I can tell, this is almost a great idea, except that by using the command="/usr/sbin/puppetca", we would be ignoring any command passed to the ssh session. The best I can figure there would be no way to restrict the ssh session to just the puppetca command and pass the certname to the server to get cleaned up. I really like the idea of the client sending a request to clean its own cert, but I don''t see how it can work using ssh and still have a secure server. Alternatively, I''m thinking the client script could send an http request (via CURL) to to server. The server then has a simple PHP script that writes the sender''s hostname to a file on the server with the hostname as the name of the file. A launchd job simply watches the dir where the files are written and executes a command to clean the cert and delete the file. A little more complicated, but much more secure. --- Thanks, Allan Marcus 505-667-5666 On Jul 2, 2009, at 10:24 AM, Michael Semcheski wrote:> > On Thu, Jul 2, 2009 at 12:21 PM, Allan Marcus<allan@lanl.gov> wrote: >> Would I need to write a bunch of fugly stuff in my sshd_config to >> limit what the puppet user can do via the ssh command? any examples? > > You put the client''s key in /root/.ssh/authorized_keys. All you need > to do is prepend this to it: > > command="/usr/sbin/puppetca",no-pty,no-port-forwarding > > Check the documentation for your version of sshd to be sure. > > >--~--~---------~--~----~------------~-------~--~----~ 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, Jul 2, 2009 at 1:29 PM, Allan Marcus<allan@lanl.gov> wrote:> from what I can tell, this is almost a great idea, except that by > using the command="/usr/sbin/puppetca", we would be ignoring any > command passed to the ssh session. The best I can figure there would > be no way to restrict the ssh session to just the puppetca command and > pass the certname to the server to get cleaned up.Look at the documentation for sshd again. What we''re doing is saying "if this key is used to start an ssh session, don''t run anything except the command listed here." --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
I love where this thread is going, I too share in this problem. Kurt: Puppet is still being run on the client because the client is using a cached config (am I right on this guys?). I love the scripted ssh key, but ALSO love the PHP script that could be CURL-ed from the client. Will a PHP script be able to capture the hostname of a connecting client? From there, the php script could call puppetca to clean the cert and create a new one...would this be cleaner than bundling a cert with your base-image? Unfortunately, I''m not that versed in PHP to hash a script out from scratch. Does anyone have a rough outline that we could steal? -Gary --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Gary Larizza wrote:> I love where this thread is going, I too share in this problem. > > Kurt: Puppet is still being run on the client because the client is > using a cached config (am I right on this guys?). > > I love the scripted ssh key, but ALSO love the PHP script that could > be CURL-ed from the client. Will a PHP script be able to capture the > hostname of a connecting client? From there, the php script could > call puppetca to clean the cert and create a new one...would this be > cleaner than bundling a cert with your base-image? Unfortunately, I''m > not that versed in PHP to hash a script out from scratch. Does anyone > have a rough outline that we could steal? >Also be great if this discussion and any resulting configuration or code could end up on the wiki somewhere too... Regards James Turnbull -- Author of: * Pro Linux Systems Administration (http://tinyurl.com/linuxadmin) * Pulling Strings with Puppet (http://tinyurl.com/pupbook) * Pro Nagios 2.0 (http://tinyurl.com/pronagios) * Hardening Linux (http://tinyurl.com/hardeninglinux)
I am currently working on doing a very similar thing with kickstart. There are two ways you can deal with the hostname... have PHP do an nslookup for the ipaddress that is connecting (prefered for security reasons), or just pass it as an argument to the PHP script. Chris On Jul 3, 2009, at 6:12 AM, Gary Larizza wrote:> > I love where this thread is going, I too share in this problem. > > Kurt: Puppet is still being run on the client because the client is > using a cached config (am I right on this guys?). > > I love the scripted ssh key, but ALSO love the PHP script that could > be CURL-ed from the client. Will a PHP script be able to capture the > hostname of a connecting client? From there, the php script could > call puppetca to clean the cert and create a new one...would this be > cleaner than bundling a cert with your base-image? Unfortunately, I''m > not that versed in PHP to hash a script out from scratch. Does anyone > have a rough outline that we could steal? > > -Gary > >--~--~---------~--~----~------------~-------~--~----~ 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 Jul 3, 12:51 pm, Christopher Webber <kgbbelm...@gmail.com> wrote:> I am currently working on doing a very similar thing with kickstart. > There are two ways you can deal with the hostname... have PHP do an > nslookup for the ipaddress that is connecting (prefered for security > reasons), or just pass it as an argument to the PHP script. > > Chrisnslookup wouldn''t work if you''re talking about clients that AREN''T listed in dns...such as lab machines or the like. I see what you mean, though - there are other methods for pulling that data. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
here you go, its fetched from a much bigger website, so I didnt really test it, but worth a shot :) http://gist.github.com/140457 cheers, Ohad On Fri, Jul 3, 2009 at 9:12 PM, Gary Larizza <glarizza@mac.com> wrote:> > I love where this thread is going, I too share in this problem. > > Kurt: Puppet is still being run on the client because the client is > using a cached config (am I right on this guys?). > > I love the scripted ssh key, but ALSO love the PHP script that could > be CURL-ed from the client. Will a PHP script be able to capture the > hostname of a connecting client? From there, the php script could > call puppetca to clean the cert and create a new one...would this be > cleaner than bundling a cert with your base-image? Unfortunately, I''m > not that versed in PHP to hash a script out from scratch. Does anyone > have a rough outline that we could steal? > > -Gary > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
How does the cgi script execute a sudo? --- Thanks, Allan Marcus 505-667-5666 On Jul 3, 2009, at 11:10 PM, Ohad Levy wrote:> here you go, its fetched from a much bigger website, so I didnt > really test it, but worth a shot :) > > http://gist.github.com/140457 > > cheers, > Ohad > > On Fri, Jul 3, 2009 at 9:12 PM, Gary Larizza <glarizza@mac.com> wrote: > > I love where this thread is going, I too share in this problem. > > Kurt: Puppet is still being run on the client because the client is > using a cached config (am I right on this guys?). > > I love the scripted ssh key, but ALSO love the PHP script that could > be CURL-ed from the client. Will a PHP script be able to capture the > hostname of a connecting client? From there, the php script could > call puppetca to clean the cert and create a new one...would this be > cleaner than bundling a cert with your base-image? Unfortunately, I''m > not that versed in PHP to hash a script out from scratch. Does anyone > have a rough outline that we could steal? > > -Gary > > > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
cgi runs with the user which runs the web server, so for example if you use apache, give sudo rights to apache account to execute puppetca. Ohad On 7/6/09, Allan Marcus <allan@lanl.gov> wrote:> > How does the cgi script execute a sudo? > > --- > Thanks, > > Allan Marcus > 505-667-5666 > > > > On Jul 3, 2009, at 11:10 PM, Ohad Levy wrote: > >> here you go, its fetched from a much bigger website, so I didnt >> really test it, but worth a shot :) >> >> http://gist.github.com/140457 >> >> cheers, >> Ohad >> >> On Fri, Jul 3, 2009 at 9:12 PM, Gary Larizza <glarizza@mac.com> wrote: >> >> I love where this thread is going, I too share in this problem. >> >> Kurt: Puppet is still being run on the client because the client is >> using a cached config (am I right on this guys?). >> >> I love the scripted ssh key, but ALSO love the PHP script that could >> be CURL-ed from the client. Will a PHP script be able to capture the >> hostname of a connecting client? From there, the php script could >> call puppetca to clean the cert and create a new one...would this be >> cleaner than bundling a cert with your base-image? Unfortunately, I''m >> not that versed in PHP to hash a script out from scratch. Does anyone >> have a rough outline that we could steal? >> >> -Gary >> >> >> >> > > > > > >-- Sent from my mobile device --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
ok, makes sense. If I did this, would I need the -S in the sudo command? --- Thanks, Allan Marcus 505-667-5666 On Jul 6, 2009, at 8:41 AM, Ohad Levy wrote:> > cgi runs with the user which runs the web server, so for example if > you use apache, give sudo rights to apache account to execute > puppetca. > > Ohad > > On 7/6/09, Allan Marcus <allan@lanl.gov> wrote: >> >> How does the cgi script execute a sudo? >> >> --- >> Thanks, >> >> Allan Marcus >> 505-667-5666 >> >> >> >> On Jul 3, 2009, at 11:10 PM, Ohad Levy wrote: >> >>> here you go, its fetched from a much bigger website, so I didnt >>> really test it, but worth a shot :) >>> >>> http://gist.github.com/140457 >>> >>> cheers, >>> Ohad >>> >>> On Fri, Jul 3, 2009 at 9:12 PM, Gary Larizza <glarizza@mac.com> >>> wrote: >>> >>> I love where this thread is going, I too share in this problem. >>> >>> Kurt: Puppet is still being run on the client because the client is >>> using a cached config (am I right on this guys?). >>> >>> I love the scripted ssh key, but ALSO love the PHP script that could >>> be CURL-ed from the client. Will a PHP script be able to capture >>> the >>> hostname of a connecting client? From there, the php script could >>> call puppetca to clean the cert and create a new one...would this be >>> cleaner than bundling a cert with your base-image? Unfortunately, >>> I''m >>> not that versed in PHP to hash a script out from scratch. Does >>> anyone >>> have a rough outline that we could steal? >>> >>> -Gary >>> >>> >>> >>>> >> >> >>> >> > > -- > Sent from my mobile device > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
So are you wanting the cert cleaning and creation to happen everytime a client contacts the puppetmaster? What I am looking for is a script that will run on a newly imaged client that run at bootup before the puppetd process is started. That script would delete any cert on the puppetmaster and then the script would delete itself on the client. The issue that I am having is with clients that have been using puppet but are then ''re-imaged''. Once a device is running puppet, it works fine unless it is re-imaged. This seems like a more elegant solution in my environment than trying to do this on the puppet server side of things. Besides, doesn''t the client need to us its cert to talk to the server in the first place? If that cert is ''bad'' then how would it talk to the puppetmaster server and have the server delete its bad key? Now, anybody have any good resources for writing startup scripts on a Mac client? I seem to be having problems getting a script that runs fine on the command line to work at startup. -kurt On Fri, Jul 3, 2009 at 6:12 AM, Gary Larizza <glarizza@mac.com> wrote:> > I love where this thread is going, I too share in this problem. > > Kurt: Puppet is still being run on the client because the client is > using a cached config (am I right on this guys?). > > I love the scripted ssh key, but ALSO love the PHP script that could > be CURL-ed from the client. Will a PHP script be able to capture the > hostname of a connecting client? From there, the php script could > call puppetca to clean the cert and create a new one...would this be > cleaner than bundling a cert with your base-image? Unfortunately, I''m > not that versed in PHP to hash a script out from scratch. Does anyone > have a rough outline that we could steal? > > -Gary > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
As I understand it, if the client has a new set of certs, when the client talks to the server the server will reject the client since the certs on the client don''t match what the server signed. The answer when the client has a new set of certs is to run a puppetca --clean <certName> on the server (as root). This is why you need something on the server. As an aside, I''m happy to help you with your Mac script issue. Contact me directly. Send me yoru script and how you are running it. Ideally you are using a run at load launchd job. the more I think about it, the more I am convinced that using the Mac''s serial number is the least worst option for cert name. There is still the issue of the machine being reimaged that would require the cert to be cleaned on the server, but using the serial number would allow the host name to change and not screw up the store config DB. --- Thanks, Allan Marcus 505-667-5666 On Jul 8, 2009, at 2:18 PM, Kurt Engle wrote:> So are you wanting the cert cleaning and creation to happen > everytime a client contacts the puppetmaster? > > What I am looking for is a script that will run on a newly imaged > client that run at bootup before the puppetd process is started. > That script would delete any cert on the puppetmaster and then the > script would delete itself on the client. The issue that I am having > is with clients that have been using puppet but are then ''re- > imaged''. Once a device is running puppet, it works fine unless it is > re-imaged. > > This seems like a more elegant solution in my environment than > trying to do this on the puppet server side of things. Besides, > doesn''t the client need to us its cert to talk to the server in the > first place? If that cert is ''bad'' then how would it talk to the > puppetmaster server and have the server delete its bad key? > > Now, anybody have any good resources for writing startup scripts on > a Mac client? I seem to be having problems getting a script that > runs fine on the command line to work at startup. > > -kurt > > On Fri, Jul 3, 2009 at 6:12 AM, Gary Larizza <glarizza@mac.com> wrote: > > I love where this thread is going, I too share in this problem. > > Kurt: Puppet is still being run on the client because the client is > using a cached config (am I right on this guys?). > > I love the scripted ssh key, but ALSO love the PHP script that could > be CURL-ed from the client. Will a PHP script be able to capture the > hostname of a connecting client? From there, the php script could > call puppetca to clean the cert and create a new one...would this be > cleaner than bundling a cert with your base-image? Unfortunately, I''m > not that versed in PHP to hash a script out from scratch. Does anyone > have a rough outline that we could steal? > > -Gary > > > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Sorry, i didn''t mean the db for store configs. My issue with use FQDN is for machines that use dhcp and might not have the same host name, and when building a machine behind a router, in which case more than one machine might have the same host name. I''m not thinking of using the --fqdn switch (if I cannot use a fact in the certname directive of puppet.conf) to uniquely ID a machine. Still have the issue of cleaning the cert on server though. --- Thanks, Allan Marcus 505-667-5666 On Jul 8, 2009, at 5:54 PM, Allan Marcus wrote:> the more I think about it, the more I am convinced that using the > Mac''s serial number is the least worst option for cert name. There is > still the issue of the machine being reimaged that would require the > cert to be cleaned on the server, but using the serial number would > allow the host name to change and not screw up the store config DB. > > --- > Thanks, > > Allan Marcus > 505-667-5666 > > > > On Jul 8, 2009, at 2:18 PM, Kurt Engle wrote: > >> So are you wanting the cert cleaning and creation to happen >> everytime a client contacts the puppetmaster? >> >> What I am looking for is a script that will run on a newly imaged >> client that run at bootup before the puppetd process is started. >> That script would delete any cert on the puppetmaster and then the >> script would delete itself on the client. The issue that I am having >> is with clients that have been using puppet but are then ''re- >> imaged''. Once a device is running puppet, it works fine unless it is >> re-imaged. >> >> This seems like a more elegant solution in my environment than >> trying to do this on the puppet server side of things. Besides, >> doesn''t the client need to us its cert to talk to the server in the >> first place? If that cert is ''bad'' then how would it talk to the >> puppetmaster server and have the server delete its bad key? >> >> Now, anybody have any good resources for writing startup scripts on >> a Mac client? I seem to be having problems getting a script that >> runs fine on the command line to work at startup. >> >> -kurt >> >> On Fri, Jul 3, 2009 at 6:12 AM, Gary Larizza <glarizza@mac.com> >> wrote: >> >> I love where this thread is going, I too share in this problem. >> >> Kurt: Puppet is still being run on the client because the client is >> using a cached config (am I right on this guys?). >> >> I love the scripted ssh key, but ALSO love the PHP script that could >> be CURL-ed from the client. Will a PHP script be able to capture the >> hostname of a connecting client? From there, the php script could >> call puppetca to clean the cert and create a new one...would this be >> cleaner than bundling a cert with your base-image? Unfortunately, >> I''m >> not that versed in PHP to hash a script out from scratch. Does >> anyone >> have a rough outline that we could steal? >> >> -Gary >> >> >> >>> > > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
ug, can''t type. I tried to say that I am _now_ thinking of using the fqdn name switch, but a I look into it more, I think the --certname switch will work. here''s my plan: I will have a launchd job run a script every hour. The script will simply do something like this (this is logical, so ignore syntax): MAC_UID=`facter | grep sp_serial_number | awk ''{print $3}''` if MAC_UID = '''' then MAC_UID = `facter | grep ''macaddress =>'' | awk ''{print $3}''` end if if MAC_UID = '''' then # ug, not sure end if MAC_UID = lowercase(MAC_UID) + ''.lanl.gov'' puppetd -o --certname=${MAC_UID} I''ll probably write the MAC_UID to nvram as a cache for speed. I figure this should be pretty unique. As machines start to report in I will see those with MAC addresses as host IDs, and I can send a tech out to fix the machine by burning in the correct serial number. As for cleaning the certs from the server after a machine rebuild, I''m going to write use the idea presented earlier for a web CGI and give apache sudo rights to puppetca. We already have an in-house program we use to secure and configure the Mac, so I will add a menu item to that to "Clean the Puppet Certificate". This plan will probably only work on Mac, but for now, that is my scope. Once we start running on linux and solaris I will need to revisit this issue. Hopefully there is a FACT for serial number for those OSs too. Even though I didn''t start this discussion, I thank all those that contributed to this discussion. I know there were a lot of posts about it, so if you didn''t care, sorry. --- Thanks, Allan Marcus 505-667-5666 On Jul 8, 2009, at 6:04 PM, Allan Marcus wrote:> > Sorry, i didn''t mean the db for store configs. My issue with use FQDN > is for machines that use dhcp and might not have the same host name, > and when building a machine behind a router, in which case more than > one machine might have the same host name. > > I''m not thinking of using the --fqdn switch (if I cannot use a fact in > the certname directive of puppet.conf) to uniquely ID a machine. Still > have the issue of cleaning the cert on server though. > > --- > Thanks, > > Allan Marcus > 505-667-5666 > > > > On Jul 8, 2009, at 5:54 PM, Allan Marcus wrote: > >> the more I think about it, the more I am convinced that using the >> Mac''s serial number is the least worst option for cert name. There is >> still the issue of the machine being reimaged that would require the >> cert to be cleaned on the server, but using the serial number would >> allow the host name to change and not screw up the store config DB. >> >> --- >> Thanks, >> >> Allan Marcus >> 505-667-5666 >> >> >> >> On Jul 8, 2009, at 2:18 PM, Kurt Engle wrote: >> >>> So are you wanting the cert cleaning and creation to happen >>> everytime a client contacts the puppetmaster? >>> >>> What I am looking for is a script that will run on a newly imaged >>> client that run at bootup before the puppetd process is started. >>> That script would delete any cert on the puppetmaster and then the >>> script would delete itself on the client. The issue that I am having >>> is with clients that have been using puppet but are then ''re- >>> imaged''. Once a device is running puppet, it works fine unless it is >>> re-imaged. >>> >>> This seems like a more elegant solution in my environment than >>> trying to do this on the puppet server side of things. Besides, >>> doesn''t the client need to us its cert to talk to the server in the >>> first place? If that cert is ''bad'' then how would it talk to the >>> puppetmaster server and have the server delete its bad key? >>> >>> Now, anybody have any good resources for writing startup scripts on >>> a Mac client? I seem to be having problems getting a script that >>> runs fine on the command line to work at startup. >>> >>> -kurt >>> >>> On Fri, Jul 3, 2009 at 6:12 AM, Gary Larizza <glarizza@mac.com> >>> wrote: >>> >>> I love where this thread is going, I too share in this problem. >>> >>> Kurt: Puppet is still being run on the client because the client is >>> using a cached config (am I right on this guys?). >>> >>> I love the scripted ssh key, but ALSO love the PHP script that could >>> be CURL-ed from the client. Will a PHP script be able to capture >>> the >>> hostname of a connecting client? From there, the php script could >>> call puppetca to clean the cert and create a new one...would this be >>> cleaner than bundling a cert with your base-image? Unfortunately, >>> I''m >>> not that versed in PHP to hash a script out from scratch. Does >>> anyone >>> have a rough outline that we could steal? >>> >>> -Gary >>> >>> >>> >>>> >> >> >>> > > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
generally speaking, here''s how you get a script to run at start up on the mac. sudo vi /Library/LaunchDaemons/MyStartUpScript.plist paste in the following: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>com.mycompany.MyStartUpScript </string> <key>Nice</key> <integer>20</integer> <key>ProgramArguments</key> <array> <string>/usr/local/bin/myscript.sh</string> </array> <key>RunAtLoad</key> <true/> </dict> Put your script in /usr/local/bin or where ever, but update the path in the plist above Have your script delete the plist file as the list line of the script If you need to pass arguments to your script, please each one on a <string> line in the <array> block That should be it. use the freeware "lingon" to create or edit these plists. it''s easy. Now, how to get the script to run before puppet is launched is a bit tricky and depends on how you are running puppet. --- Thanks, Allan Marcus 505-667-5666 On Jul 8, 2009, at 2:18 PM, Kurt Engle wrote:> So are you wanting the cert cleaning and creation to happen > everytime a client contacts the puppetmaster? > > What I am looking for is a script that will run on a newly imaged > client that run at bootup before the puppetd process is started. > That script would delete any cert on the puppetmaster and then the > script would delete itself on the client. The issue that I am having > is with clients that have been using puppet but are then ''re- > imaged''. Once a device is running puppet, it works fine unless it is > re-imaged. > > This seems like a more elegant solution in my environment than > trying to do this on the puppet server side of things. Besides, > doesn''t the client need to us its cert to talk to the server in the > first place? If that cert is ''bad'' then how would it talk to the > puppetmaster server and have the server delete its bad key? > > Now, anybody have any good resources for writing startup scripts on > a Mac client? I seem to be having problems getting a script that > runs fine on the command line to work at startup. > > -kurt > > On Fri, Jul 3, 2009 at 6:12 AM, Gary Larizza <glarizza@mac.com> wrote: > > I love where this thread is going, I too share in this problem. > > Kurt: Puppet is still being run on the client because the client is > using a cached config (am I right on this guys?). > > I love the scripted ssh key, but ALSO love the PHP script that could > be CURL-ed from the client. Will a PHP script be able to capture the > hostname of a connecting client? From there, the php script could > call puppetca to clean the cert and create a new one...would this be > cleaner than bundling a cert with your base-image? Unfortunately, I''m > not that versed in PHP to hash a script out from scratch. Does anyone > have a rough outline that we could steal? > > -Gary > > > > >--~--~---------~--~----~------------~-------~--~----~ 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, Jul 9, 2009 at 4:18 AM, Kurt Engle <kurt.engle@gmail.com> wrote:> So are you wanting the cert cleaning and creation to happen everytime a > client contacts the puppetmaster? > > What I am looking for is a script that will run on a newly imaged client > that run at bootup before the puppetd process is started. That script would > delete any cert on the puppetmaster and then the script would delete itself > on the client. The issue that I am having is with clients that have been > using puppet but are then ''re-imaged''. Once a device is running puppet, it > works fine unless it is re-imaged. >see the script i attached a few posts before --~--~---------~--~----~------------~-------~--~----~ 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 Fri, Jul 3, 2009 at 9:12 AM, Gary Larizza<glarizza@mac.com> wrote:> > I love where this thread is going, I too share in this problem. > > Kurt: Puppet is still being run on the client because the client is > using a cached config (am I right on this guys?). > > I love the scripted ssh key, but ALSO love the PHP script that could > be CURL-ed from the client. Will a PHP script be able to capture the > hostname of a connecting client? From there, the php script could > call puppetca to clean the cert and create a new one...would this be > cleaner than bundling a cert with your base-image? Unfortunately, I''m > not that versed in PHP to hash a script out from scratch. Does anyone > have a rough outline that we could steal?We use a script like this, but we make it a Custom 404 in Apache. When a machine installs, it requests its keys and if they don''t exist the 404 handler gets called. It then creates the key and spits it out as if it had been there the whole time. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Allan, thanks for all your help and suggestions with Mac scripts. I am getting closer to the configuration that I want. Thanks for the ''lingon'' suggestion, makes life easier. I would like to force puppetd into using the hostname of the client device when requesting a cert from the puppetmaster. Is there a puppet.conf declaration that will grab the $HOSTNAME variable and us it within puppet.conf? Or is there another way to make this happen? I tried specifiying it on the command line: puppetd --certname=$HOSTNAME, but puppetd complained bitterly. Thanks, -kurt On Wed, Jul 8, 2009 at 6:28 PM, Allan Marcus <allan@lanl.gov> wrote:> > ug, can''t type. > > I tried to say that I am _now_ thinking of using the fqdn name switch, > but a I look into it more, I think the --certname switch will work. > > here''s my plan: I will have a launchd job run a script every hour. The > script will simply do something like this (this is logical, so ignore > syntax): > > MAC_UID=`facter | grep sp_serial_number | awk ''{print $3}''` > if MAC_UID = '''' then > MAC_UID = `facter | grep ''macaddress =>'' | awk ''{print $3}''` > end if > if MAC_UID = '''' then > # ug, not sure > end if > MAC_UID = lowercase(MAC_UID) + ''.lanl.gov'' > puppetd -o --certname=${MAC_UID} > > I''ll probably write the MAC_UID to nvram as a cache for speed. > > > I figure this should be pretty unique. As machines start to report in > I will see those with MAC addresses as host IDs, and I can send a tech > out to fix the machine by burning in the correct serial number. > > As for cleaning the certs from the server after a machine rebuild, I''m > going to write use the idea presented earlier for a web CGI and give > apache sudo rights to puppetca. We already have an in-house program we > use to secure and configure the Mac, so I will add a menu item to that > to "Clean the Puppet Certificate". > > This plan will probably only work on Mac, but for now, that is my > scope. Once we start running on linux and solaris I will need to > revisit this issue. Hopefully there is a FACT for serial number for > those OSs too. > > Even though I didn''t start this discussion, I thank all those that > contributed to this discussion. I know there were a lot of posts about > it, so if you didn''t care, sorry. > > > --- > Thanks, > > Allan Marcus > 505-667-5666 > > > > On Jul 8, 2009, at 6:04 PM, Allan Marcus wrote: > > > > > Sorry, i didn''t mean the db for store configs. My issue with use FQDN > > is for machines that use dhcp and might not have the same host name, > > and when building a machine behind a router, in which case more than > > one machine might have the same host name. > > > > I''m not thinking of using the --fqdn switch (if I cannot use a fact in > > the certname directive of puppet.conf) to uniquely ID a machine. Still > > have the issue of cleaning the cert on server though. > > > > --- > > Thanks, > > > > Allan Marcus > > 505-667-5666 > > > > > > > > On Jul 8, 2009, at 5:54 PM, Allan Marcus wrote: > > > >> the more I think about it, the more I am convinced that using the > >> Mac''s serial number is the least worst option for cert name. There is > >> still the issue of the machine being reimaged that would require the > >> cert to be cleaned on the server, but using the serial number would > >> allow the host name to change and not screw up the store config DB. > >> > >> --- > >> Thanks, > >> > >> Allan Marcus > >> 505-667-5666 > >> > >> > >> > >> On Jul 8, 2009, at 2:18 PM, Kurt Engle wrote: > >> > >>> So are you wanting the cert cleaning and creation to happen > >>> everytime a client contacts the puppetmaster? > >>> > >>> What I am looking for is a script that will run on a newly imaged > >>> client that run at bootup before the puppetd process is started. > >>> That script would delete any cert on the puppetmaster and then the > >>> script would delete itself on the client. The issue that I am having > >>> is with clients that have been using puppet but are then ''re- > >>> imaged''. Once a device is running puppet, it works fine unless it is > >>> re-imaged. > >>> > >>> This seems like a more elegant solution in my environment than > >>> trying to do this on the puppet server side of things. Besides, > >>> doesn''t the client need to us its cert to talk to the server in the > >>> first place? If that cert is ''bad'' then how would it talk to the > >>> puppetmaster server and have the server delete its bad key? > >>> > >>> Now, anybody have any good resources for writing startup scripts on > >>> a Mac client? I seem to be having problems getting a script that > >>> runs fine on the command line to work at startup. > >>> > >>> -kurt > >>> > >>> On Fri, Jul 3, 2009 at 6:12 AM, Gary Larizza <glarizza@mac.com> > >>> wrote: > >>> > >>> I love where this thread is going, I too share in this problem. > >>> > >>> Kurt: Puppet is still being run on the client because the client is > >>> using a cached config (am I right on this guys?). > >>> > >>> I love the scripted ssh key, but ALSO love the PHP script that could > >>> be CURL-ed from the client. Will a PHP script be able to capture > >>> the > >>> hostname of a connecting client? From there, the php script could > >>> call puppetca to clean the cert and create a new one...would this be > >>> cleaner than bundling a cert with your base-image? Unfortunately, > >>> I''m > >>> not that versed in PHP to hash a script out from scratch. Does > >>> anyone > >>> have a rough outline that we could steal? > >>> > >>> -Gary > >>> > >>> > >>> > >>>> > >> > >> > >>> > > > > > > > > > > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
The code is incredibly insecure. All a bad guy has to do is add %3becho%20test%20%3E%20/tmp/test to the url and a file call test is written to the /tmp. Of course a really bad guy would know how to exploit a system call in a CGi much better than me. My ruby is very very limited, so if you can figure out a way to secure this script, I would appreciate it. --- Thanks, Allan Marcus 505-667-5666 On Jul 3, 2009, at 11:10 PM, Ohad Levy wrote:> here you go, its fetched from a much bigger website, so I didnt > really test it, but worth a shot :) > > http://gist.github.com/140457 > > cheers, > Ohad > > On Fri, Jul 3, 2009 at 9:12 PM, Gary Larizza <glarizza@mac.com> wrote: > > I love where this thread is going, I too share in this problem. > > Kurt: Puppet is still being run on the client because the client is > using a cached config (am I right on this guys?). > > I love the scripted ssh key, but ALSO love the PHP script that could > be CURL-ed from the client. Will a PHP script be able to capture the > hostname of a connecting client? From there, the php script could > call puppetca to clean the cert and create a new one...would this be > cleaner than bundling a cert with your base-image? Unfortunately, I''m > not that versed in PHP to hash a script out from scratch. Does anyone > have a rough outline that we could steal? > > -Gary > > > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
certname in puppet have to be lowercase, that was probably your issue. Here''s the script I''m going to use to execute puppet on my macs. I will have a launchd job that executes the script every hour. You might be able to extract what you need from this script --- Thanks, Allan Marcus 505-667-5666 #!/bin/sh # Script to run puppet and use the "correct" certname # we need the certname to be unique, so hostname is not great # by Allan Marcus of LANL # Version History # 2009-07-08: initial version # this script is run from a launchd job # this suffix is added to the value to make it look like a FQDN. # This allows for auto sign to work on the server with a simply wildcard SUFFIX=mycompany.com # see if the MAC_UID is in nvram already MAC_UID=`nvram MAC_UID 2>/dev/null | awk ''{print $2}''` if [ -z "$MAC_UID" ]; then # flag that nothing is in nvram yet NVRAM="no" fi # get the serial number for this Mac if [ -z "$MAC_UID" ]; then MAC_UID=`facter | grep sp_serial_number | awk ''{print $3}''` fi # if the MAC_UID is still null # get the primary MAC address if [ -z "$MAC_UID" ]; then MAC_UID=`facter | grep ''macaddress =>'' | awk ''{print $3}''` fi # if all the above fails, get the hostname if [ -z "$MAC_UID" ]; then MAC_UID=`hostname` fi # assuming we have something, write it to nvram # getting it from nvram is much faster and is limited to this # specific computer if [ ''$NVRAM'' == ''no'' ]; then # cert names must be lowercase MAC_UID=`echo $MAC_UID | tr "[:upper:]" "[:lower:]"` MAC_UID=${MAC_UID}.${SUFFIX} nvram MAC_UID=${MAC_UID} fi RESULTS=`puppetd -o --no-daemonize -v --certname=$MAC_UID 2>&1` RESULTS=`echo $RESULTS | grep ''Certificate request does not match existing certificate''` if [ -z "$RESULTS" ]; then exit 0 else echo "Need to clean the cert $MAC_UID" #eventually this will be a curl call to a CGI to clean the cert fi --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Putting it all together, here''s what I have for cert management on Macs. 1) A launchd job to launch puppet every hour 2) a script on the client to determine a unique attribute of the Mac and use it for cert name 3) a CGI on the server to clean a cert if the machine was re-imaged 3a) note: alter /etc/sudoers on the server to allow the cgi to run puppetca Testing is rather easy. Runt he puppetd.sh script on the client (as root). Delete the /etc/puppet/ssl dir then run again. The system should clean the cert on the server (1) This plist file should be in /Library/LaunchDaemons/ <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd "> <plist version="1.0"> <dict> <key>Label</key> <string>com.mycompany.puppetd</string> <key>ProgramArguments</key> <array> <string>/usr/bin/puppetd.sh</string> </array> <key>QueueDirectories</key> <array/> <key>StartInterval</key> <integer>3600</integer> <key>WatchPaths</key> <array/> </dict> </plist> (2) /usr/bin/puppet.sh and chmod 700 and chown root:wheel #!/bin/sh # puppetd.sh script # Script to run puppet and use the "correct" certname # we need the certname to be unique, so hostname is not great # by Allan Marcus of LANL # Version History # 2009-07-08: initial version # this script is run from a launchd job # this suffix is added to the value to make it look like a FQDN. # This allows for auto sign to work on the server with a simply wildcard SUFFIX=mycompany.com # this is the server to sent a puppetca clean to SERVER=www.mycompany.com # --------------- # see if the MAC_UID is in nvram already MAC_UID=`nvram MAC_UID 2>/dev/null | awk ''{print $2}''` if [ -z "$MAC_UID" ]; then # flag that nothing is in nvram yet NVRAM="no" fi # get the serial number for this Mac if [ -z "$MAC_UID" ]; then MAC_UID=`facter | grep sp_serial_number | awk ''{print $3}''` fi # if the MAC_UID is still null # get the primary MAC address if [ -z "$MAC_UID" ]; then MAC_UID=`facter | grep ''macaddress =>'' | awk ''{print $3}''` fi # if all the above fails, get the hostname if [ -z "$MAC_UID" ]; then MAC_UID=`hostname` fi # assuming we have something, write it to nvram # getting it from nvram is much faster and is limited to this # specific computer if [ ''$NVRAM'' == ''no'' ]; then # cert names must be lowercase MAC_UID=`echo $MAC_UID | tr "[:upper:]" "[:lower:]"` MAC_UID=${MAC_UID}.${SUFFIX} nvram MAC_UID=${MAC_UID} fi RESULTS=`puppetd -o --no-daemonize -v --certname=$MAC_UID 2>&1` RESULTS=`echo $RESULTS | grep ''Certificate request does not match existing certificate''` if [ -z "$RESULTS" ]; then exit 0 else # curl call to a CGI to clean the cert curl "http://${SERVER}/cgi-bin/cleanCert.rb?certname=${MAC_UID}" fi ### end puppetd.sh script #### (3) On the server in the CGI directory. On a Mac server you also need to allow CGI''s in server admin. #!/usr/bin/ruby # clearCert.rb # cgi to clean a cert class Puppetca # removes old certificate if it exists # parameter is the certname to use # need to allow the _www user to use sudo with the puppetca command # added using visudo # _www ALL = NOPASSWD: /usr/bin/puppetca, !/usr/bin/puppetca -- clean --all def self.clean certname, addr command = "/usr/bin/sudo /usr/bin/puppetca --clean #{certname}" # for some reason the "system" command causes Mac apache to crash # when used here %x{#{command}} %x{"logger #{addr} cleaned #{certname}"} return true end end =begin CGI starts here =end # get the value of the passed param in the URL Query_string require ''cgi'' cgi=CGI.new certname = cgi["certname"] # define the characters that are allow to avoid an injection attack # 0-9, a-z, period, dash, and colon are allowed. All else is not pattern = /[^a-z0-9.\-:]/ # determine if any other characters are in the certname reject = (certname =~ pattern) ? 1 : 0 if ((reject == 0) && Puppetca.clean(certname, ENV[''REMOTE_ADDR''])) cgi.out("status" => "OK", "connection" => "close") {"OK #{certname} cleaned\n"} else cgi.out("status" => "BAD_REQUEST", "connection" => "close") {"Not Processed: #{certname}\n"} end --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
This is fantastic. I think something like this will be very useful in managing a large number of Macintosh clients. It is certainly the help and outcome that I was looking for when I started this thread. A big "Thank You" to Allan and everyone else that contributed. I took a little different but similar approach. I may adapt my approach to mimic Allan''s as time permits. But... here is what I came up with. 1) A launchd job to run puppet every hour passing the $HOSTNAME as a certname arg. 2) If the machine is re-imaged at any time, a startup job is installed that uses ssh to contact the puppetmaster and delete the cert that corresponds to the machine''s $HOSTNAME. Then the startup job deletes itself. So the job is only run once on a newly imaged machine. i) The machine''s hostname is its serial number as determined by facter. -kurt On Thu, Jul 9, 2009 at 6:12 PM, Allan Marcus <allan@lanl.gov> wrote:> > Putting it all together, here''s what I have for cert management on Macs. > > 1) A launchd job to launch puppet every hour > 2) a script on the client to determine a unique attribute of the Mac > and use it for cert name > 3) a CGI on the server to clean a cert if the machine was re-imaged > 3a) note: alter /etc/sudoers on the server to allow the cgi to run > puppetca > > Testing is rather easy. Runt he puppetd.sh script on the client (as > root). Delete the /etc/puppet/ssl dir then run again. The system > should clean the cert on the server > > > > (1) This plist file should be in /Library/LaunchDaemons/ > <?xml version="1.0" encoding="UTF-8"?> > <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" " > http://www.apple.com/DTDs/PropertyList-1.0.dtd > "> > <plist version="1.0"> > <dict> > <key>Label</key> > <string>com.mycompany.puppetd</string> > <key>ProgramArguments</key> > <array> > <string>/usr/bin/puppetd.sh</string> > </array> > <key>QueueDirectories</key> > <array/> > <key>StartInterval</key> > <integer>3600</integer> > <key>WatchPaths</key> > <array/> > </dict> > </plist> > > > (2) /usr/bin/puppet.sh and chmod 700 and chown root:wheel > #!/bin/sh > # puppetd.sh script > # Script to run puppet and use the "correct" certname > # we need the certname to be unique, so hostname is not great > > # by Allan Marcus of LANL > > # Version History > # 2009-07-08: initial version > > # this script is run from a launchd job > > # this suffix is added to the value to make it look like a FQDN. > # This allows for auto sign to work on the server with a simply wildcard > SUFFIX=mycompany.com > > # this is the server to sent a puppetca clean to > SERVER=www.mycompany.com > > > # --------------- > > # see if the MAC_UID is in nvram already > MAC_UID=`nvram MAC_UID 2>/dev/null | awk ''{print $2}''` > if [ -z "$MAC_UID" ]; then > # flag that nothing is in nvram yet > NVRAM="no" > fi > > # get the serial number for this Mac > if [ -z "$MAC_UID" ]; then > MAC_UID=`facter | grep sp_serial_number | awk ''{print $3}''` > fi > > # if the MAC_UID is still null > # get the primary MAC address > if [ -z "$MAC_UID" ]; then > MAC_UID=`facter | grep ''macaddress =>'' | awk ''{print $3}''` > fi > > # if all the above fails, get the hostname > if [ -z "$MAC_UID" ]; then > MAC_UID=`hostname` > fi > > # assuming we have something, write it to nvram > # getting it from nvram is much faster and is limited to this > # specific computer > if [ ''$NVRAM'' == ''no'' ]; then > # cert names must be lowercase > MAC_UID=`echo $MAC_UID | tr "[:upper:]" "[:lower:]"` > MAC_UID=${MAC_UID}.${SUFFIX} > nvram MAC_UID=${MAC_UID} > fi > > RESULTS=`puppetd -o --no-daemonize -v --certname=$MAC_UID 2>&1` > RESULTS=`echo $RESULTS | grep ''Certificate request does not match > existing certificate''` > > if [ -z "$RESULTS" ]; then > exit 0 > else > # curl call to a CGI to clean the cert > curl "http://${SERVER}/cgi-bin/cleanCert.rb?certname=${MAC_UID}" > fi > > ### end puppetd.sh script #### > > (3) On the server in the CGI directory. On a Mac server you also need > to allow CGI''s in server admin. > #!/usr/bin/ruby > > # clearCert.rb > # cgi to clean a cert > > class Puppetca > # removes old certificate if it exists > # parameter is the certname to use > # need to allow the _www user to use sudo with the puppetca command > # added using visudo > # _www ALL = NOPASSWD: /usr/bin/puppetca, !/usr/bin/puppetca -- > clean --all > def self.clean certname, addr > command = "/usr/bin/sudo /usr/bin/puppetca --clean > #{certname}" > # for some reason the "system" command causes Mac apache to > crash > # when used here > %x{#{command}} > %x{"logger #{addr} cleaned #{certname}"} > return true > end > end > > =begin > CGI starts here > =end > > # get the value of the passed param in the URL Query_string > require ''cgi'' > cgi=CGI.new > certname = cgi["certname"] > > # define the characters that are allow to avoid an injection attack > # 0-9, a-z, period, dash, and colon are allowed. All else is not > pattern = /[^a-z0-9.\-:]/ > # determine if any other characters are in the certname > reject = (certname =~ pattern) ? 1 : 0 > > if ((reject == 0) && Puppetca.clean(certname, ENV[''REMOTE_ADDR''])) > cgi.out("status" => "OK", "connection" => "close") {"OK #{certname} > cleaned\n"} > else > cgi.out("status" => "BAD_REQUEST", "connection" => "close") {"Not > Processed: #{certname}\n"} > end > > > >--~--~---------~--~----~------------~-------~--~----~ 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 Fri, Jul 10, 2009 at 7:32 AM, Kurt Engle<kurt.engle@gmail.com> wrote:> This is fantastic. I think something like this will be very useful in > managing a large number of Macintosh clients. It is certainly the help and > outcome that I was looking for when I started this thread. A big "Thank You" > to Allan and everyone else that contributed. > > I took a little different but similar approach. I may adapt my approach to > mimic Allan''s as time permits. But... here is what I came up with. > > 1) A launchd job to run puppet every hour passing the $HOSTNAME as a > certname arg. > 2) If the machine is re-imaged at any time, a startup job is installed that > uses ssh to contact the puppetmaster and delete the cert that corresponds to > the machine''s $HOSTNAME. Then the startup job deletes itself. So the job is > only run once on a newly imaged machine. > > i) The machine''s hostname is its serial number as determined by facter.This is somewhat off-topic, but you shouldn''t override $HOSTNAME on OS X. You should instead set ComputerName/LocalHostName in SystemConfiguration, ie scutil --set ComputerName foo scutil --set LocalHostName foo scutil --get ComputerName scutil --get LocalHostName etc.> > -kurt > > On Thu, Jul 9, 2009 at 6:12 PM, Allan Marcus <allan@lanl.gov> wrote: >> >> Putting it all together, here''s what I have for cert management on Macs. >> >> 1) A launchd job to launch puppet every hour >> 2) a script on the client to determine a unique attribute of the Mac >> and use it for cert name >> 3) a CGI on the server to clean a cert if the machine was re-imaged >> 3a) note: alter /etc/sudoers on the server to allow the cgi to run >> puppetca >> >> Testing is rather easy. Runt he puppetd.sh script on the client (as >> root). Delete the /etc/puppet/ssl dir then run again. The system >> should clean the cert on the server >> >> >> >> (1) This plist file should be in /Library/LaunchDaemons/ >> <?xml version="1.0" encoding="UTF-8"?> >> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" >> "http://www.apple.com/DTDs/PropertyList-1.0.dtd >> "> >> <plist version="1.0"> >> <dict> >> <key>Label</key> >> <string>com.mycompany.puppetd</string> >> <key>ProgramArguments</key> >> <array> >> <string>/usr/bin/puppetd.sh</string> >> </array> >> <key>QueueDirectories</key> >> <array/> >> <key>StartInterval</key> >> <integer>3600</integer> >> <key>WatchPaths</key> >> <array/> >> </dict> >> </plist> >> >> >> (2) /usr/bin/puppet.sh and chmod 700 and chown root:wheel >> #!/bin/sh >> # puppetd.sh script >> # Script to run puppet and use the "correct" certname >> # we need the certname to be unique, so hostname is not great >> >> # by Allan Marcus of LANL >> >> # Version History >> # 2009-07-08: initial version >> >> # this script is run from a launchd job >> >> # this suffix is added to the value to make it look like a FQDN. >> # This allows for auto sign to work on the server with a simply wildcard >> SUFFIX=mycompany.com >> >> # this is the server to sent a puppetca clean to >> SERVER=www.mycompany.com >> >> >> # --------------- >> >> # see if the MAC_UID is in nvram already >> MAC_UID=`nvram MAC_UID 2>/dev/null | awk ''{print $2}''` >> if [ -z "$MAC_UID" ]; then >> # flag that nothing is in nvram yet >> NVRAM="no" >> fi >> >> # get the serial number for this Mac >> if [ -z "$MAC_UID" ]; then >> MAC_UID=`facter | grep sp_serial_number | awk ''{print $3}''` >> fi >> >> # if the MAC_UID is still null >> # get the primary MAC address >> if [ -z "$MAC_UID" ]; then >> MAC_UID=`facter | grep ''macaddress =>'' | awk ''{print $3}''` >> fi >> >> # if all the above fails, get the hostname >> if [ -z "$MAC_UID" ]; then >> MAC_UID=`hostname` >> fi >> >> # assuming we have something, write it to nvram >> # getting it from nvram is much faster and is limited to this >> # specific computer >> if [ ''$NVRAM'' == ''no'' ]; then >> # cert names must be lowercase >> MAC_UID=`echo $MAC_UID | tr "[:upper:]" "[:lower:]"` >> MAC_UID=${MAC_UID}.${SUFFIX} >> nvram MAC_UID=${MAC_UID} >> fi >> >> RESULTS=`puppetd -o --no-daemonize -v --certname=$MAC_UID 2>&1` >> RESULTS=`echo $RESULTS | grep ''Certificate request does not match >> existing certificate''` >> >> if [ -z "$RESULTS" ]; then >> exit 0 >> else >> # curl call to a CGI to clean the cert >> curl "http://${SERVER}/cgi-bin/cleanCert.rb?certname=${MAC_UID}" >> fi >> >> ### end puppetd.sh script #### >> >> (3) On the server in the CGI directory. On a Mac server you also need >> to allow CGI''s in server admin. >> #!/usr/bin/ruby >> >> # clearCert.rb >> # cgi to clean a cert >> >> class Puppetca >> # removes old certificate if it exists >> # parameter is the certname to use >> # need to allow the _www user to use sudo with the puppetca command >> # added using visudo >> # _www ALL = NOPASSWD: /usr/bin/puppetca, !/usr/bin/puppetca -- >> clean --all >> def self.clean certname, addr >> command = "/usr/bin/sudo /usr/bin/puppetca --clean >> #{certname}" >> # for some reason the "system" command causes Mac apache to >> crash >> # when used here >> %x{#{command}} >> %x{"logger #{addr} cleaned #{certname}"} >> return true >> end >> end >> >> =begin >> CGI starts here >> =end >> >> # get the value of the passed param in the URL Query_string >> require ''cgi'' >> cgi=CGI.new >> certname = cgi["certname"] >> >> # define the characters that are allow to avoid an injection attack >> # 0-9, a-z, period, dash, and colon are allowed. All else is not >> pattern = /[^a-z0-9.\-:]/ >> # determine if any other characters are in the certname >> reject = (certname =~ pattern) ? 1 : 0 >> >> if ((reject == 0) && Puppetca.clean(certname, ENV[''REMOTE_ADDR''])) >> cgi.out("status" => "OK", "connection" => "close") {"OK #{certname} >> cleaned\n"} >> else >> cgi.out("status" => "BAD_REQUEST", "connection" => "close") {"Not >> Processed: #{certname}\n"} >> end >> >> > > > > >-- Nigel Kersten nigelk@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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Absolutely. Here is my startup script that sets the hostname of the computer each time it starts up: scutil --set HostName `system_profiler SPHardwareDataType | grep "Serial Number:" | cut -d'':'' -f2 | tr "[:upper:]" "[:lower:]"` scutil --set ComputerName `system_profiler SPHardwareDataType | grep "Serial Number:" | cut -d'':'' -f2 | tr "[:upper:]" "[:lower:]"` scutil --set LocalHostName `system_profiler SPHardwareDataType | grep "Serial Number:" | cut -d'':'' -f2 | tr "[:upper:]" "[:lower:]"` -kurt On Fri, Jul 10, 2009 at 7:55 AM, Nigel Kersten <nigelk@google.com> wrote:> > On Fri, Jul 10, 2009 at 7:32 AM, Kurt Engle<kurt.engle@gmail.com> wrote: > > This is fantastic. I think something like this will be very useful in > > managing a large number of Macintosh clients. It is certainly the help > and > > outcome that I was looking for when I started this thread. A big "Thank > You" > > to Allan and everyone else that contributed. > > > > I took a little different but similar approach. I may adapt my approach > to > > mimic Allan''s as time permits. But... here is what I came up with. > > > > 1) A launchd job to run puppet every hour passing the $HOSTNAME as a > > certname arg. > > 2) If the machine is re-imaged at any time, a startup job is installed > that > > uses ssh to contact the puppetmaster and delete the cert that corresponds > to > > the machine''s $HOSTNAME. Then the startup job deletes itself. So the job > is > > only run once on a newly imaged machine. > > > > i) The machine''s hostname is its serial number as determined by facter. > > This is somewhat off-topic, but you shouldn''t override $HOSTNAME on OS X. > > You should instead set ComputerName/LocalHostName in SystemConfiguration, > ie > > scutil --set ComputerName foo > scutil --set LocalHostName foo > scutil --get ComputerName > scutil --get LocalHostName > > etc. > > > > > > > -kurt > > > > On Thu, Jul 9, 2009 at 6:12 PM, Allan Marcus <allan@lanl.gov> wrote: > >> > >> Putting it all together, here''s what I have for cert management on Macs. > >> > >> 1) A launchd job to launch puppet every hour > >> 2) a script on the client to determine a unique attribute of the Mac > >> and use it for cert name > >> 3) a CGI on the server to clean a cert if the machine was re-imaged > >> 3a) note: alter /etc/sudoers on the server to allow the cgi to run > >> puppetca > >> > >> Testing is rather easy. Runt he puppetd.sh script on the client (as > >> root). Delete the /etc/puppet/ssl dir then run again. The system > >> should clean the cert on the server > >> > >> > >> > >> (1) This plist file should be in /Library/LaunchDaemons/ > >> <?xml version="1.0" encoding="UTF-8"?> > >> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" > >> "http://www.apple.com/DTDs/PropertyList-1.0.dtd > >> "> > >> <plist version="1.0"> > >> <dict> > >> <key>Label</key> > >> <string>com.mycompany.puppetd</string> > >> <key>ProgramArguments</key> > >> <array> > >> <string>/usr/bin/puppetd.sh</string> > >> </array> > >> <key>QueueDirectories</key> > >> <array/> > >> <key>StartInterval</key> > >> <integer>3600</integer> > >> <key>WatchPaths</key> > >> <array/> > >> </dict> > >> </plist> > >> > >> > >> (2) /usr/bin/puppet.sh and chmod 700 and chown root:wheel > >> #!/bin/sh > >> # puppetd.sh script > >> # Script to run puppet and use the "correct" certname > >> # we need the certname to be unique, so hostname is not great > >> > >> # by Allan Marcus of LANL > >> > >> # Version History > >> # 2009-07-08: initial version > >> > >> # this script is run from a launchd job > >> > >> # this suffix is added to the value to make it look like a FQDN. > >> # This allows for auto sign to work on the server with a simply wildcard > >> SUFFIX=mycompany.com > >> > >> # this is the server to sent a puppetca clean to > >> SERVER=www.mycompany.com > >> > >> > >> # --------------- > >> > >> # see if the MAC_UID is in nvram already > >> MAC_UID=`nvram MAC_UID 2>/dev/null | awk ''{print $2}''` > >> if [ -z "$MAC_UID" ]; then > >> # flag that nothing is in nvram yet > >> NVRAM="no" > >> fi > >> > >> # get the serial number for this Mac > >> if [ -z "$MAC_UID" ]; then > >> MAC_UID=`facter | grep sp_serial_number | awk ''{print $3}''` > >> fi > >> > >> # if the MAC_UID is still null > >> # get the primary MAC address > >> if [ -z "$MAC_UID" ]; then > >> MAC_UID=`facter | grep ''macaddress =>'' | awk ''{print $3}''` > >> fi > >> > >> # if all the above fails, get the hostname > >> if [ -z "$MAC_UID" ]; then > >> MAC_UID=`hostname` > >> fi > >> > >> # assuming we have something, write it to nvram > >> # getting it from nvram is much faster and is limited to this > >> # specific computer > >> if [ ''$NVRAM'' == ''no'' ]; then > >> # cert names must be lowercase > >> MAC_UID=`echo $MAC_UID | tr "[:upper:]" "[:lower:]"` > >> MAC_UID=${MAC_UID}.${SUFFIX} > >> nvram MAC_UID=${MAC_UID} > >> fi > >> > >> RESULTS=`puppetd -o --no-daemonize -v --certname=$MAC_UID 2>&1` > >> RESULTS=`echo $RESULTS | grep ''Certificate request does not match > >> existing certificate''` > >> > >> if [ -z "$RESULTS" ]; then > >> exit 0 > >> else > >> # curl call to a CGI to clean the cert > >> curl "http://${SERVER}/cgi-bin/cleanCert.rb?certname=${MAC_UID}" > >> fi > >> > >> ### end puppetd.sh script #### > >> > >> (3) On the server in the CGI directory. On a Mac server you also need > >> to allow CGI''s in server admin. > >> #!/usr/bin/ruby > >> > >> # clearCert.rb > >> # cgi to clean a cert > >> > >> class Puppetca > >> # removes old certificate if it exists > >> # parameter is the certname to use > >> # need to allow the _www user to use sudo with the puppetca > command > >> # added using visudo > >> # _www ALL = NOPASSWD: /usr/bin/puppetca, !/usr/bin/puppetca > -- > >> clean --all > >> def self.clean certname, addr > >> command = "/usr/bin/sudo /usr/bin/puppetca --clean > >> #{certname}" > >> # for some reason the "system" command causes Mac apache > to > >> crash > >> # when used here > >> %x{#{command}} > >> %x{"logger #{addr} cleaned #{certname}"} > >> return true > >> end > >> end > >> > >> =begin > >> CGI starts here > >> =end > >> > >> # get the value of the passed param in the URL Query_string > >> require ''cgi'' > >> cgi=CGI.new > >> certname = cgi["certname"] > >> > >> # define the characters that are allow to avoid an injection attack > >> # 0-9, a-z, period, dash, and colon are allowed. All else is not > >> pattern = /[^a-z0-9.\-:]/ > >> # determine if any other characters are in the certname > >> reject = (certname =~ pattern) ? 1 : 0 > >> > >> if ((reject == 0) && Puppetca.clean(certname, ENV[''REMOTE_ADDR''])) > >> cgi.out("status" => "OK", "connection" => "close") {"OK > #{certname} > >> cleaned\n"} > >> else > >> cgi.out("status" => "BAD_REQUEST", "connection" => "close") {"Not > >> Processed: #{certname}\n"} > >> end > >> > >> > > > > > > > > > > > > > -- > Nigel Kersten > nigelk@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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Couple of minor revisions. 1) Thank you Ohad Levy for the original cgi script. Sorry about not giving you credit. 2) if [ ''$NVRAM'' == ''no'' ]; then should be if [ "$NVRAM" == ''no'' ]; then --- Thanks, Allan Marcus 505-667-5666 On Jul 9, 2009, at 7:12 PM, Allan Marcus wrote:> > Putting it all together, here''s what I have for cert management on > Macs. > > 1) A launchd job to launch puppet every hour > 2) a script on the client to determine a unique attribute of the Mac > and use it for cert name > 3) a CGI on the server to clean a cert if the machine was re-imaged > 3a) note: alter /etc/sudoers on the server to allow the cgi to run > puppetca > > Testing is rather easy. Runt he puppetd.sh script on the client (as > root). Delete the /etc/puppet/ssl dir then run again. The system > should clean the cert on the server > > > > (1) This plist file should be in /Library/LaunchDaemons/ > <?xml version="1.0" encoding="UTF-8"?> > <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd > "> > <plist version="1.0"> > <dict> > <key>Label</key> > <string>com.mycompany.puppetd</string> > <key>ProgramArguments</key> > <array> > <string>/usr/bin/puppetd.sh</string> > </array> > <key>QueueDirectories</key> > <array/> > <key>StartInterval</key> > <integer>3600</integer> > <key>WatchPaths</key> > <array/> > </dict> > </plist> > > > (2) /usr/bin/puppet.sh and chmod 700 and chown root:wheel > #!/bin/sh > # puppetd.sh script > # Script to run puppet and use the "correct" certname > # we need the certname to be unique, so hostname is not great > > # by Allan Marcus of LANL > > # Version History > # 2009-07-08: initial version > > # this script is run from a launchd job > > # this suffix is added to the value to make it look like a FQDN. > # This allows for auto sign to work on the server with a simply > wildcard > SUFFIX=mycompany.com > > # this is the server to sent a puppetca clean to > SERVER=www.mycompany.com > > > # --------------- > > # see if the MAC_UID is in nvram already > MAC_UID=`nvram MAC_UID 2>/dev/null | awk ''{print $2}''` > if [ -z "$MAC_UID" ]; then > # flag that nothing is in nvram yet > NVRAM="no" > fi > > # get the serial number for this Mac > if [ -z "$MAC_UID" ]; then > MAC_UID=`facter | grep sp_serial_number | awk ''{print $3}''` > fi > > # if the MAC_UID is still null > # get the primary MAC address > if [ -z "$MAC_UID" ]; then > MAC_UID=`facter | grep ''macaddress =>'' | awk ''{print $3}''` > fi > > # if all the above fails, get the hostname > if [ -z "$MAC_UID" ]; then > MAC_UID=`hostname` > fi > > # assuming we have something, write it to nvram > # getting it from nvram is much faster and is limited to this > # specific computer > if [ ''$NVRAM'' == ''no'' ]; then > # cert names must be lowercase > MAC_UID=`echo $MAC_UID | tr "[:upper:]" "[:lower:]"` > MAC_UID=${MAC_UID}.${SUFFIX} > nvram MAC_UID=${MAC_UID} > fi > > RESULTS=`puppetd -o --no-daemonize -v --certname=$MAC_UID 2>&1` > RESULTS=`echo $RESULTS | grep ''Certificate request does not match > existing certificate''` > > if [ -z "$RESULTS" ]; then > exit 0 > else > # curl call to a CGI to clean the cert > curl "http://${SERVER}/cgi-bin/cleanCert.rb?certname=${MAC_UID}" > fi > > ### end puppetd.sh script #### > > (3) On the server in the CGI directory. On a Mac server you also need > to allow CGI''s in server admin. > #!/usr/bin/ruby > > # clearCert.rb > # cgi to clean a cert > > class Puppetca > # removes old certificate if it exists > # parameter is the certname to use > # need to allow the _www user to use sudo with the puppetca command > # added using visudo > # _www ALL = NOPASSWD: /usr/bin/puppetca, !/usr/bin/puppetca -- > clean --all > def self.clean certname, addr > command = "/usr/bin/sudo /usr/bin/puppetca --clean #{certname}" > # for some reason the "system" command causes Mac apache to crash > # when used here > %x{#{command}} > %x{"logger #{addr} cleaned #{certname}"} > return true > end > end > > =begin > CGI starts here > =end > > # get the value of the passed param in the URL Query_string > require ''cgi'' > cgi=CGI.new > certname = cgi["certname"] > > # define the characters that are allow to avoid an injection attack > # 0-9, a-z, period, dash, and colon are allowed. All else is not > pattern = /[^a-z0-9.\-:]/ > # determine if any other characters are in the certname > reject = (certname =~ pattern) ? 1 : 0 > > if ((reject == 0) && Puppetca.clean(certname, ENV[''REMOTE_ADDR''])) > cgi.out("status" => "OK", "connection" => "close") {"OK #{certname} > cleaned\n"} > else > cgi.out("status" => "BAD_REQUEST", "connection" => "close") {"Not > Processed: #{certname}\n"} > end > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Sam Rowe wrote:> We use a script like this, but we make it a Custom 404 in Apache. When > a machine installs, it requests its keys and if they don''t exist the > 404 handler gets called. It then creates the key and spits it out as > if it had been there the whole time. >I''m curious, how do you prevent someone from obtaining another Puppet client''s private key? -scott --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---