Search results

Vhosts defined in LSWS console should have higher priority. You can turn on debug logging, it should show which file/directory is accessed.

I will take a look when I get a chance.

php.ini need to be updated to include the xcache configuration.

"bt" command of GDB will list the full callback stack.

It just the web console code check the availability of the file. You can manually change the configuration file.

Please PM me temp root access of your server, I can take a look when I get a chance.

Those are normal. You can ignore those messages. Yeah, we will add those to our to-do list.

for the 500 status code, please try adding "Status: 200 OK" header, see if it help. The changing MIME type does look like a bug. Is it possible that you send us a simple test application to reproduce the problem?

For RoR hosting in shared hosting environment, take a look at http://www.litespeedtech.com/support/wiki/doku.php?id=litespeed_wiki:rails_hosting PHP should work out of the box within RoR vhosts.

Are you sure it should be "4.0" instead of "4.01"? I think it should not affect the stylesheets, if you upgrade from earlier version, you may have to reload the stylesheet as previous version is cached by the browser.

How about add "staging" to the list, seems most people prefer this. Letting user input arbitrary text may open another can of worm. :)

Please check http://www.litespeedtech.com/support/wiki/doku.php?id=litespeed_wiki:apache:cpanel, You do not need to mess with other configurations for now if you want to use litespeed with cPanel. For setup PHP, http://www.litespeedtech.com/support/wiki/doku.php?id=litespeed_wiki:php:lsapi

It is not a good idea to let your customer process large file at will. It could bring down the server. There are many ways to limit this, in php.ini, in LSWS "Max request body size", etc.

If you want to use multiple ruby installation, you may have to use the manual setup with "dispatch.lsapi", you can specify path to ruby executable there.

Some browser caches the reply, so you have to clear your browser cache after change any configuration. Or, use a command tool to test it, like "lynx -mime_header ...", wget, curl, etc, all have command line option to show the response header, you can verify the content-type this way.

Please make sure to upgrade to the latest 3.3.3 release. If the problem persist, we have to login to your server and collect some useful debug information.

If you share the same user/group files among multiple realms, you will have this problem. If you use a dedicate password file with only the users that allow to access awstats in it, it will not be a problem.

3.3.3 has been released.