phpsuexec compilation problem

[abubin]

I used to compile apache without phpsuexec.

Now, when I enable phpsuexec, httpd will not be able to start. Compilation will complete without error but service httpd start will not start apache. If I compile again without phpsuexec, it will wor k again.

Anyone have any idea what is wrong with my apache?

Thanks in advance.

 

[Phenomenon]

Try disabling Versioning in PHP, it gave me a headache few times..

 

[rsaylor]

httpd configtest ? what errors are reported?

 

[abubin]

httpd configtest ? what errors are reported?

#httpd configtest
Warning: DocumentRoot [/home/domain1/public_html/demo] does not exist
Warning: DocumentRoot [/home/domain2/public_html/wap] does not exist
Syntax OK

Those two error shouldn't be the cause, right?

 

[abubin]

Try disabling Versioning in PHP, it gave me a headache few times..

disabled versioning, still same problem.

 

[mrcbrown]

What does it say in your logs? access_log and error_log? Does apache ever start up?

 

[abubin]

problem solved. One entry in httpd.conf is causing apache unable to start. Some php flag to disable safe mode.

 

[inetsur]

httpd not starts

Hi abubin,

In wich entry in httpd.conf is causing apache unable to start ? Do you post "Some php flag to disable safe mode".

I have the same issue.

When i try to restart httpd
httpd: [ != HTTP/1..] httpd has failed, please contact the sysadmin

Thanks,

D.L.

 

[abubin]

you must first use SSH to try to start your apache. Assuming you are using redhat based distro.

service httpd start

You will then see the error message which will show you which line is causing the failed startup. For me, I traced that line to a php directive which I remove. Forgot the exact syntax but it's something like this :

php_flag safe_mode_off

 

[rsaylor]

missing documentroots will cause apache failures.

Warning: DocumentRoot [/home/domain1/public_html/demo] does not exist
Warning: DocumentRoot [/home/domain2/public_html/wap] does not exist

You should create these directories or modify the docroots so it is to the public_html where the user does not have access to delete.

 

[rsaylor]

in a suexec enviroment if the user wants to run there own customer php settings the user can upload a php.ini to there directory where there application is.

[php.ini]
php_flag safe_mode_off

That would be the way to work around this, placing php directives in a php.ini is the way to do it. Placing these directives in apache or .htaccess will cause apache to fail or the site to get a 500 error.

 

[Spiral]

Generally, I don't recommend phpSuExec at all ... period!

PhpSuExec is a major security problem in and of itself and creates more new
problems than those it is there to fix so you are effectively trading one set
of security problems for another more dangerous set which kind of defeats
the whole entire point of phpSuExec in the first place.

As a side footnote, it is also not necessary to run phpSuExec to be able to track
which accounts and scripts send mail from your server(s) because you can
accomplish the same by just turning on Exim's extended logging.

Those who think they are increasing security by switching to phpSuExec are in for
a very major rude awaking because they are actually doing exactly the opposite!

However, with that said ....

The newer competing change id process, SuPHP, isn't plagued with all the
grand canyon security problems found common with phpSuExec.

Unlike phpSuExec, I would recommend that people use SuPHP.

The only major drawback of that one is it is more designed for Apache 2.

For those who can't upgrade to Apache 2 or otherwise cannot go to SuPHP for
whatever reasons then I would recommend that you just run a regular PHP installation
and not use phpSuExec but rather instead just increase the logging for Exim and Apache
and put in tighter folder owner / group permissions and other security tweaks.

You will be a whole lot better off than installing phpSuExec!

 

[abubin]

Generally, I don't recommend phpSuExec at all ... period!

PhpSuExec is a major security problem in and of itself and creates more new
problems than those it is there to fix so you are effectively trading one set
of security problems for another more dangerous set which kind of defeats
the whole entire point of phpSuExec in the first place.

As a side footnote, it is also not necessary to run phpSuExec to be able to track
which accounts and scripts send mail from your server(s) because you can
accomplish the same by just turning on Exim's extended logging.

Those who think they are increasing security by switching to phpSuExec are in for
a very major rude awaking because they are actually doing exactly the opposite!

However, with that said ....

The newer competing change id process, SuPHP, isn't plagued with all the
grand canyon security problems found common with phpSuExec.

Unlike phpSuExec, I would recommend that people use SuPHP.

The only major drawback of that one is it is more designed for Apache 2.

For those who can't upgrade to Apache 2 or otherwise cannot go to SuPHP for
whatever reasons then I would recommend that you just run a regular PHP installation
and not use phpSuExec but rather instead just increase the logging for Exim and Apache
and put in tighter folder owner / group permissions and other security tweaks.

You will be a whole lot better off than installing phpSuExec!

Yes, I also read about phpsuexec causing security problems, hence I did not use it until now. I have a problem with httpd running in excess of 90mb. It was suggested by someone that I enable phpsuexec to track the problem. After enabling phpsuexec, I still couldn't track the problem. So, I will be turning it off later.

 

[abubin]

in a suexec enviroment if the user wants to run there own customer php settings the user can upload a php.ini to there directory where there application is.

[php.ini]
php_flag safe_mode_off

That would be the way to work around this, placing php directives in a php.ini is the way to do it. Placing these directives in apache or .htaccess will cause apache to fail or the site to get a 500 error.

Hmm...I tried placing the php.ini with that directive into specified domain's public_html folder but it doesn't work. Where is the correct place to put this?

 

[Spiral]

Yes, I also read about phpsuexec causing security problems, hence I did not use it until now. I have a problem with httpd running in excess of 90mb. It was suggested by someone that I enable phpsuexec to track the problem. After enabling phpsuexec, I still couldn't track the problem. So, I will be turning it off later.

I am assuming that you don't just have too many sites hosted on your server ...

The first thing I would do before anything else on that is go to "View Bandwidth Usage"
and sort the sites on your server by bandwidth usage because I'd be willing to bet that
the excess usage is going to fall out of one of the first few on the top of that list.

The next thing would be to actually look at the cooresponding log files located in
/etc/httpd/domlogs and see what is actually going on for those sites.

While in that directory, you could also do an "ls -lSr | tail" and see what sites have
the largest log files and examine those files to see what is going on.

Excessively large log files will definitely contribute to high resource load levels for
Apache especially if the error_log file grows too large. It is generally a good idea
to roll the logs when the statistics update daily. Likewise, I would check the general
logs in /etc/httpd/logs and make sure the error_log and access_log files have not grown
excessively too large. I've seen some greater than a gigabyte on some servers!

Meanwhile you can also do a few "Apache Status" views when you are noting the higher
loads and that will tell you what is happening with Apache at that precise moment.

Multimedia streaming such as video or audio, large file upload or downloads, or
poorly written CGI scripts (usually Perl) are the usual typical culprits behind
higher usage loads so keep a keen eye out for that when reviewing log files and
Apache status screens, etc.

Another one that people don't often think about is hotlinked images. Take a simple
signature image and place it on a few popular forum sites hotlinked to a site on your
server and you could be getting more simultaneous connections for that small file
than your server can handle in the period of time between requests.

Hope that helps!

PS: Using phpSuExec would actually INCREASE your Apache memory usage! LOL