Incorrect php.ini being linked

Hi Guys,

This looks like a side-effect of this:

https://www.virtualmin.com/node/32427

But what is happening for me is that I have two different php.ini's one for the system version 5.3.3 and one for 5.4 (software collection)

When creating a new virtual host the following happens correctly:

  • I get directories

php5 AND php5.4

but virtualmin links to the php.ini found in the php5 directory and not the php.ini in the php5.4 directory.

It's defaulting to the most recent version when creating the virtual server which is fine and what I want but what's the best way for me to address the php.ini not being linked properly?

I've been going in after the fact and relinking...

Thanks! Aaron

Status: 
Closed (fixed)

Comments

Howdy -- are you referring to the symlink within $HOME/etc? If so, affecting the functionality of PHP sites at all?

That symlink shouldn't actually be used by PHP -- it should be pointing to the directory "$HOME/etc/php5" and "$HOME/etc/php54".

The symlink of php.ini is just there for convenience for folks looking to edit it by hand, it shouldn't actually be required for anything to function properly.

Hi,

I have slightly different php.ini files for 5.3.3 and 5.4.16. Virtualmin is selecting php version 5.4.16 by default (which is fine and I know I can change this behavior), but it's linking the $HOMEDIR/etc/php.ini to the $HOMEDIR/etc/php5/php.ini which would be incorrect since that is an ini for the system PHP or in my case php 5.3.3

Am I totally confused about how this is working? I guess I'd rather not have the $HOMEDIR/etc/php.ini not be linked at all if it's going to be linked to a version the ini file that isn't the active php version for that directory.

Let me know if I'm thinking about this in the wrong way...

Thanks!

The etc/php.ini link is really just for your convenience - it links to the default PHP version. However, actual PHP scripts will use the php.ini in the correct sub-directory.

OK what I'll do is delete the link because I'd rather have users go into the specific directory to ensure they are editing the php.ini for the version they are intending to make changes to.

It's has become confusing for some of my users with the addition of the new version of PHP.

Thanks!

Normally the link should be to the php.ini file for the PHP version selected for the domain's public_html directory. Do you have different PHP versions enabled for different dirs?

Hi Jamie,

That is my point exactly! It's not pointing to the correct version. Here is what I have:

Virtual Server --> PHP Versions --> Default directory ---> Set to 5.4.16

But the php.ini in $HOMEDIR/etc/php.ini is pointing to the php.ini in the php5 or in my case the PHP 5.3.3 version.

To answer your question: I'm not using different versions for multiple directories just the default.

What I expected would happen was that php.ini would be linked to the currently selected version of PHP for the default directory (5.4.16 since virtualmin selects the most recent version). And each time I change the PHP version for the default directory it would adjust that link.

Thanks!

Ok, I see the bug that causes this now - it will be fixed in the next Virtualmin release.

Awesome thanks again Jamie!

Automatically closed -- issue fixed for 2 weeks with no activity.

Hi Jamie,

I have a question related to this issue. I have compiled a second version of php (5.3.28) and when I select:

Virtual Server --> PHP Versions --> Default directory ---> Set to 5.3.28

It creates a symlink here: php.ini -> php5.3/php.ini

But doesn't create php5.3/php.ini directory and ini file.

Is it because Virtualmin can't find the php.ini to copy?

That sounds like a bug, although a different one from the original.

Where is the template PHP 5.3 php.ini file on your system?

Hi Jamie,

The path to my ini is here: /opt/rh/php53/lib/php.ini

Ok, that explains it - Virtualmin is only looking at /opt/rh/php53/root/etc/php.ini

I will fix this in the next release.

Ok thanks .. for now I'll put a copy there.

Ta. RJ

Automatically closed -- issue fixed for 2 weeks with no activity.