[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: openldap 2.4.44 - delta-syncrepl fails on auditContext

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. 

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/