Re: Configuration DB
On Thu, Aug 12, 2004 at 01:01:34PM -0700, Brian Nelson wrote:
> On Thu, Aug 12, 2004 at 12:28:42PM -0600, Paul E Condon wrote:
> > On Thu, Aug 12, 2004 at 08:43:04AM +1000, Cameron Hutchison wrote:
> > > Once upon a time Jason Rennie said...
> > > > On Mon, Aug 09, 2004 at 02:09:08AM -0700, Brian Nelson wrote:
> > > > > The debconf database is nothing more than a temporary cache of answers
> > > > > gotten from the user. Debconf will regenerate this data by asking any
> > > > > questions it needs to.
> > > >
> > > > If the Debian designers had this attitude, everything would go into
> > > > /var/cache:
> > > >
> > > > What, you want to run oowriter? Oops, just deleted that from my
> > > > cache. Downloading openoffice.org-bin.deb from www.debian.org.
> > > > Please wait.
> > >
> > > Worse than that. All configuration files could be stored in /var/cache
> > > with this logic, since vi can just regenerate this data by getting you to
> > > type it in again.
> > >
> > > As I see it, if debconf is asking you the questions again, *it* is not
> > > regenerating the data, but *you* are.
> > >
> >
> > I've looked at the contents of /var/cache/debconf on my machine. I
> > can't make out what it really contains. It certainly doesn't seem to
> > contain the answers that I gave to configuration questions during
> > package installation.
>
> $ grep Value: /var/cache/debconf/config.dat
>
> are all answers you either gave or debconf gave defaults for (depending
> on your debconf priority setting).
>
Brian, you are correct. I did not look far enough. The stanzas that I looked
at did not contain Value: clause, but I see others that do. I also see my
selection of initial sources.list action "edit by hand", but no indication
of what my edits were. Yes, I did edit sources.list by hand, and backing up
/var/cache/debconf/config.dat would not save those edits.
> > As I said in a earlier post, if you are concerned that it *does* contain
> > information that should be checkpointed, you can move it to /etc and
> > either put a softlink in /var/cache, or edit /etc/debconf.conf to point
> > to its new location within /etc
> >
> > Someone who mistrusts the design of debconf might try renaming
> > /var/cache/debconf to /var/cache/hide.debconf and see what happens.
> > Is a new /var/cache/debconf created automatically?
>
> You should never remove directories in /var/cache. Files must be
> regenerated, but directories do not need to be, so something may break
> if you do.
>
> See
> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARCACHEAPPLICATIONCACHEDATA
>
adding fuel to the fire, here is what I find in the above:
quote
_________________________________________________________________
Purpose
/var/cache is intended for cached data from applications. Such data is
locally generated as a result of time-consuming I/O or
calculation. The application must be able to regenerate or restore the
data. Unlike /var/spool, the cached files can be deleted without data
loss. The data must remain valid between invocations of the
application and rebooting the system.
Files located under /var/cache may be expired in an application
specific manner, by the system administrator, or both. The application
must always be able to recover from manual deletion of these files
(generally because of a disk space shortage). No other requirements
are made on the data format of the cache directories.
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.
---------------------------------------------------------------------
end quote
If the data in /var is easily regenerated, why is backup of these data
mentioned in the rationale as a justification for separate directories?
It seems to me that at least one of the contributers to the standard
expected that at least some sys-admins would want to backup some of
the data in /var. The standard guarentees the possibility of backup of
selected parts.
I conclude that the OP's belief that the wording of the FHS,
apparently precludes ever needing to backup /var is mistaken. So, OP,
do backup whatever parts of /var you feel you need to preserve.
--
Paul E Condon
pecondon@mesanetworks.net
Reply to: