LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   PHP configuration files location (http://www.linuxquestions.org/questions/slackware-14/php-configuration-files-location-4175471210/)

yenn 07-28-2013 10:55 AM

PHP configuration files location
 
Since there are alternative webservers (Lighttpd and Nginx) available in Slackware, I think we should also change default configuration files path. So far it's
Code:

/etc/httpd/php.ini-production
/etc/httpd/php.ini-development

which doesn't make sense if someone uses Lighty or Nginx. In Lighty Slackbuild README it's even stated
Code:

1) Copy the php.ini from /etc/httpd to /etc/lighttpd
which doesn't make sense either for the same reason. Better solution would be move these configuration files to webserver independent directory as seen in other distributions (eg. Gentoo) and let any webserver use it from default location. I suggest:
Code:

/etc/php/
Also note that PHP-FPM already has reasonable path
Code:

/etc/php-fpm/
/etc/php-fpm/php-fpm.conf.default

Another nice-to-have feature would be separation of configuration files for different php interpreters - php (cli) and php-cgi. It's useful if you have to maintain few system administration scripts in php (which I inherited from previous administrator) and you have different configuration for cli and fastCGI (hardened*).

See Gentoo directory structure
Code:

# ls /etc/php/
cgi-php5.3  cgi-php5.4  cli-php5.3  cli-php5.4  fpm-php5.4
# ls /etc/php/cgi-php5.4/
php.ini

So what do you think?

* Stripped of exec, system and similar functions on which cli scripts relies.

ponce 07-28-2013 12:08 PM

the default configuration file location (hardcoded in the interpreter at build time) is
Code:

/etc/httpd/php.ini
and personally I don't have any problem in using that, as long as I know it's there (/etc/php/php.ini should be ok too).

Quote:

Originally Posted by yenn (Post 4998359)
In Lighty Slackbuild README it's even stated
Code:

1) Copy the php.ini from /etc/httpd to /etc/lighttpd
which doesn't make sense either for the same reason.

it depends how you execute it: if you follow the example provided in the README.SLACKWARE you cited, then php is used with mod_fastcgi and invoked with
Code:

/usr/bin/php-cgi -c /etc/lighttpd/php.ini
so it makes perfect sense.

Quote:

Another nice-to-have feature would be separation of configuration files for different php interpreters - php (cli) and php-cgi. It's useful if you have to maintain few system administration scripts in php (which I inherited from previous administrator) and you have different configuration for cli and fastCGI (hardened*).
still I think it depends on the invocation so it shouldn't be strictly necessary.

yenn 07-28-2013 02:04 PM

Quote:

Originally Posted by ponce (Post 4998390)
it depends how you execute it: if you follow the example provided in the README.SLACKWARE you cited, then php is used with mod_fastcgi and invoked with
Code:

/usr/bin/php-cgi -c /etc/lighttpd/php.ini
so it makes perfect sense.

Yes, that way it make sense and it definitely works. But my point is, from semantic point of view it's bad idea put php.ini to /etc/<webserver_of_choice> no matter which one or keep php.ini for each webserver you have installed. Besides that, in my opinion any unix/linux user (without Slackware specific knowledge) would look first at /etc/php not /etc/httpd as configuration is usually stored in /etc/<program_name> and php is shared between all webservers. It happened to me once or twice too even though I use Slack almost exclusively.

Quote:

Originally Posted by ponce (Post 4998390)
still I think it depends on the invocation so it shouldn't be strictly necessary.

Of course, I use it that way with custom config file, but it would be more convenient to use default locations.

ponce 07-28-2013 03:15 PM

I use both apache and lighttpd, and in my opinion having separate php.ini files for the two is a good thing as, for example, I use different php extensions with each one, and following this, having them in the webserver folder instead of a shared one seems to me more intuitive and ordered.

In some (rare) situations I instead prefer to use php-fpm and provide it for both the webservers: in this case the above hardcoded /etc/httpd/php.ini file is used and, as I told above, it's not important for me where it is as long as I know its default location: frankly is not that important for me if this is different from other distros, as they already have other configuration files in different places (like /etc/apache2 instead of /etc/httpd, and so on)...

ppr:kut 07-29-2013 02:04 AM

The common way to do this seems to be putting php.ini in /etc. Note that /etc/php is no suitable place for the main ini file as that is the lookup path for *additional* configuration, like ini files installed by pecl extensions.

Also, php has an integrated way to provide different ini files for different SAPI modules, it looks for them however in the same directory as the main ini file. And this is where semantics go a bit weird. /etc/httpd/php-cli.ini doesn't really make a lot of sense, yet this is what php on slackware looks for when called from the command line.

yenn 08-03-2013 09:01 PM

Quote:

Originally Posted by ppr:kut (Post 4998683)
The common way to do this seems to be putting php.ini in /etc. Note that /etc/php is no suitable place for the main ini file as that is the lookup path for *additional* configuration, like ini files installed by pecl extensions.

Well, it depends on paths set during build (--with-config-file-scan-dir). But I don't know which one is the right "PHP way" of building/configuring interpreter.

And as there could be more php.ini files (php{-cgi,-fpm}.ini), I'd rather place them in separate directory (/etc/php), like for example
Code:

/etc/ssh/sshd_config
/etc/ssh/ssh_config

#instead of

/etc/sshd_config
/etc/ssh_config

but I could live with it.

Quote:

Originally Posted by ppr:kut (Post 4998683)
Also, php has an integrated way to provide different ini files for different SAPI modules, it looks for them however in the same directory as the main ini file.

I looked into gentoo ebuild and it seems that they build binaries for each SAPI in separate run, therefore it's possible to have separated php.ini and extensions .ini files for each SAPI like this

Code:

--with-config-file-path=/etc/php/cgi-php5.4
--with-config-file-scan-dir=/etc/php/cgi-php5.4/ext-active

I guess PHP in Slackware is build in one run, so every SAPI has same default values
Code:

--with-config-file-path=/etc/httpd
--with-config-file-scan-dir=/etc/php


ppr:kut 08-05-2013 06:41 AM

I don't see what building every SAPI separately brings to the table. Having separate config directories for every possible SAPI is a bit overkill.

Re /etc/php, the main problem there is that it is already used for a different purpose, and repurposing it (and introducing something like /etc/php.d) would cause a lot of required manual updating because the *.new handling of the doinst.sh won't work with that initially. And I'm not sure that using anything but /etc/php for a config directory name would solve any confusion we have now with /etc/httpd.

Also having many config files for php is really a corner case, contrary to ssh. You don't *need* a separate php-cli.ini since php-cli will pick up the main php.ini just fine. Only when you want it to contain explicitely different settings does it make sense to have it, which really only a small group of people will ever want. And I'm sure that group won't mind having slight duplication in /etc.

I do get the sentiment about /etc/httpd though.

yenn 08-10-2013 05:39 PM

I looked a little bit under the hood of PHP and figured few things regarding different SAPI:

1) Either we could build standalone interpreter for each SAPI with all libraries and extensions included, which leads to having installed same libraries N times.

2) Or use PHP as it is, while use different config file per application via command line parameter if needed.

My previous train of though was probably spoiled by Gentoo slots system and meta-distribution approach to everything. Now I agree that building separate binaries for each SAPI is overkill.

Well, we could do some sort of bash black magic that Gentoo packagers do, but I don't really understand what these particular builds scripts do and how they manage to build PHP, so I would rather stay out of this road :)


All times are GMT -5. The time now is 06:01 AM.