On Wed, Sep 15, 2010 at 11:35 AM, Luke Kanies <[email protected]> wrote:
> Shouldn't 'none' be a valid state? Or maybe 'unknown'? I would think > that's different from 'invalid'. > Do you mean if the user requests information about a host for which there is neither a certificate request nor a certificate? I think I would prefer to use a JSON "null" value for this case (equivalent to Ruby's "nil"). That would be more consistent with the existing REST API's and with the semantics of "certificate_statuses". To cause the master to discard certificate information for a given > host, issue a DELETE request to > https://<master>/<environment>/certificate_status/<hostname>. > > This takes the place of the "puppet cert" option "--clean". > > > This is essentially a superset of cert deletion and csr deletion (I don't > actually know if 'clean' removes a host from the CRL). Not a problem, but > worth noting that that behavior can be had already, albeit not as cleanly. > Yes, good point. > > certificate and certificate_request > ----------------------------------- > > The existing REST APIs for > https://<master>/<environment>/certificate/<hostname> and > https://<master>/<environment>/certificate_request/<hostname> (which > are already used internally for exchanging certificates and requests > between master and agent) are extended to support a human-readable > text format. This format is only supported for reading. This takes > the place of the "puppet cert" option "--print", and uses the same > format. > > > This seems less than ideal because it probably violates the principle of > least surprise for most people. There's a very standard text format for > certs - PEM-encoding. I'd recommend either having separate formats -- > maybe there's an existing MIME type for PEM? -- or stick to plain PEM > encoding in a text format, and then let the client decide how to deal with > it. Anyone with an ssl lib can convert from one to the other. OTOH, I > expect that certs are currently passed down as PEM-encoded text, so maybe > this is me being crazy. > You're right that anyone with an ssl lib can convert between the two formats. Can we count on clients of the REST API to have access to an ssl lib? If so, I'd be happy to drop this feature. If we decide to keep it, I agree that we should have separate formats distinguished by MIME type. The "human readable text" format would be solely for the benefit of REST API clients that didn't have easy access to an ssl lib, and all other clients (including puppet itself) would continue to use the PEM-encoded format that's already implemented today. > Will the 'puppet cert' command be extended to support both remote and local > options? That is, if I'm a Puppet user, would I be able to manage certs on > my workstation against the central server using commands shipped with > Puppet, or will I still need to be on the server if I don't want to write > code? > > This seems like a great optional feature, anyway, and should be relatively > inexpensive to add. > That's a good idea. I can't see any reason why not. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
