Fedora directory users - Jan 2009 - Referential Integrity

So After my trials and tribulations with " Referrals for Update
Operations"  (thanks again, you guys rock!) hence  known as
"Tim''s
continuing  LDAP Saga and Viking Cha-Cha"

I came across "Referential Integrity" in the docs, and boy howdy does
it
look useful!
http://www.redhat.com/docs/manuals/dir-server/ag/8.0/Creating_Directory_Entries-Maintaining_Referential_Integrity.html

I had a couple of concerns, before I enabled it that I was hoping people
could chime in on!


1) I''d like to have Referential Integrity monitor the memberUid field
as
well, but I was unclear in the documentation if when scanning the
directory if it scans ALL the directories hosted by a given server, or
just searches in the directory where the user was deleted?

for example, I have two root suffixes,  both of which contain  users and
groups ,  and more often then we''d like user "foo" exists in
both...

dc=example,dc=edu

dc=dept,dc=example,dc=edu

if I delete user uid=foo,ou=People,dc=dept,dc=example,dc=edu

would the Referential Integrity plug in know to leave  any instance of 
"uid=foo" and "memberUid=foo" in the dc=example,dc=edu
branch alone?


2) I have 2 Masters (set up to be Multi Masters) and 4 Replica''s, 
There
are a number of warnings about setting this up only on 1 of the Masters
(which shouldn''t be a problem), in the case that M1 is configured with
the Referential Integrity plug in, and it goes down for some amount of
time, and a user is deleted, will the plugin "Catch up" once M1 has
been
brought back online?


Thanks for the input!


Tim

I folks,

Did anyone have any thoughts on this? If not, I think I''ll just enable
it and start testing....  :) 

Tim


Tim Hartmann wrote:
> So After my trials and tribulations with " Referrals for Update
> Operations"  (thanks again, you guys rock!) hence  known as
"Tim''s
> continuing  LDAP Saga and Viking Cha-Cha"
>
> I came across "Referential Integrity" in the docs, and boy howdy
does it
> look useful!
>
http://www.redhat.com/docs/manuals/dir-server/ag/8.0/Creating_Directory_Entries-Maintaining_Referential_Integrity.html
>
> I had a couple of concerns, before I enabled it that I was hoping people
> could chime in on!
>
>
> 1) I''d like to have Referential Integrity monitor the memberUid
field as
> well, but I was unclear in the documentation if when scanning the
> directory if it scans ALL the directories hosted by a given server, or
> just searches in the directory where the user was deleted?
>
> for example, I have two root suffixes,  both of which contain  users and
> groups ,  and more often then we''d like user "foo"
exists in both...
>
> dc=example,dc=edu
>
> dc=dept,dc=example,dc=edu
>
> if I delete user uid=foo,ou=People,dc=dept,dc=example,dc=edu
>
> would the Referential Integrity plug in know to leave  any instance of 
> "uid=foo" and "memberUid=foo" in the dc=example,dc=edu
branch alone?
>
>
> 2) I have 2 Masters (set up to be Multi Masters) and 4 Replica''s, 
There
> are a number of warnings about setting this up only on 1 of the Masters
> (which shouldn''t be a problem), in the case that M1 is configured
with
> the Referential Integrity plug in, and it goes down for some amount of
> time, and a user is deleted, will the plugin "Catch up" once M1
has been
> brought back online?
>
>
> Thanks for the input!
>
>
> Tim
>
>
>
>
>
>
>

Sorry I can''t be more help but I am listening! We use referential
integrity but have not yet implemented it in multi-master mode nor have
we really stressed and tested it - John

On Mon, 2009-02-02 at 11:39 -0500, Tim Hartmann wrote:
> I folks,
> 
> Did anyone have any thoughts on this? If not, I think I''ll just
enable
> it and start testing....  :) 
> 
> Tim
> 
> 
> Tim Hartmann wrote:
> > So After my trials and tribulations with " Referrals for Update
> > Operations"  (thanks again, you guys rock!) hence  known as
"Tim''s
> > continuing  LDAP Saga and Viking Cha-Cha"
> >
> > I came across "Referential Integrity" in the docs, and boy
howdy does it
> > look useful!
> >
http://www.redhat.com/docs/manuals/dir-server/ag/8.0/Creating_Directory_Entries-Maintaining_Referential_Integrity.html
> >
> > I had a couple of concerns, before I enabled it that I was hoping
people
> > could chime in on!
> >
> >
> > 1) I''d like to have Referential Integrity monitor the
memberUid field as
> > well, but I was unclear in the documentation if when scanning the
> > directory if it scans ALL the directories hosted by a given server, or
> > just searches in the directory where the user was deleted?
> >
> > for example, I have two root suffixes,  both of which contain  users
and
> > groups ,  and more often then we''d like user "foo"
exists in both...
> >
> > dc=example,dc=edu
> >
> > dc=dept,dc=example,dc=edu
> >
> > if I delete user uid=foo,ou=People,dc=dept,dc=example,dc=edu
> >
> > would the Referential Integrity plug in know to leave  any instance of
> > "uid=foo" and "memberUid=foo" in the
dc=example,dc=edu branch alone?
> >
> >
> > 2) I have 2 Masters (set up to be Multi Masters) and 4
Replica''s,  There
> > are a number of warnings about setting this up only on 1 of the
Masters
> > (which shouldn''t be a problem), in the case that M1 is
configured with
> > the Referential Integrity plug in, and it goes down for some amount of
> > time, and a user is deleted, will the plugin "Catch up" once
M1 has been
> > brought back online?
> >
> >
> > Thanks for the input!
> >
> >
> > Tim
> >
> >
> >
> >
> >
> >
> >   
> 
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

http://www.spiritualoutreach.com
Making Christianity intelligible to secular society

Well then! Let me give you my experiences so far....

So I attempted to add "memberuid" to the plugin on the master I wanted
to use it on... and that went fine. restarted the server,  I added index
on all my servers for the memberuid attribute, ( I thought I might be
able to get away with indexing on just the master that was going to run
the Referential Integrity plugin, but I figured I''d keep my
configuration as consistent as possible accross both master +
replicas).   I then enabled the plug in on the console, and then ran
"/etc/init.d/dirsrv restart" So far, i felt like I was pretty much
just
follow word for work the instructions in the manual. 

For my testing, I have:

3 Directories

dc=dept,dc=school,dc=edu
dc=sub,dc=school,dc=edu
cn=Databaseinfo,dc=school,dc=edu

All three server diffrent clients, though some user name overlap, and a
change in one, shouldn''t necessarily be reflected in it''s
neighbor.

For testing I have a user I want to delete in dept

uid=User,ou=People,dc=dept,dc=school,dc=edu
and he''s a member of a Posix style group in depts as (under the base
ou=Group,dc=dept,dc=school,dc=edu_ and the same username (User) is a
member of a similar group under ou=Group,dc=school,dc=edu, I added him
there to see if the plug in would traverse directories or not.

The things I noticed after I restarted and delete the user were this:

First, once I deleted the user, my redhat-idm-console interface went a
little wonky, only rendering part of the screen until I  did a "refresh
all " from  the view menu ,  It also spit out to STDOUT the following
java errors, which it''s never done before:


Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
    at
javax.swing.plaf.basic.BasicTreeUI.ensureRowsAreVisible(BasicTreeUI.java:1904)
    at
javax.swing.plaf.basic.BasicTreeUI.toggleExpandState(BasicTreeUI.java:2223)
    at
javax.swing.plaf.basic.BasicTreeUI.handleExpandControlClick(BasicTreeUI.java:2206)
    at
javax.swing.plaf.basic.BasicTreeUI.checkForClickInExpandControl(BasicTreeUI.java:2160)
    at
javax.swing.plaf.basic.BasicTreeUI$Handler.handleSelectionImpl(BasicTreeUI.java:3498)
    at
javax.swing.plaf.basic.BasicTreeUI$Handler.handleSelection(BasicTreeUI.java:3483)
    at
javax.swing.plaf.basic.BasicTreeUI$Handler.mousePressed(BasicTreeUI.java:3464)
    at
java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:254)
    at
java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:253)
    at java.awt.Component.processMouseEvent(Component.java:5544)
    at javax.swing.JComponent.processMouseEvent(JComponent.java:3148)
    at java.awt.Component.processEvent(Component.java:5312)
    at java.awt.Container.processEvent(Container.java:2001)
    at java.awt.Component.dispatchEventImpl(Component.java:4014)
    at java.awt.Container.dispatchEventImpl(Container.java:2059)
    at java.awt.Component.dispatchEvent(Component.java:3847)
    at
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4249)
    at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3926)
    at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3859)
    at java.awt.Container.dispatchEventImpl(Container.java:2045)
    at java.awt.Window.dispatchEventImpl(Window.java:1812)
    at java.awt.Component.dispatchEvent(Component.java:3847)
    at java.awt.EventQueue.dispatchEvent(EventQueue.java:545)
    at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:268)
    at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:197)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:191)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:183)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:144)


Next, I noticed that /var/log/dirsrv/slapd-instance/referint

Log file did not get created, so I created an empty file, restarted the
directory,  deleted all the data out of "dept" re added it all with an
ldapmodify from a backup ldif i have for testing, and then once again
tried to delete "user"

"User" deleted ok, I saw the same behavior from the GUI interface, and
when I checked the groups that contained user, he hadn''t been removed.
Nor had any content been added to the
/var/log/dirsrv/slapd-us72/referint file.

So at the moment, it looks like Referential Integrity isn''t working at
all for me....  and i''m a little worried about the Java error, and more
sluggish behavior that my GUI Console is exiting..

Additionally, I didn''t see anything in access or error logs, that might
indicate whats going on..

Any thoughts?

Tim






John A. Sullivan III wrote:
> Sorry I can''t be more help but I am listening! We use referential
> integrity but have not yet implemented it in multi-master mode nor have
> we really stressed and tested it - John
>
>   
>

Hi, Tim.  I didn''t have time to peruse this (still under a nasty
deadline) but I was looking for one thing I didn''t see in your post.
I''m pulling this from memory so please double check it but did you
enable the presence attribute (?) for indexing on all the items listed i
the referential integrity plugin?

By the way, if I might mention it, would you kindly post to the bottom
of future threads.  Top posting makes it very difficult for newcomers to
the list to follow.  Thanks - John

On Tue, 2009-02-03 at 12:24 -0500, Tim Hartmann wrote:
> Well then! Let me give you my experiences so far....
> 
> So I attempted to add "memberuid" to the plugin on the master I
wanted
> to use it on... and that went fine. restarted the server,  I added index
> on all my servers for the memberuid attribute, ( I thought I might be
> able to get away with indexing on just the master that was going to run
> the Referential Integrity plugin, but I figured I''d keep my
> configuration as consistent as possible accross both master +
> replicas).   I then enabled the plug in on the console, and then ran
> "/etc/init.d/dirsrv restart" So far, i felt like I was pretty
much just
> follow word for work the instructions in the manual. 
> 
> For my testing, I have:
> 
> 3 Directories
> 
> dc=dept,dc=school,dc=edu
> dc=sub,dc=school,dc=edu
> cn=Databaseinfo,dc=school,dc=edu
> 
> All three server diffrent clients, though some user name overlap, and a
> change in one, shouldn''t necessarily be reflected in it''s
neighbor.
> 
> For testing I have a user I want to delete in dept
> 
> uid=User,ou=People,dc=dept,dc=school,dc=edu
> and he''s a member of a Posix style group in depts as (under the
base
> ou=Group,dc=dept,dc=school,dc=edu_ and the same username (User) is a
> member of a similar group under ou=Group,dc=school,dc=edu, I added him
> there to see if the plug in would traverse directories or not.
> 
> The things I noticed after I restarted and delete the user were this:
> 
> First, once I deleted the user, my redhat-idm-console interface went a
> little wonky, only rendering part of the screen until I  did a
"refresh
> all " from  the view menu ,  It also spit out to STDOUT the following
> java errors, which it''s never done before:
> 
> 
> Exception in thread "AWT-EventQueue-0"
java.lang.NullPointerException
>     at
>
javax.swing.plaf.basic.BasicTreeUI.ensureRowsAreVisible(BasicTreeUI.java:1904)
>     at
> javax.swing.plaf.basic.BasicTreeUI.toggleExpandState(BasicTreeUI.java:2223)
>     at
>
javax.swing.plaf.basic.BasicTreeUI.handleExpandControlClick(BasicTreeUI.java:2206)
>     at
>
javax.swing.plaf.basic.BasicTreeUI.checkForClickInExpandControl(BasicTreeUI.java:2160)
>     at
>
javax.swing.plaf.basic.BasicTreeUI$Handler.handleSelectionImpl(BasicTreeUI.java:3498)
>     at
>
javax.swing.plaf.basic.BasicTreeUI$Handler.handleSelection(BasicTreeUI.java:3483)
>     at
>
javax.swing.plaf.basic.BasicTreeUI$Handler.mousePressed(BasicTreeUI.java:3464)
>     at
> java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:254)
>     at
> java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:253)
>     at java.awt.Component.processMouseEvent(Component.java:5544)
>     at javax.swing.JComponent.processMouseEvent(JComponent.java:3148)
>     at java.awt.Component.processEvent(Component.java:5312)
>     at java.awt.Container.processEvent(Container.java:2001)
>     at java.awt.Component.dispatchEventImpl(Component.java:4014)
>     at java.awt.Container.dispatchEventImpl(Container.java:2059)
>     at java.awt.Component.dispatchEvent(Component.java:3847)
>     at
> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4249)
>     at
java.awt.LightweightDispatcher.processMouseEvent(Container.java:3926)
>     at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3859)
>     at java.awt.Container.dispatchEventImpl(Container.java:2045)
>     at java.awt.Window.dispatchEventImpl(Window.java:1812)
>     at java.awt.Component.dispatchEvent(Component.java:3847)
>     at java.awt.EventQueue.dispatchEvent(EventQueue.java:545)
>     at
>
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:268)
>     at
>
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:197)
>     at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:191)
>     at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:183)
>     at java.awt.EventDispatchThread.run(EventDispatchThread.java:144)
> 
> 
> Next, I noticed that /var/log/dirsrv/slapd-instance/referint
> 
> Log file did not get created, so I created an empty file, restarted the
> directory,  deleted all the data out of "dept" re added it all
with an
> ldapmodify from a backup ldif i have for testing, and then once again
> tried to delete "user"
> 
> "User" deleted ok, I saw the same behavior from the GUI
interface, and
> when I checked the groups that contained user, he hadn''t been
removed.
> Nor had any content been added to the
> /var/log/dirsrv/slapd-us72/referint file.
> 
> So at the moment, it looks like Referential Integrity isn''t
working at
> all for me....  and i''m a little worried about the Java error, and
more
> sluggish behavior that my GUI Console is exiting..
> 
> Additionally, I didn''t see anything in access or error logs, that
might
> indicate whats going on..
> 
> Any thoughts?
> 
> Tim
> 
> 
> 
> 
> 
> 
> John A. Sullivan III wrote:
> > Sorry I can''t be more help but I am listening! We use
referential
> > integrity but have not yet implemented it in multi-master mode nor
have
> > we really stressed and tested it - John
> >
> >   
> >
> 
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

http://www.spiritualoutreach.com
Making Christianity intelligible to secular society

John A. Sullivan III wrote:
> Hi, Tim.  I didn''t have time to peruse this (still under a nasty
> deadline) but I was looking for one thing I didn''t see in your
post.
> I''m pulling this from memory so please double check it but did you
> enable the presence attribute (?) for indexing on all the items listed i
> the referential integrity plugin?
>
> By the way, if I might mention it, would you kindly post to the bottom
> of future threads.  Top posting makes it very difficult for newcomers to
> the list to follow.  Thanks - John
>
>   
Whoops! Clearly an indication of my own newness! Bottom posting it shall
be!

Presence shows up as enabled by default in the index that I created. 
When I created the the index for memberuid both "equality" and
"presence" were preselected, so I figured I''d just stick with
the defaults.

No worries about time, thank you very much for looking at this with me
at all!  I''ll look forward to hearing from you when time permits!

Tim

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




2009/2/3 Tim Hartmann <hartmann@fas.harvard.edu>
> John A. Sullivan III wrote:
> > Hi, Tim.  I didn''t have time to peruse this (still under a
nasty
> > deadline) but I was looking for one thing I didn''t see in
your post.
> > I''m pulling this from memory so please double check it but
did you
> > enable the presence attribute (?) for indexing on all the items listed
i
> > the referential integrity plugin?
> >
> > By the way, if I might mention it, would you kindly post to the bottom
> > of future threads.  Top posting makes it very difficult for newcomers
to
> > the list to follow.  Thanks - John
> >
> >
>
> Whoops! Clearly an indication of my own newness! Bottom posting it shall
> be!
>
> Presence shows up as enabled by default in the index that I created.
> When I created the the index for memberuid both "equality" and
> "presence" were preselected, so I figured I''d just stick
with the defaults.
>
> No worries about time, thank you very much for looking at this with me
> at all!  I''ll look forward to hearing from you when time permits!
>
> Tim
>
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

On Tue, 2009-02-03 at 13:55 -0500, Tim Hartmann wrote:
> John A. Sullivan III wrote:
> > Hi, Tim.  I didn''t have time to peruse this (still under a
nasty
> > deadline) but I was looking for one thing I didn''t see in
your post.
> > I''m pulling this from memory so please double check it but
did you
> > enable the presence attribute (?) for indexing on all the items listed
i
> > the referential integrity plugin?
> >
> > By the way, if I might mention it, would you kindly post to the bottom
> > of future threads.  Top posting makes it very difficult for newcomers
to
> > the list to follow.  Thanks - John
> >
> >   
> 
> Whoops! Clearly an indication of my own newness! Bottom posting it shall
> be!
> 
> Presence shows up as enabled by default in the index that I created. 
> When I created the the index for memberuid both "equality" and
> "presence" were preselected, so I figured I''d just stick
with the defaults.
> 
> No worries about time, thank you very much for looking at this with me
> at all!  I''ll look forward to hearing from you when time permits!
<snip>
I believe it presence needs to be checked for all the fields using
referential integrity and does not default to on for the pre-existing
fields.  Again - pulling this from memory.  Good luck and thanks for
sharing your results - John
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

http://www.spiritualoutreach.com
Making Christianity intelligible to secular society

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

Tim

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@opensourcedevel.com

http://www.spiritualoutreach.com
Making Christianity intelligible to secular society

Tim Hartmann wrote:
> 
> - 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)
memberUID is not meant to hold a DN (see RFC 2307). It''s for storing
the
value of attribute ''uid'' of a member entry. If you store DNs
therein be
prepared for interop issues with pam_ldap / nss_ldap.

Ciao, Michael.

Michael Ströder wrote:
> Tim Hartmann wrote:
>   
>> - 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)
>>     
>
> memberUID is not meant to hold a DN (see RFC 2307). It''s for
storing the
> value of attribute ''uid'' of a member entry. If you store
DNs therein be
> prepared for interop issues with pam_ldap / nss_ldap.
>
> Ciao, Michael.
>
>   
Thanks Michael! Thats good info! I''ve inherited the directory, so it
may
be worthing going through and cleaning out the cob webs!

Tim