Installing FastCGI, or working with other PHP handlers

[GoWilkes]

I have a few sites that use MySQL instead of MySQLi, so I have to keep them on PHP 5.6 until they're all updated. But I would like to install HTTP/2 for them.

I understand that HTTP/2 isn't compatible with DSO, which is the default for my PHP 5.6.

I first turned on PHP-FPM, which I thought would override the handler entirely, but my HTTP loadtime skyrocketed! And users complained that the site was constantly timing out on them. That didn't work out at all.

Then tonight I installed mod_fcgid through EasyApache4 and changed the handler for one of the sites. But then the site began prompting to download PHP scripts instead of executing them... and I mean, downloading raw source code!! Luckily I only had that live for a minute at 2am before I changed it back, so hopefully nobody noticed :-O

So now I have a 2-part question:

1. if FastCGI is the right way to go, how do I make it work with WHM/cPanel?

2. if not, what other handler do you recommend that I install?

 

[cPRex]

Hey there!

For issue 1, the most likely explanation is that there were incompatible lines in the account's .htaccess file that kept things from working properly with fcgi. You'd want to check the .htaccess file, or even just move it out of the way completely, to see if that is the issue.

Handlers are really a personal preference. We still recommend suPHP for Wordpress sites or other similar CMS software since that ensures that file ownership and permissions are handled properly. Some admins do play around with the handlers a bit to find one that gives them good speed and usability.

 

[rivermobster]

Hey there!

For issue 1, the most likely explanation is that there were incompatible lines in the account's .htaccess file that kept things from working properly with fcgi. You'd want to check the .htaccess file, or even just move it out of the way completely, to see if that is the issue.

Handlers are really a personal preference. We still recommend suPHP for Wordpress sites or other similar CMS software since that ensures that file ownership and permissions are handled properly. Some admins do play around with the handlers a bit to find one that gives them good speed and usability.

This is good to know, as ALL of my sites are WordPress sites. It appears I am using

PHP Handlers | cPanel & WHM Documentation

PHP handlers contain libraries that the Apache web server uses to interpret and run PHP code.

docs.cpanel.net

To make this change, according to the above doc, there seems to be a LOT of security checks that need to be done!

 

[rivermobster]

For some reason the above got posted before I had the chance to finish my questions!

So anyway...

Is this something a novice like me can do myself? Or should I open a ticket for it?

Right now the only handler option I appear to have is CHI, with no other options available.

 

[cPRex]

You can install the handler through EasyApache. If there are conflicts, it will tell you right in the interface and it will make the adjustments for you.

The only real "checks" that need to happen are that all files should be 644 and all directories should be 755. If not, you'll receive permissions errors.

 

[rivermobster]

You can install the handler through EasyApache. If there are conflicts, it will tell you right in the interface and it will make the adjustments for you.

The only real "checks" that need to happen are that all files should be 644 and all directories should be 755. If not, you'll receive permissions errors.

Ok so...

Where is the file manager for WHM? lol Can I use the one in the cPanel account i made just for this particular domain?

Signed,

Learning stuff. :P

 

[cPRex]

There isn't an equivalent tool in WHM. You'll just want to ensure that's the case for the individual domain content. I should be clear that the "644 and 755" permissions rule is for the content inside the user's public_html directory and not all files on the system, so sorry if that wasn't clear the first time.

 

[rivermobster]

There isn't an equivalent tool in WHM. You'll just want to ensure that's the case for the individual domain content. I should be clear that the "644 and 755" permissions rule is for the content inside the user's public_html directory and not all files on the system, so sorry if that wasn't clear the first time.

Yeah, I was wondering about that! lol

That's still a lot of files/folders to check with a WordPress installation.

Which opens up a whole can of worms for future WP installs and the upcoming migration I have planned...

Is there some easy way to to this? Should I not bother with this?

All my clients are WP clients...

Thank you for your insight on this.

 

[cPRex]

Honsetly? I wouldn't worry about it. I'd make the switch, and then if you get errors they'll be logged in the Apache error log and you can sort them out. If there are TONS of errors, you can change permissions en masse with a simple command if you get to that point.

 

[rivermobster]

Honsetly? I wouldn't worry about it. I'd make the switch, and then if you get errors they'll be logged in the Apache error log and you can sort them out. If there are TONS of errors, you can change permissions en masse with a simple command if you get to that point.

I was kinna hoping you would say that. :P

Before I go further...

How will this affect future installs or my upcoming migration?

 

[cPRex]

I don't think it will affect them at all :D

If anything, it will make future Wordpress installs easier as you won't run into possible permissions issues in the future, but I wouldn't even factor that in to the migration. If you migrate the EasyApache settings over from Transfer Tool either before, or at the same time you do the main data transfer, it will be setup the same as the old system.

 

[rivermobster]

I don't think it will affect them at all :D

If anything, it will make future Wordpress installs easier as you won't run into possible permissions issues in the future, but I wouldn't even factor that in to the migration. If you migrate the EasyApache settings over from Transfer Tool either before, or at the same time you do the main data transfer, it will be setup the same as the old system.

Good to know. I was going to have my hosting company (HostDime) to the entire migration for me so I don't have to deal with it.

I'm hoping all the settings we put in place now will be better than the settings on the shared server I am currently on??

 

[rivermobster]

ok so...

mod_suphp has been provisioned. Now I see the option in PHP Handlers.

Should I just select the new option? Or check for any errors first?

@cPRex

 

[cPRex]

Yup - should be just as easy as choosing it. Give the system a few seconds to apply it, then check some pages on the site to see how that's working for you.

 

[rivermobster]

Yup - should be just as easy as choosing it. Give the system a few seconds to apply it, then check some pages on the site to see how that's working for you.

Ok so now I have a problem in the backend of my WP test site...

This same exact problem happened on my shared server. I worked with HostDime and the theme vender, and it came down to an issue in ModSecurity.

This is from ol the support thread on HostDime...

*edited*

The problem was (and now is)...

I added SIte Origin Premium to this site: https://domain.net/ < I just use it for testing stuff

Activated it, no problem. Activated all the premium widgets, no problem.

Went to Plugins > SiteOrigin Widgets Bundle > Manage Widgets

There were six Widgets there Disabled: Features, Headline, Icon, Price Table, Taxonomy, Video player.

Activated em all, and bam, no more Appearance > Customizer page!!

Hit the back button, and Deactivated those Widgets. Customizer page is back.

_________________________________________

So do you think we have the same problem now, after switching to suphp? Or is this a file permissions issue?

I went through and Deactivated all the SiteOrigin widgets, and now the customizer page IS back.

I can ask HostDime what setting they changed if you want.

Thanks Rex.

 

[cPRex]

It seems like ModSecurity is just tripping on the same rule, but that wouldn't necessarily be related to suPHP. It is odd that one of the plugins is generated such a large response header, but you can workaround that by editing the /etc/apache2/conf.d/modsec/modsec2.user.conf file and bumping the limit for that variable:

SecResponseBodyLimit 524288

In your case, you'd want to choose a number higher than 4048000, so I'd try 8096000 to see if that takes care of it. You could also disable the entire rule as HostDime mentioned, although I don't see the rule itself included in your output.

 

[rivermobster]

It seems like ModSecurity is just tripping on the same rule, but that wouldn't necessarily be related to suPHP. It is odd that one of the plugins is generated such a large response header, but you can workaround that by editing the /etc/apache2/conf.d/modsec/modsec2.user.conf file and bumping the limit for that variable:

SecResponseBodyLimit 524288

In your case, you'd want to choose a number higher than 4048000, so I'd try 8096000 to see if that takes care of it. You could also disable the entire rule as HostDime mentioned, although I don't see the rule itself included in your output.

You're gonna have to help me with this, as I'm not sure what to do here.

How do I make this change? I'm a server noob, remember?

 

[rivermobster]

Should the Connections Engine ruleset be disabled?

 

[rivermobster]

*edited*

 

[rivermobster]

Now to add to the confusion even more...

I put the PHP Handler back to cgi. Re-enabled all the widgets, problem came back. No more Appearance > Customize page in WP.