This is a discussion on separating persistent and ephemeral state (in lockdir) - Samba ; --Mla3UN0L0Ly2to/J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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" ...
Content-Type: text/plain; charset=us-ascii
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 don't understand the rationale for separating lock_path() and
cache_path() -- I have them the same on my system -- but at least
separating state_path() is very useful. Is there a reason that
this part of the Debian fhs.patch stuff hasn't been incorporated
into the "mainline", even as a subset of the --with-fhs option.
(E.g, having a state_path() function that's based on configure's
"statedir" and using that)?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)
-----END PGP SIGNATURE-----