2

Is there a way to change the two famous PHP variables post_max_size and upload_max_filesize in php.ini in a version-agnostic way with Ansible?

I didn't find any literature covering this and it seems wired to me because no company, let alone mega company will allow just the default 2M limit value of these two variables (which is prevalent since PHP was born, I think).

  • I would suggest you look up either the `replace` module or `lineinfile`. I normally use the former for these kind of operations. – maulinglawns Dec 16 '18 at 11:19

2 Answers2

6

Instead of regex use https://docs.ansible.com/ansible/latest/modules/ini_file_module.html

- name: set PHP memory limit
  become: yes
  ini_file:
    path: /etc/php.ini
    section: PHP
    option: memory_limit
    value: 512M
Devin Zuczek
  • 61
  • 1
  • 2
  • Thanks for posting this. I haven't used Ansible in production as of late, and did not know there was an `ini_file` module. This indeed seems more robust than using regex or lineinfile or whatever. – maulinglawns Dec 29 '19 at 18:33
  • Note that this command is not included in ansible-core; you must run `ansible-galaxy collection install community.general`. – bfontaine Dec 06 '21 at 15:12
3

Ok. This got me intrigued, and here is what I came up with:

---
- hosts: all 
  become: yes 

  tasks:
    - name: Get path to php.ini
      find:
        paths: /etc/php
        file_type: directory
        recurse: no
      register: ini_path

    - name: Update php.ini post_max_size
      replace:
        dest: "{{ ini_path.files[0].path }}/apache2/php.ini"
        regexp: '^post_max_size.*$'
        replace: 'post_max_size = 20M'
        backup: yes 

    - name: Update php.ini upload_max_filesize
      replace:
        dest: "{{ ini_path.files[0].path }}/apache2/php.ini"
        regexp: '^upload_max_filesize.*$'
        replace: 'upload_max_filesize = 20M'
        backup: yes

The first thing I do is use the find module to determine which version of php we are running, and of course registering that result into ini_path. This works because the only directory under /etc/php is the directory with the actual version number:

ls /etc/php/
7.2

Since the registered result is a python dictionary, I later combine the result with the complete path to php_ini:
"{{ ini_path.files[0].path }}/apache2/php.ini"

This way we can use the playbook despite not knowing beforehand which version of php we are running (within reason, we have to use apache2!).

Execution against my test server (Ubuntu 18) looks like this:

ansible-playbook update_phpini.yml -i "192.168.1.11," -kK
SSH password: 
SUDO password[defaults to SSH password]: 

PLAY [all] *********************************************************************

TASK [setup] *******************************************************************
ok: [192.168.1.11]

TASK [Get path to php.ini] *****************************************************
ok: [192.168.1.11]

TASK [Update php.ini post_max_size] ********************************************
ok: [192.168.1.11]

TASK [Update php.ini upload_max_filesize] **************************************
ok: [192.168.1.11]

PLAY RECAP *********************************************************************
192.168.1.11               : ok=4    changed=0    unreachable=0    failed=0

In a production environment, you could do more test, and use set_fact to assign the path to a variable early on. This is just a POC.

Also, of course adjust the file sizes to your liking!!!

maulinglawns
  • 8,426
  • 2
  • 28
  • 36
  • This is an amazing answer, thank you so much and I upvoted ! I can't stop suffer from the "what if Apache 3.4 comes out tomorrow and everything changes" and it seems that even Ansible isn't powerful enough to remove that anxiety from my mind. –  Dec 17 '18 at 07:11
  • Thank you for the kind words. As I said, this is just a POC. In production, I would do more tests and sanity-checks, plus I already have other ideas that would improve the playbook. However, I will leave it as-is for now :) You _could_ of course also check which version of apache you are using from within ansible. But if _too_ much changes between versions, well... maybe that would be too big of a playbook to write, I do not know at this point. Best regards! – maulinglawns Dec 17 '18 at 09:57
  • I take POC for Proof Of Concept. Just one last thing please, do you think it will be best to use a code from Ansible Galaxy for this purpose? I never used codes from there... given there is so few literature, do you think using something from there regarding this is a good approach? In the end I just desire maximal stability with this... –  Dec 18 '18 at 02:07
  • Hi! Yes, POC is for Proof Of Concept. I have never used anything from Ansible Galaxy. Call me paranoid, but I like to have 100% control over my playbooks. – maulinglawns Dec 18 '18 at 09:26