In procedure 2.4 (and the associated workbook) section 6 shows "&" as the operator to run both the commands (aide --check and aide_mon.sh).
Is that correct? If I do && the second command is not run if the first one fails -- which will be the case when aide --check results in changes from the baseline.
The commands in cron are run with /bin/sh as SHELL, right?
So is "&" a typo? Isn't that the operator to background a job? Should the separator really be a semicolon, so that both commands *always* run and the second one (aide_mon.sh) waits for the first to finish. (aide --check can take a long time depending on how many files you have :-), even with its database etc.)
Thoughts? @chetantiwary
Subu
This indeed appears to be a typo. You can submit a bug report by clicking on the feedback button. No guarantee that it will be fixed quickly, however.
Subu, if the intent was actually to have that second command execute, only after
successful (i.e. error free) execution of the first command, then that single
ampersand is definitely incorrect!!! You are correct in your statement about
the single ampersand's purpose: run the preceding command in the background.
Even if the first command were to run in the background, which means that
the single ampersand would be appropriate, that command COULD NOT
be followed by a semicolon, to then be followed by a second command:
Command1 &; Command2 -> syntax error ALL DAY LONG
I sent feedback that '&' should be replaced by ';'.
I never meant to have ';' in addition to '&". Even the instructor in the video seems to be confused. He tried && during the lecture and then just typed & in the guided exercise
The script aide_mon.sh looks for a pattern "Looks okay" in aide log file and if not found sends an email to a user. So it's important that first command aide_check be complete before looking for the pattern in the output log of aide /var/log/aide/.. detailing what is different from the baseline. (AIDE ... Advanced Intrusion Detection Environment). If "Looks okay" is found, no problems; so no email sent.
I am skeptical of looking for a hardcoded "Looks okay" string in a log file. Coudn't the return status of aide_check be better? Just asking.
Hello @SubuRama !
Thanks for the feedback , I have alerted the concerned team regarding the same.
I think we need "&&" here : 1, to run aide --check first to generate the file integrity report in the log - generally it takes time to run and generate the report in the log file in real scenarios.
2. then and only then , check for the "Looks okay !!" message ( or the opposite condition of it ) in the log file ( which will be generated once aide --check has run i.e $? gives 0 )
So, a "&&" should be helpful here. ";" will mean that both commands will be executed sequentially regardless of the exit status of the first command. The second command (/root/aide_mon.sh) will always run after the first command, regardless of whether the first command succeeds or fails.
Regarding the "Looks okay !!" message , I think it is pretty simple and straight forward and is benefecial for all administrators throughout the world.
I am not sure but I think we can customize it via the aide conf file ( never tried to do it yet ).
No. && means "and"; so if the first command fails (due to short cut of logical operations) the second one will not run.
For aide_check "fail" means a return code of non-zero -- that is aide found something different. Then the second part won't even run.
We want to execute the second command (the shell script that checks the log to see if things were "okay" and if not sends an email).
Using && will not make the second command run all the time which is what is desired.
What I meant by hardcoding "Looks okay" is that tomorrow if the developer changes that string to "Looks alright!" the scripts that rely on that particular string will fail
Subu
We want the second part ( the shell script ) to run only when we have a log report , hence I think && AND operator is justified here : Because we care about the log report and based on the log report - it will be analysed - whether we have an issue or everything looks okay !
If we dont have a log report in the first place and the second command is executed - it will be a false alert - so it is logical to have the first command returns an exit status of 0.
Command failure ( aide --check ) for any reason is not a reason to send an intrusion report IMHO. An admin has to test beforehand that the command is working as expected and the user with which cron is configured has the necessary permission to run the first command.
Just having the log does NOT send an email with the report. That's why you have the "grep" on that log. If "okay" is NOT found, then email is sent. So the second command should always run.
The log is generated whether aide finds something different or declares all is OK. Command aide --check is not going to fail "for any reason". We have already checked all that during the setup. Then we set up the baseline too after doing an initial aide --init and a aide --check etc.
Subu
Red Hat
Learning Community
A collaborative learning environment, enabling open source skill development.