Full_Name: Breno Leitao
Version: upstream
OS: Debian
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (32.104.18.202)
Currently, do_random() function in tests/progs/slapd-mtread.c uses a random
number (upto RAND_MAX) to access an array that is much smaller than RAND_MAX,
causing a segfault.
This causes a segmentation fault and more details could be found at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866122
Full_Name: Huy Nguyen
Version: 2.4.45
OS: AIX 7.1
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (195.6.223.9)
After running configure and make depend, make fails with the following message
:
./../../../libraries/liblmdb/mdb.c:4853:53: error: 'PTHREAD_MUTEX_ROBUST'
undeclared (first use in this function)
if (!rc) rc = pthread_mutexattr_setrobust(&mattr, PTHREAD_MUTEX_ROBUST);
It appears AIX 7?1 doesn't have robust mutexes
(https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.genpr…).
Disabling robust mutexes with CPPFLAGS="-DMDB_USE_ROBUST=0" works fine.
Full_Name: Quanah Gibson-Mount
Version: RE24
OS: N/A
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (47.208.148.239)
The back-meta(5) man page discusses the following option:
client-pr {accept-unsolicited|DISABLE|<size>}
This feature allows one to use RFC 2696 Paged Results control
when performing search operations with a specific target,
irrespective of the client's request. When set to a numeric
value, Paged Results control is always used with size as the
page size. When set to accept-unsolicited, unsolicited Paged
Results control responses are accepted and honored for
compatibility with broken remote DSAs. The client is not
exposed to paged results handling between slapd-meta(5) and the
remote servers. By default (disabled), Paged Results control is
not used and responses are not accepted. If set before any
target specification, it affects all targets, unless overridden
by any per-target directive.
However, this feature is actually disabled by default, as it is #ifdef'd behind
LDAP_DEVEL in back-meta.h:
#ifdef LDAP_DEVEL
#define SLAPD_META_CLIENT_PR 1
#endif /* LDAP_DEVEL */
So we need to determine if either:
(a) The documentation should be removed from the man page,
or
(b) The feature should be enabled by default, and moved out from behind
LDAP_DEVEL
Full_Name: G.ran Hammarb.ck
Version: 2.4.45
OS: AIX and Solaris
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (192.71.43.2)
Man pages are incorrectly formatted on AIX and Solaris.
The problem is that the .BR directive only takes 6 arguments on these platforms
and some man pages (.e.g ldapadd.1, ldapmodify.1 and ldapsearch.1) use more
arguments.
It is known to affect the options -s, -a, -e and -E.
For example, in ldapsearch.1, the line
.BR \-s \ { base \||\| one \||\| sub \||\| children }]
will be formatted as:
-s {base|sub|
The fix is to break up the line in ldapsearch.1 as e.g:
.BR \-s \ {\c
.BR base \||\| one \||\|\c
.BR sub \||\| children }]
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
--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>
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?
Full_Name: Quanah Gibson-Mount
Version: N/A
OS: N/A
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (47.208.148.239)
Download page needs updating to:
a) Have links to the checksums for the release tarballs
b) Have an encrypted download link option
Full_Name: Howard Chu
Version: 2.4
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (78.155.231.31)
Submitted by: hyc
Related to ITS#7329
Recalculating the index values can be quite expensive when deleting a value from
an attribute with many values. For 2.5 we should fix this by storing reference
counts with each index slot.
--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>