"Fatal error: Class 'PDO' not found" when script accessed using php-cli on tbpl-dev

RESOLVED FIXED

Status

Infrastructure & Operations
WebOps: Other
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: emorley, Assigned: jakem)

Tracking

Details

(Whiteboard: [push interrupt])

(Reporter)

Description

6 years ago
For bug 718632, we use php-cli to run php/getLogExcerpt.php after the cron job runs dataimport/import-buildbot-data.py. The prefetching works fine locally, but on tbpl-dev we get:

{
Fetching http://builddata.pub.build.mozilla.org/buildjson/builds-4hr.js.gz ...
Traversing runs and inserting into database...
Inserted 133 new run entries.
Traversing builders and updating database...
Updated 0 builders.

Prefetching: Rev3 WINNT 6.1 try debug test mochitests-2/5 on e22b85241e91
php /data/genericrhel6-dev/src/tbpl-dev.allizom.org/tbpl/dataimport/../php/getLogExcerpt.php id=14944098&type=annotated

Fatal error: Class 'PDO' not found in /data/genericrhel6-dev/src/tbpl-dev.allizom.org/tbpl/php/config.php on line 25
completed after 69ms
}

CCing Chris, since he kindly dealt with adding php-cli in bug 785616.
(Assignee)

Comment 2

6 years ago
I have installed php-pdo on genericadm.private.phx1.mozilla.com. This should resolve this particular issue.
Assignee: server-ops-webops → nmaul
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Hm pdo is installed, but not pdo-mysql:
Uncaught exception 'PDOException' with message 'could not find driver'

Also you might want to change the mysql password once thats done, it was leaked into the logs -.-
Good thing the logs are behind a .htaccess
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 4

6 years ago
Hah, nice... okay, I installed php-mysql instead of -pdo, and that pulls in -pdo as a dependency.

I have also changed the DB password on this, and re-deployed the app. Can anything be done to prevent such a leak in the future? It would be annoying to have to reset the password every time a DB-related issue came up, even if it is behind LDAP auth. :)
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED
(In reply to Jake Maul [:jakem] from comment #4)
> Hah, nice... okay, I installed php-mysql instead of -pdo, and that pulls in
> -pdo as a dependency.
> 
> I have also changed the DB password on this, and re-deployed the app. Can
> anything be done to prevent such a leak in the future? It would be annoying
> to have to reset the password every time a DB-related issue came up, even if
> it is behind LDAP auth. :)

Well display_errors 0 protects against that... no stack trace, no leaked password...
We added that temporary to see why it wasnt working. Hm and I see the new password was leaked as well due to the `Access denied for user 'tbpl_dev_user'@'10.8.70.208'` error. Oh boy. Lets back out that error_reporting change first, then we should be fine more or less.
I’ll check back once thats done...
http://hg.mozilla.org/users/mstange_themasta.com/tinderboxpushlog/rev/435be348c285 <- backed out.
Please check https://tbpl-dev.allizom.org/cache/revision_info.txt to make sure it is the right revision so the password doesn’t appear in a stack trace yet again.

Sorry for the inconvenience :(
(Reporter)

Comment 7

6 years ago
The import logs in https://tbpl-dev.allizom.org/cache/ are now 0 bytes.

Does the MYSQL_PASSWORD variable in the cron file need updating to the new password too? (At least for the Vagrant project, the sql password is specified in both the cron file & also php/config.php).
(Reporter)

Comment 8

6 years ago
tbpl-dev has now updated to a cset where display_errors is set to off, so we are good to update the password again now (but in both places please, to fix the data imports :-)).
(Assignee)

Comment 9

6 years ago
Yup, you're right I missed that there was a variable for it in the crontab. I've changed it again, and updated both the crontab file and the config.php file.

And yes, we do currently have the latest version... 750c0f7d20ab actually, one newer than the display_errors change. Thanks!
(Reporter)

Comment 10

6 years ago
Thank you - looking good :-)
(And great that bug 718632 is working as well on tbpl-dev as it does locally!)
(Assignee)

Comment 11

6 years ago
Classifying this as a push interrupt rather than a service interrupt, because this service was new and had never worked yet when this bug was filed/resolved.
Whiteboard: [push interrupt]
Component: Server Operations: Web Operations → WebOps: Other
Product: mozilla.org → Infrastructure & Operations
You need to log in before you can comment on or make changes to this bug.