Re: (ITS#5199) slapd sometimes hangs with back-sql
by h.b.furuseth＠usit.uio.no
h.b.furuseth(a)usit.uio.no writes:
> It looks like thread 5 runs amok in sql_dbconn_mutex() while locking
> sql_dbconn_mutex.
Oops, cut&paste error. I meant in backsql_free_db_conn().
Anyway, does your log contain that message some time before?
> "backsql_open_db_conn(...): duplicate connection ID".
The (...) is the (connection id).
--
Hallvard
16 years
Re: (ITS#5199) slapd sometimes hangs with back-sql
by h.b.furuseth＠usit.uio.no
It looks like thread 5 runs amok in sql_dbconn_mutex() while locking
sql_dbconn_mutex. That mutex lacks an unlock operation in 2.3.38 where
slapd logs "backsql_open_db_conn(...): duplicate connection ID". (Which
doesn't sound too good to me either, but then I don't know back-sql.)
If that's the problem, it was fixed in OpenLDAP 2.3.39 for ITS#5095.
--
Regards,
Hallvard
16 years
Re: (ITS#5199) slapd sometimes hangs with back-sql
by david＠schmitt.edv-bus.at
--Boundary-00=_O6HKHoQQJlEsW1J
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hi!
Please find attached the output of "thread apply all bt full".
Regards, David
--
The primary freedom of open source is not the freedom from cost, but the free-
dom to shape software to do what you want. This freedom is /never/ exercised
without cost, but is available /at all/ only by accepting the very different
costs associated with open source, costs not in money, but in time and effort.
-- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
--Boundary-00=_O6HKHoQQJlEsW1J
Content-Type: application/octet-stream;
name="bt_full"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="bt_full"
Thread 5 (Thread 1082132832 (LWP 10915)):
#0 0x00002b5a2fb75eeb in __lll_mutex_lock_wait () from /lib/libpthread.so.0
No symbol table info available.
#1 0x00000000407fc9c0 in ?? ()
No symbol table info available.
#2 0x00000000006088d0 in ?? ()
No symbol table info available.
#3 0x00002b5a2fb72d9f in pthread_mutex_lock () from /lib/libpthread.so.0
No symbol table info available.
#4 0x0000003000000030 in ?? ()
No symbol table info available.
#5 0x00000000407fc8a0 in ?? ()
No symbol table info available.
#6 0x00000000407fc7b0 in ?? ()
No symbol table info available.
#7 0x00002b5a2feba0e0 in __after_morecore_hook () from /lib/libc.so.6
No symbol table info available.
#8 0x00000000000001c9 in ?? ()
No symbol table info available.
#9 0x0000000000000002 in ?? ()
No symbol table info available.
#10 0x00000000004a12bd in lt_preloaded_symbols ()
No symbol table info available.
#11 0x0000000000000004 in ?? ()
No symbol table info available.
#12 0x00000000004a1b35 in __PRETTY_FUNCTION__.12118 ()
No symbol table info available.
#13 0x0000000000000005 in ?? ()
No symbol table info available.
#14 0x00000000007238f0 in ?? ()
No symbol table info available.
#15 0x0000000000646b60 in ?? ()
No symbol table info available.
#16 0x0000000000646a20 in ?? ()
No symbol table info available.
#17 0x00000000407fc860 in ?? ()
No symbol table info available.
#18 0x00000000005fdf90 in style_strings ()
No symbol table info available.
#19 0x0000000000603600 in aclbuf ()
No symbol table info available.
#20 0x0000000000000002 in ?? ()
No symbol table info available.
#21 0x00002b5a30a054bd in backsql_free_db_conn (op=3D0x407fc860) at /root/t=
mp/openldap2.3-2.3.38/servers/slapd/back-sql/sql-wrap.c:439
bi =3D (backsql_info *) 0x689910
tmp =3D {ldap_cid =3D 469, dbh =3D 0x0}
conn =3D <value optimized out>
#22 0x00002b5a309f7047 in backsql_connection_destroy (bd=3D<value optimized=
out>, c=3D0x0) at /root/tmp/openldap2.3-2.3.38/servers/slapd/back-sql/init=
=2Ec:590
opbuf =3D {
buffer =3D "=C0=C9\177@\000\000\000\000=D9T=A6/Z+\000\000=A0=C8\177@\000\=
000\000\000\235s=A6/Z+\000\000p\227h\000\000\000\000\000\003\000\000\000\00=
0\000\000\0005\033J\000\000\000\000\000\000\000\000\000Z+\000\000=FF=FF=FF=
=FFunknown", '\0' <repeats 93 times>, "]vB\000\000\000\000\000p=CA\177@\000=
\000\000\000P", '\0' <repeats 175 times>, "=D5\001", '\0' <repeats 174 time=
s>, "=D5\001\000\000\000\000\000\000=C0xf1Z+", '\0' <repeats 185 times>, ia=
lign =3D 1082116544, lalign =3D 1082116544,=20
falign =3D 3.99668884, dalign =3D 5.3463660918685768e-315, palign =3D 0x4=
07fc9c0 ""}
op =3D (Operation *) 0x689a50
#23 0x000000000043219c in backend_connection_destroy (conn=3D0x2b5a316678c0=
) at /root/tmp/openldap2.3-2.3.38/servers/slapd/backend.c:770
be =3D (BackendDB *) 0x689770
#24 0x0000000000427973 in connection_close (c=3D0x2b5a316678c0) at /root/tm=
p/openldap2.3-2.3.38/servers/slapd/connection.c:690
sd =3D -1
__PRETTY_FUNCTION__ =3D "connection_close"
#25 0x00000000004289c6 in connection_read (s=3D10) at /root/tmp/openldap2.3=
=2D2.3.38/servers/slapd/connection.c:1458
err =3D <value optimized out>
sd =3D 10
rc =3D -2
c =3D (Connection *) 0x2b5a316678c0
__PRETTY_FUNCTION__ =3D "connection_read"
#26 0x00000000004254db in slapd_daemon_task (ptr=3D<value optimized out>) a=
t /root/tmp/openldap2.3-2.3.38/servers/slapd/daemon.c:2468
fd =3D 10
l =3D <value optimized out>
last_idle_check =3D 0
ebadf =3D 0
#27 0x00002b5a2fb70f1a in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#28 0x00002b5a2fd4a6c2 in clone () from /lib/libc.so.6
No symbol table info available.
#29 0x0000000000000000 in ?? ()
No symbol table info available.
Thread 4 (Thread 1090525536 (LWP 10930)):
#0 0x00002b5a2fb75eeb in __lll_mutex_lock_wait () from /lib/libpthread.so.0
No symbol table info available.
#1 0x0000000041000bd0 in ?? ()
No symbol table info available.
#2 0x0000000000000000 in ?? ()
No symbol table info available.
Thread 3 (Thread 1098918240 (LWP 26084)):
#0 0x00002b5a2fb73b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpt=
hread.so.0
No symbol table info available.
#1 0x00002b5a2eb7a888 in ldap_int_thread_pool_wrapper (xpool=3D0x62a050) a=
t /root/tmp/openldap2.3-2.3.38/libraries/libldap_r/tpool.c:490
ctx =3D (ldap_int_thread_ctx_t *) 0x0
ltc_key =3D {{ltk_key =3D 0x46bf90, ltk_data =3D 0x70e340, ltk_free =3D 0x=
46baf0 <slap_sl_mem_destroy>}, {ltk_key =3D 0x0, ltk_data =3D 0x0, ltk_free=
=3D 0} <repeats 31 times>}
tid =3D 1098918240
i =3D 330
hash =3D <value optimized out>
#2 0x00002b5a2fb70f1a in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#3 0x00002b5a2fd4a6c2 in clone () from /lib/libc.so.6
No symbol table info available.
#4 0x0000000000000000 in ?? ()
No symbol table info available.
Thread 2 (Thread 1107310944 (LWP 12906)):
#0 0x00002b5a2fb75eeb in __lll_mutex_lock_wait () from /lib/libpthread.so.0
No symbol table info available.
#1 0x0000000042002bd0 in ?? ()
No symbol table info available.
#2 0x0000000000000000 in ?? ()
No symbol table info available.
Thread 1 (Thread 47666352182560 (LWP 10908)):
#0 0x00002b5a2fb720f5 in pthread_join () from /lib/libpthread.so.0
No symbol table info available.
#1 0x00000000004230d2 in slapd_daemon () at /root/tmp/openldap2.3-2.3.38/s=
ervers/slapd/daemon.c:2579
listener_tid =3D 1082132832
rc =3D 0
#2 0x000000000041665f in main (argc=3D5, argv=3D0x7fff7c053a58) at /root/t=
mp/openldap2.3-2.3.38/servers/slapd/main.c:859
save_errno =3D <value optimized out>
fp =3D (FILE *) 0x6a4f70
i =3D <value optimized out>
no_detach =3D 0
rc =3D 1
urls =3D <value optimized out>
username =3D 0x605030 "gidNumber"
groupname =3D 0x605010 "\226{=D9/Z+"
sandbox =3D 0x0
syslogUser =3D 160
configfile =3D <value optimized out>
configdir =3D <value optimized out>
serverName =3D <value optimized out>
scp =3D <value optimized out>
scp_entry =3D <value optimized out>
debug_unknowns =3D (char **) 0x0
syslog_unknowns =3D (char **) 0x0
l =3D <value optimized out>
slapd_pid_file_unlink =3D 1
slapd_args_file_unlink =3D 1
__PRETTY_FUNCTION__ =3D "main"
#0 0x00002b5a2fb720f5 in pthread_join () from /lib/libpthread.so.0
--Boundary-00=_O6HKHoQQJlEsW1J--
16 years
(ITS#5208) OpenLDAP w/ multiple bdb backends provides invalid paged result responses
by hume-ml＠bofh.ca
Full_Name: Brandon Hume
Version: 2.3.38
OS: OpenSolaris/Redhat Linux AS3
URL:
Submission from: (NULL) (129.173.2.54)
When OpenLDAP is serving a tree split into multiple backends (for whatever
reasons someone might do so), searching with the paged result control against
the base DN and ranging across the subordinate trees causes a paged result
cursor to be provided for each backend.
ie: With a config such as:
database bdb
directory /opt/csw/var/openldap/people
suffix "ou=People,dc=example,dc=com"
subordinate
rootdn "cn=NOC,dc=example,dc=com"
database bdb
directory /opt/csw/var/openldap/default
suffix "dc=domain,dc=com"
rootdn "cn=NOC,dc=domain,dc=com"
rootpw {SSHA}[...]
A search such as the following:
ldapsearch -h localhost -x -E pr=2 -b dc=dal,dc=ca '(objectclass=*)'
... will produce the following result/control response:
[...]
# search result
search: 2
result: 0 Success
control: 1.2.840.113556.1.4.319 false MAkCAQAEBAIAAAA=
control: 1.2.840.113556.1.4.319 false MAkCAQAEBP////8=
Press [size] Enter for the next {2|size} entries.
This has the effect of causing the next paged result to fail, since one of the
two values is not correct and is rejected by the server.
16 years
(ITS#5207) Password checking: external program
by hadmut＠danisch.de
Full_Name: Hadmut Danisch
Version: 2.3.38
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (85.180.64.93)
Hi,
that's a feature request:
Sometimes it is necessary to use other authentication methods than the regular
password login. E.g. when using an insecure computer in an internet cafe to
login into a web mail frontend, which accesses an imap server, which
authenticates against LDAP. It would require to authenticate trough
one-time-passwords, HTTP-Cookies or other unusual methods.
Actually,SASL provides a way to use other methods like One-time-passwords, but
is still too limited and there are too many programs (LDAP clients) out there
that don't support sasl authentication.
Therefore it would be nice if slapd could be configured to do the password
checking over some external plugin or program, which could do any sort of
unusual checking.
This way a user could enter a one time password just as a normal LDAP login
password, and pass it through the chain of programs, e.g. mailclient -
maildaemon - LDAP or
browser - webmailer - imap - LDAP.
regards
Hadmut
16 years
Re: (ITS#5195) ssf not available during sasl bind
by h.b.furuseth＠usit.uio.no
[Resending, I forgot Russell wasn't in the to/cc list of your
reply. Don't know if that means he didn't receive it or if ITS
did something clever.]
quanah(a)zimbra.com writes:
> --On Monday, October 29, 2007 11:45 PM +0000 russell-openldap(a)stuart.id.au
> wrote:
>> Secondly, just out of curiosity, are there SASL methods
>> that check a shared secret of some kind and don't use
>> userPassword? What are they?
>
> GSSAPI
And all SASL methods that use passwords, if SASL is configured to use
another password store than slapd. Like Cyrus SASL's default sasldb.
--
Regards,
Hallvard
16 years, 1 month
Re: (ITS#5195) ssf not available during sasl bind
by h.b.furuseth＠usit.uio.no
quanah(a)zimbra.com writes:
> --On Monday, October 29, 2007 11:45 PM +0000 russell-openldap(a)stuart.id.au
> wrote:
>> Secondly, just out of curiosity, are there SASL methods
>> that check a shared secret of some kind and don't use
>> userPassword? What are they?
>
> GSSAPI
And all SASL methods that use passwords, if SASL is configured to use
another password store than slapd. Like Cyrus SASL's default sasldb.
--
Regards,
Hallvard
16 years, 1 month
Re: (ITS#5195) ssf not available during sasl bind
by hyc＠symas.com
russell-openldap(a)stuart.id.au wrote:
> On Mon, 2007-10-29 at 18:07 +0100, Hallvard B Furuseth wrote:
>> No, you've forced users who authenticate against userPassword
>> to be encrypted. Not all SASL methods, nor auth with rootpw.
>
> Thats a worry. Rootpw aside, the intended objective of
> the ACL was to ensure passwords were never sent in the
> clear. Either a protocol like CRAM-MD5 was used, or the
> entire link is encrypted.
By the way, CRAM-MD5 has a few known weaknesses. Should use DIGEST-MD5
instead. http://www.ietf.org/rfc/rfc2831.txt (For what that's worth. Given
that methods exist to create MD5 collisions, it's not clear how much longer
DIGEST-MD5 will be useful.)
> Does it not do that? (Actually
> it doesn't. It should have been sasl_ssf=71. But bugs
> aside ...)
>
> Secondly, just out of curiosity, are there SASL methods
> that check a shared secret of some kind and don't use
> userPassword? What are they?
>
> The "security" option may produce better error messages
> by it appears to apply to all connections, including
> lookups done by SASL to dn="" to discover what mechanisms
> are allowed. It wasn't at all obvious to a newbie like me
> that this sentence from "man 1 ldapsearch" only applies
> if you don't use the "security" option:
>
> "-Y mech .... If it's not specified, the program will
> choose the best mechanism the server knows."
Perhaps we should add a security option to separately specify the SSF for
anonymous sessions.
--
-- 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, 1 month
Re: (ITS#5195) ssf not available during sasl bind
by quanah＠zimbra.com
--On Monday, October 29, 2007 11:45 PM +0000 russell-openldap(a)stuart.id.au
wrote:
> On Mon, 2007-10-29 at 18:07 +0100, Hallvard B Furuseth wrote:
>> No, you've forced users who authenticate against userPassword
>> to be encrypted. Not all SASL methods, nor auth with rootpw.
>
> Thats a worry. Rootpw aside, the intended objective of
> the ACL was to ensure passwords were never sent in the
> clear. Either a protocol like CRAM-MD5 was used, or the
> entire link is encrypted. Does it not do that? (Actually
> it doesn't. It should have been sasl_ssf=71. But bugs
> aside ...)
>
> Secondly, just out of curiosity, are there SASL methods
> that check a shared secret of some kind and don't use
> userPassword? What are they?
GSSAPI
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
16 years, 1 month
Re: (ITS#5195) ssf not available during sasl bind
by russell-openldap＠stuart.id.au
On Mon, 2007-10-29 at 18:07 +0100, Hallvard B Furuseth wrote:
> No, you've forced users who authenticate against userPassword
> to be encrypted. Not all SASL methods, nor auth with rootpw.
Thats a worry. Rootpw aside, the intended objective of
the ACL was to ensure passwords were never sent in the
clear. Either a protocol like CRAM-MD5 was used, or the
entire link is encrypted. Does it not do that? (Actually
it doesn't. It should have been sasl_ssf=71. But bugs
aside ...)
Secondly, just out of curiosity, are there SASL methods
that check a shared secret of some kind and don't use
userPassword? What are they?
The "security" option may produce better error messages
by it appears to apply to all connections, including
lookups done by SASL to dn="" to discover what mechanisms
are allowed. It wasn't at all obvious to a newbie like me
that this sentence from "man 1 ldapsearch" only applies
if you don't use the "security" option:
"-Y mech .... If it's not specified, the program will
choose the best mechanism the server knows."
16 years, 1 month
