Php-fpm is it excluded from the stateless paradigm and not going to be overwritten by swupd?

Thanks for reply puneetse.

My question here now is to query again, the question asked in initial post:

Have the Clear Linux developers added specific swupd exclusions to the default php configuration files?

It has been identified in this thread that php is programmed to only read the builtin file and we discovered earlier that over-riding the conf files when located outside default locations such as /etc were ignored.

Clear Linux Developers performed some fixes and updated php to resolve these issues.

But, did they at the same time add specific php-fpm swupd exclusions so these default php builtin files are forever SAFE from swupd in the case the user prefer to edit these built in files?? User may not like idea of maintaining copied conf files in locations outside default as it is probably easier to maintain built in filesā€¦Probably this is ok on other distros but here swupd presents a particular danger.

I paste the specific php-fpm note from man stateless below so search engines pick it up and this information be exposed and visible to future users, it is great for building the Clear Linux knowledge base I feel.

php-fpm
          php-fpm(8)

       Php's  default  configuration file doesn't allow us to provide an alternative as it is programmed to only read the builtin file. If you wish to have php-fpm use a different configuration, you must
       pass it a startup option to tell it where it is. This can be done by systemctl edit --full php-fpm.service. That command copies the default php-fpm service unit to /etc/systemd/system/ and  allows
       the user to override any option. It spawns an editor with the copy.

       Then, the user should change the line:
          ExecStart=/usr/sbin/php-fpm --nodaemonize

       to:
          ExecStart=/usr/sbin/php-fpm --nodaemonize --fpm-config /etc/php-fpm.conf

       The template php-fpm.conf can be found at /usr/share/defaults/php/php-fpm.conf.  One should copy this to a place in /etc/:
          cp /usr/share/defaults/php/php-fpm.conf /etc/php-fpm.conf

       Then, the user should edit /etc/php-fpm.conf and assure that configuration options are all properly set as needed.

       Care  must be taken using the default pool configuration. If needed, the user should also create /etc/php-fpm.d/ and include pool configuration files from either /usr/share/defaults/php/php-fpm.d/
       or copy them and modify them as needed as well, as well as adjust the include configuration option in php-fpm.conf to point to a new location for pool configuration files.

I have another thought about the implications of stateless involving both php-fpm and nginx-mainline concerning the associated inconveniences where it is necessary for a user to make all these changes to get config files in user work space i.e /etc.

We know a fresh Clear Linux install does not populate /etc and it is ear marked as user config area.

Is it against the rules of stateless or is there wiggle room in the stateless concept to allow these unique rigid services such as php-fpm and nginx-mainline to populate /etc with config files on install?

If no-one is motivated to approach PHP developers or on the other hand PHP developers have been approached and refused to address the issues of their strict built in config file locations, would there be motivation for Clear Linux developers to take matters in their own hand and create a packaging solution to work around php limitations and nginx default setup?

I know this may cost Clear Linux developers some extra efforts, but wouldnā€™t it be worthwhile exploring the possibility to configure the php-fpm and nginx-mainline bundles with additional scripts so that on install the bundle automatically (in case of php-fpm) runs commands to copy the default php-fpm service unit to /etc/systemd/system/

Changes:
ExecStart=/usr/sbin/php-fpm --nodaemonize
to:
ExecStart=/usr/sbin/php-fpm --nodaemonize --fpm-config /etc/php-fpm.conf

Copies all the default location conf files to /etc including the pool confs?

Essentially have the bundle perform all the tasks mentioned in man stateless for php-fpm and nginx-mainline resulting in, after bundle install, an auto prepared environment ready for user to add their unique configuration options.

This would eliminate much of the guess work and save users so much time trying to find the information because surely a user is not going to be looking first in man stateless for these answers.

Same with nginx-mainline, thereā€™s underlying, and initially unknown complications this causes with tools like Cerbo. nginx-mainline wonā€™t let users auto renew because Certbot is looking only for nginx and creates vague errors when not found nginx in default location. Instead we installed nginx-mainline, it has a different binary name and in different location to nginx and Certbot hasnā€™t a clue and neither do users, until we ask the knowledgable Clear Linux developers who do have answers.

Sadly, most system admins (all the ones I experience with) are not interested to dig deeper and find out why, they just give up and conclude nginx-mainline is not compatible with Certbot, sorry ā€˜canā€™t help youā€™.

Probably thereā€™s a few things that can be done to resolve this, deprecate nginx bundle, replace with nginx-mainline and rename nginx-mainline to be known to the system as nginx.

or

Configure any other bundle that can use nginx with directives to acknowledge and look for nginx-mainline.

Iā€™m not quite sure I understood you completely. But there arenā€™t any special exceptions for php-fpm configuration files. It adheres to the same stateless design in that if you modify the default file under /usr it can get overwritten by swupd. The correct approach on Clear Linux is to make a file in /etc (and in the special case of php-fpm modify the systemd unit to use it).

Kind of, but not really. There are some core programs which do this on first boot out of necessity and maybe a handful of exceptions with more complex platforms like Kubernetes. Part of the philosophy of statelessness is to avoid clutter and confusion between system files and user files so these exceptions should be rare.

Stateless is just a design choice by Clear Linux and is ingrained throughout the distro.

I think making nginx-mainline the default /usr/bin/nginx is a good suggestion. nginx recommends the mainline version too. Announcing NGINX 1.6 and 1.7 as Stable & Mainline Versions
Can you post it on GitHub so we can tease out the idea implications of changing in detail?