Virtualmin replication fails...

Cloudmin master: Cloudmin 8.3 Pro, Webmin 1.780, Ubuntu 14.04.2 Virtualmin host: Virtualmin GPL 4.18, Webmin 1.780, Ubuntu 12.04.3 Virtualmin replica: Virtualmin GPL 4.18, Webmin 1.780, Ubuntu 14.04.2

When I initiate a manual replication, it runs for quite a long time and then dumps out a bunch of output. In summary, it says it failed. I dig through the output and find the failure:

Extracting TAR file of home directory .. .. TAR failed! /bin/sh: 1: cd: can't cd to /home/example/domains/example.com

(example & example.com are obviously placeholders to protect the innocent)

Lo and behold, the domains directory is not on the replica machine. Is this directory not getting tarred up when the domain is backed up on the virtualmin host?

As a test, I tried to do a manual backup off the domain and download the tarball to my machine, but got this error:

Backup failed : Failed to open /home/example/domains/example.net/.virtualmin-src for writing : No such file or directory

Note that example.net is an alias of example.com. Is this indicative of the issue?

Status: 
Closed (fixed)

Comments

When configuring replication, did you select both the parent example.com domain and the example.net alias?

I told it to replicate "All virtual servers"

If you tell it to replicate just example.com , does that work?

I did several tests and here are the results:

  • example.com: worked
  • example.com and example.net: failed with the same error as doing all the domains.
  • example.com and example1.com:failed like above.
  • example.net: failed like above

Note: example1.com is another domain alias of example.com.

So in the case where you get an error like /home/example/domains/example.com , what is the top-level domain that owns /home/example ? Also, do you have any custom home directory path setup in Virtualmin on the source or destination system?

The example.com domain owns the user example. I created a top-level domain example.com (and the user example) and then later created alias domains (example.net, example1.com).

Ok, I think the issue here is that Cloudmin is doing the replication the wrong order - it needs to replicate parent domains first, so that the sub-domain home directories can be created. This will be fixed in the next release.

I am having trouble with the same issue for an alias, is there a way to change the order and fix it in the source code for the control panel? That way I can fix it and set it up to be completed. I am using this for replication, also does replication only copy the changed files or does it copy the entire directory every time it replicates? Thank you for the help.

I am now running Virtualmin 5.0 GPL, but this issue persists. Any new news to share?

One work-around would be to have two separate scheduled replications - one for the top-level domains, and another that runs a bit later for the aliases.

The problem is still there, even with the last version. But the problem isn't the order because on my server, the parent domain is replicated before the alias.... It looks like the "domain" directory isn't created when replicated an alias... Somebody have an idea why ?

Any chance we could login to your system to see what's going wrong here?

The problem seems to be only with domain alias. And it still appear. It's not a problem of replication order. The "domains" directory isn't created at all. Even if I manually create it on the salve server, when the replication of the "parent" domain occurs, the "domains" directory is removed.... I think the problem is the "domains" directory isn't forgotten during the replication.

Is it possible to correct it on a future version ?

Does the domains directory exist for the parent domain on the original (source) system?

Sorry that I have been out of touch for so long. I got bogged down with other things and just put this issue aside. I have picked it up again and rescheduled the replication. It continues to fail and here are two things it complains about:

Restoring backup for virtual server {ALIAS_DOMAIN} ..
    Restoring virtual server password, quota and other details ..
    .. done

    Extracting TAR file of home directory ..
    .. TAR failed! /bin/sh: 1: cd: can't cd to /home/{PARENT_DOMAIN}/domains/{ALIAS_DOMAIN}


Re-starting DNS server ..
Use of uninitialized value $bind8::config{"restart_cmd"} in string eq at /usr/share/webmin/bind8/bind8-lib.pl line 2074.
.. done

With respect to the first issue and in answer to your last question, the "domains" directory does exist for the parent domain on the source system, however it has no contents.

Regarding the BIND issue, I'm not sure what that's about; perhaps it's a red herring for now. If you have a suggestion on it, it would be welcome!

The BIND issue is harmless, but I'll fix it in the next release.

However, the restore problem for alias domains is real. Are you running the latest (5.04) Virtualmin release?

Both source and destination are running: Webmin version 1.821 Virtualmin version 5.04

The only difference is that the source is running Ubuntu 12.04 and the destination is running 14.04.

Can you check if the directory /home/{PARENT_DOMAIN}/domains exists on the destination system?

It does not exist, which makes sense because that's what the error message says. :-)

Wait, even the domains directory doesn't exist? That's surprising ... however, I will add some extra code to handle this case in the next Virtualmin release.

Status: Active » Fixed

Woo hoo. Do you have a targeted release timeframe?

Alternatively, could I run a "nightly build" or something?

We can send you a beta with the fix if you like?

Ok .. is the problem system running Virtualmin GPL or Pro, and on which Linux distribution?

Virtualmin GPL with 12.04 on the source and 14.04 on the destination.

I've emailed you an updated Debian package

I have installed the package on the source and destination systems. Things seem to be working. At least, I'm not getting any failure emails.

Is there a log file somewhere that would capture these types of scheduled events?

You should get email if a scheduled replication fails.

Yes -- I know. I am looking for a log that has all of the events. I am a glass-half-full sort of guy and would like to be able to verify things. :-)

Sorry, but there is no such log in Cloudmin currently.