[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: [Fedora-directory-users] Re: Referential Integrity
- From: "John A. Sullivan III" <jsullivan opensourcedevel com>
- To: "General discussion list for the Fedora Directory server project." <fedora-directory-users redhat com>
- Subject: Re: [Fedora-directory-users] Re: Referential Integrity
- Date: Thu, 05 Feb 2009 13:05:33 -0500
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,
> 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
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
jsullivan opensourcedevel com
Making Christianity intelligible to secular society
[Date Prev][Date Next] [Thread Prev][Thread Next]