mod_php and suphp?

[MACscr]

I about to setup some new servers and I was wondering if EA3 allowed the ability to run mod_php and suphp at the same time. I have some older clients that i dont want to have to go through the hassle of converting them to suphp, so i figure i could keep them at mod_php and have that as the secondary php option, but using suphp for the primary php version so that new clients use it, etc.

Advice?

[cPanelDavidG]

I about to setup some new servers and I was wondering if EA3 allowed the ability to run mod_php and suphp at the same time. I have some older clients that i dont want to have to go through the hassle of converting them to suphp, so i figure i could keep them at mod_php and have that as the secondary php option, but using suphp for the primary php version so that new clients use it, etc.

Advice?

The easiest way I can think of doing this is using EA3's concurrent PHP capabilities to run PHP 4 and 5, then setting PHP 4 to run as DSO (mod_php) and PHP 5 to run as SuPHP. PHP 5 can be your default, while users of older scripts can swiftly rename their scripts to .php4 (to execute as PHP 4 / mod_php) until their inner workings are resolved to work in a PHP 5 SuPHP setup.

In my experience, many publicly available PHP 5 scripts including the more popular apps are SuPHP-friendly nowadays.

[verdon]

In my experience, many publicly available PHP 5 scripts including the more popular apps are SuPHP-friendly nowadays.

Yes, and 3 simple shell commands will fix ownership and permissions for a client switching to suphp..

chown -R username:username /home/username/public_html/* ;
find /home/username/public_html/ -type d -exec chmod 755 {} \;
find /home/username/public_html/ -type f -exec chmod 644 {} \;

[MACscr]

Yes, and 3 simple shell commands will fix ownership and permissions for a client switching to suphp..

chown -R username:username /home/username/public_html/* ;
find /home/username/public_html/ -type d -exec chmod 755 {} \;
find /home/username/public_html/ -type f -exec chmod 644 {} \;

Thats not simple when your converting 300 accounts =P

[verdon]

no, but I bet it can easily be scripted to go through your users

[brianoz]

This script provided by cPanel will do the whole server in one easy hit:

/scripts/chownpublichtmls

You may have to remove write permission from a few scripts, but that's pretty easy... (chmod -R go-w /home/.)

There's no reason to run mod_php with suphp as all your PHP scripts will work in suphp - no headaches here in 4 years of running with phpsuexec then suphp. You'd lose most of the security advantage that suphp confers if you did, for no real advantage.

[cPanelDavidG]

...
There's no reason to run mod_php with suphp as all your PHP scripts will work in suphp ...

This is mostly, but not entirely true. Scripts that blindly set 777 permissions upon themselves and other files they rely upon will break in a SuPHP environment. Some older WordPress plugins exhibit this behavior.

However, this behavior is very rare in contemporary PHP scripts and should not be considered sufficiently significant to deter a migration to SuPHP. However, it is something to keep an eye out for when your customers complain of an internal server error with one of their scripts.

[brianoz]

You may have to remove write permission from a few scripts, but that's pretty easy... (chmod -R go-w /home/.)

This is mostly, but not entirely true. Scripts that blindly set 777 permissions upon themselves and other files they rely upon will break in a SuPHP environment. Some older WordPress plugins exhibit this behavior.

As I mentioned briefly in my post, you may have to fix permissions - as David said, you'll see 500 errors and can go check in the logfile /etc/httpd/logs/audit_log. It's actually safe to run the following command, which will remove group and other write permission from all files and directories under public_html directories in /home:

chmod -R go-w /home/*/public_html
OR
find /home -name public_html | xargs -r chmod -R go-w

or you can run a find variant to see what files/directories it would fix:

find /home \( -perm -2 -o -perm -20 \) -print | xargs ls -ld

If you want to be cautious, run the last find command first and save the output. As both of these commands change a lot of permissions, you should make sure you have a backup first.

It's probably safe to remove write permissions from *everything* in /home (ie: chmod -R go-w /home), but I'm not 100% sure as some of the mail hierarchy has group write permission, which is probably irrelevant as the group ownership is the user. (Perhaps someone with experience could comment)

[MACscr]

As I mentioned briefly in my post, you may have to fix permissions - as David said, you'll see 500 errors and can go check in the logfile /etc/httpd/logs/audit_log. It's actually safe to run the following command, which will remove group and other write permission from all files and directories under public_html directories in /home:

chmod -R go-w /home/*/public_html
OR
find /home -name public_html | xargs -r chmod -R go-w

or you can run a find variant to see what files/directories it would fix:

find /home \( -perm -2 -o -perm -20 \) -print | xargs ls -ld

If you want to be cautious, run the last find command first and save the output. As both of these commands change a lot of permissions, you should make sure you have a backup first.

It's probably safe to remove write permissions from *everything* in /home (ie: chmod -R go-w /home), but I'm not 100% sure as some of the mail hierarchy has group write permission, which is probably irrelevant as the group ownership is the user. (Perhaps someone with experience could comment)

Would be nice if someone with experience could comment on this last part about chowning/chmoding the home directories. I do know i will have users with directories/files in the /home/*/ dir that are owned by nobody and have 777 perms.

[aegis]

There's no reason to run mod_php with suphp as all your PHP scripts will work in suphp - no headaches here in 4 years of running with phpsuexec then suphp. You'd lose most of the security advantage that suphp confers if you did, for no real advantage.

There is one advantage to *NOT* using suphp. If you're running PHP as a DSO then you can use one of the many PHP caches and speed things up, sometimes dramatically so. It's the one big issue I have with PHP as a CGI.

Whereas I agree, suPHP as the default is very worthwhile, it could be relatively useful to be able to switch individual users to DSO so that they could take advantage of caching.

Unless someone has another idea for speeding up PHP under suPHP???

[brianoz]

Totally agree, the disadvantge of suPHP is that it is slower and accelerators don't work. For high volume sites, I'd want to place them on a server with only a few trusted clients (*), suhosin and CSF. Everyday hosting clients go on a server with suPHP and CSF.

(*) trusted means - they know what they're doing with PHP and security ...