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.
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
>
> Thanks,
> Fraser
> _______________________________________________
> FreeIPA-devel mailing list -- freeipa-devel(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-devel-leave(a)lists.fedorahoste
> d.org