Re: (ITS#4892) slapd HEAD crashes with ldapi:// and SASL EXTERNAL
by michael＠stroeder.com
Pierangelo Masarati wrote:
> michael(a)stroeder.com wrote:
>
>> bdb_idl_fetch_key: [5941c014]
>> <= bdb_index_read: failed (-30989)
>
> ^^^
>
> $ grep 30989 dn.h
> #define DB_OLD_VERSION (-30989)/* Out-of-date version. */
>
> I guess something strange is going on with libdb run-time loading...
Hmm, could be because the SASL RPM is built against db 4.4.20 and
OpenLDAP is built against BDB 4.5.20 in /opt/bdb-4.5. I'll check that.
Ciao, Michael.
16 years, 6 months
Re: (ITS#4892) slapd HEAD crashes with ldapi:// and SASL EXTERNAL
by ando＠sys-net.it
michael(a)stroeder.com wrote:
> bdb_idl_fetch_key: [5941c014]
> <= bdb_index_read: failed (-30989)
^^^
$ grep 30989 dn.h
#define DB_OLD_VERSION (-30989)/* Out-of-date version. */
I guess something strange is going on with libdb run-time loading...
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, 6 months
Re: Tranlucent Overlay (ITS#4889)
by ghenry＠suretecsystems.com
<quote who="Howard Chu">
> Gavin Henry wrote:
>> <quote who="Howard Chu">
>>> Gavin Henry wrote:
>>>> <quote who="hyc(a)symas.com">
>>>>> Curious that your opening log says "No dynamic config support for
>>>>> database bdb." Are you sure you have a clean install here?
>>>> I thought that was weird to. This was setup on my laptop, no OpenLDAP
>>>> from
>>>> rpm or source ever installed. Fresh 2.3.34 and db-4.2.52 (5 patches).
>>> Yeah, false alarm. The presence of the rwm overlay taints the entire
>>> stack.
>>
>> Isn't this because translucent doesn't support dynamic config, so
>> disables
>> bdb dynamic config?
>>
>> Everything is now working, with no crashes without rwm.
>>
>> I've not had chance to test HEAD yet.
>
> Translucent does support dynamic config, but rwm doesn't.
Not in 2.3.34 as I understand it. translucent.c doesn't have and olc*
things anyway.
>
> --
> -- 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, 6 months
Re: Tranlucent Overlay (ITS#4889)
by hyc＠symas.com
Gavin Henry wrote:
> <quote who="Howard Chu">
>> Gavin Henry wrote:
>>> <quote who="hyc(a)symas.com">
>>>> Curious that your opening log says "No dynamic config support for
>>>> database bdb." Are you sure you have a clean install here?
>>> I thought that was weird to. This was setup on my laptop, no OpenLDAP
>>> from
>>> rpm or source ever installed. Fresh 2.3.34 and db-4.2.52 (5 patches).
>> Yeah, false alarm. The presence of the rwm overlay taints the entire
>> stack.
>
> Isn't this because translucent doesn't support dynamic config, so disables
> bdb dynamic config?
>
> Everything is now working, with no crashes without rwm.
>
> I've not had chance to test HEAD yet.
Translucent does support dynamic config, but rwm doesn't.
--
-- 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, 6 months
Re: Tranlucent Overlay (ITS#4889)
by ghenry＠suretecsystems.com
<quote who="Howard Chu">
> Gavin Henry wrote:
>> <quote who="hyc(a)symas.com">
>
>>> Curious that your opening log says "No dynamic config support for
>>> database bdb." Are you sure you have a clean install here?
>>
>> I thought that was weird to. This was setup on my laptop, no OpenLDAP
>> from
>> rpm or source ever installed. Fresh 2.3.34 and db-4.2.52 (5 patches).
>
> Yeah, false alarm. The presence of the rwm overlay taints the entire
> stack.
Isn't this because translucent doesn't support dynamic config, so disables
bdb dynamic config?
Everything is now working, with no crashes without rwm.
I've not had chance to test HEAD yet.
Gavin.
>
> --
> -- 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, 6 months
Re: (ITS#4892) slapd HEAD crashes with ldapi:// and SASL EXTERNAL
by michael＠stroeder.com
Debug output related to this:
---------------------------- `slapd -d 255` ---------------------------
daemon: activity on 1 descriptor
daemon: activity on:
slap_listener_activate(8):
daemon: epoll: listen=7 active_threads=0 tvp=zero
daemon: epoll: listen=8 busy
>>> >>>
slap_listener(ldapi://%2fhome%2fmichael%2fBizness%2fOpenLDAP%2fODD_2006%2fslapd-socket)
daemon: listen=8, new connection on 15
daemon: added 15r (active) listener=(nil)
daemon: activity on 2 descriptors
daemon: activity on: 15r
daemon: read active on 15
daemon: epoll: listen=7 active_threads=0 tvp=zero
daemon: epoll: listen=8 active_threads=0 tvp=zero
connection_get(15)
connection_get(15): got connid=0
connection_read(15): checking for input on id=0
ber_get_next
ldap_read: want=8, got=8
0000: 30 18 02 01 01 60 13 02 0....`..
ldap_read: want=18, got=18
0000: 01 03 04 00 a3 0c 04 08 45 58 54 45 52 4e 41 4c
........EXTERNAL
0010: 04 00 ..
ber_get_next: tag 0x30 len 24 contents:
ber_dump: buf=0x08247cb0 ptr=0x08247cb0 end=0x08247cc8 len=24
0000: 02 01 01 60 13 02 01 03 04 00 a3 0c 04 08 45 58
...`..........EX
0010: 54 45 52 4e 41 4c 04 00 TERNAL..
ber_get_next
ldap_read: want=8 error=Resource temporarily unavailable
do_bind
ber_scanf fmt ({imt) ber:
ber_dump: buf=0x08247cb0 ptr=0x08247cb3 end=0x08247cc8 len=21
0000: 60 13 02 01 03 04 00 a3 0c 04 08 45 58 54 45 52
`..........EXTER
0010: 4e 41 4c 04 00 NAL..
ber_scanf fmt ({m) ber:
ber_dump: buf=0x08247cb0 ptr=0x08247cba end=0x08247cc8 len=14
0000: 00 0c 04 08 45 58 54 45 52 4e 41 4c 04 00
....EXTERNAL..
ber_scanf fmt (m) ber:
ber_dump: buf=0x08247cb0 ptr=0x08247cc6 end=0x08247cc8 len=2
0000: 00 00 ..
ber_scanf fmt (}}) ber:
ber_dump: buf=0x08247cb0 ptr=0x08247cc8 end=0x08247cc8 len=0
>>> >>> dnPrettyNormal: <>
<<< dnPrettyNormal: <>, <>
do_sasl_bind: dn () mech EXTERNAL
==> sasl_bind: dn="" mech=EXTERNAL datalen=0
SASL Canonicalize [conn=0]:
authcid="gidNumber=100+uidNumber=500,cn=peercred,cn=external,cn=auth"
slap_sasl_getdn: conn 0
id=gidNumber=100+uidNumber=500,cn=peercred,cn=external,cn=auth [len=59]
==>slap_sasl2dn: converting SASL name
gidNumber=100+uidNumber=500,cn=peercred,cn=external,cn=auth to a DN
==> rewrite_context_apply [depth=1]
string='gidNumber=100+uidNumber=500,cn=peercred,cn=external,cn=auth'
==> rewrite_rule_apply
rule='gidnumber=([0-9]+)\+uidnumber=([0-9]+),cn=peercred,cn=external,cn=auth'
string='gidNumber=100+uidNumber=500,cn=peercred,cn=external,cn=auth' [1
pass(es)]
==> rewrite_context_apply [depth=1]
res={0,'ldap:///ou=Users,ou=odd2006,dc=block-floete,dc=de??sub?(&(objectClass=posixAccount)(uidNumber=500)(gidNumber=100))'}
[rw] authid:
"gidNumber=100+uidNumber=500,cn=peercred,cn=external,cn=auth" ->
"ldap:///ou=Users,ou=odd2006,dc=block-floete,dc=de??sub?(&(objectClass=posixAccount)(uidNumber=500)(gidNumber=100))"
slap_parseURI: parsing
ldap:///ou=Users,ou=odd2006,dc=block-floete,dc=de??sub?(&(objectClass=posixAccount)(uidNumber=500)(gidNumber=100))
ldap_url_parse_ext(ldap:///ou=Users,ou=odd2006,dc=block-floete,dc=de??sub?(&(objectClass=posixAccount)(uidNumber=500)(gidNumber=100)))
str2filter "(&(objectClass=posixAccount)(uidNumber=500)(gidNumber=100))"
put_filter: "(&(objectClass=posixAccount)(uidNumber=500)(gidNumber=100))"
put_filter: AND
put_filter_list "(objectClass=posixAccount)(uidNumber=500)(gidNumber=100)"
put_filter: "(objectClass=posixAccount)"
put_filter: simple
put_simple_filter: "objectClass=posixAccount"
put_filter: "(uidNumber=500)"
put_filter: simple
put_simple_filter: "uidNumber=500"
put_filter: "(gidNumber=100)"
put_filter: simple
put_simple_filter: "gidNumber=100"
begin get_filter
AND
begin get_filter_list
begin get_filter
EQUALITY
ber_scanf fmt ({mm}) ber:
ber_dump: buf=0xb1f76154 ptr=0xb1f76156 end=0xb1f76197 len=65
0000: a3 1b 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 04
....objectClass.
0010: 0c 70 6f 73 69 78 41 63 63 6f 75 6e 74 a3 10 04
.posixAccount...
0020: 09 75 69 64 4e 75 6d 62 65 72 04 03 35 30 30 a3
.uidNumber..500.
0030: 10 04 09 67 69 64 4e 75 6d 62 65 72 04 03 31 30
...gidNumber..10
0040: 30 0
end get_filter 0
begin get_filter
EQUALITY
ber_scanf fmt ({mm}) ber:
ber_dump: buf=0xb1f76154 ptr=0xb1f76173 end=0xb1f76197 len=36
0000: 00 10 04 09 75 69 64 4e 75 6d 62 65 72 04 03 35
....uidNumber..5
0010: 30 30 a3 10 04 09 67 69 64 4e 75 6d 62 65 72 04
00....gidNumber.
0020: 03 31 30 30 .100
end get_filter 0
begin get_filter
EQUALITY
ber_scanf fmt ({mm}) ber:
ber_dump: buf=0xb1f76154 ptr=0xb1f76185 end=0xb1f76197 len=18
0000: 00 10 04 09 67 69 64 4e 75 6d 62 65 72 04 03 31
....gidNumber..1
0010: 30 30 00
end get_filter 0
end get_filter_list
end get_filter 0
>>> >>> dnNormalize: <ou=Users,ou=odd2006,dc=block-floete,dc=de>
=> ldap_bv2dn(ou=Users,ou=odd2006,dc=block-floete,dc=de,0)
<= ldap_bv2dn(ou=Users,ou=odd2006,dc=block-floete,dc=de)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(ou=users,ou=odd2006,dc=block-floete,dc=de)=0
<<< dnNormalize: <ou=users,ou=odd2006,dc=block-floete,dc=de>
slap_sasl2dn: performing internal search
(base=ou=users,ou=odd2006,dc=block-floete,dc=de, scope=2)
=> hdb_search
bdb_dn2entry("ou=users,ou=odd2006,dc=block-floete,dc=de")
entry_decode: ""
<= entry_decode()
=> access_allowed: auth access to
"ou=Users,ou=odd2006,dc=block-floete,dc=de" "entry" requested
=> dn: [4] ou=users,ou=odd2006,dc=block-floete,dc=de
=> acl_get: [4] matched
=> acl_get: [4] attr entry
=> acl_mask: access to entry
"ou=Users,ou=odd2006,dc=block-floete,dc=de", attr "entry" requested
=> acl_mask: to all values by "", (=0)
<= check a_dn_pat: *
<= acl_mask: [2] applying read(=rscxd) (stop)
<= acl_mask: [2] mask: read(=rscxd)
=> slap_access_allowed: auth access granted by read(=rscxd)
=> access_allowed: auth access granted by read(=rscxd)
search_candidates: base="ou=users,ou=odd2006,dc=block-floete,dc=de"
(0x00000002) scope=2
=> hdb_dn2idl("ou=users,ou=odd2006,dc=block-floete,dc=de")
=> bdb_filter_candidates
AND
=> bdb_list_candidates 0xa0
=> bdb_filter_candidates
OR
=> bdb_list_candidates 0xa1
=> bdb_filter_candidates
EQUALITY
=> bdb_equality_candidates (objectClass)
=> key_read
bdb_idl_fetch_key: [b49d1940]
<= bdb_index_read: failed (-30989)
<= bdb_equality_candidates: id=0, first=0, last=0
<= bdb_filter_candidates: id=0 first=0 last=0
=> bdb_filter_candidates
AND
=> bdb_list_candidates 0xa0
=> bdb_filter_candidates
EQUALITY
=> bdb_equality_candidates (objectClass)
=> key_read
bdb_idl_fetch_key: [5941c014]
<= bdb_index_read: failed (-30989)
<= bdb_equality_candidates: id=0, first=0, last=0
<= bdb_filter_candidates: id=0 first=0 last=0
<= bdb_list_candidates: id=0 first=0 last=0
<= bdb_filter_candidates: id=0 first=0 last=0
<= bdb_list_candidates: id=0 first=0 last=0
<= bdb_filter_candidates: id=0 first=0 last=0
<= bdb_list_candidates: id=0 first=2 last=0
<= bdb_filter_candidates: id=0 first=2 last=0
bdb_search_candidates: id=0 first=2 last=0
hdb_search: no candidates
send_ldap_result: conn=0 op=0 p=3
send_ldap_result: err=0 matched="" text=""
<==slap_sasl2dn: Converted SASL name to <nothing>
SASL Canonicalize [conn=0]:
slapAuthcDN="gidNumber=100+uidNumber=500,cn=peercred,cn=external,cn=auth"
./start-slapd.sh: line 12: 4310 Segmentation fault
${OPENLDAP_PREFIX}/libexec/slapd -d 255 -h "ldap://0.0.0.0:2006
ldapi://%2fhome%2fmichael%2fBizness%2fOpenLDAP%2fODD_2006%2fslapd-socket"
-n slapd-odd2006 -u michael -o slp=off -f ${LOCALCONFIG}/slapd.conf
16 years, 6 months
Re: Tranlucent Overlay (ITS#4889)
by hyc＠symas.com
ando(a)sys-net.it wrote:
> ghenry(a)suretecsystems.com wrote:
>
>> That's strange though, as I merely followed the slapd-ldap(5) man page:
>
> Slapo-rwm(5) works just fine by itself; the point is that when it was
> designed there was no cleanup hook in the callback structure, so it was
> __permmently replacing__ the original values of request DN and DN-valued
> attributes instead of __temporarily replace__ them and set the original
> values back when done. So it interacts poorly with other, more recent
> overlays.
Given that this particular rwm invocation isn't doing anything, it
should be easy enough to just comment it out and see if the problem
still occurs.
Curious that your opening log says "No dynamic config support for
database bdb." Are you sure you have a clean install here?
--
-- 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, 6 months
Re: Tranlucent Overlay (ITS#4889)
by ando＠sys-net.it
ghenry(a)suretecsystems.com wrote:
> That's strange though, as I merely followed the slapd-ldap(5) man page:
Slapo-rwm(5) works just fine by itself; the point is that when it was
designed there was no cleanup hook in the callback structure, so it was
__permmently replacing__ the original values of request DN and DN-valued
attributes instead of __temporarily replace__ them and set the original
values back when done. So it interacts poorly with other, more recent
overlays.
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, 6 months
Re: (ITS#4888) Enhance back-sql with paged results
by ando＠sys-net.it
adamson(a)andrew.cmu.edu wrote:
> When I checked on the patch file in my Emacs window this morning I saw the
> "modified buffer" flag was still on because I hadn't saved the final
> version. Grrrr. It included the function declarations and one last fix.
> Sorry about that.
:)
> When I extract the last ID number from the cookie, I
> have to make sure we're in the same objectClass as when the ID number was
> saved.
> I've replaced the patch file on my web server. If it doesn't fix the
> root entry bug you're seeing, could you show me the search you're
> performing? I'll have to more closely follow what's happening in the
> switch ( bsi.bsi_scope ) {
> segment around line 2115 in backsql_search() to see if there is some
> special case for the root entry.
It works now, thanks. I'll commit the patch, but I think we should
definitely move the cookie stuff to the frontend and generalize the
cookie stuff to use bervals before we close this ITS.
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, 6 months
Re: Tranlucent Overlay (ITS#4889)
by ghenry＠suretecsystems.com
<quote who="Pierangelo Masarati">
> In re23 slapo-rwm should not be used in conjunction with other overlays;
> there
> is a number of reports about interoperability issues, and only recently
> Howard
> fixed (I should say "reworked") it in HEAD/re24. Can you reproduce the
> same
> issue with HEAD?
Will do later this week.
That's strange though, as I merely followed the slapd-ldap(5) man page:
suffixmassage, map, rewrite*
These directives are no longer supported by
back-ldap; their functionality is now delegated to the
rwm overlay.
Essentially, add a statement
overlay rwm
first, and prefix all rewrite/map statements with rwm- to
obtain the original behavior. See slapo-rwm(5) for details.
Maybe a man page patch is needed to stop others hitting this.
Thanks.
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
16 years, 6 months