[Fedora-directory-users] NSUniqueID

[Bjorn Oglefjorn]

On 5/15/07, Richard Megginson <rmeggins at redhat.com> wrote:
>
> Bjorn Oglefjorn wrote:
> > On 5/15/07, *Richard Megginson* <rmeggins at redhat.com
> > <mailto:rmeggins at redhat.com>> wrote:
> >
> >     Bjorn Oglefjorn wrote:
> >     > That's the problem Richard, I'm not sure how it happens.  I can
> tell
> >     > you this much though.  I am using NSUniqueID as a globally unique
> id
> >     > for a one-way sync agreement to a specific application (from FDS
> to
> >     > the application).  The requirement for the globally unique id is
> >     that
> >     > it never changes.  If it somehow does change, the sync process
> >     > provides an error stating that the globally unique ids in FDS
> >     and the
> >     > application no longer match.  I can't determine exactly what is
> >     > causing this change, but I do know that it is happening.
> >     But how does the sync process/application determine that the unique
> ID
> >     has changed?  And is it possible that some application is writing
> >     to the
> >     nsUniqueID attribute and changing its value externally?  Are you
> using
> >     replication?
> >
> >
> > There is no application that has write access to our LDAP user tree.
> > I am using a dual multi-master replication setup.  What about
> > replication would cause the NSUniqueID to change?
> If you delete an entry then add it back with the same DN and mail value,
> it will generate a new nsUniqueID for the new entry.  Also, certain
> replication operations may generate replication conflict entries.  In
> this case, you could see two entries with the same mail attribute but
> different nsUniqueID values and different DNs.


The entry was not deleted, only the mail attribute was modified.  The RDN
contains the uid of the entry.

To check for this, do a search for each of the "duplicate" nsUniqueID
> values using a search filter like this:
> (|(nsuniqueid=value1)(objectclass=nsTombstone))
> and
> (|(nsuniqueid=value2)(objectclass=nsTombstone))


The first filter returns nothing (implying that there are no entries in the
directory with objectclass=nsTombstone).  The second filter returns the
entry in question.  That seems to be what one would normally expect if there
hadn't been a change in the nsuniqueid, correct?

>
> >     For example, does your sync app do something like this:
> >     get entry by name e.g . (uid=somename).  Store the nsUniqueID for
> >     the entry.
> >     Then later, do the same search (uid=somename) and get the
> nsUniqueID.
> >     Compare the nsUniqueID to the one stored previously.
> >
> >
> > That is nearly exactly how the sync application works.  For any entry
> > that the application keeps track of, it keeps a 'lastseen' LDIF.  on
> > the next run of the sync, a search is performed and the LDIFs are
> > compared.
> >
> >     If this is the case, is it possible that the uid for the entry has
> >     changed?
> >
> >
> > No, the only change made to the entry in question was to the 'mail'
> > attribute.
> >
> >     > --BO
> >     >
> >     > On 5/15/07, *Richard Megginson* <rmeggins at redhat.com
> >     <mailto:rmeggins at redhat.com>
> >     > <mailto:rmeggins at redhat.com <mailto:rmeggins at redhat.com>>> wrote:
> >     >
> >     >     Bjorn Oglefjorn wrote:
> >     >     > Hello all,
> >     >     >
> >     >     > Can someone tell me, does the NSUniqueID attribute ever
> >     change for a
> >     >     > given entry in the directory?
> >     >     No.
> >     >     > If so (I've seen it happen),
> >     >     Can you describe exactly what you saw and how to reproduce it?
> >     >     > what are the criteria that prompt NSUniqeID to change?
> >     >     >
> >     >     > Thanks,
> >     >     > BO
> >     >     >
> >     >
> >
> ------------------------------------------------------------------------
> >     >     >
> >     >     > --
> >     >     > Fedora-directory-users mailing list
> >     >     > Fedora-directory-users at redhat.com
> >     <mailto:Fedora-directory-users at redhat.com>
> >     >     <mailto:Fedora-directory-users at redhat.com
> >     <mailto:Fedora-directory-users at redhat.com>>
> >     >     >
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >     >     <
> >     https://www.redhat.com/mailman/listinfo/fedora-directory-users>
> >     >     >
> >     >
> >     >     --
> >     >     Fedora-directory-users mailing list
> >     >     Fedora-directory-users at redhat.com
> >     <mailto:Fedora-directory-users at redhat.com>
> >     >     <mailto:Fedora-directory-users at redhat.com
> >     <mailto:Fedora-directory-users at redhat.com>>
> >     >     https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >     >
> >     >
> >     >
> >     >
> >
> ------------------------------------------------------------------------
> >     >
> >     > --
> >     > Fedora-directory-users mailing list
> >     > Fedora-directory-users at redhat.com
> >     <mailto:Fedora-directory-users at redhat.com>
> >     > https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >     <https://www.redhat.com/mailman/listinfo/fedora-directory-users>
> >     >
> >
> >     --
> >     Fedora-directory-users mailing list
> >     Fedora-directory-users at redhat.com
> >     <mailto:Fedora-directory-users at redhat.com>
> >     https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > --
> > Fedora-directory-users mailing list
> > Fedora-directory-users at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-directory-users/attachments/20070515/fc3c2172/attachment.htm>