Andrey Ivanov wrote: > Hi, > > we use the referential integrity plug-in successfully in the > configuration of 3 replicated read-write master servers. The plug-in > is enabled on each server, the configuration is : > > dn: cn=referential integrity postoperation,cn=plugins,cn=config > objectClass: top > objectClass: nsSlapdPlugin > objectClass: extensibleObject > cn: referential integrity postoperation > nsslapd-pluginPath: libreferint-plugin > nsslapd-pluginInitfunc: referint_postop_init > nsslapd-pluginType: postoperation > nsslapd-pluginEnabled: on > nsslapd-pluginarg0: 3600 > nsslapd-pluginarg1: > /Local/dirsrv/var/lib/dirsrv/slapd-ens/db/refer_integrity_ > log > nsslapd-pluginarg2: 0 > nsslapd-pluginarg3: ou > nsslapd-pluginarg4: member > nsslapd-pluginarg5: uniquemember > nsslapd-pluginarg6: owner > nsslapd-plugin-depends-on-type: database > nsslapd-pluginId: referint > nsslapd-pluginVersion: 1.1.3 > nsslapd-pluginVendor: Fedora Project > nsslapd-pluginDescription: referential integrity plugin > nsslapd-pluginarg7: seeAlso > nsslapd-pluginarg8: manager > nsslapd-pluginarg9: secretary > > > The attributes monitored by the plug-in in our case are, as you can see : > ou > member > uniquemember > owner > seeAlso > manager > secretary > > We have also put a 1-hour (3600s) pause between the modification of > the attribute and the cascading changes in referencing attributes. It > is a precaution in case the modification was erroneous, in this case > we can delete the referint file to avoid the trigger of changes. > > All these attributes contain the DN of other entries. It is important. > I am not sure that your "memberuid" attribute contains the WHOLE DN > (not just the RDN part). Your /var/log/dirsrv/slapd-us72/referint file > should be writeable by the user of the ldap server (as well as the > folder /var/log/dirsrv/slapd-us72/). The file is created > automatically, you don't need to do anything manually. The plug-in > should also be activated (be default i think it is disabled). > > There is however a bug in the plug-in - only the first rename of the > entry will be taken into account > (https://bugzilla.redhat.com/show_bug.cgi?id=431607). So for the > production purposes we use the patched version. > > > Hope it helps you... > > Andrey, John, Thanks for the feedback, it help immensely! I've followed Andrey's suggestion, and updated my version of the plugin, as I could see that bug causing us trouble down the road. My observations on getting this running were this: - Both presence and equality indexing were needed, this WAS in the doc's, I had just missed the the reference to presence. - The plug in won't work for the RDN names we have in memberUid, (we actually have both the RDN and DN listed as values under the memberUid attribute, i was hoping it would see the DN, but it didn't) which is a bummer, but does work for the other attributes, (it worked for the uniqememeber attribute as advertised which was just COOL to watch ) which is immensely helpful for other application that need it! - The Log file only existed after I set the plug in to have a delay, it existed for the amount of time between the update, and when the plugin made it's change, then it deleted the file again. That explained my confusion as to why I never saw the log! Multi Master Question: - I noted that if Multimaster A has the plugin enabled, and Multimaster B doesn't, an update to Multimaster B, doesn't ever actually key the plugin on Server A to change the associated information... so for example if server A were to be go down for a period of time, and a change that would normally key the Referential Integrity plugin to make a change, it wouldn't actually get updated, and I'd get some data Skew. Andrey indicated that he's running the plug, enabled on 3 Masters. The From the documentation, http://www.redhat.com/docs/manuals/dir-server/ag/8.0/Creating_Directory_Entries-Maintaining_Referential_Integrity.html With multi-master replication, enable the plug-in on just one supplier. And some googleing I've done: http://www.mail-archive.com/fedora-directory-users at redhat.com/msg04229.html This seems like a bad idea, but is it? How much risk do I accrue if I enable it on both of my masters? If I were to find myself in a loop, how hard is that to break, and how damaging IS that actually to my database? (meaning will it blow up the whole database somehow, or just keep writing to the attribute thats being reference... or another way to put it... "Tell him about the Twinkie Ray") On one hand, it seems like a good idea to run it on both, to keep my data from skewing, but I'd like to understand the implications of any additional risk.. Thanks again for all the help, I hope this thread helps other folks as well!! Tim
