Page 1 of 1

Error: db_user

Posted: Tue May 24, 2016 2:30 am
by celsowebmax
Hi Guys...
I have one domain very long...more than 17 characters. And I am unable to create the database because of the prefix_
How can I solve this problem?
Is there any way to remove this character limit on dbuser?
Thank in advance.

Re: Error: db_user

Posted: Tue May 24, 2016 2:22 pm
by skurudo
16 symbols it's MySQL limit.
viewtopic.php?t=9945#p35765

It's not recommended, but you can change this limit:
viewtopic.php?t=5937
viewtopic.php?f=14&t=4927#p14320

Re: Error: db_user

Posted: Tue May 24, 2016 2:27 pm
by celsowebmax
I see all these topics. But not solved 100% for me.
The solution was recreate the users with only 6 characters.
Thank very much for you attention my friend.

Re: Error: db_user

Posted: Fri Jun 10, 2016 12:47 pm
by skurudo
celsowebmax wrote:I see all these topics. But not solved 100% for me.
The solution was recreate the users with only 6 characters.
Added idea on bugtracker:
https://bugs.vestacp.com/issues/258

Please vote for this feature.

Re: Error: db_user

Posted: Sat Jul 02, 2016 11:21 am
by Elizine
Edit main.sh ( /usr/local/vesta/func ) line 811 to This:
dbuser) validate_format_dbuser "${arg:0:16}" 'db_user';;
AND
in v-add-database (/usr/local/vesta/bin/) line 77 to This:
str="DB='$database' DBUSER='${dbuser:0:16}' MD5='$md5' clear=$dbpass HOST='$host' TYPE='$type'"

That takes care of the validation and shortens the username to the MAX for mysql of 16 chars whilst keeping inline with naming convention as I understand it (username_DBuser) to keep tabs on users DBs...
Probably the best solution would be to edit the front end and make the validation there.. but this works just fine it will shorten the name by latter part if to long to 16 chars.

Re: Error: db_user

Posted: Mon Jul 22, 2019 11:28 am
by Fleuv
Username shortening is not the way to go in case of usernames like:

johnnydoesgood
johnnydoesverygood

If usernames will be shortened to 8 (thus resulting name will be: johnnydo) it will cause conflicts in database creation:
  • johnnydoesgood creates dbuser "johnnydo_mydb" what will be successful and johnnydoesverygood won't be able to access or know about it.
  • johnnydoesverygood creates dbuser "johnnydo_site" what will be successful and johnnydoesgood won't be able to access or know about it.
  • johnnydoesverygood creates a second dbuser called "johnnydo_mydb" what will be successful. However the johnnydoesgood user will not be able to access the database anymore with the password used to create the user, unless johnnydoesgood updates the password what will cause the password not to work for johnnydoesverygood. Or mysql will not allow recreation of the database and the database won't be created in mysql however I don't see any error handling for this one in vesta.
Either way I would suggest increasing the max dbuser char length as the only suitable option. Here is a complete guide on how to achieve that including necessary changes to VestaCP. Note in this case the char limit is extended from 16 to 32 chars.
  • Log in to mysql as root on your (database) server and execute the following queries:

    Code: Select all

    USE mysql;
    ALTER TABLE user MODIFY user CHAR(32);
    ALTER TABLE db MODIFY user CHAR(32);
    FLUSH PRIVILEGES;
    
  • Open /usr/local/vesta/func/main.sh and search for a part of the error message what displayed on the front end, e.g. "mysql username can be". You will find a conditional check nearby, this checks if the username is within a certain length, with my current vesta version this is how I updated the code:

    Code: Select all

    if [ 33 -le ${#1} ]; then
        check_result $E_INVALID "mysql username can be up to 32 characters long"
    fi
    
That's it.

Note this is a temporary fix, suggested way of fixing this:
  • Query the mysql.user table with the describe command and lookup the user attribute's max length.
  • Cache this max length.
  • Every time the validation is executed for creating a new database this cached length will be used to validate the max length.
  • A con for this dynamic solution might be that downsizing of the max length can cause conflicts, so don't forget to make a restriction to down sizing.