Jerry Wrote: >Seriously John if you are going to start with a new product, one that >you readily admit you have not got a working knowledge of, you have got >to RTFM. Create a jail and place your new program in it and then fire >it up. Check the logs, see what is happening under the hood. Try >different configurations until you get the desired results. Once you >have stress tested your application, then move it into your production >machine. Anything less, and you are asking for trouble. If you are the >only user, then you can pretty much only screw yourself. However, if >others depend on you, then that is a totally different story.
Thank you Jerry for those kind words of wisdom. However, I too am a full time developer and have placed it in a Jail (home network) just for that reason. I am in the process of stress testing and learning how it works. The issue is not my configuration, or even my lack of knowledge as it is an add-on included in the firewall. It is that there is a limited manual (i.e. RTFM) that has been difficult to find and some are harder to understand on many open-source project. This one is no exception in that it is all on a wiki that I could not find until today when I finally saw a posting to it. I would like to point out that I happened into this use through a 3rd party that was kind enough to point out the advantages of ClamWin and IPCOP as a firewall. Just to stress my point, the manual and wiki are for the Unix/linux version and not the ClamWin version. IPCop has it buried in an add-on and has removed most of the configuration options. And it restarts whenever the Clamd service fails. I will take all the blame for my own faults (which are many) but feel it necessary to point out that the use of 3rd party tools to keep track of an application is FAULTY at best and BROKEN at worst. Microsoft has held the office community captive for years with the desktop application that "Needs" a server running in the background to make it more than a glorified typewriter. <maybe some exaggerations> >Why don't you install an application to monitor the daemon. Some can be >accessed via the web, while most will email you if something goes wrong. >Most will automatically restart the failed application. <sarcasm on> But the need to buy or get another product to keep track of my current product is like adding a chase vehicle to watch your trailer because your truck doesn't have mirrors configured properly. It works for the rich who have others to drive the car and money to pay for it. It does not work for the poor who are limited and don't have the resources. <sarcasm off> The truth is... (1) we buy computers to work harder... (2) we buy servers to link the computers in network... (3) we buy AV to protect the servers and the computers on the network.... (4) we buy firewalls to protect our network because the AV is limited... (5) we buy other software to watch the AV and firewalls because they can't be trusted to do their jobs. ... When does it stop???? How big does our house of cards need to get before we start thinking about what we are advocating???? >Define: PROBLEM -- If it is incorrectly configured, the problem can usually >be localized to the user sitting in the chair in front of the monitor. If your going to be critical (which I do not want to be or have been), I am not the only one running IPCOP (test or production) and just to be clear; the ability to restart a service who is silently failing because of a configuration file does not solve the problem, IT ONLY HIDES IT. Oh, and just for your information, I have been "Testing" these products for 6 months without issue. But with the inclusion of needing to find, get, and test even another package to "Watchdog" the process. I am not sure that I can readily advise any of my customer base to switch at this time. I will just have to keep testing. John. _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
