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

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

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

Also, which version number of Virtualmin is it?

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.

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.

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.

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.

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

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

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

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?

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.

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.

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

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.