Peter, Thank you so much! That was the issue. I disabled prelink as you indicated and everything ran fine.
I hope a future version of AIDE can take prelink into account in such a way that this problem is circumvented, if that's possible. I'll try reenabling it from time-to-time to see. --Rich Dupuy State of Louisiana -Division of Administration -Office of Computing Services -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Peter McInerney Sent: Friday, March 23, 2012 5:07 AM To: Aide user mailinglist Subject: Re: [Aide] Welcome to the "Aide" mailing list we had something similar on our systems, prelink was causing files scanned to have their times updated thus making the scans almost useless, we worked around this by disabling prelink on our linux servers (as there has been no benefit in leaving it on) on our redhat systems, it was a case of changing /etc/sysconfig/prelink PRELINKING=no and then finally a `prelink -a` once this was completed, we were able to successfully generate and then complete an aide check without any changes being noticed -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Richard van den Berg Sent: Friday, 23 March 2012 5:22 PM To: Aide user mailinglist Cc: [email protected] Subject: Re: [Aide] Welcome to the "Aide" mailing list On 23 mrt. 2012, at 05:49, Marek Dohojda <[email protected]> wrote: > I am running AIDE 0.14 on centos from base repositories. everything is > working fine till I run check. what I did to test was to run touch /bin/ls. > then I run aide --check. After it finished it updated time stamp on the /bin > directory itself. to ensure this is a problem, I rerun this with same > results. I tied another directory and different server with same results. I > am sure I am missing something stupid, but could someone please me a hint? Aide does not change the ctime or mtime of anything it scans. Only the atime which is not checked or reported by aide. There must be another mechanism on your OS responsible for this. Richard _______________________________________________ Aide mailing list [email protected] https://mailman.cs.tut.fi/mailman/listinfo/aide ______________________________________________________ CONFIDENTIALITY NOTICE This electronic mail message, including any and/or all attachments, is for the sole use of the intended recipient(s), and may contain confidential and/or privileged information, pertaining to business conducted under the direction and supervision of the sending organization. All electronic mail messages, which may have been established as expressed views and/or opinions (stated either within the electronic mail message or any of its attachments), are left to the sole responsibility of that of the sender, and are not necessarily attributed to the sending organization. Unauthorized interception, review, use, disclosure or distribution of any such information contained within this electronic mail message and/or its attachment(s), is (are) strictly prohibited. If you are not the intended recipient, please contact the sender by replying to this electronic mail message, along with the destruction all copies of the original electronic mail message (along with any attachments). ______________________________________________________ _______________________________________________ Aide mailing list [email protected] https://mailman.cs.tut.fi/mailman/listinfo/aide -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Richard Dupuy Sent: Thursday, March 22, 2012 3:30 PM To: 'AIDE user listserv' Subject: [Aide] AIDE changing directory mtimes I'm having an odd problem with AIDE where it seems that the AIDE scan itself is changing the mtime and ctime on an odd list of directories as it rolls through the filesystems. First, this is a CentOS 6.2 system... <snipping out unnecessary configuration detail> I suspect the distribution of filesystems has something to do with causing AIDE scans to affect the ctime and mtime of directories, but I'm not sure what would trigger that. Possibly something to do with cross-filesystem symlinks? I really have no idea, but the only work around I've found so far is to remove mtime and ctime monitoring from my config file (which I'd rather not do, but isn't so risky). Otherwise, is there a way to write a selection line for recursively scanning a directory that will check the mtime and ctime for every file type except the directories? (Oh, and I'm also having the problem where the / directory doesn't actually get scanned even though I have an explicit selection line requesting that, but it sounds as though that problem has been corrected upstream and will be fixed in a forthcoming release.) And finally here's what happens when I run AIDE checks. Keep in mind that I've waited up to a couple of days between AIDE checks, verified that the ctime and mtime was unchanged before beginning an AIDE check, ran the check on a very still sandbox system, and then was notified that the mtime and ctime had changed on the same directories every time after the AIDE check was kicked off... <snipping out more unnecessary configuration detail> Any help with this would be greatly appreciated. Thanks, all! :-) --Rich Dupuy State of Louisiana -Division of Administration -Office of Computing Services _______________________________________________ Aide mailing list [email protected] https://mailman.cs.tut.fi/mailman/listinfo/aide _______________________________________________ Aide mailing list [email protected] https://mailman.cs.tut.fi/mailman/listinfo/aide
