Migration from cPanel Backups fails on Quota and Database Create (possibly due to quota)

I have tried a couple of imports tonight, and one seems to have gone perfectly, but the last two failed, with messages in the output indicating that installation dependencies for Joomla and PHPMyAdmin were not being met, because they require a MySQL database.

In one case, the MySQL reported an error 122, which is out of disk. This was a 50 MB domain which had a quota of 100 MB in cPanel. The one database, the Joomla one, was created completely empty. I increased both quotas to 500 MB, and was able to finally get PHPMyAdmin to install, and then fill the one database from a MySQL dump.

I had another domain which was only 8 MB, with a 100 MB quota, similar symptoms, static files were copied, but the Joomla and PHPMyAdmin in the server template failed because of the MySQL issue.

I ran a df on my server, and it reports 3 G free, so I am not sure where I am hitting quotas.

This is on 3.77 Pro.

Status: 
Closed (fixed)

Comments

The cause may be that Virtualmin enforces on MySQL usage, while cPanel does not .. so a domain that fit under the quota in cPanel doesn't when migrated to Virtualmin.

One work-around is to turn off database quotas - this can be done at System Settings -> Server Templates -> Default Settings -> MySQL database -> Set group ownership of MySQL database files? (select "No").

I would be interested to know if that helps..

Ah, that's what the Rimuhosting guys suspected...smart cookies, they.

The whole problem started when I found it too easy to delete my favorite Server Template the other day.

So, I re-created it, and I guess missed some things, but that's where my issue started. I don't know how I hit the delete button by accident, or selected the wrong ST, but ...

So, tonight, I revamped the ST...the major thing, probably was switching all quotas from Hard to Advisory.

The next import worked perfectly.

I had another issue, dopey me...had forgotten the ${Prefix}, could only remember ${DOM} in the database names for the script installer. It would be great if there were some help along those lines on that page.

Anyway, I think you are correct about the specific quota problem, and maybe you could detect that condition somehow, and do that the user likely wants, and let it come up later in an over quota report, but late at night, while doing server moves, just let it go through :)

Cool, glad that worked.

The 3.78 Virtualmin release will include a fix to prevent this from being a problem.

Thanks, Jamie. That was the #1 and primary issue of this ticket.

Can you possibly consider the contributory issues (other than user ignorance and error):

2) "Too Easy to delete Server Template"- I am not sure, but somehow, I was surprised when I lost my best server template, I don't know whether I though I was deleting another one or what, but could you maybe ask "Are you Sure?" - Server Templates are no joke, and can embody a lot of work. One bad click can be a disaster.

3) Really easy- Can you list some of the shorthand, specifically ${Prefix} and ${DOM} in some kind of example or Help on the Server Template - Default Script Installers screen, b/c those are hard to find in the documentation. They are mentioned in other screens, in other contexts, like the Setup Email, but not on this screen. Here is some text: "Database names must be unique on your server. The best way to ensure this is to use ${Prefix}_ (the part of the domain name before the last dot), or ${DOM}_ (the full domain name)as part of the datbase name in your script installer setup. ${Prefix} is better, because it shouldn't have any special characers or dots. Example: ${Prefix}_joomla is a great name for a Joomla! database.

Thanks!

  1. Was this a server template that was in use by some domains, or was it currently un-used?

  2. Good idea, I will look into this ..

Oh, the ST I deleted was DEFINITELY, VERY MUCH in use by DOZENS of domains. With absolute certainty. Good question...and that even serves as a further indicator of whether a warning is necessary. Maybe unused STs, no warning, but used STs, warning.

Thanks, Jamie. The idea is that you can even use the text I wrote as the help text, because that's what I would have found helpful at the time.

Ok, I will add a confirmation page prior to template deletion.

BTW, it is actually possible to manually un-delete a template if it was in use by any domains when it was removed. Just edit the appropriate file under /etc/webmin/virtual-server/templates , and remove the deleted=1 line.

Automatically closed -- issue fixed for 2 weeks with no activity.