Also found during the upgrade that these files have issues:

10-bind-schema.update --> "$$" should be "$"
10-RFC4876.update --> "$$" should be "$"
--> attributeType values should not be quoted "" Example attributeType authenticationMethod

I think this is all of them, but I am running more tests and I should have the final results this afternoon.

Note that .update files are handled by IPA's own parser, which does variable substitution (so $s need to be doubled) and also CSV parsing (so sometimes, values must be quoted).

Replying to [comment:4 pviktori]:

Note that .update files are handled by IPA's own parser, which does variable substitution (so $s need to be doubled) and also CSV parsing (so sometimes, values must be quoted).

Then the parse might have bugs, as these schema ".update" files are generating syntax violations when updating the schema. I'm trying to gather more info on this. More to follow...

Very possible. Petr's point is just that the .update files themselves don't quite follow LDIF syntax.

If you use the --debug option of ipa-ldap-updater, or look in /var/log/ipaupgrade.log you can see the MOD statements that will be/are passed.

I found the problem, and it can be fixed in 389 or IPA, but I think we should fix it in 389.

So when you quote the attribute value in the file it adds spaces to the front of the string.

attributeType:"
<OID>
<NAME>
....
"

This translates to "attributeTypes: ( OID NAME ....)"

The openldap parser expects the first character to be "(", not " ".

So I should be able to resolve the issues with the update files, but the other schema files do need to be fixed. Once I can verify the fix in 389 I will make an update.

The problem with updates should be fixed when we address #3454 (Schema install and updates should be based on the same source).

Found another issue during the install on the IPA side:

Here is what I see on the DS side:

[22/Apr/2013:13:51:11 -0400] - DEBUG "2.16.840.1.113730.3.8.12.10 NAME 'ipaSELinuxUserMap' SUP ipaAssociation STRUCTURAL MUST ipaSELinuxUser MAY ( accessTime $ seeAlso )"
[22/Apr/2013:13:51:11 -0400] - DEBUG (Missing closing parenthesis)

Looking at the schema definition it is complete:

( 2.16.840.1.113730.3.8.12.10 NAME 'ipaSELinuxUserMap' SUP ipaAssociation STRUCTURAL MUST ip
aSELinuxUser MAY ( accessTime $ seeAlso ) X-ORIGIN 'IPA v3' )

But in the IPA install log I see this(which matches the DS log):

2013-04-22T17:50:41Z DEBUG add: '( 2.16.840.1.113730.3.8.12.10 NAME 'ipaSELinuxUserMap' SUP ipaAssociation STRUCTURAL MUST ipaSELinuxUser MAY ( accessTime $ seeAlso )' to objectClasses,
...

Note, it's missing the X-ORIGIN term, and the closing parenthesis. This would appear to be a issue on the IPA side, but I'm not really sure what the installer is doing at this point.

In the install log you can see inconsistent behavior:

2013-04-22T17:51:11Z ERROR Update failed: Invalid syntax: object class ( 2.16.840.1.113730.3.8.12.10 NAME 'ipaSELinuxUserMap' SUP ipaAssociation STRUCTURAL MUST ipaSELinuxUser MAY ( accessTime $ seeAlso ): Failed to parse objectclass, error(4) at (end of input)

"( 2.16.840.1.113730.3.8.12.10 NAME 'ipaSELinuxUserMap' SUP ipaAssociation STRUCTURAL MUST ipaSELinuxUser MAY ( accessTime $ seeAlso )",

2013-04-22T17:50:04Z DEBUG ( 2.16.840.1.113730.3.8.12.10 NAME 'ipaSELinuxUserMap' SUP ipaAssociation STRUCTURAL MUST ipaSELinuxUser MAY ( accessTime $ seeAlso ) X-ORIGIN 'IPA v3' )

2013-04-22T17:51:08Z DEBUG ( 2.16.840.1.113730.3.8.12.10 NAME 'ipaSELinuxUserMap' SUP ipaAssociation STRUCTURAL MUST ipaSELinuxUser MAY ( accessTime $ seeAlso )

So the full value is there, and then its not. I can provide the full log if you would like. Everytime it is always this same objcetclass(ipaSELinuxUserMap).

It's correct in the schema file but wrong in the update.

Patch sent to list, updated RPMs here: http://fedorapeople.org/~pviktori/rpms/freeipa-3fd3e61/

While the ipa install is still failing at the end of the install(trying to restart the ipa server), there are no more schema errors(that's good enough for me). Thanks for the help Petr!

master:[[br]]
d4a0fa3[[br]]
e9863e3[[br]]

This bug should be backported to RHEL6.

The migration to RHEL7.1 is having issues without this fix.

the copy-schema-to-ca.py provokes that the bad definition of domaincomponent (dc) is propagated in the whole topology since the schema of pki instance is copied to the main instance of dirsrv.