[Samba] Scripting the next UID/GID number to use

[Rowland Penny]

On Wed, 30 May 2018 08:09:50 +1200
Andrew Bartlett <abartlet at samba.org> wrote:

> On Tue, 2018-05-29 at 21:00 +0100, Rowland Penny via samba wrote:
> > On Tue, 29 May 2018 15:50:44 -0400
> > lingpanda101 via samba <samba at lists.samba.org> wrote:
> > 
> > > Hello,
> > > 
> > >      I'm developing a script to create a user and pass along all
> > > the necessary unix attributes required. I'm successful except
> > > when I go to increment msSFU30MaxUidNumber or
> > > msSFU30MaxGidNumber. I'm not sure how to use ldbedit to script
> > > this process. Any guidance would be great. Thanks.
> > > 
> > > - James
> > > 
> > > 
> > > 
> > 
> > Something like this:
> > 
> > # UPDATE msSFU30MaxUidNumber/msSFU30MaxGidNumber
> > # Input : $1 $2
> > # $1: what to update (msSFU30MaxUidNumber or msSFU30MaxGidNumber)
> > # $2: Next Number
> > #
> > # Output : Nothing
> > _updatemax () {
> > echo "Updating $1"
> > 
> > newid="dn:
> > CN=$domainNETBios,CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System,$domainDN
> > changetype: modify replace: $1
> > $1: $2"
> 
> Actually, you would want to use (something like this, not tested):
> 
> changetype: modify
> add: $1
> $1: $2
> delete: $1
> $1: $2
> 
> This is called a constrained update, and avoids a race where the value
> changes between the search and the modify.

Fair comment, but 'msSFU30MaxUidNumber' is a single valued attribute
and surely the 'add' will fail because the attribute already exists.
Following on from this, the delete will fail because the value to be
deleted isn't what is there now

So I think it what you actually mean is:

changetype: modify
delete: $1
$1: ($2 - 1) # what is there now
-
add: $1
$1: $2

> 
> That will then be atomic (either succeeds or fails as a whole) on one
> DC, but sadly not across the whole domain, which is why it isn't part
> of our standard feature-set (we don't like to create tools that have
> inherent races).
> 
> That just means always run this against one specific DC to be safe.

Totally agree
 
Rowland