übercerts

James Bowes jbowes at redhat.com
Mon Sep 12 13:06:19 UTC 2011


On Fri, Sep 09, 2011 at 10:38:38AM -0300, Dmitri Dolguikh wrote:
> On 11-09-09 10:29 AM, Michael Stead wrote:
> >On 09/09/2011 09:22 AM, Dmitri Dolguikh wrote:
> >>I ran into an issue with how content path is being created in
> >>entitlement certificates generated by candlepin when working on
> >>übercert functionality. Übercert is an entitlement certificate
> >>that has a single piece of content with the url of
> >>"/owner_name_goes_here" (this would grant access to all urls
> >>below the one specified).
> >>
> >>During entitlement certificate generation candlepin prefixes all
> >>content urls with owner-specific prefix (/owner_name/$env in
> >>general case). One way to handle this situation would be to move
> >>all übercert-related logic to candlepin (internal candlepin api
> >>allows to bypass prefix addition during cert generation). This
> >>would also have a benefit (imo) of bypassing async cert
> >>regeneration, since in this particular case it would be a bit of
> >>an overkill.
> >
> >I like this approach better. It seems a lot cleaner to me than
> >just adding a somewhat buried notion of "if startswith // than do
> >this". Would this be done as a new resource, or just bolted onto
> >an existing? What sort of 'übercert-related logic' are we talking
> >about here?
> I was thinking about adding a new resource - something like:
> /owner/:id/uebercert with POST and GET. The logic is roughly:
> 
> - create a special Product "ueber_product"
> - create content "ueber_content"
> - add content to product
> - create subscription for "ueber_product"
> - refresh pools
> - create consumer that will be used to consume the entitlement -
> "ueber_consumer"
> - and, finally, consume the entitlement and return the certificate
> 
> I'm thinking that on a subsequent POST the entitlement cert can be
> re-generated.
> 
> -d
> >
> >>
> >>Another approach would be for katello to create content with url
> >>in some specific form (one suggestion was to use '//' at the
> >>start of the url, e.g. "//ACME_Corporation"), and bypass prefix
> >>addition for such urls on candlepin side.
> >>
> >>I'm not a big fan of #2. Thoughts/opinions?
> >>
> >>Cheers,
> >>-d

This content prefix stuff is on the owner, and its pretty deep down in
the candlepin code. I'm fine with doing it in candlepin, then. the idea
of a specific url for it as you suggested also looks good. My only
concern is this is a developement only thing, right? so we'd want to
have an option toggle for it or something (plugin?)


-James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/candlepin/attachments/20110912/e9dbab2d/attachment.sig>


More information about the candlepin mailing list