On 07/10/2017 12:16 PM, Simo Sorce via FreeIPA-devel wrote:
> Hi Fraser,
> I think you put on a reasonable proposal, however If I had to design
> this right now and had the freedom to change dogtag and the rest of
> freeipa to cope I would do the following:
>
> - Change the LDAP profile storage to have versioned subtrees for
> "system" profiles, and have a "custom" subtree for user
profiles.
>
> - In the base tree have a version attribute that set what version
> dogtag should use, if absent dogtag will assume its current hardcoded
> default version. Profiles are never updated per se, a new version is
> installed and the version is upped.
>
> - On upgrade a modified profile is moved to the "custom" tree and the
> original version of the profile is stored in the system tree. This is
> assuming this does not cause older versions of dogtag to misbehave,
> otherwise we keep the modified version and make sure not to raise the
> version to use. We also find a way to notify the admin he should move
> customized profiles in the correct new section and leave system
> profiles alone.
>
> - Potentially if a dogtag server does not understand a new version, it
> keeps using an older version (perhaps we can have a "mandatory version
> attribute" to cause older versions to return an error instead. (see
> also previous case)
>
> The reason for this is that having a complex check on ipa versions is
> potentially fragile as well it adds yet another dimension to the things
> an admin need to know about to figure out why its domain is not using
> the "right" profiles.
> And I think in some cases there is no "conflict" between version
> profiles only new "optional" attributes you may want to add/support.
>
> The other option is to tie the dogtag profiles version to the domain
> level as well, and only ever use new ones when the whole domain level
> is upped. This is conditional on newer versions of dogtag being able to
> use older profile versions without modification in LDAP.
I'd rather avoid any domain level bumps unless there is serious
justification for it. Additional domain levels introduce big testing
overhead.
> HTH,
> Simo.
>
>
> On Sat, 2017-07-08 at 15:24 +1000, Fraser Tweedale via FreeIPA-devel
> wrote:
>> Hi all,
>>
>> I've published a draft design for the profile update mechanism.
>> This feature is to ensure that we can safely update included
>> profiles even when we use Dogtag profile components only available
>> in new versions.
>>
>>
https://www.freeipa.org/page/V4/Certificate_profile_update_mechanism
>>
>> Interested persons, please review the design. In particular there
>> are two main questions I would like to discuss:
>>
>> 1. We need to store the IPA version in IPA master entries. What
>> should be the schema?
>>
>>
https://www.freeipa.org/page/V4/Certificate_profile_update_mechani
>> sm#IPA_master_entries
>>
>> 2. How should we deal with customised versions of included profiles?
>> There is a big tradeoff here, of complexity + flexibility vs.
>> simplicitity + reverting customisations to included profiles (and
>> preventing them in future).
>>
>>
https://www.freeipa.org/page/V4/Certificate_profile_update_mechani
>> sm#Dealing_with_modified_profiles
>>
I'm in favor of not supporting customized versions. I'm not sure how
common it is to customize these profiles among users. Unless it is very
common, I wouldn't support them to avoid the additional complexity. The
users always have the option to automate these customizations after
every server upgrade, if they really require them.
I agree - unfortunately we currently allow them so the questions
about how to deal with this remain (even if we transition to
preventing modification of included profiles in future).