Hey all,
I''ve been designing a new feature for Puppet, and wanted to get some
kick-back from the community to see if you think this is needed or not. The
feature is called Puppet Sites, and meets some specific goals by means of a
few tasks.
- Securely add nodes to your deployment without manually signing
certificates on the CA...
- ...so that you can have the advantages of autosigning without its
security problems.
- Get a list of all the nodes in your deployment...
- ...so that a single command can give you what previously you had to
trawl multiple services (ENCs, CAs, etc...) on each Puppet master in your
deployment to retrieve.
- Store connection information for Puppet services in a central location
(accessible from manifests, puppet.conf, and defaults.rb)...
- ...so that you don''t have to manage puppet.conf files on each
node
in your population
- ...so that agent/master/CA configuration stays consistent across
your deployment
- ...so that you can update your config and fetch a new catalog in a
single operation.
Thanks in advance for the feedback!
- Daniel
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/cdG9GFFqvYEJ.
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, May 10, 2012 at 12:44 PM, Daniel Sauble <djsauble@puppetlabs.com>wrote:> Hey all, > > I''ve been designing a new feature for Puppet, and wanted to get some > kick-back from the community to see if you think this is needed or not. The > feature is called Puppet Sites, and meets some specific goals by means of a > few tasks. > > - Securely add nodes to your deployment without manually signing > certificates on the CA... > - ...so that you can have the advantages of autosigning without its > security problems. > > > - Get a list of all the nodes in your deployment... > - ...so that a single command can give you what previously you had > to trawl multiple services (ENCs, CAs, etc...) on each Puppet master in > your deployment to retrieve. > > How does this work with ENCs? Will the ENC need to talk to Puppet sitesfor node information such as environment settings? When nodes are added and removed from Puppet sites will they be updated in the ENC and vice-versa.> > - Store connection information for Puppet services in a central > location (accessible from manifests, puppet.conf, and defaults.rb)... > - ...so that you don''t have to manage puppet.conf files on each > node in your population > - ...so that agent/master/CA configuration stays consistent across > your deployment > - ...so that you can update your config and fetch a new catalog in > a single operation. > > So will each node then need to be configured with the location to Puppetsites?> Thanks in advance for the feedback! > - Daniel > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/puppet-users/-/cdG9GFFqvYEJ. > 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. >-- Kelsey Hightower Developer Puppet Labs (678) 4719501 -- 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, May 10, 2012 at 6:44 AM, Daniel Sauble <djsauble@puppetlabs.com> wrote:> Hey all, > > I''ve been designing a new feature for Puppet, and wanted to get some > kick-back from the community to see if you think this is needed or not. The > feature is called Puppet Sites, and meets some specific goals by means of a > few tasks. > > Securely add nodes to your deployment without manually signing certificates > on the CA... > > ...so that you can have the advantages of autosigning without its security > problems. > > Get a list of all the nodes in your deployment... > > ...so that a single command can give you what previously you had to trawl > multiple services (ENCs, CAs, etc...) on each Puppet master in your > deployment to retrieve. > > Store connection information for Puppet services in a central location > (accessible from manifests, puppet.conf, and defaults.rb)... > > ...so that you don''t have to manage puppet.conf files on each node in your > population > ...so that agent/master/CA configuration stays consistent across your > deployment > ...so that you can update your config and fetch a new catalog in a single > operation. > > Thanks in advance for the feedback! > - DanielHi Daniel, thanks for dropping a note to get some feedback on this. While these features sound very nice I personally would find it interesting and might have more to add if you went into a bit of detail about how you plan to implement these features. Thanks, -- Romeo -- 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 Thursday, May 10, 2012 9:53:15 AM UTC-7, Kelsey Hightower wrote:> > On Thu, May 10, 2012 at 12:44 PM, Daniel Sauble <djsauble@puppetlabs.com>wrote: > >> Hey all, >> >> I''ve been designing a new feature for Puppet, and wanted to get some >> kick-back from the community to see if you think this is needed or not. The >> feature is called Puppet Sites, and meets some specific goals by means of a >> few tasks. >> >> - Securely add nodes to your deployment without manually signing >> certificates on the CA... >> - ...so that you can have the advantages of autosigning without >> its security problems. >> >> >> - Get a list of all the nodes in your deployment... >> - ...so that a single command can give you what previously you had >> to trawl multiple services (ENCs, CAs, etc...) on each Puppet master in >> your deployment to retrieve. >> >> How does this work with ENCs? Will the ENC need to talk to Puppet sites > for node information such as environment settings? When nodes are added and > removed from Puppet sites will they be updated in the ENC and vice-versa. >Puppet Sites includes three services: a node registry, a service registry, and an authentication service. The *node registry* in the MVP for Puppet Sites is a slightly-modified CA (the sole difference being that certificates cannot be revoked from the node registry without the node itself leaving the site). So no, there isn''t any communication between the node registry and the ENC. However, the ENC can use the *service registry* to discover where the node registry lives, and do polling to update its own classification data.> >> - Store connection information for Puppet services in a central >> location (accessible from manifests, puppet.conf, and defaults.rb)... >> - ...so that you don''t have to manage puppet.conf files on each >> node in your population >> - ...so that agent/master/CA configuration stays consistent across >> your deployment >> - ...so that you can update your config and fetch a new catalog in >> a single operation. >> >> So will each node then need to be configured with the location to Puppet > sites? > >Yes. The goal is that each agent only require a single configuration parameter (site_server, perhaps), and the agent be able to automatically connect to all Puppet services specified in the Site''s service registry.> > >> Thanks in advance for the feedback! >> - Daniel >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/puppet-users/-/cdG9GFFqvYEJ. >> 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. >> > > > > -- > Kelsey Hightower > Developer > Puppet Labs > (678) 4719501 > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/Rqarv7FGCDMJ. 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 Thursday, May 10, 2012 9:53:28 AM UTC-7, Romeo Theriault wrote:> > On Thu, May 10, 2012 at 6:44 AM, Daniel Sauble <djsauble@puppetlabs.com> > wrote: > > Hey all, > > > > I''ve been designing a new feature for Puppet, and wanted to get some > > kick-back from the community to see if you think this is needed or not. > The > > feature is called Puppet Sites, and meets some specific goals by means > of a > > few tasks. > > > > Securely add nodes to your deployment without manually signing > certificates > > on the CA... > > > > ...so that you can have the advantages of autosigning without its > security > > problems. > > > > Get a list of all the nodes in your deployment... > > > > ...so that a single command can give you what previously you had to > trawl > > multiple services (ENCs, CAs, etc...) on each Puppet master in your > > deployment to retrieve. > > > > Store connection information for Puppet services in a central location > > (accessible from manifests, puppet.conf, and defaults.rb)... > > > > ...so that you don''t have to manage puppet.conf files on each node in > your > > population > > ...so that agent/master/CA configuration stays consistent across your > > deployment > > ...so that you can update your config and fetch a new catalog in a > single > > operation. > > > > Thanks in advance for the feedback! > > - Daniel > > Hi Daniel, thanks for dropping a note to get some feedback on this. > While these features sound very nice I personally would find it > interesting and might have more to add if you went into a bit of > detail about how you plan to implement these features. > >At this point, I''m trying to elicit feedback around user needs and desires, without tying the discussion to implementation details. If any of these goals don''t seem particularly interesting to you, or if you have any goals I haven''t addressed, or if you need clarification around what I mean in any of my bullet points, I''d love to hear what you think.> Thanks, > > -- > Romeo >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/FoCkfyINrj4J. 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 May 10, 12:44 pm, Daniel Sauble <djsau...@puppetlabs.com> wrote:> > - Securely add nodes to your deployment without manually signing > certificates on the CA... > - ...so that you can have the advantages of autosigning without its > security problems. >I''m about to engage on a similar effort and was thinking of writing a puppet face to handle this job. Can you elaborate on the work flow and solution you''re thinking about?> - Get a list of all the nodes in your deployment... > - ...so that a single command can give you what previously you had to > trawl multiple services (ENCs, CAs, etc...) on each Puppet master in your > deployment to retrieve. >Personally, I have no interest in logging into my puppet servers and running commands. It seems like this problem is better solved with a real monitoring solution. Best, Adam -- 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.
Deepak Giridharagopal
2012-May-10 18:06 UTC
Re: [Puppet Users] Re: Puppet Sites. Your thoughts?
On Thu, May 10, 2012 at 11:39 AM, windowsrefund <windowsrefund@gmail.com>wrote:> Personally, I have no interest in logging into my puppet servers and > running commands. It seems like this problem is better solved with a > real monitoring solution. >Our intent is to expose this information via APIs that allow for easier integration with existing systems. In particular, we''ve been thinking about supporting the registration of listeners that get notified when nodes are added or removed from a site. That said, I share your sentiment that this is not a replacement for monitoring systems; conceptually, I view this piece of Sites much more as an mild evolution of the existing CA code. deepak -- Deepak Giridharagopal / Puppet Labs -- 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 Thursday, May 10, 2012 10:39:22 AM UTC-7, windowsrefund wrote:> > > On May 10, 12:44 pm, Daniel Sauble <djsau...@puppetlabs.com> wrote: > > > > - Securely add nodes to your deployment without manually signing > > certificates on the CA... > > - ...so that you can have the advantages of autosigning without > its > > security problems. > > > > I''m about to engage on a similar effort and was thinking of writing a > puppet face to handle this job. Can you elaborate on the work flow and > solution you''re thinking about? >We''re looking to implement a Puppet Face to address this need. The workflow currently looks like: 1. Login to the site host 2. Generate a pre-shared key 3. Join a node to the site using the pre-shared key 4. Repeat step 3 for every node you want to add to the site From the command-line, this workflow might be represented as the following: * node02$ ssh admin@site02.domain.com Last login: Mon May 7 18:15:43 2012 site02$ mount /media/usbdisk site02$ puppet site generate key > /media/usbdisk/site.key site02$ umount /media/usbdisk site02$ exit node02$ mount /media/usbdisk node02$ puppet node join site02.domain.com < /media/usbdisk/site.key Trying to add node02.domain.com to the site at site02.domain.com... Use `puppet site status node02.domain.com` to confirm success To stop waiting for the command to complete, press Ctrl-C. The command will still complete in the background. Added node02.domain.com to the site at site02.domain.com* -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/dWo3QflKMogJ. 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, May 10, 2012 at 9:34 PM, Daniel Sauble <djsauble@puppetlabs.com>wrote:> On Thursday, May 10, 2012 10:39:22 AM UTC-7, windowsrefund wrote: >> >> >> On May 10, 12:44 pm, Daniel Sauble <djsau...@puppetlabs.com> wrote: >> > >> > - Securely add nodes to your deployment without manually signing >> > certificates on the CA... >> > - ...so that you can have the advantages of autosigning without >> its >> > security problems. >> > >> >> I''m about to engage on a similar effort and was thinking of writing a >> puppet face to handle this job. Can you elaborate on the work flow and >> solution you''re thinking about? >> > > We''re looking to implement a Puppet Face to address this need. The > workflow currently looks like: > > > 1. Login to the site host > 2. Generate a pre-shared key > 3. Join a node to the site using the pre-shared key > 4. Repeat step 3 for every node you want to add to the site > > > From the command-line, this workflow might be represented as the following: > * > node02$ ssh admin@site02.domain.com > Last login: Mon May 7 18:15:43 2012 > site02$ mount /media/usbdisk > site02$ puppet site generate key > /media/usbdisk/site.key > site02$ umount /media/usbdisk > site02$ exit > node02$ mount /media/usbdisk > node02$ puppet node join site02.domain.com < /media/usbdisk/site.key > Trying to add node02.domain.com to the site at site02.domain.com... > > Use `puppet site status node02.domain.com` to confirm success > > To stop waiting for the command to complete, press Ctrl-C. > > The command will still complete in the background. > Added node02.domain.com to the site at site02.domain.com* > >will you allow the older workflow to co exists? would it be possible to drive all of the process via an external api? thanks, Ohad> -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/puppet-users/-/dWo3QflKMogJ. > > 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. >-- 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.
----- Original Message -----> From: "Daniel Sauble" <djsauble@puppetlabs.com> > To: puppet-users@googlegroups.com > Sent: Thursday, May 10, 2012 7:34:14 PM > Subject: [Puppet Users] Re: Puppet Sites. Your thoughts? > > On Thursday, May 10, 2012 10:39:22 AM UTC-7, windowsrefund wrote: > > > On May 10, 12:44 pm, Daniel Sauble < djsau...@puppetlabs.com > wrote: > > > > - Securely add nodes to your deployment without manually signing > > certificates on the CA... > > - ...so that you can have the advantages of autosigning without its > > security problems. > > > > I''m about to engage on a similar effort and was thinking of writing a > puppet face to handle this job. Can you elaborate on the work flow > and > solution you''re thinking about? > > > > We''re looking to implement a Puppet Face to address this need. The > workflow currently looks like: > > > > 1. Login to the site host > 2. Generate a pre-shared key > 3. Join a node to the site using the pre-shared key > 4. Repeat step 3 for every node you want to add to the site > > > > From the command-line, this workflow might be represented as the > following: > > node02$ ssh admin@site02.domain.com > Last login: Mon May 7 18:15:43 2012 > site02$ mount /media/usbdisk > site02$ puppet site generate key > /media/usbdisk/site.key > site02$ umount /media/usbdisk > site02$ exit > node02$ mount /media/usbdisk > node02$ puppet node join site02.domain.com < /media/usbdisk/site.key > Trying to add node02.domain.com to the site at site02.domain.com... > > > Use `puppet site status node02.domain.com` to confirm success > > To stop waiting for the command to complete, press Ctrl-C. > > The command will still complete in the background. Added > node02.domain.com to the site at site02.domain.comCan you explain the advantages this workflow has over the current process involving requesting a cert and signing it on the master? It would also be great if you could send plain text mail as is the convention on this list. -- 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 Thursday, May 10, 2012 11:37:34 AM UTC-7, ohad wrote:> > > > On Thu, May 10, 2012 at 9:34 PM, Daniel Sauble <djsauble@puppetlabs.com>wrote: > >> On Thursday, May 10, 2012 10:39:22 AM UTC-7, windowsrefund wrote: >>> >>> >>> On May 10, 12:44 pm, Daniel Sauble <djsau...@puppetlabs.com> wrote: >>> > >>> > - Securely add nodes to your deployment without manually signing >>> > certificates on the CA... >>> > - ...so that you can have the advantages of autosigning without >>> its >>> > security problems. >>> > >>> >>> I''m about to engage on a similar effort and was thinking of writing a >>> puppet face to handle this job. Can you elaborate on the work flow and >>> solution you''re thinking about? >>> >> >> We''re looking to implement a Puppet Face to address this need. The >> workflow currently looks like: >> >> >> 1. Login to the site host >> 2. Generate a pre-shared key >> 3. Join a node to the site using the pre-shared key >> 4. Repeat step 3 for every node you want to add to the site >> >> >> From the command-line, this workflow might be represented as the >> following: >> * >> node02$ ssh admin@site02.domain.com >> Last login: Mon May 7 18:15:43 2012 >> site02$ mount /media/usbdisk >> site02$ puppet site generate key > /media/usbdisk/site.key >> site02$ umount /media/usbdisk >> site02$ exit >> node02$ mount /media/usbdisk >> node02$ puppet node join site02.domain.com < /media/usbdisk/site.key >> Trying to add node02.domain.com to the site at site02.domain.com... >> >> Use `puppet site status node02.domain.com` to confirm success >> >> To stop waiting for the command to complete, press Ctrl-C. >> >> The command will still complete in the background. >> Added node02.domain.com to the site at site02.domain.com* >> >> > will you allow the older workflow to co exists? would it be possible to > drive all of the process via an external api? >>No, at present we are looking to deprecate the ''clean'', ''generate'', ''list'', ''revoke'', and ''sign'' actions of the puppet cert face. The reason for this is we want the semantics of the user interface to match the user need. The impression I''ve gotten (and feel free to chime in) is that users don''t want to sign certificates, they want to add nodes to their deployment. Yes, the goal is that all the functionality of the Puppet Face will also be available via the REST API. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/riGf_rgukFgJ. 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 May 10, 2:04 pm, Daniel Sauble <djsau...@puppetlabs.com> wrote:> On Thursday, May 10, 2012 11:37:34 AM UTC-7, ohad wrote: > > > On Thu, May 10, 2012 at 9:34 PM, Daniel Sauble <djsau...@puppetlabs.com>wrote: > > >> On Thursday, May 10, 2012 10:39:22 AM UTC-7, windowsrefund wrote: > > >>> On May 10, 12:44 pm, Daniel Sauble <djsau...@puppetlabs.com> wrote: > > >>> > - Securely add nodes to your deployment without manually signing > >>> > certificates on the CA... > >>> > - ...so that you can have the advantages of autosigning without > >>> its > >>> > security problems. > > >>> I''m about to engage on a similar effort and was thinking of writing a > >>> puppet face to handle this job. Can you elaborate on the work flow and > >>> solution you''re thinking about? > > >> We''re looking to implement a Puppet Face to address this need. The > >> workflow currently looks like: > > >> 1. Login to the site host > >> 2. Generate a pre-shared key > >> 3. Join a node to the site using the pre-shared key > >> 4. Repeat step 3 for every node you want to add to the site > > >> From the command-line, this workflow might be represented as the > >> following: > >> * > >> node02$ ssh ad...@site02.domain.com > >> Last login: Mon May 7 18:15:43 2012 > >> site02$ mount /media/usbdisk > >> site02$ puppet site generate key > /media/usbdisk/site.key > >> site02$ umount /media/usbdisk > >> site02$ exit > >> node02$ mount /media/usbdisk > >> node02$ puppet node join site02.domain.com < /media/usbdisk/site.key > >> Trying to add node02.domain.com to the site at site02.domain.com... > > >> Use `puppet site status node02.domain.com` to confirm success > > >> To stop waiting for the command to complete, press Ctrl-C. > > >> The command will still complete in the background. > >> Added node02.domain.com to the site at site02.domain.com* > > > will you allow the older workflow to co exists? would it be possible to > > drive all of the process via an external api? > > No, at present we are looking to deprecate the ''clean'', ''generate'', ''list'', > ''revoke'', and ''sign'' actions of > the puppet cert face. The reason for this is we want the semantics of the > user interface to match the > user need. The impression I''ve gotten (and feel free to chime in) is that > users don''t want to sign > certificates, they want to add nodes to their deployment.And remove them, and swap them for different physical nodes with the same name, and change the names of existing physical nodes, and maybe other things. It''s one thing to provide easy ways to do things people often want to do. It''s an altogether different thing to take away people''s tools for doing unusual things, or to make them jump through hoops to do things that ought to be easy. Text interfaces are far more expressive than any other kind, and they are easy to integrate with other tools. That''s the Unix way. By all means, provide all the convenience features and alternative interfaces you think people would like, but don''t take away my CLI. John -- 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.
Does this require that a human being has to be in the loop every time a node joins the site? How would one automate 100% the provisioning of new hosts? With the current system, I can turn on auto-sign and have some simple rules for which nodes I will accept, and trust in the knowledge that I have already ensured my network is secure enough to accept the risk of auto-signing. With that, I can automatically take a bare-metal server, and provision it all the way up to taking traffic without having anyone else involved. From the example above, having to generate the key on the master before I can provision puppet on the node seems to make that much more difficult. Also, it would be good if you specify the issues that Sites is trying to solve in more detail. From my viewpoint, I don''t have any issues with the current CA-based model. So I''m struggling to understand what you are trying to "fix". I''m sure I''m not alone, and I am assuming that I missing some details, so putting a more detailed description of the problems that the community is encountering, and how Sites would solve those would help with the discussion. On Thursday, May 10, 2012 2:34:14 PM UTC-4, Daniel Sauble wrote:> > On Thursday, May 10, 2012 10:39:22 AM UTC-7, windowsrefund wrote: >> >> >> On May 10, 12:44 pm, Daniel Sauble <djsau...@puppetlabs.com> wrote: >> > >> > - Securely add nodes to your deployment without manually signing >> > certificates on the CA... >> > - ...so that you can have the advantages of autosigning without >> its >> > security problems. >> > >> >> I''m about to engage on a similar effort and was thinking of writing a >> puppet face to handle this job. Can you elaborate on the work flow and >> solution you''re thinking about? >> > > We''re looking to implement a Puppet Face to address this need. The > workflow currently looks like: > > > 1. Login to the site host > 2. Generate a pre-shared key > 3. Join a node to the site using the pre-shared key > 4. Repeat step 3 for every node you want to add to the site > > > From the command-line, this workflow might be represented as the following: > * > node02$ ssh admin@site02.domain.com > Last login: Mon May 7 18:15:43 2012 > site02$ mount /media/usbdisk > site02$ puppet site generate key > /media/usbdisk/site.key > site02$ umount /media/usbdisk > site02$ exit > node02$ mount /media/usbdisk > node02$ puppet node join site02.domain.com < /media/usbdisk/site.key > Trying to add node02.domain.com to the site at site02.domain.com... > > Use `puppet site status node02.domain.com` to confirm success > > To stop waiting for the command to complete, press Ctrl-C. > > The command will still complete in the background. > Added node02.domain.com to the site at site02.domain.com* >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/8pW3iqUnj4MJ. 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 Thursday, May 10, 2012 3:05:38 PM UTC-7, jcbollinger wrote:> > > > On May 10, 2:04 pm, Daniel Sauble <djsau...@puppetlabs.com> wrote: > > On Thursday, May 10, 2012 11:37:34 AM UTC-7, ohad wrote: > > > > > On Thu, May 10, 2012 at 9:34 PM, Daniel Sauble < > djsau...@puppetlabs.com>wrote: > > > > >> On Thursday, May 10, 2012 10:39:22 AM UTC-7, windowsrefund wrote: > > > > >>> On May 10, 12:44 pm, Daniel Sauble <djsau...@puppetlabs.com> wrote: > > > > >>> > - Securely add nodes to your deployment without manually > signing > > >>> > certificates on the CA... > > >>> > - ...so that you can have the advantages of autosigning > without > > >>> its > > >>> > security problems. > > > > >>> I''m about to engage on a similar effort and was thinking of writing > a > > >>> puppet face to handle this job. Can you elaborate on the work flow > and > > >>> solution you''re thinking about? > > > > >> We''re looking to implement a Puppet Face to address this need. The > > >> workflow currently looks like: > > > > >> 1. Login to the site host > > >> 2. Generate a pre-shared key > > >> 3. Join a node to the site using the pre-shared key > > >> 4. Repeat step 3 for every node you want to add to the site > > > > >> From the command-line, this workflow might be represented as the > > >> following: > > >> * > > >> node02$ ssh ad...@site02.domain.com > > >> Last login: Mon May 7 18:15:43 2012 > > >> site02$ mount /media/usbdisk > > >> site02$ puppet site generate key > /media/usbdisk/site.key > > >> site02$ umount /media/usbdisk > > >> site02$ exit > > >> node02$ mount /media/usbdisk > > >> node02$ puppet node join site02.domain.com < /media/usbdisk/site.key > > >> Trying to add node02.domain.com to the site at site02.domain.com... > > > > >> Use `puppet site status node02.domain.com` to confirm success > > > > >> To stop waiting for the command to complete, press Ctrl-C. > > > > >> The command will still complete in the background. > > >> Added node02.domain.com to the site at site02.domain.com* > > > > > will you allow the older workflow to co exists? would it be possible > to > > > drive all of the process via an external api? > > > > No, at present we are looking to deprecate the ''clean'', ''generate'', > ''list'', > > ''revoke'', and ''sign'' actions of > > the puppet cert face. The reason for this is we want the semantics of > the > > user interface to match the > > user need. The impression I''ve gotten (and feel free to chime in) is > that > > users don''t want to sign > > certificates, they want to add nodes to their deployment. > > > And remove them, and swap them for different physical nodes with the > same name, and change the names of existing physical nodes, and maybe > other things. > > It''s one thing to provide easy ways to do things people often want to > do. It''s an altogether different thing to take away people''s tools > for doing unusual things, or to make them jump through hoops to do > things that ought to be easy. Text interfaces are far more expressive > than any other kind, and they are easy to integrate with other tools. > That''s the Unix way. By all means, provide all the convenience > features and alternative interfaces you think people would like, but > don''t take away my CLI.I''d like to emphasize that this is purely a change in semantics. Let me elaborate a bit about what the deprecation of these `puppet cert` actions entails, and feel free to push back if you''re still concerned. I apologize for the terseness of my deprecation post. puppet cert fingerprint puppet cert print puppet cert verify (these commands remain as is) puppet cert generate (replaced by `puppet site add`) puppet cert list (replaced by `puppet site list nodes`) puppet cert revoke (replaced by `puppet site remove`) puppet cert sign (replaced by `puppet site accept`) puppet cert clean This command doesn''t map cleanly to sites. In Puppet as it exists today, removing a certificate from the CA doesn''t revoke permission to talk to other Puppet services. In Puppet Sites, removing a node from the site revokes permission for that node to ask the site where other Puppet services live. Because of this, we''re replacing this with two commands (one being the replacement for `puppet cert revoke`): puppet site reject (reject a node''s request to join the site) puppet site remove (remove a node from the site) In Puppet Sites, nodes are still identified by their certname. With the exception of a slight behavior change to the CA--so it can serve as the authoritative source of information about which nodes are in your site--the deprecation of these CA actions is a deprecation of semantics, not functionality. I''m happy to elaborate on the mental model these replacement commands are designed to support. - Daniel -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/W9hQXvYw3v8J. 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.
Kelsey Hightower
2012-May-11 16:29 UTC
Re: [Puppet Users] Re: Puppet Sites. Your thoughts?
On Fri, May 11, 2012 at 12:21 PM, Daniel Sauble <djsauble@puppetlabs.com>wrote:> > > On Thursday, May 10, 2012 3:05:38 PM UTC-7, jcbollinger wrote: >> >> >> >> On May 10, 2:04 pm, Daniel Sauble <djsau...@puppetlabs.com> wrote: >> > On Thursday, May 10, 2012 11:37:34 AM UTC-7, ohad wrote: >> > >> > > On Thu, May 10, 2012 at 9:34 PM, Daniel Sauble < >> djsau...@puppetlabs.com>**wrote: >> > >> > >> On Thursday, May 10, 2012 10:39:22 AM UTC-7, windowsrefund wrote: >> > >> > >>> On May 10, 12:44 pm, Daniel Sauble <djsau...@puppetlabs.com> >> wrote: >> > >> > >>> > - Securely add nodes to your deployment without manually >> signing >> > >>> > certificates on the CA... >> > >>> > - ...so that you can have the advantages of autosigning >> without >> > >>> its >> > >>> > security problems. >> > >> > >>> I''m about to engage on a similar effort and was thinking of writing >> a >> > >>> puppet face to handle this job. Can you elaborate on the work flow >> and >> > >>> solution you''re thinking about? >> > >> > >> We''re looking to implement a Puppet Face to address this need. The >> > >> workflow currently looks like: >> > >> > >> 1. Login to the site host >> > >> 2. Generate a pre-shared key >> > >> 3. Join a node to the site using the pre-shared key >> > >> 4. Repeat step 3 for every node you want to add to the site >> > >> > >> From the command-line, this workflow might be represented as the >> > >> following: >> > >> * >> > >> node02$ ssh ad...@site02.domain.com >> > >> Last login: Mon May 7 18:15:43 2012 >> > >> site02$ mount /media/usbdisk >> > >> site02$ puppet site generate key > /media/usbdisk/site.key >> > >> site02$ umount /media/usbdisk >> > >> site02$ exit >> > >> node02$ mount /media/usbdisk >> > >> node02$ puppet node join site02.domain.com < >> /media/usbdisk/site.key >> > >> Trying to add node02.domain.com to the site at site02.domain.com... >> > >> > >> Use `puppet site status node02.domain.com` to confirm success >> > >> > >> To stop waiting for the command to complete, press Ctrl-C. >> > >> > >> The command will still complete in the background. >> > >> Added node02.domain.com to the site at site02.domain.com* >> > >> > > will you allow the older workflow to co exists? would it be possible >> to >> > > drive all of the process via an external api? >> > >> > No, at present we are looking to deprecate the ''clean'', ''generate'', >> ''list'', >> > ''revoke'', and ''sign'' actions of >> > the puppet cert face. The reason for this is we want the semantics of >> the >> > user interface to match the >> > user need. The impression I''ve gotten (and feel free to chime in) is >> that >> > users don''t want to sign >> > certificates, they want to add nodes to their deployment. >> >> >> And remove them, and swap them for different physical nodes with the >> same name, and change the names of existing physical nodes, and maybe >> other things. >> >> It''s one thing to provide easy ways to do things people often want to >> do. It''s an altogether different thing to take away people''s tools >> for doing unusual things, or to make them jump through hoops to do >> things that ought to be easy. Text interfaces are far more expressive >> than any other kind, and they are easy to integrate with other tools. >> That''s the Unix way. By all means, provide all the convenience >> features and alternative interfaces you think people would like, but >> don''t take away my CLI. > > > I''d like to emphasize that this is purely a change in semantics. Let me > elaborate > a bit about what the deprecation of these `puppet cert` actions entails, > and feel free > to push back if you''re still concerned. I apologize for the terseness of > my > deprecation post. > > puppet cert fingerprint > puppet cert print > puppet cert verify > (these commands remain as is) > > puppet cert generate > (replaced by `puppet site add`) > > puppet cert list > (replaced by `puppet site list nodes`) > > puppet cert revoke > (replaced by `puppet site remove`) > > puppet cert sign > (replaced by `puppet site accept`) > > puppet cert clean > > This command doesn''t map cleanly to sites. In Puppet as it exists today, > removing > a certificate from the CA doesn''t revoke permission to talk to other > Puppet services. > In Puppet Sites, removing a node from the site revokes permission for that > node > to ask the site where other Puppet services live. Because of this, we''re > replacing this > with two commands (one being the replacement for `puppet cert revoke`): > > puppet site reject (reject a node''s request to join the site) > puppet site remove (remove a node from the site) > > In Puppet Sites, nodes are still identified by their certname. With the > exception of a > slight behavior change to the CA--so it can serve as the authoritative > source of information > about which nodes are in your site--the deprecation of these CA actions is > a deprecation of > semantics, not functionality. > > I''m happy to elaborate on the mental model these replacement commands are > designed > to support. > > - Daniel >I guess what people really want to know is: Will they be able to use auto-signing? Will auto-signing still work like it does today? I see the advantages for people who never intend to use auto-signing, but the people who have accepted the risk do want to lose the "functionality" of auto-signing.> -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/puppet-users/-/W9hQXvYw3v8J. > > 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. >-- Kelsey Hightower Developer Puppet Labs (678) 4719501 -- 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 Friday, May 11, 2012 5:56:10 AM UTC-7, Marc Zampetti wrote:> > Does this require that a human being has to be in the loop every time a > node joins the site? How would one automate 100% the provisioning of new > hosts? With the current system, I can turn on auto-sign and have some > simple rules for which nodes I will accept, and trust in the knowledge that > I have already ensured my network is secure enough to accept the risk of > auto-signing. With that, I can automatically take a bare-metal server, and > provision it all the way up to taking traffic without having anyone else > involved. From the example above, having to generate the key on the master > before I can provision puppet on the node seems to make that much more > difficult. >We don''t want Puppet admins to have to trust that their network is secure. What Puppet Sites provides (among other things) is a PSK system that allows you to generate multiple-use keys for securely joining nodes to your site. In the provisioning case, you could generate a pre-shared key, bake it into your install tarball, and use that tarball to install Puppet and add each node to your site without human intervention. When you''re done installing, you can revoke the PSK so it can''t be used anymore. This gets you the convenience of autosigning with the confidence that even if your network is compromised, your Puppet deployment won''t be. But note that you can still use autosigning if you don''t want to mess with pre-shared keys, or if you trust your network. We''re just providing an alternative, not a replacement. If you want to manually execute `puppet site accept` for each node that tries to join your site, you can do that too.> Also, it would be good if you specify the issues that Sites is trying to > solve in more detail. From my viewpoint, I don''t have any issues with the > current CA-based model. So I''m struggling to understand what you are trying > to "fix". I''m sure I''m not alone, and I am assuming that I missing some > details, so putting a more detailed description of the problems that the > community is encountering, and how Sites would solve those would help with > the discussion.One problem is that there isn''t an authoritative source of information about which nodes are in your deployment. The CA comes close, but since you can remove the certificates of managed nodes, it doesn''t fit the bill. That''s one thing that Puppet Sites gets you. The ability to run a single command and know with certainty which nodes you''re managing. Another problem is that if you move services around, you have to update puppet.conf on all nodes that use that service. For example, if you migrate your master to a new host, you have to update puppet.conf on every agent that uses that master. What Puppet Sites provides is a service registry that allows you to store this information in a central location. Your agents retrieve service connection information from the service registry. So, if your master switches to a different host, all you need do is update the host in the service registry, and all your agents will pick up that change automatically. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/d-aNxTfDTSYJ. 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.
Just concerning this PSK aspect of Sites, would this also be a similar alternative to using a shared cert (or set of certs) in tandem with the node_name_value or node_name_fact, as was recently discussed in this thread? https://groups.google.com/d/msg/puppet-users/2s0PJ7p_S7M/jLVUjL34Wz4J In evaluating our implementation strategy for Puppet, I''d considered using this method to allow me to more freely deploy/recycle nodes and with one less human involved. Tim On 2012-05-11, at 12:39 PM, Daniel Sauble wrote:> We don''t want Puppet admins to have to trust that their network is secure. What Puppet Sites provides (among other things) is a PSK system that allows you to generate multiple-use keys for securely joining nodes to your site. In the provisioning case, you could generate a pre-shared key, bake it into your install tarball, and use that tarball to install Puppet and add each node to your site without human intervention. When you''re done installing, you can revoke the PSK so it can''t be used anymore. This gets you the convenience of autosigning with the confidence that even if your network is compromised, your Puppet deployment won''t be. > > But note that you can still use autosigning if you don''t want to mess with pre-shared keys, or if you trust your network. We''re just providing an alternative, not a replacement.-- 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.
Just concerning this PSK aspect of Sites, would this also be a similar alternative to using a shared cert (or set of certs) in tandem with the node_name_value or node_name_fact, as was recently suggested by Gary in this thread? https://groups.google.com/d/msg/puppet-users/2s0PJ7p_S7M/jLVUjL34Wz4J We''re just evaluating Puppet now, but I''d considered using this strategy with my cert(s) to allow me to more freely deploy/recycle nodes and with one less human involved. Tim On Friday, 11 May 2012 12:39:40 UTC-4, Daniel Sauble wrote:> > We don''t want Puppet admins to have to trust that their network is secure. > What Puppet Sites provides (among other things) is a PSK system that allows > you to generate multiple-use keys for securely joining nodes to your site. > In the provisioning case, you could generate a pre-shared key, bake it into > your install tarball, and use that tarball to install Puppet and add each > node to your site without human intervention. When you''re done installing, > you can revoke the PSK so it can''t be used anymore. This gets you the > convenience of autosigning with the confidence that even if your network is > compromised, your Puppet deployment won''t be. > > But note that you can still use autosigning if you don''t want to mess with > pre-shared keys, or if you trust your network. We''re just providing an > alternative, not a replacement. > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/tlhNPcDx9iIJ. 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 Saturday, May 12, 2012 6:14:06 AM UTC-7, Timothy Sutton wrote:> > Just concerning this PSK aspect of Sites, would this also be a similar > alternative to using a shared cert (or set of certs) in tandem with the > node_name_value or node_name_fact, as was recently suggested by Gary in > this thread? > > Yes, absolutely. However, since you''re not reusing the same private keyfor all nodes in your deployment, Sites is a more secure approach to the problem. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/gCtD3UXn13QJ. 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 have no issue with the PSK technique BUT, I do have a couple questions/concerns: 1) Please keep the old syntax in place so that users don''t have to run about modifying scripts everywhere. Internal command aliases should work fine. 2) You say that we shouldn''t be trusting the network (fine), but now we''re to distribute a PSK via an unsigned format (tar) over what medium? If you don''t have some sort of authenticator/identifier for your clients, anyone on the network could make the connection and snag the PSK, though it may be encrypted with HTTPS or somesuch. This is (unfortunately) just a hard problem if you can''t trust your network to some degree. Perhaps, you could bind it to the MAC address somehow? Then you only need to worry about MAC spoofing and firewalls, etc.... Another option would be TPM registration, but I don''t know that you want to get into all that. What about Kerberos support? That would allow for another realm of authentication possibilities. Trevor On Mon, May 14, 2012 at 11:49 AM, Daniel Sauble <djsauble@puppetlabs.com> wrote:> > > On Saturday, May 12, 2012 6:14:06 AM UTC-7, Timothy Sutton wrote: >> >> Just concerning this PSK aspect of Sites, would this also be a similar >> alternative to using a shared cert (or set of certs) in tandem with the >> node_name_value or node_name_fact, as was recently suggested by Gary in this >> thread? >> >> > Yes, absolutely. However, since you''re not reusing the same private key for > all nodes in your deployment, Sites is a more secure approach to the > problem. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/puppet-users/-/gCtD3UXn13QJ. > > 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.-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- 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 Mon, May 14, 2012 at 1:14 PM, Trevor Vaughan <tvaughan@onyxpoint.com>wrote:> I have no issue with the PSK technique BUT, I do have a couple > questions/concerns: > > 1) Please keep the old syntax in place so that users don''t have to run > about modifying scripts everywhere. Internal command aliases should > work fine. > > 2) You say that we shouldn''t be trusting the network (fine), but now > we''re to distribute a PSK via an unsigned format (tar) over what > medium? If you don''t have some sort of authenticator/identifier for > your clients, anyone on the network could make the connection and snag > the PSK, though it may be encrypted with HTTPS or somesuch. >We have a number of concerns internally about literal pre-shared keys and you''ve identified them directly. We think pre-shared-keys will degrade our security model of public key cryptography if used improperly. As a result, we haven''t fully scrubbed the term "PSK" from all of our notes and material on Puppet Sites but we''re thinking that it might be a token or another public key itself that doesn''t degrade our public key model to that of a shared secret model.> This is (unfortunately) just a hard problem if you can''t trust your > network to some degree. >Exactly. We''re planning to address this problem with Sites by making it easier to setup Puppet in a secure way while also preserving our "secure out of the box" implementation of x.509 and trusted third party public key authentication. -Jeff -- 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, 2012-05-11 at 09:39 -0700, Daniel Sauble wrote:> Another problem is that if you move services around, you have to > update puppet.conf on all nodes that use that service. For example, if > you migrate your master to a new host, you have to update puppet.conf > on every agent that uses that master. What Puppet Sites provides is a > service registry that allows you to store this information in a > central location. Your agents retrieve service connection information > from the service registry. So, if your master switches to a different > host, all you need do is update the host in the service registry, and > all your agents will pick up that change automatically.Daniel, Sorry for chiming in late, but I''m just catching up on this discussion. I didn''t see explicit mention of it one way or the other, but I would hope that whatever mechanism you are using for the service registry will support some type of inheritance mechanism for assigning the configuration settings at fairly arbitrary levels/grouping and not just globally with per-host overrides. At $WORK we are a multi-tenant environment and differing customer needs mean that there is a potential for potentially significant Puppet configuration variances from environment to environment. For instance, one customer may have their own Puppetmaster environment for catalogs/files, but share the common CA, while most other customers use a shared set of Puppetmasters. We have created a "$customer" variable within Puppet (available with every host) that we use with Hiera to select out any per-customer settings. We aren''t currently but may even select Puppetmasters based on datacenter (so, $customer and $datacenter as either/or selectors with a likely global default). Having to manage customer-wide variances per-host would quickly get pretty unmanageable. Right now our puppet.conf files are generated via templates (with data pulled from Hiera) and deployed by Puppet to take into account any variances. I like the Sites concept, but it would have to account for a similarly high degree of flexibility to be something we''d be able to use. Thanks, Sean -- 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 Friday, May 18, 2012 6:58:37 AM UTC-7, seanmil wrote:> > On Fri, 2012-05-11 at 09:39 -0700, Daniel Sauble wrote: > > Another problem is that if you move services around, you have to > > update puppet.conf on all nodes that use that service. For example, if > > you migrate your master to a new host, you have to update puppet.conf > > on every agent that uses that master. What Puppet Sites provides is a > > service registry that allows you to store this information in a > > central location. Your agents retrieve service connection information > > from the service registry. So, if your master switches to a different > > host, all you need do is update the host in the service registry, and > > all your agents will pick up that change automatically. > > Sorry for chiming in late, but I''m just catching up on this discussion. > I didn''t see explicit mention of it one way or the other, but I would > hope that whatever mechanism you are using for the service registry will > support some type of inheritance mechanism for assigning the > configuration settings at fairly arbitrary levels/grouping and not just > globally with per-host overrides.We''ve been kicking around the idea of "sites of sites", where each site could inherit from a parent site, contain a subset of the nodes in the root site, and override service registry data as needed. We don''t have the details hashed out entirely, so feedback like yours will help us converge on something useful, but our goal is to provide some kind of hierarchical service registry without reinventing Hiera. It''s a sticky problem. In order to provide a superior user experience, we decided to drop hierarchical sites from the initial release of Puppet Sites. So, expect hierarchical sites in the future, when we''ve had a chance to learn and iterate. Thanks for the feedback, - Daniel -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/WzQ_lk13N5kJ. 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.