Bug 202843 - referential integrity plugin does not stack with Class of Service appliance
referential integrity plugin does not stack with Class of Service appliance
Product: 389
Classification: Community
Component: Database - General (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Noriko Hosoi
Viktor Ashirov
Depends On:
Blocks: 152373 240316 FDS1.1.0
  Show dependency treegraph
Reported: 2006-08-16 14:36 EDT by Hai Zaar
Modified: 2015-12-07 12:12 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-12-07 12:12:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
LDIF for bug reproduction (3.62 KB, text/plain)
2006-08-16 14:36 EDT, Hai Zaar
no flags Details
bug analysis and discussion (9.20 KB, text/html)
2006-12-05 13:12 EST, Noriko Hosoi
no flags Details
cvs diffs (16.07 KB, patch)
2006-12-05 22:05 EST, Noriko Hosoi
no flags Details | Diff
Fix proposal (2.69 KB, text/html)
2006-12-05 22:07 EST, Noriko Hosoi
no flags Details
Test result: CoS is called after Referential Integrity Plugin (3.13 KB, text/html)
2006-12-05 22:12 EST, Noriko Hosoi
no flags Details
cvs diffs (revised) (16.67 KB, patch)
2006-12-06 18:09 EST, Noriko Hosoi
no flags Details | Diff
cvs diff (create_inctance.c cos.c roles_plugin.c) (10.90 KB, patch)
2006-12-08 13:07 EST, Noriko Hosoi
no flags Details | Diff
cvs commit message (1.06 KB, text/plain)
2006-12-08 13:16 EST, Noriko Hosoi
no flags Details
problem description + review request (13.80 KB, text/html)
2006-12-12 01:42 EST, Noriko Hosoi
no flags Details
cvs commit message (528 bytes, text/plain)
2006-12-12 01:46 EST, Noriko Hosoi
no flags Details
Yet another side effect... (3.54 KB, text/plain)
2006-12-13 17:20 EST, Noriko Hosoi
no flags Details
cvs commit ldif2ldbm.c (526 bytes, text/plain)
2006-12-13 17:30 EST, Noriko Hosoi
no flags Details

  None (edit)
Description Hai Zaar 2006-08-16 14:36:41 EDT
Description of problem: 
When referential integrity plugin removes attributes from CoS template (for
example: uniqueMember), objects that are affected by the CoS still have that
'deleted' attribute.

If you explicitly remove desired attribute from template, then CoS-affected
entries behave as expected.

Version-Release number of selected component (if applicable):

How reproducible:
All operations were performed using Management Console

Steps to Reproduce:
1. Import attached LDIF (base DN is dc=example,dc=com).
2. Enable referential integrity plugin
3. Restart slapd.
4. Ensure that dn: cn=testgroup,ou=posixGroups,dc=example,dc=com has attributes
    uniqueMember: uid=haizaar,ou=people,dc=example,dc=com
    uniqueMember: uid=gilran,ou=people,dc=example,dc=com
   (Propagates by CoS)
5. Delete object
    dn: uid=gilran, ou=People,dc=example,dc=com
5. Ensure that dn: cn=uids,ou=posixGroups,dc=example,dc=com has only one
'uniqueMember' attribute left - referential integrity plugin should remove the
other one.
    uniqueMember: uid=haizaar,ou=people,dc=example,dc=com
Actual results:
dn: cn=testgroup,ou=posixGroups,dc=example,dc=com still has _both_
'uniqueMember' attributes, although one attribute has been removed from template!

Expected results:
Since attribute was deleted from template, objects affected by corresponding CoS
should've seen this change.

Additional info:
Comment 1 Hai Zaar 2006-08-16 14:36:41 EDT
Created attachment 134332 [details]
LDIF for bug reproduction
Comment 2 Noriko Hosoi 2006-12-05 13:12:52 EST
Created attachment 142873 [details]
bug analysis and discussion
Comment 3 Noriko Hosoi 2006-12-05 21:42:31 EST
Comment from Pete:
You can use the start dependency code as a model for call ordering - the plugins
just need to be inserted in the list in the right order initially - they will
never have to be updated so no other code changes. 
Comment 4 Noriko Hosoi 2006-12-05 22:05:01 EST
Created attachment 142912 [details]
cvs diffs

Comment 5 Noriko Hosoi 2006-12-05 22:07:18 EST
Created attachment 142913 [details]
Fix proposal
Comment 6 Noriko Hosoi 2006-12-05 22:12:29 EST
Created attachment 142914 [details]
Test result: CoS is called after Referential Integrity Plugin

Attachment referred by the previous comment.
Comment 7 Noriko Hosoi 2006-12-05 22:20:14 EST
Sorry, it's confusing, isn't it?  Let me clarify some more.
Comment #4 is the diffs for the reviews.  
Comment #5 is the description for the diffs.  
Comment #6 shows just ordering the plugins was not enough for updating the CoS
cache.  So, Comment #6 is a sort of codicil.
Comment 8 Noriko Hosoi 2006-12-06 02:55:37 EST
Comment on attachment 142912 [details]
cvs diffs

found a bug in plugin_create_pluginlist:
+plugin_create_pluginlist( Slapi_Entry *plugin_entry, char *attr_name, 
+					 struct slapdplugin *plugin, struct
slapdplugin **plugin_list)
+	 Slapi_Attr *attr = 0;
+	 int hint =0;
+	 int num_vals = 0;
+	 int val_index = 0;
+	 Slapi_Value *val;
+	 if( 0 == slapi_entry_attr_find( plugin_entry, attr_name, &attr ))
+	 {
+		 /* allocate memory for the string array */
+		 slapi_attr_get_numvalues( attr, &num_vals );
+		 if(num_vals)
+		 {
+			 hint = slapi_attr_first_value( attr, &val );
+			 while(val_index < num_vals)
+			 {
+				 /* add the plugin to the list at the place
befores */
+				 add_plugin_to_list_after( plugin_list, plugin,
slapi_value_get_string(val) );
+				 hint = slapi_attr_next_value( attr, hint, &val
+				 val_index++;
+			 }
+		 }

This does not work when multiple nsslapd-plugin-depends-on-call is set in one
plugin entry.

I'll fix it and send out a review request again.
Comment 9 Noriko Hosoi 2006-12-06 18:09:23 EST
Created attachment 143004 [details]
cvs diffs (revised)

Fixed a bug reported in the previous comment.
That is, added a code to delete the plugin if the plugin is already in the list
before the plugin with "name".

+static void
+add_plugin_to_list_after(struct slapdplugin **list,
+						  struct slapdplugin *plugin,
const char *name)
	 struct slapdplugin **tmp;
-	 for ( tmp = list; *tmp; tmp = &(*tmp)->plg_next )
+	 PR_ASSERT(name && *name);
+	 for ( tmp = list; tmp && *tmp; tmp = &(*tmp)->plg_next )
+		 if (!strcasecmp(plugin->plg_name, (*tmp)->plg_name)) {
+			 /* plugin is already in the list before the plugin
with "name".
+			    delete it first */
+			 *tmp = (*tmp)->plg_next;
+			 if (NULL == *tmp)
+				 break;
+		 }
+		 else if (!strcasecmp(name, (*tmp)->plg_name))
Comment 10 Noriko Hosoi 2006-12-08 12:59:42 EST
Based upon the following advice from Rich, fixed in the different way.

Richard Megginson wrote:
> Could we solve this problem by having CoS (and probably Roles too) register
part of the problem is that CoS is not notified of changes during internal
operations - SLAPI_PLUGIN_INTERNAL_POST_op_FN might take care of that.
> If that doesn't work, maybe we could use some sort of generic entry state
change notification method.  I had forgotten about the statechange plugin which
could be used for this purpose.  It would work something like this:
> CoS (and Roles too, I think) registers an entry state change callback using
the slapi_apib interface.  With CoS, this can just simply call cos_post_op. 
Then, we change the internal_modify, internal_modrdn, internal_add, and
internal_delete functions to call this entry post change function using the apib
> I see.  Then can we register CoS as a "object" plugintype?  Several other
plug-ins take this approach, which need to register callbacks for preop, postop,
and other types.  For example, see the repl5_init.c - the main
replication_multimaster_plugin_init() calls slapi_register_plugin() with the
different types of plugins it wants to register as. 
Comment 11 Noriko Hosoi 2006-12-08 13:07:45 EST
Created attachment 143177 [details]
cvs diff (create_inctance.c cos.c roles_plugin.c)


1) registered cos_post_op and roles_post_op as SLAPI_PLUGIN_INTERNAL_POST_op_FN
2) changed the plugin type of CoS and Roles from "postoperation" to "object".
Comment 12 Noriko Hosoi 2006-12-08 13:11:01 EST
Richard Megginson wrote:
> Looks good.  Ship it! 

Thank you, Rich!!
Comment 13 Noriko Hosoi 2006-12-08 13:16:56 EST
Created attachment 143178 [details]
cvs commit message

Checked in into HEAD.
Comment 14 Noriko Hosoi 2006-12-12 01:42:06 EST
Created attachment 143368 [details]
problem description + review request
Comment 15 Noriko Hosoi 2006-12-12 01:46:08 EST
Created attachment 143369 [details]
cvs commit message

Reviewed by Rich (Thank you!)

Checked in into HEAD.
Comment 16 Noriko Hosoi 2006-12-13 17:20:01 EST
Created attachment 143568 [details]
Yet another side effect...

Comments from Rich:
I worry that there is some cleanup that we won't do if we skip the
plugin_closeall, but then we don't have any plugins (other than the database)
that run in db2ldif mode.  I guess let's see if the acceptance tests like the

I'm going to check in ldif2ldbm.c (with the dblayer_close call removed) and
check the acceptance results tomorrow.
Comment 17 Noriko Hosoi 2006-12-13 17:30:49 EST
Created attachment 143569 [details]
cvs commit ldif2ldbm.c

Checked in into HEAD.

I'm running the acceptance tests on 32-bit/64-bit RHEL4 from now...
Comment 20 Michael Gregg 2007-11-15 20:01:11 EST
verified aginst:
1193765112 idm-console-framework-1.1.0-5.el5idm Tue Oct 30 2007 
1193765112 redhat-idm-console-1.0.0-13.el5idm Tue Oct 30 2007 
1194380792 tftp-0.42-3.1 Tue Nov 06 2007 
1195006662 subversion-1.4.2-2.el5 Tue Nov 13 2007 
1195174828 redhat-ds-base-8.0.0-11.el5dsrv Thu Nov 15 2007 

Note You need to log in before you can comment on or make changes to this bug.