#2440 Improve schema modifications in LDAP updater
Closed: Fixed None Opened 6 years ago by mkosek.

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.

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':

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.

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:

# ldapsearch -h localhost -D "cn=Directory Manager" -x -W -b cn=schema objectClasses | grep -C 3 idnsZone

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

2 years ago

Login to comment on this ticket.

Metadata