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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
