(ITS#4858) sasl_client_init Problem
by m.birkenkamp＠e-fact-gmbh.de
Full_Name: Marcel Birkenkamp
Version: 2.1.22
OS: HP UX 11.11
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (84.63.24.153)
Hi,
i have a Problem, i've implemented a c program using OpenLDAP to connect to an
ActiveDirectory for uservalidation, the Problem is that whenever i use one of
the OpenLDAP functions (i.e. ldap_init, ldap_initialize) i get the following
error: "/usr/lib/dld.sl: Unresolvable symbol: sasl_client_init (code) from
/opt/iexpress/openldap/lib/libldap.sl - IOT trap". I've reinstalled OpenLDAP but
the Problem persists.
Does anyone have an idea what might be causing this or how i can find out where
this Problem originates?
thanks in advance
Marcel
16 years, 8 months
(ITS#4857) Subtree accesslog support
by quanah＠stanford.edu
Full_Name: Quanah Gibson-Mount
Version: 2.3/2.4/HEAD
OS: NA
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (171.66.155.86)
I was looking at adding access log configurations to my main database that would
log operations based on subtree. For example, I'd like to have all operations
on "cn=accounts,dc=stanford,dc=edu" go into one accesslog, and operations on
"cn=people,dc=stanford,dc=edu" go into another accesslog. My root is
"dc=stanford,dc=edu". There doesn't seem to be a way with the way accesslog is
currently designed to do this. I believe it would be a useful feature.
--Quanah
16 years, 8 months
Re: slapd segfaults with certain ACL's (ITS#4854)
by ando＠sys-net.it
hjensen(a)gmx.de wrote:
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 16384 (LWP 16160)]
> 0x4043e049 in free () from /lib/libc.so.6
> (gdb) bt
> #0 0x4043e049 in free () from /lib/libc.so.6
> #1 0x40069ef8 in ber_memfree_x () from /usr/lib/liblber-2.3.so.0
> #2 0x0809d4b6 in ch_free ()
> #3 0x080be84d in str2anlist ()
> #4 0x080ab33e in parse_acl ()
> #5 0x08070c5c in config_generic ()
> #6 0x0807b0f6 in config_set_vals ()
> #7 0x0807cdd9 in read_config_file ()
> #8 0x08075d1d in config_include ()
> #9 0x0807b0f6 in config_set_vals ()
> #10 0x0807cdd9 in read_config_file ()
> #11 0x0807667b in read_config ()
> #12 0x0806ffce in main ()
OK, then it should be fixed; you can pull servers/slapd/ad.c from the
CVS under the OPENLDAP_REL_ENG_2_3 tag and rebuild. Note that this
confirms that your schema is missing either or both the offending
objectClasses mozillaAbPersonAlpha, evolutionPerson.
Please test and feedback.
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
------------------------------------------
16 years, 8 months
Re: slapd segfaults with certain ACL's (ITS#4854)
by hjensen＠gmx.de
Hello,
here the additional information:
configure command line:
./configure --prefix=/usr \
--sysconfdir=/etc \
--libexecdir=/usr/sbin \
--localstatedir=/var/openldap \
--disable-nls \
--enable-debug \
--enable-syslog \
--with-threads \
--with-tls \
--with-cyrus-sasl \
--enable-spasswd \
--enable-dynamic \
--enable-ipv6 \
--enable-modules \
--enable-crypt \
--enable-rewrite \
--enable-ldbm \
--enable-ldbm-api=berkeley \
--enable-ldbm-type=btree \
--enable-bdb \
--enable-hdb \
--enable-ldap \
--enable-meta \
--enable-monitor \
--enable-dnssrv \
--enable-null \
--enable-perl \
--with-dyngroup \
--with-proxycache \
--enable-wrappers \
--enable-slurpd \
--enable-aci \
--enable-shared
Backtrace of the segfault:
(gdb) run
Starting program: /ports/openldap/work/src/openldap-2.3.34/servers/slapd/.libs/slapd
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 16160)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 16160)]
0x4043e049 in free () from /lib/libc.so.6
(gdb) bt
#0 0x4043e049 in free () from /lib/libc.so.6
#1 0x40069ef8 in ber_memfree_x () from /usr/lib/liblber-2.3.so.0
#2 0x0809d4b6 in ch_free ()
#3 0x080be84d in str2anlist ()
#4 0x080ab33e in parse_acl ()
#5 0x08070c5c in config_generic ()
#6 0x0807b0f6 in config_set_vals ()
#7 0x0807cdd9 in read_config_file ()
#8 0x08075d1d in config_include ()
#9 0x0807b0f6 in config_set_vals ()
#10 0x0807cdd9 in read_config_file ()
#11 0x0807667b in read_config ()
#12 0x0806ffce in main ()
Regards,
Henry
16 years, 8 months
Re: (ITS#4856) Back-SQL + Subtree search hits 'assert(0)'
by ando＠sys-net.it
Kevin Vargo wrote:
> Hi Pierangelo,
Please keep replies in CC to the ITS system.
> Thanks for the quick response. I just want to make sure I understand: you're saying that removing the assertion (as I did) is the correct solution?
Well, removing the assert(0) prevents the crash; the right fix is to
disallow the "subtree shortcut" in slapd.conf (slapd-sql(5)), which
causes the extra filtering on the DN to take place, so no false hits
show up. But yes, the assert(0) was overparanoid, and I removed it from
the 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
------------------------------------------
16 years, 8 months
Re: (ITS#4856) Back-SQL + Subtree search hits 'assert(0)'
by ando＠sys-net.it
vargok(a)yahoo.com wrote:
> Full_Name: K Vargo
> Version: 2.3.32
> OS: Linux (RH-EL4)
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (128.237.233.195)
>
>
> Given a Base-DN, Subtree scoped ldapsearch, while the database contains
> non-DN-matching items runs up against the 'assert(0)' in Back-SQL/search.c
> +2186.
>
> Based on how the selection works, there doesn't appear to be a reason for the
> assertion. The FIXME does not indicate WHY the dnIsSuffix should never fail:
> the comparison in dnIsSuffix tries to compare incompatible-dn records and fails
> -- as it should.
>
> Removing the assertion provides for the expected behavior in my simple case.
> Basically, it appears that a Base-DN is not being pre-filtered by the Back-SQL
> selection search, so it needs to be filtered by the dnIsSuffix check.
>
> While I could certainly see that my metadata is not correct (stock metadata from
> 2.3 + changes from 200511/msg00504.html) I'm not sure an assert(0) is
> appropriate.
>
> Additionally, there's no indication that back-sql can't support data with
> multiple DNs.
Actually, your assumption is partially incorrect, since back-sql doesn't
do prefiltering of the DN if the search is rooted at the database's
suffix (it's called the "subtree shortcut") unless you tell it
otherwise, by using "use_subtree_shortcut no" (the docs state it's the
default; this is wrong).
I admit assert(0) there is a bit too strong, but I believe it was put
there to catch this type of problems. I think the "right" solution,
apart from fixing the docs, consists in removing the assertion.
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
------------------------------------------
16 years, 8 months
(ITS#4856) Back-SQL + Subtree search hits 'assert(0)'
by vargok＠yahoo.com
Full_Name: K Vargo
Version: 2.3.32
OS: Linux (RH-EL4)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (128.237.233.195)
Given a Base-DN, Subtree scoped ldapsearch, while the database contains
non-DN-matching items runs up against the 'assert(0)' in Back-SQL/search.c
+2186.
Based on how the selection works, there doesn't appear to be a reason for the
assertion. The FIXME does not indicate WHY the dnIsSuffix should never fail:
the comparison in dnIsSuffix tries to compare incompatible-dn records and fails
-- as it should.
Removing the assertion provides for the expected behavior in my simple case.
Basically, it appears that a Base-DN is not being pre-filtered by the Back-SQL
selection search, so it needs to be filtered by the dnIsSuffix check.
While I could certainly see that my metadata is not correct (stock metadata from
2.3 + changes from 200511/msg00504.html) I'm not sure an assert(0) is
appropriate.
Additionally, there's no indication that back-sql can't support data with
multiple DNs.
16 years, 8 months
Re: (ITS#4855) slapd crash on exit (tpool)
by gael.roualland＠oleane.net
Pierangelo Masarati a écrit :
> gael.roualland(a)oleane.net wrote:
>> Full_Name: Gaël Roualland
>> Version: 2.3.34
>> OS: Linux
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (213.56.0.199)
>
> Good catch. This is a re23-only bug; fixed, will appear in next
> release. Please test re23 out of the CVS, if you can.
It works fine with the version from CVS.
Thanks,
--
Gaël Roualland -+- gael.roualland(a)oleane.net
16 years, 8 months
Re: (ITS#4855) slapd crash on exit (tpool)
by ando＠sys-net.it
gael.roualland(a)oleane.net wrote:
> Full_Name: Gaël Roualland
> Version: 2.3.34
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (213.56.0.199)
Good catch. This is a re23-only bug; fixed, will appear in next
release. Please test re23 out of the CVS, if you can.
Thanks, 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
------------------------------------------
16 years, 8 months
Re: (ITS#4855) slapd crash on exit (tpool)
by gael.roualland＠oleane.net
Erratum : the changed line is "( ctx[i].ltk_key == NULL )" and not "(
ctx[i].ltk_key != NULL )" which is the same as the release...
--
Gaël Roualland -+- gael.roualland(a)oleane.net
16 years, 8 months
