On Thu, 2009-02-05 at 12:55 -0500, Tim Hartmann wrote: > > 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!! <snip> I do appreciate your willingness to slog this out in public. It does serve as unofficial documentation for others. Thanks - John -- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 jsullivan at opensourcedevel.com http://www.spiritualoutreach.com Making Christianity intelligible to secular society
