Resolved Daily erroro message "run-parts: /etc/cron.daily/asl exited with return code 127"

[onki]

Hi,

since yesterday I do receive the above error message in an email.

Any idea how to resolve the problem?

Best regards
Onki

 

[GerdSchrewe]

Me too.
Ubuntu 16.04, Plesk Onyx 17.8 Update 26 on V-Server.
Switched from Comodo to Atomic (ModSecurity) and back again, still get this mail.

 

[IgorG]

Try to fix it with

# apt-get update
# apt-get upgrade

and then check that there is no error in the output of commands

# run-parts /etc/cron.hourly/
# aum -c

 

[GerdSchrewe]

Thanx a lot Igor.

# apt-get update = no updates
# apt-get upgrade = no upgrades

# run-parts /etc/cron.hourly/
# aum -c
# Configuring Atomic Secured Linux (ASL) 5.0-5664 for h2519287.stratoserver.net.
-bash: syntax error near unexpected token `('

I dont know what to do now. Can you help again please...

 

[IgorG]

Looks like something broken on Atomic side again.
Navigate to Tools & Settings > Web Application Firewall (ModSecurity) > Settings.
Temporary select any other Rule Set, for example, OWASP ModSecurity, and click 'Apply'.

 

[GerdSchrewe]

OK, switched to OWASP ModSecurity, applyd and did a restart.
I will let you know tomorrow morning or can I manually initiate the error message earlier?

Had to switch over to Comodo coz OWASP blocked some functions.

 

[papak]

Try to fix it with

# apt-get update
# apt-get upgrade

and then check that there is no error in the output of commands

# run-parts /etc/cron.hourly/
# aum -c

That fixed the bug, but again and again these problems with Atomic are annoying. Obviously they don't have many things under control anymore.

Update 20. 10. 2018: This morning are mails again in my inbox. Not fixed.

 

[Wikibear]

Hello together,

if fixed many things in last time with help of this forum, but at least it's seems to be a server outside problem...

Distributor ID: Ubuntu
Description:    Ubuntu 16.04.5 LTS
Release:        16.04
Codename:       xenial

# apt-get update
# apt-get upgrade

Gives me:

N: Ignoring file 'plesk.list.ai_back' in directory '/etc/apt/sources.list.d/' as it has an invalid filename extension

A KB from Plesk tells me ignore it. It will be fixed later...

# run-parts /etc/cron.hourly/
# aum -c

Result: Configuring Atomic Secured Linux (ASL) 5.0-4374 for domain.ltd

Looks good hm? Why i get this over daily?

OK other thing. Why did i get updates or syncs if it's switched off?



I switched it off and on switch over to OWASP and Off and on again and get this:





So what can i do now to fix this??? I switch it off. But get error 127... But that can't be a solution!

 

[GerdSchrewe]

I still get this Error Message every morning too.
Daily error message "run-parts: /etc/cron.daily/asl exited with return code 127"
i tried what Igor said 2 times:
# apt-get update
# apt-get upgrade
# run-parts /etc/cron.hourly/ (daily(weekly/monthly too)
# aum -c
In the 2nd run no error messages, Result: Configuring Atomic Secured Linux (ASL)....
I switched from Atomic to Comodo and back.
I deinstalled Mod Sec and installed it again.
Still get this error Mails.

When i decide to change permanently to Comodo instead of Atomic can i delete the asl files in etc/cron hourly/daily/weekly/monthly to get no more mails, or is this dangerous?

PS
I have a second server with Ubuntu 18.04 instead of 16.04: Both with Onyx 17.8 Update 26 and Comodo (Atomic for 18.04 not available at the moment).
From this server i do not get these mails.

Thanx a lot in advance.

 

[trialotto]

@GerdSchrewe, @Wikibear and @papak,

It is NOT recommended to run the command aum -c if you ONLY want to check that your Atomicorp config is up to date.

Use the command aum -ck instead!

In addition, it is very likely that there is some exceptional coincidence of circumstances, being

1 - firewall settings blocking ports or IPs: check your iptables and/or, if you are using Plesk firewall extension, see below for comments
2 - license update related issues: Plesk license server uses 3 different IP addresses nowadays, they have to be reachable
3 - package related issues: if you have one of the two issues mentioned above, you are very likely to have outdated packages and problems related to that

and all of the above is just a minor summary that is not exhaustive.

First, a solution to (potential) issue 2: just allow all of the relevant IPs by default by running the commands

iptables -I OUTPUT -p tcp -d 195.214.233.80,195.214.233.81,195.214.233.82 -m multiport --dports 443,5224 -j ACCEPT
iptables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

and this should take away all license related issues.

Second, a check for the presence of firewall related issues can be done by proceding with the following method:

a) if you are on a Virtuozzo based VPS or virtual machine: run the command cat /proc/user_beancounters and inspect the column "failcnt" for the row "numiptent": any value that is non-zero is not a good sign and actually indicates that your firewall is running wild and not working properly: do an inspection of iptables and do a reboot!

b) if you have a dedicated server or another VPS or virtual machine: skip step a)

c) if you have Plesk Firewall extension installed: inspect the firewall rulesets and

- remove unnecessary rules,
- check the order of rulesets,
- change one specific ruleset and save the modification: it can be the case that you get an error notification, there might be a bug in this extension,

and note that I am not sure yet whether the Plesk Firewall extension has a bug or that iptables (or other native packages) are buggy, but there is certainly some unexpected behavior when working with Plesk Firewall extension.

Third, a solution to (potential) issue 1 AND 3: temporarily disable the Plesk Firewall extension (if you have it activated) and do the following:

- run the commands: apt-get update && apt-get upgrade
- open Plesk Panel and go to "Tools & Settings > Plesk: License Management > Retrieve keys (click)" to refresh all license keys, including Atomicorp related keys

and if you do not encounter any problems, then the issues encountered are almost certain to be firewall related.

At this moment, you should have an up-to-date system with proper licenses.

Fourth, reactivate the Plesk Firewall extension, if you have it installed.

Fifth, do a renewed check as described in step 2: if you have allowed the Plesk license servers (see step 1) and you still have issues with

- Atomicorp's ModSec rulesets and/or renewal thereof: check contents of /etc/asl/config and verify that a username and password is present

IF /etc/asl/config is absent or IF /etc/asl/config does not contain username and password: run the command aum -c

- Plesk License updates and/or other package updates: recheck the firewall rulesets and adjust rules, especially the first rules in the firewall (for example, do not use a "allow IPs, deny others" as a first rule, this is often too prohibitive)

IF a cleanup of Plesk Firewall extension rulesets or iptables rulesets does not help: inspect Fail2Ban!


Hope the above helps a bit........

Regards.........

 

[trialotto]

I still get this Error Message every morning too. [ ......... ]

@GerdSchrewe

The daily notifications may be annoying, but in most cases you can safely ignore them (read: they are often temporary by nature).

When i decide to change permanently to Comodo instead of Atomic can i delete the asl files in etc/cron hourly/daily/weekly/monthly to get no more mails, or is this dangerous?

Dangerous? Yes and no.

No, in the sense that any ModSec ruleset can offer you protection.........but keep in mind that

- some ModSec rulesets are better than other ones: Comodo is certainly not the best out there,
- some ModSec rulesets better fit the purpose: OWASP is the most stringent, but OWASP also blocks genuine non-malicious traffic (which is not good at all)
- combining ModSec rulesets from various providers is possible, but I will diverge on this topic at this moment,

and in general, you should choose the ModSec ruleset that best fits your purpose, which would be Atomicorp's paid-for subscription in this case.

Yes, changing ModSec rulesets can become dangerous if your servers are scanned or attacked by bots: as soon as you change a ruleset, you (often) can expect the activity of bots to increase significantly, potentially leading to iptables related issues, security breaches and so on.

Moreover, if you change from a rock-solid ModSec ruleset like the paid-for Atomicorp rulesets to mediocre ruleset like that of Comodo, some security loopholes in the rulesets are certain to be exploited before you are even able to take counter-measures.

In short, it is NOT recommended to change: just pay for the Advanced ModSecurity Ruleset by Atomicorp.

Note that ASL (Atomic Secured Linux), available as a Plesk extension, is totally different thing: this is not really recommended.

I switched from Atomic to Comodo and back.
I deinstalled Mod Sec and installed it again.
Still get this error Mails.

I am pretty sure that this is (either) firewall related (or) related to Plesk's particular way of including the Atomicorp ModSec ruleset.

In short, you can exclude the firewall issues by resolving them and if the issue still persist, just wait until Plesk Team addresses the (potential) issue.

In the meantime, just ignore the error notifications, if and only if a check with the command aum -ck indicates that your Atomicorp rulesets are up-to-date.


Hope the above helps a bit ...... and explains a bit........

Regards.........

 

[GerdSchrewe]

@GerdSchrewe

The daily notifications may be annoying, but in most cases you can safely ignore them (read: they are often temporary by nature).



Dangerous? Yes and no.

No, in the sense that any ModSec ruleset can offer you protection.........but keep in mind that

- some ModSec rulesets are better than other ones: Comodo is certainly not the best out there,
- some ModSec rulesets better fit the purpose: OWASP is the most stringent, but OWASP also blocks genuine non-malicious traffic (which is not good at all)
- combining ModSec rulesets from various providers is possible, but I will diverge on this topic at this moment,

and in general, you should choose the ModSec ruleset that best fits your purpose, which would be Atomicorp's paid-for subscription in this case.

Yes, changing ModSec rulesets can become dangerous if your servers are scanned or attacked by bots: as soon as you change a ruleset, you (often) can expect the activity of bots to increase significantly, potentially leading to iptables related issues, security breaches and so on.

Moreover, if you change from a rock-solid ModSec ruleset like the paid-for Atomicorp rulesets to mediocre ruleset like that of Comodo, some security loopholes in the rulesets are certain to be exploited before you are even able to take counter-measures.

In short, it is NOT recommended to change: just pay for the Advanced ModSecurity Ruleset by Atomicorp.

Note that ASL (Atomic Secured Linux), available as a Plesk extension, is totally different thing: this is not really recommended.



I am pretty sure that this is (either) firewall related (or) related to Plesk's particular way of including the Atomicorp ModSec ruleset.

In short, you can exclude the firewall issues by resolving them and if the issue still persist, just wait until Plesk Team addresses the (potential) issue.

In the meantime, just ignore the error notifications, if and only if a check with the command aum -ck indicates that your Atomicorp rulesets are up-to-date.


Hope the above helps a bit ...... and explains a bit........

Regards.........

 

[GerdSchrewe]

Thank you very much for this very useful hints!!!

 

[trialotto]

@GerdSchrewe, @onki, @Wikibear and @papak,

I have had a look into the specific root cause of the problem "exit code 127" and this root cause simply is the (daily) cronjob not finding the /var/asl/bin/asl command.

SOLUTION: quite simple, just add some (file existence) checks in the /etc/cron.daily/asl file.

NOTE: the /etc/cron.daily/asl is provided with the aum package, which should be of version 5.0-0.5 on various Plesk versions.

NOTE: I did not test the adjustment thoroughly, but it should be sufficient to

1 - backup /etc/cron.daily/asl to a random directory outside /etc/cron.daily, by using the command: cp -p /etc/cron.daily/asl /<directory>/<name of the backup>
2 - change the contents of /etc/cron.daily/asl to (additions are marked in bold)

#!/bin/bash

# Adjusted ASL cronjob

source "/etc/asl/config"
export LANG="en_US.UTF-8"
WAIT=$(echo $RANDOM | cut -c1-3)


if [ "$CONFIGURED" == "yes" ]; then
# determine actual retention in days to use
RET_DAYS=$HIDS_CLEAN_DIFF
RET_DAYS_MODSEC=$MODSEC_CLEAN_ALERT
if [ "$RETENTION_USE_CONSOLIDATED" == "yes" ]; then
arr=($RETENTION_CONSOLIDATED)
s_value=${arr[0]}
s_period=${arr[1]}

if [ "$s_period" == "month" ] || [ "$s_period" == "months" ]; then
RET_DAYS=$((s_value * 30))
RET_DAYS_MODSEC=$RET_DAYS
elif [ "$s_period" == "year" ] || [ "$s_period" == "years" ]; then
RET_DAYS=$((s_value * 365))
RET_DAYS_MODSEC=$RET_DAYS
elif [ "$s_period" == "day" ] || [ "$s_period" == "days" ]; then
RET_DAYS=$s_value
RET_DAYS_MODSEC=$RET_DAYS
fi
fi

# Automatic Updates
if [ "$AUTOMATIC_UPDATES" == "daily" ]; then
sleep $WAIT
/var/asl/bin/aum -u >/dev/null 2>&1
fi

# Clear old alerts
#if [ $MODSEC_CLEAN_ALERT -gt 0 ]; then
if [ $RET_DAYS_MODSEC -gt 0 ]; then
/usr/bin/find /var/asl/data/audit/ -maxdepth 2 \
-type d -ctime +$RET_DAYS_MODSEC -exec /bin/rm -rf {} \; >/dev/null 2>&1
fi

# Clean old updates
/usr/bin/find /var/asl/updates -maxdepth 1 \
-type f -ctime +7 -exec /bin/rm -f {} \; >/dev/null 2>&1

# Clean old state files
if [ -d /var/ossec/queue/diff ]; then
/usr/bin/find /var/ossec/queue/diff/*/533 -maxdepth 1 -type f -ctime +1 -exec /bin/rm -f {} \; >/dev/null 2>&1
#/usr/bin/find /var/ossec/queue/diff/* -name state* -type f -ctime +$HIDS_CLEAN_DIFF -exec /bin/rm -f {} \; >/dev/null 2>&1
/usr/bin/find /var/ossec/queue/diff/* -name state* -type f -ctime +$RET_DAYS -exec /bin/rm -f {} \; >/dev/null 2>&1
#/usr/bin/find /var/ossec/queue/diff/* -name diff* -type f -ctime +$HIDS_CLEAN_DIFF -exec /bin/rm -f {} \; >/dev/null 2>&1
/usr/bin/find /var/ossec/queue/diff/* -name diff* -type f -ctime +$RET_DAYS -exec /bin/rm -f {} \; >/dev/null 2>&1
fi

# Clean > RETENTION_MAX_RBC_COUNT
# Adjusted
if [ -f /var/asl/bin/asl ]; then
/var/asl/bin/asl --rbc_clean >/dev/null 2>&1
fi

# Clean old rbc files
if [ -d /var/asl/rbc ]; then
/usr/bin/find /var/asl/rbc/* -type f -ctime +$RET_DAYS -exec /bin/rm -f {} \; >/dev/null 2>&1
fi



# Clean old malware scan reports
#/usr/bin/find /var/asl/reports -name *.log type f -ctime +$HIDS_CLEAN_DIFF -exec /bin/rm -f {} \; >/dev/null 2>&1
/usr/bin/find /var/asl/reports -name *.log type f -ctime +$RET_DAYS -exec /bin/rm -f {} \; >/dev/null 2>&1

# Run DB rotate script
if [ -f /var/asl/bin/asl_db_rotate ]; then
/var/asl/bin/asl_db_rotate >/dev/null 2>&1
fi


# Purge Logs
if [[ "$PURGE_LOGS" != "no" ]] && [[ "$PURGE_LOGS" != "-1" ]]; then
DAYS=$PURGE_LOGS
# Alerts
/usr/bin/find /var/ossec/logs/alerts/ -name \*gz -type f -ctime +$DAYS -exec /bin/rm -f {} \;
/usr/bin/find /var/ossec/logs/alerts/ -name \*sum -type f -ctime +$DAYS -exec /bin/rm -f {} \;

# Archives
/usr/bin/find /var/ossec/logs/archives/ -name \*gz -type f -ctime +$DAYS -exec /bin/rm -f {} \;
/usr/bin/find /var/ossec/logs/archives/ -name \*sum -type f -ctime +$DAYS -exec /bin/rm -f {} \;
fi


# Run rep report
# Adjusted
if [ "$REPUTATION_REPORT" == "yes" ]; then
if [ "$REPUTATION_FREQUENCY" == "daily" ] && [ -f /var/asl/bin/asl ]; then
/var/asl/bin/asl --rep_report >/dev/null 2>&1
fi
fi

# Run ASL housekeeping
# Adjusted
if [ -f /var/asl/bin/asl ]; then
/var/asl/bin/asl --housekeeping >/dev/null 2>&1
fi

else
echo "Error: ASL has not been configured"
exit 1
fi

 

[GerdSchrewe]

Thank you very much. It works for me!!!

 

[Thomas K.]

Hi, every day i receive the message: run-parts: /etc/cron.daily/asl exited with return code 126 and the command aum -c returns

/var/asl/lib/modules/configuration_setup.sh: /var/asl/bin/asl: /var/asl/usr/bin/php: bad interpreter: No such file or directory

Can someone help please.