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?
Comments
Submitted by JamieCameron on Sat, 01/02/2016 - 13:02 Comment #1
When configuring replication, did you select both the parent example.com domain and the example.net alias?
Submitted by mlbarrow on Sat, 01/02/2016 - 13:09 Comment #2
I told it to replicate "All virtual servers"
Submitted by JamieCameron on Sat, 01/02/2016 - 17:53 Comment #3
If you tell it to replicate just
example.com
, does that work?Submitted by mlbarrow on Sat, 01/02/2016 - 18:32 Comment #4
I did several tests and here are the results:
Note: example1.com is another domain alias of example.com.
Submitted by JamieCameron on Sat, 01/02/2016 - 23:13 Comment #5
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?Submitted by mlbarrow on Sun, 01/03/2016 - 13:01 Comment #6
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).
Submitted by JamieCameron on Sun, 01/03/2016 - 19:05 Comment #7
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.
Submitted by ccsdapps on Wed, 02/17/2016 - 19:23 Pro Licensee Comment #8
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.
Submitted by mlbarrow on Thu, 02/18/2016 - 11:04 Comment #9
I am now running Virtualmin 5.0 GPL, but this issue persists. Any new news to share?
Submitted by JamieCameron on Thu, 02/18/2016 - 17:04 Comment #10
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.
Submitted by versantweb on Mon, 08/15/2016 - 11:17 Pro Licensee Comment #11
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 ?
Submitted by JamieCameron on Mon, 08/15/2016 - 22:23 Comment #12
Any chance we could login to your system to see what's going wrong here?
Submitted by versantweb on Tue, 08/16/2016 - 02:40 Pro Licensee Comment #13
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 ?
Submitted by JamieCameron on Tue, 08/16/2016 - 23:59 Comment #14
Does the
domains
directory exist for the parent domain on the original (source) system?Submitted by mlbarrow on Mon, 10/24/2016 - 14:31 Comment #15
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!
Submitted by JamieCameron on Mon, 10/24/2016 - 19:43 Comment #16
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?
Submitted by mlbarrow on Tue, 10/25/2016 - 19:14 Comment #17
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.
Submitted by JamieCameron on Tue, 10/25/2016 - 22:30 Comment #18
Can you check if the directory
/home/{PARENT_DOMAIN}/domains
exists on the destination system?Submitted by mlbarrow on Tue, 10/25/2016 - 22:36 Comment #19
It does not exist, which makes sense because that's what the error message says. :-)
Submitted by JamieCameron on Thu, 10/27/2016 - 00:28 Comment #20
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.Submitted by JamieCameron on Thu, 10/27/2016 - 00:28 Comment #21
Submitted by mlbarrow on Thu, 10/27/2016 - 12:33 Comment #22
Woo hoo. Do you have a targeted release timeframe?
Alternatively, could I run a "nightly build" or something?
Submitted by JamieCameron on Sat, 10/29/2016 - 00:39 Comment #23
We can send you a beta with the fix if you like?
Submitted by mlbarrow on Sat, 10/29/2016 - 18:10 Comment #24
Yes, please!
Submitted by JamieCameron on Sun, 10/30/2016 - 11:25 Comment #25
Ok .. is the problem system running Virtualmin GPL or Pro, and on which Linux distribution?
Submitted by mlbarrow on Fri, 11/04/2016 - 21:39 Comment #26
Virtualmin GPL with 12.04 on the source and 14.04 on the destination.
Submitted by JamieCameron on Sat, 11/05/2016 - 16:04 Comment #27
I've emailed you an updated Debian package
Submitted by mlbarrow on Sun, 11/13/2016 - 15:08 Comment #28
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?
Submitted by JamieCameron on Sun, 11/13/2016 - 21:57 Comment #29
You should get email if a scheduled replication fails.
Submitted by mlbarrow on Tue, 11/22/2016 - 11:53 Comment #30
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. :-)
Submitted by JamieCameron on Tue, 11/22/2016 - 16:20 Comment #31
Sorry, but there is no such log in Cloudmin currently.