Dennis Peterson wrote: > > Ok - so here's what I did. Configured clamd to use a Unix socket. This > requires you disable the TCP socket option - can't have both. Wrote a > perl tool that connects to that socket and sends it the location of a > file I wish to scan. Works great, fast, efficient, etc, just like > you'd expect from a Unix socket vs a TCP socket. But now I have no > remote way test the daemon as I do when it is using a TCP socket. My > interest is to have a TCP control socket available for simple tasks > such as reporting status, version, etc., when clamd is configured to > use a Unix socket. > > Now I can write a simple perl listener that will accept a TCP > connection from inetd and send the query to the local Unix socket but > that seems a bit messy, and frankly, a hack. I can also write a Big > Brother extension that runs locally and reports the health too, but > yet another hack. > > One solution would be to allow either a Unix socket, or a TCP socket, > or both at the same time. > > dp
I am glad to know that indeed the socket is used for control purposes only, as I concluded from the logs. As for your request, I would vote for keeping clamd simple! If you need a TCP socket, then use a TCP socket: This shouldn't affect performance too much, taking into account that these control messages are relatively only a few. Julio _______________________________________________ http://lurker.clamav.net/list/clamav-users.html
