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. >> >> Thanks, >> Fraser >> _______________________________________________ >> FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org >> To unsubscribe send an email to freeipa-devel-leave@lists.fedorahoste >> d.org > _______________________________________________ > FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org > To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
-- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869
signature.asc
Description: OpenPGP digital signature
_______________________________________________ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org