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://lists.fedoraproject.org/pipermail/389-users/attachments/20070515/fc3c2172/attachment.html
