Re: trend-update.pl v1.00 released

Hello Tobias,


On Wed, Oct 13, 2004 at 08:40:23AM +0200, Tobias Reckhard wrote:
> >>I see that you handle reloading and/or restarting of trophie in your 
> >>script. But what about the VirusWall itself or, more specifically and in 
> >>my case, the HTTP scanner? Do you know if it needs to be signalled 
> >>and/or restarted as well?
> 
> Regarding this question, I found the following TM knowledge base 
> article: 
> http://kb.trendmicro.com/solutions/search/main/search/solutionDetail.asp?solutionID=3235 
> (mind any line wrapping that may be introduced).

Hmmm.  This  article  seems to be a more definite answer than anything
I've read so far. Until now, it wasn't clear to me whether receiving a
SIGHUP  would  force  an  update  operation  to   take   place   (i.e.
check/download/install)   or   make   previously  downloaded/installed
updates effective (which is what this article says).
So far so good, this is very much Trophie-like behaviour.

> 
> So it appears trend-update.pl could use two strategies:
> 
> 1. Send the InterScan daemons a SIGHUP when it's downloaded the pattern 
> update, just like it does to trophie. I haven't tried this, though, 
> because I'm not sure how to find the PIDs of the relevant daemons yet.
> 
> 2. Don't do anything and have the InterScan admin set the following 
> options in intscan.ini:
> 
>   update=auto
>   update_interval=<check_interval_in_minutes>
> 
> In any case, since trend-update.pl is updating the pattern files, 
> VirusWall's own autoupdate should be deactivated with the following 
> options in intscan.ini:
> 
>   Method=Automatic
>   Frequency=none
>

In that case, when if ever will it notice the updated  patterns?  It's
not clear to me.
 
> I have now used the second strategy.

What  did  you  observe?  Was  VirusWall  using  the  updated patterns
downloaded  by  my  script?  (is  there  any   way   to   see   this?)

> I will probably investigate 
> strategy 1, though, since it seems more elegant. I expect to be able to 
> find out which processes need a SIGHUP sent to them by selectively 
> stopping and restarting the individual VirusWall components and checking 
> the system's process table.
>

That sounds like a good approach. Using strace can be another. It will
show you if a process gets SIGHUPed.

> >The safest would be, of course, to stop and restart VirusWall from the
> >code section in trend-update.pl that SIGHUPs Trophie.
> >But you may dislike this.
> 
> The problem I see here is the disruption of service. I need to restart 
> VirusWall when performing an engine update (more on that later), but I'd 
> like to do it only then.

I can understand that.

(...)

> On to a different topic: Scan engine update. When trend-update.pl has 
> performed a scan engine update, it restarts trophie, so the latter loads 
> the new libvsapi.so. I need to restart the VirusWall daemons for the 
> same reason. I found the following KB article on how to manually update 
> the scan engine: 
http://kb.trendmicro.com/solutions/search/main/search/SolutionDetail.asp?SolutionID=8352&btnSearch=+GO+

> 
> I'll see if I can extend trend-update.pl myself, but I'm not much of a 
> Perl coder myself.. I'll let myself be guided by what you did for 
> trophie and send you the result when I'm done.

Well,  I  presume  that  Viruswall  installs /etc/init.d script(s?) to
start/stop the various daemons. You could just invoke these from
a wrapper script that calls *both* the Trophie start/stop script and  the
ones  from   Viruswall.   Then   just   define   $starttophiecmd   and
$stoptrophiecmd as calls to this wrapper script.

All  this  raises  the  question  of  making  trend-update.pl  a  more
general tool. Right now it's clearly focused to Trophie only. It's
not aimed at becoming a general tool to manage update of  the  various
Trend products on Linux. I'm thinking about this, but I won't have the
time to  make  massive  changes  to  it  in  the  foreseeable  future.

Greets,
_Alain_