Extension ini files missing priority in filename

[JCotton1123]

Abandoning the issue template (sorry). I believe this affects all OS, versions of Puppet, versions of this module, and versions of php.

Each PHP extension will populate the php.d directly (/etc/php.d on RedHat) with one or more extension ini files. These ini files are prefixed with a number indicating a priority that causes them to be parsed in a specific order. The php::extension resource should be updated to include a "ini_priority" or similar parameter to mimic this behavior. This is a simple enough PR. However, I discovered this issue when I realized that the php.d directory was ending up with multiple ini setting files for each extension. Ex:

# ls /etc/php.d/
20-bz2.ini       20-dom.ini       20-gettext.ini         20-mysqlnd_mysql.ini  20-posix.ini      20-sqlite3.ini  20-tokenizer.ini  20-zip.ini          30-wddx.ini       odbc.ini
20-calendar.ini  20-exif.ini      20-iconv.ini           20-odbc.ini           20-shmop.ini      20-sysvmsg.ini  20-xml.ini        30-pdo_mysqlnd.ini  30-xmlreader.ini  pdo.ini
20-ctype.ini     20-fileinfo.ini  20-mysqlnd.ini         20-pdo.ini            20-simplexml.ini  20-sysvsem.ini  20-xmlwriter.ini  30-pdo_odbc.ini     40-json.ini       xml.ini
20-curl.ini      20-ftp.ini       20-mysqlnd_mysqli.ini  20-phar.ini           20-sockets.ini    20-sysvshm.ini  20-xsl.ini        30-pdo_sqlite.ini   mysql.ini

I am looking for suggestions on implementing the priority functionality and addressing the duplicate ini settings files issue in a user-friendly way. One option is to purge php.d but this is going to have unintended consequences. One option to place the burden on the user to make sure s/he sets the extension ini_priority (maybe with a default of 20 since most exts appear to have this prio) but this isn't really user friendly. We could create some kind of hash and lookup the default priority for each extension (again with a default of 20) but this is burdensome on us, the maintainers. Any thoughts?

[Vincent--]

Hi,

I don't have an answer for Redhat, but on Ubuntu, you can add the priority directly inside the ini file (in /etc/php/X.X/cli/mods-available/foo.ini):

foo => {
    settings       => {
        'extension' => 'foo.so',
        ';priority' => '25',
    },
    package_prefix => 'php-',
},

The important part is ';priority' => '25', (don't forget the ; before priority)
And then phpenmod will create the link with the correct priority: /etc/php/X.X/cli/conf.d/25-foo.ini -> /etc/php/X.X/cli/mods-available/foo.ini

I haven't seen anything about that in this module documentation, so hopefully this will help other people who might have an issue with the loading order of php extensions.

Regards,
Vincent.

[Vincent--]

oops, just realised that works perfectly for the priority but the comment is added again and again at each puppet run 😢

[dbeckham]

I can confirm this behavior. The comment is added, but it's also added again on each subsequent puppet run.

A good use case for needing a priority would be the pecl-couchbase extension. In the current version, it requires the PHP json library be loaded. But, because (c)ouchbase comes before (j)son in alphanumeric sort and all PHP modules are defined as priority 20 by default, the couchbase module is loaded first, causing it to fail.

Example of the duplicated comments

extension = couchbase.so
;priority = 30
;priority = 30

[jk2l]

Have you guys looked at this pull request? #257

[jk2l]

Also want to add comment of my use case. We installed tideways-php, and it have a default priority of 40. Puppet generated give default priority of 20. so we can't override the priority with puppet unless we hardcode something outside of module (e.g. using fileline)

[Vincent--]

@jk2l , #257 sounds good but it cannot be merge until conflicts are solved. Also this PR has been created 1 year ago and it hasn't been merged since. I suppose the "priority" management is not a priority for the maintainers 😁
This PR might also need to manage priority changes: from what I understand after a quick look that will create the link with the correct priority but the previous link will still be present.

[jk2l]

@Vincent-- oh actually i created a new PR #335 but there is some discussion still need to be solve

[Vincent--]

Just seen that, thank you for that 😄 I've also asked the ppa maintainer if he can manage the priority directly with the script, see last comment here oerdnj/deb.sury.org#575

[jk2l]

Yesterday in IRC discussed with @igalic and considering maybe we should not use phpquery instead we use puppet recursive and do full manage extensions via puppet?

@Vincent--

[jk2l]

One issue with phpenmod and phpdismod is that after you change the priority let say from 20 to 40

phpdismod can't detect 20-module.ini because it was looking at 40-module.ini
phpendmod will add a new 40-module.ini and now clean up any duplicate module.ini

if you are increase priority probably it is just override the priority of lower version, but decrease priority won't be able to work

[Vincent--]

I agree we have only 2 options here:

• use an optimised version of php*mod scripts that can fully manage the version
• or switch to puppet based solution

About the "priority" change, this was the purpose of my comment in oerdnj/deb.sury.org#575 : phpenmod should also remove existing links with other priority than the current one

[igalic]

i am in favour of using a puppet based solution… in a puppet module.
it gives us the chance of working on more platforms, simply by not spreading our energy too fin on accommodating all of their kinks.

[poikilotherm]

PR #333 seems to provide an easy solution to this...? At least it fixes @JCotton1123 initial request.

[poikilotherm]

Sorry for the noise - this missing feature actually leads to errors: as I installed mysqlnd via php::extensions, mysqlnd.so (non-prefixed file) gets loaded after mysql.so, mysqli.so and pdo_mysql.so (from prefixed files).

[root@web01 php.d]# ls -1 *mysql*.ini
30-mysqli.ini
30-mysql.ini
30-pdo_mysql.ini
mysqlnd.ini

This leads to mysql unavailable within PHP:

PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/mysql.so' - /usr/lib64/php/modules/mysql.so: undefined symbol: mysqlnd_connect in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/mysqli.so' - /usr/lib64/php/modules/mysqli.so: undefined symbol: mysqlnd_connect in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/pdo_mysql.so' - /usr/lib64/php/modules/pdo_mysql.so: undefined symbol: mysqlnd_allocator in Unknown on line 0

Environment: CentOS 7, PHP 5.6 from IUS, voxpopuli/puppet 4.0.0.

[poikilotherm]

Sorry guys for disturbing again... This issue is kind of a blocker and there seems to be a simple solution presented in #333. Could you give it a shoot, fix this ASAP and maybe push a bugfix release to the forge? Thanks for your great work!

[jkarns87]

Bumping this again...This issue really needs to be fixed!

[luisbrandao]

This STILL is an issue for me.

[alexwiedermann]

Me too

[poikilotherm]

@JCotton1123 is your particular problem solved with #333 being merged so this might be closed?

@hunner could you please tag a release for this?

[JCotton1123]

@poikilotherm yes, #333 resolves my original issue. I'll close this. For others, I guess create a new issue with a better description if you're still facing an issue.

[minorOffense]

What we probably want to avoid having to manually set the priorities manually is some kind of conf dir purge. And then make sure the module defines the default conf files properly. Then any files created by package managers are removed in favour of the puppet ones.

Just a thought.