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/
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.
>
> With best regards,
>
> Vlado Nespor
>
>
> diff -rupN openldap-2.4.44/servers/slapd/back-relay/op.c
> openldap-2.4.44_back-relay/servers/slapd/back-relay/op.c
> --- openldap-2.4.44/servers/slapd/back-relay/op.c 2016-02-06 00:57:45.000000000
> +0100
> +++ openldap-2.4.44_back-relay/servers/slapd/back-relay/op.c 2017-02-07
> 15:09:55.046188340 +0100
> @@ -97,6 +97,7 @@ relay_back_response_cb( Operation *op, S
> (rcb)->rcb_sc.sc_next = (op)->o_callback; \
> (rcb)->rcb_sc.sc_response = relay_back_response_cb; \
> (rcb)->rcb_sc.sc_cleanup = 0; \
> + (rcb)->rcb_sc.sc_writewait = 0; \
> (rcb)->rcb_sc.sc_private = (op)->o_bd; \
> (op)->o_callback = (slap_callback *) (rcb); \
> }
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/