Author Topic: cPanel to CWP7Pro Migration Name Conflict  (Read 2304 times)

0 Members and 1 Guest are viewing this topic.

Offline
*
cPanel to CWP7Pro Migration Name Conflict
« on: April 20, 2020, 05:10:35 AM »
Just wanted to put this out there for anyone else struggling to migrate accounts from cPanel to CWP via backups.

Here is my scenario:
- I have several cPanel backup files, and they are for two companies that have many domains of similar nature.
- CWP7 has an 8 character username limit, which is bypassed when migrating cPanel accounts.
- Account names, are often based off of domain names (or the first X characters of the domain).

Here is my problem:
If I restore a cPanel backup, and it's username / domain is something like "12345678cats.com".

I can NOT restore the next backup - that has the username / domain "12345678dogs.com".

Despite the two being different, CWP7 seams to search only the first 8 characters when restoring a cPanel migration backup file. I get the concept, check to make sure the account doesn't already exist. But said check is only checking on the first 8 characters! Causing the false message of "account already exists", and failing to complete the restore.

I would simply return to my old cPanel/WHM and modify the account/username (making sure the first 8 characters are unique and of no conflict). However, I'm in the middle of an unexpected migration, as I was given only a few hours before the hard drive on my old server destroyed itself. My current options are limited to manual restoration, or bypassing the check. I have made many attempts at sorting the conflict - with no resolution.

Long story short: Make sure your account usernames do not have identical characters for the first 8!




Offline
*
Re: cPanel to CWP7Pro Migration Name Conflict
« Reply #1 on: April 20, 2020, 07:19:39 AM »
We've had a problem and we knew it was happening.

We have many domains, some "similar", for example:

domaindogs.com
domaindates.com

It's the same for us, I think CWP should expand the maximum number of characters in the user's name.

Offline
*
Re: cPanel to CWP7Pro Migration Name Conflict
« Reply #2 on: April 20, 2020, 08:56:59 AM »
There is even worse problem, if you have two accounts with similar name, deleting one account also deletes mysql databases from other.
For example, 12345678.com and 12345678.net - if .net is deleted say goodbye to .com db-s.

Offline
*****
Re: cPanel to CWP7Pro Migration Name Conflict
« Reply #3 on: April 21, 2020, 10:13:16 AM »
how did you added 2 same user ?

Offline
*
Re: cPanel to CWP7Pro Migration Name Conflict
« Reply #4 on: April 21, 2020, 01:14:28 PM »
how did you added 2 same user ?

Actually it was not same user name. both domains are 11 characters long, one was imported with long name other was created and got assigned the short one. It happened when i was trying to clue out mysql backup problem.

Offline
***
Re: cPanel to CWP7Pro Migration Name Conflict
« Reply #5 on: April 21, 2020, 03:14:03 PM »
This seems like a very bad problem.  But what are the chances of having that situation on one server.  Very small I would say.

Offline
*
Re: cPanel to CWP7Pro Migration Name Conflict
« Reply #6 on: April 23, 2020, 04:43:22 PM »
This seems like a very bad problem.  But what are the chances of having that situation on one server.  Very small I would say.

I've been at this hosting thing for decades. I can honestly tell you that the above situation happens more often than you'd expect.

Just think: Every time you registered a domain, the registrar offers you every variation of that domain. And, most entrepreneurs tend to collect domains, owning many that start with the same subject. In my case, I'm inundated with domains that begin with the same 8 characters (and it's not by my own choice).  :P

All I'm trying to say is: The potential for this subtle nuisance to happen, is far greater than expected. I do agree that it's really not the most critical problem ever. As I was able to manually re-create the offending account(s). Which was just rather time consuming and tedious.

It is more like a small bug, in which I hope the dev's can tackle in the upcoming months. Or perhaps consider putting some info in the (rather dusty) documentation.