Search results

Are you sure that you are using the 4.0.5-ent package? not the standard version?

There should not any problem to POST to a CGI script. Are you sure your CGI script has not been served as static file?

Please follow the trouble shoot steps http://www.litespeedtech.com/support/wiki/doku.php?id=litespeed_wiki:php:lsapi#trouble_shooting Please try a simple phpinfo() page see if it works. If it does, you can try strace/truss/ktrace the lsphp5 process.

You can remove the listener to the DEFAULT vhost mapping.

Just check /path/to/lsws/DEFAULT/conf/vhconf.xml

cPanel's mod_auth_passthrough are supported in our 4.0.5 release, so FP will work properly out of box, no more fixing file/directory permission/ownership required.

After evaluating the situation, we decide to keep the current behavior, as under some situation, the symbolic link need to be solved early to avoid other troubles. And I think there is a easy solution to your problem. If you intended to use a file or directory beyond the $VH_ROOT, then avoid...

It does not matter, as long as the bot acts aggressively like the status page you posted, all of them will be blocked in short time once hit the connection limits.

Just limit the number of connections from each IP, LSWS will block IP that abuse the server automatically, no need to do anything extra unless you are hitting by a botnet with hundreds or thousands zombies.

Check if the PHP PECL extension that lsphp5 tries to load is the one newly built, or one the built earlier for another version of PHP. Another choice to upgrade your system level PHP installation to PHP 5.2.9, so it wont produce a PHP PECL extension with wrong API version.

"fork() failed" is due to the limit of processes allowed for VPS has been reached. If you use default LSWS configuration, it is not likely cause that problem. however, if you have tune some configurations to a high value that beyond what you VPS can handle, it could cause some problem. You...

I think we will make it match the behavior of that under a command line shell. I think it should match the old behavior. For the error and access log properties, we can make the change.

compare to the one in the installation package of 4.x release.

LSWS only can do the opposite, clone a vhost from template. if you start with template configuration to configure a vhost, clone a vhost can be easily done.

Please check if "RAILS_GEM_VERSION" has been set in environment.rb, has RailsRunner.rb has been updated to the one in 4.x release.

Right now, LSWS dereference symbolic early, end up with a result like that. We will check and find the best way to accommodate all situations.

What happened? You can switch back to 4.0.x release from command line easily. Have updated the 4.1RC1 build to address a bug this afternoon.

It should work the same way as Apache as LSWS stop buffer the request body when large upload was detected.

Have you done other upgrade besides upgrading LSWS from 4.0.x to 4.1RC1? If it results in 503 error, it indicates trouble. I do some code comparison between two releases, see if I forgot update any thing in 4.1RC branch.

LSWS can limit the number of connections from one IP, once over the limit, all future connection requests will be dropped, so this type of attack wont affect LSWS.