Ali,

By default, it should start. You don't need to any change in any file. If you will see the bash script, there you can see, first it will check slapd.d then it will check slapd.conf file.

Could you please let us know, how do you have installed openldap.

On Fri, Feb 7, 2014 at 5:15 PM, Ali Gholami gholami@kth.se wrote:

Hi list,

I've an Ubuntu 12.04 and I'd like to install an static configraution using slapd.conf. I've created a "slapd.conf" under "/etc/ldap" where is the default directory to install OpenLDAP. But when I start my service through "sudo service slapd start " it doesn't start the service using the static configuration.

I changed the script under "/etc/init.d/slapd" so that slapd.conf will be used through "SLAPD_CONF=/etc/ldap/slapd.conf" but then the LDAP server fails to start.

Any ideas how to deploy a static configuration in Ubuntu 12.04?

Regards Ali

On 02/07/14 14:39 +0100, Ali Gholami wrote:

Thanks Vikas for the reply.

I removed the line to point to the "slapd.conf" and now I could run the service. But I get another error when I try to add structure of the entries using:

---

$sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// -f structure.ldif:

This is likely performing sasl external peercred authentication, rather than your desired external tls authentication as you intended below.

adding new entry "dc=x,dc=y"

ldap_add: Insufficient access (50) additional info: no write access to parent

---

I've created the ".ldaprc" in my home directory which defines the X590 certificates of the LDAP server and I've added the subject of the host certificated in the "slapd.conf":

---

access to * by dn="cn=admin,dc=x,dc=y" write by dn="cn=allowed host,dc=x,dc=y" read by * none

authz-regexp CN=ldap.biobankcloud.eu,O=BBC "cn=admin,dc=biobankcloud,dc=org"

database bdb suffix "dc=x,dc=y" rootdn "cn=admin,dc=x,dc=y" rootpw {SSHA}blabla...

---

IS there anything else that I should set or something broken?

Do:

sudo ldapwhoami -Y EXTERNAL -H ldapi:///

to obtain your resolved authentication identity, and create an appropriate authz-regexp rule that maps that identity to your desired user, e.g.:

authz-regexp "uidNumber=0,cn=peercred,cn=external,cn=auth" "cn=admin,dc=biobankcloud,dc=org"

See: http://www.openldap.org/doc/admin24/sasl.html

--On Friday, February 07, 2014 10:29 PM +0100 Ali Gholami gholami@kth.se wrote:

ldap_err2string ldap_add: Insufficient access (50) additional info: no write access to parent

Seems pretty clear. The ACLs you wrote are denying write access to the parent.

--Quanah

--

Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

On 02/08/2014 09:25 AM, Jarbas Peixoto Júnior wrote:

2014-02-07 8:45 GMT-03:00 Ali Gholami gholami@kth.se:

...

Hi list,

I've an Ubuntu 12.04 and I'd like to install an static configraution using slapd.conf. I've created a "slapd.conf" under "/etc/ldap" where is the default directory to install OpenLDAP. But when I start my service through "sudo service slapd start " it doesn't start the service using the static configuration.

I changed the script under "/etc/init.d/slapd" so that slapd.conf will be used through "SLAPD_CONF=/etc/ldap/slapd.conf" but then the LDAP server fails to start.

Any ideas how to deploy a static configuration in Ubuntu 12.04?

I change on file /etc/default/slapd the option SLAPD_CONF=/etc/ldap/slapd.conf

[ ]'s Jarbas

I changed " /etc/default/slapd" but still thr server does not start. The syslog file also contains little information about the failure:

---- Feb 9 17:58:36 localhost slapd[717]: @(#) $OpenLDAP: slapd (Sep 19 2013 22:39:38) $#012#011buildd@panlong:/build/buildd/openldap-2.4.28/debian/build/servers/slapd Feb 9 17:58:36 localhost slapd[717]: slapd stopped. Feb 9 17:58:36 localhost slapd[717]: connections_destroy: nothing to destroy ---

It seems there is a backward compatibility issues with slapd.conf in Ubuntu 12.04. Is there way I can figure out what is set wrong?

Ali

--On Sunday, February 09, 2014 11:49 PM +0100 Ali Gholami gholami@kth.se wrote:

I used the debug mode:

slapd -d 2 52f80527 @(#) $OpenLDAP: slapd (Sep 19 2013 22:39:38) $ buildd@panlong:/build/buildd/openldap-2.4.28/debian/build/servers/slapd p11-kit: couldn't list directory: /etc/pkcs11/modules: Permission denied 52f80527 main: TLS init def ctx failed: -1 52f80527 slapd stopped. 52f80527 connections_destroy: nothing to destroy.

---

Does anyone know why TLS ctx fails to initialize?

Because it gets permission denied when trying to access /etc/pkcs11/modules, exactly as it states.

--Quanah

--

Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

Ali Gholami wrote:

Thanks Quanah, I could resolve the error but the error message was not helpful.

I stopped the apparmor service and used strace to debug. I realized the server certificate path was not defined correctly to be loaded.

I think "p11-kit: couldn't list directory: /etc/pkcs11/modules: Permission denied " is not really the correct error message. It should be something like "certificate not found" etc.

Send a bug report to Ubuntu then, this error message comes from their GnuTLS library, not from OpenLDAP.

Ali

On 02/10/2014 10:09 PM, Quanah Gibson-Mount wrote:

...

--On Sunday, February 09, 2014 11:49 PM +0100 Ali Gholami gholami@kth.se wrote:

...

I used the debug mode:

slapd -d 2 52f80527 @(#) $OpenLDAP: slapd (Sep 19 2013 22:39:38) $ buildd@panlong:/build/buildd/openldap-2.4.28/debian/build/servers/slapd p11-kit: couldn't list directory: /etc/pkcs11/modules: Permission denied 52f80527 main: TLS init def ctx failed: -1 52f80527 slapd stopped. 52f80527 connections_destroy: nothing to destroy.

---

Does anyone know why TLS ctx fails to initialize?

Because it gets permission denied when trying to access /etc/pkcs11/modules, exactly as it states.

--Quanah

--

Quanah Gibson-Mount Architect - Server Zimbra, Inc.

---

Zimbra :: the leader in open source messaging and collaboration

OpenDJ LDAP SDK and toolkit is Java based : opendj.forgerock.org. Otherwise, Apache Directory also has a Java based library.

Regards,

Ludovic. --  Ludovic Poitou ForgeRock http://ludopoitou.wordpress.com From: Ali Gholami gholami@kth.se Reply: Ali Gholami gholami@kth.se Date: February 12, 2014 at 14:16:49 To: openldap-technical@openldap.org openldap-technical@openldap.org Subject:  Java library to manage LDAP entries Dear list,

I wonder if anyone knows about a Java based library to manage LDAP entires instead of the command line, something like phpLDAP admin?

Thanks in advance for your answer! Ali

...

...

Clément OUDOTclem.oudot@gmail.com schrieb am 07.02.2014 um 14:52 in

Nachricht CAK_oV4-gRgWjRbBqJpahd-MjYtVpmOPSx8KeecSpap3yt+US9w@mail.gmail.com:

2014-02-07 14:15 GMT+01:00 Ulrich Windl

Ulrich.Windl@rz.uni-regensburg.de:

...

Hi!

What about comparing the EntryCSN of the top-level object? You could also slapcat each node, sort the lines and compare the results (I guess the order of entries on each server is not predicable..)

You should compare contextCSN, not entryCSN.

Thanks; that's what I meant.

Clément.

All,

I've been reading this string...

Comparing the entryCSNs & contextCSNs on both of my test servers at the base DN (dc=example,dc=ldap):

mm-server1: entryCSN: 20140121153301.911487Z#000000#003#000000 contextCSN: 20140203183831.751838Z#000000#001#000000 contextCSN: 20140204143957.937393Z#000000#002#000000

mm-server2: entryCSN: 20140121153301.911487Z#000000#003#000000 contextCSN: 20140129140325.443822Z#000000#000#000000 contextCSN: 20140203183831.751838Z#000000#001#000000 contextCSN: 20140129183014.073734Z#000000#002#000000 contextCSN: 20140121153301.911487Z#000000#003#000000

1) What is this information telling me? (I want to be sure that I know) 2) Should I be concerned that there are more on mm-server2?

Thanks in advance John

-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Michael Ströder Sent: Friday, February 07, 2014 2:11 PM To: openldap-technical@openldap.org Subject: Re: Simple way to check that MMR is in sync?

Ulrich Windl wrote:

What about comparing the EntryCSN of the top-level object?

No! You should read what entryCSN attribute really is!

You have to compare the contextCSN values in the database's root entry.

In case you're using slapo-memberof or slapo-refint you want to have release 2.4.37+ with a fix for ITS#7710. Otherwise your admins will hate you for being called at night for nothing.

You could also slapcat each node, sort the lines and compare the results

Likely you don't want to do this for a directory with more than a few dozens entries in a monitor check invoked every minute. ;-]

Ciao, Michael.

Thanks Quanah;

I take it that your advice from a while back still stands, slapadd the main dbase from mm-server1 to mm-server2 (this time I won't do a slapindex -- honest)?

Thanks in advance John

-----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Monday, February 10, 2014 6:42 PM To: Borresen, John - 0442 - MITLL; Michael Ströder; openldap-technical@openldap.org Subject: RE: Simple way to check that MMR is in sync?

--On Monday, February 10, 2014 5:23 PM -0500 "Borresen, John - 0442 - MITLL" John.Borresen@ll.mit.edu wrote:

All,

I've been reading this string...

Comparing the entryCSNs & contextCSNs on both of my test servers at the base DN (dc=example,dc=ldap):

mm-server1: entryCSN: 20140121153301.911487Z#000000#003#000000 contextCSN: 20140203183831.751838Z#000000#001#000000 contextCSN: 20140204143957.937393Z#000000#002#000000

mm-server2: entryCSN: 20140121153301.911487Z#000000#003#000000 contextCSN: 20140129140325.443822Z#000000#000#000000 contextCSN: 20140203183831.751838Z#000000#001#000000 contextCSN: 20140129183014.073734Z#000000#002#000000 contextCSN: 20140121153301.911487Z#000000#003#000000

1. What is this information telling me? (I want to be sure that I

know) 2) Should I be concerned that there are more on mm-server2?

a) Ignore entryCSN

b) This means that mm-server2 has knowledge of 3 masters (1, 2, 3) mm-server1 only has knowledge of 2 masters (1, 2). This would imply that there is something broken in your setup.

--Quanah

--

Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

Ok,

Looking back at old board messages, I was able to get slapd started. Even after chown -R ldap:ldap both the accesslog and openldap-data directories (and -u ldap in the slapd command-line), most of the files became owned by root:root. But, after the failure, re-chowned and it worked.

But, still concerned about the "...access granted by manage..."

Thanks, John ________________________________________ From: openldap-technical-bounces@OpenLDAP.org [openldap-technical-bounces@OpenLDAP.org] On Behalf Of Borresen, John - 0442 - MITLL [John.Borresen@ll.mit.edu] Sent: Tuesday, February 11, 2014 2:41 PM To: Quanah Gibson-Mount; Michael Ströder; openldap-technical@openldap.org Subject: RE: Simple way to check that MMR is in sync?

All,

I attempted to slapadd the main dbase to the mm-server2 in an attempt to sync things up. Thought it was going well (no errors when doing the slapadd) but when attempting to start slapd, it failed. Here is the tail end of the start up:

237 52fa74d3 => test_filter 238 52fa74d3 GE 239 52fa74d3 => access_allowed: search access to "olcOverlay={0}syncprov,olcDatabase={0}config,cn=config" "entryCSN" requested 240 52fa74d3 <= root access granted 241 52fa74d3 => access_allowed: search access granted by manage(=mwrscxd) 242 52fa74d3 <= test_filter 5 243 52fa74d3 => test_filter 244 52fa74d3 GE 245 52fa74d3 => access_allowed: search access to "olcDatabase={1}bdb,cn=config" "entryCSN" requested 246 52fa74d3 <= root access granted 247 52fa74d3 => access_allowed: search access granted by manage(=mwrscxd) 248 52fa74d3 <= test_filter 6 249 52fa74d3 => test_filter 250 52fa74d3 GE 251 52fa74d3 => access_allowed: search access to "olcOverlay={0}accesslog,olcDatabase={1}bdb,cn=config" "entryCSN" requested 252 52fa74d3 <= root access granted 253 52fa74d3 => access_allowed: search access granted by manage(=mwrscxd) 254 52fa74d3 <= test_filter 5 255 52fa74d3 => test_filter 256 52fa74d3 GE 257 52fa74d3 => access_allowed: search access to "olcOverlay={1}syncprov,olcDatabase={1}bdb,cn=config" "entryCSN" requested 258 52fa74d3 <= root access granted 259 52fa74d3 => access_allowed: search access granted by manage(=mwrscxd) 260 52fa74d3 <= test_filter 5 261 52fa74d3 => test_filter 262 52fa74d3 GE 263 52fa74d3 => access_allowed: search access to "olcDatabase={2}bdb,cn=config" "entryCSN" requested 264 52fa74d3 <= root access granted 265 52fa74d3 => access_allowed: search access granted by manage(=mwrscxd) 266 52fa74d3 <= test_filter 5 267 52fa74d3 => test_filter 268 52fa74d3 GE 269 52fa74d3 => access_allowed: search access to "olcOverlay={0}syncprov,olcDatabase={2}bdb,cn=config" "entryCSN" requested 270 52fa74d3 <= root access granted 271 52fa74d3 => access_allowed: search access granted by manage(=mwrscxd) 272 52fa74d3 <= test_filter 5 273 52fa74d3 => test_filter 274 52fa74d3 GE 275 52fa74d3 => access_allowed: search access to "olcDatabase={3}monitor,cn=config" "entryCSN" requested 276 52fa74d3 <= root access granted 277 52fa74d3 => access_allowed: search access granted by manage(=mwrscxd) 278 52fa74d3 <= test_filter 5 279 52fa74d3 send_ldap_result: conn=-1 op=0 p=0 280 52fa74d3 send_ldap_result: err=0 matched="" text="" 281 52fa74d3 backend_startup_one: starting "dc=example,dc=ldap" 282 52fa74d3 bdb_db_open: "dc=example,dc=ldap" 283 52fa74d3 bdb_db_open: database "dc=example,dc=ldap": alock package is unstable. 284 52fa74d3 backend_startup_one (type=bdb, suffix="dc=example,dc=ldap"): bi_db_open failed! (-1) 285 52fa74d3 slapd shutdown: initiated 286 52fa74d3 ====> bdb_cache_release_all 287 52fa74d3 ====> bdb_cache_release_all 288 52fa74d3 slapd destroy: freeing system resources. 289 52fa74d3 syncinfo_free: rid=001 290 52fa74d3 slapd stopped.

1) I don't understand the "...access granted by manage...", as I've looked and looked and compared side by side the olcAccess, etc and no one has manage privs.

2) I noticed the "alock package is unstable" then on the next line "bi_db_open failed!" nasty gram.

Thanks in advance

John ________________________________________ From: openldap-technical-bounces@OpenLDAP.org [openldap-technical-bounces@OpenLDAP.org] On Behalf Of Borresen, John - 0442 - MITLL [John.Borresen@ll.mit.edu] Sent: Tuesday, February 11, 2014 1:34 PM To: Quanah Gibson-Mount; Michael Ströder; openldap-technical@openldap.org Subject: RE: Simple way to check that MMR is in sync?

Thanks Quanah;

I take it that your advice from a while back still stands, slapadd the main dbase from mm-server1 to mm-server2 (this time I won't do a slapindex -- honest)?

Thanks in advance John

-----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Monday, February 10, 2014 6:42 PM To: Borresen, John - 0442 - MITLL; Michael Ströder; openldap-technical@openldap.org Subject: RE: Simple way to check that MMR is in sync?

--On Monday, February 10, 2014 5:23 PM -0500 "Borresen, John - 0442 - MITLL" John.Borresen@ll.mit.edu wrote:

All,

I've been reading this string...

Comparing the entryCSNs & contextCSNs on both of my test servers at the base DN (dc=example,dc=ldap):

mm-server1: entryCSN: 20140121153301.911487Z#000000#003#000000 contextCSN: 20140203183831.751838Z#000000#001#000000 contextCSN: 20140204143957.937393Z#000000#002#000000

mm-server2: entryCSN: 20140121153301.911487Z#000000#003#000000 contextCSN: 20140129140325.443822Z#000000#000#000000 contextCSN: 20140203183831.751838Z#000000#001#000000 contextCSN: 20140129183014.073734Z#000000#002#000000 contextCSN: 20140121153301.911487Z#000000#003#000000

1. What is this information telling me? (I want to be sure that I

know) 2) Should I be concerned that there are more on mm-server2?

a) Ignore entryCSN

b) This means that mm-server2 has knowledge of 3 masters (1, 2, 3) mm-server1 only has knowledge of 2 masters (1, 2). This would imply that there is something broken in your setup.

--Quanah

--

Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

I guess "got empty syncUUID" is the problem.

...

...

"Borresen, John - 0442 - MITLL" John.Borresen@ll.mit.edu schrieb am

11.02.2014 um 22:18 in Nachricht 201402112118.s1BLIY8Z075659@boole.openldap.org:

All,

On mm-server1, I modified the cn=role2,ou=sudoers,dc=example,dc=ldap, by adding four more "sudoUsers":

# ldapmodify -H ldap://mm-server1.example.ldap -d 256 -x -D cn=ldapadmin,dc=example,dc=ldap -x -W Enter LDAP Password: dn: cn=role2,ou=sudoers,dc=example,dc=ldap changetype: modify add: sudoUser sudoUser: jdoe3

modifying entry "cn=role2,ou=sudoers,dc=example,dc=ldap"

dn: cn=role2,ou=sudoers,dc=example,dc=ldap changetype: modify add: sudoUser sudoUser: jdoe4

modifying entry "cn=role2,ou=sudoers,dc=example,dc=ldap"

dn: cn=role2,ou=sudoers,dc=example,dc=ldap changetype: modify add: sudoUser sudoUser: jdoe5

modifying entry "cn=role2,ou=sudoers,dc=example,dc=ldap"

dn: cn=role2,ou=sudoers,dc=example,dc=ldap changetype: modify add: sudoUser sudoUser: jdoe6

modifying entry "cn=role2,ou=sudoers,dc=example,dc=ldap"

In the accesslog on mm-server1: # ldapsearch -W -x -b cn=accesslog -v -D uid=replicator,ou=Admins,dc=example,dc=ldap reqStart ldap_initialize( <DEFAULT> ) Enter LDAP Password: filter: (objectclass=*) requesting: reqStart # extended LDIF # # LDAPv3 # base <cn=accesslog> with scope subtree # filter: (objectclass=*) # requesting: reqStart #

# accesslog dn: cn=accesslog

# 20140211203708.000000Z, accesslog dn: reqStart=20140211203708.000000Z,cn=accesslog reqStart: 20140211203708.000000Z

# 20140211203748.000000Z, accesslog dn: reqStart=20140211203748.000000Z,cn=accesslog reqStart: 20140211203748.000000Z

# 20140211203819.000000Z, accesslog dn: reqStart=20140211203819.000000Z,cn=accesslog reqStart: 20140211203819.000000Z

# 20140211203851.000000Z, accesslog dn: reqStart=20140211203851.000000Z,cn=accesslog reqStart: 20140211203851.000000Z

# search result search: 2 result: 0 Success

# numResponses: 6 # numEntries: 5

On mm-server2 nothing is updating but am seeing this in the logs: (rid=001

is

mm-server1) 52fa9043 send_ldap_result: err=0 matched="" text="" ldap_build_search_req ATTRS: reqDN reqType reqMod reqNewRDN reqDeleteOldRDN

reqNewSuperior entryCSN 52fa9066 do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) 52fa9066 do_syncrepl: rid=001 rc -1 retrying ldap_build_search_req ATTRS: reqDN reqType reqMod reqNewRDN reqDeleteOldRDN

reqNewSuperior entryCSN 52fa90a2 do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) 52fa90a2 do_syncrepl: rid=001 rc -1 retrying 52fa90d1 connection_get(76) ldap_build_search_req ATTRS: reqDN reqType reqMod reqNewRDN reqDeleteOldRDN

reqNewSuperior entryCSN 52fa90de do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) 52fa90de do_syncrepl: rid=001 rc -1 retrying ldap_build_search_req ATTRS: reqDN reqType reqMod reqNewRDN reqDeleteOldRDN

reqNewSuperior entryCSN 52fa911a do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) 52fa911a do_syncrepl: rid=001 rc -1 retrying ldap_build_search_req ATTRS: reqDN reqType reqMod reqNewRDN reqDeleteOldRDN

reqNewSuperior entryCSN 52fa9156 do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) 52fa9156 do_syncrepl: rid=001 rc -1 retrying ldap_build_search_req ATTRS: reqDN reqType reqMod reqNewRDN reqDeleteOldRDN

reqNewSuperior entryCSN 52fa9192 do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) 52fa9192 do_syncrepl: rid=001 rc -1 retrying ldap_build_search_req ATTRS: reqDN reqType reqMod reqNewRDN reqDeleteOldRDN

reqNewSuperior entryCSN 52fa91ce do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) 52fa91ce do_syncrepl: rid=001 rc -1 retrying ldap_build_search_req ATTRS: reqDN reqType reqMod reqNewRDN reqDeleteOldRDN

reqNewSuperior entryCSN 52fa920a do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) 52fa920a do_syncrepl: rid=001 rc -1 retrying ldap_build_search_req ATTRS: reqDN reqType reqMod reqNewRDN reqDeleteOldRDN

reqNewSuperior entryCSN 52fa9246 do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) 52fa9246 do_syncrepl: rid=001 rc -1 retrying

The "interval" is set to the default (01:00:00:00), type refreshAndPersist.

Yes, after reading the admin guide:

The LDAP Content Synchronization protocol has two operation types: refreshOnly and refreshAndPersist. The operation type is specified by the type parameter. In the refreshOnly operation, the next synchronization

search

operation is periodically rescheduled at an interval time after each synchronization operation finishes. The interval is specified by the

interval

parameter. It is set to one day by default. In the refreshAndPersist operation, a synchronization search remains persistent in the provider slapd

instance. Further updates to the master replica will generate searchResultEntry to the consumer slapd as the search responses to the persistent synchronization search.

1. is the interval really only used if the type is set to "refreshOnly"?

I am guessing by the "got empty syncUUID"...and "rid=001 rc -1 retrying"...that my MMR configuration is not working -- it's trying but not

working. I am not sure what else to look for to get things working.

Thanks in advance

John

-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Borresen, John - 0442 - MITLL Sent: Tuesday, February 11, 2014 2:57 PM To: Borresen, John - 0442 - MITLL; Quanah Gibson-Mount; Michael Ströder; openldap-technical@openldap.org Subject: RE: Simple way to check that MMR is in sync?

Ok,

Looking back at old board messages, I was able to get slapd started. Even after chown -R ldap:ldap both the accesslog and openldap-data directories

(and

-u ldap in the slapd command-line), most of the files became owned by root:root. But, after the failure, re-chowned and it worked.

But, still concerned about the "...access granted by manage..."

Thanks, John ________________________________________ From: openldap-technical-bounces@OpenLDAP.org [openldap-technical-bounces@OpenLDAP.org] On Behalf Of Borresen, John - 0442

• MITLL [John.Borresen@ll.mit.edu]

Sent: Tuesday, February 11, 2014 2:41 PM To: Quanah Gibson-Mount; Michael Ströder; openldap-technical@openldap.org Subject: RE: Simple way to check that MMR is in sync?

All,

I attempted to slapadd the main dbase to the mm-server2 in an attempt to

sync

things up. Thought it was going well (no errors when doing the slapadd) but

when attempting to start slapd, it failed. Here is the tail end of the

start

up:

237 52fa74d3 => test_filter 238 52fa74d3 GE 239 52fa74d3 => access_allowed: search access to "olcOverlay={0}syncprov,olcDatabase={0}config,cn=config" "entryCSN" requested 240 52fa74d3 <= root access granted 241 52fa74d3 => access_allowed: search access granted by

manage(=mwrscxd)

242 52fa74d3 <= test_filter 5
243 52fa74d3 => test_filter
244 52fa74d3     GE
245 52fa74d3 => access_allowed: search access to 

"olcDatabase={1}bdb,cn=config" "entryCSN" requested 246 52fa74d3 <= root access granted 247 52fa74d3 => access_allowed: search access granted by

manage(=mwrscxd)

248 52fa74d3 <= test_filter 6
249 52fa74d3 => test_filter
250 52fa74d3     GE
251 52fa74d3 => access_allowed: search access to 

"olcOverlay={0}accesslog,olcDatabase={1}bdb,cn=config" "entryCSN" requested 252 52fa74d3 <= root access granted 253 52fa74d3 => access_allowed: search access granted by

manage(=mwrscxd)

254 52fa74d3 <= test_filter 5
255 52fa74d3 => test_filter
256 52fa74d3     GE
257 52fa74d3 => access_allowed: search access to 

"olcOverlay={1}syncprov,olcDatabase={1}bdb,cn=config" "entryCSN" requested 258 52fa74d3 <= root access granted 259 52fa74d3 => access_allowed: search access granted by

manage(=mwrscxd)

260 52fa74d3 <= test_filter 5
261 52fa74d3 => test_filter
262 52fa74d3     GE
263 52fa74d3 => access_allowed: search access to 

"olcDatabase={2}bdb,cn=config" "entryCSN" requested 264 52fa74d3 <= root access granted 265 52fa74d3 => access_allowed: search access granted by

manage(=mwrscxd)

266 52fa74d3 <= test_filter 5
267 52fa74d3 => test_filter
268 52fa74d3     GE
269 52fa74d3 => access_allowed: search access to 

"olcOverlay={0}syncprov,olcDatabase={2}bdb,cn=config" "entryCSN" requested 270 52fa74d3 <= root access granted 271 52fa74d3 => access_allowed: search access granted by

manage(=mwrscxd)

272 52fa74d3 <= test_filter 5
273 52fa74d3 => test_filter
274 52fa74d3     GE
275 52fa74d3 => access_allowed: search access to 

"olcDatabase={3}monitor,cn=config" "entryCSN" requested 276 52fa74d3 <= root access granted 277 52fa74d3 => access_allowed: search access granted by

manage(=mwrscxd)

278 52fa74d3 <= test_filter 5
279 52fa74d3 send_ldap_result: conn=-1 op=0 p=0
280 52fa74d3 send_ldap_result: err=0 matched="" text=""
281 52fa74d3 backend_startup_one: starting "dc=example,dc=ldap"
282 52fa74d3 bdb_db_open: "dc=example,dc=ldap"
283 52fa74d3 bdb_db_open: database "dc=example,dc=ldap": alock package 

is unstable. 284 52fa74d3 backend_startup_one (type=bdb, suffix="dc=example,dc=ldap"): bi_db_open failed! (-1) 285 52fa74d3 slapd shutdown: initiated 286 52fa74d3 ====> bdb_cache_release_all 287 52fa74d3 ====> bdb_cache_release_all 288 52fa74d3 slapd destroy: freeing system resources. 289 52fa74d3 syncinfo_free: rid=001 290 52fa74d3 slapd stopped.

1. I don't understand the "...access granted by manage...", as I've looked

and looked and compared side by side the olcAccess, etc and no one has

manage

privs.

2. I noticed the "alock package is unstable" then on the next line

"bi_db_open failed!" nasty gram.

Thanks in advance

John ________________________________________ From: openldap-technical-bounces@OpenLDAP.org [openldap-technical-bounces@OpenLDAP.org] On Behalf Of Borresen, John - 0442

• MITLL [John.Borresen@ll.mit.edu]

Sent: Tuesday, February 11, 2014 1:34 PM To: Quanah Gibson-Mount; Michael Ströder; openldap-technical@openldap.org Subject: RE: Simple way to check that MMR is in sync?

Thanks Quanah;

I take it that your advice from a while back still stands, slapadd the main

dbase from mm-server1 to mm-server2 (this time I won't do a slapindex --

honest)?

Thanks in advance John

-----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Monday, February 10, 2014 6:42 PM To: Borresen, John - 0442 - MITLL; Michael Ströder; openldap-technical@openldap.org Subject: RE: Simple way to check that MMR is in sync?

--On Monday, February 10, 2014 5:23 PM -0500 "Borresen, John - 0442 - MITLL"

John.Borresen@ll.mit.edu wrote:

...

All,

I've been reading this string...

Comparing the entryCSNs & contextCSNs on both of my test servers at the base DN (dc=example,dc=ldap):

mm-server1: entryCSN: 20140121153301.911487Z#000000#003#000000 contextCSN: 20140203183831.751838Z#000000#001#000000 contextCSN: 20140204143957.937393Z#000000#002#000000

mm-server2: entryCSN: 20140121153301.911487Z#000000#003#000000 contextCSN: 20140129140325.443822Z#000000#000#000000 contextCSN: 20140203183831.751838Z#000000#001#000000 contextCSN: 20140129183014.073734Z#000000#002#000000 contextCSN: 20140121153301.911487Z#000000#003#000000

1. What is this information telling me? (I want to be sure that I

know) 2) Should I be concerned that there are more on mm-server2?

a) Ignore entryCSN

b) This means that mm-server2 has knowledge of 3 masters (1, 2, 3) mm-server1 only has knowledge of 2 masters (1, 2). This would imply that there is something broken in your setup.

--Quanah

--

Quanah Gibson-Mount Architect - Server Zimbra, Inc.

---

Zimbra :: the leader in open source messaging and collaboration