Custom PHP Install

I was advised a while back to install my own PHP install since my site required register_globals = on and fopen() = on.

I followed the guide they pointed me too here http://wiki.dreamhost.com/index.php/Installing_PHP5

At the time the large message stating they didn't offer support when you do this was not there so now I'm stuck for help.

I'll explain as best I can but this might take a few minutes to read.

I installed OsCommerce to one of my sites. It required register globals to be on. This was before OsCommerce released the register globals patch. I also had a subdomian from the OsCommerce domain which I had a shoutcast stats page which required the use of fopen.

I contacted Dreamhost who pointed me in the direction of the wiki article above which I followed.

I installed the PHP to my OsCommerce domain and soft or sym linked the php install to my subdomain so that both of them would run on the same php.ini configuration and that worked perfectly.

Now later I opened another domain in my account which I installed mambo and mambo required the use of fopen for its add-on packages. I thought I would just do the same trick and soft or symlink this domain to the php install but this did not work.

The unusual thing with my install is that some of the files are not where they should be. Its as if the php has been installed for that domain.. for example my php.ini is located in php5/etc/mydomain.com/php.ini
also my php.cgi is located directly inside the cgi-bin folder inside my domains root folder.

According to this article my php.ini shouldnt be there
http://blog.dreamhosters.com/forum/programming/36351-custom-php5-install-for-multiple-domains.htm

If I follow the instructions in that article above and modify my htacces so that my domain uses the custom php install I get 500 internal server errors, soon as I remove the add handler line in htaccess it my domain reverts back to using the default dreamhost php again.

Can someone help me resolve this issue please?
Ideas suggestions welcomed! I have been trying to sort this for around a month.. daren't try any changes incase I crashed my sites lol so I have just spent most of the time searching and reading but nothing came up that seemed to mention my problem.

Thanks guys!!!!!

Being the lazy type, I'd first try using my own php.ini:
http://wiki.dreamhost.com/index.php/PHP.ini

It'd be nice to know if this method will override register_globals and fopen. I use it for upload_max_filesize and it's very handy.

-Scott

Sorry perhaps I should have explained, I am not what you would call an advanced user.
I wouldn't normally be dabbling in this kind of stuff only I had no other option to solve my prior problems.

I would therefore advise that all answers come in the form of "Noob Instructions" lol

Sorry, perhaps I should have explained my skill level.

Thanks :D

It sounds like you are getting the hang of things, and I do not want to sound disparaging or critical, but I think you should know that:

1) register_globals being set on is a significant security risk for your site. Many common exploits use this as an attack vector, and you should very carefully consider this before deciding to turn them back "on".

2) Dreamhost's disabling of allow_url_fopen is for your protection. Again, this "feature" of PHP can easily leave your site vulnerable to exploitation unless some fairly sophisticated and thorough programming is in place to filter what is retrieved from a remote site.

3) The combination you describe - enabling register_globals *and* enabling allow_url_fopen for your sites (particularly an e-commerce site) can be a recipe for potential disaster.

This risk is greatly magnified by your own description of your skills. A good programmer with a good understanding of the issue(s) involved can mitigate some of these risks, but your reliance on others' code coupled with your lack of programming experience will make it difficult for your to evaluate the weaknesses that may be in that code. In short, you may be exposing yourself to considerable risk by modifying PHP to work in the way you describe.

Consider also that, as a citizen of a shared server, your security practices , good or bad, have the potential to impact others who share your server. Modifying the environment to remove/disable/thwart security protections DH has installed for the protection of all is a serious matter, and the responsibility to "know what you are doing", in order to do this without negatively exposing others, is very real.

To my way of thinking, doing this is a bit like disabling a safety feature on a passenger bus for your own convenience - maybe if you are an automotive engineer and are completely competent to do it safely, no harm would result; if you are just another passenger, doing such a thing without knowing the risks could be disastrous.

All of this is one of the reasons that DH support will *not* provide assistance with such things. The fact they they will *let* you do it at all presumes that, if you have sufficient knowledge to make these kinds of changes, you are likely to have sufficient knowledge to make them wisely.

The problem with the wiki article, and (to some degree) help of this type from the Forum, is that it "short-circuits" that "built-in" barrier to ill-advised modifications. This can have much the same effect on the security of the server as placing a penny in a fuse holder has on the electrical system of a house.

For all these reasons, and since you indicated you were running a e-commerce site, I respectfully suggest that you consider hiring an experienced PHP developer/ programmer to review your applications, the related implications of your proposed environment changes, *and* implement whatever changes are required/indicated rather then trying to "do it yourself".

These changes are much more significant, to both *your site* and those of others sharing your server, than the wiki's example of changing the max_upload_filesize, and should *not* be approached in the same manner.

None of this is intended to be critical of you, and I hope you read this in the spirit in which it is offered. Just because something *can* be done, does not mean that it *should* be done, and I really want you to understand the risks involved in what you are trying to do.

I wish you, and your site, only the best!

--rlparker