Re: (ITS#5374) accesslog+hdb crash with test043-delta-syncrepl
by quanah＠zimbra.com
--On February 12, 2008 12:11:50 PM +0000 h.b.furuseth(a)usit.uio.no wrote:
> Full_Name: Hallvard B Furuseth
> Version: RE23
> OS: Linux
> URL:
> Submission from: (NULL) (129.240.6.233)
> Submitted by: hallvard
>
>
> /configure \
> --disable-dynamic --disable-aci --enable-crypt --enable-lmpasswd \
> --enable-spasswd --enable-rlookups --enable-slapi --enable-wrappers \
> --enable-backends --disable-sql --enable-overlays \
> CPPFLAGS='-DLDAP_THREAD_DEBUG -DLDAP_RDWR_DEBUG'
I built as:
LD_LIBRARY_PATH="/usr/local/lib" CC=gcc CXX=g++ CFLAGS='-g -O0'
CXXFLAGS='-g -O0' CPPFLAGS='-DLDAP_THREAD_DEBUG -DLDAP_RDWR_DEBUG' sh
configure --datadir='${prefix}/lib' --libexecdir='${prefix}/lib'
--sharedstatedir='${prefix}/lib' --prefix=/usr/local
--disable-ipv6 --with-cyrus-sasl --with-tls
--enable-dynamic --enable-slapd --enable-modules
--enable-spasswd --enable-rewrite
--enable-rlookups --enable-wrappers
--enable-backends=mod --disable-shell
--disable-sql --enable-overlays=mod --enable-slapi=yes
Thread package selected is:
-pthread
s,@LTHREAD_LIBS@, -pthread,;t t
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
14 years, 3 months
Re: (ITS#5375) Slapd core dumps
by quanah＠zimbra.com
--On February 12, 2008 2:58:12 PM +0000 ecip(a)gmv.es wrote:
> Full_Name: Eduardo Izaguirre Pazos
> Version: 2.4.7
> OS: Solaris 10
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (212.0.110.2)
>
>
> Hi all, we are using Openldap as a metadirectory against a couple of AD
> servers. The slapd server core dumps when a request of all attributes of
> one entry is issued. This is the output of the slapd server using the
> debug level -1:
Hi Eduardo,
Please test with the current CVS of REL_ENG_2_4. Please build without
optimization, and with debugging symbols. Make sure you don't strip slapd
on install. If you can repeat this with current CVS, please provide a gdb
backtrace of the non-optimized, non-stripped slapd.
Thanks,
Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
14 years, 3 months
Re: (ITS#5373) ppolicy issues when deleting the password attribute, even if no password checking is enforced
by quanah＠zimbra.com
This sounds like a duplicate of ITS#5285 to me. Which will be fixed in
2.4.8, but is not being fixed in 2.3.
--Quanah
--On February 12, 2008 9:57:46 AM +0000 Guillaume.Rousse(a)inria.fr wrote:
> Full_Name: Guillaume Rousse
> Version: 2.3.40
> OS: linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (193.55.250.67)
>
>
> Here are my ppolicy settings:
> password policy
> overlay ppolicy
> ppolicy_use_lockout
> ppolicy_default cn=default,ou=policies,dc=futurs,dc=inria,dc=fr
>
> Here is my default entry:
> dn: cn=default,ou=policies,dc=futurs,dc=inria,dc=fr
> cn: default
> objectClass: pwdPolicy
> objectClass: organizationalRole
> pwdAttribute: userPassword
> pwdMaxAge: 0
> pwdInHistory: 0
> pwdCheckQuality: 0
>
> According to documentation, no user password quality checking should take
> places, however, trying to delete userPassword attribute for an user
> triggers at least a server error with this LDIF fragment:
> dn: userdn
> changetype: modify
> delete: userPassword
>
> ldapmodify: Internal (implementation specific) error (80)
> additional info: Internal Error
>
> Error message in logs: "cannot locate modification supplying new password"
>
> Or worst, a server crash with this one:
> dn: userdn
> changetype: modify
> replace: userPassword
>
> No error message from ldapmodify, and no error message in the logs in
> this case.
>
>
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
14 years, 3 months
(ITS#5375) Slapd core dumps
by ecip＠gmv.es
Full_Name: Eduardo Izaguirre Pazos
Version: 2.4.7
OS: Solaris 10
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (212.0.110.2)
Hi all, we are using Openldap as a metadirectory against a couple of AD servers.
The slapd server core dumps when a request of all attributes of one entry is
issued. This is the output of the slapd server using the debug level -1:
/opt/openldap-2.4.7/libexec/slapd -d -1 -f
/opt/openldap-2.4.7/etc/openldap/slapd.conf -h "ldap://172.22.2.43/"
and the output is:
<<< dnPretty: <cn=Eduardo Izaguirre Pazos,ou=SISTEMAS,ou=people,dc=gmv,dc=es>
Assertion failed: ( nvals == NULL && (*a)->a_nvals == (*a)->a_vals ) || ( nvals
!= NULL && ( ( (*a)->a_vals == NULL && (*a)->a_nvals == NULL ) || (
(*a)->a_nvals != (*a)->a_vals ) ) ), file attr.c, line 480
The server wa compiled with the following configure:
./configure --prefix=/opt/openldap-2.4.7 --enable-cleartext --enable-crypt
--enable-lmpasswd --enable-rewrite --enable-bdb --enable-ldap --enable-meta
--with-tls --enable-proxycache --enable-rwm
Cheers and thanks in advance.
Eduardo
14 years, 3 months
(ITS#5374) accesslog+hdb crash with test043-delta-syncrepl
by h.b.furuseth＠usit.uio.no
Full_Name: Hallvard B Furuseth
Version: RE23
OS: Linux
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
/configure \
--disable-dynamic --disable-aci --enable-crypt --enable-lmpasswd \
--enable-spasswd --enable-rlookups --enable-slapi --enable-wrappers \
--enable-backends --disable-sql --enable-overlays \
CPPFLAGS='-DLDAP_THREAD_DEBUG -DLDAP_RDWR_DEBUG'
./run -b hdb test043-delta-syncrepl
server 1 crashes at accesslog.c line 918, which unlocks &li->li_op_mutex
when it is owned by another thread.
(Can also check it by setting li_unlock = (int) ldap_pvt_thread_self()
instead of 1 after lock, and assert()ing the same before unlock.)
accesslog_op_mod() has a comment
/* FIXME: this needs to be a recursive mutex to allow
* overlays like refint to keep working.
*/
ldap_pvt_thread_mutex_lock( &li->li_op_mutex );
but this problem is not recursive use of the mutex.
(gdb) thread apply all backtrace
Thread 4 (process 10963):
#0 0x007e87a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x00a64297 in pthread_join () from /lib/tls/libpthread.so.0
#2 0x081f0f62 in ldap_int_thread_join (thread=20061088, thread_return=0x0)
at thr_posix.c:193
#3 0x081c3de4 in ldap_pvt_thread_join (thread=20061088, thread_return=0x0)
at thr_debug.c:612
#4 0x0807bb54 in slapd_daemon () at daemon.c:2579
#5 0x08066554 in main (argc=8, argv=0xbfffefd4) at main.c:859
Thread 3 (process 10965):
#0 0x007e87a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x008cb82e in epoll_wait () from /lib/tls/libc.so.6
#2 0x0807ae29 in slapd_daemon_task (ptr=0x0) at daemon.c:2174
#3 0x00a633cc in start_thread () from /lib/tls/libpthread.so.0
#4 0x008cb1ae in clone () from /lib/tls/libc.so.6
Thread 2 (process 10967):
#0 0x007e87a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x008bc29b in __write_nocancel () from /lib/tls/libc.so.6
#2 0x0086064f in _IO_new_file_write () from /lib/tls/libc.so.6
#3 0x0086089c in _IO_new_file_xsputn () from /lib/tls/libc.so.6
#4 0x00855af1 in fputs () from /lib/tls/libc.so.6
#5 0x081f6160 in lutil_debug (debug=261, level=1,
fmt=0x8237950 "<= key_change %d\n") at debug.c:89
#6 0x0814f485 in hdb_key_change (be=0x3061d24, db=0x838d518, txn=0x839bfe0,
k=0xb7bba47c, id=16, op=1) at key.c:101
#7 0x0814e7ca in indexer (op=0x83799c0, txn=0x839bfe0, ad=0x830c6e8,
atname=0x830d21c, vals=0x839aaa0, id=16, opid=1, mask=1814) at index.c:244
#8 0x0814e9a3 in index_at_values (op=0x83799c0, txn=0x839bfe0, ad=0x830c6e8,
type=0x830d1e0, tags=0x830c6f8, vals=0x839aaa0, id=16, opid=1)
at index.c:324
#9 0x0814eb05 in hdb_index_values (op=0x83799c0, txn=0x839bfe0,
desc=0x830c6e8, vals=0x839aaa0, id=16, opid=1) at index.c:373
#10 0x0814eec1 in hdb_index_entry (op=0x83799c0, txn=0x839bfe0, opid=1,
e=0x83946e8) at index.c:544
#11 0x0813ce65 in hdb_add (op=0x83799c0, rs=0x306218c) at add.c:304
#12 0x080e8903 in overlay_op_walk (op=0x83799c0, rs=0x306218c, which=op_add,
oi=0x830c800, on=0x0) at backover.c:650
#13 0x080e8ab8 in over_op_func (op=0x83799c0, rs=0x306218c, which=op_add)
at backover.c:702
#14 0x080e8bc4 in over_op_add (op=0x83799c0, rs=0x306218c) at backover.c:748
#15 0x080869e1 in fe_op_add (op=0x83799c0, rs=0x306218c) at add.c:342
#16 0x08086457 in do_add (op=0x83799c0, rs=0x306218c) at add.c:182
#17 0x0807e428 in connection_operation (ctx=0x3062218, arg_v=0x83799c0)
at connection.c:1133
#18 0x081c1d40 in ldap_int_thread_pool_wrapper (xpool=0x82c86c8) at tpool.c:478
#19 0x00a633cc in start_thread () from /lib/tls/libpthread.so.0
#20 0x008cb1ae in clone () from /lib/tls/libc.so.6
Thread 1 (process 10976):
#0 0x007e87a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x00829815 in raise () from /lib/tls/libc.so.6
#2 0x0082b279 in abort () from /lib/tls/libc.so.6
#3 0x081c2b9e in error (file=0x82749bd "thr_debug.c", line=784,
msg=0x82750a0 "ldap_pvt_thread_mutex_unlock", var=0x8274d72 "rc", val=1)
at thr_debug.c:155
#4 0x081c44ec in ldap_pvt_thread_mutex_unlock (mutex=0x830cd04)
at thr_debug.c:784
#5 0x08183fdf in accesslog_response (op=0x8386bc8, rs=0x220318c)
at accesslog.c:918
#6 0x08184f14 in accesslog_mod_cleanup (op=0x8386bc8, rs=0x220318c)
at accesslog.c:1241
#7 0x0808fcca in send_ldap_response (op=0x8386bc8, rs=0x220318c)
at result.c:458
#8 0x080903f1 in slap_send_ldap_result (op=0x8386bc8, rs=0x220318c)
at result.c:574
#9 0x0813d474 in hdb_add (op=0x8386bc8, rs=0x220318c) at add.c:409
#10 0x080e8903 in overlay_op_walk (op=0x8386bc8, rs=0x220318c, which=op_add,
oi=0x830c800, on=0x0) at backover.c:650
#11 0x080e8ab8 in over_op_func (op=0x8386bc8, rs=0x220318c, which=op_add)
at backover.c:702
#12 0x080e8bc4 in over_op_add (op=0x8386bc8, rs=0x220318c) at backover.c:748
#13 0x080869e1 in fe_op_add (op=0x8386bc8, rs=0x220318c) at add.c:342
#14 0x08086457 in do_add (op=0x8386bc8, rs=0x220318c) at add.c:182
#15 0x0807e428 in connection_operation (ctx=0x2203218, arg_v=0x8386bc8)
at connection.c:1133
#16 0x081c1d40 in ldap_int_thread_pool_wrapper (xpool=0x82c86c8) at tpool.c:478
#17 0x00a633cc in start_thread () from /lib/tls/libpthread.so.0
#18 0x008cb1ae in clone () from /lib/tls/libc.so.6
14 years, 3 months
(ITS#5373) ppolicy issues when deleting the password attribute, even if no password checking is enforced
by Guillaume.Rousse＠inria.fr
Full_Name: Guillaume Rousse
Version: 2.3.40
OS: linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (193.55.250.67)
Here are my ppolicy settings:
password policy
overlay ppolicy
ppolicy_use_lockout
ppolicy_default cn=default,ou=policies,dc=futurs,dc=inria,dc=fr
Here is my default entry:
dn: cn=default,ou=policies,dc=futurs,dc=inria,dc=fr
cn: default
objectClass: pwdPolicy
objectClass: organizationalRole
pwdAttribute: userPassword
pwdMaxAge: 0
pwdInHistory: 0
pwdCheckQuality: 0
According to documentation, no user password quality checking should take
places, however, trying to delete userPassword attribute for an user triggers at
least a server error with this LDIF fragment:
dn: userdn
changetype: modify
delete: userPassword
ldapmodify: Internal (implementation specific) error (80)
additional info: Internal Error
Error message in logs: "cannot locate modification supplying new password"
Or worst, a server crash with this one:
dn: userdn
changetype: modify
replace: userPassword
No error message from ldapmodify, and no error message in the logs in this case.
14 years, 3 months
Re: (ITS#5344) Wrong check for bad Modify DN
by h.b.furuseth＠usit.uio.no
Pierangelo Masarati writes:
> You should apply your initial patch (to HEAD, 2.4),
Done.
> then modify HEAD to pass dest_dn/dest_ndn
Later.
--
Hallvard
14 years, 3 months
Re: (ITS#5328) backends sending/setting results
by h.b.furuseth＠usit.uio.no
Some fixed in HEAD. Remaining bugs:
> Looking at the code, some overlays also send results when used as
> be_extended: pcache:pcache_op_privdb(), retcode, rwm, slapi_overlay.
Hmm - back-ldap does send_ldap_extended() too. I don't know any of
that code well though. Might have a look later, if nobody else does.
> * be->be_fetch() (bi->bi_entry_get_rw()):
> The LDAP result code matters (...) It can return just a boolean
> in (...) back-relay.
I haven't looked at what it should return when not forwarding to the
backend.
relay_back_has_subordinates() is also broken.
It should return an LDAP result code, and if returning LDAP_SUCCESS it
must also set *hasSubs to LDAP_COMPARE_FALSE or LDAP_COMPARE_TRUE. See
bdb_hasSubordinates() for an example. However:
slapd's be_has_subordinates() API seems broken: It has no way to return
"don't know" or normal errors which slapd will pay attention to. If it
returns non-success, test_ava_filter(,,,LDAP_FILTER_EQUALITY) returns
LDAP_OTHER. Looks abit excessive. OTOH test_presence_filter() assumes
that if the backend function exists then attr hasSubordinates does too.
> back-ldap:ldap_back_entry_get() can return LDAP_NO_MEMORY.
> Maybe that's OK and instead send_ldap_response() should change
> negative negative result codes to LDAP_OTHER?
Awaiting opinions - will do the smallest change and patch back-ldap
if nobody says anything.
--
Hallvard
14 years, 3 months
Re: (ITS#5369) GSSAPI support for client library
by mimir＠samba.org
--UugvWAfsgieZRqgk
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Kurt,
On Mon, Feb 11, 2008 at 09:06:19AM -0800, Kurt Zeilenga wrote:
> On Feb 11, 2008, at 1:09 AM, mimir(a)samba.org wrote:
>
>> Full_Name: Rafal Szczesniak
>> Version: HEAD
>> OS: GNU/Linux
>> URL: http://www.samba.org/~mimir/gssapi-head.diff
>
> The submitted patch file does not contain (at the top of the file, not =
=20
> as part of the diffs) the required notices.
I'm sorry about that. I was submitting it late yesterday and must have miss=
ed
that. I'll update the diff and let you know soon.
> Please review=20
> http://www.openldap.org/devel/contributing.html and insert appropriate=20
> notices. Also, please don't include in the diffs derived files (e.g.,=20
> configure).
Of course. My mistake.
cheers,
--=20
Rafal Szczesniak
Samba Team member http://www.samba.org
Likewise Software http://www.likewisesoftware.com
--UugvWAfsgieZRqgk
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHsK9nHvdfyv3qiKkRAiusAKChoX739lSkfFFRSqXxZG9ht5l3oQCghVrP
mWR71B2o2KIifs5uaiMzH58=
=SPnD
-----END PGP SIGNATURE-----
--UugvWAfsgieZRqgk--
14 years, 3 months
Re: (ITS#5370) race condition in slap_op_time()
by hyc＠symas.com
h.b.furuseth(a)usit.uio.no wrote:
> Full_Name: Hallvard B Furuseth
> Version: HEAD, RE23, RE24
> OS:
> URL:
> Submission from: (NULL) (129.240.6.233)
> Submitted by: hallvard
>
>
> slapd/operation.c:slap_op_time() can decrease last_time:
>
> thread 1: *t = slap_get_time();
> <clock: increment time()>
> thread 2: *t = slap_get_time();
> thread 2: with mutex lock: increment last_time, set last_incr = 0;
> thread 1: with mutex lock: decrement last_time, set last_incr = 0;
>
> The simplest fix is to move the slap_get_time() call inside the
> (global) slap_op_mutex lock.
>
> However as far as I can tell, only the accesslog overlay uses
> op->o_tincr, the value which needs the mutex. And accesslog
> calls slap_op_time() itself when it needs that value.
> So maybe we should remove the op->o_tincr field. Other calls
> to slap_op_time() can be replaced with slap_get_time().
Sounds like a good idea. It was somewhat redundant with the CSN counter
(except that this was for all operations, and CSN was only for write
operations) and it never became generally useful. (Shifted to microsecond
timestamps in 2.4, because tincr isn't useful across multiple servers.) I
guess it makes more sense to make it specific to accesslog.
--
-- 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/
14 years, 3 months