*** 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