clamd handicraft work

Stephen J. Smoogen smooge at gmail.com
Mon Jul 25 14:00:18 UTC 2005


On 7/24/05, Enrico Scholz <enrico.scholz at informatik.tu-chemnitz.de> wrote:
> smooge at gmail.com ("Stephen J. Smoogen") writes:
> 
> > Would it be useful to put something in the crontab that randomizes the
> > time of the update like this untested syntax?
> >
> > 0 0 * * * perl -le 'sleep rand 14400;' && {/usr/bin/freshclam --quiet
> > && { test -x /usr/sbin/clamav-notify-servers && exec
> > /usr/sbin/clamav-notify-servers || :; }}
> 
> mmh... I will definitively not add a dependency on perl just to calculate
> a random number ;)
> 

hmmm sorry should have used:

awk 'BEGIN{x=0.0; srand()};{x=(rand()*14400); print x;}'

:)

> This cron-part evolved over the various versions in the following way:
> 
> 'sleep $[ RANDOM % ... ] && ...'
> ================================
>    PROs:
>    * no additional deps
>    * crontab remains the same across subsequent packages; so it is
>      possible to apply changes (when it was not modified locally by the
>      administrator)
> 
>    CONs:
>    * does not work; it is impossible to use a literal '%' in crontabs
>    * updates happen too randomly. E.g. they could be executed at 02:59,
>      03:00 and 08:59. The first one-minute timediff is too short and the
>      05:59 delay might be too long
>    * there is a cron-instance which uglifies the 'ps' output by hanging
>      around for several hours ;)
>

Yeah.. the bonus is that it might end up being a better load balance
on the clamd servers versus some large set picking 03:14 thinking they
were being original.
 
> 
> I am thinking about a helper script which is similarly to the first
> method and gets applied as
> 
> | 0 */3 * * *  root   <helper-script> || ...
> 
> This script uses 'hostid' to determine the initial sleep time but can be
> configured by /etc/sysconfig/<something> also.
> 
>    PROs:
>    * crontab remains stable across different versions
>    * updates happen exactly every three hours with a constant, random
>      delay
>    * can be disabled without editing the crontab (that's why the '||')
> 
>    CONs:
>    * there is yet-another helper script

There are a couple of pros for a helper script:

1) Can be run again later by the administrator to fix the crontab
entry it blown away.
2) It can help when dealing with the small school computer
administrator (eg science teacher who probably doesnt really know much
about computers) who got a Linux mail system set up because some
students dad convinced them on the better cost value. Having to walk
that person through at 2 am on these can be a pain for both. [Not that
this has happened.. really.]


-- 
Stephen J Smoogen.
CSIRT/Linux System Administrator




More information about the fedora-extras-list mailing list