ando(a)sys-net.it wrote:
> mccann(a)jhu.edu wrote:
>> Full_Name: William Jon McCann Version: 2.3.34 OS: URL:
>> ftp://ftp.openldap.org/incoming/ Submission from: (NULL)
>> (128.220.146.19)
>>
>>
>> It would be really helpful for openldap to ship a pkg-config (.pc)
>> file for libldap.
>>
>> http://en.wikipedia.org/wiki/Pkg-config
>
> Quoting from the above link:
>
>> When a library is installed (say from an RPM, deb or other binary
>> packaging system)
>
> OpenLDAP only distributes source code
>
>> If one installs from source, often there will be no .pc file
>> generated, and one may need to be manually written to reflect the
>> install.
>
> No comment.
>
> Having noted this, I think generating a .pc file from "make install"
> would probably do no harm and probably bring some benefit to people that
> want to use pkg-config to configure software dependent on OpenLDAP.
>
> But I guess most packagers and distributors would still either provide
> their alternate means to configure packages, or provide specific .pc
> files, thus possibly breaking configurations based on OpenLDAP's .pc file.
>
And most are still far behind and "do their own thing" anyway. Ours
would get ignored either way.
--
Kind Regards,
Gavin Henry.
OpenLDAP Engineering Team.
E ghenry(a)OpenLDAP.org
Community developed LDAP software.
http://www.openldap.org/project/
Matthew Hardin wrote:
> Thanks for the prompt response, Ando. I've put the fix into production and
> I'll let you know how it goes. This problem only surfaces every few days
> when AD doesn't respond to a bind request, so will be at least Thursday or
> Friday before I can confirm it did the trick.
FWIW, the issue you indicated could be easily reproduced by either
adding a slapo-retcode in front of the remote server with a sleep longer
than the proxy's timeout, or simply by running the remote server under
gdb, stopping at do_bind long enough to see the timeout expire. I did
the latter, and I could 100% reproduce that issue before patching, while
it disappeared after.
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
---------------------------------------
> -----Original Message-----
> From: Pierangelo Masarati [mailto:ando@sys-net.it]
> Sent: Saturday, October 13, 2007 2:19 AM
> To: mhardin(a)symas.com
> Cc: openldap-its(a)openldap.org
> Subject: Re: (ITS#5185) assertion failure in back-meta when the remote
> directory does not answer a bind request within the time allotted
>
> ando(a)sys-net.it wrote:
>
> > Does this happen when binding as the rootdn of the back-meta instance,
> > or as a regular user? If it occurs when binding as the rootdn, then I
> > think I know where the problem is. In that case, apart from me fixing
> > the problem (working at it...), you should also use
> > "pseudoroot-bind-defer yes".
>
> I partially take it back: the above recommendation is correct; however,
> the problem I suspected for the rootdn case is also present for regular
> binds. I've committed to HEAD a fix for this problem. Please test.
Thanks for the prompt response, Ando. I've put the fix into production and
I'll let you know how it goes. This problem only surfaces every few days
when AD doesn't respond to a bind request, so will be at least Thursday or
Friday before I can confirm it did the trick.
I've also taken your advice and set pseudoroot-bind-defer yes.
Thanks,
-Matt
Matthew Hardin
Symas Corporation- The LDAP Guys
http://www.symas.com
> 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
> ---------------------------------------
Magnus.Jonsson(a)umdac.umu.se wrote:
> Full_Name: Magnus Jonsson
> Version: 2.3.38
> OS: Debian GNU/linux ”Etch”
> URL: http://foo.fot.nu/reproduce.txt
> Submission from: (NULL) (130.239.200.171)
>
>
> We are using ;x- attributes in a specific appliation to group some attributes.
>
> When removing a ;x- attrbute all the indexs for that attribute disapears.
>
> example:
>
> cn: index
> cn;x-f-1: index
> cn;x-f-2: index
>
> If a remove the cn;x-f-1 attribute I can't search for (cn=index) anymore.
I confirm your report, except that if the type and all subtypes have the
same value, and if I remove the "cn;x-f-1" value, I can no longer search
for "cn" equality, but I can still search for "cn;x-f-2".
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
---------------------------------------
mccann(a)jhu.edu wrote:
> Full_Name: William Jon McCann Version: 2.3.34 OS: URL:
> ftp://ftp.openldap.org/incoming/ Submission from: (NULL)
> (128.220.146.19)
>
>
> It would be really helpful for openldap to ship a pkg-config (.pc)
> file for libldap.
>
> http://en.wikipedia.org/wiki/Pkg-config
Quoting from the above link:
> When a library is installed (say from an RPM, deb or other binary
> packaging system)
OpenLDAP only distributes source code
> If one installs from source, often there will be no .pc file
> generated, and one may need to be manually written to reflect the
> install.
No comment.
Having noted this, I think generating a .pc file from "make install"
would probably do no harm and probably bring some benefit to people that
want to use pkg-config to configure software dependent on OpenLDAP.
But I guess most packagers and distributors would still either provide
their alternate means to configure packages, or provide specific .pc
files, thus possibly breaking configurations based on OpenLDAP's .pc file.
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
---------------------------------------
ando(a)sys-net.it wrote:
> Does this happen when binding as the rootdn of the back-meta instance,
> or as a regular user? If it occurs when binding as the rootdn, then I
> think I know where the problem is. In that case, apart from me fixing
> the problem (working at it...), you should also use
> "pseudoroot-bind-defer yes".
I partially take it back: the above recommendation is correct; however,
the problem I suspected for the rootdn case is also present for regular
binds. I've committed to HEAD a fix for this problem. Please test.
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
---------------------------------------
mhardin(a)symas.com wrote:
> Remote directory servers that do not answer a bind request within the timeout
> period will cause an assertion failure in back-meta.
>
> Analysis:
> The meta_back_bind() function calls either meta_back_proxy_authz_bind() if the
> bind is taking place with back_meta's rootdn or meta_back_single_bind() if it's
> not.
>
> Once they make the appropriate bind function call, each of these functions calls
> meta_back_bind_op_result() to process the result of the bind. Neither
> meta_back_proxy_authz_bind() or meta_back_single_bind() set the
> LDAP_BACK_CONN_BINDING state.
Because it's meta_back_getconn() that's supposed to set that flag when
appropriate.
> When meta_back_bind_op_result() calls ldap_result(), one of the possible return
> codes is 0, and meta_back_bind_op_result() will repeat the ldap_result() call,
> provided the timeout hasn't been exceeded or back-meta has been told not to
> retry.
>
> If the wait time has been exceeded the code falls through to an
> assert(LDAP_BACK_CONN_BINDING(msc)) statement. This assert is only valid when
> meta_back_do_bind() has made the function call, and it will fail if either
> meta_back_proxy_authz_bind() or meta_back_single_bind() made the function call.
The assert **should** always be valid. Its execution indicates that
there's an error somewhere else.
Does this happen when binding as the rootdn of the back-meta instance,
or as a regular user? If it occurs when binding as the rootdn, then I
think I know where the problem is. In that case, apart from me fixing
the problem (working at it...), you should also use
"pseudoroot-bind-defer 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
---------------------------------------
Full_Name: Matthew Hardin
Version: 2.3.38
OS: RHEL4
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (74.38.114.43)
Remote directory servers that do not answer a bind request within the timeout
period will cause an assertion failure in back-meta.
Analysis:
The meta_back_bind() function calls either meta_back_proxy_authz_bind() if the
bind is taking place with back_meta's rootdn or meta_back_single_bind() if it's
not.
Once they make the appropriate bind function call, each of these functions calls
meta_back_bind_op_result() to process the result of the bind. Neither
meta_back_proxy_authz_bind() or meta_back_single_bind() set the
LDAP_BACK_CONN_BINDING state.
When meta_back_bind_op_result() calls ldap_result(), one of the possible return
codes is 0, and meta_back_bind_op_result() will repeat the ldap_result() call,
provided the timeout hasn't been exceeded or back-meta has been told not to
retry.
If the wait time has been exceeded the code falls through to an
assert(LDAP_BACK_CONN_BINDING(msc)) statement. This assert is only valid when
meta_back_do_bind() has made the function call, and it will fail if either
meta_back_proxy_authz_bind() or meta_back_single_bind() made the function call.
Possible Fixes:
The correct fix would seem to be to remove the assert(), since in two out of
three cases the meta_back_bind_op_result() function is being called with the
LDAP_BACK_CONN_BINDING state not set.
It is also possible to set and clear the LDAP_BACK_CONN_BINDING state as
appropriate from the other two funcions that call it, but this seems incorrect,
as the LDAP_BACK_CONN_BINDING state is only manipulated in the
meta_back_single_dobind() direct bind function.
--On Thursday, October 11, 2007 12:37 PM +0000 Magnus.Jonsson(a)umdac.umu.se
wrote:
> Full_Name: Magnus Jonsson
> Version: 2.3.38
> OS: Debian GNU/linux ?Etch?
> URL: http://foo.fot.nu/reproduce.txt
> Submission from: (NULL) (130.239.200.171)
>
>
> We are using ;x- attributes in a specific appliation to group some
> attributes.
>
> When removing a ;x- attrbute all the indexs for that attribute disapears.
>
> example:
>
> cn: index
> cn;x-f-1: index
> cn;x-f-2: index
>
> If a remove the cn;x-f-1 attribute I can't search for (cn=index) anymore.
>
> I have tested with bdb and ldbm.
>
> Berkeley v4.3 is used.
Did you fail to note how OpenLDAP's configure specifically is designed to
abort when building against BDB 4.3? BDB 4.3 is known to be a bad release.
I suggest using 4.2.52+patchs, 4.4+patches, or 4.5+patches. Not that this
necessarily will resolve the issue you are reporting.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration