

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- 234 Views
Hello
I am working through the "Guided Exercise: Configuring Change Tracking" section of RH342 and have encounered problems with the aide_mon.sh script.
The script runs via the cron job but does not email the student@servera.lab.example.com. Instead, the mail is sent to root on servera.lab.example.com.
Running the script manually (as root) from the command line DOES send the email to the student@servera.lab.example.com.
Is there a setting within the the cron environment that is overiding the email address in the script or is there a default value elsewhere that is causing this behaviour?
Following the exercise through to the end, there also appears to be a 2nd issue.
After the AIDE database has been updated and renamed, the cron job continues to generate email alerts (to root) even when the inspection of the log file shows that there are no changes.
Running the aide_mon.sh script manually DOES NOT send any emails to the student@servera.lab.example.com.
I have run the lab twice without success in this task.
This is proving a good opportunity to try out the 'Scientific Method' of problem solving!
Unless I am mistaken, all emails from cron tasks are sent to the owner of the cron job; here it is root. So the emails will always go to root and not the student user. It is not possible to run the aide command without elevated privileges which the student user does not have.
Any advice welcome.
Thank you
Accepted Solutions


- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- 169 Views
Well, it looks like I have answered my own question; always rewarding to work it out yourself!
The undesired behaviour with the cron job appears to have been caused by the use of 2 separate commands in /etc/cron.d/aide.
Runing the aide --check command in cron will always produce some output in the form of the AIDE log. This log output (both good or bad) will be emailed to the cron job owner, which is why root was always getting emails, regardless of the aide --check outcome.
My solution to the problem:
Move the aide --check command from the cron file into the /root/aide_mon.sh and redirect the output to /dev/null.
File contents for /etc/cron.d/aide:
# AIDE Checks and alert
*/2 * * * * root /root/aide_mon.sh
====================================
File contents for /root/aide_mon.sh:
/usr/sbin/aide --check &>/dev/null
if ! /usr/bin/grep "Looks okay" /var/log/aide/aide.log &>/dev/null
then
/usr/bin/cat /var/log/aide/aide.log | /usr/bin/mail -s "AIDE Alert" student@servera.lab.example.com
fi
====================================
Note: I have fully qualified the path names to the files and binaries to avoid any potential path problems.
I also could have used grep -q instead of redirecting the output to /dev/null.
I have tested this in the labs and all looks OK. I shall attempt to forward my findings to the RHLS team to see if there are any errors with the lab environment or exercise.
I hope this may be helpful to anyone studying the RH342 course.


- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- 170 Views
Well, it looks like I have answered my own question; always rewarding to work it out yourself!
The undesired behaviour with the cron job appears to have been caused by the use of 2 separate commands in /etc/cron.d/aide.
Runing the aide --check command in cron will always produce some output in the form of the AIDE log. This log output (both good or bad) will be emailed to the cron job owner, which is why root was always getting emails, regardless of the aide --check outcome.
My solution to the problem:
Move the aide --check command from the cron file into the /root/aide_mon.sh and redirect the output to /dev/null.
File contents for /etc/cron.d/aide:
# AIDE Checks and alert
*/2 * * * * root /root/aide_mon.sh
====================================
File contents for /root/aide_mon.sh:
/usr/sbin/aide --check &>/dev/null
if ! /usr/bin/grep "Looks okay" /var/log/aide/aide.log &>/dev/null
then
/usr/bin/cat /var/log/aide/aide.log | /usr/bin/mail -s "AIDE Alert" student@servera.lab.example.com
fi
====================================
Note: I have fully qualified the path names to the files and binaries to avoid any potential path problems.
I also could have used grep -q instead of redirecting the output to /dev/null.
I have tested this in the labs and all looks OK. I shall attempt to forward my findings to the RHLS team to see if there are any errors with the lab environment or exercise.
I hope this may be helpful to anyone studying the RH342 course.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- 72 Views
Hi, thanks for bringing this up again. Seems like the ticket opened to resolve this has fallen into the forgoten land. My proposed solution to this issue is to substitute the && operator in the cronjob for an || operator, so that the second part executes if the first one fails. https://issues.redhat.com/browse/PTL-14083
About the issue of the root receiving emails instead of the student I couldn't replicate it.
Thanks again for your research and efforts to improve the course guide!
Free software for free people


- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- 64 Views
Hi
Thank you for the solution.
Is the & a typo in the following code?
/sbin/aide --check|| & /root/aide_mon.sh
It does not look right to me and causes the following error:
-bash: syntax error near unexpected token `&'
Thanks