When I go to as root:
System Settings > Server Templates > Default Settings > MySQL database
and change Create database as well as login to No, it appears that I lose the ability to create new databases. This option controls (as I understand it) only whether a default database should be created upon domain creation. So, I changed it to No.
Then, when I (as end-user) do:
Edit Databases
I see the message "This virtual server does not have any databases yet", but there is no way to create a database since there are no links or buttons on the page to create a database.
Is this a bug? I do have MySQL login enabled checked (Edit Virtual Server > Enabled features).
i noticed this also and wanted to make a ticket about it, but forgot.
It must be a bug, the only way that a user can create a database is after the master admin created the first one for him first.
I had disabled the initial creation of a database as its often not needed to have a mysql and a pgsql database from the beginning (let the user do it when and if he needs it) until I found out that a user was then not able to create his first database...
What will work though in these circumstances is when the user installs a script through the automatic installer that needs a database.
Just out of curiosity, on the Webmin side I tried manually creating the default database that would have been there had I not checked <b>No</b> for <b>Create database</b> as well as login and attached the same database permissions as would have been created. Then, I checked to see if the Virtualmin side would allow me to create a database under <b>Edit Databases</b>, but that didn't work.
If I'm going to have to live with this bug for awhile, I would want to create the default database for those accounts that are "damaged" so as to avoid potential customer calls complaining about the issue. Or, if you think Virtualmin be updated within a week or two to fix this problem, I can hold off doing any manual fix.
Should I open a ticket for this to track it? Thanks for confirming the issue.
<div class='quote'>Should I open a ticket for this to track it?</div>
Depends on whether you want to chat about it, or actually get it fixed. Forums are for talking, bug trackers are for bugs. ;-)
--
Check out the forum guidelines!
Correction: I did find a workaround to the bug. Do the following steps:
[ul][ol]In Webmin, create a database using whatever naming convention would have been used. That is, take note of what is specified in System Settings > Server Templates > MySQL database, including the entries for <b>Default database name</b> and enter it into the section Servers > MySQL Database Server > Create a new database[/ol]
[ol]Click on Database Permissions in the same section and mimic the same permissions that would have been created by default.[/ol]
[ol]Lastly, on the Virtualmin side, go to Edit Databases > Import Database and import the database you've just created.[/ol][/ul]So, with this workaround available, the pressure is off. Enjoy!
indeed that is what i have done as well.
create one then import.
if you issue a bug ticket then I will await the outcome :)
For one of the domains that I added before I reverted to allowing the default database to be created, I tried installing the script phpmyadmin. When doing so, I got the error:
<b>Failed to install script : Could not find PHP version for /home/<i><user></i>/public_html/phpmyadmin</b>
For domains that I created when the default database was created at domain-creation time, I can install phpmyadmin with no errors. Can you suggest a workaround/fix so that I can install phpmyadmin on these "damaged" top-level and sub-server domains?
Note: I can recreate the domains from scratch, but then I'd need to find some way of saving e-mail mailbox content, etc. I'm hoping for a workaround that doesn't make me delete and re-create the domain.
Thanks!
<div class='quote'>I'm hoping for a workaround that doesn't make me delete and re-create the domain.</div>
Don't do anything dramatic. I seem to recall Jamie provided a workaround in the ticket about this issue, and version 3.59 fixes the problem and will be in the repositories tonight.
--
Check out the forum guidelines!