Resolved API call failed: HTTP Error 500: Internal Server Error

[karam]

@karam

A small tip - it is recommended to allocate a new server and migrate all data to the new server, before doing something on the old (problematic) server.

After all, the site data is or should not be compromised, the Plesk related (server-wide) data probably is.

If you follow this procedure, you will have a fresh Obsidian 18.0.27 instance, which can also function as a backup (of data) and a fail-over (of sites and services).

Please note that you should inspect disk performance on the old (problematic) server, since it is very likely that you will encounter problematic performance - this is another reason for not using regular backup methods : a regular backup process via Plesk will put a heavy burden on your (old) server.

In short, in order to prevent a full breakdown of the old server with complete data loss, I would recommend to migrate data to a new server - as a work-around.

Hope this suggestion helps a bit.

Kind regards........

Got it, thanks for the tip, what I usually do, I re-insert manually the backed up domains, (very small number and won't be large as we are private company)
So I take the user files and database and insert them manually in the new plesk server, I also take every needed information, like emails and dns data.

I never restore a full backup between old and new server. that should be a good practice right ?

 

[trialotto]

@karam

This part

I never restore a full backup between old and new server. that should be a good practice right ?

is correct, to a huge extent.

In essence, what you should do -to make your life more easy- is using Plesk Migrator to migrate subscriptions between the old and new (target) server.

No manual procedures required, full pre-flight check and very convenient to use - but you need SSH access to your server.

Kind regards......

 

[trialotto]

@karam

Plesk Team released Obsidian 18.0.27, micro-update (MU) 1 - that MU1 should solve almost all of your problems.

The biggest problem now is that your old servers are very likely to be flawed to some major or minor extent - it is always good to migrate to new & clean servers.

Kind regards!

 

[karam]

@trialotto Thank you so much for informing me, I'll do a rebuild very soon, thanks again.

 

[trialotto]

Plesk Administrator hourly recieves email messages: dgri-report API call failed: HTTP Error 500: Internal Server Error follow this article to get updates on this issue (it is still under investigation by CloudLinux)

@Arashi, @IgorG,

Problems should -at least in theory- be solved with the Plesk Obsidian 18.0.27 MU1 patch.

I would kindly ask you to make sure that part of the problems solved with the MU1 patch are mentioned in the KB articles and in the forum posts.

In addition, please be aware that the absence of the MU1 patch can imply that Plesk instances can cause severe issues, for instance in the situations that

1 - the sw-cp-server has been shutdown after changing Plesk Firewall rulesets : backups can keep on running and distroy disks or frustrate disk performance,

2 - the sw-cp-server respawn configuration is causing multiple start-ups of sw-cp-server : a lot of running and/or problematic processes can be left sleeping, hence causing a drain on server resources and CPU usage in particular,

3 - the bug with number PPPM-9966 can cause the firewall stop working properly (unless a software reboot is executed) : in some cases, there is a problem with the rulesets as set by Plesk Firewall extension and those present in iptables - this misalignment can cause additional vulnerability and attack surfaces (!),

4 - the combination of the bugs with numbers PPPM-9966 and PPP-49063 can cause (if and only if unpatched) a severe vulnerability : the attack surface increases and attackers attempted to make use of this, at least in my test environments,

5 - there is (probably) still an unpatched BIND vulnerability,

and it should be properly communicated to Plesk users that they should update to Plesk Obsidian 18.0.27 MU1 immediately!

As a final remark, the issue with dgri is a symptom, not a cause or a stand-alone issue - nevertheless, it makes everything a bit more complicated, since there is an actual correlation between the before mentioned bugs and dgri : if kernel patches fail due to issues related to the bugs with the numbers PPPM-9966 and PPP-49063, the whole set of issues just gets combined into a complete mess that can cause production servers to be vulnerable and/or inoperable.

Hope the above helps a bit.

Kind regards............