question on syncprov
by Steve Reveliotty
Hi,
I'm trying to migrate from OpenLDAP 2.3.43-12.el5_6.7 to OpenLDAP
2.4.23-20.el6.x86_6.
In 2.3, we currently have one master, replicating changes to 2 consumers
via slurpd.
I'm trying to configure 2.4 w/ syncrepl, and have tried using
refreshAndPersist to mimic that same routine
of pushing changes from the master. I'm getting failures though:
on the master:
ay 25 13:55:25 slapd[6855]: send_search_entry: conn 1064 ber write failed.
May 25 13:55:45 slapd[6855]: send_search_entry: conn 1066 ber write failed.
May 25 13:56:45 slapd[6855]: send_search_entry: conn 1068 ber write
failed.
May 25 13:57:45 slapd[6855]: send_search_entry: conn 1078 ber write failed.
May 25 13:58:45 slapd[6855]: send_search_entry: conn 1084 ber write failed.
May 25 13:59:05 slapd[6855]: send_search_entry: conn 1086 ber write failed.
May 25 13:59:15 slapd[6855]: send_search_entry: conn 1087 ber write failed.
on a consumer:
May 25 13:45:15 slapd[28707]: do_syncrepl: rid=002 rc 68 retrying (9
retries left)
May 25 13:45:25 slapd[28707]: syncrepl_entry: rid=002 be_add
cn=XXXXXXX,dc=edu failed (68)
here are snippets from the master's slapd.conf and from one of the
consumers:
master -
-------
database hdb
include /etc/openldap/slapd.access
suffix "dc=XXXXdc=edu"
checkpoint 1024 5
cachesize 30000
idlcachesize 90000
rootdn "cn=Manager,XXXXX,dc=edu"
# NOTE: "updatedn" MUST BE COMMENTED OUT FOR INITIAL CREATION/LOAD OF
# ROOT INFO
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
# Cleartext passwords, especially for the rootdn, should
# be avoid. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
#rootpw secret
# needs to be changed to something someone knows.
rootpw secret
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/ldap
# Indices to maintain
# review these
index default pres,eq
index uid eq,sub
index entryUUID,entryCSN
index cn,sn,givenName,ou,mail,telephoneNumber pres,eq,sub
index employeeNumber,mailAlternateAddress,eduPersonPrincipalName
index eduPersonAffiliation,eduPersonPrimaryAffiliation
index objectClass,serialNumber eq
index isMemberOf eq,subany
TLSCertificateFile /etc/openldap/newcert.pem
TLSCertificateKeyFile /etc/openldap/newkey.pem
TLSCACertificateFile /etc/openldap/chain.pem
consumer -
------------------
database hdb
suffix "dc=XXXXX=edu"
checkpoint 1024 5
cachesize 30000
idlcachesize 90000
rootdn "cn=Manager,dc=XXXX,dc=edu"
# NOTE: "updatedn" MUST BE COMMENTED OUT FOR INITIAL CREATION/LOAD OF
# ROOT INFO
# Cleartext passwords, especially for the rootdn, should
# be avoid. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
#rootpw secret
# needs to be changed to something someone knows.
rootpw secret
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/ldap
# Indices to maintain
# review these
index default pres,eq
index uid eq,sub
index entryUUID,entryCSN
index cn,sn,givenName,ou,mail,telephoneNumber pres,eq,sub
index employeeNumber,mailAlternateAddress,eduPersonPrincipalName
index eduPersonAffiliation,eduPersonPrimaryAffiliation
index objectClass,serialNumber eq
index isMemberOf eq,subany
TLSCertificateFile /etc/openldap/newcert.pem
TLSCertificateKeyFile /etc/openldap/newkey.pem
TLSCACertificateFile /etc/openldap/chain.pem
syncrepl rid=002
provider=ldap://providername-taken-out-here:389
type=refreshAndPersist
retry="10 10 60 +"
searchbase="dc=XXXX,dc=edu"
filter="(objectClass=*)"
attrs="*"
scope=sub
schemachecking=off
bindmethod=simple
binddn="cn=Replicator,dc=XXXX,dc=edu"
credentials="password"
updateref ldap://providername-takenout-here:389
the account I"m using to bind from the consumer has read access to
everything on the master.
Thanks in advance
11 years, 3 months
slapd keeps crashing
by David Massie
Our slapd instance keeps crashing. We do not see an obvious reason for the
crashes. I am posting the crash report in the hope that someone will see
something and can point us in the right direction.
Thanks,
Dave Massie
Duplicate check
=====
Common information
=====
package
-----
architecture
-----
x86_64
kernel
-----
2.6.32-220.13.1.el6.x86_64
Additional information
=====
uid
-----
0
time
-----
1337786308
executable
-----
/var/services/openldap/libexec/slapd
component
-----
hostname
-----
aaaprod-master.uis.georgetown.edu
username
-----
root
reason
-----
Process /var/services/openldap/libexec/slapd was killed by signal 6
(SIGABRT)
analyzer
-----
CCpp
maps
-----
00400000-00624000 r-xp 00000000 fd:00 3675557
/var/services/openldap/libexec/slapd
00824000-00831000 rw-p 00224000 fd:00 3675557
/var/services/openldap/libexec/slapd
00831000-008d6000 rw-p 00000000 00:00 0
0104f000-012eb000 rw-p 00000000 00:00 0
012eb000-01441000 rw-p 00000000 00:00 0
394f800000-394f820000 r-xp 00000000 fd:00 1703938
/lib64/ld-2.12.so
394fa1f000-394fa20000 r--p 0001f000 fd:00 1703938
/lib64/ld-2.12.so
394fa20000-394fa21000 rw-p 00020000 fd:00 1703938
/lib64/ld-2.12.so
394fa21000-394fa22000 rw-p 00000000 00:00 0
394fc00000-394fd86000 r-xp 00000000 fd:00 1703939
/lib64/libc-2.12.so
394fd86000-394ff86000 ---p 00186000 fd:00 1703939
/lib64/libc-2.12.so
394ff86000-394ff8a000 r--p 00186000 fd:00 1703939
/lib64/libc-2.12.so
394ff8a000-394ff8b000 rw-p 0018a000 fd:00 1703939
/lib64/libc-2.12.so
394ff8b000-394ff90000 rw-p 00000000 00:00 0
3950000000-3950002000 r-xp 00000000 fd:00 1703950
/lib64/libdl-2.12.so
3950002000-3950202000 ---p 00002000 fd:00 1703950
/lib64/libdl-2.12.so
3950202000-3950203000 r--p 00002000 fd:00 1703950
/lib64/libdl-2.12.so
3950203000-3950204000 rw-p 00003000 fd:00 1703950
/lib64/libdl-2.12.so
3950400000-3950417000 r-xp 00000000 fd:00 1703943
/lib64/libpthread-2.12.so
3950417000-3950616000 ---p 00017000 fd:00 1703943
/lib64/libpthread-2.12.so
3950616000-3950617000 r--p 00016000 fd:00 1703943
/lib64/libpthread-2.12.so
3950617000-3950618000 rw-p 00017000 fd:00 1703943
/lib64/libpthread-2.12.so
3950618000-395061c000 rw-p 00000000 00:00 0
3950800000-395081d000 r-xp 00000000 fd:00 1703962
/lib64/libselinux.so.1
395081d000-3950a1c000 ---p 0001d000 fd:00 1703962
/lib64/libselinux.so.1
3950a1c000-3950a1d000 r--p 0001c000 fd:00 1703962
/lib64/libselinux.so.1
3950a1d000-3950a1e000 rw-p 0001d000 fd:00 1703962
/lib64/libselinux.so.1
3950a1e000-3950a1f000 rw-p 00000000 00:00 0
3951400000-3951416000 r-xp 00000000 fd:00 1703956
/lib64/libresolv-2.12.so
3951416000-3951616000 ---p 00016000 fd:00 1703956
/lib64/libresolv-2.12.so
3951616000-3951617000 r--p 00016000 fd:00 1703956
/lib64/libresolv-2.12.so
3951617000-3951618000 rw-p 00017000 fd:00 1703956
/lib64/libresolv-2.12.so
3951618000-395161a000 rw-p 00000000 00:00 0
3951c00000-3951c15000 r-xp 00000000 fd:00 1703994
/lib64/libz.so.1.2.3
3951c15000-3951e14000 ---p 00015000 fd:00 1703994
/lib64/libz.so.1.2.3
3951e14000-3951e15000 r--p 00014000 fd:00 1703994
/lib64/libz.so.1.2.3
3951e15000-3951e16000 rw-p 00015000 fd:00 1703994
/lib64/libz.so.1.2.3
3952000000-3952007000 r-xp 00000000 fd:00 1703999
/lib64/libcrypt-2.12.so
3952007000-3952207000 ---p 00007000 fd:00 1703999
/lib64/libcrypt-2.12.so
3952207000-3952208000 r--p 00007000 fd:00 1703999
/lib64/libcrypt-2.12.so
3952208000-3952209000 rw-p 00008000 fd:00 1703999
/lib64/libcrypt-2.12.so
3952209000-3952237000 rw-p 00000000 00:00 0
3952400000-395245d000 r-xp 00000000 fd:00 1703997
/lib64/libfreebl3.so
395245d000-395265c000 ---p 0005d000 fd:00 1703997
/lib64/libfreebl3.so
395265c000-395265d000 r--p 0005c000 fd:00 1703997
/lib64/libfreebl3.so
395265d000-395265e000 rw-p 0005d000 fd:00 1703997
/lib64/libfreebl3.so
395265e000-3952662000 rw-p 00000000 00:00 0
3952c00000-3952d6f000 r-xp 00000000 fd:00 1703948
/lib64/libdb-4.7.so
3952d6f000-3952f6e000 ---p 0016f000 fd:00 1703948
/lib64/libdb-4.7.so
3952f6e000-3952f74000 rw-p 0016e000 fd:00 1703948
/lib64/libdb-4.7.so
3953000000-3953019000 r-xp 00000000 fd:00 2361953
/usr/lib64/libsasl2.so.2.0.23
3953019000-3953218000 ---p 00019000 fd:00 2361953
/usr/lib64/libsasl2.so.2.0.23
3953218000-3953219000 r--p 00018000 fd:00 2361953
/usr/lib64/libsasl2.so.2.0.23
3953219000-395321a000 rw-p 00019000 fd:00 2361953
/usr/lib64/libsasl2.so.2.0.23
3953c00000-3953c2a000 r-xp 00000000 fd:00 1703964
/lib64/libk5crypto.so.3.1
3953c2a000-3953e29000 ---p 0002a000 fd:00 1703964
/lib64/libk5crypto.so.3.1
3953e29000-3953e2b000 r--p 00029000 fd:00 1703964
/lib64/libk5crypto.so.3.1
3953e2b000-3953e2c000 rw-p 0002b000 fd:00 1703964
/lib64/libk5crypto.so.3.1
3954000000-3954002000 r-xp 00000000 fd:00 1703952
/lib64/libkeyutils.so.1.3
3954002000-3954201000 ---p 00002000 fd:00 1703952
/lib64/libkeyutils.so.1.3
3954201000-3954202000 r--p 00001000 fd:00 1703952
/lib64/libkeyutils.so.1.3
3954202000-3954203000 rw-p 00002000 fd:00 1703952
/lib64/libkeyutils.so.1.3
3954400000-395440a000 r-xp 00000000 fd:00 1703963
/lib64/libkrb5support.so.0.1
395440a000-3954609000 ---p 0000a000 fd:00 1703963
/lib64/libkrb5support.so.0.1
3954609000-395460a000 r--p 00009000 fd:00 1703963
/lib64/libkrb5support.so.0.1
395460a000-395460b000 rw-p 0000a000 fd:00 1703963
/lib64/libkrb5support.so.0.1
3955800000-395583f000 r-xp 00000000 fd:00 1703977
/lib64/libgssapi_krb5.so.2.2
395583f000-3955a3f000 ---p 0003f000 fd:00 1703977
/lib64/libgssapi_krb5.so.2.2
3955a3f000-3955a40000 r--p 0003f000 fd:00 1703977
/lib64/libgssapi_krb5.so.2.2
3955a40000-3955a42000 rw-p 00040000 fd:00 1703977
/lib64/libgssapi_krb5.so.2.2
3955c00000-3955cd4000 r-xp 00000000 fd:00 1703973
/lib64/libkrb5.so.3.3
3955cd4000-3955ed4000 ---p 000d4000 fd:00 1703973
/lib64/libkrb5.so.3.3
3955ed4000-3955edd000 r--p 000d4000 fd:00 1703973
/lib64/libkrb5.so.3.3
3955edd000-3955edf000 rw-p 000dd000 fd:00 1703973
/lib64/libkrb5.so.3.3
3956800000-3956973000 r-xp 00000000 fd:00 2363773
/usr/lib64/libcrypto.so.1.0.0
3956973000-3956b73000 ---p 00173000 fd:00 2363773
/usr/lib64/libcrypto.so.1.0.0
3956b73000-3956b8c000 r--p 00173000 fd:00 2363773
/usr/lib64/libcrypto.so.1.0.0
3956b8c000-3956b96000 rw-p 0018c000 fd:00 2363773
/usr/lib64/libcrypto.so.1.0.0
3956b96000-3956b9a000 rw-p 00000000 00:00 0
3957800000-3957853000 r-xp 00000000 fd:00 2363947
/usr/lib64/libssl.so.1.0.0
3957853000-3957a53000 ---p 00053000 fd:00 2363947
/usr/lib64/libssl.so.1.0.0
3957a53000-3957a56000 r--p 00053000 fd:00 2363947
/usr/lib64/libssl.so.1.0.0
3957a56000-3957a5b000 rw-p 00056000 fd:00 2363947
/usr/lib64/libssl.so.1.0.0
7f70d8000000-7f70d80e8000 rw-p 00000000 00:00 0
7f70d80e8000-7f70dc000000 ---p 00000000 00:00 0
7f70e0000000-7f70e8000000 rw-p 00000000 00:00 0
7f70e8000000-7f70ed94c000 rw-p 00000000 00:00 0
7f70ed94c000-7f70f0000000 ---p 00000000 00:00 0
7f70f4000000-7f70ffff8000 rw-p 00000000 00:00 0
7f70ffff8000-7f7100000000 ---p 00000000 00:00 0
7f7100000000-7f7100458000 rw-p 00000000 00:00 0
7f7100458000-7f7104000000 ---p 00000000 00:00 0
7f7108000000-7f7110000000 rw-p 00000000 00:00 0
7f7110000000-7f7118000000 rw-p 00000000 00:00 0
7f7118000000-7f711c69d000 rw-p 00000000 00:00 0
7f711c69d000-7f7120000000 ---p 00000000 00:00 0
7f7120000000-7f7124000000 rw-p 00000000 00:00 0
7f7128000000-7f7130000000 rw-p 00000000 00:00 0
7f7130000000-7f7135fe7000 rw-p 00000000 00:00 0
7f7135fe7000-7f7138000000 ---p 00000000 00:00 0
7f7138000000-7f7140000000 rw-p 00000000 00:00 0
7f7140000000-7f7148000000 rw-p 00000000 00:00 0
7f7148000000-7f714fa52000 rw-p 00000000 00:00 0
7f714fa52000-7f7150000000 ---p 00000000 00:00 0
7f7150000000-7f7158000000 rw-p 00000000 00:00 0
7f7158000000-7f715e575000 rw-p 00000000 00:00 0
7f715e575000-7f7160000000 ---p 00000000 00:00 0
7f7160000000-7f7168000000 rw-p 00000000 00:00 0
7f7168000000-7f716c000000 rw-p 00000000 00:00 0
7f716c000000-7f7170000000 rw-p 00000000 00:00 0
7f7170000000-7f7174000000 rw-p 00000000 00:00 0
7f71777ff000-7f7177800000 ---p 00000000 00:00 0
7f7177800000-7f7178000000 rw-p 00000000 00:00 0
7f7178000000-7f717bfff000 rw-p 00000000 00:00 0
7f717bfff000-7f717c000000 ---p 00000000 00:00 0
7f717c000000-7f717cd6a000 rw-p 00000000 00:00 0
7f717cd6a000-7f7180000000 ---p 00000000 00:00 0
7f7180000000-7f7180d78000 rw-p 00000000 00:00 0
7f7180d78000-7f7184000000 ---p 00000000 00:00 0
7f7186fff000-7f7188000000 rw-p 00000000 00:00 0
7f7188000000-7f7188dab000 rw-p 00000000 00:00 0
7f7188dab000-7f718c000000 ---p 00000000 00:00 0
7f718cffd000-7f7190000000 rw-p 00000000 00:00 0
7f7190000000-7f7190d8d000 rw-p 00000000 00:00 0
7f7190d8d000-7f7194000000 ---p 00000000 00:00 0
7f71947fc000-7f71977ff000 rw-p 00000000 00:00 0
7f71977ff000-7f7197800000 ---p 00000000 00:00 0
7f7197800000-7f7198000000 rw-p 00000000 00:00 0
7f7198000000-7f719c000000 rw-p 00000000 00:00 0
7f719c7fb000-7f719e7fd000 rw-p 00000000 00:00 0
7f719e7fd000-7f719e7fe000 ---p 00000000 00:00 0
7f719e7fe000-7f719effe000 rw-p 00000000 00:00 0
7f719effe000-7f719efff000 ---p 00000000 00:00 0
7f719efff000-7f719f7ff000 rw-p 00000000 00:00 0
7f719f7ff000-7f719f800000 ---p 00000000 00:00 0
7f719f800000-7f71a0000000 rw-p 00000000 00:00 0
7f71a0000000-7f71a0d21000 rw-p 00000000 00:00 0
7f71a0d21000-7f71a4000000 ---p 00000000 00:00 0
7f71a4000000-7f71a8000000 rw-p 00000000 00:00 0
7f71a87fa000-7f71a87fb000 ---p 00000000 00:00 0
7f71a87fb000-7f71a8ffb000 rw-p 00000000 00:00 0
7f71a8ffb000-7f71a8ffc000 ---p 00000000 00:00 0
7f71a8ffc000-7f71a97fc000 rw-p 00000000 00:00 0
7f71a97fc000-7f71a97fd000 ---p 00000000 00:00 0
7f71a97fd000-7f71a9ffd000 rw-p 00000000 00:00 0
7f71a9ffd000-7f71a9ffe000 ---p 00000000 00:00 0
7f71a9ffe000-7f71ab7ff000 rw-p 00000000 00:00 0
7f71ab7ff000-7f71ab800000 ---p 00000000 00:00 0
7f71ab800000-7f71ac000000 rw-p 00000000 00:00 0
7f71ac000000-7f71b0000000 rw-p 00000000 00:00 0
7f71b0000000-7f71b133a000 rw-p 00000000 00:00 0
7f71b133a000-7f71b4000000 ---p 00000000 00:00 0
7f71b47fc000-7f71b67fe000 rw-p 00000000 00:00 0
7f71b67fe000-7f71b67ff000 ---p 00000000 00:00 0
7f71b67ff000-7f71b8000000 rw-p 00000000 00:00 0
7f71b8000000-7f71be8e6000 rw-p 00000000 00:00 0
7f71be8e6000-7f71c0000000 ---p 00000000 00:00 0
7f71c0000000-7f71c7ffd000 rw-p 00000000 00:00 0
7f71c7ffd000-7f71c8000000 ---p 00000000 00:00 0
7f71c8000000-7f71d0000000 rw-p 00000000 00:00 0
7f71d0000000-7f71d4000000 rw-p 00000000 00:00 0
7f71d47fb000-7f71d47fc000 ---p 00000000 00:00 0
7f71d47fc000-7f71d4ffc000 rw-p 00000000 00:00 0
7f71d4ffc000-7f71d4ffd000 ---p 00000000 00:00 0
7f71d4ffd000-7f71d67fe000 rw-p 00000000 00:00 0
7f71d67fe000-7f71d67ff000 ---p 00000000 00:00 0
7f71d67ff000-7f71d8000000 rw-p 00000000 00:00 0
7f71d8000000-7f71dc000000 rw-p 00000000 00:00 0
7f71dc000000-7f71e0000000 rw-p 00000000 00:00 0
7f71e0000000-7f71e0021000 rw-p 00000000 00:00 0
7f71e0021000-7f71e4000000 ---p 00000000 00:00 0
7f71e4253000-7f71e5254000 rw-p 00000000 00:00 0
7f71e5254000-7f71e5255000 ---p 00000000 00:00 0
7f71e5255000-7f71e5a55000 rw-p 00000000 00:00 0
7f71e5a55000-7f71e5a56000 ---p 00000000 00:00 0
7f71e5a56000-7f71e7257000 rw-p 00000000 00:00 0
7f71e7257000-7f71e7258000 ---p 00000000 00:00 0
7f71e7258000-7f71ece46000 rw-p 00000000 00:00 0
7f71ece46000-7f71ece4e000 rw-s 00000000 fd:00 3675649
/var/services/openldap/var/openldap-data/__db.006
7f71ece4e000-7f71ed230000 rw-s 00000000 fd:00 3675587
/var/services/openldap/var/openldap-data/__db.005
7f71ed230000-7f71ed470000 rw-s 00000000 fd:00 3675569
/var/services/openldap/var/openldap-data/__db.004
7f71ed470000-7f722d470000 rw-s 00000000 fd:00 3675566
/var/services/openldap/var/openldap-data/__db.003
7f722d470000-7f722f722000 rw-s 00000000 fd:00 3675035
/var/services/openldap/var/openldap-data/__db.002
7f722f722000-7f722f9e3000 rw-p 00000000 00:00 0
7f722f9e3000-7f722f9e7000 r-xp 00000000 fd:00 2360495
/usr/lib64/sasl2/libanonymous.so.2.0.23
7f722f9e7000-7f722fbe6000 ---p 00004000 fd:00 2360495
/usr/lib64/sasl2/libanonymous.so.2.0.23
7f722fbe6000-7f722fbe7000 r--p 00003000 fd:00 2360495
/usr/lib64/sasl2/libanonymous.so.2.0.23
7f722fbe7000-7f722fbe8000 rw-p 00004000 fd:00 2360495
/usr/lib64/sasl2/libanonymous.so.2.0.23
7f722fbe8000-7f722fbec000 r-xp 00000000 fd:00 2364158
/usr/lib64/sasl2/libplain.so.2.0.23
7f722fbec000-7f722fdeb000 ---p 00004000 fd:00 2364158
/usr/lib64/sasl2/libplain.so.2.0.23
7f722fdeb000-7f722fdec000 r--p 00003000 fd:00 2364158
/usr/lib64/sasl2/libplain.so.2.0.23
7f722fdec000-7f722fded000 rw-p 00004000 fd:00 2364158
/usr/lib64/sasl2/libplain.so.2.0.23
7f722fded000-7f722fdf2000 r-xp 00000000 fd:00 2360498
/usr/lib64/sasl2/libsasldb.so.2.0.23
7f722fdf2000-7f722fff1000 ---p 00005000 fd:00 2360498
/usr/lib64/sasl2/libsasldb.so.2.0.23
7f722fff1000-7f722fff2000 r--p 00004000 fd:00 2360498
/usr/lib64/sasl2/libsasldb.so.2.0.23
7f722fff2000-7f722fff3000 rw-p 00005000 fd:00 2360498
/usr/lib64/sasl2/libsasldb.so.2.0.23
7f722fff3000-7f722fff7000 r-xp 00000000 fd:00 2364155
/usr/lib64/sasl2/liblogin.so.2.0.23
7f722fff7000-7f72301f6000 ---p 00004000 fd:00 2364155
/usr/lib64/sasl2/liblogin.so.2.0.23
7f72301f6000-7f72301f7000 r--p 00003000 fd:00 2364155
/usr/lib64/sasl2/liblogin.so.2.0.23
7f72301f7000-7f72301f8000 rw-p 00004000 fd:00 2364155
/usr/lib64/sasl2/liblogin.so.2.0.23
7f72301f8000-7f7230231000 rw-p 00000000 00:00 0
7f7230231000-7f723023d000 r-xp 00000000 fd:00 1704002
/lib64/libnss_files-2.12.so
7f723023d000-7f723043d000 ---p 0000c000 fd:00 1704002
/lib64/libnss_files-2.12.so
7f723043d000-7f723043e000 r--p 0000c000 fd:00 1704002
/lib64/libnss_files-2.12.so
7f723043e000-7f723043f000 rw-p 0000d000 fd:00 1704002
/lib64/libnss_files-2.12.so
7f723043f000-7f7230445000 rw-p 00000000 00:00 0
7f7230445000-7f7230448000 r-xp 00000000 fd:00 1703972
/lib64/libcom_err.so.2.1
7f7230448000-7f7230647000 ---p 00003000 fd:00 1703972
/lib64/libcom_err.so.2.1
7f7230647000-7f7230648000 r--p 00002000 fd:00 1703972
/lib64/libcom_err.so.2.1
7f7230648000-7f7230649000 rw-p 00003000 fd:00 1703972
/lib64/libcom_err.so.2.1
7f7230649000-7f723064d000 rw-p 00000000 00:00 0
7f723064d000-7f7230656000 r-xp 00000000 fd:00 2371184
/usr/lib64/libltdl.so.7.2.1
7f7230656000-7f7230855000 ---p 00009000 fd:00 2371184
/usr/lib64/libltdl.so.7.2.1
7f7230855000-7f7230856000 rw-p 00008000 fd:00 2371184
/usr/lib64/libltdl.so.7.2.1
7f7230856000-7f7230857000 rw-p 00000000 00:00 0
7f7230857000-7f723085d000 rw-s 00000000 fd:00 3674284
/var/services/openldap/var/openldap-data/__db.001
7f723085d000-7f723085e000 rw-p 00000000 00:00 0
7fffe0384000-7fffe0399000 rw-p 00000000 00:00 0
[stack]
7fffe03f9000-7fffe03fa000 r-xp 00000000 00:00 0
[vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0
[vsyscall]
cmdline
-----
/var/services/openldap/libexec/slapd -h 'ldap://*:389 ldaps://*:636' -f
/var/services/openldap/etc/openldap/slapd.conf
os_release
-----
Red Hat Enterprise Linux Server release 6.2 (Santiago)
environ
-----
REMOTEHOST=10.212.141.90
HOSTNAME=aaaprod-master.uis.georgetown.edu
SELINUX_ROLE_REQUESTED=
HOST=aaaprod-master.uis.georgetown.edu
TERM=vt100
SHELL=/bin/bash
'SSH_CLIENT=10.212.141.90 62167 22'
SELINUX_USE_CURRENT_RANGE=
SSH_TTY=/dev/pts/0
GROUP=wheel
USER=dhm24.a
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.tbz=01;31:*.tbz2=01;31:*.bz=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=01;36:*.au=01;36:*.flac=01;36:*.mid=01;36:*.midi=01;36:*.mka=01;36:*.mp3=01;36:*.mpc=01;36:*.ogg=01;36:*.ra=01;36:*.wav=01;36:*.axa=01;36:*.oga=01;36:*.spx=01;36:*.xspf=01;36:
HOSTTYPE=x86_64-linux
MAIL=/var/spool/mail/dhm24.a
PATH=/opt/ruby-enterprise/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin
PWD=/
LANG=en_US.UTF-8
SELINUX_LEVEL_REQUESTED=
KRB5CCNAME=FILE:/tmp/krb5cc_0.1
SHLVL=4
HOME=/root
OSTYPE=linux
VENDOR=unknown
MACHTYPE=x86_64
LOGNAME=dhm24.a
CVS_RSH=ssh
'SSH_CONNECTION=10.212.141.90 62167 141.161.152.76 22'
'LESSOPEN=|/usr/bin/lesspipe.sh %s'
G_BROKEN_FILENAMES=1
_=/var/services/openldap/libexec/slapd
11 years, 3 months
Memory leak in 2.4.31 w/ hdb and MMR?
by Brandon Hume
I've got my two-node setup up and running, MMR w/ delta-syncrepl.
Node 1 is up and running with ~340k entries in the main DIT. It
consumes about 4G of VM on a Redhat AS6 box, and the data dir is around
2.3G on-disk (including __db.* and the one log.* file...), and another
100M in cn=accesslog.
I'm bringing up node 2 after nuking the data dir, and letting it
syncrepl from nothing. I was tracking a SIGBUS error, but that turned
out to be olcLogLevel=Stats+Sync generating a huge amount of logging and
filling up the disk. Fixed that, moved on.
Now, it's still crashing... but that's because slapd is bloating up
hugely and causing the machine to run out of VM and kill the process.
I've added about 8G of temporary swap, and it's still going. slapd on
node2 is 5.5G resident, and nearly 15G in size total now. On-disk the
hdb is only around 1.6G, so it still has a long ways to go.
Can I assume this is not the way it should be?
vmstat shows a lot of swap-out but almost no swap-in, so it's not
thrashing. pmap shows a large number of 64M "anon" segments. 140 of
those at one point, and 157 when I checked just now.
It looks a lot like a memory leak, though I can't tell offhand whether
the problem is in OpenLDAP (2.4.31) or in BerkeleyDB (5.3.15). When it
finishes, I'm planning on turning off delta-syncrepl and pave/rebuild
again, and see if it behaves the same. I could also give mdb a shot,
but since this is a mirror I'd have to rebuild both sides.
Any suggestions as to where I could start looking for the source of the
problem? Obviously I'm not planning on rebuilding this node on a
regular basis (and certainly not all via syncrepl) but I'm concerned
that over an extended period of time it'll leak memory even during
normal use.
I'm including my DB_CONFIG, just in case. I can supply more of the
config as necessary.
DB_CONFIG:
set_cachesize 0 536870912 0
set_lg_regionmax 10485760
set_lg_max 104857600
set_lg_bsize 26214400
set_lk_max_locks 4096
set_lk_max_objects 4096
set_flags DB_LOG_AUTOREMOVE
(If anything looks particularly stupid in here, even unrelated to the
leak, I'd love the advice...)
11 years, 3 months
Multi Master syncrepl issue
by Neil Mcbennett
Hello,
This is my first post to this list and unfortunately I come here with a
problem. I'm not new to LDAP but I am new to OpenLDAP especially the 2.4
release.
I am trying to get multi master replication working and I've read the
documentation several times. I did wonder if this might be a bug but I
still think it's probably a misunderstanding on my part.
I have 2 servers configured for multi master replcation which I will refer
to as server A and B. If I start both servers I can make changes on server
A which are immediately replicated to server B. However if I then start
making changes to server B I don't see replication back to A. The same
thing happens if I initiate replication from B, then replication to A works
but not the other way around. i.e. replication only works in 1 direction
which is determined by which server I make changes on first. I am using
slapd.conf as I didn't want to complicate matters by introducing online
config. The specific version is 2.4.31. Connectivity between the servers is
working fine - I can perform LDAP operations in both directions.
If someone could take a look at my config I'd much appreciate it.
Thanks
Neil
#slapd.conf Server A (10.5.1.110)
pidfile /usr/local/openldap/var/run/slapd.pid
argsfile /usr/local/openldap/var/run/slapd.args
include /usr/local/openldap/etc/schema/core.schema
include /usr/local/openldap/etc/schema/cosine.schema
include /usr/local/openldap/etc/schema/solaris.schema
include /usr/local/openldap/etc/schema/inetorgperson.schema
include
/usr/local/openldap/etc/schema/DUAConfigProfile.schema
include /usr/local/openldap/etc/schema/sudo.schema
modulepath /usr/local/openldap/libexec
moduleload syncprov.la
access to attrs=userPassword
by self write
by * auth
by dn="cn=ldapclient,ou=profile,dc=example,dc=com" write
access to dn.base=""
by * read
access to *
by self write
by users read
by anonymous read
serverID 1
database hdb
suffix "dc=example,dc=com"
rootdn "cn=Manager,dc=example,dc=com"
rootpw {SSHA}pnqaqMcoMhnDbSRa9WAgDbhBMr/QnUGY
lastmod on
directory /usr/local/openldap/var/openldap-data
index
objectclass,uid,uidNumber,memberUid,entryCSN,entryUUID,automountKey eq
index cn,sn,gn,mail eq,sub
syncrepl rid=001
provider=ldap://10.7.82.3
type=refreshAndPersist
searchbase="dc=example,dc=com"
attrs="*,+"
bindmethod=simple
binddn="cn=manager,dc=example,dc=com"
credentials="secret"
mirrormode TRUE
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
#######################################################
#slapd.conf server B (10.7.82.3)
pidfile /usr/local/openldap/var/run/slapd.pid
argsfile /usr/local/openldap/var/run/slapd.args
include /usr/local/openldap/etc/schema/core.schema
include /usr/local/openldap/etc/schema/cosine.schema
include /usr/local/openldap/etc/schema/solaris.schema
include /usr/local/openldap/etc/schema/inetorgperson.schema
include
/usr/local/openldap/etc/schema/DUAConfigProfile.schema
include /usr/local/openldap/etc/schema/sudo.schema
modulepath /usr/local/openldap/libexec
moduleload syncprov.la
access to attrs=userPassword
by self write
by * auth
by dn="cn=ldapclient,ou=profile,dc=example,dc=com" write
access to dn.base=""
by * read
access to *
by self write
by users read
by anonymous read
serverID 2
database hdb
suffix "dc=example,dc=com"
rootdn "cn=Manager,dc=example,dc=com"
rootpw {SSHA}pnqaqMcoMhnDbSRa9WAgDbhBMr/QnUGY
lastmod on
directory /usr/local/openldap/var/openldap-data
index
objectclass,uid,uidNumber,memberUid,entryCSN,entryUUID,automountKey eq
index cn,sn,gn,mail eq,sub
syncrepl rid=001
provider=ldap://10.5.1.110
type=refreshAndPersist
searchbase="dc=example,dc=com"
attrs="*,+"
bindmethod=simple
binddn="cn=manager,dc=example,dc=com"
credentials="secret"
mirrormode TRUE
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
#######################################################
11 years, 3 months
ACL for nssov-overlay
by Uwe Werler
Hello list,
does someone know how I can define an ACL for the socket used by the nssov-overlay? I tried
by socket.url="/var/run/nslcd/socket" read
but it won't work. Any suggestions?
Thanks in advance!
Regards Uwe
11 years, 4 months
slapd hangs upon performing modification of cn=config
by Patrick Hemmer
I have a database which was working fine, but now whenever I go to
perform any sort of modification on the database, the modification just
hangs. No error, no timeout, just sits there. However while that first
modification is hung, I can perform modifications of another database
(other than cn=config) and they work just fine. I can even do further
searches against cn=config while the modification is still hung.
Also when I run slapd in the foreground, and then send it a SIGINT, it
says "slapd shutdown: waiting for X operations/tasks to finish" and
never ends. I end up having to SIGKILL it.
The database is part of a MMR group of servers I was building, but I
shut down all the other servers to troubleshoot the issue (it makes no
difference whether the other servers are up or down, and they all
exhibit the same problem).
Where should I start looking to figure out whats going on (the specific
operation/task thats hanging)? I can run slapd in debug mode with '-1',
but theres a ton of info, and I dont know whats relevant, or which debug
mode I should use other than '-1'.
Thanks
-Patrick
11 years, 4 months
Anonymous bind allowed when configured not to.
by Kyle Smith
Good Morning,
I was recently made aware of a problem with my OpenLDAP 2.4.26 and
2.4.28 servers.
I have configured each server to disallow anony using the below directive.
### Disable anony
disallow bind_anon
This works great for Softerra Ldap Administrator, and the ldapsearch
command (linux).
$ ldapsearch -x -H ldaps://openldap.example.com -b
"ou=peoples,dc=example,dc=com" "(uid=someuser)"
ldap_bind: Inappropriate authentication (48)
additional info: anonymous bind disallowed
However, when I use Jxplorer (http://jxplorer.org/) it not only allows
the bind, but allows the search. Right now the ACL is set for "by
anonymous read", but shouldn't the disallow directive even prevent the
connection?
I'm working on getting some debug logs, but if any one has experienced
this, please let me know. Thanks.
Kyle Smith
11 years, 4 months
Re: size of bdb database, master vs replica
by Quanah Gibson-Mount
--On Tuesday, May 22, 2012 10:06 AM +0200 Jehan Procaccia
<jehan.procaccia(a)tem-tsp.eu> wrote:
> Le 21/05/2012 18:33, Quanah Gibson-Mount a écrit :
>
> --On Monday, May 21, 2012 3:15 PM +0200 jehan procaccia
> <jehan.procaccia(a)it-sudparis.eu> wrote:
>
>
> ok __dd.xxx files are memory mapped files,
> then which is the file(s) that contains the database ? I suspect
> id2entry.bdb, but why on the master the size in KB is:
> 195412 id2entry.bdb
> and on the slave
> 32 id2entry.bdb
>
>
> It doesn't look to me like your replica is replicating at all. Have you
> done a slapcat of the two and verified they are identical?
>
> --Quanah
>
>
>
> Ok, then I did a slapcat on a replica and to my big surprise, before I
> did the slapcat, bdb files on the replica were very small, then as soon
> as I did the slapcat (while slapd is off), now they are similar in size
> to the master !?
> Do we need to run regularly slapcat on replicas in order to "really"
> replicate ?
>
No. It sounds like you don't have a checkpoint directive set for your
database. You should fix that.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
11 years, 4 months
dn.exact vs dn.base
by Nick Milas
I was wondering whether there is any difference between dn.exact and
dn.base constructs.
For example, theoretically (according to the documentation) we can use
either:
access to dn.base="ou=system,dc=example,dc=com"
by dn.exact="uid=userx,ou=people,dc=example,dc=com" write
or:
access to dn.exact="ou=system,dc=example,dc=com"
by dn.base="uid=userx,ou=people,dc=example,dc=com" write
It seems to me that the two forms are interchangeable (as used, e.g.
here: http://www.openldap.org/faq/data/cache/1140.html)
Can you please clarify?
Thanks,
Nick
11 years, 4 months
Problem with localhost unauthenticated bind
by Tim Watts
Hi,
I'm having a problem with a new LDAP server (slapd 2.4.23-7.2)
I'd like to have root@localhost be able to perform "manage" operations
on the slapd on the localhost *only* - all other ACLs would be pretty
standard.
The machine itself is considered secure.
Ideally, I'd like to do this with a mode(600) Unix Domain Socket owned
by root.
How do you enable an "manage" ACL for the entire DN if and only if the
access comes via the unix socket?
================
On an aside - I've tried unauthenticated localhost access - but cannot
get that to work. This would be less desirable as anyone with ssh access
to the server would be abloe to bypass security - but I'm still curious
to know what I did wrong.
My slapd.d entries are:
cat /etc/ldap/slapd.d/cn\=config.ldif
=======================================================================
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcLogLevel: none
olcPidFile: /var/run/slapd/slapd.pid
olcToolThreads: 1
structuralObjectClass: olcGlobal
entryUUID: 62952116-3777-1031-8e1b-bfeeb6e70114
creatorsName: cn=config
createTimestamp: 20120521095922Z
entryCSN: 20120521095922.839791Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20120521095922Z
olcAllows: bind_anon_cred bind_anon_dn update_anon ### <<< Added this
=======================================================================
cat /etc/ldap/slapd.d/cn\=config/olcDatabase\=\{1\}hdb.ldif
=======================================================================
dn: olcDatabase={1}hdb
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=cch,dc=kcl,dc=ac,dc=uk
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by
anonymous auth by dn="cn=admin,dc=cch,dc=kcl,dc=ac,dc=uk" write by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by peername.regex=127\.0\.0\.1 manage ###<<< Added
olcAccess: {3}to * by self write by
dn="cn=admin,dc=cch,dc=kcl,dc=ac,dc=uk" write by * read
olcLastMod: TRUE
olcRootDN: cn=admin,dc=cch,dc=kcl,dc=ac,dc=uk
olcRootPW:: e1NTSEF9TVFtdlA4Q2FJUjZqOEdpMytlcWd5Zk1BUWFjVmpGM1c=
olcDbCheckpoint: 512 30
olcDbConfig: {0}set_cachesize 0 2097152 0
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbIndex: objectClass eq
structuralObjectClass: olcHdbConfig
entryUUID: 62964ee2-3777-1031-8e25-bfeeb6e70114
creatorsName: cn=admin,cn=config
createTimestamp: 20120521095922Z
entryCSN: 20120521095922.847576Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20120521095922Z
=======================================================================
Sorry this is a bit of a numpty question - I'm learning slapd - in a
hurry(!)
Many thanks in advance :)
Tim
--
Tim Watts
Personal Email
Personal website and blog: http://www.dionic.net/tim/
11 years, 4 months
