Issue ModSecurity/AtomicCorp: Get rid of "N: Skipping acquire of configured file [...] doesn't support architecture 'i386'" (apt update)

[King555]

Server operating system version

Ubuntu 18.04.6 LTS x64

Plesk version and microupdate number

Plesk Obsidian 18.0.x web admin edition (latest)

Whenever I run apt update, I get this notice:

N: Skipping acquire of configured file 'main/binary-i386/Packages' as repository 'https://updates.atomicorp.com/channels/tortix-common/debian bionic InRelease' doesn't
support architecture 'i386'

I know it's no error message and it can be ignored, but it's not "nice". So I tried to edit /etc/apt/sources.list.d/tortix-common.list and change

deb https://updates.atomicorp.com/channels/tortix-common/debian bionic main

to

deb [arch=amd64] https://updates.atomicorp.com/channels/tortix-common/debian bionic main

The only problem is that this file is overwritten by Plesk every morning at 06:33 and my editing is gone. Is there any other solution to fix this notice?

 

[Peter Debik]

i-386 sounds like 32-bit, but Plesk officially only supports the 64 bit version of operating systems. How did the 32-bit package come into place originally?

 

[King555]

I guess Plesk does/did this, I don't know why. I just enabled ModSecurity with the AtomicCorp (basic) ruleset within Plesk. Everything works fine, it's only this message which annoys me.

 

[Wolfgang Reidlinger]

After updating to the Plesk version "Plesk Obsidian 18.0.51" I got the following:

N: Skipping acquire of configured file 'all/binary-amd64/Packages' as repository 'http://autoinstall.plesk.com/pool/WPB_18.0.51_64 all InRelease' doesn't support architecture 'amd64'

 

[Wolfgang Reidlinger]

After updating to the Plesk version "Plesk Obsidian 18.0.51" I got the following:

N: Skipping acquire of configured file 'all/binary-amd64/Packages' as repository 'http://autoinstall.plesk.com/pool/WPB_18.0.51_64 all InRelease' doesn't support architecture 'amd64'

After disabling the following line in the file

/etc/apt/sources.list.d/plesk.list

the error was gone!

#deb [signed-by=/etc/apt/keyrings/plesk.gpg] http://autoinstall.plesk.com/pool/WPB_18.0.51_64/  all all

 

[learning_curve]

#deb [signed-by=/etc/apt/keyrings/plesk.gpg] Index of /pool/WPB_18.0.51_64 all all

Indeed. This ^ line, that relates back to a now superseded, previous Plesk Obsidian release, still causes this issue and has to be negated after each and every new Plesk release (either a Point release within the same Obsidian release or the next Obsidian release.) Can this be resolved by Plesk? @Peter Debik

Edit: Even for Non-AtomicCorp Users

 

[Peter Debik]

The keys issue has been worked on for a while already and as far as I know developers finally found out, how it came into existence. I am not sure if there is an ETA for a final fix yet, but probably many other key related issues such as the one @learning_curve describes will be fixed along with it.

 

[DracoBlue]

I have this error
How to solve it? UBUNTU 22.04

 

[DracoBlue]

@Peter Debik

 

[Peter Debik]

@DracoBlue As a workaround, add amd64 and arm64 architectures to WPB repository configuration, but only works for Plesk 18.0.54 (published soon).
Fixes only for the latest WPB_18.0.54 repo. Older repositories (18.0.51, 18.0.53) still generate the message. It is a known issue, but as far as I understood it from documentation it is no blocker and won't hurt the installation.

 

[DracoBlue]

I use 18.0.53. Waiting for 18.0.54

 

[King555]

Was there any change concerning my original problem (see first post) today or yesterday? Because now I get this error:

W: Conflicting distribution: https://updates.atomicorp.com/channels/tortix-common/ubuntu bionic/amd64/ InRelease (expected bionic/amd64/ but got )

The file /etc/apt/sources.list.d/tortix-common.list has changed today at 6:40 am, my web server is down due to problems with AtomicCorp since at least 6:42 am.

 

[King555]

(Sorry, the short edit time already expired)

OK, it should be "ubuntu/bionic" instead of "ubuntu bionic". But why does Plesk now inserts this mistake? Or is it ModSecurity itself?

 

[Peter Debik]

The Atomic ruleset is maintained by Atomic. Yet Plesk and Atomic are working together to improve the user experience in this case.

 

[King555]

I just found this article, which describes the error message I get when starting Apache:

https://support.plesk.com/hc/en-us/articles/14801826549527-Apache-fails-to-start-on-a-Plesk-server-ModSecurity-failed-to-load-IPs-from-etc-asl-whitelist-Could-not-open-ipmatch-file-etc-asl-whitelist-No-such-file-or-directory

Looks like the "aum" program from AtomicCorp "destroyed" my /etc/apt/sources.list.d/tortix-common.list.

I disabled ModSecurity now. Maybe Atomic will release a fix.

 

[trialotto]

@King555

I have done some research on this and other "aum related" issues.

The issue with respect to apt update can be solved in the following way.

The major part of the solution is adding "ARCH=AMD64", but I have also added some explanation and an additional step to add an Apt Keyring.


CAUSES

1 - double entries are likely to be present :

1.1 - in /etc/apt/sources.list, comment out if the following line is present :
#deb Atomicorp bionic main

1.2 - in /etc/apt/sources.list.d/tortix-common.list, comment out the following line :
deb [trusted=yes] Atomicorp bionic/amd64/

SOLUTION

2 - create a new .list file, in this example "atomic-common.list"

2.1 - create a new Apt Keyring, run command :
curl -fsSL https://updates.atomicorp.com/channels/tortix-common/RPM-GPG-KEY.atomicorp.txt | gpg --dearmor -o /etc/apt/keyrings/tortix-common.gpg

2.2 - create the new .list file in /etc/apt/sources.list.d/, run the command :
echo "deb [arch=amd64 signed-by=/etc/apt/keyrings/tortix-common.gpg] Atomicorp bionic main" | tee /etc/apt/sources.list.d/atomic-common.list > /dev/null

2.3 - verify by running the command : apt-get update
There should be no errors mentioned

2.4 - if you want to double check, change the /etc/apt/sources.list.d/atomic-common.list to

deb [arch=amd64 signed-by=/etc/apt/keyrings/tortix-common.gpg] Atomicorp bionic main

and run the command apt-get update, you should see :

Get:16 Atomicorp bionic InRelease [1,799 B]
Get:17 Atomicorp bionic/main amd64 Packages [2,043 B]

2.5 - change the value "debian" or "ubuntu" as you wish, they should yield the same result.


IMPORTANT NOTE
Running aum update (aum -uf) will change the /etc/apt/sources.list.d/tortix-common.list again, but you can safely ignore the warnings now, since you should have a good sources file that allows updating.


I hope the above helps!

Kind regards....

 

[trialotto]

i-386 sounds like 32-bit, but Plesk officially only supports the 64 bit version of operating systems. How did the 32-bit package come into place originally?

@Peter Debik

It can be safely assumed that it is the endresult of an orphan entry in /etc/apt/sources.list ...... see my post.

In essence, the tortix-common.list file will only yield errors, while the entry in sources.list does not use the "arch=amd64" restriction.

Kind regards....

 

[King555]

@trialotto
After creating the .list file with the content you posted, apt update produces this error message:

E: Malformed entry 1 in list file /etc/apt/sources.list.d/atomic-common.list (URI parse)
E: The list of sources could not be read.

The content is: deb [arch=amd64 signed-by=/etc/apt/keyrings/tortix-common.gpg] Atomicorp bionic main

EDIT: Nevermind, your URL in the post was replaced by just "Atomicorp". I had to replace it with the address behind it, of course.

 

[King555]

Unfortunately this does not resolve the current problems with the Atomicorp rulesets. Maybe it will not be fixed for Ubuntu 18, as it's EOL since 1st of May 2023. So I will disable Modsecurity until I upgraded to Ubuntu 20 or 22 (I won't use the Comodo ruleset, as it's too strict for my applications).

But thanks anyway!

 

[trialotto]

Unfortunately this does not resolve the current problems with the Atomicorp rulesets. Maybe it will not be fixed for Ubuntu 18, as it's EOL since 1st of May 2023. So I will disable Modsecurity until I upgraded to Ubuntu 20 or 22 (I won't use the Comodo ruleset, as it's too strict for my applications).

But thanks anyway!

@King555,

The solution provided only is intended to resolve those nasty notifications when running apt-get update or apt-get upgrade.

In essence, it is the intention to make sure that updates are applied correctly.

However, there are a lot of other issues related to Plesk with Atomicorp rulesets ........ most can be easily resolved, but neither Plesk or Atomicorp does that.

Nevertheless, it is HIGHLY RECOMMENDED to ACTIVATE MODSEC.

Just use Comodo rulesets (not really strict at all) or - even better - the OWASP rulesets.

In order to make your applications work, you should have a look at the file /var/log/modsec_audit.log and identify the offending rules.

If you have identified the IDs of the offending rules, then you can add them in Plesk > Tools & Settings > Web Application Firewall > General : rules to ignore.

I hope the above helps a bit!

Kind regards....

PS If you need to disable specific rules, then you should also ask yourself why ....... in most cases, disabling a rule from any ruleset should not be necessary for up-to-date and well-coded programs. Stated differently, if you have to disable a rule, then you should probably consider the alternative : removing or changing the application. After all, it is the (insecure or vulnerable) application that is offending, not the rule from a ruleset.