latest passdb checkins

[Simo Sorce]

Gerald Carter wrote:
> 
> Simo Sorce wrote:
> >
> > > Also, I have reworked the TDB passdb backend.  In doing so,
> > > I realized that this DBM is to limited for a passdb.
> > > Thus the "T" meaning "Trivial".  We need a more robust DBM
> > > with transactional support and multiple indexes for searching.
> > > Right now, the Berkely DB looks like a good replacement.
> > > The Gnu DBM may be another possibility, but I have not explored
> > > it as much.
> >
> > Hi, when I created it I hit the problem the tdb has
> > only one index. We may change to GnuDBM or BerkeleyDBM
> > (just reading the implementation, but which platforms we
> > will cut using this DBs ?), but I think a way to use TDB
> > and act as it is a multi indexed database may be achieved!
> 
> The problem is the operations must be atomic.  Searches
> are fine.  It's updates that become the problem.  You will
> have to implement 3 updates for one record.  Suppose your
> machine goes down in between updating the actual SAM_ACCOUNT
> and the seach table ro rid lookups.  The next time you
> lookup by a rid, the search may indicate the the entry
> does not exist when in fact it does.

I think any way a good practice would be to set a flag (semafore?) of
being active in one tdb field at opne and clear it just before closing
(when we are sure all the transaction are finished).
After a crash we should check the flag a start a tdb scan to assure all
the references exist (just an enum of USER_XXXX and then a check that
RID_YYY and UID_ZZZ exist and are correct).
I think we need anyway an option like this to force a check through
tdbedit for example, so that the user may check all is ok on his own or
recover the database after the crash.
This would resolve also the problem of the growing tdb as we may
implement a database rewrite to compact it at every check
!!

> 
> > we really need to find data only in 3 ways:
> > 1. search for username
> > 2. search for rid
> > 3. search for uid
> 
> Yup.
> 
> > for user simo, uid 500, rid 012345678 we have:
> > USER_simo -> SAM_ACCOUNT
> > UID_500 -> USER_simo
> > RID_012345678 -> USER_simo
> 
> I thought about this, but the lack of atomic updates is
> the big issue.

I think implementing a lock would be enough.

> 
> > what we need to take care is key consistency but, that
> > not a big problem. If you think it is worth I would take
> > the work to implement this idea!
> 
> I don't really.  By providing pluggable backends, we
> are not creating an unnecessary dependence.  Simply a richer
> alternative to smbpasswd.   Someone could write another in
> mySQL is they wanted.

Yes infact I have tried it at the samba 2.0.7 times but not ever
finished it ;P

> Again, initially I want
> 
>         o smbpasswd
>         o Full local SAM style DB
>         o AD style schema in LDAP

OK, as soon as I get some free time I will go and test my ideas on tdb.

-- 
Simo Sorce - Integrazione Sistemi Unix/Windows - Politecnico di Milano
E-mail: simo.sorce at polimi.it
Tel.int: 02 2399 2425 - Fax.int. 02 2399 2451
-----------------------------------------------------------------
Be happy, use Linux!