Resolved Suddenly getting ASL errors today

[NatalyaF]

Hi @TorbenH , we did not have any issues with the KB and the web site. Was the issue resolved? I can copy the solution here if you still experiencing the issue.

 

[TorbHo]

hm... I can reach it

Now it is reachable again. Thank you.

 

[Pandur2000]

The KB (which now just says update aum) doesn't fix the cron error message

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

with aum 4.0.19-40 on Debian.

 

[msch]

seems to work on Ubuntu 14.04.1 LTS‬

 

[Maximilian Grimm]

This Solution does not work if there is a mod_security installation problem like this:

Installation started in background
Auflösung der Paketabhängigkeiten wird geprüft.
Pakete werden installiert
Reading package lists...
Building dependency tree...
Reading state information...
plesk-modsecurity-configurator is already the newest version.
plesk-modsecurity-crs is already the newest version.
The following package was automatically installed and is no longer required:
libapache2-mod-security2
Use 'apt-get autoremove' to remove it.
The following NEW packages will be installed:
libapache2-modsecurity
0 upgraded, 1 newly installed, 0 to remove and 7 not upgraded.
2 not fully installed or removed.
Need to get 0 B/260 kB of archives.
After this operation, 1194 kB of additional disk space will be used.
(Reading database ... 225748 files and directories currently installed.)
Preparing to unpack .../libapache2-modsecurity_2.9.0-ubuntu14.04.15081914_amd64.deb ...
Unpacking libapache2-modsecurity (2.9.0-ubuntu14.04.15081914) ...
dpkg: error processing archive /var/cache/apt/archives/libapache2-modsecurity_2.9.0-ubuntu14.04.15081914_amd64.deb (--unpack):
trying to overwrite '/etc/apache2/mods-available/security2.conf', which is also in package libapache2-mod-security2 2.7.7-2
dpkg-deb (subprocess): decompressing archive member: lzma write error: Broken pipe
dpkg-deb: error: subprocess <decompress> returned error exit status 2
dpkg-deb (subprocess): cannot copy archive member from '/var/cache/apt/archives/libapache2-modsecurity_2.9.0-ubuntu14.04.15081914_amd64.deb' to decompressor pipe: failed to write (Broken pipe)
Errors were encountered while processing:
/var/cache/apt/archives/libapache2-modsecurity_2.9.0-ubuntu14.04.15081914_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
Error: Ein Fehler ist aufgetreten bei dem Versuch, Pakete zu installieren.
Achtung! Ihre Software ist vielleicht nicht betriebsbereit.
Bitte kontaktieren Sie den technischen Produktsupport.

 

[Grey]

Work for me at least with Debian 7.11 32bit with Plesk 12.0.18. After update aum is version 4.0.19-40.

I would however update the KB article with just upgrading aum with apt-get install --only-upgrade aum or at least list that option first. No reason to do a upgrade on the rest of the packages, that's for the sysadmin to decide.

 

[dvries]

The KB (which now just says update aum) doesn't fix the cron error message

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

with aum 4.0.19-40 on Debian.

We have also this error message after the update.

Server information:

Debian 8.5
Plesk v12.5.30
aum 4.0.19-40

How can we fix this problem?

 

[trialotto]

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

@NatalyaF

I emphasize that there should be some clarity about what the update exactly changes.

Can you provide a list of changes in aum version 4.0.19-40?

After all, note that

a) aum version 4.0.19-40 is installed overnight,

b) the files in the aum package (version 4.0.19-40) still seem to be equivalent or identical to previous packages, including the cronjob files (calling the not installed binary "asl"),

c) the /etc/asl/config file in the aum package (version 4.0.19-40) still contains the key-value pairs

- APACHE_RESTART_COMMAND="/etc/init.d/httpd restart"
- REPUTATION_REPORT="yes"

by default, suggesting that the upgrade to aum package version 4.0.19-40 is NOT a clean install, but essentially the overwriting of some files.

The overwriting of some files will cause and/or is very likely to cause existing problems to persist.

ALSO NOTE that changes made to the /etc/asl/config file (for instance, on the base of the previous version of KB129494) will NOT BE CHANGED by upgrading!!!

In short, the problem is not yet resolved, the current upgrade is just a messy work-around that probably does not resolve the root cause of the problem.

Please provide some clarification.

Regards....

PS I did tests on three development machines and I will give you some additional information, if you ask me via a PM.

 

[trialotto]

We have also this error message after the update.

Server information:

Debian 8.5
Plesk v12.5.30
aum 4.0.19-40

How can we fix this problem?

@dvries

I am not exactly sure, but I am sure enough to propose that you should set the key-value pair

REPUTATION_REPORT="no"

in the /etc/asl/config file.

If you already have this setting, just let me know, so I can investigate.

Regards....

 

[Edi Duluman]

After upgrading the aum package, I still have the error going on.

/etc/cron.hourly/asl:
run-parts: failed to exec /etc/cron.hourly/asl: Exec format error
run-parts: /etc/cron.hourly/asl exited with return code 1

 

[trialotto]

After upgrading the aum package, I still have the error going on.

/etc/cron.hourly/asl:
run-parts: failed to exec /etc/cron.hourly/asl: Exec format error
run-parts: /etc/cron.hourly/asl exited with return code 1

@Edi Duluman

You should also set REPUTATION_REPORT="no" in the /etc/asl/config file.

Also make sure that APACHE_RESTART_COMMAND="/etc/init.d/apache2 restart" (if you are on a deb based machine, like Ubuntu).

Regards.....

 

[Edi Duluman]

@Edi Duluman

You should also set REPUTATION_REPORT="no" in the /etc/asl/config file.

Also make sure that APACHE_RESTART_COMMAND="/etc/init.d/apache2 restart" (if you are on a Debian based machine, like Ubuntu).

Regards.....

Sorry, I'm running Plesk 12.5 on Debian 8, and I don't have any /etc/asl folder.

 

[dvries]

@trialotto ,

No, we have REPUTATION_REPORT = "yes". But he is now changed to 'NO'.
I will let you know if the error message is gone.

 

[Bulat]

@Pandur2000 , @dvries ,

Most likely, you have copied `/var/asl/bin/asl_cli_c` to `/var/asl/bin/asl` or created such kind of symlink. If this is the case, please get rid of `/var/asl/bin/asl` file/link as this file is not supposed to be present on Debian/Ubuntu systems.

As for APACHE_RESTART_COMMAND="/etc/init.d/apache2 restart" directive, as it was confirmed by Atomic representatives this directive is not used on Plesk servers. Therefore, it does not affect apache functionality.

 

[Pandur2000]

Most likely, you have copied `/var/asl/bin/asl_cli_c` to `/var/asl/bin/asl` or created such kind of symlink. If this is the case, please get rid of `/var/asl/bin/asl` file/link as this file is not supposed to be present on Debian/Ubuntu systems.

Nope. Did no such thing.
Using the content of the config(backup?) that was located at /var/asl/rbc/etc/asl/config with APACHE_RESTART_COMMAND and REPUTATION_REPORT adjusted to apache2 Debian / "no".

 

[trialotto]

@Pandur2000

This

Using the content of the config(backup?) that was located at /var/asl/rbc/etc/asl/config with APACHE_RESTART_COMMAND and REPUTATION_REPORT adjusted to apache2 Debian / "no".

will or should work.

Another option is available, but if using the (old) config file with REPUTATION_REPORT="no" works, just use that (it is the most convenient "work-around").

Regards...

 

[trialotto]

@Bulat,

Some remarks with respect to your (remarkable) post:

a) you state

Most likely, you have copied `/var/asl/bin/asl_cli_c` to `/var/asl/bin/asl` or created such kind of symlink. If this is the case, please get rid of `/var/asl/bin/asl` file/link as this file is not supposed to be present on Debian/Ubuntu systems.

and the REALITY is completely different:

- the "asl binary" is associated with the FULL Atomic Secured Linux package, but is not shipped with Plesk, since Plesk uses the "rule set only" approach, (and)
- the call of "/var/asl/bin/asl" should not be in the cronjob files, at least on Plesk instances it should not be present, (and)
- all cronjob files should not be present on Plesk instances.

The above is somewhat different than the confusing information you are giving.

As for APACHE_RESTART_COMMAND="/etc/init.d/apache2 restart" directive, as it was confirmed by Atomic representatives this directive is not used on Plesk servers. Therefore, it does not affect apache functionality.

Ehm, I am pretty sure (but not certain) that this is incorrect.

If I am not mistaken, the following applies.

In the cronjobs, there is the call to the command "aum -u" (depending on the configuration, the call is on a hourly, daily, weekly or monthly basis).

The command "aum -u" does use the Apache2 restart command, if the (tortix) rule set is not current.

Otherwise, the command "aum -u" will simply "pass" and do nothing.

A call of the modsecurity_ctl tool will take care of a daily, weekly or monthly update of the (tortix) rule set, implying that in most cases the command "aum -u" will simply "pass".

The above still does not imply that the aum package and the modsecurity_ctl work fine together and it certainly does not imply that Apache will not be restarted.

It simply implies that Apache will not or does not have to restart in 99,99% of the cases.

Anyway, I already asked clarity and again I am asking for a proper explanation by Plesk Team.

One of the reasons for this request is that it can occur that Apache will not restart in specific cases that the command "aum -u" has been run.

Regards.....

 

[trialotto]

@Bulat, @NatalyaF,

I am asking again: can anyone from the developers contact me, in order to allow me to present you with STR (steps-to-reproduce), so you can debug the issue?

Regards.......

 

[dvries]

@dvries

I am not exactly sure, but I am sure enough to propose that you should set the key-value pair

REPUTATION_REPORT="no"

in the /etc/asl/config file.

If you already have this setting, just let me know, so I can investigate.

Regards....

After the adjustment of REPUTATION_REPORT = "no", the error is gone!
and we get no more emails about the cronjob.

@Pandur2000,
The tip of trialotto helped me. And for you?

 

[Pandur2000]

I removed the config, removed aum, reinstalled it, copied the config file from /var/asl/rbc/etc/asl/config , now the crons are not generating error reports with
REPUTATION_REPORT="no"
APACHE_RESTART_COMMAND="/etc/init.d/apache2 restart"
on Debian.