Resolved Suddenly getting ASL errors today

[PSi_101]

You're right. Sometimes I am living in the past (good old times) ;-)

I'm just glad that even though it's not technically Plesk's problem, they're helping to do something about it.

 

[Raymond_Davelaar]

Same problem here.
/etc/cron.hourly/asl:
Error: ASL has not been configured
run-parts: /etc/cron.hourly/asl exited with return code 1

 

[msch]

I'm just glad that even though it's not technically Plesk's problem, they're helping to do something about it.

hmmm. The problem arose after plesks latest micro update. So for me they have a responsibility to fix the problem ;-)

 

[Xantiva]

Hi, thank you but i can't abo that Article "Abonnement wird erstellt: ArticleID -Parameter angeben" its a Error.... Tried it 6 times and now i'm annoyed.

Same problem here! The english message is: "Subscription creating: Specify ArticleID parameter" but there is no field for the ArticleID ?

 

[ArtZ]

I am having the same issue with one of our Plesk 12.5 / Ubuntu 14.04 machines. The file /etc/asl/config is 1 byte long. I restored the whole /etc/asl directory from backups.

-- Art Z.

 

[Made2Com]

Same problem here since last plesk micro update... :/

/etc/cron.hourly/asl:

Error: ASL has not been configured

run-parts: /etc/cron.hourly/asl exited with return code 1

 

[trialotto]

Hi everyone, please subscribe for the updates to this KB article https://kb.plesk.com/en/129494 as soon as Atomic provide the fix, we'll update it and you will be notified.

This KB article is a work-around, as opposed to the final solution Plesk customers should have.

In essence, the errors with respect to ASL are a blessing, they indicate many other problems, being (amongst others)

A - big issues with directories and commands

On deb based systems, like Ubuntu, any file or directory location containing the string "httpd" should actually be "apache2".

The same or something similar applies to commands.

Both issues are not really a "bug" (in the true sense of the word), but the result of a remarkably strange setup (let´s put it mildly, shall we?).

The problems:

- commands are not executed properly AND the wrong or a non-existing script (or binary) is called for,
- proper commands are not executed properly due to the reference to incorrect file or directory paths,

Moreover, in the (remarkably strange) setup, some of these issues have been resolved by creating symlinks.

However, even though these symlinks resolve the issues for ASL partially, the same symlinks can cause problems for other programs, binaries or scripts.

Some of the issues with the (remarkably strange) setup of ASL have been "solved" by native Plesk "wrappers", such as modsecurity_ctl.

In general, it is a big mess and it is not clear at all how the whole ASL setup affects the proper functioning of the entire system.

In summary, I would rather have a clean install and setup of ASL (read: the aum package), since the current setup does not make any sense at all, given

- the many errors,
- a lot of code that refers to httpd and should hence be deemed obsolete for deb based OSes,
- double directories (like "/etc/httpd/modsecurity.d" and "/etc/apache2/modsecurity.d") containing essentially exactly the same or roughly identical content,
- the danger of specific symlinks that actually should not be there

and so on.

It even seems to be the case that ASL (read: the aum package) is "accidentally" (what is in a word?) installed AND should be removed entirely.

I will return to the latter in the next section(s).

B - a (likely) bug in aum causing the /etc/asl/config to be empty, under circumstances that cannot be replicated if the /etc/asl/config was not empty.

Note that

- the commands aum -u and aum -c will not work if /etc/asl/config is empty
- the command aum -c will create a backup file called /etc/asl/config.bak
- the command aum -c does NOT use the file /var/asl/data/templates/config.template for creation of the config file
- the command aum -ck is EXECUTED every hour
- the error notifications are the result of cronjobs, which differ hugely by nature
- the cronjobs (read: commands in those cronjobs) can cause tcprcvbuf related issues on VPSes

implying that

1) one SHOULD NOT EDIT the /etc/asl/config file directly, since that will result in the current issues returning (for many reasons)

2) the /var/asl/data/templates/config.template, normally being the only place to edit the "configuration" ending up in /etc/asl/config, is barely relevant,

whereas a bug free aum package should not exhibit the above mentioned behaviour.

It seems to be the case that the cronjobs can be simply altered OR even deleted, to suppress all annoying error notifications,

Again, note the existence of modsecurity_ctl, that solves issues with the (strange) setup of ASL.

I will proceed with that in the next section.

C - ASL and modsecurity_ctl

ASL (Atomic Secured Linux) is associated with the aum package, which package installs a lot of files and directories with the name "asl".

However, not all files and directories are installed with the aum package provided with Plesk, resulting in error notifications when running the cronjobs.

Note that the cronjobs themselves are part of the aum package (and were not present on the OS, before the MU43 update).

Modsecurity_ctl is the Plesk (command line9 tool that allows to operate with the Web Application Firewall (WAF) and, for instance, activate specific rulesets.

In the Plesk Panel, similar functions are present under "Tools & Settings > Web application firewall", but modsecurity_ctl is somewhat different in terms of functionality.

The major (in this case relevant) function is that modsecurity_ctl organises ASL related layout.

The (internal) function fix_atomic_modsec_layout is of particular interest: without that, a properly configured ASL would not allow you to restart Apache. Bump!

I am really curious about the whole construction, since it seems to be complete madness.

However, as I have indicated before, it seems to be the case that the aum package is "accidentally" installed AND should be removed entirely.

It certainly resolves the issues with the annoyance caused by the cronjobs and/or potential bugs in the aum package itself.

D - TEMPORARY SOLUTION

I did some testing and simply removed all files installed by the aum package manually.

It works fine, but I will give some instructions:

a) remove the files:

- /etc/cron.monthly/asl
- /etc/cron.daily/asl
- /etc/cron.weekly/asl
- /etc/cron.hourly/asl
- /usr/bin/aum (a symlink)

b) remove the directories (please go to the parent directory and use rm -r to remove the asl related directory):

- /etc/asl
- /var/asl
- /usr/share/doc/aum

c) check status of modsecurity, run the command: /opt/psa/admin/sbin/modsecurity_ctl --status (adjust the path appropriately for rpm based OSes)

d) enable modsecurity (if necessary), run the command: /opt/psa/admin/sbin/modsecurity_ctl --enable (adjust the path appropriately for rpm based OSes)

e) restart apache: service apache2 restart (or /etc/init.d/apache2 start; change "apache2" to "httpd" if you are on a rpm based system)

f) double check settings, run the command: plesk bin server_pref --show-web-app-firewall

g) check the proper functioning of modsecurity, follow the steps (in chronological order)

- run the command: cd /var/log
- run the command: vi modse* (just shows the modsec_audit.log)
- run the command (from SSH): wget http://<domain on the server>/foo.php?foo=http://www.example.com (or just past the http URL in a browser)
- run the command: vi modse*

and verify that the wget command has resulted in some additional log lines.

That is all.

E - Summary

Removing the files associated with the aum package will

- prevent all types of annoying error notifications,
- ascertain that your modsecurity works properly,
- ascertain that the modsecurity_ctl tool can be used properly (without any problems),

and, in essence, it should be safe to remove the aum package completely.

I am not yet confident about the provided solution (see section D), given the obscurity of the relations between ASL rulesets, updates of those rulesets and modsecurity_ctl.

It can be a permanent solution, if somebody from Plesk Team can confirm that the rulesets will be updated on the indicate schedule (daily, weekly or monthly).

At this moment, the solution will resolve all or most of the isses with the error notifications.

Please provide some feedback, if you encounter issues (or even typo´s, grinn)


Regards!

 

[trialotto]

@Everyone, @NatalyaF,

This night (13 august 2016), the aum version 4.0.19-38 has been bumped to version 4.0.19-39.

A number of improvements are visible, but some issues (like the exit code 127 error notification) are still present.

Please report your findings, so I can investigate further.

Again, I have to emphasize that the real issue are not the "exit code error notifications", it seems to be the case that modsecurity_ctl and aum do not play nicely together.

Note that the idea behind "the manual removal of files related to the aum package" (see section D of my last post) is that any upgrade would still be installed.

In essence, the new version 4.0.19-39 is installed, even if you removed all asl related files and directories.

Also note that with version 4.0.19-39

- the commands aum -c and aum -ck do not result in any problem
- the command aum -u will cause problems: the file /etc/apache2/conf-enabled/00_mod_security.conf is created and contains content
- the modsecurity_ctl is the "tool" that should clean /etc/apache2/conf-enabled/00_mod_security.conf, but it does not when running aum -u
- Apache restarts are executed in many scenario´s, but Apache will not start if /etc/apache2/conf-enabled/00_mod_security.conf contains content

implying that one has to remove /etc/apache2/conf-enabled/00_mod_security.conf, as soon as the command aum -u is being executed.

Really? Yes, really. And that is a problem, given the cronjobs and the contents thereof.

The issue with the 00_mod_security.conf file still has to be fixed by Plesk Team or Atomicorp.

Nevertheless, it seems to be the case that we can rely on a simple solution: changing the cronjobs.

I will post some additional comments or solutions later. Time for some sleep.

Regards...

PS All of the above has been tested with the case of the (temporary) solution (see section D of my last post) and a "apt-get purge aum / apt-get install aum" sequence.

PS2 The odd thing is that on another test machine, where the new aum version has been installed over the old version (without having applied the solution from section D), the issue with the /etc/apache2/conf-enabled/00_mod_security.conf does not exist, suggesting that (on the one hand) only manual execution of the command aum -u will cause a problem (this can be discarded, very very likely not the case) and (on the other hand) that the contents of the /etc/apache2/conf-enabled/00_mod_security.conf file are sufficient enough to prevent that the contents of that file are changed when running the aum -u command. Not sure what happens on that (other) test machine.

 

[daanse]

I have no Problems, since i mentioned that Workarround is working.
(Or no Emails anymore, not visible Errors ;-) )
Thank you @NatalyaF

 

[Xantiva]

Hi,
I restored the /etc/asl/config yesterday and got "only" the exit code 127. This night the new version 4.0.19-39 was installed, but I still got the error mails every hour.

 

[trialotto]

I have no Problems, since i mentioned that Workarround is working.
(Or no Emails anymore, not visible Errors ;-) )
Thank you @NatalyaF

@daanse,

You can encounter problems when ASL is updating according to the schedule: I can safely assume that you have set a weekly or monthly update schedule in Plesk Panel.

It is recommended to go to "Tools & Settings > Web application firewall" and change the settings to test which issues will occur (note: easiest way is to select "daily").

Regards...

 

[Made2Com]

I do not made any change but since midnight the message had changed

run-parts: /etc/cron.hourly/asl exited with return code 127

 

[trialotto]

@Made2Com

You should set the key-value pair REPUTATION_REPORT="yes" (line 65 in /etc/asl/config) to REPUTATION_REPORT="no", that should be sufficient.

Regards....

 

[Made2Com]

You should set the key-value pair REPUTATION_REPORT="yes" (line 65 in /etc/asl/config) to REPUTATION_REPORT="no"

is the best solution for :

run-parts: /etc/cron.hourly/asl exited with return code 127

Thanks @trialotto for your solution, I read about this solution in the last messages, but was worried about to use it because I didn't know what I was doing... and I like to understand what I'm doing !

So I took the time to understand clearly the problem, and understood that it's clearly a plesk/atomic compat issue and I'm not a plesk nor an atomic developer! So I cut off the reports like you told, which solve the issue, wisely waiting for a solution from Plesk and Atomic teams to switch on the ASL reputation reports again...

Many thanks

 

[msch]

I can confirm that changing line 65 in /etc/asl/config to REPUTATION_REPORT="no" fixes the annoying cron error 127 but this is not a solution of the main problem. I hope Plesk and/or Atomic will provide a fix soon to make the ASL report working again.

P.S: thanks @trialotto for Your solution - looks good for me - but I will wait for further updates from plesk/Atomic.

 

[NatalyaF]

Hi everyone, we are now testing the solution from Atomic. Stay tuned!

 

[alexonb]

Hi everyone, we are now testing the solution from Atomic. Stay tuned!

ok me too have this error same

I do not made any change but since midnight the message had changed

run-parts: /etc/cron.hourly/asl exited with return code 127

not changed resolution awaitting for

 

[NatalyaF]

We updated KB article https://kb.plesk.com/en/129494 with the solution from Atomic. Please use it to fix the issue.

 

[TorbHo]

We updated KB article https://kb.plesk.com/en/129494 with the solution from Atomic. Please use it to fix the issue.

Website/Knowledgebase not reachable

 

[UFHH01]

Website/Knowledgebase not reachable

hm... I can reach it

Article ID: 129494, created on Aug 11, 2016, last review on Aug 16, 2016