This is an example of how objectclass modification looks like now:
replace:objectClasses:( 2.16.840.1.113730.3.8.6.1 NAME 'idnsZone' DESC 'Zone class' SUP idnsRecord STRUCTURAL MUST ( idnsZoneActive $$ idnsSOAmName $$ idnsSOArName $$ idnsSOAserial $$ idnsSOArefresh $$ idnsSOAretry $$ idnsSOAexpire $$ idnsSOAminimum ) MAY idnsUpdatePolicy )::( 2.16.840.1.113730.3.8.6.1 NAME 'idnsZone' DESC 'Zone class' SUP idnsRecord STRUCTURAL MUST ( idnsName $$ idnsZoneActive $$ idnsSOAmName $$ idnsSOArName $$ idnsSOAserial $$ idnsSOArefresh $$ idnsSOAretry $$ idnsSOAexpire $$ idnsSOAminimum ) MAY ( idnsUpdatePolicy $$ idnsAllowQuery $$ idnsAllowTransfer $$ idnsAllowSyncPTR $$ idnsForwardPolicy $$ idnsForwarders ) )
However, this entry is complicated and very error prone if the original schema slightly changes (for example when X-ORIGIN changes). A failure to update such objectclass can lead to serious issues in dirsrv.
I think we should create special LDAP updater actions for objectclasses and attributetypes with this syntax:
replaceoc:OID:newOCDefinion replaceatypes:OID:newAttributeTypesDefinition
The above example would then look like this:
replaceoc:2.16.840.1.113730.3.8.6.1:( 2.16.840.1.113730.3.8.6.1 NAME 'idnsZone' DESC 'Zone class' SUP idnsRecord STRUCTURAL MUST ( idnsName $$ idnsZoneActive $$ idnsSOAmName $$ idnsSOArName $$ idnsSOAserial $$ idnsSOArefresh $$ idnsSOAretry $$ idnsSOAexpire $$ idnsSOAminimum ) MAY ( idnsUpdatePolicy $$ idnsAllowQuery $$ idnsAllowTransfer $$ idnsAllowSyncPTR $$ idnsForwardPolicy $$ idnsForwarders ) )
Unless we we any upgrade issues, putting into 3.1 for now
I just had a discussion with a jhogarth on #freeipa channel - he encountered an upgrade issue when X-ORIGIN of his idnsZone object class was different than we expected it to be and this an upgrade of this objectclass failed. He was then unable to use the new attributes present in the updated objectclass.
jhogarth
#freeipa
idnsZone
Excerpt from the communication:
(05:12:20 PM) jhogarth: just updated to IPA 2.2 … when trying to prepare a replica I get: preparation of replica failed: attribute "idnsAllowQuery" not allowed - any ideas? (05:16:27 PM) jhogarth: hmm only happened when trying to include an IP address with the prepare … prepare worked with out it - trying to add replica now (05:17:18 PM) mkosek: jhogarth: this looks like idnsZone objectclass was not updated correctly in your server instance (05:18:04 PM) mkosek: jhogarth: idnsAllowQuery should be a member of this object class from version 2.2 and later (05:21:55 PM) mkosek: jhogarth: can you check on the IPA server how is idnsZone object class defined? This command shoud do the job: ldapsearch -h localhost -D "cn=Directory Manager" -x -W -b cn=schema objectClasses | grep -C 3 idnsZone (05:24:51 PM) jhogarth: mkosek: checking now (05:26:35 PM) jhogarth: here's teh output of that: http://pastebin.com/Dj8Y06xW (05:28:04 PM) jhogarth: mkosek: replica installed fine with no —ip-address option in the prepare - full CA/DNS ipa-replica-install worked (05:28:48 PM) mkosek: jhogarth: ok, cool. This will work fine until you want to add a new DNS zone or define query or zone transfer ACLs (05:29:45 PM) jhogarth: gotcha …. fortunately I don't need that yet… end of day here now in UK - will test tomorrow to confirm behavior (05:29:56 PM) mkosek: jhogarth: I could give you an LDIF that would update the object class in your IPA server install until the upgrade procedure is fixed in IPA (05:30:09 PM) jhogarth: that'd be handy
jhofarth's objectclass contained X-ORIGIN 'user defined':
X-ORIGIN 'user defined'
objectClasses: ( 2.16.840.1.113730.3.8.6.1 NAME 'idnsZone' DESC 'Zone class' S UP idnsRecord STRUCTURAL MUST ( idnsZoneActive $ idnsSOAmName $ idnsSOArName $ idnsSOAserial $ idnsSOArefresh $ idnsSOAretry $ idnsSOAexpire $ idnsSOAmini mum ) MAY idnsUpdatePolicy X-ORIGIN 'user defined' )
We expected that there is no object class, which caused the aforementioned issue.
Moving to NEEDS_TRIAGE to discuss the ticket priority.
LDIF to manually update idnsZone class - when automatic upgrade fails update-idnszone-oc.ldif
Attached LDIF can be used in the above case when automatic LDAP update fails due to mismatch in X-ORIGIN.
X-ORIGIN
To apply the LDIF the following command can be used:
# ldapmodify -h localhost -D "cn=Directory Manager" -x -W -f update-idnszone-oc.ldif
To verify that idnsAllowTransfer attribute has been added to objectclasses:
idnsAllowTransfer
# ldapsearch -h localhost -D "cn=Directory Manager" -x -W -b cn=schema objectClasses | grep -C 3 idnsZone
attachment freeipa-mkosek-298-add-safe-updates-for-objectclasses.patch
Patch freeipa-mkosek-298-add-safe-updates-for-objectclasses.patch sent for review
The final result was no new directive for updating objectclasses. Instead the objectclasses are normalized so the comparison is more reliable.
master: 917a480
ipa-3-0: dc22527
Moving closed RC1 tickets to Beta 3.
Metadata Update from @mkosek: - Issue assigned to mkosek - Issue set to the milestone: FreeIPA 3.0 Beta 3
Login to comment on this ticket.