[Fedora-directory-users] Re: Referential Integrity

Thu Feb 5 18:05:33 UTC 2009

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