4:31 a.m.
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
11:03 a.m.
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.
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.
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.
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.
--
Endi S. Dewata
11:31 a.m.
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?
11:51 a.m.
> 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.
Right, I meant to say DS of the server being upgraded must be running
(last minute changes messed it up). If IPA is shutdown, to my
understanding it will shutdown the DS too.
--
Endi S. Dewata
2:08 a.m.
Updated patch attached - it now merely adds the schema update file,
in the simple format that FreeIPA's schema update machinery uses.
If it's ACKed and I'm not around, please push it as we need it in
10.2.5.
Thanks,
Fraser
On Thu, Jun 18, 2015 at 11:51:59AM -0500, Endi Sukma Dewata wrote:
>>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.
Right, I meant to say DS of the server being upgraded must be running (last
minute changes messed it up). If IPA is shutdown, to my understanding it
will shutdown the DS too.
--
Endi S. Dewata
10:53 a.m.
On 6/19/2015 2:08 AM, Fraser Tweedale wrote:
Updated patch attached - it now merely adds the schema update file,
in the simple format that FreeIPA's schema update machinery uses.
If it's ACKed and I'm not around, please push it as we need it in
10.2.5.
Thanks,
Fraser
ACK and pushed to master.
--
Endi S. Dewata
3474
days inactive
3475
days old
5 comments
3 participants
participants (3)
-
Ade Lee -
Endi Sukma Dewata -
Fraser Tweedale