Search results

5.4.1 build 4 will be able to use 022 and parse it as octal numbers. you can try the debug build now. /usr/local/lsws/admin/misc/lsup.sh -d -f -v 5.4.1

it is a bug in LSWS parsing the value using base 10 instead of base 8. will be fixed in 5.4.1 build 4.

It could be done, but not necessary. OLS can save compressed version into its cache, and automatically update the cache if original file changes. It works better than manually create the compression cache for static file. It is fully automatic. :)

Which directory has ownership problem? Is it from our update script? or was changed manually?

is admin_php running as "lsadm" user? lsws/admin permission is like does file /usr/local/lsws//admin/tmp/sess_5eb82f48d749e76982605bd32e6a8383 exits?

those session files under /usr/local/lsws/admin/tmp/ should be owned by lsadm:lsadm with permission 0600 /usr/local/lsws/admin/tmp/ itself should be owned by lsadm:nobody with permission mask 0710. , please check if those permissions has been changed.

What server are you using? LSWS? OLS? updated to latest version? Will you get the same result if you bypass cloudlflare?

Please update to 5.4.1 build 3. /usr/local/lsws/admin/misc/lsup.sh -f -v 5.4.1

For some reason, failed, it should return 66.249.73.91 .

Please try a full stop/start. service lsws stop service lsws start

make sure you turn off "QUIC" under server->tuning tab. it should disable the alt-svc header.

To our experience, invisible reCAPTCHA is not as reliable as the checkbox one, especially with non-chrome browser. It is pretty much a google reCAPTCHA script issue, we only change the type.

Looks something is going on, which browser has problem? chrome? firefox? It could be a problem with QUIC v46 support if it only happen to chrome. try disable QUIC in webadmin server -> tuning -> QUIC .

try a full stop/start

If only available, will it serve RSA cipher? You can try making an extra copy to see if it load the RSA key. check if any error during server startup. for the HTTP/1.1 fall back, I think it is an ALPN handshake problem for some reason. Maybe the h2load rpm only build with NPN, without...

Using VPN will cause the packet being routed through extra hop, increase the latency. VPN could have lower bandwidth than direct connection. whethere QUIC over VPN can be faster than TCP over VPN, it depends. but performance is not the determine factor to use VPN or not.

For people encountered similar problem, the 400 bad request is due to request header size limit has been changed to 4096, which is lower than the size of XHR request. raise the limit solved the problem.

you can try remove to clean up SHM files. then restart OLS.

Please turn on full debug logging, reproduce the 400 bad request, send the log to bug @ litespeed... for analysis.

if you can submit a ticket to cPanel, they probably have better solution for this. To me, you can try switching PHP handler from php-fpm to suphp or CLoudLinux mod_lsapi temporarily, see if that can trigger cPanel to update all .htaccess. If it does, then switch to litespeed. If it does not...