"backup failed : Unknown --virtualmin option styles" error when running Cloudmin replication.

Submitted by internetlightspeed on Thu, 11/12/2015 - 17:10

Hi everyone. I'm running into a snag on our new Cloudmin implementation, which was built on top of two Virtualmin servers.

When I try to run the Virtualmin replication manually (the automatic replication doesn't work either), I get the following error:

Backing up 110 virtual servers on source system .. .. backup failed : Unknown --virtualmin option styles. Available options are : config templates email custom scripts scheds chroot mailserver

Replication failed - see the output above for the reason why.

I've attached screenshots of the replication configuration and the error message as well.

Status: 
Active

Comments

Submitted by JamieCameron on Thu, 11/12/2015 - 23:12

Is the Virtualmin system being backed up running the GPL or pro version?

Also, which version number of Virtualmin is it?

Submitted by internetlightspeed on Fri, 11/20/2015 - 13:16

We're using the latest paid version of Cloudmin - we only downloaded it last month. Virtualmin on the other hand, is version 4.18 GPL.

Submitted by JamieCameron on Fri, 11/20/2015 - 21:39

The work-around for this on the sync page is to de-select "Content styles" in the "Virtualmin global settings to replicate" field.

I will fix this properly in the next Cloudmin release.

Submitted by internetlightspeed on Tue, 11/24/2015 - 16:01

I've given this workaround a shot, only to find a dozen other reasons why these backups weren't completed successfully.

Part of the problem appears to be that failed replications stop the whole process, instead of moving on and doing what it can to replicate the rest of the sites. Another annoying issue that's easy to fix is how the output doesn't appear to use any carriage returns or line breaks in the way that every other Virtualmin module does. This produces output that's understandably hard to read and difficult to diagnose.

It also appears that I might need to remove any virtual servers that exist on the replicata servers before I even start the process, so that Virtualmin can do the replication the "right" way. I'm going to give that a shot and reply back with my findings.

Submitted by internetlightspeed on Tue, 11/24/2015 - 16:23

Yeah, I've just tried replicating a very simple test site, and I'm getting these weird errors:

-- begin output Starting replication from worker1.lightspeed.ca of virtual servers mocku.edu ..

Finding source and destination systems .. .. found source worker1.lightspeed.ca and destination worker2.lightspeed.ca Refreshing domains on source system .. .. done

Creating temporary directories .. .. done

Backing up 1 virtual servers on source system .. .. backup failed : Starting backup.. Creating backup for virtual server mocku.edu .. Copying virtual server configuration .. .. done Backing up Cron jobs .. Error: Failed to open /mailhome/mocku.edu/.backup/mocku.edu_unix : Permission denied Error ----- Failed to open /mailhome/mocku.edu/.backup/mocku.edu_unix : Permission denied ----- Call Stack Trace In file /usr/share/webmin/virtual-server/security-lib.pl at line 291 calling WebminCore::error In file /usr/share/webmin/virtual-server/feature-unix.pl at line 636 calling virtual_server::open_tempfile_as_domain_user In file /usr/share/webmin/virtual-server/backups-lib.pl at line 717 calling virtual_server::backup_unix In file /usr/share/webmin/virtual-server/backup-domain.pl at line 333 calling virtual_server::backup_domains

Replication failed - see the output above for the reason why.

-- end output

Even if I delete the .backup directory, this error comes back, as if Virtualmin is creating these files with the wrong permissions in the first place.

Submitted by JamieCameron on Tue, 11/24/2015 - 18:16

What permissions and ownership is Virtualmin creating that .backup directory as?

Submitted by internetlightspeed on Wed, 11/25/2015 - 11:54

root@worker1:/mailhome/mocku.edu# ls -la |grep backup

drwxrwxrwx 2 root root 4096 Nov 25 00:00 .backup

Submitted by JamieCameron on Thu, 11/26/2015 - 00:02

That is very unusual, as the directory creation should be done with domain owner permissions. Are you saying that if you completely delete it (with rm -rf .backup) , it gets re-created owned by root?

Submitted by internetlightspeed on Thu, 11/26/2015 - 11:38

Yes, it certainly does. I can try changing the ownership to the domain owner, but this could get pretty annoying real quick, since we have hundreds of virtual domains on our system.

Submitted by internetlightspeed on Thu, 11/26/2015 - 13:40

That's weird. When I manually change the .backup folder to the domain's user, running the replication changes it right back to being owned by root.

Submitted by JamieCameron on Sat, 11/28/2015 - 00:07

Does this happen when doing a regular backup as well, or only when replicating?

Submitted by internetlightspeed on Fri, 12/11/2015 - 15:01

Oh, sorry, I didn't realize I hadn't replied to this message.

No, regular backups work fine.

I'm actually moving on with another fresh install of Virtualmin and Cloudmin, without any previous virtual hosts installed on the replicated system. The old server had some hardware issues and we replaced it.

I'll let you know what my results are.