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(a)example.com
nscpEntryWsi: mail;vucsn-4648d7560000000b0000: auser(a)email.example.com
nscpEntryWsi: mail;vucsn-4648d7560000000b0000: Another.User(a)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(a)redhat.com> wrote:
Bjorn Oglefjorn wrote:
> On 5/15/07, *Richard Megginson* <rmeggins(a)redhat.com
> <mailto:rmeggins@redhat.com>> wrote:
>
> Bjorn Oglefjorn wrote:
> > On 5/15/07, *Richard Megginson* <rmeggins(a)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(a)redhat.com
> <mailto:rmeggins@redhat.com>
> > <mailto: rmeggins(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)redhat.com
>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
--
Fedora-directory-users mailing list
Fedora-directory-users(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-users