Re: how to check uniqueness of uidNumber ?

[Jim C <jcllings@tsunamicomm.net>]

The problem does not occur at the db level.  It occurs at the script 
level because one must first retrieve the uidNumber and then do the 
modify.  Between the two lines of code a race condition can possibly 
occur between scripts.  Here is an example function written in php:

function getnewuid ($ds)
{

$booleantest=FALSE;

        //We get a number of retries equal to NUMRETRIES
for($idx=0; $idx < NUMRETRIES && !$booleantest ;$idx=$idx+1 )
     {

     $entries=ldap_get_entries($ds, ldap_search($ds, PROXYDN ,"cn=*"));

     /*
     If another such script starts AND finishes it's ldap_mod_replace
     before we get ours started below, then we have a
     race condition at the script level.
     */

     if($entries[0]["uidnumber"][0] < MINUID )
          $change_entry["uidnumber"] = MINUID;
          else
          $change_entry["uidnumber"] = $entries[0]["uidnumber"][0] + 1;

        //This, at least, is atomic.
          $booleantest=ldap_mod_replace($ds, PROXYDN, $change_entry);

       }//end of for loop

     if($booleantest)
          return $change_entry["uidnumber"];
          else
	  die("Timeout error! Unable to set uidNumber in PROXYDN.  To many 
users being added from other sources?\n");

}//end of function getnewuid ($ds)

So lets say that we have more than one person adding users using the 
script in question.  What if script A ends a search just as script B 
starts a modify?  If B somehow finishes the modify before A begins it's 
modify, which could concievably happen despite the odds, then you wind 
up with two users with the same uid.  Problem is that we would rather 
there be no chance at all.  <grins and hikes up suspenders> After all, 
we are not writin' Windoze code, here. ;-)

Howard Chu wrote:
> You don't need locks, LDAP already provides atomic actions. There's more than
> one approach to solve a generic problem, you just have to understand the
> approach that LDAP supports.
> http://www.openldap.org/lists/openldap-software/200208/msg00358.html