Bjorn Oglefjorn wrote: > On 5/15/07, *Richard Megginson* <rmeggins at redhat.com > <mailto:rmeggins at redhat.com>> wrote: > > Bjorn Oglefjorn wrote: > > 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: > > > 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. Could you perhaps post the entry before and after the modification? I would really like to see the entry with all of the replication state information. You can get this by listing the special attribute nscpEntryWsi e.g. ldapsearch .... (nsuniqueid=value) nscpEntryWsi Be sure to obscure any sensitive information before posting. If there is a lot of output, you can use pastebin.com or rafb.net to avoid spamming the list. > > 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). Replication update procedures may create tombstones. Those entries do not show up unless you specify that filter in your search request. So if the entry is a tombstone, and you did a search for (nsuniqueid=value) the entry would not be returned unless you added |(objectclass=nsTombstone) to the search filter. > 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? Yes. > > > > > 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>> > > > <mailto: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>> > > > <mailto: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 > <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>> > > > <mailto: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 > > < > 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 > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20070515/d4737393/attachment.bin
