übercerts

Bryan Kearney bkearney at redhat.com
Mon Sep 12 13:14:25 UTC 2011


On 09/12/2011 09:06 AM, James Bowes wrote:
> 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
>

No.. this is production. Help customers create debug certs which they 
can hand out internally.

-- bk





More information about the candlepin mailing list