I thought 4.3.9 was vulnerable to the recent holes in PHP? Nonetheless trying a different version of PHP has no effect whatsoever.Originally Posted by MFaisal_i
I thought 4.3.9 was vulnerable to the recent holes in PHP? Nonetheless trying a different version of PHP has no effect whatsoever.Originally Posted by MFaisal_i
Yes, he thinks that all is fine, but he's really running server software with serious and known security holes. I wonder how long he has til he gets hacked?
I am becoming more and more convinced this is all because buildapache/easyapache is refusing to rebuild apache even though I tell it not to skip it.
I'm in the process of kludging the scripts to force a complete rebuild of apache but I guess the cpanel guys need to fix this. I'd raise it as a bug, but I absolutely detest bugzilla. Seems to affect current stable and release builds.
Just to add my two cents I've noticed that the issue seems to be actually phpsuexec. So php 4.3.10 with zend 2.5.7 works fine, but if you compile apache with php suexec enabled it'll break a lot of things. Recompiling without phpsuexec fixes the issue.
So if you want to use phpsuexec you will need to stick with 4.3.9 for now
I will add 4 cents I compiled php 4.3.10 with phpsuexec and zend everything works just fine![]()
Cue the choirs of angels, I've fixed it.
There appears to be a bug in easyapache which prevents it recompiling apache if it believes it to be the current version despite when other factors dictate that it should be recompiled. There's actually an override for things like the perl module to force it to build anyway but there doesnt appear to be a similar thing for phpsuexec.
It also doesnt listen to the tick box option that lets you supposedly force the update either.
The "easy" way to force easyapache to do an update is run it from the command line - when the output stops and it asks you to pick a config choice, use another SSH session as root to do the following:
cd /home/cpapachebuild/buildapache
edit checkapsetup with your preferred editor and where it says:
if ($apver ne $apv) { print "1"; } else { print "0"; }
replace this line with simply:
print "1";
save the file, and logout.
Go back to your other SSH window and continue interacting with easyapache as you would normally. Apache will be forced to recompile, and you'll find things like phpsuexec actually start working properly. I can't say if this will fix any particular problems you're having with Zend, but it WILL make regular php work with phpsuexec on a server that hasnt previously had phpsuexec enabled on it (because an apache recompile is required due to the fact that phpsuexec patches apache itself).
NOTE: Until this is fixed, each time you need to force an apache rebuild, you will have to redo this entire procedure. Each time easyapache is started it redownloads and reunpacks a fresh copy of the cpapachebuild files, overwriting your changes.
CPANEL DEVS: fix /home/cpapachebuild/buildapache/modules/apache_prep to include if's for the occurence where 'skip apache build' is unticked and/or to force a compile if phpsuexec is enabled (just in case), like you have with the perl module.
Last edited by philb; 01-08-2005 at 11:17 PM. Reason: Clarified the 'bug' - see italic section.
This actually will break apache installs, however the issue has been fixed.Originally Posted by philb
Er, nonsense. All it does is force a rebuild, something buildapache would have done anyway in older versions.Originally Posted by cPanelBilly
Oh, and something which unticking 'skip build apache even if up to date' will do. (EDIT: When it's fixed) It's exactly the same. All it does is fool buildapache into thinking the version is out of date and it does a rebuild in exactly the same way as it would for any other reason.
Last edited by philb; 01-11-2005 at 12:20 PM. Reason: addendum, caveat
Thanks... It works after editing the file checkapsetup file under /home/cpapachebuild/buildapache while recompiling apache.
And how, exactly is it fixed? Still have problems now - long after post that says is fixed. I am trying a /scripts/upcp --force after running /scripts/sysup and /scripts/updatenow.
That did not help.
Problem is back again after upcp three days ago. Last time total rebuild of apache, option one, and then rebuild again. this time - no go. Anyone?
Last edited by lloyd_tennison; 02-26-2005 at 06:16 PM.
Lloyd F Tennison