[BlueOnyx:19062] Re: Help! emu data issue

[Michael Stauber]

Hi Jeff,

> [root at mail home]# /usr/sbin/cmuImport -a -d /home/export/home/data/
> Reading config file: /etc/cmu/cmuConfig.xml
> LogFile location is /home/cmu/cmu.log
> We exported 0 vsites, 0 users, 0 lists
> Subroutine Compress::Zlib::gzFile::gzseek redefined at /usr/lib64/perl5/Compress/Zlib.pm line 219.
> 
> ===> Checking Virtual Sites <===
> ===> Checking Users <===
> Creating virtual site: www.copyzone.net
> Creating user: selfserve-mac
> restoring archive for selfserve-mac
> Creating user: jmaldonado
> restoring archive for jmaldonado
> sh: -c: line 0: unexpected EOF while looking for matching ``'
> sh: -c: line 2: syntax error: unexpected end of file
> ScanIn: Can't use string (201 OKsh: -c: line 1: unexpected EOF while looking for matching `"'
> sh: -c: line 2: syntax error: unexpected end of file
> sh: -c: line 0: syntax error near unexpected token `)'
> sh: -c: line 0: `echo -n "ScanIn: ") as a HASH ref while "strict refs" in use at /usr/cmu/perl/Archive/Tar.pm line 625.'
> [root at mail home]# 
> 
> What can I do? I’ve tried to use the data directly from the external drive, too. Same problem.

That error can happen for a couple of reasons. During unpacking of the
tarball for user selfserve-mac of Vsite www.copyzone.net CMU did run
into an error.

Possible causes:

- CMU did run out of memory
- Unpacking failed due to disk quota issues
- Tarball was corrupted

The likely cause is disk quota issues. Like the user using more
diskspace than allocated for the entire Vsite. That's one of the reasons
why the CMU Migration guide suggests to make sure that Users and Vsites
aren't over quota before you do a CMU-Export:

http://www.blueonyx.it/index.php?page=cmu-migrations

Check how big that tarball is. See if you can unpack it manually to see
if it's corrupted.

In your case I would also suggest to import the Vsites (and Users) via
CMU one by one.

Example:

/usr/sbin/cmuImport -a -n "www.copyzone.net" -d /home/export/home/data/

You can tell it to import multiple selected Vsites, too. In that case
separate the Vsite names by coma. Doing them one by make sure that you
can continue the cmuImport after a hard failure. Because then you know
exactly where it tripped and can work around Vsites (or Users) on which
the import choked.

If it's just this one Vsite that doesn't import correctly, you can then
cmuExport just this Vsite on the source server again and then only
import this one missing Vsite anew on the target box.

Or you could call cmuImport with the -c switch. That would create the
Vsite and it's users with their configurational settings, but won't
import their tarballs. So import the Vsites that can be imported without
hitch and for the rest (where cmuImport fails) either do a new export
after fixing their quota issues, or import with the -c switch and move
their data manually.

-- 
With best regards

Michael Stauber