Help with suphp mess

E

emmanuel

Verified User
Joined
Mar 26, 2007
Messages
88
I've been having problems after the latest DA update whenever a user make changes via DA, the template causes httpd to die with the error "Invalid command 'suPHP_UserGroup'"

Initially, I fixed this by removing the suPHP lines in httpd config since I don't run suphp. But this certainly isn't a permanent solution.

Doing a search, I found the DA discussion on this http://www.directadmin.com/forum/archive/index.php/t-19644.html

and followed the advise to do the ./build suphp by smtalk.

Unfortunately, that totally screwed things up because no webpages will display. So I decided maybe I was better off without suphp. Except there's apparently no way to remove suphp.

When I comment out the suphp lines in Apache, httpd chokes because libphp4.so apparently had been modified so it no longer works, being 2bytes longer than expected.

When I try to ./build php4cgi it chokes because apparently, it expects suphp to be around.

So my question is, how do I get rid of suphp permanently and restore everything back to the original state? Or somehow get everything working again? Thanks.
 
Only "./build php" touches configuration files :) "./build phpX-cgi(cli)" just updates PHP but doesn't touch configuration files.
 
It's dying telling me there was
"configure: error: Please reinstall the iconv library.

*** There was an error while trying to configure php. Check the configure/suphp/ configure.php4 file"

So I did a "./build iconv"
which died with "./build: line 4149: ldconfig: command not found"

But I ignored that and tried ./build php n again, which seems to work until it died with an error about freetype.h. I don't know if I needed it but since it was there, did a ./build freetype anyway, then it was back to ./build php n

I figure there's probably going to be a few more rounds of this so it will likely take a while. BUt if it's not supposed to be like this, please let me know before I go through the whole shebang :D
 
It should be like this, because you didn't run "./build all d" for the first time.
 
That went through and when I saw httpd starting up without error, I was overjoyed, for all of maybe 10 seconds when I tried to load up a client's php page and I saw php source code instead.

Checking, I realized that php4 was not loaded in the new httpd.conf but suphp was still loaded. Uncommenting php4, gives me an error about libphp4.so: undefined symbol: sapi_module

Then I checked php-handlers and viola, .php was not registered with it for some reason. Edited that and website came up, but only with php5 support.

After going through my client list, I realized nobody is at the moment running any php4-dependent stuff so I decided to live without php4 for now since it's far more important that the site works with what they have when they wake up.

But I still have to consider the possibility that somebody might actually have something based on php4 running that I wasn't aware of. So how do I go about putting php4 back as it was previously?

Thanks again smtalk for the help.
 
You shouldn't uncomment php4 module if it's installed as CGI. CustomBuild does everything automatically. You can try "./build rewrite_confs" if you think that something is wrong with your configuration files.
 
Is there anyway to make/tell if php4 would run if I needed it? The original conf files are all overwritten by now so I cannot remember if I was running php5 as module and php4 as cli or the other way round since both php4/5 cannot be used together as loaded modules.
 
You can see that by running: ./build options :) In options.conf you can choose any combination you want. Everything is said in CustomBuild FAQ (you should take a look at it).
 
smtalk said:
You can see that by running: ./build options :) In options.conf you can choose any combination you want. Everything is said in CustomBuild FAQ (you should take a look at it).
Click to expand...

Thanks! I'll take a look at it later tonight because my actual job isn't running the server (boss decided we could do it and threw the job at me), busy dealing with other kinds of crisises for my clients.

Although, I'll appreciate greatly if you can point me to where I can learn to remove suPHP entirely.

Right now, I have the entire squirrelmail folder hierarchy chmod to 777 in order for it to work because I don't have time to figure the right way to fix it. Even to a noob like me 777 sounds like a very very bad idea for any extended period of time. And I've no idea what else might be broken because of suphp.
 
Last edited:
emmanuel said:
Thanks! I'll take a look at it later tonight because my actual job isn't running the server (boss decided we could do it and threw the job at me), busy dealing with other kinds of crisises for my clients.

Although, I'll appreciate greatly if you can point me to where I can learn to remove suPHP entirely.

Right now, I have the entire squirrelmail folder hierarchy chmod to 777 in order for it to work because I don't have time to figure the right way to fix it. Even to a noob like me 777 sounds like a very very bad idea for any extended period of time. And I've no idea what else might be broken because of suphp.
Click to expand...

You can even have chmod 400 with suPHP :) Just make sure it's owned by webapps user ( chown -R webapps:webapps /var/www/html ). If you don't want to use suPHP - just set PHP as CLI in options.conf file and run "./build php n". Good luck! :)
 
smtalk said:
You can even have chmod 400 with suPHP :) Just make sure it's owned by webapps user ( chown -R webapps:webapps /var/www/html ). If you don't want to use suPHP - just set PHP as CLI in options.conf file and run "./build php n". Good luck! :)
Click to expand...

I decided to give suPHP one last spin after reading this but 400 didn't work. The folders already belonged to webapps since the beginning so I started wondering maybe webapps wasn't the user that apache was running on for some reason. I've no idea how to check who is apache/php running as.

But searching around for suPHP, I found another thread that says I should run it as apache:apache. That worked with 744 or 700 but not with 400 either. Although I thought that would make sense since 400 would mean read-only/no-write/no-execute isn't it?
 
BTW, I've read the CustomBuild FAQ but it doesn't, neither does google turn up any way to remove suPHP except using the OS's package manager. But since Custombuild didn't install suPHP via the OS packager, it seems that I'm stuck with suPHP even if it fails to work subsequently and/or I don't want it?
 
I told you that if you don't want to run PHP with suPHP you need to set PHP as CLI in options.conf and then run "./build php n". If you want to use PHP as CGI but don't know where is the problem, then you can find the answer in /var/log/suphp.log.
 
smtalk said:
I told you that if you don't want to run PHP with suPHP you need to set PHP as CLI in options.conf and then run "./build php n".
Click to expand...

Yes, however the problem is I can't run both php versions as CLI right? One of them have to be CGI and that would run smack into suPHP isn't it?


If you want to use PHP as CGI but don't know where is the problem, then you can find the answer in /var/log/suphp.log.
Click to expand...

suphp.log doesn't tell me anything unfortunately, just a whole repetitive list of "executing something as UID GID". When it stops php from doing whatever it is, it just fails silently. Furthermore, I read that it has a significant impact on php performance so all in all, it sounds like a bad idea to use suPHP.

There got to be some reason why suPHP exists but I'm not sure what exactly it is for, and whether it's worth the hassle to make it work or risk client running php4 scripts that hasn't been updated.
 
You must log in or register to reply here.
Back
Top