PHP-FPM templates strategy?

interfasys

interfasys

Verified User
Joined
Oct 31, 2003
Messages
1,816
Location
Switzerland
I'm sure the people behind CB2.0 must have some implementation strategy they follow when writing templates.
Would it be possible to share it with us so that we better understand some of the decisions that were made regarding PHP-FPM?
This would help us understand what CB is writing where and prevent us from breaking things or opening security holes.

Examples
The team would like to use mod_proxy_fcgi everywhere but they feel it isn't possible because ProxyPassMatch is not available in a Directory directive and because RewriteRule doesn't behave properly. See bugs #, etc.
Virtualhosts are thus using mod_fastgi except for ~user which is using mod_proxy_fcgi
Template: DAtemplates/virtual_host2*.conf
Status: OK

The team has decided to use mod_proxy_fcgi for Web apps because that's what will eventually be used everywhere.
It has been decided to create as many global ProxyPassMatch lines as there are web apps so that applications can be reached via the server's IP.
Template: Not available
Status: OK

In order for PHP scripts to be able to run in /var/www/html, it's possible to add a ProxyPassMatch directive to the server's virtualhost, but for unknown, security, etc. reasons, it is not advised to do so.
Template: CB/configure/ap2/conf/extra/httpd-vhosts.conf
Status: Not implemented
Discussion: forumlink1

The team has decided to create aliases using RewriteRule for reason X
Template: Not available
Status: Not working
Discussion: forumlink2

php-fpm.conf
etc.

We can sometimes guess what is going on and by spending time reading lots of documentation, we can eventually figure it out, but it's much easier if there is a reference document, because there are lots of different templates floating in the forums, given as solutions and which may or may not work today.
 
interfasys, final implementation of PHP-FPM is available in latest versions of CB 2.0 and DA. All of the tasks are finished. Do you still have any questions?
 
Smtalk, it seems a server setup with CB2.0-RC6 which is then upgraded with CB20.-RC7 is broken on webapps. It looks like you made changes to how the sockets work, but isnt documented.
 
Do you have any templates in /usr/local/directadmin/data/templates/custom or any files in /usr/local/directadmin/custombuild/custom? If not, I'd recommend running "./build rewrite_confs" to see if it fixes your problems. There have been a lot of changes regarding PHP-FPM between versions RC6 and RC7. The way it's setup in RC7 is described here: http://httpd.apache.org/docs/current/mod/mod_proxy.html#handler
 
I'm having an issue with the template for /var/www/html. It seems some paths are not read properly by PHP and I see a lot of errors regarding PHP trying to access .htaccess in locations outside of the root.
Paths like this /.htaccess or //.htaccess /var/www/.htaccess

Any idea what would be causing this?
What's different between this template and the one put in place for users?
 
This is htscanner module causing it, and it's normal that it cannot read /.htaccess or /home/.htaccess, as these paths are not in open_basedir paths. I reported this issue to htscanner extension developer a few months ago, but received no reply yet... Are we talking about the same open_basedir errors in your logs? Thank you! :)
 
Yeah, it's normal that it can't read these paths (and it shows up in my logs as open_basedir restrictions ;)), but I don't think it's the intention of the app. I think it's trying to read there because it does not get the proper full path to the .htaccess file.
It's trying to read /var/www/html/webapp/.htaccess and somehow, PHP is trying to read /var/www//.htaccess.
I've checked and I don't see this behaviour in my users' logs, but maybe you do? Maybe it's the type of app which is creating an issue. I see errors when clients are trying to connect using WebDAV and WBXML.
 
.htaccess reading is a recursive path scan to the directory the file is in. I mean if you run apache+mod_php, it would still read /home/user/.htaccess, /home/user/domains/.htaccess and other files. As PHP-FPM is a separate process, and it does not support php_value/php_flag by default in .htaccess files, an extension doing that is installed. It's named htscanner: http://pecl.php.net/package/htscanner. And, of course, it tries to read directories recursively, like Apache does. Aren't you seeing tries to read /.htaccess in your error log (it might be shown on the same line)? There might be enhanced/patched versions of htscanner extension for PHP that I don't know of :) But the official version seems to work that way, and doesn't allow to specify where to start the recursion from (recursion start level, for example /home/user), so that open_basedir restriction error wouldn't be shown in logfiles. htscanner.default_docroot doesn't seem to affect it.
 
Aaah :) thanks for the detailed explanation.
So, yes, the DAV scripts triggers a recursion, but not the WBXML one.
The strange thing is that this wasn't happening with proxypassmatch iirc.

EDIT: I've read the doc and checked the code and
  • default_docroot is only used as a fallback, but still doesn't work for some protocols like DAV
  • the enhanced version is a tool for hosts who don't give their users access to /home/user so that they can inject PHP settings into their users' apps

So the best thing to do would be to try and figure out why some scripts don't have access to _SERVER["DOCUMENT_ROOT"] since it's difficult to disable htscanner since that's the only way to modify PHP settings for a domain.
 
Last edited:
The root cause of it has been found:
Code: 
if (!strncmp(doc_root, cwd, doc_root_len))
            i = doc_root_len - 1;

This code fails in htscanner.c, because of incorrect SCRIPT_FILENAME set in PHP environment (when running PHP-FPM). It starts with "//" instead of "/", so htscanner takes incorrect cwd. Please try the following to see it:
Code: 
<?php
echo $_SERVER['SCRIPT_FILENAME'];
?>
 
smtalk said:
The root cause of it has been found:
Code: 
if (!strncmp(doc_root, cwd, doc_root_len))
            i = doc_root_len - 1;

This code fails in htscanner.c, because of incorrect SCRIPT_FILENAME set in PHP environment (when running PHP-FPM). It starts with "//" instead of "/", so htscanner takes incorrect cwd. Please try the following to see it:
Code: 
<?php
echo $_SERVER['SCRIPT_FILENAME'];
?>
Click to expand...
Yep, // everywhere... Did you track down the bug on php.net?
 
smtalk said:
No, I searched which place causes it and I've found it :) http://httpd.apache.org/docs/current/mod/mod_proxy.html#handler. If "/" is removed from the end of the line, it fixes the SCRIPT_FILENAME. I'm now checking if that's a typo in Apache documentation or PHP-FPM SAPI path translation.
Click to expand...
Good find. Because of this, I think it might be a documentation error and the trailing slash doesn't matter
Note

Because SetHandler overrides default handlers, normal behavior such as handling of URLs ending in a slash (/) as directories or index files is suppressed.
Click to expand...

And I see that you've reported it :)
https://bugs.php.net/bug.php?id=67998

And there is a new patch for mod_proxy_fcgi
https://bugs.php.net/patch-display...._for_mod_proxy_fcgi.patch&revision=1409922889
 
I received an answer from PHP developers, it seems the last trailing slash shouldn't be there :) While Apache developers say it should be fixed in PHP-FPM SAPI, so that it would work normally with a trailing slash at the end too. So, I think the easiest fix for now is not to use trailing slash at the end :)
 
smtalk said:
I received an answer from PHP developers, it seems the last trailing slash shouldn't be there :) While Apache developers say it should be fixed in PHP-FPM SAPI, so that it would work normally with a trailing slash at the end too. So, I think the easiest fix for now is not to use trailing slash at the end :)
Click to expand...
I agree. Even though I've removed htscanner (it's just not the right way to do things in 2014), I've updated my templates since that // might generate other, hidden issues.
 
You must log in or register to reply here.
Back
Top