- openldap-bugs - openldap.org

Re: (ITS#5112) memory leak in pcache overlay
by rhafer＠suse.de 29 Aug '07

29 Aug '07

On Wednesday 29 August 2007 17:36, Howard Chu wrote: > rhafer(a)suse.de wrote: > > Full_Name: Ralf Haferkamp > > Version: RE23, HEAD > > > > Valgrind gives me the log pasted below when I abort an ldapsearch command > > (CTRL-C) that is running against a back-ldap database that uses the > > pcache overlay. > > Makes sense. We need to use the cleanup handler and free the saved query > info if op->o_abandon is set. Do you want to code this up? I am still working on that, but checking for op->o_abandon doesn't seem to be enough. E.g. if I abort the ldapsearch while slapd is updating its cache (all entries have been returned, but the final LDAP_RESULT to the client is still missing) a filter_free in the cleanup handler will invalidly free the filter. We somehow need to make sure that the query is only free'd if nothing has been written to the cache database. -- Ralf

1 0

Re: (ITS#5112) memory leak in pcache overlay
by hyc＠symas.com 29 Aug '07

29 Aug '07

rhafer(a)suse.de wrote: > Full_Name: Ralf Haferkamp > Version: RE23, HEAD > Valgrind gives me the log pasted below when I abort an ldapsearch command > (CTRL-C) that is running against a back-ldap database that uses the pcache > overlay. Makes sense. We need to use the cleanup handler and free the saved query info if op->o_abandon is set. Do you want to code this up? > ==20850== 53,092 (35,830 direct, 17,262 indirect) bytes in 883 blocks are > definitely lost in loss record 17 of 18 > ==20850== at 0x4C22AC6: malloc (in > /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) > ==20850== by 0x508A940: ber_memalloc_x (memory.c:226) > ==20850== by 0x4ABEEE: slap_sl_malloc (sl_malloc.c:273) > ==20850== by 0x4487C0: filter_dup (filter.c:801) > ==20850== by 0x5AB151: pcache_op_search (pcache.c:2237) > ==20850== by 0x4C3F41: overlay_op_walk (backover.c:642) > ==20850== by 0x4C41D3: over_op_func (backover.c:704) > ==20850== by 0x4C4269: over_op_search (backover.c:726) > ==20850== by 0x446210: fe_op_search (search.c:369) > ==20850== by 0x445B2E: do_search (search.c:217) > ==20850== by 0x4427DB: connection_operation (connection.c:1145) > ==20850== by 0x442CA6: connection_read_thread (connection.c:1271) > > The database configuration looks like this: > ----------------------------- > database ldap > suffix o=test > uri ldap://xxxxxxxxxxxxxxxxx > readonly on > lastmod off > > overlay pcache > proxycache bdb 100000 1 10000 180 > proxyattrset 0 givenname uid ou o cn sn mail objectclass > > ### > proxytemplate (|(cn=)(mail=)(uid=)) 0 86400 > > directory /var/lib/ldap/pcache > cachesize 10000 > index objectclass,queryid eq > index sn,cn,givenname,uid,mail pres,eq,sub > ----------------------------- > > > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5114) pcache cache results for searches that hit size/timelimit
by rhafer＠suse.de 29 Aug '07

29 Aug '07

Full_Name: Ralf Haferkamp Version: RE23, HEAD OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.180.39) pcache currently cache the results of search that hit server- or clientside size- or timelimits. That means that subsequent search will get the (incomplete) results from the cache. I guess pcache should only cache operations that returned LDAP_SUCCESS.

1 0

(ITS#5113) pcache returns incomplete results
by rhafer＠suse.de 29 Aug '07

29 Aug '07

Full_Name: Ralf Haferkamp Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.180.39) While the results of a query are being cached, slapo-pcache will answer queries that match the same template from the cache that is currently being populated. This means that subsequent queries will get incomplete results until the original query is completely cached. This doesn't happen with current RE23 code.

1 0

(ITS#5112) memory leak in pcache overlay
by rhafer＠suse.de 29 Aug '07

29 Aug '07

Full_Name: Ralf Haferkamp Version: RE23, HEAD OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.180.39) Valgrind gives me the log pasted below when I abort an ldapsearch command (CTRL-C) that is running against a back-ldap database that uses the pcache overlay. ==20850== 53,092 (35,830 direct, 17,262 indirect) bytes in 883 blocks are definitely lost in loss record 17 of 18 ==20850== at 0x4C22AC6: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==20850== by 0x508A940: ber_memalloc_x (memory.c:226) ==20850== by 0x4ABEEE: slap_sl_malloc (sl_malloc.c:273) ==20850== by 0x4487C0: filter_dup (filter.c:801) ==20850== by 0x5AB151: pcache_op_search (pcache.c:2237) ==20850== by 0x4C3F41: overlay_op_walk (backover.c:642) ==20850== by 0x4C41D3: over_op_func (backover.c:704) ==20850== by 0x4C4269: over_op_search (backover.c:726) ==20850== by 0x446210: fe_op_search (search.c:369) ==20850== by 0x445B2E: do_search (search.c:217) ==20850== by 0x4427DB: connection_operation (connection.c:1145) ==20850== by 0x442CA6: connection_read_thread (connection.c:1271) The database configuration looks like this: ----------------------------- database ldap suffix o=test uri ldap://xxxxxxxxxxxxxxxxx readonly on lastmod off overlay pcache proxycache bdb 100000 1 10000 180 proxyattrset 0 givenname uid ou o cn sn mail objectclass ### proxytemplate (|(cn=)(mail=)(uid=)) 0 86400 directory /var/lib/ldap/pcache cachesize 10000 index objectclass,queryid eq index sn,cn,givenname,uid,mail pres,eq,sub -----------------------------

1 0

Re: (ITS#5106) LDAPI problem on amd64
by ando＠sys-net.it 29 Aug '07

29 Aug '07

> I updated to 2.3.38 and the problem seems to have vanished. > Thanks for the hint. Thanks for the prompt feedback. I've closed this ITS. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5106) LDAPI problem on amd64
by svgmuc＠bluebottle.com 29 Aug '07

29 Aug '07

Hi, Quoting Pierangelo Masarati <ando(a)sys-net.it>: > You should be using the latest 2.3 release; there was quite a bit > of > work on ldapi between 2.3.32 and 2.3.38 (ITS#4893 and > other possibly related fixes). Having said this, I don't know if it > will solve your problem, but at least it would make sure it's not > fixed yet. No need to say that things work fine here on > Linux/amd64. I updated to 2.3.38 and the problem seems to have vanished. Thanks for the hint. Best, Sven ---------------------------------------------------------------------- Finally - A spam blocker that actually works. http://www.bluebottle.com/tag/4

1 0

Re: (ITS#5065) out of order ctxcsn from old entryCSN
by ando＠sys-net.it 29 Aug '07

29 Aug '07

> Old entryCSN values imported into the data from another server, can crash > replicas. The ITS reports that this is now fixed in HEAD. I would appreciate if you feedback using a fresh HEAD build, since the CSN syntax is now more thoroughly checked, although it is supposed to allow the old one in input. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

slapd makes very strange troubles in VServer
by Niki Hammler 29 Aug '07

29 Aug '07

Hi, Today I began to move my LDAP-Server to a Linux VServer jail. On the host and on the VServer I run Debian etch 4.0. Installing slapd was no problem (aptitude install slapd). I just copied all configuration and data files from the host which worked perfectly before and copied them 1:1 into the VServer. slapd starts without any warnings. But connecting with a client is not possible, neither inside the VServer nor outside. For security reasons, I just allow access with SSL or TLS-required (the very same file worked greatly on the host!): pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel 0 disallow bind_anon require authc security tls=1 TLSCACertificateFile /etc/ldap/ssl/cacert.crt TLSCertificateFile /etc/ldap/ssl/ldap.crt TLSCertificateKeyFile /etc/ldap/ssl/ldap.key TLSVerifyClient never All key files and database files are accessible by slapd (user=openldap, group=openldap). Connecting to ldap and ldaps works greatly from inside the VServer and also from outside: $ nc 192.168.0.2 ldap ^c $ nc 192.168.0.2 ldaps ^c $ There are no packet filters installed, debugging with tcpdump (local interface) shows the complete TCP traffic and handshake with no errors. The strange error is always the same: The clients do not want to connect, sending SSL stuff is always possible but after that, nothing is received. Let's begin with plain SSL: $ openssl s_client -connect 192.168.0.2:636 -debug CONNECTED(00000003) write to 0x80bee90 [0x80bf4e8] (118 bytes => 118 (0x76)) 0000 - 80 74 01 03 01 00 4b 00-00 00 20 00 00 39 00 00 .t....K... ..9.. 0010 - 38 00 00 35 00 00 16 00-00 13 00 00 0a 07 00 c0 8..5............ 0020 - 00 00 33 00 00 32 00 00-2f 03 00 80 00 00 05 00 ..3..2../....... 0030 - 00 04 01 00 80 00 00 15-00 00 12 00 00 09 06 00 ................ 0040 - 40 00 00 14 00 00 11 00-00 08 00 00 06 04 00 80 @............... 0050 - 00 00 03 02 00 80 f5 5d-10 d2 64 21 24 0c b1 c3 .......]..d!$... 0060 - 92 37 72 7a 4a 9c 09 88-46 b2 f8 39 ef f6 c4 c8 .7rzJ...F..9.... 0070 - 84 74 8e a6 79 e1 .t..y. read from 0x80bee90 [0x80c4a48] (7 bytes => 0 (0x0)) 20500:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188: $ I did lots of tests with many LDAP clients (ldapwhoami, ldapsearch commandline tools, PHP, Softerra LDAP Administrator and Clients in exim4, Courier etc). In this case I show connecting with SSL using ldapwhoami: $ ldapwhoami -x -H ldaps://nobaq.intern.stiftingtal.net -D "uid=nobaq,ou=users,dc=intern,dc=stiftingtal,dc=net" -w secret -v -d 999 ldap_initialize( ldaps://nobaq.intern.stiftingtal.net ) ldap_create ldap_url_parse_ext(ldaps://nobaq.intern.stiftingtal.net) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP nobaq.intern.stiftingtal.net:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.0.2:636 ldap_connect_timeout: fd: 3 tm: -1 async: 0 TLS trace: SSL_connect:before/connect initialization tls_write: want=118, written=118 0000: 80 74 01 03 01 00 4b 00 00 00 20 00 00 39 00 00 .t....K... ..9.. 0010: 38 00 00 35 00 00 16 00 00 13 00 00 0a 07 00 c0 8..5............ 0020: 00 00 33 00 00 32 00 00 2f 03 00 80 00 00 05 00 ..3..2../....... 0030: 00 04 01 00 80 00 00 15 00 00 12 00 00 09 06 00 ................ 0040: 40 00 00 14 00 00 11 00 00 08 00 00 06 04 00 80 @............... 0050: 00 00 03 02 00 80 20 25 c9 bb fe 68 e8 52 6c 87 ...... %...h.Rl. 0060: 04 ae 25 d1 8b f5 73 c8 3d ca 73 ab e3 92 3f 9f ..%...s.=.s...?. 0070: c9 9d 79 4e aa fb ..yN.. TLS trace: SSL_connect:SSLv2/v3 write client hello A tls_read: want=7, got=0 TLS: can't connect. ldap_perror ldap_start_tls: Can't contact LDAP server (-1) $ As you can see, reading fails. And now using a normal connection but with TLS: ldapwhoami -x -H ldap://192.168.0.2 -D "uid=nobaq,ou=users,dc=intern,dc=stiftingtal,dc=net" -w secret -v -d 999 -ZZ ldap_initialize( ldap://192.168.0.2 ) ldap_create ldap_url_parse_ext(ldap://192.168.0.2) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP 192.168.0.2:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.0.2:389 ldap_connect_timeout: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush: 31 bytes to sd 3 0000: 30 1d 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 0....w...1.3.6.1 0010: 2e 34 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .4.1.1466.20037 ldap_write: want=31, written=31 0000: 30 1d 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 0....w...1.3.6.1 0010: 2e 34 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .4.1.1466.20037 ldap_result ld 0x8051088 msgid 1 ldap_chkResponseList ld 0x8051088 msgid 1 all 1 ldap_chkResponseList returns ld 0x8051088 NULL wait4msg ld 0x8051088 msgid 1 (infinite timeout) wait4msg continue ld 0x8051088 msgid 1 all 1 ** ld 0x8051088 Connections: * host: 192.168.0.2 port: 389 (default) refcnt: 2 status: Connected last used: Wed Aug 29 00:04:19 2007 ** ld 0x8051088 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ** ld 0x8051088 Response Queue: Empty ldap_chkResponseList ld 0x8051088 msgid 1 all 1 ldap_chkResponseList returns ld 0x8051088 NULL ldap_int_select read1msg: ld 0x8051088 msgid 1 all 1 ber_get_next ldap_read: want=8, got=8 0000: 30 0c 02 01 01 78 07 0a 0....x.. ldap_read: want=6, got=6 0000: 01 00 04 00 04 00 ...... ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x8051088 msgid 1 message type extended-result ber_scanf fmt ({eaa) ber: read1msg: ld 0x8051088 0 new referrals read1msg: mark request completed, ld 0x8051088 msgid 1 request done: ld 0x8051088 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_extended_result ber_scanf fmt ({eaa) ber: ldap_parse_result ber_scanf fmt ({iaa) ber: ber_scanf fmt (}) ber: ldap_msgfree TLS trace: SSL_connect:before/connect initialization tls_write: want=118, written=118 0000: 80 74 01 03 01 00 4b 00 00 00 20 00 00 39 00 00 .t....K... ..9.. 0010: 38 00 00 35 00 00 16 00 00 13 00 00 0a 07 00 c0 8..5............ 0020: 00 00 33 00 00 32 00 00 2f 03 00 80 00 00 05 00 ..3..2../....... 0030: 00 04 01 00 80 00 00 15 00 00 12 00 00 09 06 00 ................ 0040: 40 00 00 14 00 00 11 00 00 08 00 00 06 04 00 80 @............... 0050: 00 00 03 02 00 80 83 33 38 7c c9 0a f9 0b 42 67 .......38|....Bg 0060: 76 97 03 8b e3 47 55 fe 74 ed 86 08 83 fe ed 88 v....GU.t....... 0070: 0e 40 53 97 e5 3e .@S..> TLS trace: SSL_connect:SSLv2/v3 write client hello A tls_read: want=7, got=0 TLS: can't connect. ldap_perror ldap_start_tls: Connect error (-11) $ Connecting without the '-ZZ' seems to work, I get the "confidentiality required" message: $ ldapwhoami -x -H ldap://192.168.0.2 -D "uid=nobaq,ou=users,dc=intern,dc=stiftingtal,dc=net" -w secret -v ldap_initialize( ldap://192.168.0.2 ) ldap_bind: Confidentiality required (13) additional info: TLS confidentiality required $ So I guess the problem is SSL. As said, all SSL files are accessible and there are no errors in the logs or when starting slapd with '-d'. The certificates CN is exactly the hostname. I'm very frustrated because I can't find any errors. I repeat: the very same configuration worked perfectly on the host system. Is this a bug? Thank you very much in advance for any advice, Niki

2 6

(ITS#5111) The '-W' client tool option seems to be reserved by POSIX.2
by ando＠sys-net.it 28 Aug '07

28 Aug '07

Full_Name: Pierangelo Masarati Version: all ever since OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando It seems to be reserved for getopt(3) extensions. I noticed this recently, and I couldn't find any mention of it in the mailing lists/ITS. I don't think it worth fixing, since it's always been there. Just note it somewhere. p.

1 0

Re: ldap_int_global_options not initialized (ITS#5109)
by ando＠sys-net.it 28 Aug '07

28 Aug '07

damien.doiselet(a)neolane.com wrote: > My application is multithread. :) > I've had a call to ldap_get_option(NULL, LDAP_OPT_API_INFO, &ldapi) > before spawning threads, but here the crash occurred also in > ldap_initailize but in ldap_ld_free(). The above sentence is not clear to me; what does the trace below refer to? Your original application, or the one that calls ldap_get_option before spawning threads? What does ldap_ld_free() have to do with this? It never occurs in the trace below. > I addition, I won't call ldap outside my thread. Doesn't matter. Global options are global, so multiple threads may find it uninit'ed, and try to concurrently initialize it. > The full stack trace is : > #0 0xb7e93473 in strlen () from /lib/tls/i686/cmov/libc.so.6 > #1 0xb3a191f9 in ber_strdup_x (s=0x6a626f28 <Address 0x6a626f28 out of > bounds>, ctx=0x0) at memory.c:640 > #2 0xadd2fd66 in ldap_charray_dup (a=0xb313a324) at charray.c:164 > #3 0xadd26883 in ldap_url_dup (ludp=0x8b83798) at url.c:1191 > #4 0xadd26912 in ldap_url_duplist (ludlist=0x8b83798) at url.c:1217 > #5 0xadd11b34 in ldap_create (ldp=0xb32e0dc8) at open.c:149 > #6 0xadd11de1 in ldap_initialize (ldp=0xb32e0ec0, url=0x8946d20 > "ldap://ldap:389") at open.c:225 Please make sure you're calling the desired library objects (libldap & liblber). Can you post the result of ldd for your application? > I have same thing with the 2.3.38 Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: ldap_int_global_options not initialized (ITS#5109)
by quanah＠zimbra.com 28 Aug '07

28 Aug '07

--On Tuesday, August 28, 2007 3:58 PM +0000 damien.doiselet(a)neolane.com wrote: > Thanks > > My application is multithread. > I've had a call to ldap_get_option(NULL, LDAP_OPT_API_INFO, &ldapi) > before spawning threads, but here the crash occurred also in > ldap_initailize but in ldap_ld_free(). > I addition, I won't call ldap outside my thread. Be careful of the LDAP libraries on debian. If they get loaded, you are in trouble, since they are hacked to touch Gnu TLS, and you'll get all sorts of fun. This all gets resolved once OpenLDAP 2.4 is released. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5110) back-ldap, proxy authentication fails when chasing referrals
by f.huiskens＠science-computing.de 28 Aug '07

28 Aug '07

Full_Name: Florian Huiskens Version: 2.3.30 OS: Ubuntu 7.04 URL: Submission from: (NULL) (85.216.39.101) I try to set up an environment, where a client communicates with an LDAP-Proxy. The Proxy forwards the client's query (using the ldap-backend) to an LDAP-Slave. The authentication mechanism I use (proxy - slave) is SASL (GSSAPI). The proxy has a kerberos ticket available. Proxy Authentication works in general (using PROXAUTHZ), but fails on referrals (though rebind-as-user is set). This means that if information is written and the proxy receives a referral to the master, the bind-informations gets lost. Thanks for any help, regards Florian Config-files: Master: include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel 0 # Where the dynamically loaded modules are stored modulepath /usr/lib/ldap moduleload back_bdb moduleload syncprov # The maximum number of entries that is returned for a search operation sizelimit 500 # The tool-threads parameter sets the actual amount of cpu's that is used # for indexing. tool-threads 1 backend bdb checkpoint 512 30 ####################################################################### # Specific Directives for database #1, of type bdb: # Database specific directives apply to this databasse until another # 'database' directive occurs database bdb suffix "dc=idm,dc=local" # rootdn directive for specifying a superuser on the database. This is needed # for syncrepl. rootdn "dc=idm,dc=local" directory "/var/lib/ldap" dbconfig set_cachesize 0 2097152 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 index objectClass eq # Save the time that the entry gets modified, for database #1 lastmod on access to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=idm,dc=local" write by dn="uid=ldap/extubuntu.idm.local,ou=slaves,dc=idm,dc=local" read by anonymous auth by * none access to dn.base="" by * read access to * by dn="cn=admin,dc=idm,dc=local" write by * read # syncrepl config overlay syncprov syncprov-checkpoint 100 1 syncprov-sessionlog 100 # SASL setup #sasl-host ubuntu-desktop sasl-authz-policy To sasl-secprops minssf=56 sasl-realm idm.local sasl-regexp uid=(.*),cn=idm.local,cn=gssapi,cn=auth ldap:///dc=idm,dc=local??sub?(|(uid=$1)(cn=$1)) Slave: include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel 0 modulepath /usr/lib/ldap moduleload back_bdb sizelimit 500 tool-threads 1 backend bdb checkpoint 512 30 database bdb suffix "dc=idm,dc=local" #rootdn "dc=idm,dc=local" rootdn "dc=nowhere,dc=nouniverse" directory "/var/lib/ldap" dbconfig set_cachesize 0 2097152 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 index objectClass eq lastmod on access to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=idm,dc=local" write by anonymous auth by self write by * none # by dn="cn=repl-admin,dc=idm,dc=local" write access to dn.base="" by * read access to * by dn="cn=admin,dc=idm,dc=local" write by self write by * read # by dn="cn=repl-admin,dc=idm,dc=local" write # by * read syncrepl rid=1 provider=ldap://ubuntu-desktop:389 searchbase="dc=idm,dc=local" type=refreshAndPersist retry="60 10 300 +" bindmethod=sasl saslmethod=GSSAPI updateref ldap://ubuntu-desktop:389 # SASL setup sasl-authz-policy To sasl-secprops minssf=56 sasl-realm idm.local sasl-regexp uid=(.*),cn=idm.local,cn=gssapi,cn=auth ldap:///dc=idm,dc=local??sub?(|(uid=$1)(cn=$1)) Proxy (running on the same host as the Slave): include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel 1 modulepath /usr/lib/ldap moduleload back_ldap database ldap uri ldap://extubuntu.idm.local:390/ suffix "dc=idm,dc=local" chase-referrals yes rebind-as-user yes # SASL setup sasl-secprops minssf=56 sasl-realm idm.local sasl-regexp uid=(.*),cn=idm.local,cn=gssapi,cn=auth ldap:///dc=idm,dc=local??sub?(|(uid=$1)(cn=$1)) idassert-bind bindmethod=sasl mode=self authcid=ldap/extubuntu.idm.local # should come from ticket but does not. Snippets of an ldapsearch: debugging information from the proxy conn=10 fd=9 ACCEPT from IP=127.0.0.1:3380 (IP=0.0.0.0:389) conn=10 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" conn=10 op=0 SRCH attr=supportedSASLMechanisms conn=10 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=10 op=1 BIND dn="" method=163 conn=10 op=2 BIND dn="" method=163 conn=10 op=2 RESULT tag=97 err=14 text= conn=10 op=3 BIND dn="" method=163 conn=10 op=1 RESULT tag=97 err=14 text= request done: ld 0x81dd960 msgid 3 SASL [conn=10] Error: unable to open Berkeley db /etc/sasldb2: No such file or directory conn=10 op=3 BIND authcid="admin(a)idm.local" authzid="admin(a)idm.local" conn=10 op=3 BIND dn="cn=admin,dc=idm,dc=local" mech=GSSAPI ssf=56 conn=10 op=3 RESULT tag=97 err=0 text= conn=10 op=4 SRCH base="dc=idm,dc=local" scope=2 deref=0 filter="(cn=fhuisk)" request done: ld 0x8197038 msgid 1 request done: ld 0x8197038 msgid 2 request done: ld 0x8197038 msgid 3 request done: ld 0x8197038 msgid 4 request done: ld 0x8197038 msgid 5 conn=10 op=4 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=10 op=5 UNBIND conn=10 fd=9 closed debugging information from the slave conn=0 op=2 SRCH base="dc=idm,dc=local" scope=2 deref=0 filter="(|(uid=admin)(cn=admin))" conn=0 op=2 SRCH attr=1.1 <= bdb_equality_candidates: (uid) index_param failed (18) <= bdb_equality_candidates: (cn) index_param failed (18) conn=0 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=2 fd=16 ACCEPT from IP=127.0.1.1:2814 (IP=0.0.0.0:390) conn=2 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" conn=2 op=0 SRCH attr=supportedSASLMechanisms conn=2 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=2 op=1 BIND dn="" method=163 conn=2 op=2 BIND dn="" method=163 conn=2 op=2 RESULT tag=97 err=14 text= conn=2 op=3 BIND dn="" method=163 <= bdb_equality_candidates: (uid) index_param failed (18) <= bdb_equality_candidates: (cn) index_param failed (18) SASL [conn=2] Error: unable to open Berkeley db /etc/sasldb2: No such file or directory conn=2 op=3 BIND authcid="ldap/extubuntu.idm.local(a)idm.local" authzid="ldap/extubuntu.idm.local(a)idm.local" conn=2 op=3 BIND dn="uid=ldap/extubuntu.idm.local,ou=slaves,dc=idm,dc=local" mech=GSSAPI ssf=56 conn=2 op=3 RESULT tag=97 err=0 text= conn=2 op=4 PROXYAUTHZ dn="cn=admin,dc=idm,dc=local" conn=2 op=4 SRCH base="dc=idm,dc=local" scope=2 deref=0 filter="(cn=fhuisk)" <= bdb_equality_candidates: (cn) index_param failed (18) conn=2 op=4 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=2 op=1 RESULT tag=97 err=14 text= conn=2 op=5 UNBIND conn=2 fd=16 closed ldapsearch call and result root@extUbuntu:/etc/ldap# ldapsearch cn=fhuisk SASL/GSSAPI authentication started SASL username: admin(a)IDM.LOCAL SASL SSF: 56 SASL installing layers # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: cn=fhuisk # requesting: ALL # # fhuisk, users, idm.local dn: cn=fhuisk,ou=users,dc=idm,dc=local uid: fhuisk givenName:: RmxvcmlhbiA= objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson sn: Huiskens cn: fhuisk userPassword:: dGVzdA== # search result search: 5 result: 0 Success # numResponses: 2 # numEntries: 1 root@extUbuntu:/etc/ldap# fyi: ldapwhoami root@extUbuntu:/etc/ldap# ldapwhoami SASL/GSSAPI authentication started SASL username: admin(a)IDM.LOCAL SASL SSF: 56 SASL installing layers dn:cn=admin,dc=idm,dc=local Result: Success (0) root@extUbuntu:/etc/ldap# Snippets of an ldapmodify debugging information from the proxy conn=0 fd=9 ACCEPT from IP=127.0.0.1:3145 (IP=0.0.0.0:389) conn=0 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" conn=0 op=0 SRCH attr=supportedSASLMechanisms conn=0 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=0 op=1 BIND dn="" method=163 conn=0 op=2 BIND dn="" method=163 conn=0 op=2 RESULT tag=97 err=14 text= conn=0 op=3 BIND dn="" method=163 request done: ld 0x81a39f8 msgid 1 conn=0 op=1 RESULT tag=97 err=14 text= request done: ld 0x81a39f8 msgid 2 SASL [conn=0] Error: unable to open Berkeley db /etc/sasldb2: No such file or directory conn=0 op=3 BIND authcid="admin(a)idm.local" authzid="admin(a)idm.local" conn=0 op=3 BIND dn="cn=admin,dc=idm,dc=local" mech=GSSAPI ssf=56 conn=0 op=3 RESULT tag=97 err=0 text= conn=0 op=4 MOD dn="cn=fhuisk,ou=users,dc=idm,dc=local" conn=0 op=4 MOD attr=cn request done: ld 0x8192200 msgid 1 request done: ld 0x8192200 msgid 2 request done: ld 0x8192200 msgid 3 request done: ld 0x8192200 msgid 4 request done: ld 0x8192200 msgid 7 request done: ld 0x8192200 msgid 5 conn=0 op=4 RESULT tag=103 err=47 text=anonymous proxyAuthz not allowed conn=0 op=5 UNBIND conn=0 fd=9 closed debugging information from the slave conn=0 fd=13 ACCEPT from IP=127.0.1.1:2862 (IP=0.0.0.0:390) conn=0 op=0 BIND dn="" method=128 conn=0 op=0 RESULT tag=97 err=0 text= conn=0 op=1 SRCH base="dc=idm,dc=local" scope=2 deref=0 filter="(|(uid=admin)(cn=admin))" conn=0 op=1 SRCH attr=1.1 <= bdb_equality_candidates: (uid) index_param failed (18) <= bdb_equality_candidates: (cn) index_param failed (18) conn=0 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=1 fd=15 ACCEPT from IP=127.0.1.1:2863 (IP=0.0.0.0:390) conn=1 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" conn=1 op=0 SRCH attr=supportedSASLMechanisms conn=1 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=1 op=1 BIND dn="" method=163 conn=1 op=2 BIND dn="" method=163 conn=1 op=3 BIND dn="" method=163 <= bdb_equality_candidates: (uid) index_param failed (18) <= bdb_equality_candidates: (cn) index_param failed (18) SASL [conn=1] Error: unable to open Berkeley db /etc/sasldb2: No such file or directory conn=1 op=3 BIND authcid="ldap/extubuntu.idm.local(a)idm.local" authzid="ldap/extubuntu.idm.local(a)idm.local" conn=1 op=3 BIND dn="uid=ldap/extubuntu.idm.local,ou=slaves,dc=idm,dc=local" mech=GSSAPI ssf=56 conn=1 op=2 RESULT tag=97 err=14 text= conn=1 op=4 PROXYAUTHZ dn="cn=admin,dc=idm,dc=local" conn=1 op=4 MOD dn="cn=fhuisk,ou=users,dc=idm,dc=local" conn=1 op=4 MOD attr=cn conn=1 op=4 RESULT tag=103 err=10 text= conn=1 op=3 RESULT tag=97 err=0 text= conn=1 op=1 RESULT tag=97 err=14 text= conn=1 op=5 UNBIND conn=1 fd=15 closed debugging information from the master conn=1 fd=14 ACCEPT from IP=172.16.82.240:1290 (IP=0.0.0.0:389) conn=1 op=0 BIND dn="" method=128 conn=1 op=0 RESULT tag=97 err=0 text= conn=1 op=1 RESULT tag=103 err=47 text=anonymous proxyAuthz not allowed do_modify: get_ctrls failed conn=1 op=2 UNBIND conn=1 fd=14 closed ldapmodify call and result root@extUbuntu:/etc/ldap# ldapmodify SASL/GSSAPI authentication started SASL username: admin(a)IDM.LOCAL SASL SSF: 56 SASL installing layers dn: cn=fhuisk,ou=users,dc=idm,dc=local changetype: modify add: cn cn: newCN - modifying entry "cn=fhuisk,ou=users,dc=idm,dc=local" ldapmodify: Proxy Authorization Failure (47) additional info: anonymous proxyAuthz not allowed root@extUbuntu:/etc/ldap#

1 0

Re: ldap_int_global_options not initialized (ITS#5109)
by damien.doiselet＠neolane.com 28 Aug '07

28 Aug '07

Thanks My application is multithread. I've had a call to ldap_get_option(NULL, LDAP_OPT_API_INFO, &ldapi) before spawning threads, but here the crash occurred also in ldap_initailize but in ldap_ld_free(). I addition, I won't call ldap outside my thread. The full stack trace is : #0 0xb7e93473 in strlen () from /lib/tls/i686/cmov/libc.so.6 #1 0xb3a191f9 in ber_strdup_x (s=0x6a626f28 <Address 0x6a626f28 out of bounds>, ctx=0x0) at memory.c:640 #2 0xadd2fd66 in ldap_charray_dup (a=0xb313a324) at charray.c:164 #3 0xadd26883 in ldap_url_dup (ludp=0x8b83798) at url.c:1191 #4 0xadd26912 in ldap_url_duplist (ludlist=0x8b83798) at url.c:1217 #5 0xadd11b34 in ldap_create (ldp=0xb32e0dc8) at open.c:149 #6 0xadd11de1 in ldap_initialize (ldp=0xb32e0ec0, url=0x8946d20 "ldap://ldap:389") at open.c:225 I have same thing with the 2.3.38 Damien Doiselet Pierangelo Masarati a écrit : > Only issues occurring with either the latest release (now 2.3.28) or HEAD code > ought to be considered, as they might be related to already known and perhaps > solved problems. Please check with a fresh build from 2.3.28. > > In the meanwhile, it might be worth checking: > > - is your application multithread? > > - in case it is, is the first call to a libldap routine occurring __before__ > starting multiple threads, or after? If after, then fix your project by adding > a call to an LDAP routine (e.g. ldap_set_option() with an option that does not > require a LDAP* handle) __before__ spawning threads. > > - can you test your development using a libldap library containing debug > symbols, in order to provide helpful information? > > p. >

1 0

Re: Does libldap.so.2 still exist in the latest version of open-ldap,and if not, what could other applications link to instead?
by Gavin Henry 28 Aug '07

28 Aug '07

<quote who="Oliver de Peyer"> > Well, put it this way, it's not a bug with OpenLDAP but it > is a bug with PINE. This seemed like the most appropriate > list to post to though since maybe an OpenLDAP user could > suggest a workaround. Ok, but we don't provide support for 3rd Party software integration with OpenLDAP and refer users to the appropriate mailing lists. > Most people would be used to installing Linux applications > just using .rpms and will be flummoxed by dependency > problems, especially if they are home users. The problem is > that PINE needs a library, libldap.so.2, that the more > recent versions of OpenLDAP no longer supplies. If there is > any easy workaround that the OpenLDAP community can suggest > as a workaround, then PINE users would be very grateful. The work around would be to get upstream to update there lib dependancies. > But to be absolutely clear, yes, it's definitely PINE's bug > not OpenLDAP's! Of course! ;-) But please, seek help on their lists, there's nothing more we can do to help, as it's not a bug with our software. > > In answer to your second suggestion, yes, if you know what > you're doing it is quite easily to compile from the PINE > source and omit OpenLDAP - you can put NOLDAP as a suffix > on the relevant build command. That's what I did in the > end. Understood. > This doesn't help people who are used to just using .rpms > though and it doesn't help people who actually want to use > OpenLDAP with PINE. Well, we distribute in source, so we don't provide RPMs. RPMs are supplied for convience by distros, as you know. > > I would have posted this to PINE lists as you suggest, but > as far as I could make out they don't have email lists per > se but only newsgroups. And one of the things I wanted to > use PINE was to post to newsgroups... but I couldn't get > PINE to work... All things are pointing towards not using PINE then ;-) > I'll post to their newsgroup from my PC at work, but in the > meantime, if anybody on this list has any ideas about > solving this problem from and OpenLDAP perspective, then > I'd be very grateful. They look pretty active to me: http://www.washington.edu/pine/pine-info/ http://mailman1.u.washington.edu/pipermail/pine-info/ http://marc.info/?l=pine-info&w=2&r=1&s=libldap&q=b Gavin.

1 0

(ITS#5109) ldap_int_global_options not initialized
by damien.doiselet＠neolane.com 28 Aug '07

28 Aug '07

Full_Name: Damien Doiselet Version: 2.3.30 OS: Debian 4 (kernel 2.6.20.7) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.243.24.157) I'm developing an application which use openldap. I load the library at the runtime with function GetProcAddress My application work correctly except on one PC. This PC is a Debian 4.0 with a kernel 2.6.20.7. Ldap library is a 2.3.30. The library crash, and so my code too in ldap_initialize() (first call of a ldap function): #0 0xb7eab3a3 in strlen () from /lib/tls/i686/cmov/libc.so.6 #1 0xb3a2d1f9 in ber_strdup_x (s=0x6a626f28 <Address 0x6a626f28 out of bounds>, ctx=0x0) at memory.c:640 #2 0xaddcbdf6 in ldap_charray_dup () from /usr/lib/libldap-2.3.so.0 #3 0xaddc2773 in ldap_url_dup () from /usr/lib/libldap-2.3.so.0 #4 0xaddc2802 in ldap_url_duplist () from /usr/lib/libldap-2.3.so.0 #5 0xaddab4dc in ldap_create () from /usr/lib/libldap-2.3.so.0 #6 0xaddab7d1 in ldap_initialize () from /usr/lib/libldap-2.3.so.0 While I was debugging, ldap_int_global_options was not initialized. Nevertheless, with -lldap compilation with gcc, there is no problem.

1 0

Does libldap.so.2 still exist in the latest version of open-ldap, and if not, what could other applications link to instead?
by Oliver de Peyer 27 Aug '07

27 Aug '07

I am trying to install PINE on Fedora 7 (and hey, why not? It's good enough as a command line email program) So, I get hold of Pine-4.64-1-i386.rpm from the UW website. But when I try to install this with rpm, it told me I was missing various dependencies. I managed to download these one by one until I got to one called libldap.so.2. I got as far as working out that this is part of open-ldap. open-ldap.2.3.38 was the latest version I could find and it installed fine - I know it installed OK because the test scripts etc. run OK. But, libldap.so.2 is NOT THERE!! For instance, from the /../ directory, find -name libldap.so.2 -print doesn't find anything (but find -name *so.2 -print does, so there definitely are similarly named files around) I searched for libldap.so.2 in the open-ldap archives and all references to it were a few years ago. It seemed quite possible to me that libldap.so.2 has perhaps been renamed as something else in recent versions of open-ldap. Plenty of other libraries were created when I installed open-ldap.2.3.38, just not one with the exact name libldap.so.2. Is this some finickity requirement of PINE? I have got Apt installed but I don't really know how to use it - can I go look for something as specific as a .so.2 library file? So, what would people suggest? Can I get hold of this file for PINE or persuade it to use something else? (and if so, what and how?) Out of interest, why is PINE interested in libldap.so.2 in the first place and what does it do? Thanks in advance, Sarpeyer

2 1

Re: (ITS#5108) SID/RID: decimal or hex?
by hyc＠symas.com 27 Aug '07

27 Aug '07

ando(a)sys-net.it wrote: > Well, in slapd.conf(5) I already put 0-4095, but be can back it out. I > don't have any preference. Since the max will just slightly increase, I > don't see a big deal in terms of backwards compatibility. In any case > 4096 or 1000 is big for a RID, so no-one will be hurt. I was more > concerned about the 10 limit... OK. I kind of think they ought to be documented differently, so that people don't confuse SIDs with RIDs (as often happened in OpenLDAP 2.2) but it's probably fine the way it is. -- -- Howard Chu Chief Architect, 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#5108) SID/RID: decimal or hex?
by ando＠sys-net.it 27 Aug '07

27 Aug '07

Howard Chu wrote: > ando(a)sys-net.it wrote: >> Howard Chu wrote: > >>> The SID in the CSN has always been hex (but usually zero). The RID is >>> not part of the CSN and has always been decimal. Since the RID only >>> needs to be unique within a particular slapd instance, there's no real >>> problem there. >>> >> >> Right. but, well, slap_parse_csn_sid() was using strtoul(..., 10). Now >> fixed. > > Yeah, oops. That's good. > >> For consistency I've made both behave the same. The user won't >> basically notice it, so I don't see backward compatibility issues. > > So we leave the docs saying RID is 0-999? Well, in slapd.conf(5) I already put 0-4095, but be can back it out. I don't have any preference. Since the max will just slightly increase, I don't see a big deal in terms of backwards compatibility. In any case 4096 or 1000 is big for a RID, so no-one will be hurt. I was more concerned about the 10 limit... p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5108) SID/RID: decimal or hex?
by hyc＠symas.com 27 Aug '07

27 Aug '07

ando(a)sys-net.it wrote: > Howard Chu wrote: >> The SID in the CSN has always been hex (but usually zero). The RID is >> not part of the CSN and has always been decimal. Since the RID only >> needs to be unique within a particular slapd instance, there's no real >> problem there. >> > > Right. but, well, slap_parse_csn_sid() was using strtoul(..., 10). Now > fixed. Yeah, oops. That's good. > For consistency I've made both behave the same. The user won't > basically notice it, so I don't see backward compatibility issues. So we leave the docs saying RID is 0-999? -- -- Howard Chu Chief Architect, 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#5108) SID/RID: decimal or hex?
by ando＠sys-net.it 27 Aug '07

27 Aug '07

Howard Chu wrote: > ando(a)sys-net.it wrote: >> Full_Name: Pierangelo Masarati >> Version: HEAD/re23 >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (82.63.140.131) >> Submitted by: ando >> >> >> Should SID/RID be decimal (0-999) as in parsing and the rest of the >> syncrepl >> code, or hexadecimal (0-FFF) as in code generating CSN values? I >> understand the >> point is (almost) moot, but we'd get there as soon as someone starts >> using >>> 10-way multimaster... >> >> I'm fixing the code so that it consistently uses hex server IDs, >> please holler >> if using decimals is preferred. > > The SID in the CSN has always been hex (but usually zero). The RID is > not part of the CSN and has always been decimal. Since the RID only > needs to be unique within a particular slapd instance, there's no real > problem there. > Right. but, well, slap_parse_csn_sid() was using strtoul(..., 10). Now fixed. For consistency I've made both behave the same. The user won't basically notice it, so I don't see backward compatibility issues. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5108) SID/RID: decimal or hex?
by hyc＠symas.com 26 Aug '07

26 Aug '07

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re23 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > Submitted by: ando > > > Should SID/RID be decimal (0-999) as in parsing and the rest of the syncrepl > code, or hexadecimal (0-FFF) as in code generating CSN values? I understand the > point is (almost) moot, but we'd get there as soon as someone starts using >> 10-way multimaster... > > I'm fixing the code so that it consistently uses hex server IDs, please holler > if using decimals is preferred. The SID in the CSN has always been hex (but usually zero). The RID is not part of the CSN and has always been decimal. Since the RID only needs to be unique within a particular slapd instance, there's no real problem there. -- -- Howard Chu Chief Architect, 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#5106) LDAPI problem on amd64
by ando＠sys-net.it 26 Aug '07

26 Aug '07

svgmuc(a)bluebottle.com wrote: You should be using the latest 2.3 release; there was quite a bit of work on ldapi between 2.3.32 and 2.3.38 (ITS#4893 and other possibly related fixes). Having said this, I don't know if it will solve your problem, but at least it would make sure it's not fixed yet. No need to say that things work fine here on Linux/amd64. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5107) Wrong URL on admin guide in README
by ando＠sys-net.it 26 Aug '07

26 Aug '07

nicolasstlaurent.nospam(a)gmail.com wrote: > README file refer to : > > http://www.openldap.org/doc/guide/admin/guide.html > > The actual URL is : > > http://www.openldap.org/doc/admin/ Fixed in re23/re24. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5108) SID/RID: decimal or hex?
by ando＠sys-net.it 26 Aug '07

26 Aug '07

ando(a)sys-net.it wrote: > Should SID/RID be decimal (0-999) as in parsing and the rest of the syncrepl > code, or hexadecimal (0-FFF) as in code generating CSN values? I understand the > point is (almost) moot, but we'd get there as soon as someone starts using >> 10-way multimaster... or, if RID is to be typed in decimal form, let's remove the 3 digit limitation, and set a < 4096 limitation like for serverID. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5108) SID/RID: decimal or hex?
by ando＠sys-net.it 26 Aug '07

26 Aug '07

Full_Name: Pierangelo Masarati Version: HEAD/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando Should SID/RID be decimal (0-999) as in parsing and the rest of the syncrepl code, or hexadecimal (0-FFF) as in code generating CSN values? I understand the point is (almost) moot, but we'd get there as soon as someone starts using >10-way multimaster... I'm fixing the code so that it consistently uses hex server IDs, please holler if using decimals is preferred. p.

1 0

(ITS#5107) Wrong URL on admin guide in README
by nicolasstlaurent.nospam＠gmail.com 26 Aug '07

26 Aug '07

Full_Name: Nicolas St-Laurent Version: 2.3.37 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (205.205.243.49) README file refer to : http://www.openldap.org/doc/guide/admin/guide.html The actual URL is : http://www.openldap.org/doc/admin/

1 0

(ITS#5106) LDAPI problem on amd64
by svgmuc＠bluebottle.com 26 Aug '07

26 Aug '07

Full_Name: Sven Gerlach Version: 2.3.32 OS: NetBSD-3.1/amd64 URL: ftp://ftp.openldap.org/incoming/sven-gerlach-070826.txt Submission from: (NULL) (88.217.224.173) Hi, I've encountered a problem with the use of LDAPI connections on my system. The same set has been installed and configured on a NetBSD/i386 (32bit) system for testing and comparision purposes. The result is that the LDAPI implementation doesn't seem to work properly on the amd64 port. Any attempt to connect fails in ber_get_next() with an ERANGE. I've checked the configure line of the openldap-server package: # grep LDAP_PF_LOCAL openldap-2.3.32/config.log openldap-2.3.32/config.log:#define LDAP_PF_LOCAL 1 So, I figure, LDAPI support is compiled in. It works on the i386 port, anyway. I've uploaded my slapd.conf and debug output of ldapsearch and slapd. If anyone can help me with that, please do. Any assistance is appreciated as my knowledge of OpenLDAP internals isn't good enough. Best regards, Sven Gerlach

1 0

Re: (ITS#5077) syncrepl.add_cmp() infinite loop on swapped values
by hyc＠symas.com 25 Aug '07

25 Aug '07

hyc(a)symas.com wrote: > Donn Cave wrote: >> It looks easy enough to me to code up an order independent version that >> will actually work. I would initialize adds[] and dels[] with old & new >> berval pointers, iterate through dels[] and adds[] (nested), and clear >> both on match. The code is easier to follow and empirically I see one >> fewer matches in the cases I tested it on. But that's just a test of >> the algorithm - I haven't sorted out what needs to be done at the end of >> the function where mcur etc. are modified depending on i == j. > > The only way to do this right, without dying on an O(n^2) algorithm, is to sort > both arrays first and then walk through them in order as the original code did. > If you want to submit such a patch, please do. I don't have a lot of time to > focus on this at the moment. I've committed a patch based somewhat on your suggestion, in the interest of expediting a 2.4.5 release. Please test, we need to lock down this code ASAP. -- -- Howard Chu Chief Architect, 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#5104) OpenLDAP build breaks with SSL
by brucee＠acm.org 25 Aug '07

25 Aug '07

You need to specify the no-dso option when you configure OpenSSL. This should eliminate the requirement for -ldl on the link. ----- Original Message ----- From: <ando(a)sys-net.it> To: <openldap-its(a)openldap.org> Sent: Saturday, August 25, 2007 3:18 AM Subject: Re: (ITS#5104) OpenLDAP build breaks with SSL > Richard Beckett wrote: >> Pierangelo, I really need help. My neck is on the block with this one. >> It is preventing me from accessing Active directory since that requires >> SASL. > > 1) Your issue is seems not to be an issue, since it seems to work for > anyone else, including myself. If I can't reproduce, I can't fix it. > 2) I don't have time. > 3) If I had time, I'd spend it working for the community, not for a > single (unless well paid), but you keep posting only to me. > 4) The fact I initially answered your request doesn't mean you gained a > perpetual support ticket until your issue is solved. > 5) If you post to the ITS there are chances someone else, either with > the same problem, or with better understanding of the issue can help. > > I consider my participation to this ITS closed. > > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > --------------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- > > >

1 0

Re: (ITS#5104) OpenLDAP build breaks with SSL
by ando＠sys-net.it 25 Aug '07

25 Aug '07

Richard Beckett wrote: > Pierangelo, I really need help. My neck is on the block with this one. > It is preventing me from accessing Active directory since that requires > SASL. 1) Your issue is seems not to be an issue, since it seems to work for anyone else, including myself. If I can't reproduce, I can't fix it. 2) I don't have time. 3) If I had time, I'd spend it working for the community, not for a single (unless well paid), but you keep posting only to me. 4) The fact I initially answered your request doesn't mean you gained a perpetual support ticket until your issue is solved. 5) If you post to the ITS there are chances someone else, either with the same problem, or with better understanding of the issue can help. I consider my participation to this ITS closed. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5102) back-perl build issues
by ando＠sys-net.it 25 Aug '07

25 Aug '07

Kurt Zeilenga wrote: >> ConfigReply is declared in slapd/config.h; could it be another, >> system-related config.h is present in an earlier include path? >> >> Even though, I see in the above cc command-line -I .. is present... > > Personally, I think have -I., -I.., etc. is really bad. This causes > #include "config.h" > and > #include <config.h> > > to be equivalent. However, there could be both a local config.h and a > config.h somewhere in the system include directory. > > I would be better if slapd/config.h was included here by: > #include "../config.h" > > and -I.. not be added to the include path. It possible -I.. is causing > a system header to be eclipsed by the local header. -I.. is needed to include slap.h, proto-slap.h, ... I'd rather rename config.h, which is quite generic, into slapconf.h or so. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5102) back-perl build issues
by quanah＠zimbra.com 25 Aug '07

25 Aug '07

--On Saturday, August 25, 2007 6:16 AM +0000 kurt(a)OpenLDAP.org wrote: > Personally, I think have -I., -I.., etc. is really bad. This causes > #include "config.h" > and > #include <config.h> > > to be equivalent. However, there could be both a local config.h and > a config.h somewhere in the system include directory. > > I would be better if slapd/config.h was included here by: > #include "../config.h" > > and -I.. not be added to the include path. It possible -I.. is > causing a system header to be eclipsed by the local header. > Namely, /opt/local/lib/perl5/5.8.8/darwin-2level/CORE/config.h. This issue seems to hit Mac systems a lot, dunno why. But I've seen it with several things now that touch perl. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5102) back-perl build issues
by kurt＠OpenLDAP.org 25 Aug '07

25 Aug '07

On Aug 25, 2007, at 5:35 AM, ando(a)sys-net.it wrote: > kurt(a)OpenLDAP.org wrote: > >>>> Entering directory `/Users/kurt/Work/devel/servers/slapd/back-perl' >>>> /bin/sh ../../..//libtool --tag=disable-shared --mode=compile cc - >>>> g -O2 >>>> -I../../../include -I../../../include -I.. -I./.. -I/opt/ >>>> local/include >>>> -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing - >>>> pipe >>>> -Wdeclaration-after-statement -I/opt/local/include >>>> -I/opt/local/lib/perl5/5.8.8/darwin-2level/CORE -I/usr/pkg/ >>>> include >>>> -I/usr/pkg/include/db45 -c init.c >>>> cc -g -O2 -I../../../include -I../../../include -I.. -I./.. >>>> -I/opt/local/include -fno-common -DPERL_DARWIN -no-cpp-precomp >>>> -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/opt/ >>>> local/include >>>> -I/opt/local/lib/perl5/5.8.8/darwin-2level/CORE -I/usr/pkg/include >>>> -I/usr/pkg/include/db45 -c init.c -o init.o >>>> init.c:90: error: parse error before 'ConfigReply' > > ConfigReply is declared in slapd/config.h; could it be another, > system-related config.h is present in an earlier include path? > > Even though, I see in the above cc command-line -I .. is present... Personally, I think have -I., -I.., etc. is really bad. This causes #include "config.h" and #include <config.h> to be equivalent. However, there could be both a local config.h and a config.h somewhere in the system include directory. I would be better if slapd/config.h was included here by: #include "../config.h" and -I.. not be added to the include path. It possible -I.. is causing a system header to be eclipsed by the local header. Namely, /opt/local/lib/perl5/5.8.8/darwin-2level/CORE/config.h. > > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > --------------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- > > >

1 0

Re: (ITS#5102) back-perl build issues
by ando＠sys-net.it 25 Aug '07

25 Aug '07

kurt(a)OpenLDAP.org wrote: >>> Entering directory `/Users/kurt/Work/devel/servers/slapd/back-perl' >>> /bin/sh ../../..//libtool --tag=disable-shared --mode=compile cc - >>> g -O2 >>> -I../../../include -I../../../include -I.. -I./.. -I/opt/ >>> local/include >>> -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe >>> -Wdeclaration-after-statement -I/opt/local/include >>> -I/opt/local/lib/perl5/5.8.8/darwin-2level/CORE -I/usr/pkg/include >>> -I/usr/pkg/include/db45 -c init.c >>> cc -g -O2 -I../../../include -I../../../include -I.. -I./.. >>> -I/opt/local/include -fno-common -DPERL_DARWIN -no-cpp-precomp >>> -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/opt/ >>> local/include >>> -I/opt/local/lib/perl5/5.8.8/darwin-2level/CORE -I/usr/pkg/include >>> -I/usr/pkg/include/db45 -c init.c -o init.o >>> init.c:90: error: parse error before 'ConfigReply' ConfigReply is declared in slapd/config.h; could it be another, system-related config.h is present in an earlier include path? Even though, I see in the above cc command-line -I .. is present... p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5102) back-perl build issues
by kurt＠OpenLDAP.org 25 Aug '07

25 Aug '07

On Aug 22, 2007, at 6:04 PM, ando(a)sys-net.it wrote: > kurt(a)OpenLDAP.org wrote: > >> With perl v5.8.8 from macports (recently upgraded) Switching to the MacOS X default perl doesn't help... > Works fine here (Linux) > >> Entering directory `/Users/kurt/Work/devel/servers/slapd/back-perl' >> /bin/sh ../../..//libtool --tag=disable-shared --mode=compile cc - >> g -O2 >> -I../../../include -I../../../include -I.. -I./.. -I/opt/ >> local/include >> -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe >> -Wdeclaration-after-statement -I/opt/local/include >> -I/opt/local/lib/perl5/5.8.8/darwin-2level/CORE -I/usr/pkg/include >> -I/usr/pkg/include/db45 -c init.c >> cc -g -O2 -I../../../include -I../../../include -I.. -I./.. >> -I/opt/local/include -fno-common -DPERL_DARWIN -no-cpp-precomp >> -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/opt/ >> local/include >> -I/opt/local/lib/perl5/5.8.8/darwin-2level/CORE -I/usr/pkg/include >> -I/usr/pkg/include/db45 -c init.c -o init.o >> init.c:90: error: parse error before 'ConfigReply' >> init.c: In function 'perl_back_db_init': >> init.c:92: error: number of arguments doesn't match prototype >> proto-perl.h:27: error: prototype declaration > > This was recently (sort of: 2 weeks ago) changed. Are you sure you > updated? Yes. > > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > --------------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- > > >

1 0

Re: (ITS#5105) 64 bit Windows portability errors in liblber
by hyc＠symas.com 24 Aug '07

24 Aug '07

alexey.melnikov(a)isode.com wrote: > Full_Name: Alexey Melnikov > Version: 2.3.28 > OS: Windows XP > URL: ftp://ftp.openldap.org/incoming/alexey-melnikov-070824.diff > Submission from: (NULL) (62.3.217.250) > > > Visual C 8.0 reports warnings when building liblber with /Wp64 (64 bit Windows > portability warnings). The warnings are actually bugs on Windows 64: Thanks, committed to HEAD. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5105) 64 bit Windows portability errors in liblber
by alexey.melnikov＠isode.com 24 Aug '07

24 Aug '07

Full_Name: Alexey Melnikov Version: 2.3.28 OS: Windows XP URL: ftp://ftp.openldap.org/incoming/alexey-melnikov-070824.diff Submission from: (NULL) (62.3.217.250) Visual C 8.0 reports warnings when building liblber with /Wp64 (64 bit Windows portability warnings). The warnings are actually bugs on Windows 64: bprint.c(269) : warning C4311: 'type cast' : pointer truncation from 'char *' to 'long' bprint.c(270) : warning C4311: 'type cast' : pointer truncation from 'char *' to 'long' bprint.c(271) : warning C4311: 'type cast' : pointer truncation from 'char *' to 'long' bprint.c(308) : warning C4311: 'type cast' : pointer truncation from 'char *' to 'long' bprint.c(309) : warning C4311: 'type cast' : pointer truncation from 'char *' to 'long' decode.c(376) : warning C4311: 'type cast' : pointer truncation from 'BerVarray' to 'long' decode.c(377) : warning C4312: 'type cast' : conversion from 'unsigned long' to 'berval *' of greater size decode.c(409) : warning C4311: 'type cast' : pointer truncation from 'BerVarray' to 'long' decode.c(409) : warning C4312: 'type cast' : conversion from 'unsigned long' to 'BerVarray' of greater size Warnings in bprint.c are caused by use of %X which is incorrect on Windows 64. Portable %p should be used instead. Problems in decode.c are caused by typecasting a pointer to a long. Unfortunately on Windows 64 a pointer is 64 bits, while "long" is still 32bits, which is obviously problematic. The fix is to use typecase to "char *" instead, as pointer arithmetics will work for it. I've uploaded the patch as <ftp://ftp.openldap.org/incoming/alexey-melnikov-070824.diff>

1 0

Re: (ITS#5096) [enhancement] back-sql should provide a means to reload schema mapping runtime
by ando＠sys-net.it 24 Aug '07

24 Aug '07

ando(a)sys-net.it wrote: > This is a request enhancement for a means to reload schema mapping run-time, > without the need to stop slapd. The ideal candidate for this feature seems to > be back-monitor. ... of course, adding back-config support would probably allow to remove and add the database again, resulting in the expected behavior. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5077) syncrepl.add_cmp() infinite loop on swapped values
by hyc＠symas.com 23 Aug '07

23 Aug '07

Donn Cave wrote: > It looks easy enough to me to code up an order independent version that > will actually work. I would initialize adds[] and dels[] with old & new > berval pointers, iterate through dels[] and adds[] (nested), and clear > both on match. The code is easier to follow and empirically I see one > fewer matches in the cases I tested it on. But that's just a test of > the algorithm - I haven't sorted out what needs to be done at the end of > the function where mcur etc. are modified depending on i == j. The only way to do this right, without dying on an O(n^2) algorithm, is to sort both arrays first and then walk through them in order as the original code did. If you want to submit such a patch, please do. I don't have a lot of time to focus on this at the moment. -- -- Howard Chu Chief Architect, 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#5104) OpenLDAP build breaks with SSL
by ando＠sys-net.it 23 Aug '07

23 Aug '07

Hallvard B Furuseth wrote: > ando(a)sys-net.it writes: >> Actually, things seem to work just fine. I erroneously built >> openssl-0.9.8e without shared, and in that case it doesn't work. > > What's wrong with building it without shared? The build instructions > doesn't say we need the shared variant. I screwed things up, because I was building on Opteron, and ld complained about some non-relocatable symbols in libssl.a. Probably it either didn't guess well at my system, or I missed something. So it was probably me. Explicitly adding LIBS=-ldl fixed configure, but not the build later on. But I think this is off-topic with respect to this ITS. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5104) OpenLDAP build breaks with SSL
by h.b.furuseth＠usit.uio.no 23 Aug '07

23 Aug '07

ando(a)sys-net.it writes: > Actually, things seem to work just fine. I erroneously built > openssl-0.9.8e without shared, and in that case it doesn't work. What's wrong with building it without shared? The build instructions doesn't say we need the shared variant. -- Hallvard

1 0

Re: (ITS#5104) OpenLDAP build breaks with SSL
by ando＠sys-net.it 23 Aug '07

23 Aug '07

PLEASE KEEP REPLIES IN COPY ON THE ITS! Richard Beckett wrote: > I built openssl with the shared option for the config script. I have the > LD_LIBRARY_PATH set to /usr/local/lib which is where I put the Berkeley > DB libraries. Do I need something else? > > Here is what I get from the"make" after having run "make depend": > > ./.libs/libldap.a(tls.o)(.text+0x593): In function `sb_tls_bio_read': > /usr/local/src/LDAP/openldap-2.3.38/libraries/libldap/tls.c:676: > undefined reference to `BIO_clear_flags' Those symbols (at least in openssl-9.8.0e) are defined in libcrypto. You don't show the linker command line that is failing, but I still believe your build environment is broken, since OpenLDAP explicitly links libcrypto along with libssl. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5104) OpenLDAP build breaks with SSL
by ando＠sys-net.it 23 Aug '07

23 Aug '07

Please keep replies on the list Richard Beckett wrote: > Pierangelo, thank you very much for the reply. Can you suggest a > work-around for the time being? Do I need to edit the Makefile? I have > not worked at this level for many years and my knowledge of "make" is > rusty. Actually, things seem to work just fine. I erroneously built openssl-0.9.8e without shared, and in that case it doesn't work. I suspect your build environment is broken (possibly the way you built openssl?). Please check if it's built correctly; if it is, please inspect the config.log resulting from building OpenLDAP to get some hint about the reason of the failure. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5104) OpenLDAP build breaks with SSL
by ando＠sys-net.it 23 Aug '07

23 Aug '07

rbeckett(a)exelixis.com wrote: > Full_Name: Richard Beckett > Version: openldap-2.3.38 > OS: Solaris 10/RHEL v4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (65.209.203.254) > > > After compiling openssl-0.9.8e and installing it, then configuring > openldap-2.3.38 with ./configure followed by make depends and make, the make > fails. If I remove the /usr/local/lib/*ssl* and /usr/local/include/ssl* > directories and files then the make works fine. This occurs on both the Linux > and Solaris hosts It seems that linking a program with openssl needs to explicitly provide -ldl in LIBS. I'm investigating whether this is related to OpenLDAP's configure or related to libssl's build/installation. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5104) OpenLDAP build breaks with SSL
by rbeckett＠exelixis.com 23 Aug '07

23 Aug '07

Full_Name: Richard Beckett Version: openldap-2.3.38 OS: Solaris 10/RHEL v4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.209.203.254) After compiling openssl-0.9.8e and installing it, then configuring openldap-2.3.38 with ./configure followed by make depends and make, the make fails. If I remove the /usr/local/lib/*ssl* and /usr/local/include/ssl* directories and files then the make works fine. This occurs on both the Linux and Solaris hosts

1 0

(ITS#5103) ldap_create_passwordpolicy_control creates illegal pp request control
by kurt＠OpenLDAP.org 22 Aug '07

22 Aug '07

Full_Name: Kurt Zeilenga Version: HEAD OS: Mac OS X 10.4.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.180.46.200) Submitted by: kurt Fixed in HEAD libraries/libldap/ppolicy.c 1.14,1.15 libraries/libldap/controls.c 1.53,1.55

3 4

Re: (ITS#5102) back-perl build issues
by ando＠sys-net.it 22 Aug '07

22 Aug '07

kurt(a)OpenLDAP.org wrote: > With perl v5.8.8 from macports (recently upgraded) Works fine here (Linux) > Entering directory `/Users/kurt/Work/devel/servers/slapd/back-perl' > /bin/sh ../../..//libtool --tag=disable-shared --mode=compile cc -g -O2 > -I../../../include -I../../../include -I.. -I./.. -I/opt/local/include > -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe > -Wdeclaration-after-statement -I/opt/local/include > -I/opt/local/lib/perl5/5.8.8/darwin-2level/CORE -I/usr/pkg/include > -I/usr/pkg/include/db45 -c init.c > cc -g -O2 -I../../../include -I../../../include -I.. -I./.. > -I/opt/local/include -fno-common -DPERL_DARWIN -no-cpp-precomp > -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/opt/local/include > -I/opt/local/lib/perl5/5.8.8/darwin-2level/CORE -I/usr/pkg/include > -I/usr/pkg/include/db45 -c init.c -o init.o > init.c:90: error: parse error before 'ConfigReply' > init.c: In function 'perl_back_db_init': > init.c:92: error: number of arguments doesn't match prototype > proto-perl.h:27: error: prototype declaration This was recently (sort of: 2 weeks ago) changed. Are you sure you updated? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Saturn v1.1 on openldap v2.4.4alpha
by Domagoj Babic 22 Aug '07

22 Aug '07

Hi, I'd appreciate if anyone could provide feedback on this report from another tool. I've filtered out all the warnings that are provably false. BTW, playing with openldap for a couple of days, I found that the code is of much lower quality than some other open source projects, like ISC bind & ntp, openssh,... Static checkers also find more bugs. Some things I spotted: - code is very non-uniform, the same things are done in very different ways - in several places (10-20) pointers are checked with an assertion, but after the pointer has already been dereferenced. What's the purpose of assertions then? - "fat interfaces" - very long sequences of dereferences, like: *desc->ad_type->sat_equality->smr_normalize make GDB debugging harder, discourage consistency checking, and make static checking reports less readable. - inconsistency, a lot of it, for instance, a pointer is dereferenced, and ten lines below it's actually checked for NULL and then dereferenced Anyways, here is the report, I hope it's going to be helpful: Please replace ??? with Yes/No, and a short explanation. Bad programming practices are not considered bugs. A bug (by my definition) is a sequence of events that would crash the app, no matter how small the probability is, or how irrelevant the app is. Please, also consider the calling context (unlike Calysto, Saturn does not provide a complete trace, so it is hard to figure out whether the functions can be called under the right conditions to trigger the bug). If you can prove that the function can never be called so as to trigger the 'bug', then it's not a bug. ---------------------------------------------------------------- Bug: ??? @blue @2114 blue __arg0*.bv_val of function select_backend can evaluate to NULL select_backend (2114:servers/slapd/acl.c), final site of dereference is: (678:servers/slapd/backend.c) @servers/slapd/acl.c @Null pointer is passed to a function which dereferences it. ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? @violet @774 violet (INCONSISTENT USE) Possible null dereference __arg1*.e_nname.bv_val. This variable is checked for Null at lines: 704, and is dereferenced through call chain: servers/slapd/acl.c:regex_matches (774:servers/slapd/acl.c), acl_string_expand (2507:servers/slapd/acl.c), final site of dereference is: (2455:servers/slapd/acl.c) @servers/slapd/acl.c @Interprocedural inconsistency error @violet @837 violet (INCONSISTENT USE) Possible null dereference __arg1*.e_nname.bv_val. This variable is checked for Null at lines: 704, and is dereferenced through call chain: acl_string_expand (837:servers/slapd/acl.c), final site of dereference is: (2455:servers/slapd/acl.c) @servers/slapd/acl.c @Interprocedural inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Seems like a bug. @violet @3868 violet (INCONSISTENT USE) Possible null dereference __arg0*.si_anlist. This variable is checked for Null at lines: 3859, and is dereferenced through call chain: anlist_unparse (3868:servers/slapd/syncrepl.c), final site of dereference is: (2841:servers/slapd/bconfig.c) @servers/slapd/syncrepl.c @Interprocedural inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Seems like a bug. @red @1753 red Possible NULL dereference of keys+keycount @servers/slapd/schema_init.c @Intraprocedural Null error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? @orange @2212 orange (INCONSISTENT USE) Possible null dereference of variable c->be->be_suffix+i. This variable is checked for Null at lines: 2192 @servers/slapd/bconfig.c @Inconsistency error @orange @2211 orange (INCONSISTENT USE) Possible null dereference of variable c->be->be_suffix+i. This variable is checked for Null at lines: 2192 @servers/slapd/bconfig.c @Inconsistency error @orange @2212 orange (INCONSISTENT USE) Possible null dereference of variable c->be->be_suffix+(i+1). This variable is checked for Null at lines: 2192 @servers/slapd/bconfig.c @Inconsistency error @orange @2209 orange (INCONSISTENT USE) Possible null dereference of variable c->be->be_suffix+i. This variable is checked for Null at lines: 2192 @servers/slapd/bconfig.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? @orange @3147 orange (INCONSISTENT USE) Possible null dereference of variable c->be->be_update_refs+i. This variable is checked for Null at lines: 3135 @servers/slapd/bconfig.c @Inconsistency error @orange @3149 orange (INCONSISTENT USE) Possible null dereference of variable c->be->be_update_refs+(i+1). This variable is checked for Null at lines: 3135 @servers/slapd/bconfig.c @Inconsistency error @orange @3148 orange (INCONSISTENT USE) Possible null dereference of variable c->be->be_update_refs+i. This variable is checked for Null at lines: 3135 @servers/slapd/bconfig.c @Inconsistency error @orange @3149 orange (INCONSISTENT USE) Possible null dereference of variable c->be->be_update_refs+i. This variable is checked for Null at lines: 3135 @servers/slapd/bconfig.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? There seems to be some correlation between default_passwd_hash and c->valx interprocedurally, but I couldn't figure it out. @orange @1934 orange (INCONSISTENT USE) Possible null dereference of variable default_passwd_hash+i. This variable is checked for Null at lines: 1938 @servers/slapd/bconfig.c @Inconsistency error @orange @1933 orange (INCONSISTENT USE) Possible null dereference of variable default_passwd_hash+i. This variable is checked for Null at lines: 1938 @servers/slapd/bconfig.c @Inconsistency error @orange @1934 orange (INCONSISTENT USE) Possible null dereference of variable default_passwd_hash+(i+1). This variable is checked for Null at lines: 1938 @servers/slapd/bconfig.c @Inconsistency error @orange @1932 orange (INCONSISTENT USE) Possible null dereference of variable default_passwd_hash+i. This variable is checked for Null at lines: 1938 @servers/slapd/bconfig.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? The same as above @orange @2743 orange (INCONSISTENT USE) Possible null dereference of variable default_referral+i. This variable is checked for Null at lines: 2731 @servers/slapd/bconfig.c @Inconsistency error @orange @2744 orange (INCONSISTENT USE) Possible null dereference of variable default_referral+i. This variable is checked for Null at lines: 2731 @servers/slapd/bconfig.c @Inconsistency error @orange @2745 orange (INCONSISTENT USE) Possible null dereference of variable default_referral+i. This variable is checked for Null at lines: 2731 @servers/slapd/bconfig.c @Inconsistency error @orange @2745 orange (INCONSISTENT USE) Possible null dereference of variable default_referral+(i+1). This variable is checked for Null at lines: 2731 @servers/slapd/bconfig.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? @orange @377 orange (INCONSISTENT USE) Possible null dereference of variable b1. This variable is checked for Null at lines: 348 @servers/slapd/backglue.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Seems like a false positive, but not sure. @violet @463 violet (INCONSISTENT USE) Possible null dereference servers/slapd/oc.c:oc_list.stqh_first*.soc_next.stqe_next. This variable is checked for Null at lines: 461, and is dereferenced through call chain: servers/slapd/oc.c:oc_delete_names (463:servers/slapd/oc.c), final site of dereference is: (394:servers/slapd/oc.c) @servers/slapd/oc.c @Interprocedural inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? @orange @2807 orange (INCONSISTENT USE) Possible null dereference of variable a->acl_attrs+0. This variable is checked for Null at lines: 2784 @servers/slapd/aclparse.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Seems like attrs_alloc can return NULL @799. @red @869 red Possible NULL dereference of a with trace a @servers/slapd/entry.c @Intraprocedural error with loop summary propagation @red @837 red Possible NULL dereference of a with trace a @servers/slapd/entry.c @Intraprocedural error with loop summary propagation @red @871 red Possible NULL dereference of a with trace a @servers/slapd/entry.c @Intraprocedural error with loop summary propagation @red @856 red Possible NULL dereference of a with trace a @servers/slapd/entry.c @Intraprocedural error with loop summary propagation @red @840 red Possible NULL dereference of a with trace a @servers/slapd/entry.c @Intraprocedural error with loop summary propagation @red @838 red Possible NULL dereference of a with trace a @servers/slapd/entry.c @Intraprocedural error with loop summary propagation ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Seems like out is initialized in the loop body, and the loop is executed at least once, but I'm not sure. @orange @292 orange (INCONSISTENT USE) Possible null dereference of variable out+outpos. This variable is checked for Null at lines: 268 @libraries/liblunicode/ucstr.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Bug, pointer returned by realloc not checked. @red @288 red Possible NULL dereference of values+(nvalues+j) with trace values @tests/progs/slapd-search.c @Intraprocedural error with loop summary propagation ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Seems like anew->an_name.bv_val can remain uninitialized or NULL @red @943 red Possible NULL dereference of anew->an_name.bv_val+0 with trace anew*.an_name.bv_val @servers/slapd/ad.c @Intraprocedural error with loop summary propagation @red @921 red Possible NULL dereference of anew->an_name.bv_val+0 with trace anew*.an_name.bv_val @servers/slapd/ad.c @Intraprocedural error with loop summary propagation ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Inconsistency, can it be NULL? @orange @128 orange (INCONSISTENT USE) Possible null dereference of variable info. This variable is checked for Null at lines: 136 @libraries/librewrite/rule.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? @blue @172 blue Trace entry of function tests/progs/slapd-modrdn.c:do_modrdn evaluates to NULL and is dereferenced through call chain: tests/progs/slapd-modrdn.c:do_modrdn (172:tests/progs/slapd-modrdn.c), final site of dereference is: (205:tests/progs/slapd-modrdn.c) @tests/progs/slapd-modrdn.c @Interprocedural Null error with loop summary propagation ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Seems like bugs - SF_POP can return NULL. @blue @385 blue __arg1 of function slap_set_join can evaluate to NULL slap_set_join (385:servers/slapd/sets.c), final site of dereference is: (230:servers/slapd/sets.c) @servers/slapd/sets.c @Null pointer is passed to a function which dereferences it. @blue @411 blue __arg1 of function slap_set_join can evaluate to NULL slap_set_join (411:servers/slapd/sets.c), final site of dereference is: (230:servers/slapd/sets.c) @servers/slapd/sets.c @Null pointer is passed to a function which dereferences it. ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Seems like bugs. @orange @231 orange (INCONSISTENT USE) Possible null dereference of variable rset+j. This variable is checked for Null at lines: 134, 188 @servers/slapd/sets.c @Inconsistency error @orange @244 orange (INCONSISTENT USE) Possible null dereference of variable rset+j. This variable is checked for Null at lines: 134, 188 @servers/slapd/sets.c @Inconsistency error @orange @235 orange (INCONSISTENT USE) Possible null dereference of variable rset+j. This variable is checked for Null at lines: 134, 188 @servers/slapd/sets.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Seems like bugs. @orange @243 orange (INCONSISTENT USE) Possible null dereference of variable lset+i. This variable is checked for Null at lines: 120, 188 @servers/slapd/sets.c @Inconsistency error @orange @235 orange (INCONSISTENT USE) Possible null dereference of variable lset+i. This variable is checked for Null at lines: 120, 188 @servers/slapd/sets.c @Inconsistency error @orange @230 orange (INCONSISTENT USE) Possible null dereference of variable lset+i. This variable is checked for Null at lines: 120, 188 @servers/slapd/sets.c @Inconsistency error @orange @244 orange (INCONSISTENT USE) Possible null dereference of variable lset+i. This variable is checked for Null at lines: 120, 188 @servers/slapd/sets.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? This pointer is checked @210, and if it's NULL a proper msg is printed, and then the pointer can be dereferenced. Would this be considered a bug, or a normal sequence of events? @blue @227 blue __arg0 of function servers/slurpd/ldap_op.c:free_ldmarr can evaluate to NULL servers/slurpd/ldap_op.c:free_ldmarr (227:servers/slurpd/ldap_op.c), final site of dereference is: (574:servers/slurpd/ldap_op.c) @servers/slurpd/ldap_op.c @Null pointer is passed to a function which dereferences it. ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Looks like a bug. @red @349 red Possible NULL dereference of ldmarr+nops @servers/slurpd/ldap_op.c @Intraprocedural Null error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? @red @646 red Possible NULL dereference of srs with trace srs @servers/slapd/overlays/syncprov.c @Intraprocedural error with loop summary propagation @red @649 red Possible NULL dereference of srs with trace srs @servers/slapd/overlays/syncprov.c @Intraprocedural error with loop summary propagation @red @647 red Possible NULL dereference of srs with trace srs @servers/slapd/overlays/syncprov.c @Intraprocedural error with loop summary propagation ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Can that pointer be NULL? @orange @545 orange (INCONSISTENT USE) Possible null dereference of variable op->o_bd. This variable is checked for Null at lines: 551, 553, 597 @servers/slapd/backover.c @Inconsistency error @orange @477 orange (INCONSISTENT USE) Possible null dereference of variable op->o_bd. This variable is checked for Null at lines: 483, 485, 529 @servers/slapd/backover.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Looks like a bug if the loop body @1104 is not executed. @red @1112 red Possible NULL dereference of on with trace on @servers/slapd/backover.c @Intraprocedural error with loop summary propagation @red @1113 red Possible NULL dereference of on with trace on @servers/slapd/backover.c @Intraprocedural error with loop summary propagation ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Bad programming practice, what's the point of checking the pointer after dereference?? Is this a bug? @orange @528 orange (INCONSISTENT USE) Possible null dereference of variable val. This variable is checked for Null at lines: 534 @servers/slapd/value.c @Inconsistency error @orange @465 orange (INCONSISTENT USE) Possible null dereference of variable val. This variable is checked for Null at lines: 471 @servers/slapd/value.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Bad programming practice, is it a bug? @orange @298 orange (INCONSISTENT USE) Possible null dereference of variable data. This variable is checked for Null at lines: 302 @libraries/librewrite/ldapmap.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Seems like a bug. @orange @194 orange (INCONSISTENT USE) Possible null dereference of variable defaults. This variable is checked for Null at lines: 115, 118, 121, 125 @libraries/liblutil/sasl.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? @red @147 red Possible NULL dereference of p @libraries/liblutil/avl.c @Intraprocedural Null error @red @148 red Possible NULL dereference of p @libraries/liblutil/avl.c @Intraprocedural Null error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? This is definitely a bad programming practice. Can rdn be NULL? @orange @238 orange (INCONSISTENT USE) Possible null dereference of variable rdn+iAVA. This variable is checked for Null at lines: 240 @servers/slapd/dn.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? This is definitely a bad programming practice. Can dn be NULL? @orange @1202 orange (INCONSISTENT USE) Possible null dereference of variable dn. This variable is checked for Null at lines: 1204 @servers/slapd/dn.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? This is definitely a bad programming practice. Can suffix be NULL? @orange @1202 orange (INCONSISTENT USE) Possible null dereference of variable suffix. This variable is checked for Null at lines: 1205 @servers/slapd/dn.c @Inconsistency error ---------------------------------------------------------------- ---------------------------------------------------------------- Bug: ??? Seems like a bug. @red @634 red Possible NULL dereference of avl_list+ciltmp @libraries/liblutil/avl.c @Intraprocedural Null error ---------------------------------------------------------------- Thx, -- Domagoj Babic http://www.domagoj.info/ http://www.calysto.org/

2 2

(ITS#5102) back-perl build issues
by kurt＠OpenLDAP.org 22 Aug '07

22 Aug '07

Full_Name: Kurt Zeilenga Version: HEAD OS: Mac OS X 10.4.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.180.46.200) Submitted by: kurt With perl v5.8.8 from macports (recently upgraded) Entering directory `/Users/kurt/Work/devel/servers/slapd/back-perl' /bin/sh ../../..//libtool --tag=disable-shared --mode=compile cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -I/opt/local/include -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/opt/local/include -I/opt/local/lib/perl5/5.8.8/darwin-2level/CORE -I/usr/pkg/include -I/usr/pkg/include/db45 -c init.c cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -I/opt/local/include -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/opt/local/include -I/opt/local/lib/perl5/5.8.8/darwin-2level/CORE -I/usr/pkg/include -I/usr/pkg/include/db45 -c init.c -o init.o init.c:90: error: parse error before 'ConfigReply' init.c: In function 'perl_back_db_init': init.c:92: error: number of arguments doesn't match prototype proto-perl.h:27: error: prototype declaration init.c:93: error: 'be' undeclared (first use in this function) init.c:93: error: (Each undeclared identifier is reported only once init.c:93: error: for each function it appears in.) init.c: At top level: init.c:106: error: parse error before 'ConfigReply' init.c: In function 'perl_back_db_open': init.c:108: error: number of arguments doesn't match prototype proto-perl.h:28: error: prototype declaration init.c:112: error: 'be' undeclared (first use in this function) make[3]: *** [init.lo] Error 1

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs