- openldap-bugs - openldap.org

Re: (ITS#6370) Error converting syncprov-checkpoint option to olcSpCheckpoint attribute
by masarati＠aero.polimi.it 10 Nov '09

10 Nov '09

Fixed in HEAD, servers/slapd/overlays/syncprov.c 1.289 -> 1.290 Please test. The fix should apply smoothly to recent 2.4 releases. Thanks for reporting, p.

1 0

(ITS#6370) Error converting syncprov-checkpoint option to olcSpCheckpoint attribute
by kblaney＠nortel.com 10 Nov '09

10 Nov '09

Full_Name: Kyle Blaney Version: 2.4.15 OS: Redhat Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.11.182.187) In OpenLDAP 2.4.19, values change when converting from the syncprov-checkpoint option in file-based configuration to the olcSpCheckpoint attribute in online configuration. To reproduce: 1. Configure OpenLDAP using file-based slapd.conf configuration that contains the following line: syncprov-checkpoint 100 10 2. Make slapd.d directory. 3. Convert file-based configuration to online configuration using the following command: slapd -f slapd.conf -F slapd.d File-based configuration is converted to the cn=config database, but after conversion the value of the olcSpCheckpoint attribute in the "olcOverlay={1}syncprov,olcDatabase={1}bdb,cn=config entry" is "100 600" when it should be the same as in file-based configuration ("100 10").

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by masarati＠aero.polimi.it 10 Nov '09

10 Nov '09

pitpalme+openldap(a)gmail.com wrote: > Full_Name: Peter Palmreuther > Version: 2.4.19 > OS: FreeBSD 7.2 / Solaris 8 > URL: > Submission from: (NULL) (87.123.91.4) > > > 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 (FreeBSD) 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". Can you check whether the entry actually exist, although in "glue" state? You can do this by searching (e.g. with ldapsearch) as the rootdn, to bypass access checking, and using the manageDSAit control (-MM). p.

1 0

(ITS#6247)
by daniel＠pluta.biz 10 Nov '09

10 Nov '09

Hi, I've uploaded a cleaned up version. It's nearly a complete rewrite of the original contribution. In addition to the previous version which (intentionally) just supported the constant MRA "NOW" the updated version also supports now[+/-]offset calculation and matching. The offset's syntax is "NYears#Nmonths#Ndays#NHours#NMinutes#NSeconds" where '#' separates the different time unit fields and N is the amount of time (offset) for a distinct time unit. N can be a negative or positive value (all none-digits and blanks are ignored, multiple signs are simply aggregated to a single (the first from the left) sign). Thanks to previous normalization before the actual matching the "timedrift effect" (see followup #4 above) isn't present any more, too. The two matching rule's (nowOrEarlier/nowOrLaterMatch) are compatible with any generalizedTime-syntax based attribute. Additionally the module introduces two specialized syntaxes exclusively dedicated to this modules matching rules (intentionally not supporting any kind of generalizedTime[Ordering]Match-ing extensible match). Please have a look at the README, the sample schema definition, and/or the source for further details. The current version can be found here: ftp://ftp.openldap.org/incoming/daniel-pluta-now-091110-1.tgz Any kind of feedback is very welcome. Thanks a lot! Daniel

1 0

(ITS#6369) Get rid of cacertdir_rehash
by FullName＠in-valid.com 10 Nov '09

10 Nov '09

Full_Name: Full Name Version: 2.3.43 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:708:10:10:21c:25ff:fe98:3f0e) It is inconvenient to have to use cacertdir_rehash command to hash the certs. IMO it does not service any purpose. It would be nice if cert could be just dropped to a dir and then openldap sees it.

1 0

(ITS#6368) Bug in deleting entry in MirrorMode
by pitpalme+openldap＠gmail.com 09 Nov '09

09 Nov '09

Full_Name: Peter Palmreuther Version: 2.4.19 OS: FreeBSD 7.2 / Solaris 8 URL: Submission from: (NULL) (87.123.91.4) 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 (FreeBSD) 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.

1 0

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

Re: (ITS#6361) Failed assertion in slapd when running on OpenWRT/glibc
by mike＠flyn.org 05 Nov '09

05 Nov '09

Yes, I have just been able to recreate this in 2.4.19. The line in daemon.c at which the assertion occurs in this version is 994. I have also seen: ldap_write: want=22 error=Broken pipe ... slapd: connection.c:786: connection_closing: Assertion 'c->c_struct_state == SLAP_C_USED' failed One things to note is that, in addition to being on MIPS32, my platform has only 32MB of memory. I also have a swap file that is 64MB.

1 0

slapd 2.4.19 Segmentation fault under load
by alexs＠ulgsm.ru 04 Nov '09

04 Nov '09

Good day. Openldap 2.4.19 installed from freebsd ports. All configs in defauls Freebsd 7.2 amd64 All configs in defauls, added anly indexes and back_end are hdb. Testing database is 1000 users accounts with minimal attributes from standart schemas. Under testing load slapd crash after 10sec of work. ]>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 (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debug symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols d)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no gging symbols found)...[New LWP 100584] (no debugging symbols found)...(no debugging symbols found)...[New Thread 0x8019020b0 (LWP 100584)] (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debug symbols found)...[New Thread 0x801902560 (LWP 100085)] [New Thread 0x8022040b0 (LWP 100113)] [New Thread 0x802204240 (LWP 100128)] [New Thread 0x8022043d0 (LWP 100162)] [New Thread 0x802204560 (LWP 100209)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x802204560 (LWP 100209)] 0x0000000801d96b6e in hdb_idl_fetch_key () from /usr/local/libexec/openldap/back_hdb-2.4.so.7 (gdb) (gdb) (gdb) where #0 0x0000000801d96b6e in hdb_idl_fetch_key () from /usr/local/libexec/openldap/back_hdb-2.4.so.7 #1 0x0000000801d8e449 in hdb_key_read () from /usr/local/libexec/openldap/back_hdb-2.4.so.7 #2 0x0000000801d909f4 in hdb_filter_candidates () from /usr/local/libexec/openldap/back_hdb-2.4.so.7 #3 0x0000000801d91376 in list_candidates () from /usr/local/libexec/openldap/back_hdb-2.4.so.7 #4 0x0000000801d8fa1c in hdb_filter_candidates () from /usr/local/libexec/openldap/back_hdb-2.4.so.7 #5 0x0000000801d91376 in list_candidates () from /usr/local/libexec/openldap/back_hdb-2.4.so.7 #6 0x0000000801d8fd4a in hdb_filter_candidates () from /usr/local/libexec/openldap/back_hdb-2.4.so.7 #7 0x0000000801d8ab36 in hdb_search () from /usr/local/libexec/openldap/back_hdb-2.4.so.7 #8 0x000000000042cda8 in fe_op_search () #9 0x000000000042d519 in do_search () #10 0x000000000042a9ef in connection_closing () #11 0x000000000042b48a in connections_shutdown () #12 0x000000080074b352 in ldap_int_thread_pool_wrapper () from /usr/local/lib/libldap_r-2.4.so.7 #13 0x00000008014e54d1 in pthread_getprio () from /lib/libthr.so.3 #14 0x0000000000000000 in ?? () Error accessing memory address 0x7ffffdbfb000: Bad address. (gdb) I glad to give a more debug, if any body say how to do it. -- Email: alexs(a)ulgsm.ru Email/Jabber: alexs(a)ulgsm.ru

3 5

Re: (ITS#6353) berval->string conversions ignore \0
by h.b.furuseth＠usit.uio.no 04 Nov '09

04 Nov '09

I wrote: > Conversion from a binary blob (struct berval*, BerElement read) > to a char* string typically just grabs bv.bv_val even when the > value may contain embedded '\0's. > > In these cases, correct operation may require that the conversion > fails if bv_len != (bv_val ? strlen(bv_val) : 0). Or if bv_val is > not \0-terminated, to check if memchr(bv_val, '\0', bv_len) == NULL. > > Examples: liblber/decode.c: > ber_get_stringa, ber_get_stringb, ber_get_bitstringa, ber_scanf "aAv" decode.c now rejects embedded NUL bytes in cases where we do not save the length anywhere. However it accepts terminating NUL bytes, which AD can send at least in diagonsticMessage: http://www.openldap.org/lists/openldap-devel/200911/msg00001.html -- Hallvard

1 0

Re: (ITS#6361) Failed assertion in slapd when running on OpenWRT/glibc
by hyc＠symas.com 04 Nov '09

04 Nov '09

mike(a)flyn.org wrote: > Full_Name: W. Michael Petullo > Version: 2.4.16 > OS: OpenWRT/Linux/glibc > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.6.126.162) > > > I am running slapd on OpenWRT/MIPS32/Linux/glibc. I have found that after a > period of running, slapd terminates with: Please try to reproduce this with a current release (2.4.19). > > slapd: daemon.c:983: slapd_set_read: Assertion > ((((&slap_daemon.sd_actives)->__fds_bits)[(((s)) / (8 * sizeof (__fd_mask)))] & > ((__fd_mask) 1 << (((s)) % (8 * sizeof (___fd_mask))))) != 0) failed. > > $ ldd /usr/sbin/slapd > libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2 (0x2aad8000) > liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 (0x2ab20000) > libuuid.so.1 => /usr/lib/libuuid.so.1 (0x2ab3c000) > libdb-4.7.so => /usr/lib/libdb-4.7.so (0x2ab50000) > libresolv.so.2 => /lib/libresolv.so.2 (0x2ac92000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2aca6000) > libc.so.6 => /lib/libc.so.6 (0x2ad3e000) > libpthread.so.0 => /lib/libpthread.so.0 (0x2ae98000) > /lib/ld.so.1 (0x2aaa8000) > > $ slapd -V > @(#) $OpenLDAP: slapd 2.4.16 (Nov 3 2009 08:04:35) $ > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6361) Failed assertion in slapd when running on OpenWRT/glibc
by mike＠flyn.org 04 Nov '09

04 Nov '09

Full_Name: W. Michael Petullo Version: 2.4.16 OS: OpenWRT/Linux/glibc URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.6.126.162) I am running slapd on OpenWRT/MIPS32/Linux/glibc. I have found that after a period of running, slapd terminates with: slapd: daemon.c:983: slapd_set_read: Assertion ((((&slap_daemon.sd_actives)->__fds_bits)[(((s)) / (8 * sizeof (__fd_mask)))] & ((__fd_mask) 1 << (((s)) % (8 * sizeof (___fd_mask))))) != 0) failed. $ ldd /usr/sbin/slapd libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2 (0x2aad8000) liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 (0x2ab20000) libuuid.so.1 => /usr/lib/libuuid.so.1 (0x2ab3c000) libdb-4.7.so => /usr/lib/libdb-4.7.so (0x2ab50000) libresolv.so.2 => /lib/libresolv.so.2 (0x2ac92000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2aca6000) libc.so.6 => /lib/libc.so.6 (0x2ad3e000) libpthread.so.0 => /lib/libpthread.so.0 (0x2ae98000) /lib/ld.so.1 (0x2aaa8000) $ slapd -V @(#) $OpenLDAP: slapd 2.4.16 (Nov 3 2009 08:04:35) $

1 0

(ITS#6360) slapd memory usage grows to consume all available memory
by whm＠stanford.edu 03 Nov '09

03 Nov '09

Full_Name: Bill MacAllister Version: 2.4.19+ OS: Debian 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.165) We are using OpenLDAP 2.4.19 with a patch for ITS6334. We are using libhoard for memory management. The backend database is bdb 4.8. We are seeing slapd memory usage grow until all of the memory on the system is consumed. Our database has a bit over 500,000 dns. The cache values we are using are: cachesize 200000 dncachesize 0 idlcachesize 200000 On a test server with 16 bg of memory, 14.7 consumed by slapd we see: ldapsearch -b cn=monitor + | grep -i cache olmBDBEntryCache: 115 olmBDBDNCache: 519795 olmBDBIDLCache: 60510 I have tried running slapd under valgrind and when the server is shutdown valgrind does not report any memory leaks. It appears that slapd allocates the memory, remembers it has allocated it, and does not use it.

1 0

Re: (ITS#6357) Problem configuring openldap
by quanah＠zimbra.com 02 Nov '09

02 Nov '09

--On Friday, October 30, 2009 11:34 PM +0000 pierre42d(a)9online.fr wrote: I suggest you read the README file shipped with the OpenLDAP release. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5810) $BACKEND selections in make test
by h.b.furuseth＠usit.uio.no 02 Nov '09

02 Nov '09

Maybe it's about time to close this one... Could someone test if NDB likes this acfilter.sh instead of the current one? In the tests where NDB works, anyway. I don't know which ones. The current acfilter depends on awk being GNU awk, which can be wrong even on Linux. Ubuntu has awk = mawk. This variant uses perl instead. back-ldif passes most tests with this acfilter and a few additions of BACKEND2SORT="ldif=e". #! /bin/sh # $OpenLDAP: pkg/ldap/tests/scripts/acfilter.sh,v 1.15 2009/01/21 23:40:44 kurt Exp $ ## This work is part of OpenLDAP Software <http://www.openldap.org/>. ## ## Copyright 1998-2009 The OpenLDAP Foundation. ## All rights reserved. ## ## Redistribution and use in source and binary forms, with or without ## modification, are permitted only as authorized by the OpenLDAP ## Public License. ## ## A copy of this license is available in the file LICENSE in the ## top-level directory of the distribution or, alternatively, at ## <http://www.OpenLDAP.org/license.html>. # Strip LDIF comments, or strip everything when $BACKEND=null. # Optionally sort attrs/entries according to $BACKEND2SORT: # BACKEND2SORT="<backend>=[a][e],<backend>=[a][e],..." says whether # to sort attributes in an entry, and whether to sort entries. # 2+ empty input lines separate each list of entries to be sorted. # This feature needs Perl, otherwise any sorting is just by lines. # Defaults, used when $BACKEND2SORT does not mention $BACKEND acfilter_b2s="ndb=a" case ,$BACKEND2SORT in *,$BACKEND=*) acfilter_b2s=$BACKEND2SORT ;; esac case $BACKEND,$acfilter_b2s in null,*) : ;; *,$BACKEND=[ae]*) if (perl -e 0) 2>/dev/null; then perl -we ' ($end, $sort, @e, @out) = ("", $ARGV[0] =~ /,\Q$ARGV[1]\E=(\w*)/); sub lsort { shift(@_) =~ /[$sort]/o ? sort(@_) : @_; } foreach (<STDIN>, "", "") { if (/^ /s) { $e[-1] .= $_; next; } if (/./m) { push @e, $_ unless /^\#/s; next; } if (!@out) { print $end; $end = ""; } if (@e) { push @out, join "", shift(@e), &lsort("a", splice @e); } else { print join("\n", &lsort("e", splice @out)), $end; } $end = $_; }' ",$acfilter_b2s" "$BACKEND" else grep -v '^#' | sort ; fi ;; *) grep -v '^#' ;; esac

1 0

Re: (ITS#6337) Combining back-relay/slapo-rwm and back-hdb/slapo-accesslog seg faults
by h.b.furuseth＠usit.uio.no 02 Nov '09

02 Nov '09

Committed a new fix for Bind and Extended operations in HEAD. This one has no impact on cases which already worked before this ITS: It just searches for the callback and removes it. Possibly something like the previous fix would actually make back-relay better behaved, but such behavior change and my chatter in previous message should go in a separate ITS if someone investigates it. -- Hallvard

1 0

(ITS#6359) Problem compiling openldap
by pierre42d＠9online.fr 31 Oct '09

31 Oct '09

Full_Name: Pierre Version: 2.4.19 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (79.89.161.74) # make Making all in /tmp/openldap-2.4.19 Entering subdirectory include make[1]: Entering directory `/tmp/openldap-2.4.19/include' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/tmp/openldap-2.4.19/include' Entering subdirectory libraries make[1]: Entering directory `/tmp/openldap-2.4.19/libraries' Making all in /tmp/openldap-2.4.19/libraries Entering subdirectory liblutil make[2]: Entering directory `/tmp/openldap-2.4.19/libraries/liblutil' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/tmp/openldap-2.4.19/libraries/liblutil' Entering subdirectory liblber make[2]: Entering directory `/tmp/openldap-2.4.19/libraries/liblber' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/tmp/openldap-2.4.19/libraries/liblber' Entering subdirectory liblunicode make[2]: Entering directory `/tmp/openldap-2.4.19/libraries/liblunicode' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/tmp/openldap-2.4.19/libraries/liblunicode' Entering subdirectory libldap make[2]: Entering directory `/tmp/openldap-2.4.19/libraries/libldap' /bin/sh ../../libtool --mode=link gcc -s -O3 -march=i686 -L/usr/local/BerkeleyDB.4.6/lib -o apitest apitest.o libldap.la ../../libraries/liblber/liblber.la ../../libraries/liblutil/liblutil.a -lsasl2 -lgnutls -lcrypt -lresolv gcc -s -O3 -march=i686 -o .libs/apitest apitest.o -L/usr/local/BerkeleyDB.4.6/lib ./.libs/libldap.so /tmp/openldap-2.4.19/libraries/liblber/.libs/liblber.so -L/usr/local/lib ../../libraries/liblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a /usr/local/lib/libsasl2.so -ldl /usr/local/lib/libgnutls.so /usr/local/lib/libtasn1.so /usr/local/lib/libgcrypt.so -lnsl -lcap /usr/local/lib/libgpg-error.so -lz -lcrypt -lresolv ./.libs/libldap.so: undefined reference to `gnutls_x509_crt_list_import' ./.libs/libldap.so: undefined reference to `gnutls_certificate_get_x509_cas' ./.libs/libldap.so: undefined reference to `gnutls_cipher_suite_info' collect2: ld returned 1 exit status make[2]: *** [apitest] Error 1 make[2]: Leaving directory `/tmp/openldap-2.4.19/libraries/libldap' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/tmp/openldap-2.4.19/libraries' make: *** [all-common] Error 1

1 0

Re: (ITS#6358) Problem compiling openldap
by pierre42d＠9online.fr 31 Oct '09

31 Oct '09

Problem linked to the use of the --enable-lmpasswd option

1 0

(ITS#6358) Problem compiling openldap
by pierre42d＠9online.fr 31 Oct '09

31 Oct '09

Full_Name: Pierre Version: 2.4.19 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (79.89.161.74) # make Making all in /tmp/openldap-2.4.19 Entering subdirectory include make[1]: Entering directory `/tmp/openldap-2.4.19/include' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/tmp/openldap-2.4.19/include' Entering subdirectory libraries make[1]: Entering directory `/tmp/openldap-2.4.19/libraries' Making all in /tmp/openldap-2.4.19/libraries Entering subdirectory liblutil make[2]: Entering directory `/tmp/openldap-2.4.19/libraries/liblutil' gcc -s -O3 -march=i686 -I../../include -I../../include -I/usr/local/BerkeleyDB.4.6/include -I/usr/local/BerkeleyDB.4.6/include -c -o passwd.o passwd.c passwd.c:820: error: parse error before "des_key" passwd.c: In function `lmPasswd_to_key': passwd.c:822: error: `lmPasswd' undeclared (first use in this function) passwd.c:822: error: (Each undeclared identifier is reported only once passwd.c:822: error: for each function it appears in.) passwd.c:835: error: `key' undeclared (first use in this function) passwd.c: In function `chk_lanman': passwd.c:846: error: `des_key' undeclared (first use in this function) passwd.c:846: error: parse error before "key" passwd.c:847: error: `des_context' undeclared (first use in this function) passwd.c:848: error: `des_data_block' undeclared (first use in this function) passwd.c:866: error: `key' undeclared (first use in this function) passwd.c:867: error: `schedule' undeclared (first use in this function) passwd.c:868: error: `StdText' undeclared (first use in this function) passwd.c:868: error: `PasswordHash1' undeclared (first use in this function) passwd.c:868: error: `DES_ENCRYPT' undeclared (first use in this function) passwd.c:876: error: `PasswordHash2' undeclared (first use in this function) passwd.c: In function `hash_lanman': passwd.c:1142: error: `des_key' undeclared (first use in this function) passwd.c:1142: error: parse error before "key" passwd.c:1143: error: `des_context' undeclared (first use in this function) passwd.c:1144: error: `des_data_block' undeclared (first use in this function) passwd.c:1162: error: `key' undeclared (first use in this function) passwd.c:1163: error: `schedule' undeclared (first use in this function) passwd.c:1164: error: `StdText' undeclared (first use in this function) passwd.c:1164: error: `PasswordHash1' undeclared (first use in this function) passwd.c:1164: error: `DES_ENCRYPT' undeclared (first use in this function) passwd.c:1168: error: `PasswordHash2' undeclared (first use in this function) make[2]: *** [passwd.o] Error 1 make[2]: Leaving directory `/tmp/openldap-2.4.19/libraries/liblutil' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/tmp/openldap-2.4.19/libraries' make: *** [all-common] Error 1

1 0

(ITS#6357) Problem configuring openldap
by pierre42d＠9online.fr 31 Oct '09

31 Oct '09

Full_Name: Pierre Version: 2.4.19 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (79.89.161.74) [...] checking number of arguments of ctime_r... 2 checking number of arguments of gethostbyname_r... 6 checking number of arguments of gethostbyaddr_r... 8 checking db.h usability... no checking db.h presence... no checking for db.h... no configure: error: BDB/HDB: BerkeleyDB not available But I have Berkeley DB installed in its default location...

1 0

Re: ITS#3526 chaining enhancements
by masarati＠aero.polimi.it 30 Oct '09

30 Oct '09

> Looks to me like the mentioned features have been implemented and this ITS > should be closed. OK? Yes, everything seems to be implemented. Note that chained operations only work for a single hop, since back-ldap does not allow to add proxied authz control when already set. Thanks, p.

1 0

Re: (ITS#6324) slapd -d ? emits incorrect value for LDAP_DEBUG_ANY on x86_64
by h.b.furuseth＠usit.uio.no 30 Oct '09

30 Oct '09

That fix caused a lot of overflow warnings about LDAP_DEBUG_ANY. I've updated ldap/include/ldap_log.h, ldap/servers/slapd/bconfig.c with an alternate fix. (The main.c fix stays.) While I was at it, I handled output of ANY as -1 specially, since that is a common input value but other negative numbers are not. -- Hallvard

1 0

(ITS#6356) slapd.conf tcp-buffer gets uninitialized value
by h.b.furuseth＠usit.uio.no 30 Oct '09

30 Oct '09

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard config_tcp_buffer() passes 'idx' uninitialized to tcp_buffer_add_one(). Introduced in rev 1.384 for ITS#6234 (TCP buffer configuration) when !defined(LDAP_TCP_BUFFER_X_ORDERED), then rev 1.388 removed the #ifdef LDAP_TCP_BUFFER_X_ORDERED which could set the value. (Not sure if this needed an ITS -- the code is in 2.4.18/19, but inside #ifdef LDAP_TCP_BUFFER which is #defined if LDAP_DEVEL.)

1 0

(ITS#6355) Uninitialiezed rsa_callback with OpenSSL
by h.b.furuseth＠usit.uio.no 30 Oct '09

30 Oct '09

Full_Name: Hallvard B Furuseth Version: HEAD, 2.4.19 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard libldap/tls_o.c:lso_tmp_rsa_cb() returns an uninitialized value if BN_set_word() fails. Introduced in rev 1.13; openldap 2.4.19. Fixing to return NULL.

1 0

Re: (ITS#6339) ldapsearch -V doesn't exist after version info
by quanah＠zimbra.com 30 Oct '09

30 Oct '09

--On Friday, October 30, 2009 9:44 AM +0100 Pierangelo Masarati <masarati(a)aero.polimi.it> wrote: > quanah(a)zimbra.com wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.19 >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.29.239) >> >> >> Executing ldapsearch -V to get the version information correctly prints >> it, but then proceeds to execute a search. > > Perhaps it's not clearly documented (no "-V" in man page, unclear message > in help) but you need to use -VV to exit after printing version. That's... bizarre. Even slapd doesn't behave that way. Nor any other program comes immediately to mind. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6339) ldapsearch -V doesn't exist after version info
by masarati＠aero.polimi.it 30 Oct '09

30 Oct '09

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.19 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > Executing ldapsearch -V to get the version information correctly prints it, but > then proceeds to execute a search. Perhaps it's not clearly documented (no "-V" in man page, unclear message in help) but you need to use -VV to exit after printing version. p.

1 0

Re: ITS#3526 chaining enhancements
by masarati＠aero.polimi.it 30 Oct '09

30 Oct '09

hyc(a)symas.com wrote: > Looks to me like the mentioned features have been implemented and this ITS > should be closed. OK? Not sure, need to check. p.

1 0

ITS#3526 chaining enhancements
by hyc＠symas.com 30 Oct '09

30 Oct '09

Looks to me like the mentioned features have been implemented and this ITS should be closed. OK? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6346) syncrepl problems with 2.4.19
by hyc＠symas.com 30 Oct '09

30 Oct '09

openldap(a)science-computing.de wrote: > Full_Name: Christoph Herrmann > Version: 2.4.19 > OS: SLES11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.17.244.2) > > > > we did some stress tests to an openldap-2.4.19 test infrastructure. > we are running the tests in a single master environment with 5 slave servers, > all with openldap-2.4.19. All machines are running ntpd and are in sync: Thanks for this report, very helpful. A proposed fix for this is now in CVS HEAD overlays/syncprov.c. Please test and let us know your results, thanks. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6340) What should I do it well?
by quanah＠zimbra.com 29 Oct '09

29 Oct '09

Hello, kbind is obsolete, and has been for quite some time. You should be using SASL/GSSAPI instead. In any case, this question is not a bug report, so it does not belong in the ITS system. I would suggest you use the openldap-technical list if you have further questions about developing applications with the OpenLDAP libraries. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6352) Not all certificates are read if the TLS_CACERTDIR contains broken links
by quanah＠zimbra.com 29 Oct '09

29 Oct '09

--On Tuesday, October 27, 2009 8:30 AM +0000 steffen.gruner(a)basf.com wrote: > Full_Name: Steffen Gruner > Version: 2.3.43 The 2.3 release series is no longer supported. I suggest upgrading to the latest stable release (2.4.19) and trying there. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6352) Not all certificates are read if the TLS_CACERTDIR contains broken links
by hyc＠symas.com 28 Oct '09

28 Oct '09

steffen.gruner(a)basf.com wrote: > Full_Name: Steffen Gruner > Version: 2.3.43 > OS: Gentoo Linux > URL: > Submission from: (NULL) (84.171.177.13) > > > If in the TLS_CACERTDIR (/etc/ssl/certs/ on by box) contains broken symbolic > links the ldapsearch command stops on the first broken link and doesn't use all > the other certificates. This functionality is provided by the OpenSSL library; you should file this bug report with them. In the meantime, now you know yet another reason why we recommend using TLS_CACERT instead of TLS_CACERTDIR. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6354) Regex-based authzTo example in docs, section 15.3.3.1, is incorrect.
by tim＠stoo.org 28 Oct '09

28 Oct '09

Full_Name: Tim Stewart Version: 2.4.x OS: N/A URL: Submission from: (NULL) (65.200.62.8) The OpenLDAP documentation at: http://www.openldap.org/doc/admin24/sasl.html#SASL%20Authentication describes an example of using a regular expression to describe a set of distinguished names as opposed to using an ldap:// URL. The example is authzTo: dn.regex=^uid=[^,]*,dc=example,dc=com$ which will produce a syntax error. Instead, the example should read like authzTo: dn.regex:^uid=[^,]*,dc=example,dc=com$ (the first `=' is replaced with `:') which is accepted by the server.

1 0

(ITS#6353) berval->string conversions ignore \0
by h.b.furuseth＠usit.uio.no 28 Oct '09

28 Oct '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Conversion from a binary blob (struct berval*, BerElement read) to a char* string typically just grabs bv.bv_val even when the value may contain embedded '\0's. In these cases, correct operation may require that the conversion fails if bv_len != (bv_val ? strlen(bv_val) : 0). Or if bv_val is not \0-terminated, to check if memchr(bv_val, '\0', bv_len) == NULL. Examples: liblber/decode.c: ber_get_stringa, ber_get_stringb, ber_get_bitstringa, ber_scanf "aAv" Similarly, a lot of code requires a berval to be \0-terminated, but some also - sometimes unwarranted - also that the first \0 it encounters when walking the value is the terminating \0. For example, libldap/getdn.c has some exported functions that look for \0 without checking bv_len, some which checks bv_len but not a terminating \0, and some which does both. I really don't know which of these functions can expect there is no embedded \0. I think we need to introduce 'typedef struct berval BerString', used to document that bv_len == (bv_val ? strlen(bv_val) : 0) for the particular berval in question (e.g. in a function prototype). And maybe a typedef BerData for the opposite.

1 0

Re: (ITS#6334) hang during ldapmodify
by quanah＠zimbra.com 27 Oct '09

27 Oct '09

--On Tuesday, October 27, 2009 2:57 PM +0000 mkd(a)cs.brown.edu wrote: > One last question... what upstream stable release will include this fix? 2.4.20 will. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6334) hang during ldapmodify
by mkd＠cs.brown.edu 27 Oct '09

27 Oct '09

One last question... what upstream stable release will include this fix? Thanks! Mark Howard Chu wrote: > You're welcome, thanks for your help digging into the problem. >

1 0

(ITS#6352) Not all certificates are read if the TLS_CACERTDIR contains broken links
by steffen.gruner＠basf.com 27 Oct '09

27 Oct '09

Full_Name: Steffen Gruner Version: 2.3.43 OS: Gentoo Linux URL: Submission from: (NULL) (84.171.177.13) If in the TLS_CACERTDIR (/etc/ssl/certs/ on by box) contains broken symbolic links the ldapsearch command stops on the first broken link and doesn't use all the other certificates. Please see this trace: ... open("/lib/libz.so", O_RDONLY) = 4 read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P\24\0\0004\0\0\0\240"..., 512) = 512 fstat64(4, {st_mode=S_IFREG|0755, st_size=69512, ...}) = 0 mmap2(NULL, 71888, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0xb7b39000 mmap2(0xb7b4a000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x10) = 0xb7b4a000 close(4) = 0 munmap(0xb7ecf000, 145583) = 0 open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 4 fstat64(4, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0 poll([{fd=4, events=POLLIN}], 1, 10) = 1 ([{fd=4, revents=POLLIN}]) read(4, "H\323y\354\334WM\262\274<qu\24\37\270\250\375ZI2\177\363\325\344-K\253'\330\241\211\243"..., 32) = 32 close(4) = 0 getuid32() = 1000 time(NULL) = 1256629367 open("/etc/ssl/cert.pem", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/etc/ssl/certs/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 4 fstat64(4, {st_mode=S_IFDIR|0755, st_size=12512, ...}) = 0 fcntl64(4, F_GETFD) = 0x1 (flags FD_CLOEXEC) getdents(4, /* 120 entries */, 4096) = 4064 open("/etc/ssl/certs//.", O_RDONLY|O_LARGEFILE) = 5 fstat64(5, {st_mode=S_IFDIR|0755, st_size=12512, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ef2000 read(5, 0xb7ef2000, 4096) = -1 EISDIR (Is a directory) close(5) = 0 munmap(0xb7ef2000, 4096) = 0 open("/etc/ssl/certs//..", O_RDONLY|O_LARGEFILE) = 5 fstat64(5, {st_mode=S_IFDIR|0755, st_size=152, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ef2000 read(5, 0xb7ef2000, 4096) = -1 EISDIR (Is a directory) close(5) = 0 munmap(0xb7ef2000, 4096) = 0 open("/etc/ssl/certs//d537fba6.0", O_RDONLY|O_LARGEFILE) = 5 fstat64(5, {st_mode=S_IFREG|0644, st_size=1505, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ef2000 read(5, "-----BEGIN CERTIFICATE-----\nMIIEK"..., 4096) = 1505 read(5, ""..., 4096) = 0 close(5) = 0 munmap(0xb7ef2000, 4096) = 0 open("/etc/ssl/certs//DigiNotar_Root_CA.pem", O_RDONLY|O_LARGEFILE) = 5 fstat64(5, {st_mode=S_IFREG|0644, st_size=1980, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ef2000 read(5, "-----BEGIN CERTIFICATE-----\nMIIFi"..., 4096) = 1980 read(5, ""..., 4096) = 0 close(5) = 0 munmap(0xb7ef2000, 4096) = 0 open("/etc/ssl/certs//QuoVadis_Root_Certification_Authority.pem", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) close(4) = 0 write(2, "ldap_bind: Can't contact LDAP ser"..., 42ldap_bind: Can't contact LDAP server (-1) ) = 42 exit_group(1) = ?

1 0

Re: (ITS#6334) hang during ldapmodify
by hyc＠symas.com 27 Oct '09

27 Oct '09

SATOH Fumiyasu wrote: >> Please try with the latest include/ldap_pvt.h (1.113) and libldap/sasl.c >> (1.74) from CVS, thanks. > > http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/sasl.c.diff?r1=1… > > s/errno/err/ ? > Absolutely right, thanks. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6334) hang during ldapmodify
by fumiyas＠osstech.jp 27 Oct '09

27 Oct '09

> Please try with the latest include/ldap_pvt.h (1.113) and libldap/sasl.c > (1.74) from CVS, thanks. http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/sasl.c.diff?r1=1… s/errno/err/ ? -- -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- Personal Home: http://www.SFO.jp/blog/

1 0

Re: (ITS#6334) hang during ldapmodify
by hyc＠symas.com 26 Oct '09

26 Oct '09

Mark Dieterich wrote: > Howard, > >> Please try with the latest include/ldap_pvt.h (1.113) and libldap/sasl.c >> (1.74) from CVS, thanks. > > I couldn't get the 2.4.19 stable release to compile with just these few > changes, so I just pulled the entire CVS HEAD. I'm happy to report that > my test case no longer hangs! It looks like you changed the logic to > catch partial writes and this appears to have fixed the error I was seeing. > > So it looks like my issue and the Stanford issue were linked after all. > > Thanks! You're welcome, thanks for your help digging into the problem. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6334) hang during ldapmodify
by mkd＠cs.brown.edu 26 Oct '09

26 Oct '09

Howard, > Please try with the latest include/ldap_pvt.h (1.113) and libldap/sasl.c > (1.74) from CVS, thanks. I couldn't get the 2.4.19 stable release to compile with just these few changes, so I just pulled the entire CVS HEAD. I'm happy to report that my test case no longer hangs! It looks like you changed the logic to catch partial writes and this appears to have fixed the error I was seeing. So it looks like my issue and the Stanford issue were linked after all. Thanks! Mark

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs