Can you please the error log from the consumer

Thanks for the reply. Please find the error file for the replication consumer attached. Important errors are the one logged on Jun07.

On the master, we are getting the error message mentioned above:

...
Schema replication update failed. Constraint violation.
Warning: unable to replicate schema to host
...

Thanks for your help!

In order to replicate updates, schema definitions need to be replicated as well. The schema is pushed by the supplier to the consumer in the early steps of replication session. This can create issue when the supplier schema is older (subset) of the consumer schema.

In 1.3.6, a new mechanism prevents a "old" schema to overwrite a new "one". It also introduce a capability to learn missing schema definitions

Interesting logs are

[07/Jun/2018:18:53:32.005097809 -0700] - ERR - modify_schema_dse - [C] Local objectClasses must not be overwritten (set replication log for additional info)
...
[07/Jun/2018:18:53:37.538954636 -0700] - ERR - NSACLPlugin - __aclp__init_targetattr - targetattr "passwordPolicySubentry" does not exist in schema. Please add attributeTypes "passwordPolicySubentry" to schema if necessary.

The first line shows that the consumer (Centos7) '[C] received a schema that was not a superset of it own schema. It refused to apply it locally. This did not prevent replication to continue but later we can see an error because of missing schema definition.

Would you please enable replication logging (nsslapd-errorlog-level: 8192) on the consumer and do a dummy update on the supplier. This will trigger a replication session and log will contain the details why the consumer refused the schema.

A limitation of schema learning is when a same definition need a merge. For example OC A allows attributes B, C, D and on the other server allows B, D, E.
It could be the case here

Attached is the errors file after enabling "nsslapd-errorlog-level: 8192"

As I mentioned above, after the replication initialization service won't restart with the following errors;

Jun  8 18:14:16 ldap13 systemd: Starting 389 Directory Server ldap13....
Jun  8 18:14:16 ldap13 ns-slapd: [08/Jun/2018:18:14:16.641296676 -0700] - NOTICE - slapd_bootstrap_config - nsslapd-errorlog-level: ignoring 8192 (since -d 266354688 was given on the command line)
Jun  8 18:14:16 ldap13 ns-slapd: [08/Jun/2018:18:14:16.774026366 -0700] - ERR - attr_syntax_create - Error: the EQUALITY matching rule [caseIgnoreListMatch] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [registeredAddress]
Jun  8 18:14:16 ldap13 ns-slapd: [08/Jun/2018:18:14:16.778525726 -0700] - ERR - attr_syntax_create - Error: the SUBSTR matching rule [caseIgnoreListSubstringsMatch] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [registeredAddress]
Jun  8 18:14:16 ldap13 ns-slapd: [08/Jun/2018:18:14:16.782276920 -0700] - ERR - attr_syntax_create - Error: the EQUALITY matching rule [caseIgnoreIA5Match] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc]
Jun  8 18:14:16 ldap13 ns-slapd: [08/Jun/2018:18:14:16.785406003 -0700] - ERR - attr_syntax_create - Error: the SUBSTR matching rule [caseIgnoreIA5SubstringsMatch] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc]
Jun  8 18:14:16 ldap13 ns-slapd: [08/Jun/2018:18:14:16.788838208 -0700] - ERR - dse_read_one_file - The entry cn=schema in file /etc/dirsrv/slapd-ldap13/schema/99user.ldif (lineno: 1) is invalid, error code 20 (Type or value exists) -
Jun  8 18:14:16 ldap13 ns-slapd: [08/Jun/2018:18:14:16.791842377 -0700] - ERR - setup_internal_backends - Please edit the file to correct the reported problems and then restart the server.
Jun  8 18:14:16 ldap13 systemd: dirsrv@ldap13.service: main process exited, code=exited, status=1/FAILURE
Jun  8 18:14:16 ldap13 systemd: Failed to start 389 Directory Server ldap13..
Jun  8 18:14:16 ldap13 systemd: Unit dirsrv@ldap13.service entered failed state.
Jun  8 18:14:16 ldap13 systemd: dirsrv@ldap13.service failed.

At this point, I restore the original 99user.ldif file, and it restarts again.

Just in case, attached is the schema file at ldap master.

Again thanks a lot for you help.

P.S. I won't be able to reply back until June 19th as I will be away for vacation.

@sinan81 , I think there are two issues possibly related.
Some schema definitions are inconsistent (matching rules incompatible with some attribute syntax).
The replication of the schema to consumer (Centos7) is rejected.

For the first issue I think it is due to old combinaison of definitions no longer supported. Please try the changes

registeredAddress   : 1.3.6.1.4.1.1466.115.121.1.15
    -> Try SYNTAX: 1.3.6.1.4.1.1466.115.121.1.41
sabayonProfileURL   : 1.3.6.1.4.1.1466.115.121.1.26
    -> Try EQUALITY: caseExactIA5Match
dc                  : 1.3.6.1.4.1.1466.115.121.1.15
    Try
  EQUALITY caseIgnoreIA5Match
  SUBSTR caseIgnoreIA5SubstringsMatch

For the second issue I have no clue because there was no failure [1] when the replication logging was on ([C] Local objectClasses must not be overwritten).
After enabling replication logging on Centos7, do a dummy update on the master and wait it is replicated on the consumer (Centos7).

@tbordaz :
Am I supposed to do the modification you suggested on the master or the consumer? (Sorry, I am not very familiar with 389-ds/LDAP yet.) If "master", then a quick search of the above mentioned attributes yields the following:

"registeredAddress" attribute is defined in 01common.ldif:

attributeTypes: ( 2.5.4.26 NAME 'registeredAddress' DESC 'Standard LDAP attribute type' SUP postalAddress X-ORIGIN 'RFC 2256' )

Are you suggesting that I should modify it to:

attributeTypes: ( 2.5.4.26 NAME 'registeredAddress' DESC 'Standard LDAP attribute type' SUP postalAddress SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 X-ORIGIN 'RFC 2256' )

Similarly, 'sabayonProfileURL' is defined in 06sabayonProfile.ldif

attributeTypes: (
  1.3.6.1.4.1.2312.4.3.3.1
  NAME 'sabayonProfileURL'
  DESC 'The URL of a sabayon profile'
  SUP labeledURI
  X-ORIGIN 'Sabayon'
)

Again, are you suggesting that I should change it to

attributeTypes: (
  1.3.6.1.4.1.2312.4.3.3.1
  NAME 'sabayonProfileURL'
  DESC 'The URL of a sabayon profile'
  SUP labeledURI
  EQUALITY caseExactIA5Match
  X-ORIGIN 'Sabayon'
)

"dc" attribute is defined in 05rfc2247.ldif, and already equivalent to what you suggested:

attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) DESC 'Standard LDAP attribute type' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'RFC 2247' )

Thanks for your help and patience!

Hi,

Basically with recent version of 389-ds, there is a more strict compatibility checking between attribute syntax and matching rules. I suggest that you edit the problematic definitions on both sides master/consumer.

Regarding 'registeredAddress' your suggested change is correct: add the SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 to the definition

Regarding sabayonProfileURL, I think the problem comes for the superior syntax (labeledURI), it seems it is 1.3.6.1.4.1.1466.115.121.1.26 and I would recommend to change labeledURI to be 1.3.6.1.4.1.1466.115.121.1.15

Regarding 'dc', the syntax should be 1.3.6.1.4.1.1466.115.121.1.26 and EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch

I would recommend that before doing the changes, you save all schema files (master/consumer) and update 99user.ldif for the new definitions

Hi again,

Sorry for the late reply! As I am working with a "production" machine, I've decided to keep the server intackt and work with a clone in test environment which took some time.

After I applied the suggested edits (see * below), I initialized the consumer. For the first time, a substantial amount of schema replication seemed to happen in this case. As before, I did a simple replication test, and it worked. However, when I restarted dirsrv I got similar attribute errors as before. After taking a careful look at the replicated 99user.ldif file I noticed that the syntax for the registeredAddress was incorrect: ...121.1.15 as opposed to your suggestion: ...121.1.41. So, I corrected this, and right now the only errors that I get are the following:

[28/Jun/2018:21:03:55.939911111 -0700] - ERR - dse_read_one_file - The entry cn=schema in file /etc/dirsrv/slapd-ldap13/schema/99user.ldif (lineno: 1) is invalid, error code 20 (Type or value exists) - 
[28/Jun/2018:21:03:55.943172363 -0700] - ERR - setup_internal_backends - Please edit the file to correct the reported problems and then restart the server.

Again, I am wondering if you have further suggestions. You will find the current version of consumer 99user.ldif file attached along with the error logs.

Overall, I think there is good a progress as attributes errors are gone, and a substantial amount of master schema is replicated. However, still the dirsrv is not able to restart.

*: Initially I didn't change anything in 99user.ldif files since the didn't contain the attributes of interest: registeredAddress, labeledUri, and dc.

PS: I think I forgot to enable debug mode for the replication this time around. It will be definitely enabled for the next step.

And here is the errors file.

Thanks for your help!

I am wondering if you have suggestions as to how to debug this problem. I tried setting "nsslapd-errorlog-level = 2048" however this was ignored with the reason "...since -d 266354688 was given on the line."

There have been many improvements to replication over the last two years. If you can reproduce the problem on the latest version 1.4.x please reopen this ticket. Closing for now...

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/2797

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.