Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1044203

Summary:	[RFE] Allow referint plugin to use an alternate config area
Product:	Red Hat Enterprise Linux 7	Reporter:	Nathan Kinder <nkinder>
Component:	389-ds-base	Assignee:	Rich Megginson <rmeggins>
Status:	CLOSED ERRATA	QA Contact:	Viktor Ashirov <vashirov>
Severity:	unspecified	Docs Contact:
Priority:	high
Version:	7.0	CC:	nhosoi, nkinder, vashirov
Target Milestone:	rc	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	389-ds-base-1.3.3.1-1.el7	Doc Type:	Enhancement
Doc Text:	Feature: Referential Integrity plugin can now use an alternate config area. Also, the pluginarg plugin configuration has been deprecated to use unique config attributes instead: old style: nsslapd-pluginarg0: 0 nsslapd-pluginarg1: /var/log/dirsrv/slapd-localhost/referint nsslapd-pluginarg2: 0 nsslapd-pluginarg3: member nsslapd-pluginarg4: uniquemember new style: referint-update-delay: 0 referint-logfile: /var/log/dirsrv/slapd-localhost/referint referint-logchanges: 0 referint-membership-attr: member referint-membership-attr: uniquemember New shared configuration: nsslapd-pluginConfigArea: <entry DN> The entry DN <entry DN> must be a valid entry, that contains the config settings seen above. The plugin still accepts the plugin arg configuration in the plugin entry, but not in the new shared config entry. Making config changes is dynamnic now, and does not require a server restart. For more details, see also: http://www.port389.org/docs/389ds/design/ri-plugin-configuration.html#sts=Referential%20Integrity%20Plugin%C2%A0Configuration	Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-03-05 09:33:05 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Nathan Kinder 2013-12-17 21:55:23 UTC

This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/47603

The referint plug-in currently uses it's main plug-in config entry in cn=config for the referint configuration. This doesn't allow the referint configuration to be replicated across all masters in a replicated environment.

We should add support for using an alternate config area that is in a normal backend. We already do this for other plug-ins by using nsslapd-pluginConfigArea in the main plug-in config entry.

Comment 4 Viktor Ashirov 2014-11-25 13:24:36 UTC

$ rpm -qa | grep 389
389-ds-base-1.3.3.1-9.el7.x86_64
389-ds-base-debuginfo-1.3.3.1-9.el7.x86_64
389-ds-base-libs-1.3.3.1-9.el7.x86_64

Basic functionality works for this RFE, but there is an undefined behaviour, when an pluginConfigArea entry contaning options is renamed (see test case [7])
Also see [2], there is a minor issue with missing error message. 

Test cases

[0] Create MMR setup

[1] Enable plugin on M1, restart the server
$ ldapmodify -D 'cn=Directory Manager' -w Secret123 -H ldap://localhost:1189 << EOF
dn: cn=referential integrity postoperation,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled: on
EOF

modifying entry "cn=referential integrity postoperation,cn=plugins,cn=config"

$ sudo systemctl restart dirsrv.target

$ ldapsearch -LLL -D 'cn=Directory Manager' -w Secret123 -H ldap://localhost:1189 -b 'cn=referential integrity postoperation,cn=plugins,cn=config' nsslapd-pluginEnabled
dn: cn=referential integrity postoperation,cn=plugins,cn=config
nsslapd-pluginEnabled: on

RESULT: PASS

[2] Try to add nsslapd-pluginConfigArea with inexisting DN - server should prevent it.
$ ldapmodify -D 'cn=Directory Manager' -w Secret123 -H ldap://localhost:1189 << EOF
dn: cn=referential integrity postoperation,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginConfigArea
nsslapd-pluginConfigArea: cn=referintConfig,dc=example,dc=com
EOF

modifying entry "cn=referential integrity postoperation,cn=plugins,cn=config"
ldap_modify: Operations error (1)

RESULT: PASS
Buth there is no message in the error logs saying what's wrong. It would be nice to have one similar to messages in [3]

[3] Add config area without the required args

$ ldapmodify -D 'cn=Directory Manager' -w Secret123 -H ldap://localhost:1189 -a << EOF
dn: cn=referintConfig,dc=example,dc=com
objectClass: extensibleObject
objectClass: nsContainer
objectClass: top
cn: referintConfig
EOF

adding new entry "cn=referintConfig,dc=example,dc=com"

Try to add nsslapd-pluginConfigArea again as in [2]. It fails and server complains in the error logs: 
referint-plugin - referint_postop_del, args are NULL

RESULT: PASS

[4] Add config area with some required args
Repeat [3] adding to cn=referintConfig required attributes. When one of them is missing, server complains about it in the error logs:
referint-plugin - Plugin configuration is missing referint-update-delay
referint-plugin - Plugin configuration is missing referint-logfile
referint-plugin - Plugin configuration is missing referint-logchanges

RESULT: PASS

[5] Add config area with all required args
$ ldapmodify -D 'cn=Directory Manager' -w Secret123 -H ldap://localhost:1189 -a << EOF
dn: cn=referintConfig,dc=example,dc=com
objectClass: extensibleObject
objectClass: nsContainer
objectClass: top
cn: referintConfig
referint-update-delay: 0
referint-logfile: /var/log/dirsrv/slapd-M1/referint
referint-logchanges: 0
referint-membership-attr: member
referint-membership-attr: uniquemember
referint-membership-attr: owner
referint-membership-attr: seeAlso
EOF

adding new entry "cn=referintConfig,dc=example,dc=com"

$ ldapmodify -D 'cn=Directory Manager' -w Secret123 -H ldap://localhost:1189 << EOF
dn: cn=referential integrity postoperation,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginConfigArea
nsslapd-pluginConfigArea: cn=referintConfig,dc=example,dc=com
EOF

modifying entry "cn=referential integrity postoperation,cn=plugins,cn=config"

RESULT: PASS

[6]. Check that nsslapd-pluginConfigArea overrrides cn=config plugin options:
[6.1]
Remove referint-membership-attr: uniquemember from cn=config plugin configuration
referint-membership-attr: uniquemember should be present in pluginConfigArea

$ ldapsearch -LLL -D 'cn=Directory Manager' -w Secret123 -H ldap://localhost:1189 -b 'cn=referential integrity postoperation,cn=plugins,cn=config' referint-membership-attr
dn: cn=referential integrity postoperation,cn=plugins,cn=config
referint-membership-attr: member
referint-membership-attr: owner
referint-membership-attr: seeAlso

$ ldapsearch -LLL -D 'cn=Directory Manager' -w Secret123 -H ldap://localhost:1189 -b 'cn=referintConfig,dc=example,dc=com' referint-membership-attr
dn: cn=referintConfig,dc=example,dc=com
referint-membership-attr: member
referint-membership-attr: uniquemember
referint-membership-attr: owner
referint-membership-attr: seeAlso

[6.2] Modify an entry that is a member of groupOfUniqueNames - uniqueMember should be updated accordingly
Before update:
$ ldapsearch -LLL -D 'cn=Directory Manager' -w Secret123 -H ldap://localhost:1189 -b 'cn=group1,ou=People,dc=example,dc=com' uniqueMember
dn: cn=group1,ou=People,dc=example,dc=com
uniqueMember: cn=user1,ou=People,dc=example,dc=com
uniqueMember: cn=user2,ou=People,dc=example,dc=com

Modify an entry:
$ ldapmodify -D 'cn=Directory Manager' -w Secret123 -H ldap://localhost:1189  << EOF
dn: cn=user1,ou=People,dc=example,dc=com
changetype: modrdn
newrdn: cn=user1_modified
deleteoldrdn: 1
newsuperior: ou=People,dc=example,dc=com
EOF
modifying rdn of entry "cn=user1,ou=People,dc=example,dc=com"

After update:
$ ldapsearch -LLL -D 'cn=Directory Manager' -w Secret123 -H ldap://localhost:1189 -b 'cn=group1,ou=People,dc=example,dc=com' uniqueMember
dn: cn=group1,ou=People,dc=example,dc=com
uniqueMember: cn=user2,ou=People,dc=example,dc=com
uniqueMember: cn=user1_modified,ou=people,dc=example,dc=com

[6.3] Remove referint-membership-attr: uniquemember from pluginConfigArea

$ ldapmodify -D 'cn=Directory Manager' -w Secret123 -H ldap://localhost:1189  << EOF
dn: cn=referintConfig,dc=example,dc=com
changetype: modify
replace: referint-membership-attr
referint-membership-attr: member
referint-membership-attr: owner
referint-membership-attr: seeAlso
EOF
modifying entry "cn=referintConfig,dc=example,dc=com"

[6.4] Modify entry that is a member of groupOfUniqueNames - uniqueMember should not be updated

$ ldapmodify -D 'cn=Directory Manager' -w Secret123 -H ldap://localhost:1189  << EOF
dn: cn=user2,ou=People,dc=example,dc=com
changetype: modrdn
newrdn: cn=user2_modified
deleteoldrdn: 1
newsuperior: ou=People,dc=example,dc=com
EOF
modifying rdn of entry "cn=user2,ou=People,dc=example,dc=com"

After update: 
$ ldapsearch -LLL -D 'cn=Directory Manager' -w Secret123 -H ldap://localhost:1189 -b 'cn=group1,ou=People,dc=example,dc=com' uniqueMember
dn: cn=group1,ou=People,dc=example,dc=com
uniqueMember: cn=user2,ou=People,dc=example,dc=com
uniqueMember: cn=user1_modified,ou=people,dc=example,dc=com


RESULT: PASS


[7] Test MODRDN on PluginConfigArea for referint
PluginConfigArea contains
referint-membership-attr: member
referint-membership-attr: uniquemember
referint-membership-attr: owner
referint-membership-attr: seeAlso

cn=referential integrity postoperation,cn=plugins,cn=config contains
referint-membership-attr: member
referint-membership-attr: owner
referint-membership-attr: seeAlso

MODRDN on entries updates uniqueMember in groupOfUniqueNames as expected.

[7.1] 
Rename cn=referintConfig,dc=example,dc=com to cn=referintConfig_disabled,dc=example,dc=com
Do MODRDN on entry that is a member of groupOfUniqueNames - server updates groupOfUniqueNames -> FAIL

In my opinion, this is undefined behaviour, since server doesn't have valid runtime configuration for referint (pluginConfigArea points to inexisting dn, but options from it were used)
Possible solutions:
a) Server should not allow renaming of dn that is a value of pluginConfigArea.
b) Server should fall back to cn=config options, if pluginConfigArea contains invalid dn during runtime.
c) Server should maintain integrity of pluginConfigArea.

[7.2] 
Remove from cn=referintConfig_disabled referint-membership-attr: uniquemember.
Rename it back to cn=referintConfig.
Do MODRDN on entry that is a member of groupOfUniqueNames - server updates groupOfUniqueNames, but there is no uniquemember in referint-membership-attr -> FAIL

[7.3] 
Add back referint-membership-attr: uniquemember.
Do MODRDN on entry that is a member of groupOfUniqueNames - server updates groupOfUniqueNames -> PASS

[7.4]
Remove referint-membership-attr: uniquemember.
Do MODRDN on entry that is a member of groupOfUniqueNames - server doesn't update it, as expected -> PASS

RESULT: FAIL

Comment 5 Sankar Ramalingam 2014-12-08 11:11:43 UTC

Marking it as Verified since the basic functionality works fine. Only moving/renaming of configuration entry fails. Requesting Viktor to open a new bug for the failed test case.

Comment 6 Viktor Ashirov 2014-12-08 11:45:18 UTC

New bug: https://bugzilla.redhat.com/show_bug.cgi?id=1171682

Comment 8 errata-xmlrpc 2015-03-05 09:33:05 UTC

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, 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://rhn.redhat.com/errata/RHSA-2015-0416.html