When you create a new virtual server, Virtualmin copies all of the php.ini files for the different versions of PHP to the virtual server’s home/account in the location (similar) /root/home/exampleaccount/etc/php.7.4 and this allows flexibility for each server to be different
The Problem
When i want to make changes to the php.ini I have to do this on each virtual server manually.
There is a GUI editor for the global php.ini files in webmin Webmin --> Tools --> PHP Configuration but this seems pointless as these ini files are just being used like Server Templates. Alter once and then all accounts are updated.
Questions
Is it possible to use the global php.ini files rather than having separate ones. This is more condusive for hosting companies.
Can you push php.ini changes to virtual servers easily?
Can changes be set to override the values in the default php.ini file rather than replacing it with a separate php.ini file. Maybe using the .user.ini mechanism instead for local overrides.
Any help would be appreciated and hopefully I have not missed something obvious
Although I see your point here. I think this is still the correct way → make a change for each VS separately. Just how many times do you actually need to alter/edit php.ini in the lifetime of a VS? It might make more sense to make it possible to make changes to the global php.ini and then possible to roll-out to selected/all VS?
As you role out new Virtual servers their php.ini will become out of sync with the global and this is a bad way of managing servers for webhosting. I like to know what they are all set at and I can change them to be all the same.
The current setup will just have servers on different snapshots of the global php.ini at different times even if they are not touched.
Webhosting = Using a single central php.ini . There are no sysadmins invoved here.
App deployment = Probably better having a single php.ini so a sysadmin can change at will.
@Stegan Any idea how to do any of my points? Thanks
Sorry no. That needs input from those who work on the code. I was more about seeing and up to a point, in agreement with you. I have never had to alter a php.ini on a site yet. But then none of my sites use php (outside of the installed apps like Roundcube etc.
@jimr1you might be wrong with your assumption., they might be jailed. But it might be worth checking to see what happens when I alter the global php.ini
When you create a Virtual server, the global php.ini for ‘CGI wrapper’/FCGId PHP and for each of the different versions installed (7.4, 8.1, 8.2) are copied in the following way:
This means editing the global php.ini files in Webmin --> Tools --> PHP Configuration is pointless as these ini files are just being used like Server Templates, when using CGI/FCGId.
@jimr1 I have just checked with PHP FPM and you are correct. .
When I alter one of the global php.ini files via Webmin, restart the server the change is reflected. Overrides per domain act as they are supposed too.
So question is, what is that copy mechanism for? is it a hangover from using mod_php and should be removed?
The copied php.ini files are used for ‘CGI wrapper’/FCGId and they were/are a way of Virtualmin allowing each server to have their own php.ini settings. This is definately an old way of doing it and is pointless trying to upgrade these systems as they will not be used for much longer I suspect.
PHP configuration variables for scripts - does not alter the php.ini files copied for ‘CGI wrapper’/FCGId when you create a Virtual Server. I am still not sure what is does. This option can be used to insert or manipulate php values for software that is installed via Virtualmin --> Install Scripts
Using PHP-FPM does not require its own copy of the php.ini to work and provide an override mechanism.
Is anyone really bothered these days ? Php fpm is the way forward for web servers (unless it’s the server I have coded which uses php cli rather than the recognised modes). Before you ask this was written for a specific person and is not main stream released
which is useful if you wish to serve different versions of php in different directories of the same domain, I believe that in future versions of the virtualmin module that you will be able to use FPM to achieve the same goal, but just be aware in the current version of the virtualmin module, virtualmin writes a symlink to ~/etc/php.ini which is linked to the version of php you have chosen (e.g 8.1), which in turn messes with the cli installation of php for that user. For example you may want to serve the web pages using php 7.x but allow any exec’s from the web content to use php 8.x it will not as it uses the version of php.ini that the symlink points to (in this case 7.x). To get around the problem delete the symlink.