Re: Re: event cache management (no, not code cache) -- W32/Nimda filter

Sean Straw / PSE wrote:

The design consideration here is that an SQL dependance means anyone who might want to use the module (this is for dealing with CodeRed and W32/Nimda and no doubt the next IIS worm that strikes) must do SQL setup for a new database, etc. oh, and after verifying that the whois protocol is indeed as trivial as I thought is was, I've dealt with that - so at the moment, my script isn't dependant upon any external utilities (obviously, support for updating a firewall would require an external script (fired up from cron), but that isn't required unless you're going to actually enable the firewalling capability, and it still isn't something that is exec'd from the PHP script).

Just to throw my two cents in, I'd agree with Richard that SQL would make this much easier. Yes, you'd need to set up a db or table for the SQL stuff, but it's going to be much more scaleable, and my hunch is most people that are concerned enough about nimda and future worms/viruses/etc are either going to have some SQL database at their disposal, or will expend the time/effort to get one. Also, consider those with multiple web servers - each of them logging distinct data would be overkill - a separate DB machine would take the load off them (network only, no disk) and keep a centralized copy of logs. Good luck. Michael Kimsal http://www.tapinternet.com/php/ PHP training courses 734-480-9961