Ad_astra
Flight Engineer Flight Engineer
Flight Engineer
  • 234 Views

Guided Exercise: Configuring Change Tracking

Jump to solution

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 

Labels (1)
0 Kudos
1 Solution

Accepted Solutions
Ad_astra
Flight Engineer Flight Engineer
Flight Engineer
  • 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. 

 

View solution in original post

3 Replies
Ad_astra
Flight Engineer Flight Engineer
Flight Engineer
  • 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. 

 

carlos_arias
Moderator
Moderator
  • 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!

RHCA - Level III
Free software for free people
Ad_astra
Flight Engineer Flight Engineer
Flight Engineer
  • 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 

0 Kudos
Join the discussion
You must log in to join this conversation.