Search results

It can only be customized per user account, not possible to be per sub-domain.

Please send us the detail on how to reproduce the problem along with temp root access to the server.

If you have tried NULLed LSWS on that server, that server is likely being blacklisted by our system. Please send in your IP for verification.

We need more details in order for us to investigate. It will be a lot easier if it could be reliably reproduced. There is no code changes in 4.0.18 directly related to .htaccess file handling.

It is harmless, fixed in the updated 4.0.18 build.

please try the updated 4.0.18 build.

can you double check that it is correctly configured under subdirectory? spell, .htaccess file name, etc. If it is, we may have to try to reproduce it in our lab. Is the subdirectory document root of a subdomain?

Yes, it is in our RC3 build. You can just change the version number in the download link to try it.

Please try changing the order in /home/user/public_html/.htaccess that's the only place where index.php is in front.

It is not possible. same with apache.

For each user account, only one set of PHP suEXEC processes will be created, it wont be per subdomain. So, the document root of the first vhost, usually the main vhost, will be used for the PHP suEXEC environment. PHP suEXEC is not per subdomain, but per user account, it is to avoid creating...

solution now, is to use a "chain" secrule to exclude URL "/cgi-sys/suspendedpage.cgi"

SecRuleRemoveById is not support in 4.0.x, will be supported in 4.1

Looks like some required PHP modules are missing, you need to compare the phpinfo() page from the working Apache installation with LSWS installation. rebuild PHP accordingly. You need to check the complete error message in the error log below An easier way to migrate from Apache is to install...

Looks like a bug with handling rule actions. you add actions to those rules, without "deny" action, lsws default to allow, while apache may use SecDefaultAction. You can explicitly add "deny" to the rule action for now.

Litespeed can take both, apache cannot.

Which version of PHP you build with easyApache? Can you check if there is any PHP source code directory under /home/cpeasyapache/src ? It should have the PHP source code. It should be 5.2.11 if you select 5.2.11 when run easyApache. check the version number reported by "/usr/local/bin/php -i"...

You can enable modsec debug log (in error_log), then try the rule, if 404 is return, it wont trigger the rule, make sure the file is there. if security rule is not triggered and the file is there, please send us the modsec log entires.

Digging a little bit deeper on this, came cross http://www.eyrie.org/~eagle/notes/rpath.html I think something wrong with RPATH built into the binary, it can be checked with readelf -d lsphp5 | grep RPATH If somehow /usr/lib(64) got into RPATH before /opt/xml/lib, it could cause wrong...

just use plain proxy to talk to backend servlet engine.