How-to: cPanel to DA migration
- Thread starter smtalk
- Start date
@smtalk All lines in the passwd files have bytes=0M unless I've manually modified the email account limits in the web GUI.
Based on what I saw in the add_email.sh script, I've written a script that logs back into the old cPanel server, and reads the maildirsize file for each email account. I run it right after the backup is restored in DA, and it writes the quota entries to the /etc/virtual/domain.com/quota file. I did not know that there was a quota in the passwd file also since that isn't done in the add_email.sh script when it writes to the passwd file.
I just found that if I now run
echo "action=rewrite&value=email_passwd&user=USER" >> /usr/local/directadmin/data/task.queue
after writing the quota file, that it will update the passwd file to have the correct quotas. Once I do that it looks correct.
For what it is worth, I'm completely new to DA and liking it so far, but struggling to find what I can be sure is up-to-date/accurate info in a lot of cases when searching the forums, knowledgebase, and version feature history. There seems to be a lot of information available, but is difficult to know whether it is still valid or not. It seems like the add_email.sh script is a bit outdated.
It appears I have a functional workaround based on what I have written, but it would of course be better if the restore handled it directly so it works for everyone else. I'd like to get this working before I get to my larger accounts.
I'm willing to do whatever testing or debugging you need to help sort this out within the cpanel to DA process, and am comfortable with C/C++, PHP, BASH, and several other languages, if you tell me where to look and everything that needs to be done.
Regards,
Ron
Based on what I saw in the add_email.sh script, I've written a script that logs back into the old cPanel server, and reads the maildirsize file for each email account. I run it right after the backup is restored in DA, and it writes the quota entries to the /etc/virtual/domain.com/quota file. I did not know that there was a quota in the passwd file also since that isn't done in the add_email.sh script when it writes to the passwd file.
I just found that if I now run
echo "action=rewrite&value=email_passwd&user=USER" >> /usr/local/directadmin/data/task.queue
after writing the quota file, that it will update the passwd file to have the correct quotas. Once I do that it looks correct.
For what it is worth, I'm completely new to DA and liking it so far, but struggling to find what I can be sure is up-to-date/accurate info in a lot of cases when searching the forums, knowledgebase, and version feature history. There seems to be a lot of information available, but is difficult to know whether it is still valid or not. It seems like the add_email.sh script is a bit outdated.
It appears I have a functional workaround based on what I have written, but it would of course be better if the restore handled it directly so it works for everyone else. I'd like to get this working before I get to my larger accounts.
I'm willing to do whatever testing or debugging you need to help sort this out within the cpanel to DA process, and am comfortable with C/C++, PHP, BASH, and several other languages, if you tell me where to look and everything that needs to be done.
Regards,
Ron
MAX_EMAILACCT_QUOTA=unlimited is in the cp/username file, but that isn't the email account quota for any of the accounts. That's the maximum that is allowed for the end user to select for an email quota, hence the MAX designation.
By this, are you implying that all mailboxes will be set to MAX_EMAILACCT_QUOTA instead of their actual individual quota in the cPanel account? That wouldn't be the correct behavior as none of the email accounts in this cpmove file have an unlimited email quota. Even if it was set to 750MB or something specific it would not be the correct behavior to set all email accounts to the same quota. Very few of my customers have the same quota on every mailbox. This particular account has most mailboxes with a quota of no more than 100MB, and one is set to 750MB. It sounds like at best I would get all mailboxes set to 750MB if all are set to MAX_EMAILACCT_QUOTA.
By this, are you implying that all mailboxes will be set to MAX_EMAILACCT_QUOTA instead of their actual individual quota in the cPanel account? That wouldn't be the correct behavior as none of the email accounts in this cpmove file have an unlimited email quota. Even if it was set to 750MB or something specific it would not be the correct behavior to set all email accounts to the same quota. Very few of my customers have the same quota on every mailbox. This particular account has most mailboxes with a quota of no more than 100MB, and one is set to 750MB. It sounds like at best I would get all mailboxes set to 750MB if all are set to MAX_EMAILACCT_QUOTA.
I'm finding good success with this script except for 1 caveat:
When a domain has a subdomain setup, it seems cPanel created the directory originally with permissions set to 0750 (no permissions at all for other users). This causes apache to fail to load the subdomains as it cannot check for and read a .htaccess file. Setting the permissions to match other folders (0755, read and execute for other users) fixes the issue. Might be worth having the script check the permissions on the folders inside public_html
When a domain has a subdomain setup, it seems cPanel created the directory originally with permissions set to 0750 (no permissions at all for other users). This causes apache to fail to load the subdomains as it cannot check for and read a .htaccess file. Setting the permissions to match other folders (0755, read and execute for other users) fixes the issue. Might be worth having the script check the permissions on the folders inside public_html
I see the permissions issue was addressed on earlier pages and was due to mod_ruid2. Seems the search function on these forums doesn't work well, because I had searched for it previously and found no results (and still don't) when searching this thread only for "subdomain" even though that is used in many posts.
I have an account which completely failed to transfer properly. It didn't copy the majority of the folders/files in public_html and didn't set up any of the subdomains. The only thing it complained about in the error.log was one instance of it refusing to move files over due to them already existing. I'm not sure how to provide debug information to fix the script without sharing a lot of private data, so if you'd like some info let me know what to send. I verified the cpmove archive was complete. Here's what it complained about:
I assume this was due to the subdomain having a folder that doesn't match, but neither the track nor track2015 folders made it.
I have an account which completely failed to transfer properly. It didn't copy the majority of the folders/files in public_html and didn't set up any of the subdomains. The only thing it complained about in the error.log was one instance of it refusing to move files over due to them already existing. I'm not sure how to provide debug information to fix the script without sharing a lot of private data, so if you'd like some info let me know what to send. I verified the cpmove archive was complete. Here's what it complained about:
Code:
WARNING! track.domain.com path was set to custom in cPanel: public_html/track2015
WARNING! Not moving custom track.domain.com path public_html/track2015 to DirectAdmin location, because public_html/track folder also exists in public_html.I assume this was due to the subdomain having a folder that doesn't match, but neither the track nor track2015 folders made it.
Just send me a cpmove file with email limits and I'll fix it in the script. Thank you!
If it had a 'domain pointer' - I guess data could be in another folder. I could check it directly on your server, or in cpmove file.
Seems it actually failed due to the sever running out of disk space in the middle of the process. Resolving that and it seems everything migrated successfully.
The only other issue I have found is that cronjobs which use a cron "nicknames" (eg @weekly) do not copy over as well as commented out ones. I can understand why it'd skip comments, but the ones using nicknames should be copied.
Hello to everyone,
I am a cpanel user and I want to move to DA. Since I am not very experienced I have a couple of questions.
-Will my Laravel installations have any issue with the migration?
-Is there a limit regarding the backup file size. I have an account 30GB all emails. Will this be a problem?
-Some accounts a have changed the default root folder of cpanel from public_html to another folder. Will the migration script take this into consideration?
-Will my DNS zone records be updated automatically?
-Are cron jobs also moved or they have to be made manually?
Thank you in advance for your help.
I am a cpanel user and I want to move to DA. Since I am not very experienced I have a couple of questions.
-Will my Laravel installations have any issue with the migration?
-Is there a limit regarding the backup file size. I have an account 30GB all emails. Will this be a problem?
-Some accounts a have changed the default root folder of cpanel from public_html to another folder. Will the migration script take this into consideration?
-Will my DNS zone records be updated automatically?
-Are cron jobs also moved or they have to be made manually?
Thank you in advance for your help.
They might, due to custom document root, but you could set the same one to be used in DirectAdmin too after the transfer (easy to do). You may give it a try with a single domain.
No problems, if you have enough of space.
Yes, they should still work, but, as mentioned in laravel case - there is still a chance
It depends on where you host your DNS zones. If nameservers are pointing to DirectAdmin server - yes, the zones will be taken. If not - they'd need to be updated on the server you manage DNS.
They'll be transferred.
They might, due to custom document root, but you could set the same one to be used in DirectAdmin too after the transfer (easy to do). You may give it a try with a single domain.
No problems, if you have enough of space.
Yes, they should still work, but, as mentioned in laravel case - there is still a chance
It depends on where you host your DNS zones. If nameservers are pointing to DirectAdmin server - yes, the zones will be taken. If not - they'd need to be updated on the server you manage DNS.
They'll be transferred.
Very helpful, thanks again.
Regarding PHP, some of my accounts have different PHP versions from the default, will this be the case in DA as well and will the php.ini files work the same way?
I have only migrated a few CP accounts to DA but soon thousands will follow. Is it possible to visualize the import process (like a CB update) so that we can see what exactly was done (like CP transfer tool), without an output we've no idea if it worked or not. Is there a log that is written?
Same version would be selected if it exists on DA server.
Restoration progress is a part of 1.60 of DA.
Nice, any features id yet?
Last question, I hope, can I keep the same nameserver as my cpanel?
In other words will I be able to setup the DA server without the actual domain pointing to its IP?