openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Bug in deleting entry in MirrorMode?
by Peter Palmreuther 09 Nov '09

09 Nov '09

Hello, I'm writing to this list to clarify if I discovered a bug or just did not configure OpenLDAP properly. I've set up OpenLDAP to run in "MirrorMode": # [...] overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 # [...] syncrepl rid=001 provider=ldap://localhost:11389 type=refreshAndPersist searchbase="o=esolution,dc=deutscherv,dc=de" schemachecking=on bindmethod=simple binddn="cn=MirrorMode,o=esolution,dc=deutscherv,dc=de" credentials="M1rr0rM3" retry="60 +" serverID 1 mirrormode on # [...] The second server is set up identically, except "serverID" is 2 and "provider" is set to URL of first server. The fact addresses are "localhost" is because I replicated my main setup on my private server to better inspect and debug the problem. When adding, modifying and deleting an entry it can happend I do get a positive return from delete, but a subsequent "add" fails with "code=68: Already exists". This does not happen all the time, but often enough to name it "reproducible". This seems not to happen if there's a "sleep" between modify and delete. It also seems not to happen if secondary server is down. So either I've got a configuration problem or there's a problem with synchronization. Anybody here to help, tracking down this problem? Thanks a lot, and -- Regards, Peter

2 1

(ITS#6367) syncprov ... changed by peer, ignored
by olivier.chirossel＠sfr.com 09 Nov '09

09 Nov '09

Full_Name: olivier chirossel Version: 2.4.17 and 2.4.19 OS: linux URL: http://86.64.145.174:8080/ Submission from: (NULL) (62.39.9.251) in refreshend persist mode, the replication is incorrect for an entry which be delete/add after master restart and before the reconnection of the slave. steps to reproduce : 0) two linux server (one for the master, one for the slave) on the master ip : 10.143.73.9 on the slave ip : 10.143.73.71 1) kernel configuration on the slave by default tcp_keepalive_time 7200 on linux and tcp_keepalive_probes 9 put in /etc/sysctl.conf net.ipv4.tcp_keepalive_time = 60 net.ipv4.tcp_keepalive_probes = 2 and sysctl -p 2) master set up on /etc/openldap tar xvf slapd_master.tar (get on the url ) and slapd -F /etc/openldap/slapd.d and ldapadd -h 10.153.73.9 -D "cn=admin, cn=config" -w secret -f first.ldif (get on url) 2) slave set up on /etc/openldap tar xvf slapd_slave.tar (get on the url ) and slapd -F /etc/openldap/slapd.d 2) on the master : add the entry ldapadd -h 10.153.73.9 -D "cn=admin, cn=config" -w secret -f test1init.ldif (get on url) 3) on the master : restart the master and delete/add (with new value) kill `pidof slapd` slapd -F /etc/openldap/slapd.d ldapdelete -h 10.153.73.9 -D "cn=admin, cn=config" -w secret msisdn=6666666660,suffix=0,dc=sfr.com ldapadd -h 10.153.73.9 -D "cn=admin, cn=config" -w secret -f testcreate.ldif (get on url) verify the entry ldapsearch -L -L -L -D "cn=admin, cn=config" -w secret -b " suffix=0,dc=sfr.com" 4) on the slave : see the slave reconnect netstat -an | grep 389 for see the connection between the slave and the master ldapsearch -L -L -L -D "cn=admin, cn=config" -w secret -b " suffix=0,dc=sfr.com" see the logs 5) on the slave after reconnection to the master ldapsearch -L -L -L -D "cn=admin, cn=config" -w secret -b " suffix=0,dc=sfr.com" ( "no entry for dn msisdn=6666666660,suffix=0,dc=sfr.com" ) 6) on the master after reconnection from the slave to the master in the logs syncprov ... changed by peer, ignored

1 0

Re: (ITS#6366) application GUI crashes when openning file by a user created by LDAP
by michael＠stroeder.com 07 Nov '09

07 Nov '09

fuzq(a)anl.gov wrote: > Full_Name: Albert Fu > Version: 2.3.27-8.el5_2.4.i386 > OS: Scientific Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (164.54.208.62) > > > I have a Linux application software with a text editor developed with QT > and C++. Every time when openning a file by a user created by LDAP, the > software crashes with "floating point exception". However, this doesn't > happen to users added to the system by command 'useradd' or 'Users and > Groups' tool of the system. I really doubt that this has something to do with OpenLDAP itself. Regarding the LDAP side you should try to track down whether the user data returned via nss_ldap or similar is complete and correct. Anyway the software should not crash if the user name for a numeric user id cannot be found. Ciao, Michael.

1 0

Re: (ITS#6366) application GUI crashes when openning file by a user created by LDAP
by quanah＠zimbra.com 07 Nov '09

07 Nov '09

--On Friday, November 06, 2009 5:07 PM +0000 fuzq(a)anl.gov wrote: > Full_Name: Albert Fu > Version: 2.3.27-8.el5_2.4.i386 > OS: Scientific Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (164.54.208.62) > > > I have a Linux application software with a text editor developed with QT > and C++. Every time when openning a file by a user created by LDAP, the > software crashes with "floating point exception". However, this doesn't > happen to users added to the system by command 'useradd' or 'Users and > Groups' tool of the system. Aside from the fact that 2.3 is historic, how is it OpenLDAP's bug that an application you wrote crashes? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6366) application GUI crashes when openning file by a user created by LDAP
by fuzq＠anl.gov 06 Nov '09

06 Nov '09

Full_Name: Albert Fu Version: 2.3.27-8.el5_2.4.i386 OS: Scientific Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (164.54.208.62) I have a Linux application software with a text editor developed with QT and C++. Every time when openning a file by a user created by LDAP, the software crashes with "floating point exception". However, this doesn't happen to users added to the system by command 'useradd' or 'Users and Groups' tool of the system. Thanks,

1 0

(ITS#6365) Bad slapcat output when slapd running
by apm＠mutex.dk 06 Nov '09

06 Nov '09

Full_Name: Peter Mogensen Version: 2.4.19 OS: Debian Lenny URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (95.166.36.16) Using openldap 2.4.17 and 2.4.19 linked with libdb4.6 and libdb4.8 in a mirrormode setup: * Load the database with slapadd on server-1, start server-1 The LDIF being loaded is generated with slapcat from a slapd 2.3.30-5+etch2 Running on Debian Etch. I have no reason to suspect that it is not loaded correctly into server1 * Start server-2 and monitor the progress of replication with slapcat, for example: # for ((I=1;I<=20;I++)); do slapcat > out-$I; done * Look at the output: # for ((I=1;I<=20;I++)); do wc -l out-$I; done I would expect the generated files to be strictly increasing in size. However, some times there's a file which is smaller than the previous. In it I see LDIF entries like this: dn: objectClass: top objectClass: NamedObject objectClass: simpleSecurityObject uid: rieke userPassword:: e1NBU0x..... structuralObjectClass: NamedObject entryUUID: e46b680e-e5f5-102b-93c9-79162adc1d46 creatorsName: dc=admin,dc=example,dc=com createTimestamp: 20070823185333Z entryCSN: 20070823185333.000000Z#000002#000#000000 modifiersName: dc=admin,dc=example,dc=com modifyTimestamp: 20070823185333Z ... with an empty DN line. My config is as follows. It has been converted to LDIF and the server is running with a cn=config database: ============================================ #gentlehup on pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel none tool-threads 4 # Modules modulepath /usr/lib/ldap moduleload back_hdb moduleload syncprov # Schemas include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/inetorgperson.schema # Limits disallow bind_anon #idletimeout 120 sizelimit 2000 # TLS/Auth TLSCACertificateFile /etc/ldap/ssl/ca.crt TLSCertificateFile /etc/ldap/ssl/server.crt TLSCertificateKeyFile /etc/ldap/ssl/server.nopass.key TLSCipherSuite "NULL-SHA" # Allow root to configure slapd via ldapi:/// TLSVerifyClient demand authz-regexp "gidNumber=0\\+uidNumber=0,cn=peercred,cn=external,cn=auth" "cn=config" authz-regexp "email=root(a)example.com,cn=config,ou=dev,o=example.com,st=Denmark,c=DK" "cn=config" ##### Mirror mode #### serverID 2 database config limits dn.exact="cn=config" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited syncrepl rid=1 provider=ldaps://server1.example.com:636/ searchbase="cn=config" type=refreshAndPersist retry="60 +" scope=sub schemachecking=on bindmethod=sasl binddn="cn=config" saslmech="EXTERNAL" tls_cert=/etc/ldap/ssl/config.crt tls_key=/etc/ldap/ssl/config.nopass.key tls_cacert=/etc/ldap/ssl/ca.crt tls_cipher_suite="NULL-SHA" syncrepl rid=2 provider=ldaps://server2.example.com:636/ searchbase="cn=config" type=refreshAndPersist retry="60 +" scope=sub schemachecking=on bindmethod=sasl binddn="cn=config" saslmech="EXTERNAL" tls_cert=/etc/ldap/ssl/config.crt tls_key=/etc/ldap/ssl/config.nopass.key tls_cacert=/etc/ldap/ssl/ca.crt tls_cipher_suite="NULL-SHA" overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncprov-reloadhint TRUE mirrormode on ================================================= The database which I slapcat and which is being replicated has been loaded with " ldapadd -YEXTERNAL -H ldapi:/// -f ..." from this LDIF: dn: olcDatabase={1}hdb,cn=config objectClass: olcHdbConfig objectClass: olcDatabaseConfig olcDatabase: hdb olcSuffix: cn=data,dc=example,dc=com olcRootDN: cn=config olcDbDirectory: /var/lib/ldap/cn=data,dc=example,dc=com olcDbMode: 0660 olcDbConfig: set_cachesize 2 0 0 olcDbConfig: set_lg_bsize 2097512 olcDbConfig: set_lg_dir /var/lib/ldap/cn=data,dc=example,dc=com-log olcDbConfig: set_flags DB_LOG_AUTOREMOVE olcDbConfig: set_lk_max_objects 5000 olcDbConfig: set_lk_max_locks 5000 olcDbConfig: set_lk_max_lockers 5000 olcDbCheckpoint: 1024 10 olcDbCachefree: 16 olcDbCachesize: 100000 olcDbIDLcacheSize: 300000 olcDbLinearIndex: TRUE olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbIndex: cn eq,sub olcDbIndex: uid eq olcDbIndex: ou eq olcDbIndex: o eq olcDbIndex: givenName eq,sub olcDbIndex: sn eq,sub olcDbIndex: mail eq,sub olcDbIndex: member eq olcDbIndex: reader eq olcDbIndex: writer eq olcDbIndex: admin eq olcAccess: to dn.base="cn=data,dc=example,dc=com" attrs=userPassword by * auth olcAccess: to dn.base="cn=data,dc=example,dc=com" by dn.base="cn=data,dc=example,dc=com" search olcAccess: to dn.children="cn=data,dc=example,dc=com" by dn.base="cn=data,dc=example,dc=com" write olcSyncRepl: rid=3 provider=ldaps://server1.example.com:636/ searchbase="cn=data,dc=example,dc=com" type=refreshAndPersist retry="60 +" scope=sub schemachecking=on bindmethod=sasl binddn="cn=config" saslmech="EXTERNAL" tls_cert=/etc/ldap/ssl/config.crt tls_key=/etc/ldap/ssl/config.nopass.key tls_cacert=/etc/ldap/ssl/ca.crt tls_cipher_suite="NULL-SHA" olcSyncRepl: rid=4 provider=ldaps://server2.example.com:636/ searchbase="cn=data,dc=example,dc=com" type=refreshAndPersist retry="60 +" scope=sub schemachecking=on bindmethod=sasl binddn="cn=config" saslmech="EXTERNAL" tls_cert=/etc/ldap/ssl/config.crt tls_key=/etc/ldap/ssl/config.nopass.key tls_cacert=/etc/ldap/ssl/ca.crt tls_cipher_suite="NULL-SHA" olcMirrorMode: TRUE olcLimits: dn.base="cn=config" size.soft=unlimited size.hard=unlimited time.soft=unlimited time.hard=unlimited dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpCheckpoint: 100 600 olcSpSessionlog: 100 olcSpReloadHint: TRUE dn: olcOverlay=refint,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcRefintConfig olcOverlay: refint olcRefintAttribute: member

1 0

Re: (ITS#6364) refint needs to have rootdn set
by michael＠stroeder.com 06 Nov '09

06 Nov '09

quanah(a)OpenLDAP.org wrote: > The refint overlay doesn't necessarily work correctly without a rootdn being set > on the database it is applying to. This requirement should be documented in the > man page. I'd argue that slapd should not even start if such a strong requirement of an overlay is not met by configuration. Ciao, Michael.

1 0

(ITS#6364) refint needs to have rootdn set
by quanah＠OpenLDAP.org 05 Nov '09

05 Nov '09

Full_Name: Quanah Gibson-Mount Version: 2.4.19 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) The refint overlay doesn't necessarily work correctly without a rootdn being set on the database it is applying to. This requirement should be documented in the man page. See: http://www.openldap.org/lists/openldap-software/200911/msg00039.html for more info

1 0

(ITS#6363) back-config fails on some modify operations
by rhafer＠suse.de 05 Nov '09

05 Nov '09

Full_Name: Ralf Haferkamp Version: RE24, Head OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.200.105) Example: I have the following entry in cn=config: dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by self none olcRootDN: cn=config olcRootPW: secret olcSecurity: simple_bind=128 Doing this modification: dn: olcDatabase={0}config,cn=config replace: olcAccess olcAccess: to * by * none - delete: olcSecurity olcSecurity: simple_bind=128 fails with: modifying entry "olcDatabase={0}config,cn=config" ldap_modify: Other (e.g., implementation specific) error (80) additional info: <olcAccess> unknown factor slapd logs: Nov 5 14:41:42 devel slapd[29934]: olcAccess: value #0: <olcAccess> unknown factor p��Ŷ Nov 5 14:41:42 devel slapd[29934]: conn=10 op=1 RESULT tag=103 err=80 text=<olcAccess> unknown factor The problem seems to be that ca->argv[] isn't correctly initialized in config_modify_internal. I am working on a fix currently.

1 0

(ITS#6362) slapd 2.4.19 Segmentation fault under load
by alexs＠ulgsm.ru 05 Nov '09

05 Nov '09

Full_Name: Aleksey Version: 2.4.19 OS: Freebsd7.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.93.136.26) Openldap 2.4.19 installed from freebsd ports. All configs in defauls Freebsd 7.2 amd64 Slapd built with the "-g" flag and install with the make install STRIP="" Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. In slapd config added using hdb as backend and indexes. Testing database consist of 1000 users accounts with minimum attributes. On stress test load slapd Segmentation fault in 10-30 sec. #ldd /usr/local/libexec/slapd /usr/local/libexec/slapd: libldap_r-2.4.so.7 => /usr/local/lib/libldap_r-2.4.so.7 (0x80073b000) liblber-2.4.so.7 => /usr/local/lib/liblber-2.4.so.7 (0x800881000) libltdl.so.7 => /usr/local/lib/libltdl.so.7 (0x80098e000) libdb-4.6.so.0 => /usr/local/lib/libdb-4.6.so.0 (0x800a97000) libssl.so.5 => /usr/lib/libssl.so.5 (0x800ccf000) libcrypto.so.5 => /lib/libcrypto.so.5 (0x800e19000) libfetch.so.5 => /usr/lib/libfetch.so.5 (0x8010ab000) libcom_err.so.4 => /usr/lib/libcom_err.so.4 (0x8011b9000) libcrypt.so.4 => /lib/libcrypt.so.4 (0x8012bb000) libwrap.so.5 => /usr/lib/libwrap.so.5 (0x8013d4000) libthr.so.3 => /lib/libthr.so.3 (0x8014dd000) libc.so.7 => /lib/libc.so.7 (0x8015f5000) #gdb /usr/local/libexec/slapd (gdb) run -d 0 Starting program: /usr/local/libexec/slapd -d 0 [New LWP 100311] [New Thread 0x801a020b0 (LWP 100311)] [New Thread 0x801a02880 (LWP 100073)] [New Thread 0x8034040b0 (LWP 100076)] [New Thread 0x803404240 (LWP 100077)] [New Thread 0x8034043d0 (LWP 100078)] [New Thread 0x803404560 (LWP 100116)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x803404560 (LWP 100116)] 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory address 0x7ffffd9f9f38: Bad s. ) at idl.c:511 511 { (gdb) (gdb) (gdb) where #0 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory address 0x7ffffd9f9f38: dress. ) at idl.c:511 #1 0x0000000802d50dc5 in hdb_key_read (be=0x801a853d0, db=0x803519800, txn=0x80352b040, k=0x8069005 70, ids=0x806a00000, saved_cursor=0x0, get_flag=0) at key.c:50 #2 0x0000000802d5363c in equality_candidates (op=0x803521000, rtxn=0x80352b040, ava=0x7ffffda7a4f0, ids=0x806c00000, tmp=0x806a00000) at filterindex.c:788 #3 0x0000000802d51d10 in hdb_filter_candidates (op=0x803521000, rtxn=0x80352b040, f=0x7ffffda7a550, ids=0x806c00000, tmp=0x806a00000, stack=0x806d00000) at filterindex.c:154 #4 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, flist=0x7ffffda7a5 f type=161, ids=0x806b00000, tmp=0x806a00000, save=0x806c00000) at filterindex.c:581 #5 0x0000000802d5229c in hdb_filter_candidates (op=0x803521000, rtxn=0x80352b040, f=0x7ffffda7a530, ids=0x806b00000, tmp=0x806a00000, stack=0x806c00000) at filterindex.c:204 #6 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, flist=0x7ffffda7a5 f type=160, ids=0x7ffffdafa760, tmp=0x806a00000, save=0x806b00000) at filterindex.c:581 #7 0x0000000802d521e4 in hdb_filter_candidates (op=0x803521000, rtxn=0x80352b040, f=0x7ffffda7a570, ids=0x7ffffdafa760, tmp=0x806a00000, stack=0x806b00000) at filterindex.c: #8 0x0000000802d4dca9 in search_candidates (op=0x803521000, rs=0x7ffffdbfab30, e=0x7ffffda7a71 tx n=0x80352b040, ids=0x7ffffdafa760, scopes=0x7ffffda7a760) at search.c:1206 #9 0x0000000802d4befa in hdb_search (op=0x803521000, rs=0x7ffffdbfab30) at search.c:586 #10 0x0000000000439bb5 in fe_op_search (op=0x803521000, rs=0x7ffffdbfab30) at search.c:366 #11 0x0000000000439520 in do_search (op=0x803521000, rs=0x7ffffdbfab30) at search.c:217 #12 0x000000000043613d in connection_operation (ctx=0x7ffffdbfac70, arg_v=0x803521000) at connection .c:1123 #13 0x00000000004366d9 in connection_read_thread (ctx=0x7ffffdbfac70, argv=0x12) at connection.c:125 9 #14 0x0000000800797052 in ldap_int_thread_pool_wrapper () from /usr/local/lib/libldap_r-2.4.so. #15 0x000000080164b4d1 in pthread_getprio () from /lib/libthr.so.3 #16 0x0000000000000000 in ?? () Error accessing memory address 0x7ffffdbfb000: Bad address.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs