Hi,
I'm using Virtualmin GPL which works pretty flawless. However, during a recent conversion from Sub-Server to a Parent Server, I did come across something which appears to be a bug.
During the conversion process, Virtualmin does not update database credential in the domain configuration file.
This causes all future databases to use the previous user id and name schema from the former parent server.
I have in the midst of troubleshooting the issue, verified this by manually checking the domain's configuration file, and even disabling/deleting all databases, then recreating them to see if the issue resolves itself.
In the end, I was able to correct the issue manually by updating the configuration file, turning off databases, deleting any databases already created, then turning the feature back on and creating a new database.
This is certainly not a life threatening issue, however these kind of bugs if ignored, will eventually start adding up.
Anyways, that's my two cents ;-)
Thanks in advance for your attention to this.
Comments
By the way, my version of Virtualmin GPL is 3.73 (the latest per this writing)
Submitted by JamieCameron on Sun, 09/20/2009 - 22:38 Comment #2
Sounds like a bug .. but could you tell me which file you manually updated, and what you changed?
I can then check why Virtualmin isn't doing this automatically in your case.
Jamie,
I updated one of the "domain configuration" files, you know the ones with the "numeric" names found at:
/etc/webmin/virtual-server/domains/
(on CentOS 5)
I ended up updating I believe the following values.
(anything that had the old username associated with it)
ex.
"db", "db_mysql", "mysql_user", and "ugroup"
(I currently only have mySQL enabled in my install, so it's hard to say weather postgeSQL is affected or not)
Submitted by JamieCameron on Mon, 09/21/2009 - 12:18 Comment #4
I would expect db and db_mysql to not change, as there is no way to rename a MySQL database, so the old name is always kept. However, mysql_user should get set to a new name that matches the domain's new Unix username. Did that not happen?
None of the values I ended up updating myself were changed automatically.
As for changing the database name itself, while I understand this may not be possible if there is a database already created while being under the previous parent domain, would it not make sense to have there be a way for the system to use the new naming schema, if either the old database is removed, or there were no pre-existing database previously setup?
Submitted by JamieCameron on Tue, 09/22/2009 - 00:05 Comment #6
Actually, if you were just moving a sub-server to become a top-level virtual sever, the domain name wouldn't have changed, right? So the DB name wouldn't be expected to either..
Jamie,
With my setup yes, it would be expected to change.
My system is setup uniquely that "usernames" are in the form of:
XYZ1234 (sample only)
and home directories are:
/home/domain.com
So when I convert a sub-server to a parent, I expect that while it won't delete the existing database, it should start creating databases using the new username.
To be more specific, I use sub-servers only for "aliases" and "sub-domain" purposes, and create new parent accounts for unique domain names (with aliases being the exception)
This has allowed me to setup a good designed system for my purposes without needing a "reseller" feature, which frankly is fine for me. (not to say I don't intend to send you guys a chunk of change in the future just for providing this great product, and supporting it as awesome as you do.)
Anyways, that's just my opinion on the matter.
It's no big deal, as the extra work, if this is how you intended to design the system is perfectly fine, given that I pay nothing to license, or receive this amazing support so far.
*** I do intend to continue using the GPL version indefinitely, however I do plan on sending you guys a sizable "donation" when financially possible. ***
Thanks again Jamie!
Submitted by JamieCameron on Tue, 09/22/2009 - 23:57 Comment #8
Ok, I think I see what you mean now .. so your DB names are based on the username, which effectively changes when a virtual server is made a top-level server?
At the moment, there's no way in Virtualmin to change this behavior, but I will see what I can do in a future release.
Jamie,
Yeah, it's a pretty unique setup which allows us to maintain decent control over hosting and various other aspects of the account as a whole. Each "user id" also acts as an "account id" in our global system which connects to various services like billing and the like.
Hence we use the following format (for reference and further clarification):
User ID: xyz1234
Home Dir: /home/mydomain.com
DB User: xyz1234
DB Name: xyz1234
User ID: xyz1234
Home Dir: /home/mydomain.com/domains/mysub.mydomain.com
DB User: xyz1234
DB Name: xyz1234_mysub
When we setup "aliases" which are the exception to our system design, we do not enable databases for them, and if requested alias all email addresses (no catchalls) back to the primary domain's email address. (ex. myname@myalias.com => myname@mydomain.com)
Anyways, I'm always tweaking settings and making things better, but the above is what things currently look like, and based on over 10 years in the business I'm quite happy with it :-)
Before Virtualmin, we used costly tools to drive our business with very little flexibility. This is why, in the future, I will become a major financial and marketing contributor towards the continued success of the product family as I've been quite impressed with both Webmin, and Virtualmin to date.
The way I see it, any financial or marketing investment in this product/service is worth its weight in gold, compared to other larger and impersonal companies who compete. Not to mention, even a small contribution on an occasional basis I believe can go a long way, and is a fraction of the cost compared to competing products given there is no requirement to do so. Which works nicely when looking at it from an operating expense perspective. (not saying it's not worth paying, just nice to have a choice, as this allows me to provide the savings onto my customers, which in turn allows us to generate more business, which in turn allows us to contribute towards financial contributions in your product/company/service. Heh Heh)
Once again, thanks Jamie for your time on this, and to the rest of the Webmin/Virtualmin/Cloudmin team for their efforts and assistance past/present!
Kudos!
*** If you would like a formal testimony I'd be happy to provide one given my experience with the product, service and support. ***
Submitted by JamieCameron on Wed, 09/23/2009 - 23:28 Comment #10
Ok, that's a nice layout ..
So I guess if the sub-server in the example was converted to a top-level server, you would expect the DB to be changed from xyz1234_mysub to xyz5678 ?
If this is something that could be made possible for the future, that'd be excellent.
*** I'm pretty sure that if Virtualmin has access to the "root" mySQL account, it should be able to if setup create a "new database" then "export/import" the tables from the "old database" to the "new database", after which, if successful could drop the old database. Worse case, the system could be setup to at least create a database "dump" and store it somewhere in the new parent's home directory. Say, /home/mydomain.com/backups/old-db.tgz" for instance. ***