1
Development and Code Review / Re: Why php-cgi with lighty fcgi wrapper instead of php-fpm?
« on: February 16, 2017, 11:40:05 pm »
Ok, got it. Will probably look at it when free time allow
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
2
Development and Code Review / Re: Why php-cgi with lighty fcgi wrapper instead of php-fpm?
« on: February 15, 2017, 01:00:38 am »
Thanks for your reply and architecture link, AdSchellevis, interesting read. Definitely like the way you guys are going! Do you have any ETA for complete transition to configd?
Back to current state, could you please explain, why lighty would still need root privs even with php-fpm?
I mean, it is perfectly clear that php itself currently needs root due to legacy code, and that it is inevitable until transition to configd is completed. However for lighty itself I see only one reason for it to keep running as root after initial startup and socket creation - to be able to spawn php-cgi workers under root.
With php-fpm this would no longer be the case, it would spawn and manage its workers on its own. All lighty would have to do then is to communicate with fpm via unix-socket, which could be configured with any mode/owner/group independently (it may easily be lighty:lighty 0600 while having php workers running as 0:0). The last thing would be to adjust FS permissions so lighty would be able to serve static files on read-only basis.
Am I missing something here?
I really encourage you to consider switching to php-fpm at least for stability. Old php-cgi is almost obsolete as far as I'm aware, fpm on the contrary became very widespread since its inclusion in php-core and is actively maintained. Personally I have been using it for 5-or-so years with almost 0 issues (except one regression case long ago on 5.3 branch).
Ofc fpm setup would be slightly more complex than current one, but that just a little bit. The biggest difference would be that you have to add startup script for it and reconfigure lighty to use fpm socket, not a big deal)
Back to current state, could you please explain, why lighty would still need root privs even with php-fpm?
I mean, it is perfectly clear that php itself currently needs root due to legacy code, and that it is inevitable until transition to configd is completed. However for lighty itself I see only one reason for it to keep running as root after initial startup and socket creation - to be able to spawn php-cgi workers under root.
With php-fpm this would no longer be the case, it would spawn and manage its workers on its own. All lighty would have to do then is to communicate with fpm via unix-socket, which could be configured with any mode/owner/group independently (it may easily be lighty:lighty 0600 while having php workers running as 0:0). The last thing would be to adjust FS permissions so lighty would be able to serve static files on read-only basis.
Am I missing something here?
I really encourage you to consider switching to php-fpm at least for stability. Old php-cgi is almost obsolete as far as I'm aware, fpm on the contrary became very widespread since its inclusion in php-core and is actively maintained. Personally I have been using it for 5-or-so years with almost 0 issues (except one regression case long ago on 5.3 branch).
Ofc fpm setup would be slightly more complex than current one, but that just a little bit. The biggest difference would be that you have to add startup script for it and reconfigure lighty to use fpm socket, not a big deal)
3
Development and Code Review / Why php-cgi with lighty fcgi wrapper instead of php-fpm?
« on: February 13, 2017, 02:43:23 am »
Hi, guys.
Just installed OPNSense in a VM for testing and was quite surprised to see it running php-cgi instead of fpm. Why so?
Ofc, firewall/router webface isn't intended nor required to serve 100s of rps, so fpm performance optimizations aren't that relevant here, but what about stability and security? Personally I thought cgi-fcgi (don't confuse with fpm-fcgi) sapi was long ago obsolete and probably even dropped, however now I can see its still maintained, but how actively?
Also wouldn't it be better to run fcgi manager as separate process and then completely drop root privs from lighty as the first step to complete and proper priv separation? Having daemon listening public socket running as root just makes me a bit uncomfortable, even though it is behind packet filter)
And same question for lighty vs nginx.
I have nothing against lighty, actually have almost no experience with it at all. Just curious, was it intended and though-about migration or it just was inherited from parent sense and left intact?
Just installed OPNSense in a VM for testing and was quite surprised to see it running php-cgi instead of fpm. Why so?
Ofc, firewall/router webface isn't intended nor required to serve 100s of rps, so fpm performance optimizations aren't that relevant here, but what about stability and security? Personally I thought cgi-fcgi (don't confuse with fpm-fcgi) sapi was long ago obsolete and probably even dropped, however now I can see its still maintained, but how actively?
Also wouldn't it be better to run fcgi manager as separate process and then completely drop root privs from lighty as the first step to complete and proper priv separation? Having daemon listening public socket running as root just makes me a bit uncomfortable, even though it is behind packet filter)
And same question for lighty vs nginx.
I have nothing against lighty, actually have almost no experience with it at all. Just curious, was it intended and though-about migration or it just was inherited from parent sense and left intact?
Pages: [1]