El 2010-09-02 a las 19:59 +0200, Giuseppe Sacco escribió:
> Hi Camaleón,
> sorry for replying quite late, but I would like to make a few points
> clean before releasing squeeze. So, please, help me in understanding how
> tot solve the problem you reported.
Don't worry and thanks for replying :-)
> My point of view is that changing a default behaviour, when you have a
> package already packages since long, it something I would avoid.
> Moreover, I believe that this default is good: you give administrator
> one months in order to check all archives, you give users one months in
> order to get back to their faxes, you avoid disk to be filled without
> noticing it.
Do not get me wrong. Running a cleaning routine is good for a default
setup, but if the cleaning routine can lead in files deletion (in this case,
it removes unreferences files located in the fax archive folder), that
makes no sense to me, as it is an adventurous path.
Let me compare this situation with an e-mailsystem spool. Should we have
enabled by default a routine to automatically delete spam messages
stored in the users folders? I guess no. That is a very delicated task
that has to be reviewed by the administrator and I think any of us
prefer to get an "out of space" warning than loosing a single e-mail
for their users/clients.
With faxes the situation is quite similar. Maybe people does not care
about faxing because it seems to be an outdated (legacy) technology but
it is still being very much used under some environments and in some
countries. Even more than e-mail :-)
That said, I also understand that Debian policy for this package has
its own background (I admit I landed into Debian some months ago. Before
using Debian I was using openSUSE and being there never had to touch
HylafAX configuration to avoid things like this) and I am aware that
any modification of the current configuration can be even non advisable.
> Il giorno sab, 19/12/2009 alle 15.37 +0100, Camaleón ha scritto:
> [...]
> > 1/ Fax archiving is not always a good idea. As received and sent faxes
> > are removed from the active queues, they are not longer available for
> > the users to review them in an easily manner. Anyway, is a task that
> > has to be carefully reviewed by the administrator before getting
> > executed.
>
> You are right here. Every FAX is archived only under two different
> options: first, the administrator configure the system so that every fax
> is archived; and second, the fax submitter ask for archiving it.
>
> > 2/ There is a second (and more severe) problem with this routine: it
> > deletes files that should not be deleted at all.
> >
> > For example, I maintain a big spool for faxes, documents and logs
> > (since 2.006) and that routine automatically deletes (just "erases"
> > without archiving) any unreferenced file that founds.
> >
> > That means the files are completely lost, none option to restore them
> > from /var/spool/hylafax/archive.
>
> This is addressed by backups. That's why people do backups: when you
> miss a file, you get it back from tape.
I agree, but backups should be only used for uncommon/unexpected
situations not the ones you can encounter for making use of the
defaults options for a program :-).
> Moreover, are you telling that you store non-hylafax documents
> under /var/spool/hylafax? I don't really understand your sentence,
> sorry.
No, they are hylafax generated files, but with no reference (ID) at all
or just missed. As per "man faxqclean":
***
"(...) After scanning for completed jobs faxqclean scans the docq subdirectory
and builds up a table of document files. Files that are not referenced
by any job and that are older than a specified threshold are removed.
***
> > 3/ That behavior forced me to disable the routine at all so it gets not
> > executed but I fear that any security update of hylafax-server package
> > just restores the script and activates it again.
> >
> > So my wish is for this script to be disabled by default because the way
> > is configured right now it can delete your files.
>
> no, don't worry. cronjobs are conffiles, so whenever you install a new
> package, if anyone changed the original shipped cronjob, debconf will
> ask you if you want to replace the changed file with the new shipped
> version.
>
> Anyway, you write that you had to *completely* disable the routine. Are
> you suggesting you would like a more parametric routine? What part would
> you live in place and what part would you disable?
The fact is I just removed the "execute" permission of the cron job
located under "/etc/cron.weekly/hylafax" just to be sure the routine does
not get exceuted.
But maybe we could reach a more pragmatic approach that avoids
disturbing the standard configuration of Debian's hylafax policy.
How about letting the user to control this behaviour by adding a
configuration parameter at "/etc/default/hylafax" that allows
enabling/disabling this? Take this just as an example:
#enable cron jobs, 0 to disable at all, 1 to run them
RUN_CRON_JOBS=1
# if RUN_CRON_JOBS is enabled ("1"), choose the ones that may be
# runned, in a selectively amnner. RUN_CRON_JOB_ARCHIVING controls
# whether if "faxcron" and "faxqclean" should be executed and
# RUN_CRON-JOB_STATS controls if "xferfaxstats" should be run.
RUN_CRON_JOB_ARCHIVING=1
RUN_CRON_JOB_STATS=1
I hope you get the idea and I would also like to hear another options
to handle that :-)
Default values could be "enabled" to keep the current Debian's policy
for HylaFAX, but the user can easily change that behavior by just
modfiying a variable value. Of course, it should be documented at the
readme file so newcomers can be warned about the current setup and how
can be avoided.
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
