Shared Directory parameter for some tdb files

[Steven Danneman]

> > It now occurs to me that the distinction which I'm really making is
> > between persistent TDB files and temporary TDB files.  And via the
> FHS
> > support, this distinction has already been made using the STATEDIR
> and
> > CACHEDIR parameters.
> >
> > For now you can disregard the previous patch and RFC as I
investigate
> > if the FHS implementation will fulfill my need.
> 
> The FHS mode presents many problems IMO. For the implementation, see
> get_dyn_STATEDIR() and get_dyn_CACHEDIR() in dynconfig.c .
> 
> In non-fhs-mode these returns lp_lockdir(), while in FHS-mode these
are
> fixed to STATEDIR and CACHEDIR, respectively.
> 
> It also seems that the introduction of cachedir and statedir has not
> been carried through completely: STATEDIR is used in
> lib/util.c:state_path(), which is used in some places where originally
> lock_path() had been used. But CACHEDIR is not used at all.
> 
> One problem here is that these statedir and cachedir options are only
> virtual config options, and not integrated into loadparm like the
other
> options. I would like to have a proper splitting into three fully
> configurable options lockdir statedir and cachedir (say), that should
> be used consistently throughout.
> 
> I think this needs proper fixing, but this needs to be done very
> carefully in order not to break existing installations.
> 
> If you come up with thoughts about this matter, I will gladly
> collaborate on this, since it is a real pain in the neck.  :-)

Hey Michael,

Thanks for the in-depth analysis.  You've confirmed everything I thought
from looking at the code yesterday.
 
I think the proper plan is:

1) Make STATEDIR and CACHEDIR configurable through autoconf as well as
loadparm, and make them default to LOCKDIR.  This makes them first class
citizens, not just usable with FHS.

I'm working on a patch to do all this right now and it seems straight
forward.

2) Audit all callers of state_path() and lock_path() and change them to
the proper path.

This is obviously more error prone part and like you said needs to be
done carefully.  I'll take a first stab at this after I finish the first
patch and send you the results.

-Steven