Search results

Are you really need 4.4.9? most people uses PHP 5.x now. if do not need, remove PHP 4.4.9 from your server. if need, please rebuild PHP 4.4.9 from easyApache first.

You can use rewrite rule to do that just like with Apache.

You can do that with "build PHP" feature from admin console as well. Build matching PHP set the PHP configuration parameters matching that in your Apache setup, with "build PHP" you have to set parameters by yourself.

Please double check if you have SSL certificate configured properly under "SSL" tab for "ssl" listener from LSWS web console.

Just try build matching PHP one more time, one small issue has been fixed in PHP LSAPI 6.3 code. You need to put php.ini in /usr/local/lib/ .

Reproduced in our lab, fix is in the latest 4.2.4 build.

We will verify the rule posted by Karl with 4.2.4. if you have any specific rule to check, please let us know.

The missing style is from http://windowsforum.com/css.php?css=bb_code,dark_azucloud,facebook,login_bar,message,message_user_info,node_list,share_page,thread_view&style=2&dir=LTR&d=1377237793 latest 4.2.4 should have take care of it. I have switched to LiteSpeed and browse the forum for a while...

I am not sure what css problem to look at. thought it is the main layout, appear to be detail in the page. I will investigate more. May need to switch to LiteSpeed temporarily during investigation.

Please read http://www.litespeedtech.com/support/wiki/doku.php?id=litespeed_wiki:mod_security_compatibility Most rules will work fine, if there are minor compatibility issue, we will fix it. MULTIPART_STRICT_ERROR is not supported.

The memory limit is for individual process, not the sum of all PHP processes started by the daemon. It should be 40 + 2048, if you increase share memory to 10240, the set limit above 40+10240 + head room.

If it is the result of building matching PHP, you need to try it from command line /usr/local/lsws/fcgi-bin/lsphp5 -i If it works, you should be fine. if it does not, let us know the error message.

just go ahead build it. If cannot do it from WHM, do it from command line.

those are none-fatal errors, does not affect any thing, but you'd better eliminate those by fixing the php.ini.

there is another choice now: http://www.php.net/manual/en/intro.opcache.php For using very large shared memory, you need to write to the developer of each opcode cache, they can give you accurate answers.

I think your issue is more likely that PHP randomly crashed in the middle of processing css.php script. And CDN is used for one of CSS group, so if CDN cache a bad copy, it could many people receive bad CSS. Right now, litespeed seems stable on port 80.

stderr log is the output from processes writing to STDERR. The "ping" and "host" error are from third party CGI or something. the log like "Child process with pid: 244566 was killed by signal: 15, core dump: 0" is normal, just an idle external app being stopped with SIGTERM. core dump: 0 means...

More investigation found that other URL works is due to a flaw in LSWS handling redirect. when 127.0.0.1 is used, it goes to the Apache default vhost at /var/www/html, the URL does not exist, causes a redirect to /404.shtml, when redirect performed, LSWS uses the "Host" header to locate the...

The purge request must be sent to the IP that the vhost bound to, by default purge_cache_byrul.php uses 127.0.0.1, but the request cannot reach the vhost unless it also bound to 127.0.0.1 IP. Explicitly set the IP in the purge request works.

You can configure LiteSpeed to run another port with port offset, like 2000, Apache is on port 80, LiteSpeed is on port 2080. So, we can trouble shoot this issue without affecting other users. Please send us the URL having this problem, it may not be required, but, a temp root access could get...