Skip to main content

Moving all sites - multiple nameservers

Comments

12 comments

  • TechAmigo Support

    Hi Alistair,

    We'll provide you the best practice and step by step instructions of migration process.

    We can divide the whole process into 2 phases.

    The first phase includes initial transfer and testing

    1. Transfer all accounts with "Live Transfer" disabled
    2. Manually update DNS zone records on the new server to point to the new server's IP
    3. Test thoroughly on the new server using /etc/hosts file by adding the DNS testing like below

      1.2.3.4  domain.com  www.domain.com

    4. If you found any issues, fix it before DNS switch. Test it until it corrects.

    The second phase includes final sync.

    1. Lower TTLs further (you've already set to 600 - good!)
    2. Update glue records for your nameservers
    3. Do a final sync - this time you can use "Live Transfer" for accounts that changed
    4. Monitor propagation using online tools or commands like dig


    Regarding Resellers, communicate the migration schedule precisely and provide them with the new server IP addresses in advance.

    Regarding Email issue, transfer the email accounts but don't point MX records until final sync. Also, please do note that, there will be slight email downtime window.

    Please write to us if you need anymore clarifications.


    Regards,
    TechAmigo Support

    0
  • cPRex Jurassic Moderator

    Yes - if you disable the Live Transfer function that will stop the immediate proxy between the two systems and it will turn into a more traditional migration.

    You can use the same nameservers as you just need to update the glue records at the registrar when you are ready to make the switch.  This type of migration results in no downtime as a user visiting a website will get directed to either the old or the new machine during the short propagation time.

    0
  • Alistair Mcintyre

    Thank you both for your detailed responses. This validates what I was thinking, so I am now confident to proceed.

    I did, however, run into another gotcha. One of the websites I had previously imported to the new server for testing... I later reverted to the old server, restored the DNS on the old server and terminated the account on the new server.

    I am now trying to import it back into the new server, but I get the following error...

    Error: You have selected 1 account that cannot transfer properly because its username conflicts with a username on the local server.

    • The remote account “usernamehere” cannot transfer because an account with the same username exists on the local server.

    I have 2 options: overwrite or deselect. If I choose overwrite, the transfer fails because the account doesnt exist.

    I suspect WHM/cPanel is holding a piece of the old account. Is there a way to purge this from the system?

    Thank you again!

     

    0
  • cPRex Jurassic Moderator

    Can you run this command to see if there is anything left of that account in the userdata/

    grep -Ri username /var/cpanel/userdata

    Just replace "username" with the actual cPanel username you're working with.

     

    0
  • Alistair Mcintyre

    Update:

    I was able to address this issue by manually creating the account using the exact same username in WHM, then deleting the account. I was then able to import the account from the other server.

    I guess something got hung up when I removed the account previously.

    Cheers!

    0
  • cPRex Jurassic Moderator

    It looks like we were typing at the same time :)

    I'm glad to hear that worked, even though I don't have a good explanation for exactly what may have happened.

    0
  • Alistair Mcintyre

    Yea very close timing...

    I did check the location you mentioned, and there was nothing referencing the user account. I also looked in MySQL just in case there was a database left behind (username issue) nothing there either.

    Error logs also appeared to be free of related errors. It's a mystery!

    Thanks again.

    1
  • Alistair Mcintyre

    You will be getting fed up with me and this awkward transfer :-) 

    New problem...

    When I select all accounts (deselect the few that I have already brought over for a test), then uncheck "live transfer" apply that to all accounts and hit "copy" accounts are failing...

    Streaming home directory from source server …
    receiving incremental file list
    rsync: opendir "/home/usernamehere/.HttpRequest" failed: Permission denied (13)

    The process hands for a long time. I then abort and retry with that account skipped, the same applies for other accounts.

    The dot file .HttpRequest does not exist. Is this something that resulted from my previous live transfer that was aborted?

     

    0
  • TechAmigo Support

    Hello  Alistair,

    This type of permission error is common and can happen due to several reasons.

    • Fix ownership and permissions of the specific file on source server

                    chown -R username:username /home/username/.HttpRequest
                    chmod 755 /home/username/.HttpRequest

    • Check and fix parent directory ownership and permission

                   chown username:username /home/username/
                   chmod 751 /home/username/

    • Temporarily disable SELinux and retry

                   sudo setenforce 0. 

             This change is temporary and will only last until the next system reboot.

    • Temporarily disable the user from cagefs via WHM or cli

               #check if CageFS is enabled

                    cagefsctl --list username

               #If CageFS is enabled, temporarily update the user

                    cagefsctl --update username

    Retry the transfer, if the issue still occurs disable it.

                # Disable CageFS for migration (temporarily)
                     cagefsctl --disable username

                # After migration, re-enable it
                     cagefsctl --enable username 

    Let us know if any of these works.


    Regards,
    TechAmigo Support

    0
  • Alistair Mcintyre

    I may have a rough theory as to why that happened. The hostname for the destination server is a subdomain (srv2.example.com) of a domain hosted on the source server. It seems the DNS did get altered even though live transfer was disabled. I also appear the destination server became unreachable during the transaction.

    This time, website DNS zones were not affected, but SSO (WHMCS to cPanel) stopped working...

    I was able to correct this by running...

    /scripts/restartsrv_cpsrvd
    /scripts/upcp --force

    Why am I getting all the strange, unexpected errors lol :-) 

    Alistair.

    1
  • quietFinn

    When I transfer accounts I always whitelist the source server's IP in the destination server's firewall, and the destination server's IP in the source server's firewall. If I don't do that I will have problems, especially if I use Live Transfer.

     

     

    1
  • Alistair Mcintyre

    HI again everyone, and thank you very much for your valuable input. I started fresh and finally got a block of sites moved over. The biggest issue was CloudLinux. When it creates an account, it starts restricting right away. My default install set the IO limit at 1mbps :-) I assumed it was a connection/data issue, but once I set that to "0" (no limit), things improved. Another possible reason for the move being a little slow was my choice to go RAID 1 in my main NVME drives. This will be lightning fast for serving pages, but writes, especially sequential writes, need to be done twice.. 

    The .HttpRequest dot folders.. I believe they are an artefact from a cPanel process. The problem is they are created as root (or a sudo user) the permissions are set in such a way then they can't be read or moved by other users. That's why rsync was failing. I removed these folders, they only appeared to be placed in resellers' apex accounts?

    Feeling happy now, I am finally getting somewhere. I should have spent a few weeks getting more acquainted with CloudLinux, instead of just seeing it at my provider and impulsively hitting "add to cart" lol

    Again, thank you for all the help and support, any further issues and I will need to annoy you again lol :-) 

    0

Please sign in to leave a comment.