openlitespeed - 404 error for restored users from backup

R

rock2019

New member
Joined
Dec 8, 2019
Messages
5
Hi,

I have a strange thing with openlitespeed, I have a fresh server just installed with directadmin.
My issue is when I'm creating a new user the website loads just fine when I restore the user from the backup the process is completed but I'm getting 404 error when I'm accessing the website.

I can see the configuration are fine, there is no htaccess which could affect this, if I'm trying to access the openlitespeed panel it says 503 service unavailable but the new create websites work just fine.

1. works with new create accounts
2. doesn't work when the account is restored from the backup file.

Any ideas?
 
Try
Code: 
cd /usr/local/directadmin/custombuild
./build update
./build clean
./build rewrite_confs
 
Was this backup from a working DA server with OLS or some other place?
 
Did you read through this? https://forum.directadmin.com/threads/how-to-cpanel-to-da-migration.58059/
Other things to take into consideration:
Click to expand...
* It's recommended to leave all the cpmove-user.tar.gz files on the system after restore. If there are bugs, or something goes wrong, it'd still be possible to recover that data.
* Like any software - there might be bugs there, if you notice any - please let us know, and we'll try fixing them as soon as possible.
* DirectAdmin supports a different feature set than cPanel. For example, DirectAdmin supports nginx/openlitespeed, MySQL8, rspamd etc., but it has no support for PostgreSQL or Ruby. So, if you have any sites using them - they'd need to be transferred manually.
* Max username length is 16 characters for MySQL users by default, and 10 for system user. Max username length can be increased in /usr/local/directadmin/conf/directadmin.conf. You can find max length of your username in cPanel easily:
Click to expand...

Did you have OLS on cpanel? I think the migration is supposed to be apples to apples. Not totally sure though I dont use OLS.
 
I'd suggest checking /var/log/httpd/domains/domain.com.error_log
 
bdacus01 said:
Glad you got it. Could you please post what you did?
Click to expand...
What I did extra was

/usr/local/directadmin/scripts/cpanel_to_da/cpanel_to_da.sh /home/admin/user_backups/cpmove-USERNAME.tar.gz /home/admin/converted_user_backup
chown -R admin. /home/admin/converted_user_backup
 
rock2019 said:
What I did extra was

/usr/local/directadmin/scripts/cpanel_to_da/cpanel_to_da.sh /home/admin/user_backups/cpmove-USERNAME.tar.gz /home/admin/converted_user_backup
chown -R admin. /home/admin/converted_user_backup
Click to expand...
Thanks
 
just the 404 error:

185.15.220.199 - - [04/Mar/2024:13:59:54 +0100] "GET / HTTP/2" 404 663 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36 Edg/122.0.0.0"
51.254.199.11 - - [04/Mar/2024:14:06:40 +0100] "GET / HTTP/1.1" 301 246 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:118.0) Gecko/20100101 Firefox/118.0"
51.254.199.11 - - [04/Mar/2024:14:06:44 +0100] "GET / HTTP/1.1" 404 1127 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:118.0) Gecko/20100101 Firefox/118.0"
37.11.228.94 - - [04/Mar/2024:14:17:57 +0100] "GET /quienes-somos/ HTTP/2" 404 663 "https://www.google.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36"
37.11.228.94 - - [04/Mar/2024:14:24:07 +0100] "GET /quienes-somos/ HTTP/2" 404 663 "https://www.google.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36"
37.11.228.94 - - [04/Mar/2024:14:24:12 +0100] "GET / HTTP/2" 404 663 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36"
37.11.228.94 - - [04/Mar/2024:14:26:02 +0100] "GET / HTTP/2" 404 663 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36"
37.11.228.94 - - [04/Mar/2024:14:26:03 +0100] "GET / HTTP/2" 404 663 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36"
37.11.228.94 - - [04/Mar/2024:14:26:04 +0100] "GET / HTTP/2" 404 663 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36"
 
Last edited:
mihosting said:
I have the same problem from a backup restored from jetbackup

any idea?
Click to expand...
this was a bug in 5.3.9 where jetbackup restores are disabling php/sll and remove the private to public symlink.

Update to 5.3.10 it is just released.

For current user that is not working check that php/ssl is turned on at the domain settings. Check symlink. And restart webserver.
 
Hello everyone!

We appreciate everyone's support for using JetBackup! This was a known issue where JetBackup would not properly backup the symlink between private_html and the public_html in the account's domains directory. Our latest release of JetBackup v5.3.10 ALPHA tier addresses this issue (JB5-DA #174). Please note that our standard release Cycle from EDGE to BETA then STABLE typically takes our team about a month each to promote releases between Tiers.

If you decide not to upgrade to JetBackup v5.3.10 Alpha Tier, here are some suggested workarounds:
  • If the admin account is re-named, the pre/post restore "Set to unlimited" before re-applying quotas at the end of the restore will run the MODIFY_USER calls as "root" which isn't permitted by the DirectAdmin API. To resolve this, it's possible to create a temporary "admin" account, but the admin account should be active for the API call to complete. - This will be resolved with case #JB5-DA-175
  • private_html symlink - due to a bug in the backup, the value for this setting is not being stored properly and will result in the private HTML directory being enabled. To resolve this, simply re-enable the private HTML symlink option from User Level > Domain Setup. - This will be resolved with case #JB5-DA-174
  • PHP/SSL/Redis may be set to "OFF" post restore - The pre-restore set all quotas to "Unlimited" does not set these to OFF, but due to the way the DirectAdmin API works, the absence of these values in the CMD_MODIFY_USER API call results in DirectAdmin setting User Feature to OFF. To resolve, re-enable any disabled user feature post-restore. - This will be resolved with case #JB5-DA-181
Hopefully, this will help resolve your issue! If the error persists, feel free to submit a ticket with our support team through the Client Area.

Best Regards,
JetApps Team.
 
You must log in or register to reply here.
Back
Top