Re: (ITS#4927) pam_authenticate through ldap causes cups to crash
by quanah@stanford.edu
--On Monday, April 16, 2007 6:31 PM +0000 ryan(a)stat.Berkeley.EDU wrote:
> On Fri, Apr 13, 2007 at 11:29:39PM +0200, Hallvard B Furuseth wrote:
>> hyc(a)symas.com writes:
>> > 3) if you can reproduce this issue with an unstripped set of OpenLDAP
>> > libraries that would make the backtrace more useful.
>>
>> ...which I think you build with
>> env ac_cv_prog_STRIP=":" ./configure ...
>
> I tried ac_cv_proj_STRIP as well as STRIP, but the Makefiles were still
> prepared with "STRIP = -s" which then leads to "install -s". I found this:
>
> http://www.openldap.org/lists/openldap-bugs/200604/msg00123.html
>
> I edited build/top.mk and removed the '-s' from STRIP and the configure
> stage prepared Makefiles with "STRIP = ".
You can always just run:
make install STRIP=""
or
rather than hacking the makefiles.
--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
Re: (ITS#4927) pam_authenticate through ldap causes cups to crash
by ryan@stat.Berkeley.EDU
On Fri, Apr 13, 2007 at 11:29:39PM +0200, Hallvard B Furuseth wrote:
> hyc(a)symas.com writes:
> > 3) if you can reproduce this issue with an unstripped set of OpenLDAP
> > libraries that would make the backtrace more useful.
>
> ...which I think you build with
> env ac_cv_prog_STRIP=":" ./configure ...
I tried ac_cv_proj_STRIP as well as STRIP, but the Makefiles were still
prepared with "STRIP = -s" which then leads to "install -s". I found this:
http://www.openldap.org/lists/openldap-bugs/200604/msg00123.html
I edited build/top.mk and removed the '-s' from STRIP and the configure
stage prepared Makefiles with "STRIP = ".
But the original issue has been resolved due to a local build issue.
Thanks!
Ryan
16 years, 5 months
Re: (ITS#4927) pam_authenticate through ldap causes cups to crash
by ryan@stat.Berkeley.EDU
On Fri, Apr 13, 2007 at 02:10:19PM -0700, Howard Chu wrote:
> >cups 1.2.10 invokes pam_authenticate which on my system goes through ldap.
> >When
> >cups tries to authenticate it is dumping core. The backtrace seems to show
> >that
> >it is crashing within the OpenLDAP code. I'm using the PADL libraries, not
> >the
> >native Solaris libraries.
>
> A few things:
> 1) This is most likely going to be an nss_ldap issue.
> 2) please provide the output for "info shared" in gdb.
> 3) if you can reproduce this issue with an unstripped set of OpenLDAP
> libraries that would make the backtrace more useful.
Thanks for your feedback. Your second tip, running "info shared", showed
that cups was linking against 2 different LDAP libraries, the one I intended
and the one in /opt/SFW/. Once I fixed the build everything worked just
fine.
This issue can be closed.
Ryan
16 years, 5 months
Problème with SASL/DIGEST-MD5 authentication
by Abdelmjid HALLOUM
hi,
i am a beginer with OpenLDAP, i installed it in my mchine ubuntu 6
but when i the problem is :
root # ldapadd ............................)
SASL/DIGEST-MD5 authentication started
Please enter your password:
ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80)
additional info: SASL(-13): user not found: no secret in database
anyhelp?
16 years, 5 months
Re: (ITS#4928) LDAP Error 0x34=LDAP_UNAVAILABLE
by hyc@symas.com
imtiazpk82(a)gmail.com wrote:
> Full_Name: Imtiaz Khadim
> Version: 3
> OS: Window server 2000
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (202.38.48.230)
>
>
> Hi,
>
> I am using Sun Iplanet Directory Server 5.2
That's your first problem.
Nothing in this report has anything to do with OpenLDAP Software. I
suggest you contact Sun for assistance, or upgrade from the Sun server
to a current OpenLDAP release. This ITS will be closed.
> and LDAP Version 3.0 to fetch
> records. The Problem currently i am facing is as follow
>
> I have made three conection to Iplanet Directory with same authentication level.
> Each connection apply diferent filter and fetch records.
> First rule fetch 15000 records.
> and 2nd and third fetch 700 record each and this schedule is to be run on every
> day.
> First time it fetch records correctly but when on next day it ran again 2nd and
> third filter run correctly but when first filter is applied the API
> ldap_search_s() return error code 0x34. Why this happen? the other two are
> working fine and these three connections are part of one application. Can any
> one help me out please.
>
> reagrds
> Imtiaz Khadim
>
>
> .
>
--
-- 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/
16 years, 5 months
(ITS#4928) LDAP Error 0x34=LDAP_UNAVAILABLE
by imtiazpk82@gmail.com
Full_Name: Imtiaz Khadim
Version: 3
OS: Window server 2000
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (202.38.48.230)
Hi,
I am using Sun Iplanet Directory Server 5.2 and LDAP Version 3.0 to fetch
records. The Problem currently i am facing is as follow
I have made three conection to Iplanet Directory with same authentication level.
Each connection apply diferent filter and fetch records.
First rule fetch 15000 records.
and 2nd and third fetch 700 record each and this schedule is to be run on every
day.
First time it fetch records correctly but when on next day it ran again 2nd and
third filter run correctly but when first filter is applied the API
ldap_search_s() return error code 0x34. Why this happen? the other two are
working fine and these three connections are part of one application. Can any
one help me out please.
reagrds
Imtiaz Khadim
16 years, 5 months
Re: (ITS#4922) test_filter problem on uid filter
by ando@sys-net.it
Please post replies to the ITS system.
Juri Tanganelli wrote:
> The entry e497004 is a candidate for sure
My point is: it's clear that if you filter for (uid=e497004) the
corresponding entry must be selected as candidate. But does it actually
get selected, and does test_filter() get applied to it? I understand
it's obvious, but the typical bug with things that have always worked is
that one believes they don't work while the point is that they don't get
used as one expects. You should check this.
> : a filter on a different
> attribute
> of the same entry returns the correct result. I can provide you with any
> information you need for an analysis of the problem (stack trace, variable
> dumps, etc...).
> What kind of information do you want me to produce?
Well, you should check that when searching for (uid=e497004)
test_filter() gets invoked and the entry passed to it contains the
attribute "uid" with the value "e497004". To do this, you should run
slapd within a debugger, set a breakpoint at test_filter() and, as soon
as the function is entered, check the contents of e->e_attrs down the
list until you find the "uid" attribute.
If the attribute is there with the requested value, and it is searchable
(ACL), test_filter() must succeed (return LDAP_COMPARE_TRUE).
So you need to check:
- the presence of "uid"
- the presence of the desired value
- the access privileges of the identity that runs the request
It might be that test_filter() returns LDAP_COMPARE_TRUE but the result
is handled incorrectly by your custom backend, or by the frontend based
on the way the result is passed back to it. By stepping through the
whole operation you should be able to detect what goes wrong.
If you find out that the error is in test_filter(), we'll be happy of
fixing it, of course.
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
---------------------------------------
16 years, 5 months
Re: (ITS#4927) pam_authenticate through ldap causes cups to crash
by h.b.furuseth@usit.uio.no
hyc(a)symas.com writes:
> 3) if you can reproduce this issue with an unstripped set of OpenLDAP
> libraries that would make the backtrace more useful.
...which I think you build with
env ac_cv_prog_STRIP=":" ./configure ...
--
Regards,
Hallvard
16 years, 5 months
Re: (ITS#4927) pam_authenticate through ldap causes cups to crash
by hyc@symas.com
ryan(a)stat.berkeley.edu wrote:
> Full_Name: Ryan Lovett
> Version: 2.3.32
> OS: Solaris 10
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (128.32.135.6)
>
>
> cups 1.2.10 invokes pam_authenticate which on my system goes through ldap. When
> cups tries to authenticate it is dumping core. The backtrace seems to show that
> it is crashing within the OpenLDAP code. I'm using the PADL libraries, not the
> native Solaris libraries.
A few things:
1) This is most likely going to be an nss_ldap issue.
2) please provide the output for "info shared" in gdb.
3) if you can reproduce this issue with an unstripped set of OpenLDAP
libraries that would make the backtrace more useful.
--
-- 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/
16 years, 5 months