[Freeipa-devel] Re: [DESIGN] Certificate profile update mechanism

[Fraser Tweedale via FreeIPA-devel]

On Mon, Jul 10, 2017 at 12:44:40PM +0200, Tomas Krizek wrote:
> 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).
_______________________________________________
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org