in reply to can a script change itself?

Why do you want to create a unique UID?

When you create an LDAP entry, it is assigned a Distinguished Name attribute (DN) -- this is a unique identifier for that LDAP entry.

The LDAP server itself has these DN's stored at that point, there's no reason to store them separately for your script -- they can be retreived at any time.

However, if you're dead set on storing unique identifiers, store the DN's in a hash for later reference. I like to use Data::Dumper to dump the hash into a data file for later reference and update.

Cheers,
Matt

Replies are listed 'Best First'.
Re^2: can a script change itself?
by strat (Canon) on Mar 25, 2005 at 09:53 UTC
    • Well, if you use "cn=surname firstname,ou=..." as a DN, there might be the problem if there are two persons with the same name in the same ou... so an additional really unique id might be helpful (at least to make DN really unique): "cn=surname firstname uniqueid,ou=..." (or even think about using this uniqueId as cn... but that might cause problems with certificates...)
    • If you want to do a periodic data synchronisation to different data sources, you need something constant... and a person's name doesn't need to be constant (e.g. in case of marriage).. so for meta directories, I often add a unique attribute to the ldap object which can also be copied to other data sources to get a link to objects in that directory

    The way I prefer to use is to enhance the ldap schema by another objectclass (e.g. lastUniqueIdentifier) which contains among others the attribute an attribut where the last used unique identifier is saved (e.g. lastUniqueUID). This way I can use it from several synchronisation jobs...

    Best regards,
    perl -e "s>>*F>e=>y)\*martinF)stronat)=>print,print v8.8.8.32.11.32"

[reply]
      From the perl LDAP FAQ:

      Every entry in a directory has a Distinguished Name, or DN. It is a unique Entry identifier throughout the complete directory. No two Entries can have the same DN within the same directory.

      On the other hand, a relative distinguished name (RDN):

      Every DN is made up of a sequence of Relative Distinguished Names, or RDNs. The sequences of RDNs are separated by commas (,). In LDAPv2 semi-colons (;) were also allowed. There can be more than one identical RDN in a directory, but they must have different parent entries.

      I see your second point. However, I suppose it depends on how you're handling records -- in the event of marriage, for example, you could look at it as one LDAP entry being deleted and a new one created. That's fine if you don't care about tracking the history of name changes.

      Cheers,
      Matt

[reply]

        yes, it's possible; but is it also good practise (especially for bigger directories)? if you work with tree structures in your person directory (e.g. ou's and departments and so on), people objects might change there position in the tree, and so sooner or later there may be collitions with the same cn in the same ou. That is one of the reason why I prefer having a unique naming attribute value (e.g. cn=surname givenname uniqueId), another one is that you can think about saving all the person objects in one container (e.g. ou) and if a person changes department, you don't need to revoke and create certificates because the dn doesn't change...

        well, deleting and creating a person object in case of a name change often is a bad idea:

        • in a metadirectory, you would loose all links to other data sources you synchronize data from and to, and also loose the data, and perhaps can't write those change of surname in other data sources you synchronize and get data inconsistency
        • if you delete and create a user in ActiveDirectory, it will normally loose all it's data

        So a rename or move often is the better way

        Best regards,
        perl -e "s>>*F>e=>y)\*martinF)stronat)=>print,print v8.8.8.32.11.32"

[reply]

In Section Seekers of Perl Wisdom