Full_Name: Quanah Gibson-Mount
Version: 2.4.43
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (47.208.148.239)
When using glued/subordinate databases, the "limits" directive needs to be set
on the parent as well as subordinate dbs to be applied if there are global
limits in place. This is currently not documented. Otherwise, the "limits"
directive settings on the subordinate databases is not honored.
Full_Name: Quanah Gibson-Mount
Version: HEAD
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (47.208.148.239)
While you can set olcMemberOfRefInt during an add operation when instantiating
slapo-memberOf with cn=config, you cannot modify the value after that point.
Attempting to change the value results in:
Running ldapmodify to change olcMemberOfRefInt value
ldapmodify failed (80)!
slapd log shows:
592ef748 <<< dnPrettyNormal:
<olcOverlay={0}memberof,olcDatabase={1}bdb,cn=config>,
<olcOverlay={0}memberof,olcDatabase={1}bdb,cn=config>
592ef748 conn=1003 op=1 modifications:
592ef748 replace: olcMemberOfRefInt
592ef748 one value, length 5
592ef748 conn=1003 op=1 MOD
dn="olcOverlay={0}memberof,olcDatabase={1}bdb,cn=config"
592ef748 conn=1003 op=1 MOD attr=olcMemberOfRefInt
592ef748 slap_queue_csn: queueing 0x7f326010add0
20170531170304.816445Z#000000#000#000000
592ef748 oc_check_required entry
(olcOverlay={0}memberof,olcDatabase={1}bdb,cn=config), objectClass
"olcMemberOf"
592ef748 oc_check_allowed type "objectClass"
592ef748 oc_check_allowed type "olcOverlay"
592ef748 oc_check_allowed type "olcMemberOfGroupOC"
592ef748 oc_check_allowed type "olcMemberOfMemberAD"
592ef748 oc_check_allowed type "olcMemberOfMemberOfAD"
592ef748 oc_check_allowed type "structuralObjectClass"
592ef748 oc_check_allowed type "entryUUID"
592ef748 oc_check_allowed type "creatorsName"
592ef748 oc_check_allowed type "createTimestamp"
592ef748 oc_check_allowed type "olcMemberOfRefInt"
592ef748 oc_check_allowed type "entryCSN"
592ef748 oc_check_allowed type "modifiersName"
592ef748 oc_check_allowed type "modifyTimestamp"
592ef748 send_ldap_result: conn=1003 op=1 p=3
592ef748 send_ldap_result: err=80 matched="" text=""
592ef748 send_ldap_response: msgid=2 tag=103 err=80
ber_flush2: 14 bytes to sd 8
592ef748 conn=1003 op=1 RESULT tag=103 err=80 qtime=0.000020 etime=0.816572
text=
592ef748 slap_graduate_commit_csn: removing 0x7f326010add0
20170531170304.816445Z#000000#000#000000
592ef748 connection_get(8)
gnoe(a)symas.com wrote:
> Full_Name: Gregory Noe
> Version:
> OS:
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (63.142.209.94)
>
>
> Update mdb_load to safely load back-mdb databases. Currently back-mdb's custom
> sort functions don't order database items in the correct order.
Actually no, this ITS is about tweaking back-mdb to give mdb_load a better
hint about what ordering to use. In particular, the id2v table in master/RE25
isn't being reloaded in proper order at the moment.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--On Wednesday, May 24, 2017 3:14 PM +0000 nespor(a)id.ethz.ch wrote:
> I am not quite sure, if it is really the same problem. I do not use the
> Red Hat openldap package.
> I have downloaded openldap-2.4.44.tgz on January 5, 2017, and compiled
> myself.
Yes, it was fixed in May of 2016 (2.4.44 was released February of 2016).
So it is already fixed for the next release (2.4.45).
Hope that helps.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
I am not quite sure, if it is really the same problem. I do not use the
Red Hat openldap package.
I have downloaded openldap-2.4.44.tgz on January 5, 2017, and compiled
myself.
On 05/24/17 15:48, Howard Chu wrote:
> Howard Chu wrote:
>> nespor(a)id.ethz.ch wrote:
>>> Full_Name: Vlado Nespor
>>> Version: 2.4.44
>>> OS: Red Hat el7
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (2001:67c:10ec:32d0::222)
>>>
>>>
>>> We have experienced random slapd segmentation faults, when the relay
>>> backend and rwm overlay were used in the configuration. After some
>>> time I could reproduce the segmentation fault on a slow client and
>>> with test queries, which were supposed to return a larger set of
>>> entries.
>>>
>>> I could trace the problem to a wrong pointer in the slap_writewait_play
>>> function in the openldap-2.4.44/servers/slapd/result.c file, and then
>>> further to the openldap-2.4.44/servers/slapd/back-relay/op.c file.
>>> After
>>> the addition of the sc_writewait pointer initialisation (see the patch
>>> below), the test queries returned correct results and random slapd
>>> segmentation faults disappeared.
>>
>> Thanks for the report, but this was already fixed in ITS#8218
>> released in
>> 2.4.43. Sounds like Red Hat has botched their source code since the
>> official
>> fix has been out for nearly 2 years already.
>
> Sorry, a typo on my part. It was ITS#8428.
>
Howard Chu wrote:
> nespor(a)id.ethz.ch wrote:
>> Full_Name: Vlado Nespor
>> Version: 2.4.44
>> OS: Red Hat el7
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (2001:67c:10ec:32d0::222)
>>
>>
>> We have experienced random slapd segmentation faults, when the relay
>> backend and rwm overlay were used in the configuration. After some
>> time I could reproduce the segmentation fault on a slow client and
>> with test queries, which were supposed to return a larger set of entries.
>>
>> I could trace the problem to a wrong pointer in the slap_writewait_play
>> function in the openldap-2.4.44/servers/slapd/result.c file, and then
>> further to the openldap-2.4.44/servers/slapd/back-relay/op.c file. After
>> the addition of the sc_writewait pointer initialisation (see the patch
>> below), the test queries returned correct results and random slapd
>> segmentation faults disappeared.
>
> Thanks for the report, but this was already fixed in ITS#8218 released in
> 2.4.43. Sounds like Red Hat has botched their source code since the official
> fix has been out for nearly 2 years already.
Sorry, a typo on my part. It was ITS#8428.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/