On Sat, 29 Nov 2003 19:33:54 -0800, Tom Mitchell wrote:
From: Keith G. Robertson-Turner redhat-forums@genesis-x.nildram.co.uk tripwire-2.3.1-18.rhfc1 has now been submitted for QA.
Thank you....
Well it was one of those essential apps that was missing from the release (valid reasons or not) and it just had to be done. Although long term you should be thinking of aide (or that other one I can't remember ... that's got a name like a camel trader).
Note that the current release is tripwire-2.3.1-18.fdr.3.i386.rpm
For tripwire (-17) I have been tinkering with redirecting standard error in /etc/cron.daily/tripwire-check so redundant messages like:
How verbose you like your reports, is entirely up to you, but understand that it isn't a good idea for this to be implemented as a default setting, particularly for a security tool. I'll Leave it up to the individual.
What larger set of troubles might this generate and what errors am I blindly tossing once tripwire is correctly setup and running?
Well in general, redirecting stderr to null means that if - e.g. - the app crashes, you won't know why, and like I said, in the case of a security app, that probably isn't a good idea. Yes tripwire is a bit repetitive in its output, but ... well it's up to you really.
So far I like the result and tripwire does the right thing as far as I can tell. i.e. am I doing something stupid?
If you're just tinkering with a home system, then no ... not stupid, not particularly useful either, but not stupid.
If it's a server or production system in a mission critical environment, then ... well let's put it this way, I wouldn't do it.
Keith.
On Sun, 30 Nov 2003, Keith G. Robertson-Turner wrote:
On Sat, 29 Nov 2003 19:33:54 -0800, Tom Mitchell wrote:
From: Keith G. Robertson-Turner redhat-forums@genesis-x.nildram.co.uk tripwire-2.3.1-18.rhfc1 has now been submitted for QA.
Well it was one of those essential apps that was missing from the release
....
For tripwire (-17) I have been tinkering with redirecting standard error in /etc/cron.daily/tripwire-check so redundant messages like:
....
Well in general, redirecting stderr to null means that if - e.g. - the app
....
If it's a server or production system in a mission critical environment, then ... well let's put it this way, I wouldn't do it.
Thank you, after sleeping on this I will do it differently for my home tinkering machines.
Instead of dev/null I will redirect stderr to a cautiously specified tmpfile file. Then after the normal report is generated "cat" that error file. This way if things error out in unexpected ways I will still see the errors in the email from cron, but at the end.
In this case the missing files do have "standard" tripwire policy lines such that if the files show up they are noticed as a new file then they are tracked for changes after a --update. I did not wish to simply remove them from the policy to tidy up the email. i.e. If removed from the policy, I might not notice the arrival when they show up after I load some new rpm, module or package that justified a specific standard policy.
Regards, TomM