On 06/17/2015 01:09 PM, Fraser Tweedale wrote:
On Wed, Jun 17, 2015 at 12:28:33PM +0200, thierry bordaz wrote:
Hello Fraser,

    The schema is propagated on all replica. So if you update the
    schema, the updates will be eventually present everywhere.
    There is two ways to update the schema.

      * online update (prefered), you simply do a ldapmodify on
        'cn=schema' adding/updating attributetypes/objectclasses
      * offline. You stop a replica/master, update the schema files,
        start the server. This is not the prefered solution because
        depending on version of DS it can take more time to detect the
        new schema and propagated it.

    Do you know how CS schema upgrade will be done (online/offline) ?
    Is it the new definitions
    http://www.freeipa.org/page/V4/Certificate_Profiles#Schema ?

    Thanks
    thierry

Thanks Thierry for your detailed reply!  The schema is actually
defined by Dogtag and is used only by the Dogtag directory tree
(under DN o=ipa-ca).  I will do an online update.

Cheers,
Fraser

Hi Fraser,

The schema is per DS instance so all suffixes will share the same schema.
Now only o=ipaca entries will use the new definitions.

During upgrade, if you do online update of 'cn=schema', the next update (on main sufix or o=ipaca) will trigger the replication of those definitions. The exact replication scenario of the schema depends on the version of DS but the definitions should eventually be present on all instances. You may check if the definitions are propagated on each instance with 'ldapsearch -h <host> -p 389 -D "cn=directory manager" -w ... -b "cn=schema" attributetypes objectclasses.

I am not sure what is the 'Migrate file-base profile' scenario. Is it an import (ldif2db) of new profiles with entries containing new schema defintions ?

thanks
thierry

On 06/17/2015 07:52 AM, Martin Kosek wrote:
On 06/16/2015 06:39 PM, Fraser Tweedale wrote:
I fixed several issues which broke Dogtag upgrades involving
particular versions; these will be in the next release.

I haven't yet gotten to to the reported failure running
ipa-replica-upgrade on a replica (but I haven't forgotten about it
either.)  This is the only issue affecting *fresh installs* that I
am aware of.  If you know of others please let me know!

The remaining Dogtag-related upgrade problem is caused by new DS
schema on the Dogtag side, which is used for LDAP-based profiles.
There is not yet an automatic schema upgrade facility for Dogtag, so
the new schema was missing.

The planned approach is:

- Either Dogtag or FreeIPA will add the new CS schema on upgrade.
   (Eventually Dogtag will need to manage its own schema updates but
   right now there is no facility, and the new schema is only used by
   IPA.)
If possible, I would prefer Dogtag to update the schema the best it can,
otherwise there is a risk of collisions or upgrade breakages if FreeIPA
starts updating Dogtag internals.

- Migrate file-based profiles into LDAP during IPA upgrade.  But for
   this to work, I need to make sure that if new schema is added,
   then entries that use the new schema, replication to instances
   that did not yet have the new schema will not break.  Anyone who
   knows LDAP better than me, please share your knowledge!
Shouldn't schema just replicate, when the first FreeIPA+CS is upgraded?
CCing Thierry for reference, he had a lot of fun with schema upgrades.

- If my assumptions about replication are wrong, the best approach
   will probably be to have the administrator perform profile
   migration (via a script) as a later task, after all replicas have
   been upgraded.
Not a fan of this, FreeIPA upgrades should be ideally automatic and
straightforward. So far we did not have problems with automatic upgrades
(well, except Dogtag9->Dogtag10 upgrade - I would prefer not to have such
situation again).

Thanks for updates!
Martin

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to