Frank Swasey wrote:
Today at 11:45am, Quanah Gibson-Mount wrote:
--On Monday, June 20, 2016 12:31 PM -0400 Frank Swasey Frank.Swasey@uvm.edu wrote:
Delta-Syncrepl has started failing to actually replicate the consumer starting with an empty database, it fails with code 0x50 because of the auditContext attribute that is present in the suffix entry on the master server due to the accesslog overlay being used.
I can make it work if I load the accesslog overlay in the replica's configuration (without actually configuring it). This appears to be new behavior since 2.4.42.
Is this expected, and now required with 2.4.44, or should I open an ITS?
Not quite sure what you mean. I have no issues with empty consumers replicating from their master servers.
I mean that an empty consumer fails to replicate from its master servers unless I load the accesslog module. It fails with the following:
Jun 20 12:29:29 ldap7r slapd[21153]: syncrepl_message_to_entry: rid=100 DN: dc=uvm,dc=edu, UUID: b745df88-a640-1027-9374-fb1dd3799b92 Jun 20 12:29:29 ldap7r slapd[21153]: UNKNOWN attributeDescription "AUDITCONTEXT" inserted. Jun 20 12:29:29 ldap7r slapd[21153]: syncrepl_entry: rid=100 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jun 20 12:29:29 ldap7r slapd[21153]: syncrepl_message_to_entry: rid=100 DN: dc=uvm,dc=edu, UUID: b745df88-a640-1027-9374-fb1dd3799b92 Jun 20 12:29:29 ldap7r slapd[21153]: UNKNOWN attributeDescription "AUDITCONTEXT" inserted. Jun 20 12:29:29 ldap7r slapd[21153]: syncrepl_entry: rid=100 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jun 20 12:29:29 ldap7r slapd[21153]: syncrepl_entry: rid=100 inserted UUID b745df88-a640-1027-9374-fb1dd3799b92 Jun 20 12:29:29 ldap7r slapd[21153]: syncrepl_entry: rid=100 be_search (32) Jun 20 12:29:29 ldap7r slapd[21153]: syncrepl_entry: rid=100 inserted UUID b745df88-a640-1027-9374-fb1dd3799b92 Jun 20 12:29:29 ldap7r slapd[21153]: syncrepl_entry: rid=100 be_search (32) Jun 20 12:29:29 ldap7r slapd[21153]: syncrepl_entry: rid=100 dc=uvm,dc=edu Jun 20 12:29:29 ldap7r slapd[21153]: syncrepl_entry: rid=100 dc=uvm,dc=edu Jun 20 12:29:29 ldap7r slapd[21153]: syncrepl_entry: rid=100 be_add dc=uvm,dc=edu (80) Jun 20 12:29:29 ldap7r slapd[21153]: syncrepl_entry: rid=100 be_add dc=uvm,dc=edu (80) Jun 20 12:29:29 ldap7r slapd[21153]: syncrepl_entry: rid=100 be_add dc=uvm,dc=edu failed (80) Jun 20 12:29:29 ldap7r slapd[21153]: syncrepl_entry: rid=100 be_add dc=uvm,dc=edu failed (80) Jun 20 12:29:29 ldap7r slapd[21153]: do_syncrepl: rid=100 rc 80 retrying Jun 20 12:29:29 ldap7r slapd[21153]: do_syncrepl: rid=100 rc 80 retrying
That tells me that the masters are sending the auditContext attribute but my replica has no clue what to do with it so fails to add the base dn and nothing works after that.
That's definitely odd. auditContext is a dsaOperational attribute, so it is not supposed to propagate in replication. slap_send_search_entry in slapd/result.c explicitly strips these out. The only thing I can think of is that someone has changed your auditContext schema definition so it's no longer a dsaOperation attribute.