Search results

Uploaded the gdb output as zip.

TITLE: wp toolkit: 100% CPU when running " -- core info" on a broken wp instance PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE: CentOS Linux release 7.5.1804 (Core) Plesk Onyx Version 17.5.3 Update #51, last updated on June 20, 2018 10:10 PM PROBLEM DESCRIPTION: Looks like one of the bugs...

Run "setenforce Permissive" in a root shell and try again.

Just thought we should add while {WEBSPACEROOT} side steps the problem it also breaks isolation between the various sites in the subscription. So if one of the sites gets hacked they can run code on the others sites in the subscription - not a good security outcome if you ask me... Rename...

@Visnet, what do the server's logs say? Any chance you've got SELinux enabled? What does "getenforce" return?

Yep, that's exactly right, if using {WEBSPACEROOT}{/}{:}{TMP}{/} everything is fine. However the default setting is {DOCROOT}{/}{:}{TMP}{/}

Thanks Igor, but that doesn't sound right. Why do they need access to our servers? I thought I've given a reliable method to reproduce the problem, is there anything I might have missed in my report? Can't the devs replicate the bug themselves?

TITLE: PHP breaks for additional domain if the parent subscription is renamed PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE: CentOS Linux 7.5.1804 (Core)‬ Product Plesk Onyx Version 17.5.3 Update #47, last updated on May 15, 2018 12:42 PM PROBLEM DESCRIPTION: If the subscription is renamed...

Hi, don't want to sound too pushy, but has anyone from Plesk dev looked at this issue lately? Forwarded to devs - php-fpm service unavailable after domain removed from Plesk It's quite serious, when it replicates it takes down all the sites using the affected php-fpm handler. Thanks.

Ok, it's easy to reproduce the bug when restoring from the Plesk backups. Here are the steps: 1. Prerequisites: - Plesk Version 17.5.3 Update #47 on CentOS 7 - Multiple php-fpm handlers installed and already configured for other existing vhosts 2. Create a test subscription, I used adit3.local...

Is it possible that, under *some* circumstances, Plesk creates php-fpm configuration for 2 different handlers and, when deleting the subdomain, it only deletes one of them? These are the action log entries which might have been a factor in the bungle. Coming from 127.0.0.1 I assume they're Plesk...

Any chance the developers can make the fpm process more fault tolerant in event of missing config file vs kill all the sites using that fpm hander. i.e skip or exclude missing files?

Thanks Igor. As I've already mentioned it's random, in fact we've only seen it once and enabling debugging in Plesk is a no-no for production. I'll try to collect more information from the affected server and contact support.

TITLE: php-fpm service unavailable after domain removed from Plesk PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE: Plesk Onyx Version 17.5.3 Update #47, last updated on May 9, 2018 10:27 PM on CentOS 7.4 PROBLEM DESCRIPTION: I see there's already a KB article on this issue: Unable to switch...

Under plesk Components it lists; PPSitebuilder17.0.15-16072217 This is for Plesk Onyx Version 17.5.3 Update #45, last updated on April 10, 2018 10:06 PM Under MU # 45 change log it says; Fixed Captcha in the “Contact Form” module in Web Presence Builder 17.0.16. See the details in the KB...

According to Change Log for Plesk the Captcha code in the contact has been fixed in MU #44 with WPB 17.0.6, however #45 we're running at the moment is still using WPB 17.0.5. I'm really confused! How should I read this information? The client is still unhappy cause their captcha thingie isn't...

Excellent, thanks. Any chance to have it backported to 17.5.3? We're not ready yet to upgrade to 17.8.

Roger that, thanks :)

TITLE: Can't enter DMARC record as CNAME in 17.5.3 PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE: Onyx 17.5.3 Update #38, CentOS 7.4 64bit PROBLEM DESCRIPTION: Trying to test setting up DMARC records for multiple domains using CNAMEs as per: FAQ - DMARC Wiki When trying to add a CNAME record...

I'd also love an answer to this...