[OpenAFS] On-Access Virus Scanning
Sun, 20 Dec 2009 09:46:31 -0500
Holger Rauch wrote:
> what solutions would you recommend for on-access virus scanning on an
> OpenAFS host acting as a central file server (offering access to home
> and other AFS volumes to OpenAFS clients running mostly Windows XP)?
> I know that e.g. the Dazuko kernel module can scan "normal" ext3
> filesystems and is used by NOD32 (probably also by other virus
> scanners). The problem with that module is that there are many
> versions floating around on the net and I'm not sure which one to
> choose for a Debian Lenny system (arch: x86-64). Besides, I don't have
> any experience whether it works well in conjunction with OpenAFS.
> The main eason(s) why I'm asking this is that I
> a) don't want to/can not rely on the client PCs (running at least Win
> XP with NOD32) having their virus scanner signature constantly up to
> date. (Yes, I know the best would probably be to talk my boss into
> issuing an appropriate policy in writing which forbids user's to
> disable automatic updates to virus scanner signature databases
> and/or disabling the virus scanner completely, but I don't want to
> rely solely on some piece of paper.)
> b) I don't want our file server to turn into a "central virus
> exchange" (thus other client PCs accessing the file server may get
> infected by a virus "behind the scenes")
> Any advice is greatly appreciated!
> Kind regards,
As I understand, the "virus scanner on all clients" is the best
supported for now. The OpenAFS fileserver doesn't support on-access
virus scanning. That said, we would love to see that.
It might be possible to kludge something together using the verbose
fileserver logs and a virus scanning daemon with AFS administrator
privileges, but I'm not sure if anyone has done such a thing. I think
most folks rely on client-side virus scanning.
Another options would be a scheduled full virus scan of your whole AFS
tree, but that's painful and possible dangerous if you hit a circular
path or go outside your own cell.