separation of config from cached data
Brought to you by:
adamkennedy
CVS Monitor doesn't appear to save its repository and
modules configuration in a safe place so they can be
reused. If you set the working directory to /tmp or
/var/tmp and something (like a reboot or cron job) comes
along that wipes them out, not only the cache is lost
(which is good) but also all information the admin entered
about repositories and modules. It would be better to
save this info in a file alongside main.conf.
Logged In: YES
user_id=153576
Can you provide some information on the operating system you
are using? CVS Monitor already does a couple of tricks and
warnings on systems it recognises are actively hostile to
data in /tmp.
For debian, we already warn against using /tmp, and an
earlier poster has provided a directory designed
specifically for caches.
The main problem is that CVS Monitor can write huge amounts
of cache data, so we need a "real" cache dir, and to not
write directly into the web directory.
An upgrade of the configuration part of the MetaData would
be nice, but I lack the time as usual. Any contributor is
welcome to provide an alternative at any time. The Storable
solution for modules is convenient.
Logged In: YES
user_id=874180
I have installed CVS Monitor 0.6.3 on Redhat Linux 7 and 8,
and Solaris 7. The Solaris system has very slow disk access
and 1G of /tmp in main menory, so using /tmp there seems an
obvious choice.
I didn't realise CVS Monitor's cache wasn't designed to be
installed in /tmp (or any other place from which files can be
deleted automatically by an external process or reboot), and I
think it would be very useful to support this.
However, whether or not it is supported to put the cache in
/tmp is really a separate issue. Even when it isn't supported, I
do want to separate my configuration information (i.e. the CVS
repositories and modules to monitor) out into a separate file.
That would allow me for example to migrate a CVS Monitor
installation from one host to anther by copying the config file
and saying "go" instead of having to re-enter all the
configuration information by hand.
Logged In: YES
user_id=153576
Well, the initial reason for /tmp was to try and find
somewhere, _anywhere_, that was outside of the web user's
directory, since they can often have quotas, and that this
cache directory is ( by default ) writable by the web user.
In the end, /tmp was the only location one can reliably find
a place that allows the typically unpriveleged web user to
write data...
In the current installation, it will at least look for a
couple of common alternatives. Some Mandrake/Debian/etc
linux distros create /var/cache/(httpd|apache) as writable
by the web user, and CVS Monitor will use one of those in
preference if it can find it.
As for seperating the config data out, it would involve
something along the lines of modifying
CVSMontitor::MetaData::Module::(load, save, reload, possibly
_freezable). It's not a priority for me personally. Someone
else is welcome to implement this, or pay me/others to do so.