Page MenuHomePhabricator

Tool Labs: Enable php5-mcrypt on Trusty
Closed, ResolvedPublic


Croptool cannot switch from precise to trusty until the mcrypt php extension is added. Mcrypt is enabled on Precises, but not on Trusty.

Update: suggests it needs to be enabled with php5enmod, i.e., linked from /etc/php5/mods-available/ to /etc/php5/cgi/conf.d/.

Event Timeline

Danmichaelo raised the priority of this task from to Needs Triage.
Danmichaelo updated the task description. (Show Details)
Danmichaelo added a project: Toolforge.
Danmichaelo added a subscriber: Danmichaelo.

Hmm, I see that it is marked to be installed for both precise and trusty - and I just checked, and it is installed on trusty too. Do you have sample code that shows it not being usable on trusty?

Strange. I got Fatal error: Call to undefined function mcrypt_module_open(). And on the command line, php -i | grep mcrypt gives no results. Both indicating it's not installed.

Perhaps it's installed, but not activated? I vaguely remember that some ubuntu php packages do not create the necessary symlinks in /etc/php5/

Danmichaelo renamed this task from Tool Labs: Install php5-mcrypt on Trusty to Tool Labs: Enable php5-mcrypt on Trusty.Jun 21 2015, 1:54 PM
Danmichaelo updated the task description. (Show Details)
Danmichaelo set Security to None.

I'm puzzled by this. Almost all packages have their respective config files in conf.d -- mcrypt.ini is the only exception. In the packages, I can't figure out why any others would be installed -- I'd expect none of them to be enabled. I can just add a call to php5enmod specifically for mcrypt (using mediawiki::php5mod, probably), but I wouldn't feel certain other modules could just randomly get the same issue...

The best would of course be to fix this upstream, but not sure how hard that is.. There is a bug here (also listing some other modules like imap):

I'm not that familiar with Launchpad, so I'm a little confused. Status says "Fix Released", but there's also a unmerged branch waiting for review:

The first is the change that caused this (requiring php5enmod). The second indeed mentions the following:

The absence of a postinst script causes the extension to not be enabled after install.

and indeed, packages build from the php5 package have a

php5_invoke enmod ALL ${dsoname}

in their postinst. Open bugs on the matter are and

I've learned that mcrypt is abandonware and not really recommended to use, so I've removed the dependency on it in CropTool. If no other tools need it, I guess this issue can be closed?

Change 324957 had a related patch set uploaded (by Tim Landscheidt):
Tools: Enable PHP module mcrypt on Trusty execution nodes

Can someone test if this is an issue in the debian jessie kubernetes images we use?

You can with the following:

webservice stop
webservice --backend=kubernetes start

This should also provide you with a slightly newer PHP (5.6)

Answered myself: yes, it works fine in the jessie images.

So one way to get support for this would be to just move to k8s using the commands I specified earlier.

Change 324957 merged by Andrew Bogott:
Tools: Enable PHP module mcrypt on Trusty execution nodes