openldap-technical

openldap-technical@openldap.org

1 participants
9989 discussions

more on migrating from 2.3 to 2.4
by Bobby Krupczak 27 May '12

27 May '12

Hi! I did my nfs/nis/ldap/smb/dns swap this morning. I'm struggling with getting my ldap server to work as before. slapd is running and answering anonymous queries (like logging in and checking passwords) from other machines. >From the slapd host, I can do an ldapsearch (over ssl) and everything works. I authenticate as rootdn just fine. >From a different host, I cant do an ldapsearch; I receive an "invalid creditionals (49)" error. I have enabled debugging in ldapsearch and dont see anything interesting. The server ssl cert verifies fine. No config has changed on my client. I'm thinking its ssl, ipv6, and client cert related or maybe ACLs? In my slapd.conf file, I've put TLSVerifyClient never Any suggestions? slapd is 2.4.26-7.fc16.x86_64 Yes I know I'm running the fedora package. As soon as I can get the machine up and running as before I will start migrating. Thanks, Bobby

1 0

question on syncprov
by Steve Reveliotty 25 May '12

25 May '12

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

2 4

slapd keeps crashing
by David Massie 25 May '12

25 May '12

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

2 5

Memory leak in 2.4.31 w/ hdb and MMR?
by Brandon Hume 25 May '12

25 May '12

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...)

3 7

Multi Master syncrepl issue
by Neil Mcbennett 25 May '12

25 May '12

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 #######################################################

1 0

ACL for nssov-overlay
by Uwe Werler 24 May '12

24 May '12

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

2 1

slapd hangs upon performing modification of cn=config
by Patrick Hemmer 24 May '12

24 May '12

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

3 7

Anonymous bind allowed when configured not to.
by Kyle Smith 24 May '12

24 May '12

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

2 2

Re: size of bdb database, master vs replica
by Quanah Gibson-Mount 24 May '12

24 May '12

--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

2 2

dn.exact vs dn.base
by Nick Milas 24 May '12

24 May '12

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

3 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical