#2961 [RFE] Add update metadata to LDAP updater
Opened 11 years ago by mkosek. Modified 7 years ago

Problem:

Our LDAP updates cannot distinguish updates that have been already done in the past (with earlier IPA version) and new updates that were not done yet. This affects for example those updates:

40-dns.update:

dn: cn=Update PBAC memberOf $TIME, cn=memberof task, cn=tasks, cn=config
add: objectClass: top
add: objectClass: extensibleObject
add: cn: IPA PBAC memberOf $TIME
add: basedn: 'cn=privileges,cn=pbac,$SUFFIX'
add: filter: (objectclass=*)
add: ttl: 10

The task that was added due to missing member/memberOf pair for permissions in the past is now run every time because updater does not know if the pairs were fixed yet.

Another example:

60-trusts.update:

# Add the default PAC type to configuration
dn: cn=ipaConfig,cn=etc,$SUFFIX
addifnew: ipaKrbAuthzData: MS-PAC

If user deletes this setting after the upgrade, it will be restored during the next upgrade because addifnew cannot know that the update was already proceeded.

Proposed solution:

We should have an space in the directory where we should write some metadata to LDAP update status. For chosen (all?) updates like the above we should have a not if the update was already performed or not.

There should be 2 such spaces - one for shared tree ($SUFFIX) between all replicas placed in a shared tree and one non-shared tree (cn=config, etc.) placed outside of a shared tree.

In the update files we should be able to mark the metadata name, type and value, for example:

updateifnew: shared:PBACupdate:1
dn: cn=Update PBAC memberOf $TIME, cn=memberof task, cn=tasks, cn=config
add: objectClass: top
add: objectClass: extensibleObject
add: cn: IPA PBAC memberOf $TIME
add: basedn: 'cn=privileges,cn=pbac,$SUFFIX'
add: filter: (objectclass=*)
add: ttl: 10

The first line means that the update should be done only when it is a new update and i.e. PBACupdate in the shared metadata space version is lower than 1 or not set. If we would want to run the update again for already updated version, we could just change the first line to:

updateifnew: shared:PBACupdate:2

I agree with using name for each upgrade, but I am not sure I understand the reason to have an index number.

I think we should just use a unique name for each new upgrade and if an admin or a developer need to replay an update all he needs to do is to delete the corresponding update entry.

The name could be marked with some version/release in the name as well to give a better indication of when the update is supposed to be performed, but that's not required. We could as well use uuids, what matters is that 2 distinct updates must not use the same name so, some automation to come up with unique names or to check we do not have duplicates would be nice.

Changing 3.2 priority

If this is implemented the heuristic in the update_services.py plugin added by https://fedorahosted.org/freeipa/ticket/2960 should be replaced by the solution used here.

Metadata Update from @mkosek:
- Issue assigned to rcritten
- Issue set to the milestone: Future Releases

7 years ago

Login to comment on this ticket.

Metadata