michael(a)stroeder.com wrote:
> Full_Name: Michael Ströder
> Version: RE24
> OS: OpenSUSE Linux 10.2
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (84.163.82.89)
>
>
> Please add attribute type 'auditContext' to subschema.
It is registered by slapo-accesslog(5). I can see it when
slapo-accesslog(5) is built.
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: ando(a)sys-net.it
-----------------------------------
Dieter Kluenter wrote:
> Pierangelo Masarati <ando(a)sys-net.it> writes:
>
>> dieter(a)dkluenter.de wrote:
>>
>>> Sorry, forgot it,
>> Should be fixed in HEAD, please test. I infer you're using multiple
>> instances of slapo-dynlist(5) in your slapd.conf, aren't you?
>
> No, just one instance.
Sounds odd, because the error was related to executing slapo-dynlist's
db_open() function while the static vars holding the dgIdentity (and the
dgAuthz) attrs being already initialized. Can you test the fix to
overlays/dynlist.c 1.51->1.52? It is for HEAD, but should apply
straightforwardly to 2.4.
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: ando(a)sys-net.it
-----------------------------------
Pierangelo Masarati <ando(a)sys-net.it> writes:
> dieter(a)dkluenter.de wrote:
>
>> Sorry, forgot it,
>
> Should be fixed in HEAD, please test. I infer you're using multiple
> instances of slapo-dynlist(5) in your slapd.conf, aren't you?
No, just one instance.
-Dieter
--
Dieter Klünter | Systemberatung
http://www.dkluenter.de
GPG Key ID:8EF7B6C6
amg1127(a)cefetrs.tche.br wrote:
> I submitted a bug report in Ubuntu's Launchpad. The address is:
>
> https://bugs.launchpad.net/ubuntu/+source/openldap2.3/+bug/243337
>
> The bug refers to 2.4.9, but it is reproducible in OpenLDAP 2.4.10 (I could
> reproduce it, at least).
Your logs show something relatively odd: apparently, slapo-unique(5) is
trying to perform an internal search with a really malformed filter:
==> unique_search ,
str2filter "(&objectClass=posixGroup(|(gidNumber=1000)))"
put_filter: "(&objectClass=posixGroup(|(gidNumber=1000)))"
put_filter: AND
put_filter_list "objectClass=posixGroup(|(gidNumber=1000))"
Can you please try using "(objectClass=posixGroup)" instead of
"objectClass=posixGroup" as the unique_uri filter in your test slapd.conf?
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: ando(a)sys-net.it
-----------------------------------
dieter(a)dkluenter.de wrote:
> Sorry, forgot it,
Should be fixed in HEAD, please test. I infer you're using multiple
instances of slapo-dynlist(5) in your slapd.conf, aren't you?
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: ando(a)sys-net.it
-----------------------------------
Howard Chu <hyc(a)symas.com> writes:
> dieter(a)dkluenter.de wrote:
>> Full_Name: Dieter Kluenter
>> Version: 2.4.10
>> OS: openSUSE
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (84.142.217.87)
[...]
>
> Where is the backtrace?
Sorry, forgot it,
#0 0x00007f07d3c6a5c5 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x00007f07d3c6a5c5 in raise () from /lib64/libc.so.6
#1 0x00007f07d3c6bbb3 in abort () from /lib64/libc.so.6
#2 0x00007f07d3c631e9 in __assert_fail () from /lib64/libc.so.6
#3 0x00000000004894a1 in slap_bv2ad (bv=0x7fffddbd3c30, ad=0x7f07d2bbc4f0,
text=0x7fffddbd3c70) at ad.c:164
#4 0x00000000004893a3 in slap_str2ad (str=0x7f07d29bad62 "dgIdentity",
ad=0x7f07d2bbc4f0, text=0x7fffddbd3c70) at ad.c:123
#5 0x00007f07d29ba0bc in dynlist_db_open (be=0x7fffddbd3ce0,
cr=0x7fffddbd3f20) at dynlist.c:1560
#6 0x00000000004bae67 in over_db_open (be=0x8b9a90, cr=0x7fffddbd3f20)
at backover.c:153
#7 0x0000000000449819 in backend_startup_one (be=0x8b9a90, cr=0x7fffddbd3f20)
at backend.c:224
#8 0x0000000000449ad2 in backend_startup (be=0x8b9a90) at backend.c:267
#9 0x000000000047366f in slap_startup (be=0x8b9a90) at init.c:225
#10 0x00000000004c1853 in slap_tool_init (progname=0x55a728 "slapadd", tool=1,
argc=10, argv=0x7fffddbe4a08) at slapcommon.c:725
#11 0x00000000004beff0 in slapadd (argc=10, argv=0x7fffddbe4a08)
at slapadd.c:73
#12 0x00000000004190ef in main (argc=10, argv=0x7fffddbe4a08) at main.c:636
(gdb)
-Dieter
--
Dieter Klünter | Systemberatung
http://www.dkluenter.de
GPG Key ID:8EF7B6C6
hyc(a)symas.com wrote:
> vorlon(a)debian.org wrote:
>> This bug is marked as fixed in 2.4.8, but I still see the same problem in
>> the test suite in 2.4.10. Trying to start slapd with back-meta gives:
>>
>> /home/devel/openldap/build-area/openldap2.3-2.4.10/debian/build/servers/slapd/.libs/lt-slapd: symbol lookup error: ../servers/slapd/back-meta/.libs/back_meta-2.4.so.2: undefined symbol: slap_idassert_parse_cf
>>
>> Is this a regression since 2.4.8?
>
> Looks more like an incomplete fix. The functions in question haven't changed
> since 2006. Since we're not using a hacked libltdl the problem you're seeing
> doesn't show up here. I guess you should have tested this sooner...
Additional patches for back-ldap/back-meta are now in HEAD; please test.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
vorlon(a)debian.org wrote:
> This bug is marked as fixed in 2.4.8, but I still see the same problem in
> the test suite in 2.4.10. Trying to start slapd with back-meta gives:
>
> /home/devel/openldap/build-area/openldap2.3-2.4.10/debian/build/servers/slapd/.libs/lt-slapd: symbol lookup error: ../servers/slapd/back-meta/.libs/back_meta-2.4.so.2: undefined symbol: slap_idassert_parse_cf
>
> Is this a regression since 2.4.8?
Looks more like an incomplete fix. The functions in question haven't changed
since 2006. Since we're not using a hacked libltdl the problem you're seeing
doesn't show up here. I guess you should have tested this sooner...
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Andrew Findlay wrote:
> Indeed, though draft-behera-ldap-password-policy-xx.txt is a bit unclear
> on the subject of that attribute:
>
> 5.3.3 pwdAccountLockedTime
> The current implementation does allow
> admins to set the value, which appears to be the only way to
> lock/unlock an account without changing the password.
The current implementation allows pretty much anybody to set the attribute.
It's intended that it can only be set when using the Relax Constraints control.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/