[PATCH] 2/2: Associate file locations to newly introduced path variables

[Steve Langasek]

Hi Jerry,

On Mon, Oct 15, 2007 at 06:30:11PM -0500, Gerald (Jerry) Carter wrote:
> > -	cache_fname = lock_path("idmap_cache.tdb");
> > +	cache_fname = cache_path("idmap_cache.tdb");

> >  	DEBUG(10, ("Opening cache file at %s\n", cache_fname));

> We've had this discussion before and your patch still suffers
> from the same assumptions.  Tdb files may operate as both
> cache and persistent state.  For example, the idmap_cache.tdb
> and winbindd_cache.tdb are required for offline logons.

This "persistent state" is nevertheless a cache, because these files aren't
the original copy of the data and can be reproduced from the source as
needed, provided the network is up.

Most cache data (/var/cache) is not deleted from Linux systems under normal
circumstances.  Deleting cached data will frequently be an inconvenience;
deleting a debconf cache from a Debian system may cause annoying prompts
next time you go to upgrade your system, deleting a squid cache will cause
delays while pages are re-downloaded and will inhibit offline operation,
deleting /var/cache/apt will also require a network to fix as
previously-downloaded packages will go missing, and deleting
/var/cache/fontconfig probably (I haven't tried) makes your desktop very
unhappy the next time you try to log in.

Putting stuff in /var/cache doesn't mean "please delete me with abandon".
The rationale for /var/cache in the FHS is:

    Rationale: The existence of a separate directory for cached data allows
    system administrators to set different disk and backup policies from other
    directories in /var.

I think that applies fairly to the idmap and winbindd caches.  Not that
either cache should ever be very large, but there's really no need to
include them in backups.  And if a user deletes /var/cache/samba/* while
offline and using winbind-based logins, well, putting the data in
/var/lib/samba doesn't prevent users from aiming ignorantly at their toes
either.

> If you remove the $(lockdir)/printing/*tdb, an print jobs sent
> by Windows clients that are held in the print queue after a reboot
> will now appear as "Remote Downlevel Document".

But /var/cache is not cleaned on reboot, so in what sense is "after a
reboot" relevant here?  Is this simply "after a restart of smbd"?

I can understand the position that printjob decriptions are persistent state
rather than a cache, since they can't be recreated once lost.  (Actually, I
gather they should really be treated as spool data, but that's a very minor
difference.)  If you say that the data in these per-printer tdbs should be
treated as persistent, I'm content to make that change in the Debian
packaging regardless of whether this patch is accepted upstream, because
that would be a matter of improving our conformance with the FHS.

But on the point of whether /var/cache should be split out at all, I'm happy
even if upstream continues in perpetuity to have a default policy of
treating cache data as persistent data (and I understand the upstream
challenges of upgrade support th such a change to defaults).  The object of
the current patch is simply to *label* the files according to which FHS
category they logically belong to, so that users or distributors who want
their Samba installations to comply with the FHS have the option of doing
so without extensive (and ongoing) patching.

> I can give you the data_path() changes.  But -1 on the state and cache
> path separation.  FHS-compliant or not, in this respect, the Debian
> packages break Samba functionality.

Sorry, is that statement based on user feedback?  Aside from some bugs
resulting from historic miscategorization of particular files, I have never
heard a complaint from a Debian user of the Samba packages that traced to
the FHS patching.  I'm quite confident that Samba works well while
conforming to the FHS, just like all other software we ship in Debian.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon at debian.org                                   http://www.debian.org/