Search results

CyberPanel uses the package from https://rpms.litespeedtech.com/debian/pool/main/jammy/ Which version is lsphp81-ioncube_12.0.5. I will forward the update request(ioncube 13) to our build master but no ETA. To get the version now, you might want to build it on your own, or wait for the new...

Possibly our dev has some issues that need to be checked. You can still use 1.7.19 and lsup to v.1.8.0 or even 1.8.1 as a temporary solution.

Try putting the following rules on the top of your .htaccess file, graceful restart OLS, and see if it works. RewriteCond %{HTTPS} !on RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI}/$1 [R,L]

I didn't test it, the first two rules look ok to me but 3&4. If you check the log, is the rule being hit?

You might need to edit the listener as well. For wildcard, you might want to check this post from CyberPanel forum https://community.cyberpanel.net/t/how-to-set-up-wildcard-ssl-on-cyberpanel-openlitespeed/30652

okok, not sure what's the old command you ran, but this one is correct.

It seems working fine. So what and how did you fix the issue?

No problem.

You are right, can not just include it in the server config file, need to include it in the virtual host config file.

Maybe it's similar to this issue? https://stackoverflow.com/questions/9866597/uploading-php-files-via-ftp-all-linebreaks-and-crs-are-lost-upon-upload

Hi, I can't reproduce it, could you run the following and share the output? sudo wget -O - https://repo.litespeed.sh | sudo bash -x

Thank you for being so patient, the build master will prepare it when available, but no ETA.

Good. If subdomain.A.com:8088/index.html loads fine, but subdomain.A.com:8088/, then it's auto index problem. But you mentioned subdomain.A.com returns a 404, which is probably a domain mapping issue on the listener, have you map the domain on port 80/443?

Do you have port 8088 allowed on the server? :unsure:

The config looks right. If you visit HTTP://subdomain.A.com:8088/index.html directly, does it return 200 ok, or 404 not found?

Can you compare the file size before/after upload to the server? If it's uploaded via the FTP, then it sounds not web server-related.

Thanks for the report, we have received the issue and it should be fixed in the next build.

Check access logs and see if there's any unusual traffic during that time.

Have you set up document root in the subdomain's virtual host?

If the site relies on PHP heavily, 120 is ok.