Search results

Does it ever end? It could be a huge directory being indexed. need to locate that directory and stop it.

try "ps -ef | grep default.php" then quickly start stracing one of the PID listed. strace -tt -T -p <pid_of_php_serving_default.php> try multiple times, you will get one successful strace.

In Apache configuration, regular site is configured as one vhost on port 80, SSL site is configured as another vhost on port 443. They both pointing to the same document root, so they look the same, serve the same content. But from web server point of view they are two independent vhosts. If...

LiteMage was not turned on for the SSL vhost, in Apache configuration, SSL and regular vhost are two separate vhosts.

Maybe not completely disabled. strace the php process to find out which directory it is indexing. add a blank index.html

There could be multiple versions of PHPs, each version need its own php.d, cannot mixed together. And we intentionally not to use /etc/php.d usually used by system RPM. I think it should work if you symlink /etc/php.d, just the configuration in those ini files may not work properly for lsphp56.

maybe someone is abusing your server. find out which site, turn off auto directory index for that site.

Apache suPHP is running PHP as CGI, all request variables are passed as real environment variables, $_SERVER[] is based on that. LiteSpeed is using our own API and protocol to pass request variables directly into $_SERVER[], $_ENV is the original environment when lsphp process starts, it does...

You can add required ENV variables to External app Environment. https://www.litespeedtech.com/docs/webserver/config/extapps#env

You cannot do that, only your host can. You can ask your host about adding LiteMage add-on to the LSWS server license if have not, it is FREE now.

Please upgrade to 5.0.5 build 3 with command /usr/local/lsws/admin/misc/lsup.sh -f -v 5.0.5 You may need to clear LiteMage cache by removing the cache directory, restart LSWS. If problem persists, contact us with temp root access, we can take a look.

You should install "development files" for anything missing during running "configure". In this case, it should be apt-get install libpcre3-dev

liteSpeed has SSL negotiation/renegoication protection, since all SSL traffic going though CloudFlare IPs, you may need to add cloudflare IP as trusted IP, or turn off SSL renegotiation protection. https://www.litespeedtech.com/docs/webserver/config/listeners#renegProtection

Yes, it is a limitation of LiteMage. Yes, if you put "LiteMage off" in the http configuration, it cannot be turned on in .htaccess.

This issue has been fixed with 5.0.5 build 1. it has been published.

I think we should just match Apache's behavior. It is an issue of a default vhost when only IP are access.

It sounds like something we need to look into. Is temp root access to the server available?

When LiteSpeed block CloudFlare IP, CloudFlare will show that error page as it cannot get the page from original server.

With 5.0 or 4.2? have you add Railgun server IP as trusted IP? It requires a trialing "T" like "xx.xx.xx.xxT". It should never be blocked if in the trusted list.

Looks like we need temp root access to trouble shoot what is the root cause of it.