All,
I came in this morning, and the test environment was hung. Not sure what is going on. slapd on both servers will not stay up for more than 5-minutes. I tried to back step so attempted to slapadd from the dbase.ldif that I created the other day when things were working. When slapadding, I am receiving the following error: # slapadd -w -q -F /usr/local/openldap/etc/openldap/slapd.d -l /usr/local/openldap/etc/openldap/ldif/backup/mm-server2_example_ldap.ldif 52f3bb11 olcDbDirectory: value #0: invalid path: No such file or directory 52f3bb11 config error processing olcDatabase={1}bdb,cn=config: olcDbDirectory: value #0: invalid path: No such file or directory slapadd: bad configuration directory!
Any assistance as to what to look for would be great!
Thanks in advance John
________________________________________ From: Ulrich Windl [Ulrich.Windl@rz.uni-regensburg.de] Sent: Wednesday, February 05, 2014 2:50 AM To: Borresen, John - 0442 - MITLL; openldap-technical@openldap.org; Quanah Gibson-Mount Subject: Antw: RE: Syncrepl and mmr
"52f0fe5f send_search_entry: conn 1003 access to attribute userPassword, value #0 not allowed"
I'm not surprised that you have a problem with the user's password.
"Borresen, John - 0442 - MITLL" John.Borresen@ll.mit.edu schrieb am
04.02.2014 um 15:56 in Nachricht 201402041456.s14EuaHc022629@boole.openldap.org:
Here is a log snippet from mm-server2:
52f0fe5f => slap_access_allowed: read access granted by read(=rscxd) 52f0fe5f => access_allowed: read access granted by read(=rscxd) 52f0fe5f => access_allowed: result was in cache (objectClass) 52f0fe5f => access_allowed: result was in cache (objectClass) 52f0fe5f => access_allowed: result was in cache (objectClass) 52f0fe5f => access_allowed: result was in cache (objectClass) 52f0fe5f => access_allowed: result not in cache (userPassword) 52f0fe5f => access_allowed: read access to "uid=jdoe,ou=Users,dc=example,dc=ldap" "userPassword" requested 52f0fe5f => acl_get: [1] attr userPassword 52f0fe5f => acl_mask: access to entry "uid=jdoe,ou=Users,dc=example,dc=ldap", attr "userPassword" requested 52f0fe5f => acl_mask: to value by "cn=admin,cn=config", (=0) 52f0fe5f <= check a_dn_pat: self 52f0fe5f <= check a_dn_pat: anonymous 52f0fe5f <= check a_dn_pat: cn=ldapadmin,dc=example,dc=ldap 52f0fe5f <= check a_dn_pat: uid=replicator,ou=admins,dc=example,dc=ldap 52f0fe5f <= check a_dn_pat: * 52f0fe5f <= acl_mask: [5] applying none(=0) (stop) 52f0fe5f <= acl_mask: [5] mask: none(=0) 52f0fe5f => slap_access_allowed: read access denied by none(=0) 52f0fe5f => access_allowed: no more rules 52f0fe5f send_search_entry: conn 1003 access to attribute userPassword, value #0 not allowed 52f0fe5f conn=1003 op=20 ENTRY dn="uid=jdoe,ou=users,dc=example,dc=ldap" ber_flush2: 496 bytes to sd 21
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Borresen, John - 0442 - MITLL Sent: Tuesday, February 04, 2014 9:31 AM To: Quanah Gibson-Mount; openldap-technical@openldap.org Subject: RE: Syncrepl and mmr
All,
This morning, I shut down slapd on mm-server2 and, using the ldif that I created off of mm-server1 primary dbase (used slapcat to create) and attempted to resync the dbases.
Background: when viewing the dbases on mm-server1 and mm-server2 on Apache Directory Studio (binding with cn=ldapadmin,dc=example,dc=ldap), the "ou=Users,dc=example,dc=ldap" will show the userPassword attribute on mm-server1, but NOT on mm-server2. If I perform an ldapsearch (again, with cn=ldapadmin,dc=example,dc=ldap, on both servers the userPassword attribute echoes out to console as expected. When binding to uid=replicator,ou=Admins,dc=example,dc=ldap on both servers, on the Apache Directory Studio, the userPassword attribute is seen.
Now, this morning, as stated, slapd was shut down on mm-server2.
Moved /var/lib/openldap/openldap-data out of the way Recreated the /var/lib/openldap/openldap-data directory, copying the DB_CONFIG back in.
Chowned it the directory to ldap:ldap
Ran:
# slapadd -w -q -F /usr/local/openldap/etc/openldap/slapd.d -l /usr/local/openldap/etc/openldap/ldif/backup/example_ldap.ldif _#################### 100.00% eta none elapsed none fast!
Closing DB... # /usr/local/openldap/sbin/slapindex -F /usr/local/openldap/etc/openldap/slapd.d
Reconnected, to mm-server2 via the Apache Directory Studio using cn=ldapadmin,dc=example,dc=ldap & uid=replicator,ou=Admins,dc=example,dc=ldap, same results as before.
Any suggestions?
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: Monday, February 03, 2014 4:22 PM To: Quanah Gibson-Mount; openldap-technical@openldap.org Subject: RE: Syncrepl and mmr
Well...that was a "doh!" on my part. <lol>
One last stupid question for the evening. "slapcat" created the ldif, when slapadd-ing to the the secondary, should I remove the extra lines (ex. entryUUID, creatorsName,createTimeStamp)?
Thanks, John
-----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Monday, February 03, 2014 4:03 PM To: Borresen, John - 0442 - MITLL; openldap-technical@openldap.org Subject: RE: Syncrepl and mmr
--On Monday, February 03, 2014 3:57 PM -0500 "Borresen, John - 0442 - MITLL" John.Borresen@ll.mit.edu wrote:
Hmmmmmmmm,
Taking your advice to reload the secondary from the primary...by creating master set of ldifs off of the primary (mm-server1):
On the primary (mm-server1): # slapcat -F /usr/local/openldap/etc/openldap/slapd.d -l # backup/example_ldap.ldif -b dc=example,dc=ldap 52f000f2 ldif_read_file: checksum error on "/usr/local/openldap/etc/openldap/slapd.d/cn=config.ldif" 52f000f2 bdb_monitor_db_open: monitoring disabled; configure monitor database to enable
On the secondary (mm-server2): the same command worked...
There is no indication here the command failed. All it is reporting is that someone modified cn=config.ldif by hand rather than correctly using ldapmodify.
--Quanah
--
Quanah Gibson-Mount Architect - Server Zimbra, Inc.
Zimbra :: the leader in open source messaging and collaboration