[Pki-devel] [PATCH] 0042 Upgrade: add scriptlet to add profile schema

[Ade Lee]

On Thu, 2015-06-18 at 11:03 -0500, Endi Sukma Dewata wrote:
> On 6/18/2015 4:31 AM, Fraser Tweedale wrote:
> > Attached patch adds upgrade scriptlet to add the certprofile schema.
> > This must be in the next build.
> >
> > Side note: future cleanup should probably now remove the profiles
> > attributeTypes and objectClass from the main schema.ldif, and the
> > install script updated to import all the various schema files.  This
> > should make schema updates easier to do, and hard to forget! in the
> > future.
> >
> > Thanks,
> > Fraser
> 
> One issue, all upgrade scripts must be idempotent, so the script should 
> either check before modifying each item, or ignore failures of each 
> modification (I think ldapmodify has a -c option). This is necessary 
> because the script may need to run again, and also it's needed by 
> replica to avoid conflicts with changes coming from master.
> 
> There are several restrictions imposed by the simultaneous database & 
> package upgrade which should be document somewhere, and this applies to 
> both standalone Dogtag and IPA:
> 
> 1. The all DS replicas must be running when the package is installed, 
> otherwise the upgrade will fail.
> 
Not necessarily.  Dogtag schema shows up in 99user.ldif which means they
are replicated.  Schema changes are replicated, which means they really
only need to be done on one server.  If a replica is down, it will
eventually have the change replicated to it when it replays the
changelog.

> 2. The upgrade must be done one server at a time, and the changes must 
> be completely replicated before upgrading another replica, otherwise the 
> changes might collide.
> 

There should be a check to see whether the change has already been
performed - either through replication or from being applied through
package upgrade.

What we really need for database changes is a database version that we
can query. 

> 3. The changes must be backward compatible, otherwise replicas that have 
> not been upgraded yet may have a problem.
> 
> 4. Changes to the database/configuration in all replicas should be 
> limited or prevented until all replicas are upgraded, otherwise it may 
> cause inconsistencies.
> 
> 5. If nuxwdog is enabled, the password.conf may not exist. The 
> password.conf must be restored at least temporarily, otherwise the 
> upgrade will fail.
> 

This will likely not work for IPA systems.  We talk to the DB using the
dbuser which uses client cert authentication to authenticate to the db.
If I recall correctly, the directory manager password is removed from
password.conf.  The dbuser does not have permissions to make schema
changes.

In your code, there is no provision for cases where the password does
not exist.

> 6. Upgrade failures may not be known immediately unless the admin checks 
> the upgrade log, or discovers that some functionalities are not working.
> 
> 7. It's not possible to dry-run database upgrade. Depending on the 
> changes, it may not be possible to revert database changes. The admin 
> should be advised to create a backup before upgrade.
> 
> 8. The admin should be careful with yum/dnf updates since it could 
> trigger unplanned upgrade.
> 
> If the one issue above is fixed, and these restrictions are acceptable, 
> it's ACKed.
> 
> In the next update I suggest we move all schema files into 
> /usr/share/pki/server/schema.
> 
> Just a note, with a post-install database upgrade these restrictions may 
> not exist or can be handled in a better way. If possible we might want 
> to support both mechanisms: simultaneous upgrade for IPA or for certain 
> scenarios, and post-install upgrade for Dogtag in general.
> 

Given all this, do we really want to have db changes as part of the auto
upgrade?