samba 4: a new configuration system?

[Alan DeKok]

Andrew Tridgell <tridge at osdl.org>
>  > From a quick strace it does a fcntl64(3, F_SETLKW, {type=F_WRLCK,
>  > whence=SEEK_SET, start=0, len=0}) on /etc/.pwd.lock before firing up
>  > $EDITOR.  
> 
> It uses a write lock? 

  On .pwd.lock.  Otherwise two admins can edit /etc/passwd at the same
time.

> That could only work if nobody else makes lock
> calls on the file at all, as otherwise the whole system would come to
> a standstill while the adminisistrator is editing /etc/passwd.

  Yup.  Which is why the lock isn't on /etc/passwd.

  It's "cooperative" locking.  If you "vi /etc/passwd" at the same
time, there may be race conditions.

> An alternative might be to use a lock that is unique to ldbedit, so
> the underlying tdb won't see it (for example, create a .lck
> file).

  Exactly.  "sam.ldb.lock" is the cooperative lock file for edits to
"sam.ldb".


> hmm, maybe there is a way. ldbedit could do this:
> 
>  1) fetch the records, giving ldif1
>  2) launch editor, user does edits, giving ldif2
>  3) get the lock
>  4) re-fetch the records, giving ldif3
>  5) if ldif1 != ldif3, then unlock and give an error message
>  6) take diff of ldif1 and ldif2, and apply
>  7) unlock and exit
> 
> It means a bit more cpu time, but should be safe. 

  That's complicated.  Why not just:

 1) create sam.ldb.lck || die "can't get lock"
 2) fetch records, giving ldif1
 3) launch editor, user does edits, giving ldif2
 4) take diff of ldif1 and ldif2, and apply
 5) unlock & exit

  This presumes that the clients aren't editing the same records as
the admin is, but that's a separate issue.

  Alan DeKok.