augeas-lenses filter for PHP files doesn't match php7.0-* files

[Simon Arlott]

[Impact]

Automation of configuration editing cannot be done for PHP installations on Xenial using augeas. The location of php configuration files moved in php7, to a directory augeas doesn't look in.

[Test Case]

  - Create lxc container
  $ sudo apt-get install php7.0-cli
  $ sudo apt-get install augeas-lenses augeas-tools
  $ augtool ls /files/etc/php
  ## (no output)
  - Add the PPA
  $ augtool ls /files/etc/php
  7.0/ = (none)

[Regression Potential]

Since this makes the PHP configuration accessible to augeas where it wasn't before, behaviors to watch for would relate to php configuration issues when augeas (or puppet) are in use. It is expected that by now most administrators will have worked around the problem by using some other method to configure php, so it is unlikely users would experience behavior regression.

[Fix]

This adds the "/etc/php/*/*/*.ini" path to the php lense for augeas,
following what upstream has done, and that we carry in newer versions of
Ubuntu.

[Discussion]

While it is true that Xenial is old at this point, enterprises that use
configuration automation software like augeas sometimes still need older
versions of Ubuntu (e.g. via ESM). PHP has been a popular choice for
many enterprises in the past, so it is expected that PHP 5 -> 7.0
upgrades are still relevant. So, given that, plus the simplicity of
this fix it seems still worthy of SRU.

[Original Report]

The filter list in /usr/share/augeas/lenses/dist/php.aug includes:
/etc/php*/*/*.ini
/etc/php*/fpm/pool.d/*.conf

This will match the php5-fpm package files:
/etc/php5/fpm/php.ini
/etc/php5/fpm/pool.d/*.conf

But not the php7.0-fpm package files:
/etc/php/7.0/fpm/php.ini
/etc/php/7.0/fpm/pool.d/*.conf

Puppet handles this badly because augeas won't report that anything has changed trying to set options in /etc/php/7.0/fpm/php.ini, so it does nothing instead of reporting an error:

Debug: Augeas[php_sessions](provider=augeas): Will attempt to save and only run if files changed
Debug: Augeas[php_sessions](provider=augeas): sending command 'set' with params ["/files/etc/php/7.0/fpm/php.ini/Session/session.gc_maxlifetime", "604800"]
Debug: Augeas[php_sessions](provider=augeas): Skipping because no files were changed
Debug: Augeas[php_sessions](provider=augeas): Closed the augeas connection

augeas-lenses:
  Installed: 1.4.0-0ubuntu1
  Candidate: 1.4.0-0ubuntu1
  Version table:
 *** 1.4.0-0ubuntu1 500
        500 http://gb.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
        500 http://gb.archive.ubuntu.com/ubuntu xenial/main i386 Packages
        100 /var/lib/dpkg/status

php7.0-fpm:
  Installed: 7.0.4-7ubuntu2ppa1
  Candidate: 7.0.4-7ubuntu2ppa1
  Version table:
 *** 7.0.4-7ubuntu2ppa1 1000
       1000 http://ppa.launchpad.net/sa.me.uk/um/ubuntu xenial/main amd64 Packages
        100 /var/lib/dpkg/status
     7.0.4-7ubuntu2 500
        500 http://gb.archive.ubuntu.com/ubuntu xenial/universe amd64 Packages

[Robie Basak (racb)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.

I believe upstream monitor bugs for this package. I'm interested to know how upstream plan to fix this - we can cherry-pick their changes.

[Dominic Cleal (domcleal)]

I'd suggest just adding these two entries to the includes list:

/etc/php/*/*/*.ini
/etc/php/*/fpm/pool.d/*.conf

Unless there are other incompatible INI files that might be matched? I'm not familiar with the PHP packages to be sure.

[Michael Wodniok (wodniok)]

Okay, i've opened a pull request for this some hours ago and it got already accepted (upstream-Bug #399: https://github.com/hercules-team/augeas/commit/d454d7dceb2613b861db6d2a8724bf47360466f7

[Raphaël Pinson (raphink)]

I could add this patch to the augeas 1.6 package in Yakkety. Do we want to include it in Xenial, too though?

[Michael Wodniok (wodniok)]

... and the rest of my comment went away, thx launchpad ...

it contains only the first line, as i didn't know fpm was also affected (not using it).
Please make sure the line fixes the problem for fpm. If yes, please either make a PR, or say something, then i will create a second one.

The other question is, whether this package is still maintained (another bug is still there, but patch exists and is posted here).

[Michael Wodniok (wodniok)]

@raphink: yes, please.

[Raphaël Pinson (raphink)]

https://launchpad.net/ubuntu/+source/augeas/1.6.0-0ubuntu2

[Launchpad Janitor (janitor)]

This bug was fixed in the package augeas - 1.6.0-0ubuntu2

---------------
augeas (1.6.0-0ubuntu2) yakkety; urgency=medium

  * Fix location of php.ini for PHP 7 (LP: #1580731):
    - d/p/0004-Reflect-Ubuntu-16.04-location-of-php.ini-399.patch

 -- Raphaël Pinson <email address hidden> Thu, 18 Aug 2016 16:17:27 +0200

[Robie Basak (racb)]

Thanks Raphaël! I'll add a task for Xenial.

[Jon Grimm (jgrimm)]

@raphink (or anyone else that has seen this)

I built a xenial ppa with this fix. Would you be able to test, or provide a set of instructions that would allow me to test the fix?

https://launchpad.net/~jgrimm/+archive/ubuntu/augeas-1580731

sudo add-apt-repository ppa:jgrimm/augeas-1580731
sudo apt-get update

Assuming the fix tests well, I'll work an SRU for 16.04/xenial.

[Bryce Harrington (bryce)]

I've reproduced the issue and verified Jon's PPA fixes it. I've respun his patch to update the version (there's been one security update since his PPA) and added DEP3 info while I was at it. I've posted the refreshed work to my own PPA:

  https://launchpad.net/~bryce/+archive/ubuntu/augeas-sru-lp1580731

I can carry the SRU forward for this.

[Robie Basak (racb)]

Following a discussion with Bryce earlier, on behalf of the SRU team I'm declining this SRU and mark it Won't Fix.

It might have been relevant to fix in Xenial at the time, but the bug has now been fixed in newer releases including in two newer LTS releases. The benefit to Xenial users seems minimal now, especially as not a single user has stepped up to test Jon's proposed fix in four years.

As the impact on users on Xenial therefore appears to be zero, I don't think it's appropriate to SRU this now, when balanced against the regression risk of toolchain changes mutating a rebuild. If the situation changes and users do appear who are affected, then we can reconsider.

Note that I've not considered any other factors. If users are affected, an appropriate answer may still be to upgrade rather than SRUing this fix.