• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Change all domains to FastCGI and update file permissions

ukc

New Pleskian
Hello,

We have a number of Plesk 12 servers where clients have created a mix of domains that run PHP as FastCGI and Apache. We no longer allow clients to create new domains that run PHP as Apache.

For all the existing domains, we need to convert all domains to run PHP as FastCGI and then we need to update all the file permissions so that we do not run into issues for accounts that have files created/owned by Apache in the vhosts folders.

I *think* i've found a way to do this, but before I run it, I want to find if you think this will work!

Step 1) Change all domains to use FastCGI PHP Handler

# mysql -uadmin -p`cat /etc/psa/.psa.shadow` psa
# UPDATE `hosting` SET php_handler_id = 'fastcgi';
# /usr/local/psa/admin/bin/httpdmng --reconfigure-all

Step 2) Update file permissions for all domains to resolve potential Apache file permission issues

# /usr/local/psa/bin/repair --restore-vhosts-permissions

In your estimation, will this work? It's Step 2 that I am not 100% sure can be used in this way.

Thanks in advance!

UPDATE: Unfortunately Step 2 does not fix the file permissions, only the folder permissions. So I still seek a one-liner that will help fix all the file permissions!
 
Last edited:
Additionally, to find domains that are not using FastCGI as the PHP handler:

# select domains.name,hosting.php_handler_id from domains,hosting where hosting.dom_id=domains.id and hosting.php_handler_id != "fastcgi";
 
What about just:

# for i in `mysql -uadmin -p\`cat /etc/psa/.psa.shadow\` psa -Ns -e "select name from domains"`; do /usr/local/psa/bin/subscription -u $i -php_handler_id fastcgi; done
 
Igor,

That does take care of the PHP handler change on all domains. However, in may case, only 50 domains of 500 actually need to be updated and each change takes a little while as the configuration files are compiled on each iteration - so this would take quite some time, and also unnecessarily update domains that do not need updating.

By focusing on the domains that actually need updating I can minimise the time taken and server load considerably as the "reconfigure all" afterwards takes care of the reconfiguration in a single sweep.

Hope this explains why I am using another method. I'm still trying to find how to correct the apache owned files to the correct owners once domains are converted to fastcgi.
 
You can use your own sql select instead of "select name from domains". I can say only that this is most correct method for achieving what you want.
 
Igor, thank you for the feedback. I have modified the sql query to update only those domains that require it:

# for i in `mysql -uadmin -p\`cat /etc/psa/.psa.shadow\` psa -Ns -e "select domains.name from domains,hosting where hosting.dom_id=domains.id and hosting.php_handler_id != 'fastcgi' order by domains.name;"`; do /usr/local/psa/bin/subscription -u $i -php_handler_id fastcgi; done

As for apache file ownership, I am using a manual method. However, i'm finding that 90% of domains do not have any files owned by apache so it's just a matter of checking each domain after the php_handler_id update to ensure there are no apache files, and where there are, change the ownership and group to match that of the default FTP user of the subscription.
 
While using PLESK 10, fastCGI was a resource hog. However, "run as user" add-on was money well spent.
It allowed me to run apache as a module but with the FTP user's privs..
 
mod_itk and/or mod_ruid2 do only work in conjunction with mod_php, so it does not work with any additional PHP version you'd like to support on your server.
But yeah, FastCGI is a resource hog....
either you let these processes die again very fast, so in total they do not consume that much memory - but then any opCode cacher is virtually useless ---> i.e. it requires more CPU resources
or you configure them to run for quite some time in order to be able to profit from xCache/opCache - but then you need quite a lot of RAM if you're hosting many sites.
 
Back
Top