Quanah Gibson-Mount wrote:
--On Monday, March 06, 2017 4:37 PM +0100 "A. Schulze" sca@andreasschulze.de wrote:
Hello,
while planning a data scheme update we found it handy to have a unique value for each entry. short time later we found "entryUUID" :-) But we are still unsure.Should we simply use entryUUID or should we extend our schema to hold a new attribute similar to entryUUID.
entryUUID is defined in RFC4530, as an internal LDAP attribute. Personally, if you need a UUID for tracking, I would create your own specific to your application/needs. For example, when I was at Stanford, we used suRegID (stanford university registry ID) and when I was at zimbra, we used zimbraID (zimbra identifier). There have been format changes in the past that required wiping out some of the generated attributes when going between releases.
This is bad advice. If you actually want a UUID then use entryUUID. As noted, it is defined in RFC4530 which means it isn't going to change. The format of UUIDs is well-established in internet standards.
When an existing attribute has *exactly* the syntax and semantics that you want, use it.
suRegID and zimbraID are not UUIDs are they?
Using your own identifier ensures that will not be an issue. Also, if you do things like allow backing up/restoring user entries that have gotten deleted, a restored entry (depending on the method use) may end up with a new entryUUID.
Yes, you should only use the recommended backup procedures.
--On Tuesday, March 07, 2017 4:58 PM +0000 Howard Chu hyc@symas.com wrote:
This is bad advice. If you actually want a UUID then use entryUUID. As noted, it is defined in RFC4530 which means it isn't going to change. The format of UUIDs is well-established in internet standards.
I disagree. :) There are perefectly valid reasons to avoid using the LDAP created UUID.
When an existing attribute has *exactly* the syntax and semantics that you want, use it.
suRegID and zimbraID are not UUIDs are they?
Yes, they are UUIDs. In Stanford's case, the UUID was generated outside of LDAP in another system, and used as a reference through multitudes of other systems, many of which had no access to LDAP. Using the entryUUID would not have been feasible.
In Zimbra's case, there's a capability to store the non-operational attributes of an account for restoration at a later date via other utilities. The licensed nature, based off total accounts, for Zimbra's commercial product means that deleting inactive accounts is a common procedure, as well as restoring them at a later date. Restoring a single account where operational attributes are present is a pain. In addition, at least one customer did not use OpenLDAP as the backend store. Having a persistent UUID on the account was necessary because other portions of the product could retain references to an old account even once deleted that would need to be consistent if the account was restored.
Using your own identifier ensures that will not be an issue. Also, if you do things like allow backing up/restoring user entries that have gotten deleted, a restored entry (depending on the method use) may end up with a new entryUUID.
Yes, you should only use the recommended backup procedures.
The above not really isn't about backup, it's about restoration. See above.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Howard Chu wrote:
Quanah Gibson-Mount wrote:
entryUUID is defined in RFC4530, as an internal LDAP attribute. Personally, if you need a UUID for tracking, I would create your own specific to your application/needs. For example, when I was at Stanford, we used suRegID (stanford university registry ID) and when I was at zimbra, we used zimbraID (zimbra identifier). There have been format changes in the past that required wiping out some of the generated attributes when going between releases.
This is bad advice. If you actually want a UUID then use entryUUID. As noted, it is defined in RFC4530 which means it isn't going to change. The format of UUIDs is well-established in internet standards.
This very much depends on which data source is supposed to be the authorative source of new objects and how the whole object life-cycle looks like.
If the LDAP entry is persistent and it is *the* main authorative source of an object the LDAP entry's 'entryUUID' attribute may serve as a good unique ID.
But note the strong if-clause in the sentence above. If you e.g. merge various data sources you might have to generate UUIDs in a separate process *before* the object even reaches your LDAP server. BTDT.
Ciao, Michael.
openldap-technical@openldap.org
-
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount