> > On master server I see that slave issued search, but no results returned.
obviously the filter is failing; what you can't see is that the master is not simply using the filter you provided, but it's augmenting it with entryCSN related stuff, so if you ldapsearch with your filter and you get data, that's not exactly what's going on. By the way, does a search with that filter succeed? > > Jan 19 14:34:18 backup slapd[6094]: conn=11 op=1 SRCH > base="o=aspec,c=ru" scope=2 deref=0 filter="(objectClass=belkamAccount)" > Jan 19 14:34:18 backup slapd[6094]: conn=11 op=1 SRCH attr=* + > Jan 19 14:34:18 backup slapd[6094]: slap_global_control: unavailable > control: 1.3.6.1.4.1.4203.1.9.1.1 > Jan 19 14:34:18 backup slapd[6094]: send_ldap_result: conn=11 op=1 p=3 > Jan 19 14:34:18 backup slapd[6094]: send_ldap_result: err=0 matched="" > text="" > Jan 19 14:34:18 backup slapd[6094]: send_ldap_response: msgid=2 tag=101 > err=0 > Jan 19 14:34:18 backup slapd[6094]: conn=11 op=1 SEARCH RESULT tag=101 > err=0 nentries=0 text= > Jan 19 14:34:18 backup slapd[6094]: daemon: activity on 1 descriptor > Jan 19 14:34:18 backup slapd[6094]: daemon: activity on: > Jan 19 14:34:18 backup slapd[6094]: 18r > > > Colud you tell what this unavailable control messages mean? The frontend does not recognize the sync control, so delegates its handling to the database (actually, to the syncprov overlay). It's harmless (in fact, it's logged at "trace"). p. Ing. Pierangelo Masarati Responsabile Open Solution OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: [EMAIL PROTECTED] ------------------------------------------
