On Wed, 5 Aug 2009, J. Oquendo wrote:
I made a butchery for my own servers.
Well written article, and comprehensive too. Well done! My problems with interpreted scripts to handle parsing of log files in the way your article describes are: * Scanning happens in chunks, a cron job for example. If for some reason your log file gets pretty big, maybe tail or grep takes a long enough time for you to have TWO versions of the script running, which could lead to some unexpected results. * Scanning happens in 5 minute granularity, and you may be screwed by the time the script gets around to running again. * The code is interpreted, not compiled, and thusly less efficient with greater overhead. * Grepping and Copying involves lots of IO. In a production environment, log files can get really big, making parsing, grepping and copying costly, especially every 5 minutes. There is a great benefit to on-the-fly log parsing and action with a compiled tool that uses minimal resources. For most people, all the tools are functionally the same -- block hosts that pass a certain threshold or set of rules. But when you get into production systems with a lot of customers and a lot of attacks, the interpreted script (PHP, Python, bash/sh/tcsh) simply doesn't scale as well as a compiled, native OS byte-code long-running daemon. I don't want to get into another language flame war, we all use what works for us during the time we need such things, and when it stops working for us, we change. There's 9 ways from Sunday to do the things we all have to do as VoIP folk, none of them are wrong, every choice has tradeoffs. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------