PHP App Cannot Connect After a MySQL Password Rotation: A Safe 114la-Era Diagnostic Guide

Maintenance notice (checked 2026-09-01): This is not current installation or support documentation for 114la. It turns a short 2011 post into a credential-rotation and fault-isolation guide for PHP applications using MySQL or MariaDB. Do not obtain software from old snapshot download links, and never paste a real password into a command line, ticket, or public log.

An application saying “cannot connect to database” after a rotation does not prove that the database password is wrong. A mismatch in the server account, application configuration, network or Unix socket, TLS, or PHP driver can produce a similar symptom. Establish the exact connection tuple and a rollback point first, then change only one variable at a time.

Table of Contents

What “114la” means here

An archived official webpage dated 2011-08-03 described 114啦 as an open-source website-directory/navigation site builder and labeled the page V1.15. That context is consistent with the PHP configuration path and MySQL fields in the old post. This article therefore interprets “114la” as that period's PHP/MySQL web-directory application.

The snapshot establishes only how the site described itself at that time. It does not prove that the path in the post applies to every release, or that any surviving download, domain, or package is still maintained by the original project or safe. No verifiable, currently maintained official upstream was found in this review. The snapshot is provenance evidence, not a download or support endpoint.

Start with the right failure model

Separate the connection into four layers before rotating a password again:

Database account: A MySQL/MariaDB account includes both a user and a source host. For example, 'app_user'@'localhost' and 'app_user'@'10.%' are different accounts.
Application configuration: Changing a database-side password does not update the credential stored by a PHP application. Changing the configuration alone does not change the database account either.
Transport endpoint: Host, port, Unix socket, database name, and TLS settings must match the deployment. On Unix, localhost commonly selects a socket while 127.0.0.1 normally selects TCP.
Runtime: PHP extensions, authentication-plugin support, container or VM networking, process environment, and cached configuration can all affect the result.

Stop gates before a change

Stop rather than experimenting in production if any of these conditions is unmet:

You do not have explicit authority to administer the application and database account.
There is no maintenance window, or application writers and queued jobs cannot be paused or drained.
There is no recent backup, provider snapshot, or tested recovery path. A backup is usable only after a restore test, not merely because a file exists; choose a method appropriate to the server version and storage engine.
The previous connection tuple is unknown, or the old credential is not held in a controlled password manager for rollback.
The application still uses database root, remote root, 'user'@'%', or unnecessary global privileges. Have a DBA create a separate least-privilege application account first; an outage is not a reason to broaden access.
The database product and exact version are unknown. MySQL and MariaDB account behavior, authentication plugins, and password-change syntax are not interchangeable across every release.

Record a baseline, not secrets

Collect versions from the same container, VM, or host as the PHP application and keep the output in an administrator-approved private console:

mysql --version
php --version
php --modules | grep -E '^(mysqli|pdo_mysql)$'

Record the exact connection tuple in a controlled change record, but reference the password in a secret manager rather than copying it:

Item	Confirm exactly
Database product/version	MySQL or MariaDB; exact version
Database account	Exact username and account source host
Endpoint	Hostname and port, or Unix socket path
Database	Exact database name and charset requirements
Transport	Whether remote; TLS mode, CA, and certificate hostname
PHP runtime	PHP version, `mysqli`/`pdo_mysql`, actual container or host
Configuration source	The single authority: config file, service environment, container secret, or platform secret

Do not place a password in a screenshot, shell export, chat, ticket, or command argument. MySQL explicitly warns that --password=value and -pSECRET are insecure. Use --password or -p with no value so the client prompts, or an approved, protected login mechanism.

Reproduce from the same runtime environment

First choose the same transport used by the application. Every value in this TCP example is a placeholder:

mysql 
  --protocol=TCP 
  --host='<EXACT_DB_HOST>' 
  --port='<EXACT_DB_PORT>' 
  --user='<LEAST_PRIVILEGE_APP_USER>' 
  --password 
  --database='<EXACT_DB_NAME>' 
  --execute='SELECT CURRENT_USER(), USER(), DATABASE(), @@hostname, @@port, @@version, @@version_comment;'

If the application uses a Unix socket, test it separately; do not provide host and port at the same time:

mysql 
  --protocol=SOCKET 
  --socket='<EXACT_SOCKET_PATH>' 
  --user='<LEAST_PRIVILEGE_APP_USER>' 
  --password 
  --database='<EXACT_DB_NAME>' 
  --execute='SELECT CURRENT_USER(), USER(), DATABASE(), @@hostname, @@port, @@version, @@version_comment;'

After a successful connection, capture the account match, grants, and TLS state in that session. Keep the output only in a restricted maintenance record:

SELECT CURRENT_USER(), USER(), DATABASE(), @@hostname, @@port, @@version, @@version_comment;
SHOW GRANTS;
SHOW STATUS LIKE 'Ssl_cipher';

CURRENT_USER() is the account the server actually matched for privilege checks; USER() is the identity submitted by the client. If they differ, investigate source-host account matching first. Remote connections should use a trusted CA under the organization's policy; where supported, VERIFY_IDENTITY validates both the certificate and hostname. Do not disable certificate verification merely to obtain a connection.

Make one bounded rotation

The change record should name one application account and one deployment:

Enter maintenance mode and drain background writers.
Save SHOW GRANTS, the health baseline, and the current configuration version; confirm the backup/snapshot and recovery owner.
Confirm the exact account 'APP_USER'@'EXACT_APP_HOST'. Do not change root or create remote root access.
Generate and set a random password through a provider console, DBA tool, or another approved channel that does not put the real secret in shell history, process listings, or chat.
Update only the application's password reference. Do not also change its host, port, database name, authentication plugin, or grants.
Run the acceptance checks below. On failure, use the written rollback instead of stacking more changes.

The shape of the statement on modern servers is shown below only to make the account boundary explicit; do not execute it without checking the version:

ALTER USER '<APP_USER>'@'<EXACT_APP_HOST>'
  IDENTIFIED BY '<NEW_RANDOM_SECRET>';

The secret in the example is a placeholder. An interactive SQL client may still write a real value to history or audit logs, so use the provider/DBA's approved secret-safe tooling. Consult documentation for the exact MySQL or MariaDB version first. For old releases, obtain a compatible process from the DBA; do not copy an obsolete SET PASSWORD, direct system-table update, or FLUSH PRIVILEGES recipe from search results.

MySQL 8.0.14 and later can use dual passwords when privileges and client compatibility have been verified, reducing the cutover window. This is not portable MariaDB syntax and does not replace acceptance testing. Do not replace the placeholder with a real secret and paste it into a shell or ticket:

ALTER USER '<APP_USER>'@'<EXACT_APP_HOST>'
  IDENTIFIED BY '<NEW_RANDOM_SECRET>'
  RETAIN CURRENT PASSWORD;

ALTER USER '<APP_USER>'@'<EXACT_APP_HOST>'
  DISCARD OLD PASSWORD;

Run DISCARD OLD PASSWORD only after the new configuration passes acceptance and every old process has exited.

Update application configuration separately

The 2011 post names /admin/config/cfg_database.php, but there is not enough evidence that every 114la release used that path or schema. Locate the authoritative configuration only in your own verified deployment. Back up the file and permission metadata before editing, and do not print its contents to a shared terminal.

If the application supports environment variables or platform secret injection, a conceptual mapping in modern PHP might look like this:

$GLOBALS['database']['db_user'] = getenv('APP_DB_USER');
$GLOBALS['database']['db_pass'] = getenv('APP_DB_PASSWORD');
$GLOBALS['database']['db_name'] = getenv('APP_DB_NAME');
$GLOBALS['database']['db_host'] = getenv('APP_DB_HOST');

This is not a drop-in 114la patch. First ensure the application fails safely when a value is absent and that the PHP process receives these variables from an approved secret store. If a legacy application can read only a file, update it through a non-leaking editor/deployment flow, keep it outside the web root where the architecture permits, allow only the necessary service account to read it, and never commit it. Do not put a .env file in a publicly reachable directory.

Syntax-check the changed file first; the path is a placeholder:

php -l '<PATH_TO_CHANGED_PHP_CONFIG>'

Then reload only the application processes that actually consume the configuration. Do not treat a database restart as the default fix. Never make a connection work by issuing GRANT ALL ON ., widening the source host to %, or switching to a weak or deprecated authentication plugin.

Version, authentication-plugin, and TLS gates

Check the version before ALTER USER. MySQL and MariaDB releases differ in supported clauses and required privileges. Use dual-password RETAIN CURRENT PASSWORD/DISCARD OLD PASSWORD only under the matching MySQL version documentation.
Upgrade clients rather than defaulting to weaker authentication. mysql_native_password was deprecated in MySQL 8.0.34, is disabled by default in 8.4, and was removed in 9.0. If an old PHP driver cannot handle the server's authentication method, prefer a supported PHP/MySQL client combination. PHP documents full caching_sha2_password support beginning with PHP 7.4.4; verify the actual build and driver too.
Do not conflate socket and TCP. In a PDO MySQL DSN, a Unix socket is a distinct connection form from host/port. Reproduce what the application actually uses.
Verify TLS remotely. Preserve the required TLS mode, CA, and certificate hostname. A certificate error is a trust or hostname problem to fix, not a reason to turn verification off.

Narrow the problem by error class

Symptom	Check first	Do not
`Access denied for user ...`	Secret reference, `user@host` match, account lock/expiry, whether the app still reads the old secret	Repeatedly change root's password or widen access to `%`
`Unknown database`	Exact database name, case, and account grants	Create an empty same-named database to hide the error
`Connection refused`/timeout	Host, port, listener, container network, firewall, service state	Change the database password first
`No such file or directory` (socket)	Actual socket path; whether the app interprets `localhost` as a socket	Create an arbitrary socket file
Unsupported authentication method/plugin	Server plugin, PHP driver, version compatibility	Habitually enable `mysql_native_password`
TLS/certificate verification failure	CA, chain, hostname, client TLS mode, clock	Disable certificate verification
CLI succeeds, PHP fails	PHP's actual container/user, extension, configuration source, long-running processes, deployment cache	Rotate the database password again

Keep only the time, error class/code, and request correlation identifier needed for diagnosis. Before sharing, remove passwords, connection strings, hosts, usernames, database names, absolute paths, cookies, and tokens. Never upload a raw exception page or complete configuration to a forum.

Acceptance and rollback

Run one bounded acceptance sequence:

From the application's runtime environment, run a read-only connection check with a prompted password.
Point the application at the new secret, run php -l, and reload only the necessary PHP/worker processes.
Check a read-only page or health endpoint that reveals no sensitive data. If the application permits it, create, read, update, and delete one dedicated test record, then remove it.
Confirm background jobs/queues recover, no new authentication errors appear, SHOW GRANTS is unchanged, and remote connections still use the expected TLS.
Observe for the agreed window. If MySQL dual passwords were used, discard the old password only after every old process has exited.

On failure, stop writers and restore the previous application configuration reference. If the database no longer accepts the old password, an authorized DBA should restore that credential to the exact application account through a secret-safe channel, then repeat verification. Do not restore a whole database backup for a simple credential mismatch. Enter the tested data-recovery process only if data itself was changed or lost.

Maintainer checklist

[ ] Authority, maintenance window, and recovery owner are confirmed.
[ ] Backup/snapshot restore is verified; old configuration and file permissions can be rolled back.
[ ] Exact user@host, host/port or socket, database name, PHP/database versions, and TLS requirements are recorded.
[ ] A separate least-privilege application account is used; there is no remote root, % widening, or global GRANT ALL.
[ ] Passwords travel only through a secret manager, prompted client, or approved DBA path—not CLI arguments, Git, chat, or public logs.
[ ] Only the password reference changed; endpoint, grants, and authentication plugin did not change simultaneously.
[ ] CLI, PHP application, queues, grants, and TLS pass acceptance; the old password is retired on schedule.
[ ] Logs are redacted and temporary test files/data are removed.

References

Archived 2011 source (provenance only)

The block below preserves the source export's complete visible body, line breaks, punctuation, and nested code fence, with trailing whitespace normalized. Three narrow safety substitutions were made: the historical database username, password value, and database name were replaced with explicit placeholders. The unmodified values remain only in source_export/Git provenance and must not enter the maintained page, a command, or a log.

The old instruction to edit configuration directly and ask the hosting provider is rejected as current guidance. It lacks backup, least privilege, secret handling, version, TLS, acceptance, and rollback gates.

MySQL改密码， 114la无法连接数据库


路径为/admin/config/cfg_database.php 这个文件
 例如：
 $GLOBALS [‘database’] [‘db_user’] = ‘[historical database user redacted]’; 数据库用户名
 $GLOBALS [‘database’] [‘db_pass’] = ‘[historical password value redacted]’; 数据库密码
 $GLOBALS [‘database’] [‘db_name’] = ‘[historical database name redacted]’; 数据库名
 $GLOBALS [‘database’] [‘db_host’] = ‘localhost’; 数据库地址
 可以手动修改。
 咨询下空间商数据库正确信息，按提示填入进去就可以了。