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.
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.dn: uid=auser,ou=People,dc=example,dc=com nscpEntryWsi: dn: uid=auser,ou=People,dc=example,dc=comnscpEntryWsi: 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@xxxxxxxxxxx <mailto:auser@xxxxxxxxxxx> nscpEntryWsi: mail;vucsn-4648d7560000000b0000: auser@xxxxxxxxxxxxxxxxx <mailto:auser@xxxxxxxxxxxxxxxxx> nscpEntryWsi: mail;vucsn-4648d7560000000b0000: Another.User@xxxxxxxxxxx <mailto:Another.User@xxxxxxxxxxx>nscpEntryWsi: entrydn: uid=auser,ou=people,dc=example,dc=com nscpEntryWsi: entryid: 2803 <snip> nscpEntryWsi: nsUniqueId: 647b2b01-1dd211b2-80c7e758-74ea0000
Thanks again Richard. --BOOn 5/15/07, *Richard Megginson* < rmeggins@xxxxxxxxxx <mailto:rmeggins@xxxxxxxxxx>> wrote:Bjorn Oglefjorn wrote: > On 5/15/07, *Richard Megginson* < rmeggins@xxxxxxxxxx <mailto:rmeggins@xxxxxxxxxx> > <mailto:rmeggins@xxxxxxxxxx <mailto:rmeggins@xxxxxxxxxx>>> wrote: > > Bjorn Oglefjorn wrote: > > On 5/15/07, *Richard Megginson* < rmeggins@xxxxxxxxxx <mailto:rmeggins@xxxxxxxxxx> > <mailto:rmeggins@xxxxxxxxxx <mailto:rmeggins@xxxxxxxxxx>> > > <mailto:rmeggins@xxxxxxxxxx <mailto:rmeggins@xxxxxxxxxx> <mailto: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. > > > 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@xxxxxxxxxx <mailto:rmeggins@xxxxxxxxxx> > <mailto:rmeggins@xxxxxxxxxx <mailto:rmeggins@xxxxxxxxxx>> > > <mailto: rmeggins@xxxxxxxxxx <mailto:rmeggins@xxxxxxxxxx> <mailto: rmeggins@xxxxxxxxxx <mailto:rmeggins@xxxxxxxxxx>>> > > > <mailto:rmeggins@xxxxxxxxxx <mailto:rmeggins@xxxxxxxxxx> <mailto:rmeggins@xxxxxxxxxx <mailto:rmeggins@xxxxxxxxxx>> > <mailto: 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>> > > <mailto: Fedora-directory-users@xxxxxxxxxx <mailto:Fedora-directory-users@xxxxxxxxxx> > <mailto:Fedora-directory-users@xxxxxxxxxx <mailto:Fedora-directory-users@xxxxxxxxxx>>> > > > <mailto: Fedora-directory-users@xxxxxxxxxx <mailto:Fedora-directory-users@xxxxxxxxxx> > <mailto:Fedora-directory-users@xxxxxxxxxx <mailto:Fedora-directory-users@xxxxxxxxxx>> > > <mailto: 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<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>> > > <mailto:Fedora-directory-users@xxxxxxxxxx <mailto:Fedora-directory-users@xxxxxxxxxx> > <mailto:Fedora-directory-users@xxxxxxxxxx <mailto:Fedora-directory-users@xxxxxxxxxx>>> > > > <mailto:Fedora-directory-users@xxxxxxxxxx <mailto:Fedora-directory-users@xxxxxxxxxx> > <mailto:Fedora-directory-users@xxxxxxxxxx <mailto:Fedora-directory-users@xxxxxxxxxx>> > > <mailto: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>> > > <mailto: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> > > < > 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>> > > <mailto: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> > <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
