Page MenuHomePhabricator

Unable to initialize database with invalid credentials in configuration file
Closed, InvalidPublic

Description

I am trying to setup a new Phabricator installation. The MySQL credentials that I have configured in conf/local/local.json don't currently have access to any of the Phabricator databases (because the Phabricator databases do not yet exist). I am trying to initialize the database by passing the MySQL username and password via CLI flags, but I am getting the following error:

> /usr/local/src/phabricator/bin/storage upgrade --force --user=root --password=REDACTED
MySQL Credentials Not Configured

Unable to connect to MySQL using the configured credentials. You must
configure standard credentials before you can upgrade storage. Run these
commands to set up credentials:

  phabricator/ $ ./bin/config set mysql.host __host__
  phabricator/ $ ./bin/config set mysql.user __username__
  phabricator/ $ ./bin/config set mysql.pass __password__

These standard credentials are separate from any administrative credentials
provided to this command with __--user__ or __--password__, and must be
configured correctly before you can proceed.

Raw MySQL Error: #1045: Access denied for user 'root'@'REDACTED' (using
password: YES)

Steps to reproduce

  1. Run ./bin/config set mysql.pass $(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1) to change mysql.pass to a bogus value.
  2. Run ./bin/storage upgrade --user=${USER} --password=${PASSWORD} where $USER and $PASSWORD are valid credentials.

Event Timeline

This could definitely be more clear, but I think this is currently expected -- you still need to have valid configuration even when providing additional administrative credentials.

bin/storage will execute a mixture of normal queries (which use normal credentials) and privileged/administrative queries (which use the administrative credentials you provide).

The modern purpose of --user and --password is only to let you make schema changes as a privileged user if the normal user doesn't have ALTER TABLE and other similar permissions. It means "use these special credentials when applying edits via migration patches", not "ignore my configuration and use these credentials instead".

I think this may have worked differently in the past, but making it mean "ignore my configuration" is a bigger mess now that we have cluster.databases and I'm not sure there's much of a use case for it. Why were you trying to initialize storage with an invalid database configuration?

The MySQL credentials that I have configured in conf/local/local.json don't currently have access to any of the Phabricator databases (because the Phabricator databases do not yet exist).

I'd expect this to still work -- the code attempts to connect to MySQL without selecting a database, then SELECT 1. So if the configuration is valid, we should survive this check, even if the databases don't exist yet. Can you mysql -u <user> -p <pass> with the configured credentials and then SELECT 1?

Closing this for lack of feedback, feel free to resurrect it if you get back to it.