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
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.confWhy 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.serviceThen, the user should remove the line:
ExecStart=/usr/sbin/php-fpm --nodaemonizeThen add these lines under [service]:
ExecStart=/usr/sbin/php-fpm --nodaemonize --fpm-config /etc/php/pear.confExecStart=/usr/sbin/php-fpm --nodaemonize --fpm-config /etc/php/php-fpm.confExecStart=/usr/sbin/php-fpm --nodaemonize --fpm-config /etc/php/php-fpm.d/www.confExecStart=/usr/sbin/php-fpm --nodaemonize --fpm-config /etc/php/php.iniThen modify /etc/php/php-fpm.conf and under Pool Definitions section at bottom add:
include=/etc/php/php-fpm.d/*.confWouldn't this achieve user configuration of ALL the
php-fpmconf 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