On 8/31/07, Martin Schröder <[EMAIL PROTECTED]> wrote: > > 2007/8/31, Jan-Henrik Haukeland <[EMAIL PROTECTED]>: > > With this many files I think you would be better of using something > > like auditd, famd or some other file watching daemon, which I suspect > > there are many of, though they may also exhaust memory with > > Or use tripwire or sth similar. Or mount the filesystem read-only.
Hi Martin, Mounting the file system read-only is indeed a possibility but the problem is that in doing so it doesn't allow an organization of small people to learn about the complexity of the resources on the file system (e.g., we expect them to be mostly static but what if there is something we don't know about that finds itself needing to write to the read-only file system)? I've never tried out tripwire, but why couldn't monit be evolved to the next level of evolution such that it could be just as good at scaling to hundreds of thousands of file system resources for monitoring purposes? Personally, I really like monit a lot and prefer to stay using it for these purposes rather than have to spend time getting to know about tripwire or something similar. I'd love to see an evolution of monit for scaling to large resources. Is there a good reason why monit should not evolve to that next level of maturity? Best > Martin > > > -- > To unsubscribe: > http://lists.nongnu.org/mailman/listinfo/monit-general >
-- To unsubscribe: http://lists.nongnu.org/mailman/listinfo/monit-general
