(ITS#4933) syncrepl unlimited timeout vs. .ldaprc
by donn＠u.washington.edu
Full_Name: Donn Cave
Version: 2.4.4
OS: Red Hat RHEL 3
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (128.95.135.150)
Appears to me that unless timelimit value passed to ldap_search_ext() is
positive, the ld_timelimit from .ldaprc overrides, so there's no way for
syncrepl ldap_sync_search() to literally specify "unlimited".
To duplicate: configure syncrepl timelimit=unlimited; edit /.ldaprc ->
"TIMELIMIT 23"; start replica slapd with a sufficiently large replication
backlog; observe timeout at 23 seconds.
To kludge: use extravagantly large value instead: if (si->si_tlimit > 0)
timeout.tv_sec = si->tlimit; else timeout.tv_sec = 31536000;
and pass &timeout unconditionally.
16 years, 5 months
Re: (ITS#4922)
by ando＠sys-net.it
Juri Tanganelli wrote:
> After further debugging i found the following behaviour:
>
> The entry has the uid attribute correctly initialized: uid S287384.
Then it should have a corresponding normalized value "s287384" (note the
lowercase "s") in the a_nvals array of bervals of the Attribute
strycture where it's stored. If it doesn't (e.g. because the attribute
was created incorrectly by your custom backend) then the behavior you
see makes perfectly sense, and is not indicative of a software bug in
OpenLDAP software.
p.
> If the uid starts with a capital letter then using these two filters:
>
> (uid=S287384) or (uid=s287384) doesn't return any result.
>
> If the uid attribute starts with a lower case letter ( i.e. uid=s287384
> ) then both filters work and return the entry.
> The definition of the uid attribute is embodied in openldap source code
> and from what i have seen it should be treated as a case insensitive
> attribute. How to explain this behaviour??
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
---------------------------------------
16 years, 5 months
Re: (ITS#4932) Core dump caused in ldap_extended_operation()
by h.b.furuseth＠usit.uio.no
rguerrero(a)datamirror.com writes:
> ldap_extended_operation(ld = (nil), reqoid = "1.3.6.1.4.1.1466.20037", reqdata = (nil), sctrls = (nil), cctrls = ??, msgidp = 0x2ff18cd4), line 62 in "extended.c"
> ldap_start_tls(ld = ??, serverctrls = ??, clientctrls = ??, msgidp = ??), line 1859 in "tls.c"
> do_start_tls(session = 0xf027b7f0), line 1343 in "ldap-nss.c"
Looks like an ldap-nss.c problem to me, not an OpenLDAP problem.
An uninitialized (or destroyed but not zeroed) LDAP*, perhaps?
Look at the value of *session, in particular session->ls_conn,
in the do_start_tls() frame.
--
Regards,
Hallvard
16 years, 5 months
(ITS#4922)
by juritanganelli＠gmail.com
------=_Part_125517_21113365.1176969864256
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
After further debugging i found the following behaviour:
The entry has the uid attribute correctly initialized: uid S287384.
If the uid starts with a capital letter then using these two filters:
(uid=S287384) or (uid=s287384) doesn't return any result.
If the uid attribute starts with a lower case letter ( i.e. uid=s287384 )
then both filters work and return the entry.
The definition of the uid attribute is embodied in openldap source code and
from what i have seen it should be treated as a case insensitive attribute.
How to explain this behaviour??
Best Regards,
Juri.
------=_Part_125517_21113365.1176969864256
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<div>After further debugging i found the following behaviour:</div>
<div> </div>
<div>The entry has the uid attribute correctly initialized: uid S287384.</div>
<div> </div>
<div>If the uid starts with a capital letter then using these two filters:</div>
<div> </div>
<div>(uid=S287384) or (uid=s287384) doesn't return any result.</div>
<div> </div>
<div>If the uid attribute starts with a lower case letter ( i.e. uid=s287384 ) then both filters work and return the entry.</div>
<div>The definition of the uid attribute is embodied in openldap source code and from what i have seen it should be treated as a case insensitive attribute. How to explain this behaviour??</div>
<div> </div>
<div>Best Regards,</div>
<div>Juri.</div>
------=_Part_125517_21113365.1176969864256--
16 years, 5 months
(ITS#4932) Core dump caused in ldap_extended_operation()
by rguerrero＠datamirror.com
Full_Name: Ron Guerrero
Version: 2.3.27
OS: AIX 5.3
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (64.201.167.139)
We've got an application that indirectly calls OpenLDAP APIs. One function in
particular is causing our process to core dump. The stack trace generated by
dbx is as follows:
0xd0128470 (pthread_kill+0x88) 80410014 lwz r2,0x14(r1)
pthread_kill(??, ??) at 0xd0128470
_p_raise(??) at 0xd0127f08
raise.raise(??) at 0xd0315740
abort.abort() at 0xd0344cb0
__assert_c99(??, ??, ??, ??) at 0xd03aede0
ldap_extended_operation(ld = (nil), reqoid = "1.3.6.1.4.1.1466.20037", reqdata =
(nil), sctrls = (nil), cctrls = ??, msgidp = 0x2ff18cd4), line 62 in
"extended.c"
ldap_start_tls(ld = ??, serverctrls = ??, clientctrls = ??, msgidp = ??), line
1859 in "tls.c"
do_start_tls(session = 0xf027b7f0), line 1343 in "ldap-nss.c"
unnamed block in do_with_reconnect(base = "dc=gwl,dc=com", scope = 2, filter =
"(&(objectClass=posixAccount)(uidNumber=138056))", attrs = 0xf027d5a8, sizelimit
= 1, private = 0x2ff19658, search_func = 0xf027b9a0), line 1530 in "ldap-nss.c"
unnamed block in do_with_reconnect(base = "dc=gwl,dc=com", scope = 2, filter =
"(&(objectClass=posixAccount)(uidNumber=138056))", attrs = 0xf027d5a8, sizelimit
= 1, private = 0x2ff19658, search_func = 0xf027b9a0), line 1530 in "ldap-nss.c"
unnamed block in do_with_reconnect(base = "dc=gwl,dc=com", scope = 2, filter =
"(&(objectClass=posixAccount)(uidNumber=138056))", attrs = 0xf027d5a8, sizelimit
= 1, private = 0x2ff19658, search_func = 0xf027b9a0), line 1530 in "ldap-nss.c"
do_with_reconnect(base = "dc=gwl,dc=com", scope = 2, filter =
"(&(objectClass=posixAccount)(uidNumber=138056))", attrs = 0xf027d5a8, sizelimit
= 1, private = 0x2ff19658, search_func = 0xf027b9a0), line 1530 in "ldap-nss.c"
_nss_ldap_search_s(args = 0x2ff196c8, filterprot =
"(&(objectClass=posixAccount)(uidNumber=%d))", sel = LM_PASSWD, user_attrs =
(nil), sizelimit = 1, res = 0x2ff19658), line 3047 in "ldap-nss.c"
_nss_ldap_getbyname(args = 0x2ff196c8, result = 0x20131698, buffer = "", buflen
= 1024, errnop = 0x2ff22ff8, filterprot =
"(&(objectClass=posixAccount)(uidNumber=%d))", sel = LM_PASSWD, parser =
0xf027b97c), line 3394 in "ldap-nss.c"
ldap-pwd.pw_byuid(this = ??, uid = ??), line 55 in "irs-pwd.c"
_nss_ldap_getpwuid(uid = 138056), line 181 in "aix_authmeth.c"
_getpwuid_shadow_r(??, ??, ??, ??, ??) at 0xd03d0900
_posix_getpwuid_shadow_r(??, ??, ??, ??, ??, ??) at 0xd03d02cc
sniq.getpwuid_r(??, ??, ??, ??, ??) at 0xd249170c
snigun(??, ??, ??) at 0xd2491648
nigconcbs(??, ??, ??) at 0xd28cc858
osncon(0x0, 0x0, 0x1803, 0x201090ec, 0x20105bec, 0x20105be4, 0x20105b70,
0x20105c20) at 0xd28cce6c
kpuadef(??, ??, ??, ??, ??, ??, ??, ??) at 0xd1d0d1b4
upiini(0x0, 0x0, 0x0, 0x0, 0x200eda80, 0x200edca0, 0x200edef4, 0x2010fe40) at
0xd20f24d4
upiah0(??, ??, ??, ??, ??, ??, ??) at 0xd20efce4
kpuatch(??, ??, ??, ??, ??, ??, ??) at 0xd1d378fc
OCIServerAttach(??, ??, ??, ??, ??) at 0xd20fbfb0
As you can see application makes a call to an Oracle API.
Has anyone seen this issue before? Notice in ldap_start_tls() the first
parameter, the ldap handle, is non-null. However, in ldap_extended_operation(),
the ldap handle is null. Looking at the code, ldap_start_tls() is calling
ldap_extended_operation() with the same ldap handle that was passed to it.
The latest source files for extended.c and tls.c have not changed since the
2.3.27 release.
16 years, 5 months
Re: (ITS#4924) assertion failure during test039-glue-ldap-concurrency
by rhafer＠suse.de
This seems really to be an PPC specific kernel (or glibc) issue. I think I was
able to create an isolated testcase to reproduce that problem outside of the
OpenLDAP libraries. I'll now bug our kernel guys with it.
But removing the assert(0) from request.c was still the right thing as
Hallvard already mentioned in his first reply.
--
Ralf
16 years, 5 months
Re: (ITS#4931) To integrate Open LDAP with Jetspeed2
by quanah＠stanford.edu
--On Wednesday, April 18, 2007 1:57 PM +0000 vaibhav(a)omnimessaging.com
wrote:
> Full_Name:
> Version: openldap-2.2.13-2
> OS: redhat linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (210.211.142.177)
>
>
> How to use OPENLDAP with jetspeed2 ?
>
> please guide me.
> Also please let me know how to check if ldap is working with jetspeed.
>
> I installed LDAP with BDB also can see all entires in LDAP -Browser.
> Bis issue is how to use LDAP with Jetspeed2 for auth.
Hello,
The OpenLDAP ITS system is for reporting bugs, not for asking usage
questions. If you have questions specific to the OpenLDAP software, please
use the "openldap-software(a)openldap.org" mailing list.
On a side note, you may need to contact RedHat for support if you run into
issues with the openldap release you are using, as it is significantly out
of date.
Regards,
Quanah
--
Quanah Gibson-Mount
Senior Systems Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
16 years, 5 months
(ITS#4931) To integrate Open LDAP with Jetspeed2
by vaibhav＠omnimessaging.com
Full_Name:
Version: openldap-2.2.13-2
OS: redhat linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (210.211.142.177)
How to use OPENLDAP with jetspeed2 ?
please guide me.
Also please let me know how to check if ldap is working with jetspeed.
I installed LDAP with BDB also can see all entires in LDAP -Browser.
Bis issue is how to use LDAP with Jetspeed2 for auth.
regards
VAibhav KAle
16 years, 5 months
(ITS#4930) slaptest should be quiet on success
by jsafranek＠redhat.com
Full_Name: Jan Safranek
Version: 2.3.35
OS: Linux (Fedora 6)
URL:
Submission from: (NULL) (62.40.79.66)
The 'slaptest' tool is a bit verbose, it sends 'config file testing succeeded'
to stderr. IMHO it should do not output anything, especially to stderr, if
everything is all right.
Here is a small patch, causing the slaptest to display the aforementioned
message only if -v switch is used:
Index: servers/slapd/slaptest.c
===================================================================
RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/slaptest.c,v
retrieving revision 1.9
diff -r1.9 slaptest.c
107c107,108
< fprintf( stderr, "config file testing succeeded\n");
---
> if (verbose)
> fprintf( stderr, "config file testing succeeded\n");
16 years, 5 months
(ITS#4929) Contriware Tool to create backsql metadata and tables
by takyin＠hotmail.com
Full_Name: Paul
Version: 2..3.34
OS: FC6
URL: ftp://ftp.openldap.org/incoming/paul-070417.tar.gz
Submission from: (NULL) (219.79.33.240)
Dear Sir/Madam,
I am interested to contribute my work on a tool that help backsql to work with
MYSQL 5.0.
It will create all tables, functions and metadata in sql command that can fit
into MYSQL ver 5.0
=============================================
Some brief information about the tool
=============================================
It is a php program with web interface, user can select which schema they want
and create
the resultant sql command. It should work with openldap 2.3.34 .
Yours Paul
16 years, 5 months
