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

Status: RESOLVED FIXED

(Infrastructure & Operations Graveyard :: WebOps: Other, task)

Description

[Ed Morley [:emorley]]

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.

Comment 1

[Ed Morley [:emorley]]

The line in question:
http://hg.mozilla.org/users/mstange_themasta.com/tinderboxpushlog/file/e3325a59f257/php/config.php.example#l25

Comment 2

[Jake Maul [:jakem]]

I have installed php-pdo on genericadm.private.phx1.mozilla.com. This should resolve this particular issue.

Comment 3

[Arpad Borsos [:Swatinem]]

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

Comment 4

[Jake Maul [:jakem]]

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. :)

Comment 5

[Arpad Borsos [:Swatinem]]

(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...

Comment 6

[Arpad Borsos [:Swatinem]]

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 :(

Comment 7

[Ed Morley [:emorley]]

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).

Comment 8

[Ed Morley [:emorley]]

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 :-)).

Comment 9

[Jake Maul [:jakem]]

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!

Comment 10

[Ed Morley [:emorley]]

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

Comment 11

[Jake Maul [:jakem]]

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.