You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 6, 2023. It is now read-only.
I'm not quite following the logic with the paths given in the explanation in this man page under php-fpm
cp /usr/share/defaults/php/php-fpm.conf /etc/php-fpm.conf
Why dump php-fpm.conf directly in /etc/ ?
To maintain consistency, why is it not suggested just copy the default directory and contents /usr/share/defaults/php/
to /etc/
With: cp -R /usr/share/defaults/php /etc/
then run: systemctl edit --full php-fpm.service
Then, the user should remove the line: ExecStart=/usr/sbin/php-fpm --nodaemonize
Then add these lines under [service]: ExecStart=/usr/sbin/php-fpm --nodaemonize --fpm-config /etc/php/pear.conf ExecStart=/usr/sbin/php-fpm --nodaemonize --fpm-config /etc/php/php-fpm.conf ExecStart=/usr/sbin/php-fpm --nodaemonize --fpm-config /etc/php/php-fpm.d/www.conf ExecStart=/usr/sbin/php-fpm --nodaemonize --fpm-config /etc/php/php.ini
Then modify /etc/php/php-fpm.conf and under Pool Definitions section at bottom add: include=/etc/php/php-fpm.d/*.conf
Wouldn't this achieve user configuration of ALL the php-fpm conf files and maintain exactly the same dir and file structure of the system defaults?
Also, this is quite a bit of a hassle, couldn't developers write additional scripts, include them in the php-basics bundle, so when user run swupd bundle-add php-basic these scripts perform all the tasks to configure and place the default php-fpm configuration files in /etc.
Probably the nginx-mainline should also have install script so run and add the conf files to /etc.
The idea of stateless I assume relates to system and swupdate, once a user decides to install a bundle the install should preconfigure in the expectation the user will actually need to custom configure and so this case, what we do with configs should't be going against stateless.
I suppose these script are only needed for php-fpm because it is not bendable to CL
s stateless and requires forced intervention, and nginx-mainlne, well that's a given to be custom configured.
I mention some of these concerns and observations here:
I'm not quite following the logic with the paths given in the explanation in this man page under php-fpm
cp /usr/share/defaults/php/php-fpm.conf /etc/php-fpm.conf
Why dump php-fpm.conf directly in
/etc/
?To maintain consistency, why is it not suggested just copy the default directory and contents
/usr/share/defaults/php/
to
/etc/
With:
cp -R /usr/share/defaults/php /etc/
then run:
systemctl edit --full php-fpm.service
Then, the user should remove the line:
ExecStart=/usr/sbin/php-fpm --nodaemonize
Then add these lines under [service]:
ExecStart=/usr/sbin/php-fpm --nodaemonize --fpm-config /etc/php/pear.conf
ExecStart=/usr/sbin/php-fpm --nodaemonize --fpm-config /etc/php/php-fpm.conf
ExecStart=/usr/sbin/php-fpm --nodaemonize --fpm-config /etc/php/php-fpm.d/www.conf
ExecStart=/usr/sbin/php-fpm --nodaemonize --fpm-config /etc/php/php.ini
Then modify /etc/php/php-fpm.conf and under Pool Definitions section at bottom add:
include=/etc/php/php-fpm.d/*.conf
Wouldn't this achieve user configuration of ALL the
php-fpm
conf files and maintain exactly the same dir and file structure of the system defaults?Also, this is quite a bit of a hassle, couldn't developers write additional scripts, include them in the php-basics bundle, so when user run swupd bundle-add php-basic these scripts perform all the tasks to configure and place the default php-fpm configuration files in
/etc
.Probably the nginx-mainline should also have install script so run and add the conf files to
/etc
.The idea of stateless I assume relates to system and swupdate, once a user decides to install a bundle the install should preconfigure in the expectation the user will actually need to custom configure and so this case, what we do with configs should't be going against stateless.
I suppose these script are only needed for php-fpm because it is not bendable to CL
s stateless and requires forced intervention, and nginx-mainlne, well that's a given to be custom configured.
I mention some of these concerns and observations here:
https://community.clearlinux.org/t/php-fpm-is-it-excluded-from-the-stateless-paradigm-and-not-going-to-be-overwritten-by-swupd/1607/21
The text was updated successfully, but these errors were encountered: