SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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
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.
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
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.
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
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.
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)...
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.
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
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
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 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
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.