hi, since i had issues to restore a full backup, and talked about it on IRC
i explain what can happen:
- many domains and much stuff
- one or more domains have NOT been created with Virtualmin first...
- one or more domains have Administration group like mail or other which can do conflict... the reasons about this can be many...there's not a particular reason
- the Admin does a full backup, which may even require MANY HOURS
- now, after many hours, when he goes to a new server and tries to restore he can get an error like this:
"Re-creating virtual server domain.com .... a clash was detected : A unix group named mail already exists - try selecting a different administration username"
so, you should prevent this BEFORE the backup and NOT after... e.g. if the Administration group has not the same name as user
-> username:username
alerts the Admin to change this BEFORE the full backup AND you can even alert him when he does an "Import Virtual Server"
this lets the Admin avoid to wait uselessly for a backup which may require even many hours
otherwise he has to:
- go to /etc/webmin/virtual-server/domains, find the domain file needed and change the values for group, ugroup and gid and then re-make the backup again...
anyway, you should also let him edit that specific file content from Virtualmin itself, step which ATM he can't do...
other issue happened to me:
- MySQL max_allowed_packet
it may happen that on a new server, where the first thing that an Admin does is e.g.
- install the OS
- yum update
- install.sh (Virtualmin)
- restore the full backup
the max_allowed_packet is too low to manage the backuped databases, they can be many and different each other
in my case had an error like "load failed! ERROR 2006 (HY000) at line ..." where the max_allowed_packet was the default MySQL value
so, you could edit your script to read the max_allowed_packet variable inside /etc/my.cnf and register that value, then change it to 100M or another safe value, restart mysql, do the restore, once the restore is complete revert that to the original value and restart mysql again...done. If even in that case the restore fails, well... the Admin has to understand what's going on, but in that case ONLY
hope this helps
best regards
Comments
Submitted by JamieCameron on Mon, 11/24/2014 - 18:38 Comment #1
Regarding the backup issue, if the admin user didn't conflict on the original system I'm not sure how Virtualmin could know that it is going to clash on the system you are restoring on prior to actually doing the restore..
Submitted by 7stars on Mon, 11/24/2014 - 18:56 Comment #2
but you can do easily the same,
when the Admin imports the Virtual Server, just force him to specify name:name, a name for the virtual server owner, not used by any other virtual server, and the same name for its administration group instead of "just read what you see from Users and Groups"
or you can even read it but first do a check, if it's not good you force him to edit...eg. retrieve the username and the group, if they are different, tell the Admin that he should call the Administration group like the username is...and create the group if it's not in the list
in this way there's no conflict at all and restore doesn't return that error
then, for mysql, i think that you can do that too...
Submitted by JamieCameron on Mon, 11/24/2014 - 22:21 Comment #3
Oh, so in this case was the username you selected when importing the domain already in use by another domain on the original system?
Submitted by 7stars on Tue, 11/25/2014 - 04:22 Comment #4
no, the problem was the Administration group,
in this case it was "mail" and obviously mail returns error when you try to restore
so in that way you could avoid any issue...
when the Admin does "Import Virtual Server" only, giving a unique domain owner with the same name for the group...
foo:foo - bar:bar - one:one... and so on
this is my opinion
Submitted by JamieCameron on Tue, 11/25/2014 - 16:19 Comment #5
Ok, this will be detected and handled in the next Virtualmin release.
Submitted by Issues on Tue, 12/09/2014 - 16:20 Comment #6
Automatically closed -- issue fixed for 2 weeks with no activity.