CVS update: samba/source

[Jim McDonough]

> > The login cache read/write/delete is outside of the ldap backend, so it
could
> > easily be called by other backends.  tdbsam won't call it for obvious
> > reasons, and authors of other backends need to decide if they want to
> > implement it.
>
> Which are these obvious reasons?
Adding a tdb cache to tdbsam is pointless.  Nothing good can come from it.
Despite our warnings, people use rsync to replicate tdbsam, and I don't
think the interactions would be beneficial.  Also, if the idealx
replication project produces something, I would imagine tdbsam would be the
backend of choice, and we'd be conflicting there.
> Sorry but have followed the discussion around this problem only and
> haven't seen the code, can you just put down 2 words?
> Wouldn't it be better to be consistent and lett all backend behave the
> same way?
besides the tdbsam reasons above:
- Each backend should evaluate if it is even appropriate for that tbackend
- Every backend would already have to have its own way of dealing with
getting time on the backend storage, which in some cases would mean
changing each backend
- It would have been put in more places in passdb than we have backends (I
know, this isn't a valid reason, I'm just pointing it out.

In fact, we need to consider the appropriate way of turning it off when the
user wants, but I didn't consider another smb.conf parm a good thing.  I'm
very open to ideas here.  It was suggested to me as a compile or configure
option, and I thought perhaps of a policy option, or perhaps something in
our ldap schema itself would be more appropriate.

I put the generic caching functions in a separate file so other backends
could use them, but just not the logic that decides how to actually cache.
I also didn't use gencache for 3 reasons: it was silly to be going
back/forth from text<->numbers just to use them; these are not cache
entries that expire based on a timestamp when they are created, but
relative to the current password policy, so the gencache expiration logic
wouldn't work; wasn't sure it was a great idea for performance, though I
admit this is just conjecture.

----------------------------
Jim McDonough
IBM Linux Technology Center
Samba Team
6 Minuteman Drive
Scarborough, ME 04074
USA

jmcd at us.ibm.com
jmcd at samba.org

Phone: (207) 885-5565
IBM tie-line: 776-9984