Hi
"Individual php.ini files are stored in $HOME/etc/php4/php.ini and $HOME/etc/php5/php.ini, and can be administered using the PHP Configuration module found under the Services menu under each domain within Virtualmin."
I understand this part where every virtual server has its own php.ini file which is created by duplicating the main php.ini file while creating the virtual server.
Now my question is, if the user of the virtual server edits the php.ini file, how is it reloaded? Doesn't apache need to be restarted or how does this work? Or does the server automatically detect changes made to the php.ini file and updates it?
Thanks in advance
Firstly, per-vserver php.ini files are only available when PHP is called in (F)CGId mode, as opposed to mod_php5. The difference is: with FCGI, the scripts are executed in a separate (in case of FCGI memory-persistent) process and in the vserver owner's user context. With mod_php5, scripts are executed by the Apache process itself.
Therefore I'm quite certain that Apache does not need to be reloaded, since it does not execute the PHP stuff itself. I also don't think that the FCGI daemon needs to be restarted. My understanding is that the CGI wrapper, which is called when a PHP script is to be executed and which passes the call to the FCGI daemon, loads the configuration on the fly each time.
You can rather easily test if configuration changes are applied without any service restart by putting a file, e.g. named
phpinfo.php, somewhere in the public_html of the site in question, and giving it this content:<div class="codeblock"><pre><code><span style="color: #000000"><span style="color: #0000BB"><?php<br /></span><span style="color: #007700">&</span><span style="color: #FF8000">#10;phpinfo(); <br /></span><span style="color: #0000BB">?></span></span></code></pre></div>When you call up this file in a browser, it will show you a detailed list of PHP configuration related things, including all settings from the INI. You can then call up the file, check the settings, change them in VMin, and call the file again to see if they have changed.
Yes I guess, I'll have to try it to find out.
Correct me if I'm wrong, but I believe this is how it works:
When php script is called:
Apache is run by the user of this virtual server (& not root or www-data) due to suexec
Apache treats the request as a CGI which is defined to call FCGI
FCGI uses the local php.ini file at $HOME/etc/php5/php.ini and calls php as the user running the virtual server(& not root).
Yepp, nearly correct. :)
The rest is correct.
I just did some experiments, and apparently it is required to "trigger a re-caching" in the FCGId process when you changed the PHP INI file. It should suffice to change the last-modified date of the wrapper script, which is
/home/{serveruser}/fcgi-bin/php5.fcgi.I'm currently running into a problem there though. I cannot do anything with this file ("permission denied") except for reading it. I can't edit it, rename it or touch it, not even set its permissions or owner. Not even as root.
I'm trying to find out now why that is so.
Okay I found out why the php5.cgi file was "off-limits" even to root. :) Some nifty thing named "immutable bit". I wasn't even aware that there are further file attribute bits in addition to those settable by "chmod"... That's Linux forya. ;)
By executing
chattr -i php5.cgithe immutable bit can be cleared. Doing further tests now.So I guess, everytime I do a change in php.ini, I should be executing
touch /home/{serveruser}/fcgi-bin/php5.fcgi(obviously, after I've cleared the so called immutable bit)Question: I've not yet dealt with sub-domains, but how would I be adding a sub-domain to this same virtual server that will use the same php.ini file settings. I don't think I should be using a sub-server since I'm guessing that creates a whole new virtual server?
Thanks for the help so far. Also, Let me know the outcome of your further test!
Seems FCGId is doing some kind of caching that cannot be overcome by simply modifying the php5.fcgi file. Once a PHP file is loaded, even editing that file to contain an error has no immediate effect.
Am looking now how to get FCGId to reload the file and its ini, without having to restart it or Apache.
Mmh, I'm not certain, but I don't think VMin has a built-in way to have two vservers share the same PHP ini in FCGI mode.
An idea for a "quick hack" would be to create a sub-server, and replace its PHP ini file with a link to the one in the main server. Actually,
~/etc/php.inialready IS a link to~/etc/php5/php.ini. So it'd be feasible to have this link point somewhere else.But i think modifying the time on php5.fcgi makes sense. Else imagine, fcgi reloading the php.ini every time it is forked. Would slow down things.
So I'm not understand, how is a sub-server different from creating a new server? When should I be using which one?
Yep, basically it sure makes sense. Now to find out how to instigate fcgi to actually reload the file. :)
As for sub-server: You can create two kinds of servers, "parent" and "sub". The difference is that sub-servers do not get an own administration user, and their data is stored in a subdirectory "domains" (by default, name is configurable) in the home of the parent server.
I see.
Well that means that the 'domains' directory is located in the same directory where 'fcgi-bin' and 'etc/php..' reside. Now even though, the sub-servers do not use this 'fcgi-bin' or 'etc/php', why should it be in their parent directory?
Do you think this layout for multiple domains under the same server makes sense instead?
For the main server:
/home/{serveruser}/{domain}/public_html/home/{serveruser}/{domain}/fcgi-bin
/home/{serveruser}/{domain}/etc
/home/{serveruser}/{domain}/etc/php
and so on...
For sub-servers (additional domain or sub-domain belonging to the same virtual server) will follow the same structure too:
/home/{serveruser}/{domain}/public_html/home/{serveruser}/{domain}/fcgi-bin
/home/{serveruser}/{domain}/etc
/home/{serveruser}/{domain}/etc/php
and so on...
With this layout, the user's home directory clearly has the domains hosted under him. And in addition, it is clear that which php.ini file, fcgi directory, etc belongs to which virtual host / domain.
What do you think?
Sub-servers get put in a subdirectory of the parent server's home, because they "belong", logically and concerning ownership, permissions and FTP access, to the parent server's owner... So I think it makes sense to put them in there, and not alongside the parent server. :)
Each sub-server (it does not matter by the way if their domain is a subdomain of the parent or not) has, inside their "~/domains/..." subdirectory, the same structure as the parent server.
As usual, thanks for the prompt reply Locutus.
Maybe it would be easier for me to get used to the directory layout used by virtualmin instead of trying to adapt what I'm used to on my present hosting provider. Though, think about this:
Putting it alongside like I suggested clearly depicts that they are not dependent on each other whatsoever (which is how it is anyway right as far as apache is concerned?). I thought this way, I can put log files of each domain in their own directory.
so
for Logs:
home/user/domain1.com/logs/home/user/domain2.com/logs/
for public_html:
home/user/domain1.com/public_html/home/user/domain2.com/public_html/
and so on.. since they are all parallel as far as the website is concerned. It's only the ftp account & linux user that they share.
Well, VMin is quite configurable in terms on what gets put where in the filesystem. :) If you look through the options in Virtualmin Configuration and the Template parameters, it's quite conceivable that you can mimic a directory structure like you're used to.
Yes, VMin vservers are independent as far as Apache is concerned, that's right. They just aren't in terms of which VMin user can access/configure what.
For your purpose, I suppose it is not even required to use sub-servers. Actually those are meant to be used when they are to be managed by the same server owner.
As for logfiles... By default, vserver Apache logs are put side-by-side in
/var/log/virtualmin, no matter if parent or subserver. But those paths are configurable as well of course. :)"For your purpose, I suppose it is not even required to use sub-servers. Actually those are meant to be used when they are to be managed by the same server owner."
Actually, I have a few websites which are related and I want them to fall under one user so editing, updating, moving files, etc is easier.
But thanks a lot! I will be trying out whatever you mentioned in the coming days and will get back to troubling you if I have a problem or doubts.
Once again, thanks!
Rogerroger, you're welcome, and have fun! :)
By the way, about your initial question, I meanwhile got the info that you need to kill the
php5-cgiprocess of the user in question to make it pick up INI changes right away. Might play around with that a bit.Awesome, let me know the solution once it works for you. Besides, simply restarting apache does the job of reloading the php.ini file for all users right?
Yep, certainly. Restarting Apache is a sure way to apply any configuration changes. :) A graceful restart should even suffice, you might want to try that out (command
apache2ctl).Locutus
I've been trying out virtual servers and I think the fastest way to reload a modified php.ini file is to use the "apply changes" option in the virtual server's login. (I think this restarts the entire apache itself right? )
Also, I didn't have the immutable bit problem and could right away edit the local php.ini from filezilla over sftp.
Which "Apply changes" button exactly do you mean? The full "path" in Virtualmin should help to find it. :) A hint in advance: To find out what exactly Vmin does when you click such buttons, the Debug log helps greatly, since all commands executed can be logged there.
As for the immutable bit... Okay, you got lucky then I suppose. :) For me it was set, but it's sure possible that some previous process had already cleared it for you.