How-to: cPanel to DA migration

The migration tool seems to work great overall. Thank you. I've migrated about 50 accounts so far with great success

The one issue I just noticed is that email account quotas are not being restored. All email accounts appear to be restored as "unlimited" regardless of their quota on the cPanel server. Is this a bug or something that just isn't being done? It should be possible to parse the mailbox quota from the first line of the maildirsize file in each account, if a quota is set.

Also I noticed that /usr/local/directadmin/scripts/add_email.sh will never write a quota if the quota file does not already exist. Possibly this is where the issue is happening because on my restored accounts there is no /etc/virtual/<domain>/quota file at all. If the restore is using that script to create the email accounts, there will never be a quota file created. It looks to me that the
if [ -e ${QUOTA} ]; then

needs an
Code:
else
        echo "${EMAIL}:${QUOTAVAL}" > ${QUOTA}

So the file gets created with the first entry if it doesn't exist.

Thanks,
Ron
 
@capalon it doesn't use add_email.sh for that. Do you have any quota set in /etc/virtual/domain.com/passwd file?
 
@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
 
Does cpmove tarball has MAX_EMAILACCT_QUOTA variable defined in cp/username ? As that's the place where the converter script takes the quota from. I could review your sample cpmove file if you'd like me to :)
 
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.
 
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
 
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:

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.
 
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.

Just send me a cpmove file with email limits and I'll fix it in the script. Thank you!
 
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:

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.

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.
 
Hi all... I am a total noob at moving emails from server to server. I can usually do it with no issue if the new email accounts are in the DA account. (in the maildir folder). But they are not showing up after I have created them in the new account on the DA. (I have a request into the support for my server provider, but they take forever to answer and fix)..

So I guess my first question is.... does the name of the email account (ie: Maureen) show up in the MailDir folder under the domain it was created in as soon as it is created? And if it doesn't, am I correct in thinking that my server support team needs to fix this first?

Thank you for your patience and understanding.. AND if there is an answer in another topic, please let me know.. (trying to figure this out on my own.. thanks again)

(original emails in cpanel going to new account on DA)

>M<
 
It would be an additional domain added to my main domain (reseller account). The others were OK since there weren't any emails to move. I have 3 domains with multiple email accounts (including folders in each) to be moved. I've deleted email accounts no longer needed.
 
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.
 
Is it main user account? Or additional one?
It would be an additional domain added to my main domain (reseller account). The others were OK since there weren't any emails to move. I have 3 domains with multiple email accounts (including folders in each) to be moved. I've deleted email accounts no longer needed.
 
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.
 
-Will my Laravel installations have any issue with the migration?
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.

-Is there a limit regarding the backup file size. I have an account 30GB all emails. Will this be a problem?

No problems, if you have enough of space.

-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?

Yes, they should still work, but, as mentioned in laravel case - there is still a chance :)

-Will my DNS zone records be updated automatically?

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.

-Are cron jobs also moved or they have to be made manually?
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?
 
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?
Same version would be selected if it exists on DA server.
 
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?
Restoration progress is a part of 1.60 of DA.
 
Back
Top