Hello all, Can someone tell me, does the NSUniqueID attribute ever change for a given entry in the directory? If so (I''ve seen it happen), what are the criteria that prompt NSUniqeID to change? Thanks, BO
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@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >
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. --BO On 5/15/07, Richard Megginson <rmeggins@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@redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > >
I can also tell you that NSUniqueID was 19d98481-1dd211b2-8023e758-74ea0000 then changed to 647b2b01-1dd211b2-80c7e758-74ea0000 --BO On 5/15/07, Bjorn Oglefjorn <sys.mailing@gmail.com> 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. > --BO > > On 5/15/07, Richard Megginson <rmeggins@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@redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > -- > > Fedora-directory-users mailing list > > Fedora-directory-users@redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > >
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? 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. If this is the case, is it possible that the uid for the entry has changed?> --BO > > On 5/15/07, *Richard Megginson* <rmeggins@redhat.com > <mailto:rmeggins@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@redhat.com > <mailto:Fedora-directory-users@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@redhat.com > <mailto:Fedora-directory-users@redhat.com> > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > ------------------------------------------------------------------------ > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >
On 5/15/07, Richard Megginson <rmeggins@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? 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@redhat.com > > <mailto:rmeggins@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@redhat.com > > <mailto:Fedora-directory-users@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@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > Fedora-directory-users mailing list > > Fedora-directory-users@redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > >
Bjorn Oglefjorn wrote:> On 5/15/07, *Richard Megginson* <rmeggins@redhat.com > <mailto:rmeggins@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. 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@redhat.com > <mailto:rmeggins@redhat.com> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@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@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@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@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>> > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > Fedora-directory-users mailing list > > Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@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@redhat.com > <mailto:Fedora-directory-users@redhat.com> > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > ------------------------------------------------------------------------ > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >
On 5/15/07, Richard Megginson <rmeggins@redhat.com> wrote:> > Bjorn Oglefjorn wrote: > > On 5/15/07, *Richard Megginson* <rmeggins@redhat.com > > <mailto:rmeggins@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@redhat.com > > <mailto:rmeggins@redhat.com> > > > <mailto:rmeggins@redhat.com <mailto:rmeggins@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@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@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@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>> > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > -- > > > Fedora-directory-users mailing list > > > Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@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@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > Fedora-directory-users mailing list > > Fedora-directory-users@redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > >
Bjorn Oglefjorn wrote:> On 5/15/07, *Richard Megginson* <rmeggins@redhat.com > <mailto:rmeggins@redhat.com>> wrote: > > Bjorn Oglefjorn wrote: > > On 5/15/07, *Richard Megginson* <rmeggins@redhat.com > <mailto:rmeggins@redhat.com> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@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@redhat.com > <mailto:rmeggins@redhat.com> > > <mailto: rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> > <mailto:rmeggins@redhat.com <mailto:rmeggins@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@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>> > > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@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@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>> > > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@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@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@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@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>> > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > Fedora-directory-users mailing list > > Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@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@redhat.com > <mailto:Fedora-directory-users@redhat.com> > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > ------------------------------------------------------------------------ > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >
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? 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@example.com nscpEntryWsi: mail;vucsn-4648d7560000000b0000: auser@email.example.com nscpEntryWsi: mail;vucsn-4648d7560000000b0000: Another.User@example.com nscpEntryWsi: entrydn: uid=auser,ou=people,dc=example,dc=com nscpEntryWsi: entryid: 2803 nscpEntryWsi: parentid: 2 nscpEntryWsi: createTimestamp;vucsn-45ecada3000000010000: 20070305235111Z nscpEntryWsi: creatorsName;vucsn-45ecada3000000010000: uid=creator,ou=people,dc=example,dc=com nscpEntryWsi: userPassword;vucsn-45ecada3000000010000: {crypt}xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx nscpEntryWsi: employeeType;vucsn-45ecada3000000010000: Fulltime nscpEntryWsi: ou;vucsn-45ecada3000000010000: Management nscpEntryWsi: o;vucsn-45ecada3000000010000: example.com nscpEntryWsi: manager;vucsn-45ecada3000000010000: uid=manager,ou=People,dc=example,dc=com nscpEntryWsi: title;vucsn-45ecada3000000010000: General Manager nscpEntryWsi: loginShell;vucsn-45ecada3000000010000: /bin/bash nscpEntryWsi: scalixMailboxClass;vucsn-45ecada3000000010000: LIMITED nscpEntryWsi: scalixHideUserEntry;vucsn-45ecada3000000010000: FALSE nscpEntryWsi: scalixLimitNotifyUser;vucsn-45ecada3000000010000: TRUE nscpEntryWsi: scalixLimitInboundMail;vucsn-45ecada3000000010000: TRUE nscpEntryWsi: scalixLimitOutboundMail;vucsn-45ecada3000000010000: TRUE nscpEntryWsi: scalixLimitMailboxSize;vucsn-45ecada3000000010000: 1024 nscpEntryWsi: scalixMailboxAdministrator;vucsn-45ecada3000000010000: FALSE nscpEntryWsi: scalixAdministrator;vucsn-45ecada3000000010000: FALSE nscpEntryWsi: scalixServerLanguage;vucsn-45ecada3000000010000: AMERICAN nscpEntryWsi: scalixMailnode;vucsn-45ecada3000000010000: mailnode nscpEntryWsi: scalixScalixObject;vucsn-45ecada3000000010000: TRUE nscpEntryWsi: objectClass;vucsn-45ecada3000000010000: top nscpEntryWsi: objectClass;vucsn-45ecada3000000010000: person nscpEntryWsi: objectClass;vucsn-45ecada3000000010000: organizationalPerson nscpEntryWsi: objectClass;vucsn-45ecada3000000010000: inetorgperson nscpEntryWsi: objectClass;vucsn-45ecada3000000010000: posixAccount nscpEntryWsi: objectClass;vucsn-45ecada3000000010000: scalixUserClass nscpEntryWsi: givenName;vucsn-45ecada3000000010000: Another nscpEntryWsi: gidNumber;vucsn-45ecada3000000010000: 100 nscpEntryWsi: uidNumber;vucsn-45ecada3000000010000: 12498 nscpEntryWsi: uid;vucsn-45eee916000000010000;mdcsn-45eee916000000010000: auser nscpEntryWsi: cn;adcsn-45eee916000100010000;vucsn-45eee916000100010000: Another User nscpEntryWsi: gecos;adcsn-45eee916000100010000;vucsn-45eee916000100010000: Another User nscpEntryWsi: homeDirectory;adcsn-45eee916000100010000;vucsn-45eee916000100010000: /home/auser nscpEntryWsi: sn;adcsn-45eee916000100010000;vucsn-45eee916000100010000: User nscpEntryWsi: nsUniqueId: 647b2b01-1dd211b2-80c7e758-74ea0000 Thanks again Richard. --BO On 5/15/07, Richard Megginson <rmeggins@redhat.com> wrote:> > Bjorn Oglefjorn wrote: > > On 5/15/07, *Richard Megginson* <rmeggins@redhat.com > > <mailto:rmeggins@redhat.com>> wrote: > > > > Bjorn Oglefjorn wrote: > > > On 5/15/07, *Richard Megginson* <rmeggins@redhat.com > > <mailto:rmeggins@redhat.com> > > > <mailto:rmeggins@redhat.com <mailto:rmeggins@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@redhat.com > > <mailto:rmeggins@redhat.com> > > > <mailto: rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > > > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@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@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>> > > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@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@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>> > > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@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@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@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@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>> > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > -- > > > Fedora-directory-users mailing list > > > Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@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@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > Fedora-directory-users mailing list > > Fedora-directory-users@redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > >
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@example.com <mailto:auser@example.com> > nscpEntryWsi: mail;vucsn-4648d7560000000b0000: auser@email.example.com > <mailto:auser@email.example.com> > nscpEntryWsi: mail;vucsn-4648d7560000000b0000: > Another.User@example.com <mailto:Another.User@example.com> > nscpEntryWsi: entrydn: uid=auser,ou=people,dc=example,dc=com > nscpEntryWsi: entryid: 2803 > <snip> > nscpEntryWsi: nsUniqueId: 647b2b01-1dd211b2-80c7e758-74ea0000This 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.> > Thanks again Richard. > --BO > > On 5/15/07, *Richard Megginson* < rmeggins@redhat.com > <mailto:rmeggins@redhat.com>> wrote: > > Bjorn Oglefjorn wrote: > > On 5/15/07, *Richard Megginson* < rmeggins@redhat.com > <mailto:rmeggins@redhat.com> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>>> wrote: > > > > Bjorn Oglefjorn wrote: > > > On 5/15/07, *Richard Megginson* < rmeggins@redhat.com > <mailto:rmeggins@redhat.com> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> > <mailto:rmeggins@redhat.com <mailto:rmeggins@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@redhat.com > <mailto:rmeggins@redhat.com> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > > > <mailto: rmeggins@redhat.com > <mailto:rmeggins@redhat.com> <mailto: rmeggins@redhat.com > <mailto:rmeggins@redhat.com>>> > > > > <mailto:rmeggins@redhat.com > <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com > <mailto:rmeggins@redhat.com>> > > <mailto: rmeggins@redhat.com <mailto:rmeggins@redhat.com> > <mailto:rmeggins@redhat.com <mailto:rmeggins@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@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>> > > > <mailto: Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>>> > > > > <mailto: Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>> > > > <mailto: Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@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@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>> > > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>>> > > > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>> > > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@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@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto: Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>> > > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto: Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@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@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto: Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>> > > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto: Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>>> > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > -- > > > Fedora-directory-users mailing list > > > Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@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@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>> > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > Fedora-directory-users mailing list > > Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@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@redhat.com > <mailto:Fedora-directory-users@redhat.com> > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > ------------------------------------------------------------------------ > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >
On 5/15/07, Richard Megginson <rmeggins@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@example.com <mailto:auser@example.com> > > nscpEntryWsi: mail;vucsn-4648d7560000000b0000: auser@email.example.com > > <mailto:auser@email.example.com> > > nscpEntryWsi: mail;vucsn-4648d7560000000b0000: > > Another.User@example.com <mailto:Another.User@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@redhat.com > > <mailto:rmeggins@redhat.com>> wrote: > > > > Bjorn Oglefjorn wrote: > > > On 5/15/07, *Richard Megginson* < rmeggins@redhat.com > > <mailto:rmeggins@redhat.com> > > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>>> wrote: > > > > > > Bjorn Oglefjorn wrote: > > > > On 5/15/07, *Richard Megginson* < rmeggins@redhat.com > > <mailto:rmeggins@redhat.com> > > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > > > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@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@redhat.com > > <mailto:rmeggins@redhat.com> > > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > > > > <mailto: rmeggins@redhat.com > > <mailto:rmeggins@redhat.com> <mailto: rmeggins@redhat.com > > <mailto:rmeggins@redhat.com>>> > > > > > <mailto:rmeggins@redhat.com > > <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com > > <mailto:rmeggins@redhat.com>> > > > <mailto: rmeggins@redhat.com <mailto:rmeggins@redhat.com> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@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@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>> > > > > <mailto: Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>>> > > > > > <mailto: Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>> > > > > <mailto: Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@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@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>> > > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>>> > > > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>> > > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@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@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto: Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>> > > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto: Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@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@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto: Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>> > > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto: Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>>> > > > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > -- > > > > Fedora-directory-users mailing list > > > > Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@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@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>> > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > -- > > > Fedora-directory-users mailing list > > > Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@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@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > Fedora-directory-users mailing list > > Fedora-directory-users@redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > >
Bjorn Oglefjorn wrote:> On 5/15/07, *Richard Megginson* <rmeggins@redhat.com > <mailto:rmeggins@redhat.com>> wrote: > > > > 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?If it were deleted or turned into some other sort of replication fix-up entry, then searching by (&(objectclass=nsTombstone)(nsuniqueid=19d98481-1dd211b2-8023e758-74ea0000)) should find it. I assume you already searched for (nsuniqueid=19d98481-1dd211b2-8023e758-74ea0000) and found nothing.> I can tell you that a mail attribute value was removed and added > before this change in nsuniqueid occurred.So if you just remove and add a mail attribute value to any entry, does the nsuniqueid change happen? I''m assuming not, based on what you said. So something else has to happen to make the nsuniqueid value change. This particular case seems strange to me. The first thing that happens to the entry is it''s creation: nscpEntryWsi: createTimestamp;vucsn-45ecada3000000010000: 20070305235111Z nscpEntryWsi: creatorsName;vucsn-45ecada3000000010000: uid=creator,ou=people,dc=example,dc=com At this time, many of the other attributes are added to the entry: nscpEntryWsi: userPassword;vucsn-45ecada3000000010000: {crypt}xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ... nscpEntryWsi: uidNumber;vucsn-45ecada3000000010000: 12498 Then, sometime later, the posix attributes are added/modified: nscpEntryWsi: uid;vucsn-45eee916000000010000;mdcsn-45eee916000000010000: auser ... nscpEntryWsi: sn;adcsn-45eee916000100010000;vucsn-45eee916000100010000: User This seems odd - were these attributes originally added with other values, then changed? Was the original dn uid=auser, or was this changed? Then, sometime later, the mail attribute was changed: 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 example com <mailto:auser%20example%20com> nscpEntryWsi: mail;vucsn-4648d7560000000b0000: auser email example com <mailto:auser%20email%20example%20com> nscpEntryWsi: mail;vucsn-4648d7560000000b0000: Another User example com <mailto:Another%20User%20example%20com>> > > > > Thanks again Richard. > > --BO > > > > On 5/15/07, *Richard Megginson* < rmeggins@redhat.com > <mailto:rmeggins@redhat.com> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>>> wrote: > > > > Bjorn Oglefjorn wrote: > > > On 5/15/07, *Richard Megginson* < rmeggins@redhat.com > <mailto:rmeggins@redhat.com> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>>>> wrote: > > > > > > Bjorn Oglefjorn wrote: > > > > On 5/15/07, *Richard Megginson* < > rmeggins@redhat.com <mailto:rmeggins@redhat.com> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > > > <mailto:rmeggins@redhat.com > <mailto:rmeggins@redhat.com> <mailto: rmeggins@redhat.com > <mailto:rmeggins@redhat.com>>> > > > > <mailto:rmeggins@redhat.com > <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com > <mailto:rmeggins@redhat.com>> > > <mailto: rmeggins@redhat.com <mailto:rmeggins@redhat.com> > <mailto:rmeggins@redhat.com <mailto:rmeggins@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> <http://pastebin.com> > > or rafb.net <http://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@redhat.com <mailto:rmeggins@redhat.com> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > > > <mailto:rmeggins@redhat.com > <mailto:rmeggins@redhat.com> <mailto: rmeggins@redhat.com > <mailto:rmeggins@redhat.com>>> > > > > <mailto: rmeggins@redhat.com > <mailto:rmeggins@redhat.com> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > <mailto: rmeggins@redhat.com <mailto:rmeggins@redhat.com> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>>>> > > > > > <mailto: rmeggins@redhat.com > <mailto:rmeggins@redhat.com> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> > > <mailto: rmeggins@redhat.com <mailto:rmeggins@redhat.com>>> > > > <mailto: rmeggins@redhat.com > <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com > <mailto:rmeggins@redhat.com>> > > <mailto: rmeggins@redhat.com <mailto:rmeggins@redhat.com> > <mailto:rmeggins@redhat.com <mailto:rmeggins@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@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>> > > > <mailto: Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>>> > > > > <mailto: Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>> > > > <mailto: Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>>>> > > > > > <mailto: Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>> > > > <mailto: Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>>> > > > > <mailto: Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>> > > > <mailto: Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@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 > <https://www.redhat.com/mailman/listinfo/fedora-directory-users>>> > > > > > > > > > > > > > > > > -- > > > > > Fedora-directory-users mailing list > > > > > Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>> > > > <mailto: Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>>> > > > > <mailto: Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>> > > > <mailto: Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>>>> > > > > > <mailto: Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>> > > > <mailto: Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>>> > > > > <mailto: Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>> > > > <mailto: Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@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@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>> > > > <mailto: Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>>> > > > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>> > > > <mailto: Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@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@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>> > > > <mailto: Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>>> > > > > <mailto: Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>> > > > <mailto: Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>>>> > > > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > -- > > > > Fedora-directory-users mailing list > > > > Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>> > > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@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@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>> > > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@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@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@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@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > <mailto:Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com>> > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > Fedora-directory-users mailing list > > Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@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@redhat.com > <mailto:Fedora-directory-users@redhat.com> > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > ------------------------------------------------------------------------ > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >
On 5/15/07, Richard Megginson <rmeggins@redhat.com> wrote:> > Bjorn Oglefjorn wrote: > > On 5/15/07, *Richard Megginson* <rmeggins@redhat.com > > <mailto:rmeggins@redhat.com>> wrote: > > > > > > > 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? > If it were deleted or turned into some other sort of replication fix-up > entry, then searching by > > (&(objectclass=nsTombstone)(nsuniqueid=19d98481-1dd211b2-8023e758-74ea0000)) > should find it. I assume you already searched for > (nsuniqueid=19d98481-1dd211b2-8023e758-74ea0000) and found nothing.Correct, both of those searches return nothing.> I can tell you that a mail attribute value was removed and added > > before this change in nsuniqueid occurred. > So if you just remove and add a mail attribute value to any entry, does > the nsuniqueid change happen? I''m assuming not, based on what you > said. So something else has to happen to make the nsuniqueid value > change.This is a rare occurrence and I''ve yet to nail down what is actually causing it. By far, most modify operations do not cause nsuniqueid to change. This particular case seems strange to me. The first thing that happens> to the entry is it''s creation: > nscpEntryWsi: createTimestamp;vucsn-45ecada3000000010000: 20070305235111Z > nscpEntryWsi: creatorsName;vucsn-45ecada3000000010000: > uid=creator,ou=people,dc=example,dc=com > > At this time, many of the other attributes are added to the entry: > nscpEntryWsi: userPassword;vucsn-45ecada3000000010000: > {crypt}xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > ... > nscpEntryWsi: uidNumber;vucsn-45ecada3000000010000: 12498 > > Then, sometime later, the posix attributes are added/modified: > nscpEntryWsi: uid;vucsn-45eee916000000010000;mdcsn-45eee916000000010000: > auser > ... > nscpEntryWsi: sn;adcsn-45eee916000100010000;vucsn-45eee916000100010000: > User > > This seems odd - were these attributes originally added with other > values, then changed? Was the original dn uid=auser, or was this changed?If that is true, that is indeed odd. Looking back through my audit logs shows only the change to the mail attribute values. Is there another way I can check and see the change of the posix attributes? Then, sometime later, the mail attribute was changed:> 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 > example com <mailto:auser%20example%20com> > nscpEntryWsi: mail;vucsn-4648d7560000000b0000: auser email example com > <mailto:auser%20email%20example%20com> > nscpEntryWsi: mail;vucsn-4648d7560000000b0000: Another User example com > <mailto:Another%20User%20example%20com> > > > > > > > > Thanks again Richard. > > > --BO > > > > > > On 5/15/07, *Richard Megginson* < rmeggins@redhat.com > > <mailto:rmeggins@redhat.com> > > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>>> wrote: > > > > > > Bjorn Oglefjorn wrote: > > > > On 5/15/07, *Richard Megginson* < rmeggins@redhat.com > > <mailto:rmeggins@redhat.com> > > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > > > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>>>> wrote: > > > > > > > > Bjorn Oglefjorn wrote: > > > > > On 5/15/07, *Richard Megginson* < > > rmeggins@redhat.com <mailto:rmeggins@redhat.com> > > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > > > > <mailto:rmeggins@redhat.com > > <mailto:rmeggins@redhat.com> <mailto: rmeggins@redhat.com > > <mailto:rmeggins@redhat.com>>> > > > > > <mailto:rmeggins@redhat.com > > <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com > > <mailto:rmeggins@redhat.com>> > > > <mailto: rmeggins@redhat.com <mailto:rmeggins@redhat.com> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@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> <http://pastebin.com> > > > or rafb.net <http://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@redhat.com <mailto:rmeggins@redhat.com> > > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > > > > <mailto:rmeggins@redhat.com > > <mailto:rmeggins@redhat.com> <mailto: rmeggins@redhat.com > > <mailto:rmeggins@redhat.com>>> > > > > > <mailto: rmeggins@redhat.com > > <mailto:rmeggins@redhat.com> > > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > > <mailto: rmeggins@redhat.com <mailto:rmeggins@redhat.com> > > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>>>> > > > > > > <mailto: rmeggins@redhat.com > > <mailto:rmeggins@redhat.com> > > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> > > > <mailto: rmeggins@redhat.com <mailto:rmeggins@redhat.com>>> > > > > <mailto: rmeggins@redhat.com > > <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com > > <mailto:rmeggins@redhat.com>> > > > <mailto: rmeggins@redhat.com <mailto:rmeggins@redhat.com> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@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@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>> > > > > <mailto: Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>>> > > > > > <mailto: Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>> > > > > <mailto: Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>>>> > > > > > > <mailto: Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>> > > > > <mailto: Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>>> > > > > > <mailto: Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>> > > > > <mailto: Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@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 > > <https://www.redhat.com/mailman/listinfo/fedora-directory-users>>> > > > > > > > > > > > > > > > > > > > -- > > > > > > Fedora-directory-users mailing list > > > > > > Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>> > > > > <mailto: Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>>> > > > > > <mailto: Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>> > > > > <mailto: Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>>>> > > > > > > <mailto: Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>> > > > > <mailto: Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>>> > > > > > <mailto: Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>> > > > > <mailto: Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@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@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>> > > > > <mailto: Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>>> > > > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>> > > > > <mailto: Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@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@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>> > > > > <mailto: Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>>> > > > > > <mailto: Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>> > > > > <mailto: Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>>>> > > > > > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > -- > > > > > Fedora-directory-users mailing list > > > > > Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>> > > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@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@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>> > > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@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@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@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@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > > <mailto:Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@redhat.com>> > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > -- > > > Fedora-directory-users mailing list > > > Fedora-directory-users@redhat.com > > <mailto:Fedora-directory-users@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@redhat.com > > <mailto:Fedora-directory-users@redhat.com> > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > Fedora-directory-users mailing list > > Fedora-directory-users@redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > >
Bjorn Oglefjorn wrote:> <snip> > > > This seems odd - were these attributes originally added with other > values, then changed? Was the original dn uid=auser, or was this > changed? > > > If that is true, that is indeed odd. Looking back through my audit > logs shows only the change to the mail attribute values. Is there > another way I can check and see the change of the posix attributes?You said "audit logs" - do you mean the DS audit log? http://www.redhat.com/docs/manuals/dir-server/ag/7.1/dsstats.html#1092377 If not, you could enable the audit log to see exactly what modifications are occurring.
On 5/16/07, Richard Megginson <rmeggins@redhat.com> wrote:> > Bjorn Oglefjorn wrote: > > <snip> > > > > > > This seems odd - were these attributes originally added with other > > values, then changed? Was the original dn uid=auser, or was this > > changed? > > > > > > If that is true, that is indeed odd. Looking back through my audit > > logs shows only the change to the mail attribute values. Is there > > another way I can check and see the change of the posix attributes? > You said "audit logs" - do you mean the DS audit log? > http://www.redhat.com/docs/manuals/dir-server/ag/7.1/dsstats.html#1092377 > If not, you could enable the audit log to see exactly what modifications > are occurring.Yes, I do have audit logging enabled on both of my fedora-ds machines but only as of the end of last month. I only see the modification of the mail attributes in the audit log. --> Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > >
Bjorn Oglefjorn wrote:> > > On 5/16/07, *Richard Megginson* <rmeggins@redhat.com > <mailto:rmeggins@redhat.com>> wrote: > > Bjorn Oglefjorn wrote: > > <snip> > > > > > > This seems odd - were these attributes originally added with > other > > values, then changed? Was the original dn uid=auser, or was > this > > changed? > > > > > > If that is true, that is indeed odd. Looking back through my audit > > logs shows only the change to the mail attribute values. Is there > > another way I can check and see the change of the posix attributes? > You said "audit logs" - do you mean the DS audit log? > http://www.redhat.com/docs/manuals/dir-server/ag/7.1/dsstats.html#1092377 > <http://www.redhat.com/docs/manuals/dir-server/ag/7.1/dsstats.html#1092377> > If not, you could enable the audit log to see exactly what > modifications > are occurring. > > > Yes, I do have audit logging enabled on both of my fedora-ds machines > but only as of the end of last month. I only see the modification of > the mail attributes in the audit log.Ok. The information might still be in the changelog. You can dump the contents of the changelog using the perl script bin/slapd/admin/scripts/template-cl-dump.pl - cd /opt/fedora-ds ; perl bin/slapd/admin/scripts/template-cl-dump.pl -H for usage.> > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > ------------------------------------------------------------------------ > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >