Please whitelist cPanel in your adblocker so that you’re able to see our version release promotions, thanks!

The Community Forums

Interact with an entire community of cPanel & WHM users!

The remote server didn't report a correct md5sum of the archive.

Discussion in 'General Discussion' started by randomuser, Jun 25, 2005.

  1. randomuser

    randomuser Well-Known Member

    Jun 25, 2005
    Likes Received:
    Trophy Points:
    Hi, I started a multiple account transfer earlier, and only a handful of the accounts successfully transferred before receiving the error in the title. I googled the error and found that what some people are doing for a solution is to use /scripts/pkgacct to create the tarball of the user account, then scp the file to the new host, then /scripts/restorepkg on the tarball in the /home dir on the new server.

    I wish I was able to find some legitimate cPanel documentation on these commands. Perhaps it exists in a place I am not looking (google, the cPanel/WHM documentation, these forums, etc).

    I need to get some accounts copied. My question is this: if I run /scripts/pkgacct <username>

    will that have ANY affect on the current users' directory? I do not want this site to be unoperational. While I could read the 1636 lines of "pkgacct" myself, I think it would be more sensible to ask here first.

    Please someone let me know if the following should be sufficient (this is what I have gleaned from google and a few forum posts - again, documentation would be nice, a little too easy perhaps):

    1. On the host with the existing website / databases / etc:
    /scripts/pkgacct username

    2. Then scp the cpmove-username.tar.gz to the new host, to the directory /home

    3. Then, on the new host,
    /scripts/restorepkg username

    That will not disrupt anything on the existing host, and will create the new user account on the new host, correct? If there is anything I am missing, please do let me know. Thank you.

    edit: OR for 3, I could do a Restore a Full Backup/cpmove file on the new host

    more edit: neither host is FBSD - both are Linux

    final edit: I am going to try the 2 step plan detailed here (thanks for that, blueandwhiteg3)
    #1 randomuser, Jun 25, 2005
    Last edited: Jun 25, 2005
  2. dalem

    dalem Well-Known Member PartnerNOC

    Oct 24, 2003
    Likes Received:
    Trophy Points:
    cPanel Access Level:
    DataCenter Provider
    wont disrupt a thing

    and you can use either method posted to restore
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  3. Well-Known Member

    Feb 24, 2005
    Likes Received:
    Trophy Points:
    Sidman, PA

    Wow, we just had this issue last night - spent 9 hours with account transfers.

    Make sure that for ssh, root logins are enabled, port is 22, and I'd recommend disabling any firewalls on both servers. It worked for us.
  4. randomuser

    randomuser Well-Known Member

    Jun 25, 2005
    Likes Received:
    Trophy Points:
    Hi, thanks all for your replies and reassurance. 9 hours omg! I'm sorry to hear that, I know what a pain the process can be when done manually - it is definitely time consuming. I used a hybrid combination of the following:

    Method 1

    Log into the user's site via cPanel and create a backup in their home dir

    Since cPanel doesn't tell you when the backup is complete (I watched one backup screen for a while, and ultimately just looked in the user's /home directory to see that the temporary backup_date_whatever directory had disappeared, and the backup tarball was no longer growing in size), I just kept an eye on the tarball and scpd it to the new host. (You have the scp option already available, but for whatever reason I scpd it manually - don't ask :)

    Logged into the new host via WHM and did a backup restore

    Method 2 (for a few sites that were not in DNS (because they don't even exist) and for a couple other sites that were not up or I was not able to connect to cPanel

    On the current host, run /scripts/pkgacct username

    scp the new tarball in /home to the new host

    Run the backup restore utility from WHM on the new host (probably could've just run /scripts/restorepkg, but I didn't try as the other method was already working fine)

    The only thing that leaves me wondering is, what on earth is the difference between /scripts/pkgacct and /scripts/pkgacct2 ? I might take a look at them both and try to figure it out. I stuck with pkgacct throughout the process because I saw it mentioned more on these forums than pkgacct2.

    So, I hope this information helps someone. Basically I just gathered it from google and other posts here on the forums anyway, so it's nothing new really. Someone else already posted a handy bash loop in another thread a la

    [user@host /home]# for accounts in `ls /home` ; do /scripts/pkgacct $accounts ; done

    or something similiar, and I believe a handy bash loop for /scripts/restorepkg on the new host. Of course this is only if you want to do every single account in /home. Another way that I will definitely do next time, is to make a file with a list of the accounts to be transferred, and do the bash loop a la: for x in `cat file` ; do /scripts/pkgacct $x ; done
    and something similiar on the new host after the files have been scpd. An expect script maybe could be used to scp the tarballs to the new host. This seems to me like the entire process almost could be automated. The only downside is, if something goes wrong during pkgacct or restorepkg. This would obviously need to be watched very closely I guess.

    Thanks again, sorry for opening another thread on the issue, as I know it has been covered before. Just wanted to make sure I was moving in the right direction.

    edit: I'm glad I used pkgacct and not pkgacct2 :D I really should have examined them both before doing anything, however. One difference I see has something to do with copying a resellerconfig (pkgacct does this, pkgacct2 does not). Works for me.
    #4 randomuser, Jun 25, 2005
    Last edited: Jun 26, 2005

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice