Julio Maidanik said: > > 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
Aaaaahhh.... eyah. It was that whole redirected standard-in diversion I was questioning. Well, I think it's a little bit bigger deal than you, but then perhaps your mail volumes are not stressing your systems nor have a five 9's lights out 24/7/365 requirement that is also NOC/OpenView friendly. In my world performance and remote access are important. If you think this is added complexity then perhaps you don't have a good grasp of the advantages of not getting a call-out at 3:00 am. dp _______________________________________________ http://lurker.clamav.net/list/clamav-users.html
