(ITS#8681) dynlist overlay fails to generate attributes when paging is used
by jengelh@inai.de
Full_Name: Jan Engelhardt
Version: 2.4.44, 2.4.45
OS: Linux 4.11, openSUSE Tumbleweed 20170626
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (77.178.174.83)
I observed that the dynlist overlay fails to generate its attributes for certain
DNs. Ultimately it appears to relate to the chosen page size with which the
database is queried; the smaller, the more often it occurs.
Reproduce as follows:
1. Set up dynlist in slapd.conf for the database:
include rfc2307bis.schema
include dyngroup.schema
database hdb
suffix o=da
index objectClass eq
rootdn cn=root,o=da
overlay dynlist
dynlist-attrset posixAccount labeledURI memberOf
2. Construct some entries, such as:
dn: cn=users,o=da
member: uid=foo,o=da
cn: users
objectClass: groupOfNames
objectClass: top
objectClass: posixGroup
gidNumber: 1555
description: users
memberUid: foo
dn: uid=foo,o=da
objectClass: top
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
cn: foo
displayName: Foo
givenName: foo
sn: foo
uid: foo
mail: foo(a)dagent.lh
gidNumber: 1555
homeDirectory: /home/foo
uidNumber: 25122
labeledURI: ldap:///o=da??sub?(&(objectClass=posixGroup)(memberUid=foo))
3. Query database with a sufficiently small page size:
## ldapsearch -xb o=da -E pr=1
dn: o=da [
a little trimmed for brevity]
control: 1.2.840.113556.1.4.319 false MA0CAQAECAEAAAAAAAAA
pagedresults: cookie=AQAAAAAAAAA=
dn: cn=root,o=da [
]
pagedresults: cookie=AgAAAAAAAAA=
Press [size] Enter for the next {1|size} entries.
dn: cn=users,o=da [
]
pagedresults: cookie=CAAAAAAAAAA=
Press [size] Enter for the next {1|size} entries.
dn: uid=foo,o=da
objectClass: top
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
cn: foo
displayName: Foo Beyond
givenName: foo
sn: foo
uid: foo
mail: foo(a)dagent.lh
gidNumber: 1555
homeDirectory: /home/foo
uidNumber: 25122
labeledURI: ldap:///o=da??sub?(&(objectClass=posixGroup)(memberUid=foo))
# search result
search: 5
result: 0 Success
control: 1.2.840.113556.1.4.319 false MAUCAQAEAA==
pagedresults: cookie=
With larger pagesizes or completely omitting -E pr, memberOf does appear:
labeledURI: ldap:///o=da??sub?(&(objectClass=posixGroup)(memberUid=foo))
memberOf: cn=users,o=da
6 years, 2 months
Re: (ITS#8680) OpenLDAP 2.4.45 for Windows
by quanah@symas.com
--On Friday, June 30, 2017 2:12 PM +0000 muthamma.appaiah(a)wellsfargo.com
wrote:
> Full_Name: Svetlana
> Version: 2.4.45
> OS: Windows
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (2620:160:e708:6::c)
>
>
> Hi team,
>
> Could you please help us with the source file of 2.4.45 for Windows
> operating system from your website?
Hello,
The ITS system is for reporting bugs with the OpenLDAP software. It is not
the proper location for asking for help. If you need assistance with
compiling OpenLDAP on Windows, the correct forum for asking for that help
would be the openldap-technical(a)openldap.org list.
Alternatively, I would note that my company (Symas) provides pre-built
binaries of OpenLDAP for Windows with options for support.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 2 months
Re: (ITS#8100) Empty accesslog causes issues with delta-syncrepl MMR configurations
by quanah@symas.com
--On Thursday, April 09, 2015 5:42 AM +0000 quanah(a)openldap.org wrote:
> Full_Name: Quanah Gibson-Mount
> Version: 2.4.39
> OS: Linux 2.6
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (50.25.188.166)
>
>
> When one has an MMR setup using delta-syncrepl, and the masters get into a
> situation where one is out of sync, or adding a new MMR node to an
> existing cluster, things will be broken until the new/reloaded node has a
> write op that goes to the accesslog DB. In an existing cluster, where a
> node is being reloaded, it causes all nodes to go into an endless looping
> fallback sync until that write occurs.
One possible fix for this, would be to refuse to delete the final entry in
the accesslog during the purge phase. That way, the accesslog would never
be empty. I'm not sure how difficult this would be to implement, code wise.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 3 months
Re: (ITS#8677) back-sock segfaults on CONTINUE (database sock)
by michael@stroeder.com
hyc(a)symas.com wrote:
>> When using back-sock (database sock) and the external sock listener returns
>> CONTINUE then slapd seg faults.
>>
>> Yes, returning CONTINUE is only allowed when using back-sock as overlay.
>> But slapd should not seg fault and rather return as LDAP result:
>
> No. This is a configuration error and it's appropriate to halt the server and
> force it to be fixed.
Even if I follow your argument this message does not look like the server was
deliberately halted:
slapd: result.c:83: sock_read_and_send_results: Assertion `si->si_ops != 0' failed.
./start-slapd.sh: line 21: 30179 Aborted (core dumped) ${OPENLDAP_EXEC}
-d stats,shell -h "ldap://0.0.0.0:9876 ${LDAPI_URI}" -n slapd-sock-test -f slapd.conf
Also the args and PID files are not cleaned up. I guess database environment(s) of other
backend(s) is/are also not closed in a controlled manner.
So at least it should properly log a message and shutdown cleanly.
Ciao, Michael.
6 years, 3 months
Re: (ITS#8677) back-sock segfaults on CONTINUE (database sock)
by hyc@symas.com
michael(a)stroeder.com wrote:
> Full_Name:
> Version: 2.4.45
> OS: Linux
> URL:
> Submission from: (NULL) (213.240.182.98)
>
>
> When using back-sock (database sock) and the external sock listener returns
> CONTINUE then slapd seg faults.
>
> Yes, returning CONTINUE is only allowed when using back-sock as overlay.
> But slapd should not seg fault and rather return as LDAP result:
>
> result: 80 Other (e.g., implementation specific) error
> text: CONTINUE not allowed for back-sock
No. This is a configuration error and it's appropriate to halt the server and
force it to be fixed.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
6 years, 3 months
(ITS#8677) back-sock segfaults on CONTINUE (database sock)
by michael@stroeder.com
Full_Name:
Version: 2.4.45
OS: Linux
URL:
Submission from: (NULL) (213.240.182.98)
When using back-sock (database sock) and the external sock listener returns
CONTINUE then slapd seg faults.
Yes, returning CONTINUE is only allowed when using back-sock as overlay.
But slapd should not seg fault and rather return as LDAP result:
result: 80 Other (e.g., implementation specific) error
text: CONTINUE not allowed for back-sock
6 years, 3 months
Re: (ITS#8676) openldap source uses implicit functoin declarations
by h.b.furuseth@usit.uio.no
On 19. juni 2017 23:19, slyfox(a)gentoo.org wrote:
> Why those are problems? implicit function declarations mean the
> function type will be defaulted to int(int, int). > For functions like
> int slap_sasl_cbinding( Connection *conn, struct berval *cbv );
> it might cause pointer-to-int truncation on 64-bit platforms.
No, implicit declarations are defaulted to int(), and function call
args are not converted other than integer promotions. So it's not a
problem when the function are called with args of the correct types.
But yeah, it won't hurt to clean up.
--
Hallvard
6 years, 3 months