No php.ini!

K

kjpetrie

I've just discovered I have no php.ini file on my server. According to phpinfo() it should be at /usr/local/etc/php.ini but I have no such file. According to the PHP manual I should copy either the development or production version to that location and then edit it for my needs, but I can't find those on my machine either! I installed www/mod_php72 using ports-mgmt/pkg.

Where can I get these files for use on FreeBSD or do we really not need them?
 
Evidently, you did not understand my post. These files are not installed by www/mod_php72, so they can't be copied internally. I have since obtained copies of the files from PHP's Github and uploaded those, as better than nothing. However, it would be better to have FreeBSD versions of the files to ensure compatibility with paths.
 
They are definitely provided with phpXX as I've installed this several times recently.

mod_php doesn't actually seem to rely on any php package (don't quite see what use it is as AFAIK mod_php can't pass requests to an external service like php-fpm can), so have you actually got php installed?

Edit: Looking at the first post, if you're running phpinfo on this host then you clearly have php installed... Which only leaves these files being removed somehow...
 
I have only www/mod_php72 on this machine, installed in two jails which run web servers. lang/php72 is not installed, so it is clear www/mod_php72 is sufficient to run PHP in Apache. However, that being the case, surely it should contain at least one sample php.ini to complete or enable set-up. I shouldn't have to go hunting on line for it when I realise belatedly it's missing.
 
A number of php72-* modules are going to depend on lang/php72.

Code: 
# pkg info -r php72
php72-7.2.27:
        php72-calendar-7.2.27
        php72-dom-7.2.27
        php72-filter-7.2.27
        php72-gd-7.2.27
        php72-json-7.2.27
        php72-pdo_mysql-7.2.27
        php72-session-7.2.27
        php72-simplexml-7.2.27
        php72-xml-7.2.27
        php72-pdo-7.2.27
        webtrees-1.7.13
 
Yes, but as you can see www/mod_php72 isn't one of them, so it's a little odd to expect someone to install it just to get a configuration file for something that doesn't need it.

Actually, I do have lang/php72 installed in another jail, and I have now found the files I wanted there, but unless PHP is a jailbreak mechanism that shouldn't be relevant.
 
If you don't have the php.ini file, all that happens is that everything goes to defaults. It's not the end of the world, everything runs as normal and the port doesn't install it, only the template that you finally found. phpinfo() just lists whatever location it thinks you should put it.

If you're complaining that mod_php doesn't install a sample but php does... I guess technically you can just install mod_php since both of them seem to install libphp7.so, but you probably want some modules. Maintainers expect you to know what you're doing in this case 🤷‍♂️
 
msplsh said:
I guess technically you can just install mod_php since both of them seem to install libphp7.so
Click to expand...
Different locations, so there's no conflict. They can't both install /usr/local/etc/php.ini-development and /usr/local/etc/php.ini-production because that would cause a file conflict. As www/mod_php72 works just fine without a php.ini (it uses fairly sensible defaults) it's left up to the system administrator to configure it (as a lot of ports do).

Code: 
root@webtrees:~ # pkg info -l mod_php72 | grep 'libphp'
        /usr/local/libexec/apache24/libphp7.so
root@webtrees:~ # pkg info -l php72 | grep 'libphp'
        /usr/local/lib/libphp7.so
 
I wasn't aware of this but it seems mod_php actually creates a completely standalone binary of php that is loaded into Apache as a module. As such, it doesn't actually require the php port/pkg installed.

This is a fairly unlikely situation to be in though as, as SirDice says, as soon as you want to install a module, lang/phpXX will be a dependency. Due to the way the ports tend to disable all php modules by default, it's almost useless for any half serious application without at least one module.

Seeing as mod_php doesn't seem to rely on lang/php, maybe there is a plausible argument that it should install the sample ini files, although they would likely need different names to the ones installed by lang/php. Personally I would just install lang/php anyway, as it seems odd to just have mod_php installed on its own, and as mentioned any modules will require it anyway.
 
I'm not sure what the assumptions behind this are. All I know is I want to run PHP on my websites and I use PHP extensively to build site functionality. I don't need any add-ons, just the core language to code in and write my back-end functions. I was just shocked to discover by accident that the php.ini file wasn't where I expected it when I wanted to set error_reporting and display_errors globally rather than on a per-application basis and then, on further investigation, find even the sample files I'm supposed to adapt weren't there to be copied. Yes, they'd have to have different names or be in a different directory to avoid clashes, but that's trivial enough to sort out. One could even have the actual .ini in a different location to allow the CLI and web versions to be installed on the same machine with different configurations for different uses.

But it's all getting a bit academic now as I've solved the initial problem and got sensible settings in place for development and production. I know the module runs well without the file - I've used it for months without the file and my sites work well and I doubt a third party accessing would notice any difference, but it's one less thing to worry about now when I'm writing scripts, as my systems now have error handling defaults which suit their purposes. It's also enabled me to disable phpinfo on the production server, as that's obviously not something you'd want someone to see if they managed to trick the server into running it!

I don't think this could be considered solved. I'm not sure it's even soluble as there appears to be room for different opinions and we clearly don't see the issue the same way. However, I no longer need help on this issue so I'm happy to leave it here.
 
You must log in or register to reply here.
Back
Top