This is a discussion on Re: separating persistent and ephemeral state (in lockdir) - Samba ; > Samba currently defaults to storing all of its state into lockdir. > I don't think that this is optimal, because it means that > "persistant" state (e.g, winbindd_idmap.tdb) is kept in the same > location as "ephemeral" state (e.g, ...
> Samba currently defaults to storing all of its state into lockdir.
> I don't think that this is optimal, because it means that
> "persistant" state (e.g, winbindd_idmap.tdb) is kept in the same
> location as "ephemeral" state (e.g, locking.tdb).
> This is a problem because some systems (e.g, embedded) want to
> keep persistent state in a separate location to where run-time
> state is stored, since the latter may be on a file-system that's
> (re-)initialized at boot.
> The author of the "fhs.patch" in packaging/Debian/** seems to
> agree with this sentiment. Based on that patch and my own changes,
> here's a quick analysis of the category of each file that's
> accessed via lock_path():
> lock_path() (e.g, /var/run/samba)
> state_path() (e.g, /etc/samba/private)
> cache_path() (Debian separates this from lock_path() for some reason)
I didn't know about this patch yet, but I think this is a good idea, and
I'll integrate that for samba4 if no one doesn't like it.
tridge: do you agree?
jerry,jra,vl,gd: for samba3 this would also make sense, but maybe with
all tree defaulting to the current lock_dir() to not