*** Bug 1830435 has been marked as a duplicate of this bug. ***

upstream ticket https://pagure.io/389-ds-base/issue/51068

Fix pushed upstream => POST

Hello,

I am watching the RedHat IT case, do we have a fix we can provide to our customers?

Thanks,

I can look into that, but at a glance, the RHEL-7 389-ds-base hotfix would be for 1.3.10 , not 1.3.9

I made a RHEL-7.8 389-ds-base-1.3.10 hotfix , attached to the sf case number 02643823 , not much testing done on it.

I am trying to do a RHEL-7.7 389-ds-base-1.3.9 hotfix , but the koji build command I used a few minutes earlier correctly, cannot reach http://brewweb.devel.redhat.com/ at the moment, not sure what is going on.

Hello,

The fix https://pagure.io/389-ds-base/issue/51068 is easy to backport and Marc made a hotfix [1].
I initially thought the bug was rare but I am probably wrong as it happened several time recently. There is not workaround, the trigger (update of schema) can not be prevented but I think to mitigate the risk any change of schema (direct ldapmodify or upgrade of an instance with new schema) should preferably done during calm period.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1824930#c13

I made another hotfix for RHEL-7.7 389-ds-base-1.3.9.1-10 , waiting on feedback.
there was some internal outage this weekend.

Build tested: 389-ds-base-1.3.10.2-5.el7.x86_64

Steps:

1. Add 4000 entries:
ldclt -D "cn=Directory Manager" -w password -f cn=userXXXXX -b "ou=people,dc=example,dc=com" -e add,person,incr,noloop,commoncounter -r0 -R4000

2. Set small entry cache and restart dirsrv:

dn: cn=config,cn=ldbm database,cn=plugins,cn=config
changetype: modify
replace: nsslapd-cache-autosize
nsslapd-cache-autosize: 0
-
replace: nsslapd-dbcachesize
nsslapd-dbcachesize: 512001
-

3. Start search and mod loads in a different terminal:
ldclt -D "cn=Directory Manager" -w password -f cn=userXXXXX -b "ou=people,dc=example,dc=com" -e  esearch,incr,commoncounter -r0 -R4000
ldclt -D "cn=Directory Manager" -w password -f cn=userXXXXX -b "ou=people,dc=example,dc=com" -e incr,commoncounter,attreplace=description:valueXXXXXXXXXX -r0 -R4000

4. Do a schema mod:
cat schema-mod.ldif
dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( 8.9.10.11.12.13.14 NAME 'MozAttribute' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Mozilla Dummy Schema' )
-
add: objectclasses
objectclasses: ( 1.2.3.4.5.6.7 NAME 'MozillaObject' SUP top MUST ( objectclass $ cn ) MAY ( MozAttribute ) X-ORIGIN 'user defined' )"
-

ldapmodify -D cn=directory\ manager -w password  -f schema-mod.ldif

With 389-ds-base-1.3.10.2-3.el7.x86_64 schema mod operation would hang indefinitely.
With 389-ds-base-1.3.10.2-5.el7.x86_64 schema mod operation completes immediately. Marking as VERIFIED.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (389-ds-base bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:3894