On 5/15/07, Richard Megginson <rmeggins at redhat.com> wrote: > > Bjorn Oglefjorn wrote: > > I've edited out the personal/company details, but here is the result > > of the query. Looks interesting, I've never seen this before. Is > > there a good section in the docs on how to read this? > No. It's not intended for users to read. It's mostly interesting for > developers, for debugging purposes. > > > > dn: uid=auser,ou=People,dc=example,dc=com > > nscpEntryWsi: dn: uid=auser,ou=People,dc=example,dc=com > > nscpEntryWsi: > > modifyTimestamp;adcsn-4648d7560000000b0000;vucsn-4648d7560000000b0000: > > 20070514213629Z > > nscpEntryWsi: > > modifiersName;adcsn-4648d7560000000b0000;vucsn-4648d7560000000b0000: > > uid=modifier,ou=people,dc=example,dc=com > > nscpEntryWsi: > > mail;adcsn-4648d7560000000b0000;vucsn-4648d7560000000b0000: > > auser at example.com <mailto:auser at example.com> > > nscpEntryWsi: mail;vucsn-4648d7560000000b0000: auser at email.example.com > > <mailto:auser at email.example.com> > > nscpEntryWsi: mail;vucsn-4648d7560000000b0000: > > Another.User at example.com <mailto:Another.User at example.com> > > nscpEntryWsi: entrydn: uid=auser,ou=people,dc=example,dc=com > > nscpEntryWsi: entryid: 2803 > > <snip> > > nscpEntryWsi: nsUniqueId: 647b2b01-1dd211b2-80c7e758-74ea0000 > This looks like the entry before modification? What does the entry look > like after modification? Another attribute you can use to uniquely > identify an entry in a single backend is the entryid attribute. > However, the entryid is not globally unique across all backends and > replicas. This above is the entry as it currently lives in LDAP. The NSUniqueID value there is the _new_ value. As I stated before: "I can also tell you that NSUniqueID was 19d98481-1dd211b2-8023e758-74ea0000 then changed to 647b2b01-1dd211b2-80c7e758-74ea0000" I don't think there is a way for me to search for the entry as it was before the modification is there? I can tell you that a mail attribute value was removed and added before this change in nsuniqueid occurred. > > > Thanks again Richard. > > --BO > > > > 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: > > > > 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: > > > > > 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 <http://pastebin.com> > > or rafb.net <http://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>>> > > > > > <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 <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>>> > > > > > <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 > > <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> > > > > > <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>>> > > > > > <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 > > <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>> > > > > <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 > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > -- > > > > 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/b0a82383/attachment.html
