MySQL API1 Bug After 11.28? mysql::adduser

[Volomike]

Our sysop upgraded the server's cpanel to 11.28. Our cPanel XML API code was working perfectly fine before the upgrade. Unfortunately now when we run our code, it creates the database okay, but then below when we create the user, it's failing to do anything:

$asArgs = array();
$asArgs[] = $sDBUser;
$asArgs[] = $sDBPass;
$this->_XMLAPI->api1_query($this->_sCPUser, 'Mysql', 'adduser', $asArgs);

...where $sDBUser = 'webmdorg_test12', $sDBPass = 'pass123456', $this->_sCPUser = 'webmdorg'. Note I'm using the common XMLAPI class for PHP that people commonly use with cpanel, which I downloaded out of the forums here. Note also that the database is named webmdorg_test12 -- matching the same thing as the db user.

What I end up with is a database 'webmdorg_test12', but no user and no error in PHP.

So you might be wondering if we have db prefixing on or off. Well, in WHM, it has the "Disable DB Prefixing" option available to us, but we didn't select it. And when I go into a user's MySQL Databases control panel in cpanel, it shows prefixes (based on the cpanel account name) in front of the database name field and username field. And no, we have not yet run "/usr/local/cpanel/bin/setupdbmap" and don't know we need to do so or not.

Please help! We're confused, and we have customers who depend on this to work.

EDIT 1:

The XML object response I get back from the API is this:

SimpleXMLElement Object
(
    [module] => Mysql
    [func] => adduser
    [type] => event
    [source] => internal
    [apiversion] => 1
    [data] => SimpleXMLElement Object
        (
            [result] => SimpleXMLElement Object
                (
                )

        )

    [event] => SimpleXMLElement Object
        (
            [result] => 1
        )

)

[zeki79]

hello
i think there is a bug in 11.28
i dont have the same issues, but problems with creating mysql logins when i migrate accounts. see http://forums.cpanel.net/f338/erros-...te-172491.html

greets
zeki

[cPanelMatt]

Could I please see the entry created in /usr/local/cpanel/logs/access_log when this query is run? That will give me a good idea of what exactly is going on. I plan on digging into this more tomorrow.

[Volomike]

In the access_log file like you suggest, the only result I get back is this:

10.10.10.10 - webmdorg [11/14/2010:18:33:26 -0000] "POST /xml-api/cpanel HTTP/1.1" 200 0 "" ""

I used tail -f access_log to see the entries. When I ran the add db user script, it returned the above result.

(Note I changed the IP address above instead of my real workstation IP.)

However! something interesting came up. I tailed out the error_log, and it reported this error:

[2010-11-14 12:50:53 -0600] info [cpanel] Mysql usernames must be 16 characters or less
[2010-11-14 12:50:53 -0600] warn [mysql::adduser] Encountered error in mysql::adduser: Mysql usernames must be 16 characters or less

So, I took off the db prefix. So, instead of "webmdorg_test1234", I did "test1234". It automatically threw the cpanel account prefix on for me and gave me a proper result:

[2010-11-14 12:51:27 -0600] info [mysqladmin] Creating MySQL virtual user webmdorg_test1234 for user webmdorg

Nowhere in the docs does it say that we need to change our API calls for 11.28 so that we should not add on the cpanel account prefix. In Appendix E of the DBMappingWhitePaper PDF, it vaguely implies this, but not exactly when it says, "If Prefixing is off, username will be taken literally. No prefix will be added at creation." What they don't state is that prefixing will be ON by default after a 11.28 upgrade. Therefore, a prefix will be added at creation when using either the adddb or adduser API.

And here's also something that's odd. I used the adddb API, and it took the dbname literally and did not add an additional prefix on it -- so, that goes counter to Appendix E of the DBMappingWhitePaper PDF.

So, here's the summary of the workaround. You'll know you have prefixing turned on if there's a "Disable DB Prefixing" option in your WHM under the "SQL Services" area. We had it turned on by default and haven't disabled it.

Regardless of how confusing Appendix E is in the DBMappingWhitePaper PDF, it appears that adddb is tolerant and will accept a dbname with or without cpanel prefixing and handle it properly. As well, adduserdb seems to also be tolerant on dbname having the cpanel prefix or not. HOWEVER, adduser is NOT tolerant when DB Prefixing is ON, and will not permit you to add a user with cpanel prefixing. Got it?

Here's another way of stating it, assuming that webmdorg is the cpanel account, and test1234 is the database name I want as well as the username I want:

DB Prefixing ON
- adddb -- can use webmdorg_test1234 or test1234 for the dbname
- adduser -- can ONLY use test1234 for the username
- adduserdb -- can use webmdorg_test1234 or test1234 for the dbname, but can ONLY use test1234 for the username

DB Prefixing OFF
- adddb -- can use webmdorg_test1234 for the dbname and NOT test1234
- adduser -- can ONLY use webmdorg_test1234 for the username
- adduserdb -- dbname must be webmdorg_test1234, and username must be webmdorg_test1234.

[cPanelDavidN]

Hi Volomike,

I'm sorry to hear that you're having issues with the Mysql API calls. Hopefully we can clarify the design changes introduced in 11.28 and get cPanel and your scripts communicating clearly again.

Nowhere in the docs does it say that we need to change our API calls for 11.28 so that we should not add on the cpanel account prefix.

- The Mysql calls 'adddb' and 'adduser' have always allow you to create databases and users without the prefix in the name. In cPanel version before 11.28, the Mysql module would always prefix the string you pass (as the first argument for those calls).

- In 11.28, these two function behave in exactly the same way as previous versions of cPanel IF DB Prefixing is on (as stated in Appendix E). If in a previous version of cPanel your script passed the prefix within the string, I'd be surprised that it worked properly for you as that would contradict all behavior I observed when testing cPanel 11.25.0 API calls. I've always just passed the unique portion of the name, the same way the cPanel UI does, ie. no prefix in my string. All that said, the document doesn't mention any need to change your API calls because previous versions of those API calls are not expected or intentionally designed to work the way that it seems your scripts are using them.

In Appendix E of the DBMappingWhitePaper PDF, it vaguely implies this, but not exactly when it says, "If Prefixing is off, username will be taken literally. No prefix will be added at creation."

- IF you have DB Prefixing off, then the string you pass will be taken literally for those two functions; ie, no prefix will be added. If prefixing is on, it will auto add a prefix.

These two calls are noted because they have behavior that will change when you turn DB Prefixing off. The is different than all the other API calls related to databases. All other calls should behave the same whether DB Prefixing is on or off, that means all those other calls will need the full, or literal name of the database resource as it lives within the mysql databases.

For example, the call adduserdb, responsible for assigning ownership between a databases and a database virtual user (a db user created in the cPanel interface) has changed. Regardless of the state of DB Prefixing, you must now always pass the full database and user name. So, if you have prefixing on you need to pass 'user_dbname' and 'user_dbvirtuser'.

What they don't state is that prefixing will be ON by default after a 11.28 upgrade.

- Granted it's in only one place (Second paragraph of page 18, Implementation Details, 11.28 with Prefixing On)

cPanel systems with DB Mapping which have DB Prefixing enabled, (the default value)...

in the white paper, which I find to be enough, another explicit probably wouldn't hurt. This design implementation has been said numerous times in the forums as well on the integration blog.

I've attached a sample script ('sample_adddbs_loop.txt') that I use on occasion when doing some particular database testing (making many databases and virtual users for many pre-existing users). It's not fabulous and is not designed for production use, but it should give you a good idea about the design implementation.

Regards,
-DavidN