Create MySQL user and database with same name as cPanel user
Let's say I have a cPanel user called "example". This user can create MySQL users and databases, provided that they are prefixed with "example_".
I'd like to set up a MySQL user called "example" (no underscore or anything), and a database by the same name. In my case, I'm in the process of migrating a large number of sites from an old server where this was the convention, and being able to do this would greatly simplify the process, since I wouldn't have to update all the config files to reflect new usernames and database names.
Currrently, it looks like the only way to do this is to disable database prefixing entirely. Database prefixing is a nice thing to have, and I'd like to keep it enabled. Instead, I'd like to be able to manually create users and databases from WHM with arbitrary names that bypass this restriction.
I like this idea 
cPanel, WebHost Manager and WHM are registered trademarks of cPanel, L.L.C. for providing its computer software that facilitates the management and configuration of Internet web servers.
It's unlikely that we will add this behavior into cPanel & WHM. Previously, such a user *did* exist on old cPanel & WHM versions as a means of various cPanel elements accessing cPanel user databases (it was a user that inherently was given access to all databases for that user). The password was kept in sync with the cPanel user's password (which meant it was prone to customer sites "breaking" when they changed their cPanel password, and therefore this MySQL user's password). By nature of this being a prior user that we must accommodate for supporting/restoring for old accounts, we can't realistically repurpose it in the future. This would break compatibility with restoring old accounts.
In the use case you've mentioned (using a MySQL username equal to the cPane username while using DB Prefixing) the system would need to rename the DB when it renamed the user, therefore meaning you'd still need to edit DB configs for your scripts. I am not seeing how this feature prevents you from having to edit DB configs.
The only feature that would prevent this from being needed is with DB Prefixing set to OFF.
With DB Prefixing on (as you've requested you want to keep) there's no way to retain an exact DB name. It will always have to be renamed when you change the account username. This is by nature of DB Prefixing using the prefix to determine ownership of a DB.
I'm not sure I'm fully understanding your request, since you site this in the context of "mass moving accounts". Mass moving accounts (outside of name conflicts when transferring) doesn't involve DB or Username changes.
It's unlikely that we will add this behavior into cPanel & WHM. Previously, such a user *did* exist on old cPanel & WHM versions as a means of various cPanel elements accessing cPanel user databases (it was a user that inherently was given access to all databases for that user). The password was kept in sync with the cPanel user's password (which meant it was prone to customer sites "breaking" when they changed their cPanel password, and therefore this MySQL user's password). By nature of this being a prior user that we must accommodate for supporting/restoring for old accounts, we can't realistically repurpose it in the future. This would break compatibility with restoring old accounts.
In the use case you've mentioned (using a MySQL username equal to the cPane username while using DB Prefixing) the system would need to rename the DB when it renamed the user, therefore meaning you'd still need to edit DB configs for your scripts. I am not seeing how this feature prevents you from having to edit DB configs.
The only feature that would prevent this from being needed is with DB Prefixing set to OFF.
With DB Prefixing on (as you've requested you want to keep) there's no way to retain an exact DB name. It will always have to be renamed when you change the account username. This is by nature of DB Prefixing using the prefix to determine ownership of a DB.
I'm not sure I'm fully understanding your request, since you site this in the context of "mass moving accounts". Mass moving accounts (outside of name conflicts when transferring) doesn't involve DB or Username changes.
It's unlikely that we will add this behavior into cPanel & WHM. Previously, such a user *did* exist on old cPanel & WHM versions as a means of various cPanel elements accessing cPanel user databases (it was a user that inherently was given access to all databases for that user). The password was kept in sync with the cPanel user's password (which meant it was prone to customer sites "breaking" when they changed their cPanel password, and therefore this MySQL user's password). By nature of this being a prior user that we must accommodate for supporting/restoring for old accounts, we can't realistically repurpose it in the future. This would break compatibility with restoring old accounts.
In the use case you've mentioned (using a MySQL username equal to the cPane username while using DB Prefixing) the system would need to rename the DB when it renamed the user, therefore meaning you'd still need to edit DB configs for your scripts. I am not seeing how this feature prevents you from having to edit DB configs.
The only feature that would prevent this from being needed is with DB Prefixing set to OFF.
With DB Prefixing on (as you've requested you want to keep) there's no way to retain an exact DB name. It will always have to be renamed when you change the account username. This is by nature of DB Prefixing using the prefix to determine ownership of a DB.
I'm not sure I'm fully understanding your request, since you site this in the context of "mass moving accounts". Mass moving accounts (outside of name conflicts when transferring) doesn't involve DB or Username changes.
It's unlikely that we will add this behavior into cPanel & WHM. Previously, such a user *did* exist on old cPanel & WHM versions as a means of various cPanel elements accessing cPanel user databases (it was a user that inherently was given access to all databases for that user). The password was kept in sync with the cPanel user's password (which meant it was prone to customer sites "breaking" when they changed their cPanel password, and therefore this MySQL user's password). By nature of this being a prior user that we must accommodate for supporting/restoring for old accounts, we can't realistically repurpose it in the future. This would break compatibility with restoring old accounts.
In the use case you've mentioned (using a MySQL username equal to the cPane username while using DB Prefixing) the system would need to rename the DB when it renamed the user, therefore meaning you'd still need to edit DB configs for your scripts. I am not seeing how this feature prevents you from having to edit DB configs.
The only feature that would prevent this from being needed is with DB Prefixing set to OFF.
With DB Prefixing on (as you've requested you want to keep) there's no way to retain an exact DB name. It will always have to be renamed when you change the account username. This is by nature of DB Prefixing using the prefix to determine ownership of a DB.
I'm not sure I'm fully understanding your request, since you site this in the context of "mass moving accounts". Mass moving accounts (outside of name conflicts when transferring) doesn't involve DB or Username changes.
In my case, I'm migrating accounts from a non-cPanel server. On that server, there was nothing restricting what usernames could and couldn't be used, but the general practice was to use their system username, which in most cases is the same username we give them when moving them to cPanel.
Essentially, all I need is the ability from WHM to create an arbitrarily-named database and assign it to a certain user. I assumed the constraints I placed on my request would simplify things, but apparently that's not the case.
This is a fresh cPanel installation, and we're not dealing with old cPanel accounts, so I don't see why backwards-compatibility should hold us back.
In my case, I'm migrating accounts from a non-cPanel server. On that server, there was nothing restricting what usernames could and couldn't be used, but the general practice was to use their system username, which in most cases is the same username we give them when moving them to cPanel.
Essentially, all I need is the ability from WHM to create an arbitrarily-named database and assign it to a certain user. I assumed the constraints I placed on my request would simplify things, but apparently that's not the case.
This is a fresh cPanel installation, and we're not dealing with old cPanel accounts, so I don't see why backwards-compatibility should hold us back.
Hmmm, cannot edit.
I forgot to mention that the Database mapping tool is in WHM, restricted to users with root level access.
Hmmm, cannot edit.
I forgot to mention that the Database mapping tool is in WHM, restricted to users with root level access.
That could be useful, but my issue is with the fact that with database prefixing enabled, ALL databases MUST be prefixed.
I'd like that restriction to apply to normal users, but be bypassable by WHM admins.
That could be useful, but my issue is with the fact that with database prefixing enabled, ALL databases MUST be prefixed.
I'd like that restriction to apply to normal users, but be bypassable by WHM admins.
I am in the exact position as DanH42 - moving a load of clients from a none CPanel/WHM server over to one I have just setup. It would be very useful to be able to do this as we also experience the same setup as Dan with DB name/username the same as the primary account name. The passwords for the DB's are different from the primary account password though. So I don't forsee the issues regarding passwords as mentioned, as they are unique in each instance.
I am in the exact position as DanH42 - moving a load of clients from a none CPanel/WHM server over to one I have just setup. It would be very useful to be able to do this as we also experience the same setup as Dan with DB name/username the same as the primary account name. The passwords for the DB's are different from the primary account password though. So I don't forsee the issues regarding passwords as mentioned, as they are unique in each instance.
Replies have been locked on this page!