Changing PHP's post_max_size and upload_max_filesize with Ansible












0














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).










share|improve this question
























  • 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 at 11:19
















0














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).










share|improve this question
























  • 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 at 11:19














0












0








0







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).










share|improve this question















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).







debian php ansible stability upload






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 17 at 5:58

























asked Dec 16 at 9:33









JohnDoea

1351132




1351132












  • 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 at 11:19


















  • 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 at 11:19
















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 at 11:19




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 at 11:19










1 Answer
1






active

oldest

votes


















1














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!!!






share|improve this answer























  • 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.
    – JohnDoea
    Dec 17 at 7: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 at 9: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...
    – JohnDoea
    Dec 18 at 2: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 at 9:26











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f489281%2fchanging-phps-post-max-size-and-upload-max-filesize-with-ansible%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









1














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!!!






share|improve this answer























  • 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.
    – JohnDoea
    Dec 17 at 7: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 at 9: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...
    – JohnDoea
    Dec 18 at 2: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 at 9:26
















1














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!!!






share|improve this answer























  • 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.
    – JohnDoea
    Dec 17 at 7: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 at 9: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...
    – JohnDoea
    Dec 18 at 2: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 at 9:26














1












1








1






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!!!






share|improve this answer














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!!!







share|improve this answer














share|improve this answer



share|improve this answer








edited Dec 16 at 17:11

























answered Dec 16 at 17:03









maulinglawns

6,22121225




6,22121225












  • 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.
    – JohnDoea
    Dec 17 at 7: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 at 9: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...
    – JohnDoea
    Dec 18 at 2: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 at 9:26


















  • 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.
    – JohnDoea
    Dec 17 at 7: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 at 9: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...
    – JohnDoea
    Dec 18 at 2: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 at 9:26
















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.
– JohnDoea
Dec 17 at 7:11






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.
– JohnDoea
Dec 17 at 7: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 at 9:57






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 at 9: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...
– JohnDoea
Dec 18 at 2:07






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...
– JohnDoea
Dec 18 at 2: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 at 9:26




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 at 9:26


















draft saved

draft discarded




















































Thanks for contributing an answer to Unix & Linux Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f489281%2fchanging-phps-post-max-size-and-upload-max-filesize-with-ansible%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Morgemoulin

Scott Moir

Souastre