Search results

Hello, Amir. Kindly refer to the following thread for an explanation of the issue and the workaround: Issue - Plesk Migrator failed to perform action with cfreateDump.pl

Everyone, I just want to follow up on the matter with the missing notifications option in the new Imunify extension. CloudLinux and our team are still working on implementing this functionality, the ETA is mid July.

Hello, @Medina . Could you please confirm that the changes you applied were saved? When you go to your Plesk DNS zone, there is typically a notice at the top of the page if the changes were not applied:

Thank you for the update. The initially reported error with 105 error code was reviewed by our engineers and it was determined it is due to connectivity issue with Dr.Web's update servers. Regarding the last reported errors with code 109, the root cause is also usually due to connectivity...

Our engineers were also unable to reproduce the issue. If you can open a ticket so that can be checked directly on the machine it will be great. The reference id of the internal case is PPS-17982.

@trialotto can you please confirm what are the exact errors you encounter when running the /etc/cron.daily/drweb-update and /opt/drweb/update.pl? I am unable to replicate the behavior on a test environment.

@trialotto , I am not quite sure I was able to understand the question. Sorry. Are you asking in reference to the automatic MariaDB Upgrade tool? If yes, can you please confirm which custom config files are you referring to?

@trialotto Thank you for your feedback about the extension. I will share it with our team. Regarding the issue with the extension removal, if there are any leftover files they could be removed as follow: rm -rf /opt/ai-bolit rm -rf /opt/i360_pam_imunify/ rm -rf /opt/imunify360 rf -rf...

@buschmann The error in question doesn't actually affect the repair process. Therefore, it is qualified as a cosmetic bug. The priority of the bugfix is low. It is still in our team's processing queue, but other fixes as prioritized based on their impact.

Hello, @Oldiesmann . This typically occurs due to misconfiguration of the SOGo extension. Could you please execute the following command to repair the config:

Hello, @JuanCar . We have a registered bug for this behavior identified with ID EXTNODEJS-135. Unfortunately, at this point, I cannot suggest a workaround for removing the inactive domains from the list. The issue will be fixed in one of the future releases, but I cannot provide an ETA. You can...

Hello, @chazza . To me, it sounds like the Default Plesk Interface is set as Power User view for the license in Partner Central. If you are a Plesk partner, please check the configuration in your Partner Central: Product Configurations If you purchased the license from a third-party Plesk...

Unfortunately, at this point, there is no way to cover the site preview URL with valid certificate. I will need to check further why you are being prompted to buy the SSL again and how could that behavior be potentially avoided. I will follow up with more details as soon as possible.

If the records are for a second-level domain like example.com (as it looks like from the attached notification), the DS records should be added through the domain registrar, i.e. the provider from which you bought the domain name. If they are for a subdomain of a domain hosted in Plesk and...

Thanks, Peter. I opened a new internal report, so our team can double-check in case I am missing something. If they are also unable to reproduce the error it will be best if you can provide us with access to narrow down the reason.

It is not handled automatically. The keys must be manually updated in the parent zone. If you are unsure where the parent zone is, you can use a tool like DNSViz. If the records are not updated you can experience DNS issues, so I wouldn't recommend ignoring the notification. The full doc...

No, your setup is right. If you want to cover examplesitename1.123-456-78-90.previewdomain.com it should be for 123-456-78-90.previewdomain.com. I believe the new aliases should be automatically covered by the SSL, but since you are asking I am guessing that doesn't happen. What you can try is...

Hello, @GreenhouseTech . Do I correctly understand that the wildcard SSL is installed for *.123-456-78-90.previewdomain.com rather than *.previewdomain.com?

It could be. I tried disabling the functions globally and still no such error: Would you mind testing that on a default WordPress installation?

Thank for the update. The functions are disabled (checked with phpinfo). I deleted some tables and files prior to the restoration, switched the language to German, but still I am unable to reproduce the error. What's the MariaDB/MySQL version you are running?