Cloning a sub-server in Virtualmin Pro clones database without proper permission and name

Submitted by beat on Wed, 10/03/2012 - 01:19

Good morning,

When a customer clones a subdomain there are 2 issues:

1) despite fact that full access permission to the cloned database is set for the main user of the parent virtual server is properly set, when the user tries to access the "Manage database..." link, he gets:

Error
You are not allowed to edit this database

This is annoying as even changing permissions in database still doesn't fix it. Any idea were this access can be fixed ?

2) the name of the cloned database is not prefixed with the owner/domain name. Let's say example.com has a subdomain dev.example.com and clones it into test.example.com. The new database will be named test and not example_test.

Status: 
Closed (fixed)

Comments

Submitted by JamieCameron on Wed, 10/03/2012 - 13:04

For problem 1, does it help if you select the domain from the left menu, click Edit Virtual Server, and then click Save (as root) ?

Submitted by beat on Wed, 10/03/2012 - 14:32

Yes, that fixes the issue for that case (saved both sub-virtual server and main virtual server of customer !

Thanks !

P.s. bug remains to be fixed in Virtualmin Pro ;-)

Submitted by JamieCameron on Wed, 10/03/2012 - 16:50

Cool - I will have Virtualmin do that automatically in future.

As for problem 2, what are the actual domain names and database names on your system?

If the domain dev.foo.com has a database called dev_bar and the domain is cloned to smeg.foo.com , then cloned database should be named smeg_bar .

Submitted by beat on Wed, 10/03/2012 - 17:15

Great for your fix of #1, many thanks for the quick reply as usual.

Main domain of customer is:

novaexample.ch

(his main domain, without database, he's a web designer with customers)

a sub-vitrual server is:

customer.ch (with database name is customer_maindata, as we parametered Virtualmin somewhere to prefix database names, don't recall where now, but e.g. in script installers config or somewhere else. Did that setting 3 years ago, would have to go through our setup documentation).

and he cloned that sub-domain to:

dev.hiscustomer.ch

and there database name (of cloned database) became:

dev

I would have expected:

devhiscustomer_maindata

as name of the cloned database. or:

hiscustomer_dev

but certainly not just "dev", as there might be more domains dev.somethingelse.com on our server later. ;-)

(btw i sent an email to Joe a week ago re our last VIrtualmin Pro renewals payment, but he didn't reply yet, is he around, if yes can you please ping him to check his mail/spambox?) :-)

Submitted by JamieCameron on Wed, 10/03/2012 - 17:37

Did the source customer.sh domain have any other databases, or just that one customer_maindata ?

If you were to create a new domain named dev.hiscustomer.ch, its initial database would be named dev after the first part of the domain. So if the domain being cloned has only one initial database, it will be copied to dev during the clone process.

Regarding the renewal, could you forward that email to me at jcameron@virtualmin.com ?

Submitted by beat on Thu, 10/04/2012 - 15:16

Did the source customer.sh domain have any other databases, or just that one customer_maindata ?

only one.

If you were to create a new domain named dev.hiscustomer.ch, its initial database would be named dev after the first part of the domain. So if the domain being cloned has only one initial database, it will be copied to dev during the clone process.

Understand, even though it's a bit surprising. For multiple "." in domain name, I would expect to have them either appended without separator or with _ as separator. ;-)

Regarding the renewal, could you forward that email to me at jcameron@virtualmin.com ?

Sure. Done. Sorry to bother you with admin questions. Added a technical one to make it more interesting. :-D

Submitted by JamieCameron on Thu, 10/04/2012 - 17:05

It is a little surprising, but using the first part of the domain name for the default database is kind of the Virtualmin standard. The only improvement I would consider is if the DB was named dev_maindata .

I will check out your email..

Submitted by beat on Sat, 10/06/2012 - 06:20

Yes, dev_maindata would make more sense when cloning than just "dev", which is a bit surprising, as most sites have a "dev." or "test." or "stage." sub-virtual-server ;-)

(nothing major though)

Submitted by JamieCameron on Sat, 10/06/2012 - 23:56

I had a closer look into this, and found a case where you can end up with an odd database name like this - basically, it can only happen if the original primary DB for the domain being cloned was deleted, leaving only the customer_maindata database.

I will fix this in the next reelase.

Submitted by Issues on Sun, 10/21/2012 - 00:08

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