Re: NSUniqueID

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxx
nscpEntryWsi: mail;vucsn-4648d7560000000b0000: auser@xxxxxxxxxxxxxxxxx
nscpEntryWsi: mail;vucsn-4648d7560000000b0000: Another.User@xxxxxxxxxxx
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@xxxxxxxxxx> wrote:
Bjorn Oglefjorn wrote:
> On 5/15/07, *Richard Megginson* < rmeggins@xxxxxxxxxx
> <mailto:rmeggins@xxxxxxxxxx>> wrote:
>
>     Bjorn Oglefjorn wrote:
>     > On 5/15/07, *Richard Megginson* < rmeggins@xxxxxxxxxx
>     <mailto:rmeggins@xxxxxxxxxx>
>     > <mailto:rmeggins@xxxxxxxxxx <mailto:rmeggins@xxxxxxxxxx>>> wrote:
>     >
>     >     Bjorn Oglefjorn wrote:
>     >     > 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@xxxxxxxxxx
>     <mailto:rmeggins@xxxxxxxxxx>
>     >     <mailto: rmeggins@xxxxxxxxxx <mailto: rmeggins@xxxxxxxxxx>>
>     >     > <mailto:rmeggins@xxxxxxxxxx <mailto:rmeggins@xxxxxxxxxx>
>     <mailto: rmeggins@xxxxxxxxxx <mailto:rmeggins@xxxxxxxxxx>>>> wrote:
>     >     >
>     >     >     Bjorn Oglefjorn wrote:
>     >     >     > Hello all,
>     >     >     >
>     >     >     > Can someone tell me, does the NSUniqueID attribute ever
>     >     change for a
>     >     >     > given entry in the directory?
>     >     >     No.
>     >     >     > If so (I've seen it happen),
>     >     >     Can you describe exactly what you saw and how to
>     reproduce it?
>     >     >     > what are the criteria that prompt NSUniqeID to change?
>     >     >     >
>     >     >     > Thanks,
>     >     >     > BO
>     >     >     >
>     >     >
>     >
>     ------------------------------------------------------------------------
>     >     >     >
>     >     >     > --
>     >     >     > Fedora-directory-users mailing list
>     >     >     > Fedora-directory-users@xxxxxxxxxx
>     <mailto:Fedora-directory-users@xxxxxxxxxx>
>     >     <mailto: Fedora-directory-users@xxxxxxxxxx
>     <mailto:Fedora-directory-users@xxxxxxxxxx>>
>     >     >     <mailto: Fedora-directory-users@xxxxxxxxxx
>     <mailto:Fedora-directory-users@xxxxxxxxxx>
>     >     <mailto: Fedora-directory-users@xxxxxxxxxx
>     <mailto:Fedora-directory-users@xxxxxxxxxx>>>
>     >     >     >
>     https://www.redhat.com/mailman/listinfo/fedora-directory-users
>     >     >     <
>     >
>     https://www.redhat.com/mailman/listinfo/fedora-directory-users
>     <https://www.redhat.com/mailman/listinfo/fedora-directory-users>>
>     >     >     >
>     >     >
>     >     >     --
>     >     >     Fedora-directory-users mailing list
>     >     >     Fedora-directory-users@xxxxxxxxxx
>     <mailto:Fedora-directory-users@xxxxxxxxxx>
>     >     <mailto:Fedora-directory-users@xxxxxxxxxx
>     <mailto:Fedora-directory-users@xxxxxxxxxx>>
>     >     >     <mailto:Fedora-directory-users@xxxxxxxxxx
>     <mailto:Fedora-directory-users@xxxxxxxxxx>
>     >     <mailto:Fedora-directory-users@xxxxxxxxxx
>     <mailto:Fedora-directory-users@xxxxxxxxxx>>>
>     >     >
>     https://www.redhat.com/mailman/listinfo/fedora-directory-users
>     <https://www.redhat.com/mailman/listinfo/fedora-directory-users >
>     >     >
>     >     >
>     >     >
>     >     >
>     >
>     ------------------------------------------------------------------------
>     >     >
>     >     > --
>     >     > Fedora-directory-users mailing list
>     >     > Fedora-directory-users@xxxxxxxxxx
>     <mailto: Fedora-directory-users@xxxxxxxxxx>
>     >     <mailto:Fedora-directory-users@xxxxxxxxxx
>     <mailto: Fedora-directory-users@xxxxxxxxxx>>
>     >     > https://www.redhat.com/mailman/listinfo/fedora-directory-users
>     >     <
>     https://www.redhat.com/mailman/listinfo/fedora-directory-users>
>     >     >
>     >
>     >     --
>     >     Fedora-directory-users mailing list
>     >     Fedora-directory-users@xxxxxxxxxx
>     <mailto: Fedora-directory-users@xxxxxxxxxx>
>     >     <mailto:Fedora-directory-users@xxxxxxxxxx
>     <mailto: Fedora-directory-users@xxxxxxxxxx>>
>     >     https://www.redhat.com/mailman/listinfo/fedora-directory-users
>     >
>     >
>     >
>     >
>     ------------------------------------------------------------------------
>     >
>     > --
>     > Fedora-directory-users mailing list
>     > Fedora-directory-users@xxxxxxxxxx
>     <mailto:Fedora-directory-users@xxxxxxxxxx>
>     > https://www.redhat.com/mailman/listinfo/fedora-directory-users
>     < https://www.redhat.com/mailman/listinfo/fedora-directory-users>
>     >
>
>     --
>     Fedora-directory-users mailing list
>     Fedora-directory-users@xxxxxxxxxx
>     <mailto:Fedora-directory-users@xxxxxxxxxx>
>     https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>
>
> ------------------------------------------------------------------------
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users



--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users

[Index of Archives]     [Fedora Directory Users]     [Fedora Directory Devel]     [Fedora Announce]     [Fedora Legacy Announce]     [Kernel]     [Fedora Legacy]     [Share Photos]     [Fedora Desktop]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Big List of Linux Books]     [Gimp]     [Yosemite News]

  Powered by Linux