samba 4: a new configuration system?

[Andrew Tridgell]

Tim,

 > That might be enough for editing smb.conf[.tdb].  Are you thinking of
 > allowing a LDAP backend for every possible tdb in Samba4?

For all the ldb's, but not all the tdb's. For example, it makes no
sense to allow brlock.tdb to be in ldap (or even in a ldb), but it
does make sense for the wins database to be able to be stored in ldap.

I've recently been running with:

  sam database = ldap://localhost
  ldapsrv:samdb = sam.ldb

and 'make test' passes fine.

We need to do a few more things to make this viable:

 1) we need some way to specify authentication information for a
    bind. The above only works because our ldap server doesn't require
    a bind.

 2) we need to be able to specify a basedn, especially for things like
    the wins database which doesn't specify one itself

 3) we would need to create real schemas for the various DBs, and add
    objectclasses to some of the ldb calls (again, wins is a good
    example).

None of this is a really high priority for me, but I do think its
worth supporting. 

 > 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? 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.

We would have the same problem with ldbedit. If someone started
editing sam.ldb, and we took a lock, and the admin took a couple of
minutes to do the editing then by the time they had finished nearly
every windows client would have an error dialog up saying that it had
an error reading from the network drive.

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). That still means that changes made via RPC calls could
interfere with changes made with ldbedit, but I can't see how we can
avoid that.

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. 

Anyone have any alternative suggestions?

Cheers, Tridge