- openldap-bugs - openldap.org

Re: (ITS#4716) syncrepl - consumer missed some delete
by Paolo.Rossi.con＠h3g.it 23 Oct '06

23 Oct '06

--Apple-Mail-2-751178356 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > Are you patched for ITS#4708 and ITS#4695? Those are my current > "don't try to syncrepl without it" for RE23... No, I was using 2.3.27 "pure" I'll give a try, THX > > Is this refreshAndPersist, or refreshOnly? delta-syncrepl? Do you > use a session log? Maybe just post the relevant config entirely... Right, and sorry It is a syncrepl with RefresAndPersist, with "retry 600 +" The enviroment is the same of ITS#4702 with 1m entry DB Paolo --Apple-Mail-2-751178356 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 <HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = -khtml-line-break: after-white-space; "><DIV><BLOCKQUOTE = type=3D"cite"></BLOCKQUOTE><BR><BLOCKQUOTE type=3D"cite"><DIV = style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px; ">Are you patched for ITS#4708 and ITS#4695? Those are = my current "don't try to syncrepl without it" for = RE23...</DIV></BLOCKQUOTE><DIV><BR = class=3D"khtml-block-placeholder"></DIV><DIV>No, I was using 2.3.27 = "pure"=A0</DIV><DIV>I'll give a try, THX</DIV><BR><BLOCKQUOTE = type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: 0px; = margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV = style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px; ">Is this refreshAndPersist, or refreshOnly? = delta-syncrepl? Do you use a session log? Maybe just post the relevant = config entirely...</DIV> </BLOCKQUOTE></DIV><BR><DIV>Right, and = sorry</DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV>It is a = syncrepl with RefresAndPersist, with "retry 600 +"</DIV><DIV><BR = class=3D"khtml-block-placeholder"></DIV><DIV>The enviroment is the same = of ITS#4702 with 1m entry DB</DIV><DIV><SPAN class=3D"Apple-style-span" = style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = rgb(0, 0, 0); font-family: Helvetica; font-size: 15px; font-style: = normal; font-variant: normal; font-weight: normal; letter-spacing: = normal; line-height: normal; text-align: auto; = -khtml-text-decorations-in-effect: none; text-indent: 0px; = -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = white-space: normal; widows: 2; word-spacing: 0px; "><DIV><BR = class=3D"khtml-block-placeholder"></DIV><DIV><BR = class=3D"khtml-block-placeholder"></DIV><DIV>Paolo=A0</DIV></SPAN></DIV><B= R></BODY></HTML>= --Apple-Mail-2-751178356--

1 0

Re: (ITS#4717) Efficient handling of response lists in C-API
by Kurt＠OpenLDAP.org 22 Oct '06

22 Oct '06

At 10:14 AM 10/22/2006, ando(a)sys-net.it wrote: >Full_Name: Pierangelo Masarati >Version: HEAD >OS: irrelevant >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (81.72.89.40) >Submitted by: ando > > >In proxies, we occasionally need to mark some response messages as "don't care". > This is slightly different than "abandon", in the sense that, for performance >and band occupation, an abandon would likely get too late to the remote server, >but if the response is not removed from the list that would grow and waste >resources. > >In realistic cases we profiled proxies that spend 50-60% of the CPU time running >the list of messages to check if any of them has been abandoned. > >The proposed fix consists in: > >- keeping abandoned msgid's sorted, so that a bisection algorithm can be used to >check if a msgid has been abandoned > >- add a ldap_int_abandon() call that marks a message as "abandoned" without >actually sending an "abandon" operation. This call is, by now, private >(ldap_int_) since its use in normal clients would make little sense. However, >whenever it does make sense, there's no objection in making the call public >(sort of ldap_abandon_mark()). I rather not name this "abandon" as it doesn't send an Abandon request. Maybe name this "discard" instead. E.g., ldap_int_discard(). >With this change, the overall CPU used to check response list in the very same >test cases dropped to less than 1%. > >p.

1 0

(ITS#4717) Efficient handling of response lists in C-API
by ando＠sys-net.it 22 Oct '06

22 Oct '06

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando In proxies, we occasionally need to mark some response messages as "don't care". This is slightly different than "abandon", in the sense that, for performance and band occupation, an abandon would likely get too late to the remote server, but if the response is not removed from the list that would grow and waste resources. In realistic cases we profiled proxies that spend 50-60% of the CPU time running the list of messages to check if any of them has been abandoned. The proposed fix consists in: - keeping abandoned msgid's sorted, so that a bisection algorithm can be used to check if a msgid has been abandoned - add a ldap_int_abandon() call that marks a message as "abandoned" without actually sending an "abandon" operation. This call is, by now, private (ldap_int_) since its use in normal clients would make little sense. However, whenever it does make sense, there's no objection in making the call public (sort of ldap_abandon_mark()). With this change, the overall CPU used to check response list in the very same test cases dropped to less than 1%. p.

1 0

Re: (ITS#4716) syncrepl - consumer missed some delete
by richton＠nbcs.rutgers.edu 20 Oct '06

20 Oct '06

Are you patched for ITS#4708 and ITS#4695? Those are my current "don't try to syncrepl without it" for RE23... Is this refreshAndPersist, or refreshOnly? delta-syncrepl? Do you use a session log? Maybe just post the relevant config entirely...

1 0

Re: (ITS#4715) proxy retries anonymously
by ando＠sys-net.it 20 Oct '06

20 Oct '06

ashish(a)ratboy.net wrote: > I tried the rebind-as-user approach and that works :) > Will try out the HEAD soon. > Good. I'll rework the documentation accordingly. Cheers, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4715) proxy retries anonymously
by ashish＠ratboy.net 20 Oct '06

20 Oct '06

> I see that the connection is retried anonymously, which is incorrect. > This issue is known, and it has been fixed in HEAD code by using identity > assertion to retry non-anonymous connections. Another option would be to > set "rebind-as-user", so that user credentials are saved and used to retry > non-anonymous connections. I tried the rebind-as-user approach and that works :) Will try out the HEAD soon. Thank you. Ashish Gawarikar

1 0

Re: (ITS#4715) proxy retries anonymously
by ando＠sys-net.it 20 Oct '06

20 Oct '06

> Either you provide an all-OpenLDAP setup, consisting of proxy, remote > server and operation sequence that clearly shows the issue, so that we can > reproduce and track it, or you should rather investigate what's happening > between the proxy and the remote server, e.g. by providing a tcpdump of > the communications resulting in the error you reported. Sorry, I missed your intermediate posting with a trace of the problem (either I didn't get that message or I simply overlooked it; I've found it right now on the ITS). I see that the connection is retried anonymously, which is incorrect. This issue is known, and it has been fixed in HEAD code by using identity assertion to retry non-anonymous connections. Another option would be to set "rebind-as-user", so that user credentials are saved and used to retry non-anonymous connections. Personally, I'd prefer the idassert approach, but "rebind-as-user" could be useful in case the remote server does not support proxyAuthz, or in case your applications need to use proxyAuthz themselves. Can you try either (or both) approaches? The former requires you to build HEAD (or re24, since last night it was sync'ed with HEAD) code. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4715) proxy retries anonymously
by ando＠sys-net.it 20 Oct '06

20 Oct '06

> Attaching the relevant slapd.conf I don't think this is by any means relevant. I've run some basic checks, as I said, and nothing at the proxy side seems to be able to cause the error you report. Either you provide an all-OpenLDAP setup, consisting of proxy, remote server and operation sequence that clearly shows the issue, so that we can reproduce and track it, or you should rather investigate what's happening between the proxy and the remote server, e.g. by providing a tcpdump of the communications resulting in the error you reported. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4702) out-of-memory on huge DB ?
by Paolo.Rossi.con＠h3g.it 19 Oct '06

19 Oct '06

Hi, today I'm finally succeed to export the huge DB with the 64bit build, solaris8/sparc, shminfo_shmmax=536870912 DB_CONFIG whit set_cachesize 0 384000000 1 and using slapcat -f slapd.conf -l producer_dump.ldif FYI, here the final memory allocation and output ldif file: PID RSS VSZ %MEM TIME STIME COMMAND 10294 7491744 7497840 93.1 02:22:27 10:35:37 slapcat ls -la -rw-r--r-- 1 test other 10486259712 Oct 19 13:16 producer_dump.ldif therefore, about 7,5 GB of RAM for ca. 10 GB of ldif Any suggestion, cue? Paolo

1 0

Re: (ITS#4716) syncrepl - consumer missed some delete
by Paolo.Rossi.con＠h3g.it 19 Oct '06

19 Oct '06

I've do some other test: I've shutdown consumer (desynched), and I've do about 10000 random modify on producer, then I've set loglevel -1 on producer (due to find something wrong) and started consumer. After a night, I've restarted the cluster again (producer and consumer) setting a relaxed loglevel on producer, but this time consumer was resynched! Also the deleted DN ignored previously, are now in sych. very strange. Paolo

1 0

Re: (ITS#4715) proxy retries anonymously
by ashish＠ratboy.net 18 Oct '06

18 Oct '06

This is a multi-part message in MIME format. --------------040702090906080801050004 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Attaching the relevant slapd.conf --------------040702090906080801050004 Content-Type: text/plain; name="slapd.conf" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="slapd.conf" pidfile /var/run/ldap/slapd.pid argsfile /var/run/ldap/slapd.args # Logging is disabled by default. Enable logging when necessary. # (May significantly affect performance, depending on the level of # server activity.) # To enable logging of access, read, modify, and deletions, # set the loglevel to 256 loglevel none # disallow bind_anon gentlehup on # The sizelimit restriction controls the potential to which the directory # contents may be exploited. Directory queries can only return *this* # many responses. # #sizelimit unlimited sizelimit 200 # Limit the amount of time the server will spend performing # a single query # #timelimit unlimited timelimit 3600 allow bind_v2 ####################################################################### # SASL: ####################################################################### # # SMD is configured with SASL support for most environments. # See the provided slapd.conf man page for additional information. # ## sasl-secprops: # Used to specify Cyrus SASL security properties. The "none" value # by itself causes the default "noanonymous,noplain" to be cleared. sasl-secprops none # ## sasl-host: # Used to specify the fully qualified domain name # used for SASL processing. #sasl-host <fqdn> # ## sasl-realm: # Specify the SASL realm. Default is empty. #sasl-realm <realm> ####################################################################### # schema information ####################################################################### include /usr/local/example/smd-4.0/schema/syntax.defs include /usr/local/example/smd-4.0/schema/core.schema include /usr/local/example/smd-4.0/schema/cosine.schema include /usr/local/example/smd-4.0/schema/inetorgperson.schema include /usr/local/example/smd-4.0/schema/openldap.schema include /usr/local/example/smd-4.0/schema/nis.schema include /usr/local/example/smd-4.0/schema/messageRecipient.schema include /usr/local/example/smd-4.0/schema/smi.schema include /usr/local/example/smd-4.0/schema/sieve.schema include /usr/local/example/smd-4.0/schema/sendmail.schema # All user-customized schema additions must be made in the files # stored under /etc/mail/openldap/schema. include /etc/mail/openldap/schema/custom.schema ####################################################################### # ldap database definitions ####################################################################### database ldap lastmod off suffix "" # The proxy cache function requires that the 'rootdn' parameter is set. # Note that with the password configured below, it cannot be used to bind rootdn "cn=Manager" rootpw {SHA}example-proxycache ###################################################################### # Back-LDAP connection settings ###################################################################### # # Two settings are necessary: # A) Optional TLS settings, used with all ldap:// connections. # This setting must appear before the LDAP URI. # B) LDAP URI list, with hosts separated by spaces # # To require TLS on ldap:// connections, use "tls start" # To try TLS (but not require) on ldap:// connections, use "tls try-start" # # tls start # tls try-start # # This URI example has two LDAP replica servers to try, using ldaps and ldap #uri "ldaps://rep1.domain.com ldaps://rep2.domain.com ldap://rep1.domain.com" uri ldap://ldap.smi.example.com ###################################################################### # Proxycache settings ###################################################################### overlay pcache ########## <database> <max_entries> <numattrsets> <entry_limit> <cc_period> proxycache bdb 10000 3 1 600 proxycachequeries 10000 # Important proxycache notes: # - You may have multiple queries per cache set # - The same query can appear in multiple cache sets # - Only one proxyattrset definition may appear for any cache set # - A given attribute may only appear in one proxyattrset. # - Taking all four conditions above, if multiple queries need access # to the same attribute in their result, the queries must appear # within the same cache set. Also, the attrset for that cache set # must contain a list of all attributes returned from any of the # queries in that set. # - All attributes used in search queries must be defined in the schema. # Sendmail has pre-defined schema including the vendor-specific attributes. # - Additional application and target directory server notes appear # below the cache definitions # - An entry will be cached once for each different search query that # is being used to find it. This means that the actual number of # LDAP entries which may be cached is not the value set in MAX_ENTRIES # above, but instead is this value divided by the number of distinct # LDAP queries being used. # Cache set 0 is used for Flow Control, Authentication, LDAP routing, Proxy lookups proxyattrset 0 DN mail mailRoutingAddress mailHost imapHost popHost objectClass smiAuthDisabled # # Cache set 1 is used for distribution list expansion proxyattrset 1 mgrpRFC822MailMember objectClass # # Cache set 2 is used for Sieve lookups proxyattrset 2 messageStoreUserFilter objectClass # Set_# ttl neg-ttl # # SMD: proxytemplate (|(mailLocalAddress=)(objectClass=)) 0 900 120 proxytemplate (|(mailRoutingAddress=)(objectClass=)) 0 900 120 proxytemplate (&(objectClass=)(mailRoutingAddress=)) 1 900 120 proxytemplate (mailRoutingAddress=) 2 900 120 # # AD: proxytemplate (|(mail=)(proxyAddresses=)(userPrincipalName=)(objectClass=)) 0 900 120 # # Domino: proxytemplate (|(mail=)(uid=)(&(uid=)(mailDomain=))) 0 900 120 # # Novell: proxytemplate (mail=) 0 900 120 # # Netscape/ iPlanet / SunOne / Fedora proxytemplate (|(mail=)(mailAlternateAddress=)(objectClass=)) 0 900 120 proxytemplate (&(objectClass=)(|(mail=)(mailAlternateAddress=))) 1 900 120 proxytemplate (|(mail=)(mailAlternateAddress=)(objectClass=)) 2 900 120 ###################################################################### # BDB Settings # Proxycache uses BDB to store its local information ###################################################################### directory /var/example/ldap/smd-proxycache dbconfig set_cachesize 0 8388608 0 dbconfig set_lg_max 10485760 dbconfig set_flags db_log_autoremove dbconfig set_flags DB_TXN_NOSYNC dbconfig set_lg_bsize 2097152 cachesize 10000 idlcachesize 10100 cachefree 20 dbnosync index queryid,objectClass,mail,mailLocalAddress,mailRoutingAddress eq index uid,mailDomain,userPrincipalName,proxyAddresses,mailAlternateAddress eq ###################################################################### # TLS information, required to enable TLS and LDAPS connections ###################################################################### TLSCipherSuite ALL:!EXP:!LOW:!ADH:@STRENGTH TLSCertificateFile /etc/mail/openldap/ssl/certs/ashish.smi.example.com/default.crt TLSCertificateKeyFile /etc/mail/openldap/ssl/certs/ashish.smi.example.com/default.key --------------040702090906080801050004--

1 0

Re: (ITS#4707) patch: option to bind client socket to an address
by rtsai＠ironport.com 18 Oct '06

18 Oct '06

On Wed, Oct 18, 2006 at 12:23:03PM -0700, Kurt D. Zeilenga wrote: > At 12:12 PM 10/18/2006, hyc(a)symas.com wrote: > >rtsai(a)ironport.com wrote: > >> Full_Name: Robert Tsai > >> Version: 2.3.27 > >> OS: FreeBSD 6.1-RELEASE > >> URL: ftp://ftp.openldap.org/incoming/openldap-2.3.27-bindaddr.patch.txt > >> Submission from: (NULL) (63.251.108.100) > >> > >> This is a patch that provides a mechanism to bind the LDAP client > >> connection to a desired address via ldap_set_option(..., > >> LDAP_OPT_BINDADDR). This call saves some state which is then used > >> by ldap_int_prepare_socket to bind the socket before opening a > >> connection to the LDAP server. > > > >I can't think of any good reason to need such a feature. Can you > >give some background on why anyone would use it? > > I can see a few cases where a client might want to bind the local > address, for instance, to ensure use of a particular network > interface. Yes, this was the need addressed by the patch. The client host has two interfaces to two separate networks. We could have simply configured a host route to the LDAP server, but that would have been too coarse-grained (all traffic, instead of just the LDAP traffic). > However, my concern with patch is one of the approach taken to > accommodate this binding. I'm thinking it might be better to > provide an alternative to ldap_initialize(3) which takes a connected > descriptor instead of a URL. Then calling program can do whatever > it pleases before its used by slapd(8). That would probably work for me. Contributing from the "outside", I was hesitant to propose adding another interface into the library, so I just crammed it into ldap_set_option :). -- Robert Tsai | IronPort Systems | http://www.ironport.com/ | 650-989-2063

1 0

Re: (ITS#4707) patch: option to bind client socket to an address
by Kurt＠OpenLDAP.org 18 Oct '06

18 Oct '06

At 12:12 PM 10/18/2006, hyc(a)symas.com wrote: >rtsai(a)ironport.com wrote: >> Full_Name: Robert Tsai >> Version: 2.3.27 >> OS: FreeBSD 6.1-RELEASE >> URL: ftp://ftp.openldap.org/incoming/openldap-2.3.27-bindaddr.patch.txt >> Submission from: (NULL) (63.251.108.100) >> >> >> This is a patch that provides a mechanism to bind the LDAP client connection to >> a desired address via ldap_set_option(..., LDAP_OPT_BINDADDR). This call saves >> some state which is then used by ldap_int_prepare_socket to bind the socket >> before opening a connection to the LDAP server. > >I can't think of any good reason to need such a feature. Can you give >some background on why anyone would use it? I can see a few cases where a client might want to bind the local address, for instance, to ensure use of a particular network interface. However, my concern with patch is one of the approach taken to accommodate this binding. I'm thinking it might be better to provide an alternative to ldap_initialize(3) which takes a connected descriptor instead of a URL. Then calling program can do whatever it pleases before its used by slapd(8). -- Kurt

1 0

Re: (ITS#4715) proxy retries anonymously
by ando＠sys-net.it 18 Oct '06

18 Oct '06

hyc(a)symas.com wrote: > The proxycache has nothing to do with the connections to the remote > server. That's handled by the back-ldap or whatever backend you're > using. Since you haven't provided any of the relevant config info from > your slapd.conf there's no way to tell what you're doing there. > > In fact your log shows that a Bind was performed on the retry, but it > was done anonymously. So it may be something as simple as a missing > config keyword (like rebind-as-user in back-ldap). Or it may possibly be > related to a bug in back-ldap's retry handling as Pierangelo mentioned > in his reply to you. > > There is no proxycache bug here. At the moment, without further details, > it doesn't seem there's any OpenLDAP software bug here at all. > I've made a couple of checks with re23 making connections timeout at the remote server's side, and retry works as expected. As far as I remember, the retry issues I mentioned were essentially related to non-search ops, or to ops involving identity assertion. Unless the poster of the issue can provide a clear way to reproduce his problem, there seems to be no evidence of a bug neither in proxy cache nor in back-ldap. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4707) patch: option to bind client socket to an address
by hyc＠symas.com 18 Oct '06

18 Oct '06

rtsai(a)ironport.com wrote: > Full_Name: Robert Tsai > Version: 2.3.27 > OS: FreeBSD 6.1-RELEASE > URL: ftp://ftp.openldap.org/incoming/openldap-2.3.27-bindaddr.patch.txt > Submission from: (NULL) (63.251.108.100) > > > This is a patch that provides a mechanism to bind the LDAP client connection to > a desired address via ldap_set_option(..., LDAP_OPT_BINDADDR). This call saves > some state which is then used by ldap_int_prepare_socket to bind the socket > before opening a connection to the LDAP server. I can't think of any good reason to need such a feature. Can you give some background on why anyone would use it? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4715) proxy retries anonymously
by hyc＠symas.com 18 Oct '06

18 Oct '06

The proxycache has nothing to do with the connections to the remote server. That's handled by the back-ldap or whatever backend you're using. Since you haven't provided any of the relevant config info from your slapd.conf there's no way to tell what you're doing there. In fact your log shows that a Bind was performed on the retry, but it was done anonymously. So it may be something as simple as a missing config keyword (like rebind-as-user in back-ldap). Or it may possibly be related to a bug in back-ldap's retry handling as Pierangelo mentioned in his reply to you. There is no proxycache bug here. At the moment, without further details, it doesn't seem there's any OpenLDAP software bug here at all. Ashish Gawarikar wrote: > > ------------------------------------------------------------------------ > > The problem is that the connection to the backend server drops and the proxy > cache has to reestablish it. Doing this, it doesn't do a BIND again and thus > the query is executed with anonymous privileges and fails. See log file from > the backend server: -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4715) Proxy cache TTL does not seem to be working as documented
by hyc＠symas.com 18 Oct '06

18 Oct '06

Your log actually indicates that it attempted to re-query the remote server but got an error from the remote server. Sounds like you have other problems, unrelated to the proxycache. (Note that the pcache overlay never returns a NO_SUCH_OBJECT error code itself, that can only happen because the remote server returned that code.) ashish(a)ratboy.net wrote: > Full_Name: Ashish Gawarikar > Version: 2.3.27 > OS: Linux - 2.6 based > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (63.211.143.38) > > > Openldap 2.3.27 configured as proxy cache is behaving erratically. > > Entries being answered from the proxy cache sometimes result with a negative > result, even though the LDAP server has the information. > > It appears like the proxycache "forgets" that it has gotten the answer, but > doesn't re-query the target server to fetch the information again. > > Proxy cache returns 'no such object' for a previously found entry if the ttl > has passed between queries: > > conn=0 op=2 SRCH base="dc=mail,dc=example,dc=com" scope=2 deref=0 > filter="(mailLocalAddress=account1(a)example.com)" > conn=0 op=2 SRCH attr=maillocaladdress > request done: ld 0x83dd3b8 msgid 3 > conn=0 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=Search operation > succeeded > > <-- wait "some" time here --> > > conn=0 op=3 SRCH base="dc=mail,dc=example,dc=com" scope=2 deref=0 > filter="(mailLocalAddress=account1(a)example.com)" > conn=0 op=3 SRCH attr=maillocaladdress > conn=0 op=3 ldap_back_retry: retrying URI="ldap://ldap.example.com:389" > DN="cn=admin,dc=example,dc=com" > request done: ld 0x83dd3b8 msgid 1 > request done: ld 0x83dd3b8 msgid 2 > conn=0 op=3 SEARCH RESULT tag=101 err=32 nentries=0 text=No such object: > dc=mail,dc=example,dc=com -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4716) syncrepl - consumer missed some delete
by Paolo.Rossi.con＠h3g.it 18 Oct '06

18 Oct '06

Full_Name: Paolo Rossi Version: 2.3.27 OS: solaris 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.149.168.124) Hi, Doing stress test on syncrepl, 1 producer --> 1 consumer, I've found a strange issue: Afer load the openLDAP cluster (1m entry whit random 1,2 or 3 sub dn), I've used a script to make constant random changes on the producer. Meanwhile I've do some test & check on consumer. I've found a issue when, stopping the consumer for some minutes, whit a continuous load versus producer, restarting the consumer it resync itself but some DELETE operation of entire subDN went lost. Doing a search I've noticed on producer: dn: testid=106087406087,ou=profiles,dc=foo,dc=bar structuralObjectClass: profile entryUUID: e2543b6a-559a-1029-82d7-f1c24b7d324b creatorsName: cn=Manager,dc=foo,dc=bar modifiersName: cn=Manager,dc=foo,dc=bar createTimestamp: 20050510122923Z modifyTimestamp: 20050510122923Z entryCSN: 20050510122923Z#000017#00#000000 entryDN: testid=106087406087,ou=profiles,dc=foo,dc=bar subschemaSubentry: cn=Subschema hasSubordinates: FALSE but on consumer: dn: testid=106087406087,ou=profiles,dc=foo,dc=bar structuralObjectClass: profile entryUUID: e2543b6a-559a-1029-82d7-f1c24b7d324b creatorsName: cn=Manager,dc=foo,dc=bar modifiersName: cn=Manager,dc=foo,dc=bar createTimestamp: 20050510122923Z modifyTimestamp: 20050510122923Z entryCSN: 20050510122923Z#000017#00#000000 entryDN: testid=106087406087,ou=profiles,dc=foo,dc=bar subschemaSubentry: cn=Subschema hasSubordinates: TRUE dn: subtestID=106087406087,testid=106087406087,ou=profiles,dc=foo,dc=bar structuralObjectClass: profileAccount entryUUID: e25462d4-559a-1029-82d8-f1c24b7d324b creatorsName: cn=Manager,dc=foo,dc=bar modifiersName: cn=Manager,dc=foo,dc=bar createTimestamp: 20050510122923Z modifyTimestamp: 20050510122923Z entryCSN: 20050510122923Z#000018#00#000000 entryDN: subtestID=106087406087,testid=106087406087,ou=profiles,dc=foo,dc=bar subschemaSubentry: cn=Subschema hasSubordinates: FALSE ----- only on producer: hasSubordinates: FALSE I've "loglevel config acl sync" on consumer, but there is no log of sync operation on that dn. Also restarting the cluster, replica remain desynched on that dn. Solaris 8 sparc openLDAP 2.3.27 (64 bit build) BDB 4.2.52.5 hdb backend Paolo

1 0

(ITS#4715) Proxy cache TTL does not seem to be working as documented
by ashish＠ratboy.net 17 Oct '06

17 Oct '06

Full_Name: Ashish Gawarikar Version: 2.3.27 OS: Linux - 2.6 based URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.211.143.38) Openldap 2.3.27 configured as proxy cache is behaving erratically. Entries being answered from the proxy cache sometimes result with a negative result, even though the LDAP server has the information. It appears like the proxycache "forgets" that it has gotten the answer, but doesn't re-query the target server to fetch the information again. Proxy cache returns 'no such object' for a previously found entry if the ttl has passed between queries: conn=0 op=2 SRCH base="dc=mail,dc=example,dc=com" scope=2 deref=0 filter="(mailLocalAddress=account1(a)example.com)" conn=0 op=2 SRCH attr=maillocaladdress request done: ld 0x83dd3b8 msgid 3 conn=0 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=Search operation succeeded <-- wait "some" time here --> conn=0 op=3 SRCH base="dc=mail,dc=example,dc=com" scope=2 deref=0 filter="(mailLocalAddress=account1(a)example.com)" conn=0 op=3 SRCH attr=maillocaladdress conn=0 op=3 ldap_back_retry: retrying URI="ldap://ldap.example.com:389" DN="cn=admin,dc=example,dc=com" request done: ld 0x83dd3b8 msgid 1 request done: ld 0x83dd3b8 msgid 2 conn=0 op=3 SEARCH RESULT tag=101 err=32 nentries=0 text=No such object: dc=mail,dc=example,dc=com

1 0

(ITS#4714) 'Connection' object not throwing LDAPException upon sudden server connection loss
by alejandro.robles＠tre.se 16 Oct '06

16 Oct '06

Full_Name: Alejandro Robles Version: n/a OS: Solaris 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.182.141.229) SUMMARY This issue relates to JLDAP software package (novell-jldap-devel-2006.06.22-1unix.zip) whereby during a sudden server connection loss the Connection object doesn't through an LDAPException upon an LDAP Search operation. If this situation isn't detectec it causes the running thread to hang where retrieving results by first invoking hasMoreElements() method. DETAILS A client program of the form: 1{ 2 Connect; 3 Bind; 4 5 <being loop> 6 try {Search;} 7 catch (LDAPException) {<do something>} 8 while(hasMoreElements()) { 9 retrieve; 10 } 11 Sleep 10secs; 12 <end loop> 13 14 Unbind; 15 Disconnect; 16} If a connection loss is simulated while the program is sleeping (line 11), when the thread wakes up and invokes the Search method (line 6) is doesn't through an exception and thereafter the thread gets locked when running hasMoreElements() on the results (line 8). SOLUTION The cause of the problem is belived to be within the Connection object in the method 'writeMessage' (below extract from /com/novell/ldap/Connection.java object version 1.88): /* * IOException could be due to a server shutdown notification which * caused our Connection to quit. If so we send back a slightly * different error message. We could have checked this a little * earlier in the method but that would be an expensive check each * time we send out a message. Since this shutdown request is * going to be an infrequent occurence we check for it only when * we get an IOException. shutdown() will do the cleanup. */ if( clientActive) { // We beliefe the connection was alive if (unsolSvrShutDnNotification) { // got server shutdown throw new LDAPException( ExceptionMessages.SERVER_SHUTDOWN_REQ, new Object[] { host, new Integer(port)}, LDAPException.CONNECT_ERROR, null, ioe); } // Other I/O Exceptions on host:port are reported as is throw new LDAPException(ExceptionMessages.IO_EXCEPTION, new Object[] {host, new Integer(port)}, LDAPException.CONNECT_ERROR, null, ioe); } The fact that the Connection has been lost causes prior to issuing a search to the server to set the value of clietActive to false. The latter in turn causes that any IOExceptions within the method not be handled properly (not thrown at all) causing the mentioned problem. PROPOSED FIX To add a default Exception throwing code for the cases where 'clientActive' is false. /* * IOException could be due to a server shutdown notification which * caused our Connection to quit. If so we send back a slightly * different error message. We could have checked this a little * earlier in the method but that would be an expensive check each * time we send out a message. Since this shutdown request is * going to be an infrequent occurence we check for it only when * we get an IOException. shutdown() will do the cleanup. */ if( clientActive) { // We beliefe the connection was alive if (unsolSvrShutDnNotification) { // got server shutdown throw new LDAPException( ExceptionMessages.SERVER_SHUTDOWN_REQ, new Object[] { host, new Integer(port)}, LDAPException.CONNECT_ERROR, null, ioe); } // Other I/O Exceptions on host:port are reported as is throw new LDAPException(ExceptionMessages.IO_EXCEPTION, new Object[] {host, new Integer(port)}, LDAPException.CONNECT_ERROR, null, ioe); } else // Other I/O Exceptions on host:port are reported as is throw new LDAPException(ExceptionMessages.IO_EXCEPTION, new Object[] {host, new Integer(port)}, LDAPException.CONNECT_ERROR, null, ioe); }

1 0

Re: (ITS#4702) out-of-memory on huge DB ?
by paolo.rossi.con＠h3g.it 16 Oct '06

16 Oct '06

Another day, another try. Today I've tried the slapcat (32Bit) a 8 GB RAM solaris/sparc machine. also this time I had: core dumped ch_malloc of 16392 bytes failed ch_malloc.c:57: failed assertion `0' allocation at coredump was PID RSS VSZ %MEM TIME STIME COMMAND 29941 4164952 4168968 51.8 01:15:27 16:03:43 slapcat It seems the famous 4GB allocation limit on 32Bit build ? I will try the last shot, reloading a BD on a 64 Bit build; but seems the 32Bit build, had no hope to finish the task :( Paolo

1 0

Re: (ITS#4713) test030-relay broken in HEAD
by ando＠sys-net.it 15 Oct '06

15 Oct '06

quanah(a)stanford.edu wrote: > --On Monday, October 16, 2006 5:41 AM +0000 quanah(a)stanford.edu wrote: > > > > >> I'll see if I can get a core from it. >> > > Never mind, I found the problem in slapd.1.out: > > /usr/local/build/ldap-head-20061015/servers/slapd/.libs/lt-slapd: > relocation error: ../servers/slapd/back-meta/.libs/back_meta-2-devel.so.0: > undefined symbol: ldap_back_proxy_authz_ctrl > > > Sounds like something isn't being linked right, or something isn't declared > right in the back-meta build. > Right. Back-meta occasionally reuses stuff from back-ldap; apparently I pulled et another function from there, so it seems you need to load back_ldap.la as well to use back_meta.la. I wonder if there's any better solution (e.g. statically link back_meta.la with back_ldap.la, but then there would be duplicates when one loads both?). Too bad I don't routinely check HEAD with all-modules builds, sorry. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4713) test030-relay broken in HEAD
by quanah＠stanford.edu 15 Oct '06

15 Oct '06

--On Monday, October 16, 2006 5:41 AM +0000 quanah(a)stanford.edu wrote: > I'll see if I can get a core from it. Never mind, I found the problem in slapd.1.out: /usr/local/build/ldap-head-20061015/servers/slapd/.libs/lt-slapd: relocation error: ../servers/slapd/back-meta/.libs/back_meta-2-devel.so.0: undefined symbol: ldap_back_proxy_authz_ctrl Sounds like something isn't being linked right, or something isn't declared right in the back-meta build. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4713) test030-relay broken in HEAD
by quanah＠stanford.edu 15 Oct '06

15 Oct '06

--On Monday, October 16, 2006 5:38 AM +0000 ando(a)sys-net.it wrote: > quanah(a)stanford.edu wrote: >> When running test030-relay, I get a failure. >> > works just fine here, on Linux 32 bit and Solaris 64 bit >> Basic output shows: >> >> Using meta backend... >> >> Starting slapd on TCP/IP port 9011... >> Using ldapsearch to check that slapd is running... >> Using ldapadd to populate the database... >> Searching base="dc=example,dc=com"... >> Searching base="o=Example,c=US"... >> Search failed (255)! >> ./scripts/test030-relay: line 79: kill: (20796) - No such process >> > Sounds like slapd either stopped or crashed; anything relevant from > slapd's logs (or any core dump around)? >> The ldapsearch.out file shows: >> > snip... >> # searching base="o=Example,c=US"... >> ldap_result: Can't contact LDAP server (-1) >> > This is not much indicative of the reason of the failure; see above. > Note that Saturday 14 I made sort of a mess in HEAD with daemon.c, which > I only noticed and fixed late Sunday 15; please make sure you're using > the correct files from HEAD. It is HEAD as of now, i.e., I retrieved it this evening. ;) I'll see if I can get a core from it. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4713) test030-relay broken in HEAD
by ando＠sys-net.it 15 Oct '06

15 Oct '06

quanah(a)stanford.edu wrote: > When running test030-relay, I get a failure. > works just fine here, on Linux 32 bit and Solaris 64 bit > Basic output shows: > > Using meta backend... > > Starting slapd on TCP/IP port 9011... > Using ldapsearch to check that slapd is running... > Using ldapadd to populate the database... > Searching base="dc=example,dc=com"... > Searching base="o=Example,c=US"... > Search failed (255)! > ./scripts/test030-relay: line 79: kill: (20796) - No such process > Sounds like slapd either stopped or crashed; anything relevant from slapd's logs (or any core dump around)? > The ldapsearch.out file shows: > snip... > # searching base="o=Example,c=US"... > ldap_result: Can't contact LDAP server (-1) > This is not much indicative of the reason of the failure; see above. Note that Saturday 14 I made sort of a mess in HEAD with daemon.c, which I only noticed and fixed late Sunday 15; please make sure you're using the correct files from HEAD. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs