Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] php.cli tries to write on wrong php.ini file in Ubuntu 20.04 LTS #216

Open
miquelbonastredreivip opened this issue Oct 26, 2020 · 4 comments
Labels

Comments

@miquelbonastredreivip
Copy link

Your setup

Formula commit hash / release tag

I'm using tag v1.3.1 (80f9c94)

Also fails in master (efcd71f)

Versions reports (master & minion)

(I'm using marterless deployment in Vagrant)

Salt Version:
           Salt: 3002
 
Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: 2.7.3
      docker-py: Not Installed
          gitdb: Not Installed
      gitpython: Not Installed
         Jinja2: 2.10.1
        libgit2: 0.28.3
       M2Crypto: Not Installed
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.6.2
   mysql-python: 1.4.4
      pycparser: Not Installed
       pycrypto: Not Installed
   pycryptodome: 3.6.1
         pygit2: 1.0.3
         Python: 3.8.5 (default, Jul 28 2020, 12:59:40)
   python-gnupg: 0.4.5
         PyYAML: 5.3.1
          PyZMQ: 18.1.1
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 4.5.3
            ZMQ: 4.3.2
 
System Versions:
           dist: ubuntu 20.04 focal
         locale: utf-8
        machine: x86_64
        release: 5.4.0-51-generic
         system: Linux
        version: Ubuntu 20.04 focal

Pillar / config used

You can find example configuration here:

https://github.com/miquelbonastredreivip/php-formula-bugreport-20201026

Pillar info here:

https://raw.githubusercontent.com/miquelbonastredreivip/php-formula-bugreport-20201026/master/salt/pillar/php.sls


Bug details

Describe the bug

In Ubuntu 20.04 LTS, php.cli.ini fails when trying to modify php.ini file, with the following error:

ID: php_cli_ini
    Function: file.managed
        Name: /etc/php/7.2/cli/php.ini
      Result: False
     Comment: Parent directory not present
     Started: 14:23:37.740679
    Duration: 63.969 ms
     Changes:   

Steps to reproduce the bug

git clone https://github.com/miquelbonastredreivip/php-formula-bugreport-20201026
cd php-formula-bugreport-20201026
vagrant up

Expected behaviour

salt and php-formula should have modified file "/etc/php/7.4/cli/php.ini"

Attempts to fix the bug

It works in Ubuntu 18.04 LTS, so I'm still using this version.

Additional context

@myii
Copy link
Member

myii commented Oct 26, 2020

Thanks for this report, @miquelbonastredreivip.

There is fix proposed for this at #215. However, that itself is linked back to #214. And that is dependent on saltstack-formulas/openvpn-formula#132! So the solution is in the pipeline but may take a little time to achieve.

@miquelbonastredreivip
Copy link
Author

Thanks for the feedback. In my case, I'm not in a hurry to migrate from 18.04/php7.2 to 20.04/php7.4.

Miquel

@Enchiridion
Copy link

I'm having the same issue with both fpm & cli on Ubuntu 20.04 using PHP 7.4. Everything above v1.0 was broken. I tried walking through the code, but couldn't find the error in any of the sls files, how it pulled the version number to use from the pillar seemed obvious and correct, but I'm no jinja expert.

I was able to workaround it by manually specifying the paths:

  version: '7.4'
  lookup:
    fpm:
      service: php7.4-fpm
      pools: /etc/php/7.4/fpm/pool.d/
      ini: /etc/php/7.4/fpm/php.ini
      conf: /etc/php/7.4/fpm/php-fpm.conf
      defaults:
        include: /etc/php/7.4/fpm/pool.d/*.conf
        global:
          pid: /var/run/php7.4-fpm.pid
          error_log: /var/log/php7.4-fpm.log
    cli:
      ini: /etc/php/7.4/cli/php.ini

@waynegemmell
Copy link

waynegemmell commented Nov 10, 2021

I have the same issue with php-fpm. I don't have any idea where it get's the 7.2 from. Any idea when this is going to bubble to the front? I'm glad to see the workaround above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants