Hi Stuart, thanks for your response. Please see my inline comments below…
> Am 10.07.2023 um 13:26 schrieb Stuart Henderson <stu.li...@spacehopper.org>: > > (moving to ports@, reply-to set) > > > On 2023-07-10, Mike Fischer <fischer+o...@lavielle.com> wrote: >> Hi! >> >> I’m trying to figure out the best way to maintain multiple php-fpm setups at >> the same time and ran into a somewhat annoying issue. >> >> I’m not sure how many other users might have a similar situation? If this >> something too non-standard, let me know and I’ll shut up ;-) >> >> >> Background >> ========== >> >> The server supports multiple versions of PHP for websites using php-fpm. >> There are also multiple web servers running at the same time (on different >> IP/port combinations obviously). Specifically OpenBSD httpd and Apache httpd >> from ports. >> >> OpenBSD httpd runs in its normal chroot(2) environment. Apache httpd does >> not use chroot(2). This requires corresponding setups for php-fpm as well. >> Using e.g. a non-chroot(2) php-fpm with OpenBSD httpd does not work. >> >> Each php-fpm variant uses its own socket. So changing the PHP version for a >> web server (or even for just certain paths on that server) is as easy as >> pointing to the correct socket for the FastCGI mechanism of the web server. >> >> >> Setup >> ===== >> >> All available PHP Versions are supported and configured. I.e. 7.4, 8.0, 8.1 >> and 8.2 for OpenBSD 7.3. >> >> I have adjusted /etc/php-7.4.ini, /etc/php-8.0.ini, etc. as required >> >> I have created and modified /etc/php-fpm-7.4cr.conf, >> /etc/php-fpm-7.4ncr.conf, /etc/php-fpm-8.0cr.conf, /etc/php-fpm-8.0ncr.conf, >> etc. The default /etc/php-fpm.conf is not actively used. >> >> I have copied the /etc/rc.d/phpXX_fpm files and modified them to: >> - use the appropriate /etc/php-fpm.conf (/etc/php-fpm-7.4cr.conf, >> /etc/php-fpm-7.4ncr.conf, /etc/php-fpm-8.0cr.conf, /etc/php-fpm-8.0ncr.conf, >> etc.) >> - use the appropriate /etc/php.ini (/etc/php-7.4.ini, /etc/php-8.0.ini, >> /etc/php-8.1.ini and /etc/php-8.2.ini) >> - adjust the pexp to match the php-fpm.conf in addition to "php-fpm-7.4: >> master process", e.g. "php-fpm-7.4: master process >> .*/etc/php-fpm-7.4cr.conf.*", etc. >> >> Thus I have: >> /etc/rc.d/php74cr_fpm >> /etc/rc.d/php74ncr_fpm >> /etc/rc.d/php80cr_fpm >> /etc/rc.d/php80ncr_fpm >> /etc/rc.d/php81cr_fpm >> /etc/rc.d/php81ncr_fpm >> /etc/rc.d/php82cr_fpm >> /etc/rc.d/php82ncr_fpm >> >> And all of these have been enabled using `rcctl enable php74cr_fpm >> php74ncr_fpm php80cr_fpm php80ncr_fpm php81cr_fpm php81ncr_fpm php82cr_fpm >> php82ncr_fpm` and of course started using `rcctl start …`. >> >> For example: >> # cat /etc/rc.d/php82cr_fpm >> #!/bin/ksh >> >> daemon="/usr/local/sbin/php-fpm-8.2" >> daemon_flags="-c /etc/php-8.2-cr.ini -y /etc/php-fpm-82cr.conf" >> >> . /etc/rc.d/rc.subr >> >> pexp="php-fpm-8.2: master process .*/etc/php-fpm-82cr.conf.*" >> rc_reload=NO >> >> rc_cmd $1 >> # >> >> >> (Note: I know this could be further reduced to just one master process for >> each version with a chroot(2) and a non-chroot(2) pool defined in the single >> php-fpm.conf for each PHP version. But that is irrelevant to the issue at >> hand.) > > Actually I think that is relevant. At least, if you just had one running > php-fpm daemon per version, you totally avoid the problem. That would only solve the chroot/non-chroot problem, not the multiple versions of PHP. If you want, then just reduce my issue to one web server (either one). Then this is indeed irrelevant as I stated. > >> >> Issue >> ===== >> >> `rcctl ls started` lists php74_fpm, php80_fpm, php81_fpm and php82_fpm as >> started even though they are neither enabled nor started! >> >> The reason this happens is the pexp which is too general. E.g. for php74_fpm >> it is pexp="php-fpm-7.4: master process .*" >> >> Modifying this to e.g. pexp="php-fpm-7.4: master process >> .*/etc/php-fpm.conf.*" solves the problem. >> >> BUT: /etc/rc.d/php74_fpm will be overwritten when the php-7.4 port ist >> updated. (Same for the other versions of course.) So my change is lost and >> has to be reapplied. If I forget about this then at a later time I’ll become >> confused by the output of `rcctl ls started`. >> >> >> Questions >> ========= >> >> 1) Is there a better, update-proof way to solve this problem? > > With a single daemon per version, remove the extra added phpXX_fpm > copies, instead follow the suggestion after "If you need to run multiple > versions of PHP on one machine" in php's pkg-readme. Actually that is effectively what I did. Ok to be fair the strict pkg-readme method would store the config file paths in /etc/rc.conf.local which means the scripts in /etc/rc.d/ do not need to be modified. That does help with the update issue but then I loose my settings when I disable and later re-enable the service. So it opens another issue. > >> 2) Would it make sense to include the more specific pexp in the PHP ports? >> (I don’t think doing so would hurt the default use case, but maybe I’m >> overlooking something?) > > This is a bit awkward to do; the rc script would then need to > parse the phpXX_fpm_flags variable and figure out what string php-fpm > will use when it sets the process name (i.e. look for -y or --fpm-config > and parse them the same way that php-fpm itself does). No not really. Just adding »/etc/php-fpm.conf.*« to the pexp in the default rc.d script for the PHP version works for all versions of php-fpm and solves the problem. E.g.: pexp="php-fpm-8.2: master process .*/etc/php-fpm.conf.*“ But this change also gets lost with each update if it isn’t applied to the ports. > Yes it is possible to do that, but it's definitely more fragile, and > considering that the main purpose of php-fpm is to run multiple copies > of php for different environments anyway, it seems a bit redundant to > run multiple copies of the same version of php-fpm. As I stated above ignore that aspect of my setup. Let’s reduce this to just running multiple versions of PHP. > Though the existing pexp is slightly less flexible, IMHO it's enough for > most use cases, and it doesn't really seem worth the extra fragility to > do this differently. Is my suggestion really more fragile? Is there any chance the default install would not use /etc/php-fpm.conf as the php-fpm config file? Ok, I do see that someone strictly using the pkg-readme method would run into issues as the matched pattern would not always match the the manually configured config file. So I guess I’m left with the strict pkg-readme method, /etc/rc.conf.local and the fact that my settings get lost on disable. Sigh… Maybe I need to write scripts to enable the services and automatically restore the settings. Something like: # cat /root/bin/enable_php74_fpm.sh #!/bin/sh service='php74_fpm' /usr/sbin/rcctl enable "$service" && \ /usr/sbin/rcctl set "$service" flags '-c /etc/php-7.4.ini -y /etc/php-fpm-74.conf' # EOF. # cat /root/bin/enable_php80_fpm.sh #!/bin/sh service='php80_fpm' /usr/sbin/rcctl enable "$service" && \ /usr/sbin/rcctl set "$service" flags '-c /etc/php-8.0.ini -y /etc/php-fpm-80.conf' # EOF. # cat /root/bin/enable_php81_fpm.sh #!/bin/sh service='php81_fpm' /usr/sbin/rcctl enable "$service" && \ /usr/sbin/rcctl set "$service" flags '-c /etc/php-8.1.ini -y /etc/php-fpm-81.conf' # EOF. # cat /root/bin/enable_php82_fpm.sh #!/bin/sh service='php82_fpm' /usr/sbin/rcctl enable "$service" && \ /usr/sbin/rcctl set "$service" flags '-c /etc/php-8.2.ini -y /etc/php-fpm-82.conf' # EOF. # Then I only need to remember to use the script instead of the standard rcctl enable phpXX_fpm. But at least I don’t need to memorize the flags for each version. Thanks for your help! Mike
