PHPSuExec being installed on existing servers »» Tips and tricks

[chaloupe]

This is the best answer of the year for me about Mambo!

Tx quietFinn!

So I will probably get it enable soon. Will send an email to all clients and then get the job done at night.

[quietFinn]

Can anyone confirm that WHM.AutoPilot v.2.x works with PHPSuExec?

[Serra]

Mine is working fine. The only problem I had was with the mib_data folder. I had to chmod and chown all the files. If you see the dedicated server thread, the script I wrote doesn't change anything above /public_html/, so it doesn't do mib_data.

[vtrain]

has this been installed/configured in more shared servers?

I'm asking because one of my clients has a problem on a photo album. Before I debug I want to know if I need to do the changes for PHPSuExec or not.

Vt

[quietFinn]

Originally Posted by vtrain

has this been installed/configured in more shared servers?

I'm asking because one of my clients has a problem on a photo album. Before I debug I want to know if I need to do the changes for PHPSuExec or not.

Vt

http://forums.hostgator.com/showpost...50&postcount=7

[vtrain]

Originally Posted by quietFinn

http://forums.hostgator.com/showpost...50&postcount=7

Thanks. THis is more reliable anyway ;-)

Vt.

[bizfast]

I've recently started with HostGator and noticed that the PHPSuExec causes some features to work differently. Hopefully this will help others who are trying to debug similar issues.

One is http_auth which is the browser based authentication that pops up to prompt users for their login and password on protected pages/directories. PHP_AUTH_USER & PHP_AUTH_PW are no longer passed through PHPSuExec. So when you get the login box, you enter your username and password and you will never be able to login. I had about 4-5 pages that were password protected using this method, so I had to develop a login page to replace the http_auth logic. From what I've read, PHPSuExec also disables standard .htaccess authentication, but I have not been using this so maybe another user can validate/test this firsthand.

As mentioned in the original post, php_flag & php_value statements need to be moved over to the new php.ini file. I noticed register_globals is on by default, but if you have a php.ini file it will automatically turn off register_globals, even if the php.ini file is blank. So be sure to add the register_globals=on flag to the php.ini file if you need register_globals on.

Also, I've read that php.ini needs to be included in every subdirectory where you want it to be used, as opposed to the .htaccess file that by default is applied to every subdirectory. This doesn't affect my use of the php.ini file, but I could see how it may be a pain for others to copy this into multiple directories. Again, this is something I read while trying to debug my issue, so someone would need to verify this firsthand.

Here is a sample of what I used to replace the http_auth code to check for username/password.

PHP Code:

<?
// define admin user/password -- These should really be in
// a separate script such as a config file. Replace yourusername & 
// yourpassword below with the actual password you want to use
define('ADMIN_USERNAME', 'yourusername');
define('ADMIN_PASSWORD', 'yourpassword');
 
session_start();
//session_register(), session_is_registered() or session_unregister() are no longer 
//needed in PHP 4.3 when using register_globals is set to off
//http://us2.php.net/manual/en/ref.session.php
if($_POST["f_username"])
{
$_SESSION["username"] = $_POST["f_username"];
$_SESSION["password"] = $_POST["f_password"]; 
}
 
//For security, escape strings that could be checked against mysql database
//You should review security and add any needed security enhancements from:
//http://www.sklar.com/page/article/owasp-top-ten
$_SESSION["username"] = mysql_real_escape_string($_SESSION["username"]);
$_SESSION["password"] = mysql_real_escape_string($_SESSION["password"]); 
 
if($_SESSION["username"] == ADMIN_USERNAME and $_SESSION["password"] == ADMIN_PASSWORD) //Password Matches
{
//Password is correct, do not display the form, allow user to see the page
}
//If no input exists, this is the first time the form is displayed. Show form, do not show page.
elseif(!$_POST["f_username"] or !$_POST["f_password"]) 
{
$exit = 'X'; 
}
//Occurs any time the password does not match. Show error, show form, & do not show page.
else 
{
echo "Sorry, authentication failed.";
$exit = 'X';
}
if($exit == "X") //If user is not yet authenticated, show form & EXIT
{
?>
<br><br>
<form name="authenticate_user" action="<?echo $next_page;?>" method=POST>
<table>
<tr><td>
Username&nbsp;&nbsp;<input type=text name="f_username" size=20 maxlength=20>
<br>
Password&nbsp;&nbsp;<input type=password name="f_password" size=20 maxlength=20>
<br><br>
<input type=submit name="Submit">
</td></tr></table>
</form>
<?
exit; //Exit so the page contents are not shown.
}
?>

Save the above script as inc_authenticate.php

Next, whatever page you are trying to protect, just include the following code at the top of the page.

PHP Code:

<?
require ("inc_authenticate.php");
?>

Keep in mind this is just a simple example. You may need additional security depending on your use.

Garett

[Serra]

From what I've read, PHPSuExec also disables standard .htaccess authentication, but I have not been using this so maybe another user can validate/test this firsthand.

I don't think that is the case. I'm using several sites with this method and they continue to work after PHPSuExec was installed.

The method that you discribe above is ok, but you should kill the session and issue a 401 error instead of just stopping the script.

[jeff_s]

So is this conversion to "phpsuexec" progressing?

What servers have/have not been upgraded to phpsuexec?

On 02 May, a reply from HG's GatorAndre in this thread promised notification of an upgrade schedule by email or posting, but (I believe) this has not occured.

-Jeff
HG reseller

[chaloupe]

It should be in cue after template spelling and shared ssl pages update.

To know if your server has been change to PHPSuExec, you can use the phpinfo.php files. There is a thread about it I will try to find it and post the link to how to check if PHPSuExec has been enable or not on your server.

Best regards,

[chaloupe]

It is on the first page of this thread


http://forums.hostgator.com/showpost...50&postcount=7

Best regards,

[jeff_s]

Chaloupe, I know about phpinfo() revealing the change, and I have been watching this thread with keen interest. But that was not my question. I was hoping for an authoritative (HG) answer about progress and a schedule, to be warned in advance when this will happen to my server. Being in the position of finding broken scripts, discovered hours or days after it happened, without notice, is just bad business.

Btw,

"It should be in cue after template spelling and..."

"cue" should be queue. It's from French, meaning "tail".

[chaloupe]

DJ's CD player got cue on it and it is all in english. it's a shortcut I use.

[sheila]

Originally Posted by GatorAndre

We will add it to existing servers one at a time, so you will be informed once this takes place. I recommend you to start working on the php.ini thing as soon as possible though, so whenever it is installed on your server you already have everything modified and just need to upload.

Well what happened to the part about "you will be informed"?

I had to hear about it from my client when their site came up broken this morning.

Gee, thanks guys.

[vtrain]

I have the phpinfo() on my server and I check everyday... I would really like to know when will this be applied to my server with a few days in advance...

Vt

[jeff_s]

How is this effort progressing?

Which servers have been converted to phpsuexec?

Mine has not. Is there a schedule posted anywhere yet for when the remaining servers will be converted?

In post #9 of this thread, GatorAndre promised that customers would be notified by email in advance of this conversion being done on our servers. Has anyone received such an email warning? From some other threads, it appears that at least some customers were NOT warned before changing over to phpsuexec.

-jeff_s

[vtrain]

After reading the latest post from Serra here: http://forums.hostgator.com/showthre...astpost&t=6864
I created a ticket, about two days ago: XGW-846059

Posted On: 02 Jun 2006 12:43 PM
Hi,

Unfortunately you would just need to check the announcement forums. There is really nothing more we can suggest. :-(
Thank you.

If there is anything else we can assist you with please do not hesitate to ask.

Regards,
Matt Johnson

The info should appear here. I just accepted it will happen when I'm not expecting.... nothing I can do of. I'm checking also with the phpinfo()

Vt

[faras]

My clints and I using Movable Type for our weblogs. MT generates permition 666 for PHP files when we update it, but PHPSuExec sets permition 644 for php and cgi files!
How can we solve the problem and fix the errors?

[Serra]

PHPSuExec doesn't set permissions.

[faras]

Originally Posted by Serra

PHPSuExec doesn't set permissions.

So from where I can fix my websites error?
what shoud I do?>

[quietFinn]

Originally Posted by faras

So from where I can fix my websites error?
what shoud I do?>

Change the permissions of php files to 644, using ftp client, or cPanel file manager.

Originally Posted by Serra

PHPSuExec doesn't set permissions.

Ditto.
It's most likely the software you are using that's doing that I guess.

[Kelmas]

Is PHPSUEXEC planned to be running on gator19?

[quietFinn]

Originally Posted by Kelmas

Is PHPSUEXEC planned to be running on gator19?

It will be running on all servers, sooner or later.

[cjnoyes]

Originally Posted by faras

My clints and I using Movable Type for our weblogs. MT generates permition 666 for PHP files when we update it, but PHPSuExec sets permition 644 for php and cgi files!
How can we solve the problem and fix the errors?

I'll bet that this is one of those php things, that if it creates a new topic or something like that, creates a php page holding the data. I saw some I think it was simple blog or something like that that did that. Something like that would need to be rewritten so that when they are written, they get permissions set correctly after they are written