Looks like I caused this bug :-( with the fix for https://fedorahosted.org/389/ticket/47647

I guess we have to add back the bogus schema entry to make schema replication work :P This means our schema tests in master will fail. I'm not sure how we can fix this and keep backwards compatability.

There are two issues:

since https://fedorahosted.org/389/ticket/47490 and https://fedorahosted.org/389/ticket/47647, it fails to push the schema 'master' -> 1.3.1 and 'master' -> 1.2.11 because of 'printer-uri'
A workaround is to update 60rfc3712.ldif under <1.3.1 or 1.2.11 install>/etc/dirsrv/schema, and update already created instances

since https://fedorahosted.org/389/ticket/47541, it fails to push the schema 'master' -> 1.2.11 because of unhashed#user#password pseudo attribute

attachment
0001-Ticket-47676-Replication-of-the-schema-fails-master-.patch

attachment
0002-Ticket-ticket47676-Replication-of-the-schema-fails-m.patch

In create_repl_schema_policy() - you should clear or free the pblock after every add operation. It may cause strange problems to re-use the same pblock for multiple operations (even though it may seem to work fine in your testing).

Your return -1 will leak memory. Don't do a short-circuit return:
{{{

672         if (return_value != LDAP_SUCCESS && return_value != LDAP_ALREADY_EXISTS) { 
673                 slapi_log_error(SLAPI_LOG_FATAL, repl_plugin_name, "Warning: unable to " 
674                         "create configuration entry %s: %s\n", repl_schema_top, 
675                         ldap_err2string(return_value)); 
676                 return -1; 
677         }

}}}
- instead, have a done: label that does all of the cleanup:
{{{
int rc = 0;
...
672 if (return_value != LDAP_SUCCESS && return_value != LDAP_ALREADY_EXISTS) {
673 slapi_log_error(SLAPI_LOG_FATAL, repl_plugin_name, "Warning: unable to "
674 "create configuration entry %s: %s\n", repl_schema_top,
675 ldap_err2string(return_value));
676 rc = -1;
goto done;
677 }
...
done:
if (pb) {
slapi_pblock_free(pb);
pb = NULL;
}
return rc;
}}}

You will also need to free Slapi_Entry *e if the add fails - if the add is successful, set e = NULL so you will know that you don't need to free it.

{{{

219 repl_schema_policy_t supplier_policy = {0}; 
220 repl_schema_policy_t consumer_policy = {0};

}}}
Do these need to be globals? If not, please define them as static.

Also, the parsing, structs, etc. - do you need to have a separate name and oid? Can't you just have a char *name_or_oid?

Finally, I think you can get rid of a lot of the parsing, etc. by just having 4 different multi-valued attributes:
schemaUpdateAccept: acceptattr
schemaUpdateAccept: acceptoid
...
schemaUpdateReject: rejectattr
schemaUpdateReject: rejectoid
...

I don't know if you even need to keep a separate list of objectclasses and attributetypes - I suppose if we allow you to have an objectclass and an attribute with the same name, then you might want to reject objectclass "foo" but allow attribute "foo". As far as OIDs go, you will never have an objectclass or attribute with the same OID as any other schema element.

attachment
0002-Ticket-47676-test-case.patch

attachment
0003-Ticket-47676-Replication-of-the-schema-fails-master-.patch

git merge

Updating 01cb401..c44ea92
Fast-forward
dirsrvtests/tickets/ticket47676_test.py | 485 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ldap/schema/01core389.ldif | 5 +
ldap/servers/plugins/replication/repl5_init.c | 98 +++++++++++++++-
ldap/servers/slapd/schema.c | 304 +++++++++++++++++++++++++++++++++++++++++++++++--
ldap/servers/slapd/slap.h | 36 ++++++
ldap/servers/slapd/slapi-private.h | 3 +
6 files changed, 922 insertions(+), 9 deletions(-)
create mode 100644 dirsrvtests/tickets/ticket47676_test.py

git push origin master

Counting objects: 30, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (16/16), done.
Writing objects: 100% (16/16), 11.80 KiB, done.
Total 16 (delta 12), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
01cb401..c44ea92 master -> master

commit c44ea92
Author: Thierry bordaz (tbordaz) tbordaz@redhat.com
Date: Tue Feb 4 11:50:45 2014 +0100

attachment
0001-Ticket-47676-cont.-Replication-of-the-schema-fails-m.patch

I did pick up a wrong OID for nsSchemaPolicy OID. Just OLC reviewed by Rich

git merge ticket47676_entries
Updating c44ea92..ce43858
Fast-forward
ldap/schema/01core389.ldif | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

git push origin master

Counting objects: 9, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 691 bytes, done.
Total 5 (delta 4), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
c44ea92..ce43858 master -> master

commit ce43858
Author: Thierry bordaz (tbordaz) tbordaz@redhat.com
Date: Wed Feb 5 16:56:10 2014 +0100

In order to backport ​https://fedorahosted.org/389/ticket/47721 in 1.3.2, this bug needs to be backported first

git push origin '''389-ds-base-1.3.2''' (core fix)

Counting objects: 30, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (16/16), 11.76 KiB, done.
Total 16 (delta 12), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
dd543aa..e35d201 389-ds-base-1.3.2 -> 389-ds-base-1.3.2

commit e35d201
Author: Thierry bordaz (tbordaz) tbordaz@redhat.com
Date: Tue Feb 4 11:50:45 2014 +0100

git push origin '''389-ds-base-1.3.2''' (wrong OID)

Counting objects: 9, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 689 bytes, done.
Total 5 (delta 4), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
e35d201..d26a4a0 389-ds-base-1.3.2 -> 389-ds-base-1.3.2

commit d26a4a0
Author: Thierry bordaz (tbordaz) tbordaz@redhat.com
Date: Wed Feb 5 16:56:10 2014 +0100

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/1013

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.