Bjorn Oglefjorn wrote:
On 5/15/07, *Richard Megginson* <rmeggins@xxxxxxxxxx
<mailto:rmeggins@xxxxxxxxxx>> 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.
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))
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@xxxxxxxxxx <mailto:rmeggins@xxxxxxxxxx> > <mailto:rmeggins@xxxxxxxxxx <mailto:rmeggins@xxxxxxxxxx>>> 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@xxxxxxxxxx <mailto:Fedora-directory-users@xxxxxxxxxx> > <mailto:Fedora-directory-users@xxxxxxxxxx <mailto:Fedora-directory-users@xxxxxxxxxx>> > > 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@xxxxxxxxxx <mailto:Fedora-directory-users@xxxxxxxxxx> > <mailto:Fedora-directory-users@xxxxxxxxxx <mailto:Fedora-directory-users@xxxxxxxxxx>> > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > ------------------------------------------------------------------------ > > -- > Fedora-directory-users mailing list > Fedora-directory-users@xxxxxxxxxx <mailto:Fedora-directory-users@xxxxxxxxxx> > 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@xxxxxxxxxx <mailto:Fedora-directory-users@xxxxxxxxxx> https://www.redhat.com/mailman/listinfo/fedora-directory-users ------------------------------------------------------------------------ -- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
