On Wed, 2016-10-05 at 17:03 +0000, Mailvaganam, Hari wrote: > W.r.t a vSphere implementation that has a requirement for entryUUID -- has it, or plans to, support in 389-DS -- https://fedorahosted.org/389/ticket/137? > Hi, I've just commented on the ticket, but there is a better explination. We already have a UUID type on all objects in directory server, specifically nsUniqueId. It looks like: nsuniqueid: 0344fb02-703811e5-a62bf7bf-2add969e Looking at the rfc, we can see: https://www.ietf.org/rfc/rfc4530.txt entryUUID: 597ae2f6-16a6-1027-98f4-d28b5365dc14 So if we compare these: 0344fb02-703811e5-a62bf7bf-2add969e 597ae2f6-16a6-1027-98f4-d28b5365dc14 Not quite the same. Turns out that nsuniqueId is displayed in 4 groups of 8 characters, where as entryUUID is https://www.ietf.org/rfc/rfc4122.txt displayed. We could actually write a plugin, that when you request entryUUID, it actually reads the nsUniqueId and formats it correctly: before: 0344fb02-703811e5-a62bf7bf-2add969e after : 0344fb02-7038-11e5-a62b-f7bf2add969e There would still be some other discussions to be had, but the answer is "We kind of support it, but not quite". Sadly, for a feature like this, it won't happen "overnight" for 1.3.5, and I can't guarantee when it would be ready. You may be able to "cheat" and in the syntax do something like: 01core389.ldif: Change line 41 from: attributeTypes: ( 2.16.840.1.113730.3.1.542 NAME 'nsUniqueId' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation X-ORIGIN 'Netscape Directory Server' ) TO: attributeTypes: ( 2.16.840.1.113730.3.1.542 NAME ('nsUniqueId' 'entryUUID') DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation X-ORIGIN 'Netscape Directory Server' ) ldapsearch -LLL -x -s base -b 'dc=example,dc=com' entryUUID dn: dc=example,dc=com entryUUID: 55d3cd25-8b4f11e6-b30bf972-f1241077 The quirk here is that you have to REQUEST entryUUID in the search, else it will still return as nsUniqueID: ldapsearch -LLL -x -s base -b 'dc=example,dc=com' + dn: dc=example,dc=com nsUniqueId: 55d3cd25-8b4f11e6-b30bf972-f1241077 So if you could post the access log search query that vmware is attempting, we can let you know if this work around will work or not. -- Sincerely, William Brown Software Engineer Red Hat, Brisbane
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
