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

Re: N-Way MultiMaster with 2.4



Ok, when I configure it and trap the logs, one of my systems shows:

[ldap@dv1nitle05-ldap1]$
[ldap@dv1nitle05-ldap1]$ daemon: select: listen=7 active_threads=0 tvp=zero
do_syncrep2: rid=011 got search entry without Sync State control
do_syncrepl: rid=011 retrying (3 retries left)
daemon: activity on 1 descriptor
daemon: waked
daemon: select: listen=7 active_threads=0 tvp=zero
daemon: select: listen=7 active_threads=0 tvp=zero
do_syncrep2: rid=011 got search entry without Sync State control
do_syncrepl: rid=011 retrying (2 retries left)
daemon: activity on 1 descriptor
daemon: waked
daemon: select: listen=7 active_threads=0 tvp=zero
daemon: select: listen=7 active_threads=0 tvp=zero
do_syncrep2: rid=011 got search entry without Sync State control
do_syncrepl: rid=011 retrying (1 retries left)
daemon: activity on 1 descriptor
daemon: waked
daemon: select: listen=7 active_threads=0 tvp=zero
daemon: select: listen=7 active_threads=0 tvp=zero
do_syncrep2: rid=011 got search entry without Sync State control
do_syncrepl: rid=011 retrying
daemon: activity on 1 descriptor
daemon: waked
daemon: select: listen=7 active_threads=0 tvp=zero
daemon: select: listen=7 active_threads=0 tvp=zero
do_syncrep2: rid=011 got search entry without Sync State control
do_syncrepl: rid=011 retrying (4 retries left)
daemon: activity on 1 descriptor
daemon: waked
daemon: select: listen=7 active_threads=0 tvp=zero



the other one is trying to do the sync with logs like

=> access_allowed: read access to "cn=manager,dc=nitle,dc=org" "hasSubordinates" requested
=> dn: [1]
=> dn: [2] cn=subschema
=> dn: [3] cn=log
=> dnpat: [4] ^([^,]*,)?ou=[^,]+,(dc=[^,]+(,dc=[^,]+)*)$ nsub: 3
=> acl_get: [5] attr hasSubordinates
=> slap_access_allowed: result not in cache (hasSubordinates)
=> acl_mask: access to entry "cn=manager,dc=nitle,dc=org", attr "hasSubordinates" requested
=> acl_mask: to value by "cn=manager,cn=config", (=0)
<= check a_dn_pat: cn=replslave,ou=replication,dc=nitle,dc=org
<= check a_dn_pat: cn=mirrormode,ou=replication,dc=nitle,dc=org
<= check a_dn_pat: uid=ldaprw,ou=staff,dc=nitle,dc=org
<= check a_dn_pat: uid=ldapro,ou=staff,dc=nitle,dc=org
<= check a_dn_pat: cn=manager,cn=config
<= acl_mask: [5] applying write(=wrscxd) (stop)
<= acl_mask: [5] mask: write(=wrscxd)
=> slap_access_allowed: read access granted by write(=wrscxd)
=> access_allowed: read access granted by write(=wrscxd)
daemon: activity on 1 descriptor
daemon: activity on: 11r
daemon: read activity on 11
daemon: select: listen=7 active_threads=0 tvp=zero
connection_read(11): input error=-2 id=5, closing.
daemon: activity on 1 descriptor
daemon: removing 11
daemon: waked
daemon: select: listen=7 active_threads=0 tvp=zero



It appears I'm also getting bind failures as the cn=manager,cn=config user that I have, however, I don't always get the errors, I get successful binds as that user to get the info above, but then later after it's been running for a short while, it starts to get err49 (auth err)


I'm investigating more.   I wonder if I'm overriding my databases......
On Jan 4, 2008, at 5:59 PM, Gavin Henry wrote:

<quote who="Chris G. Sellers">
Hello all.  I've read the news posting at
http://blog.suretecsystems.com/archives/40-OpenLDAP-Weekly-News-Issue-5.html#extended
  for multimaster N-Way sync.   Very good stuff.

I've configured the cn=config backend, and I can browse it with my
LDAP browser on both my Masters. (I have two servers)

I have created the replication agreements and are able to add them to
the cn=config as documented in the URL above.  No problem on both
servers.

When I add the data sync, I get a little confused.

Below, for ${BACKEND} I assume I put something like bdb for the
database backend correct? If I do this it does not fail, but the sync
does not happen. I don't see a whole lot of errors either with the
sync.

bdb or hdb, depending on how you've built slapd.

Logs?


dn: olcDatabase={1}$BACKEND,cn=config objectClass: olcDatabaseConfig objectClass: olc${BACKEND}Config olcDatabase: {1}$BACKEND olcSuffix: $BASEDN olcDbDirectory: ./db olcRootDN: $MANAGERDN olcRootPW: $PASSWD olcSyncRepl: rid=004 provider=$URI1 binddn="$MANAGERDN" bindmethod=simple credentials=$PASSWD searchbase="$BASEDN" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1 olcSyncRepl: rid=005 provider=$URI2 binddn="$MANAGERDN" bindmethod=simple credentials=$PASSWD searchbase="$BASEDN" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1 olcSyncRepl: rid=006 provider=$URI3 binddn="$MANAGERDN" bindmethod=simple credentials=$PASSWD searchbase="$BASEDN" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1 olcMirrorMode: TRUE

dn: olcOverlay=syncprov,olcDatabase={1}${BACKEND},cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov


I end up with olcDatabase={1}bdb in there twice.

What should the $BACKEND value be if not bdb.   (if by db backend is
bdb).

Thanks for any insight.  For now, I am going to have to revert to
Master+Slave via syncrepl and referrals.

Sellers


| ----------------------------------------------------------------------|
Chris G. Sellers, MLS Lead Internet Engineer
National Institute for Technology & Liberal Education
535 West William Street, Ann Arbor, Michigan 48103
chris.sellers@nitle.org 734.661.2318








______________________________________________ Chris G. Sellers | NITLE Technology 734.661.2318 | chris.sellers@nitle.org AIM: imthewherd | GTalk: cgseller@gmail.com