Hello Tim,
I was interested to read your post, as using Apache is something I've been wondering about for a while now, but never got round to testing. I work in a small team with limited support capacity. All of our other web apps are fronted by Apache, so my thinking was standardizing on Apache would be a good thing for a team of our size.
Anyway, to the problem. You didn't describe beyond "it's not working" how the problem manifests itself, but I'm going to assume you faced the same problem that I faced in my test Vagrant Ubuntu 18.04, Apache 2.4.29 box:
When visiting an AtoM URL that has PATH_INFO data, e.g. the location /index.php/informationobject/browse you get:
"403, Access denied" corresponding to
/var/log/apache2/error.log: "AH01071: Got error 'Access to the script '/var/www/html/atom/index.php/informationobject/browse' has been denied (see security.limit_extensions)"
or, if 'security.limit_extensions = ' is added to /etc/php/7.2/fpm/pool.d/atom.conf — not that it's advisable — you get:
"404, No input file specified" corresponding to
to
/var/log/apache2/error.log:
"AH01071: Got error 'Unable to open primary script: /var/www/html/atom/index.php/informationobject/browse (No such file or directory)"
The home page, /index.php is returned normally.
I'm guessing you're at the stage of getting the web installer to run. My Vagrant box is pre-configured, so I'm not confronted by the web installer, and haven't unconfigured AtoM in order to do so. However, hopefully this won't matter.
I think you were on the right lines with it being a PATH_INFO related problem. If you look at the
vanilla AtoM-Nginx config you will see a block like this:
location ~ ^/(index|qubit_dev)\.php(/|$) {
include /etc/nginx/fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_split_path_info ^(.+\.php)(/.*)$;
fastcgi_pass atom;
}
A key line here is
fastcgi_split_path_info which populates SCRIPT_NAME and PATH_INFO with the respective values from the regex capture groups. The way I approached this problem was to try to mimic what the Nginx config block is doing, in Apache, to set all the CGI variables appropriately.
A couple of things I did to set myself up for testing this are as follows:
- Type a2enmod proxy_fcgi (enable the proxy_fcgi module in Apache)
- increase logging for this module:
- Add
LogLevel proxy_fcgi:trace6 to the bottom of /etc/apache2/apache2.conf
- Traces then logged to /var/log/apache2/error.log
After much experimentation and searching, I came across the
ProxyFCGISetEnvIf directive. This allowed me to apply the CGI variable manipulations required to at least allow me to return the page /index.php/informationobject/browse successfully. Here is a barebones VirtualHost I came up with:
<VirtualHost *:80>
DocumentRoot /var/www/html/atom
KeepAliveTimeout 300
Timeout 300
ProxyFCGISetEnvIf "true" SCRIPT_NAME "/index.php"
ProxyFCGISetEnvIf "%{REQUEST_URI} =~ m|^/(index)\.php(/.*)$|" PATH_INFO "$2"
ProxyFCGISetEnvIf "true" SCRIPT_FILENAME "%{DOCUMENT_ROOT}/index.php"
ProxyPassMatch ^/(index|qubit_dev)\.php(/|$) "unix:/run/php7.2-fpm.atom.sock|fcgi://localhost:9002/var/www/html/atom"
<Directory "/var/www/html/atom">
AllowOverride All
Require all granted
</Directory>
</VirtualHost>
To see the manipulations' Before & After values, which is helpful to understand what Apache is or isn't sending to PHP, the following can be done:
Visit /index.php to generate the following log lines:
#tail -f /var/log/apache2/error.log | stdbuf -o0 grep 'fix_cgivars: override'
[proxy_fcgi:trace4] fix_cgivars: override SCRIPT_NAME from '/index.php' to '/index.php'
[proxy_fcgi:trace4]
fix_cgivars: override SCRIPT_FILENAME from 'proxy:fcgi://localhost:9002/var/www/html/atom/index.php' to '/var/www/html/atom/index.php'
Visit /index.php/informationobject/browse to generate the following log lines:
#tail -f /var/log/apache2/error.log | stdbuf -o0 grep 'fix_cgivars: override'
[proxy_fcgi:trace4]
fix_cgivars: override SCRIPT_NAME from '/index.php/informationobject/browse' to '/index.php'
[proxy_fcgi:trace4]
fix_cgivars: override PATH_INFO from '(null)' to '/informationobject/browse'
[proxy_fcgi:trace4]
fix_cgivars: override SCRIPT_FILENAME from 'proxy:fcgi://localhost:9002/var/www/html/atom/index.php/informationobject/browse' to '/var/www/html/atom/index.php'
I think from the above it's self-evident what's going on. The PATH_INFO characters were being left on the end of SCRIPT_NAME, and PHP rightly couldn't locate a script file at that location. PATH_INFO itself wasn't set when it should have been. And SCRIPT_FILENAME suffered the same fate as SCRIPT_NAME, while also oddly being prepended with proxy:fcgi://localhost:9002.
Clearly the above isn't a complete solution, but hopefully it's helpful in forging support for Apache.
I didn't note any of these kinds of CGI variable manipulations in the J Grant Forrest guide, so I'm unclear on how he got it working. However,
his guide links through to
an Apache configuration where the more modern Proxy by Handler method is used; I'm inferring from what
I've read about this method that the above manipulations may not be necessary:
You can also force a request to be handled as a reverse-proxy request, by creating a suitable Handler pass-through. The example configuration below will pass all requests for PHP scripts to the specified FastCGI server using reverse proxy. This feature is available in Apache HTTP Server 2.4.10 and later. For performance reasons, you will want to define a worker representing the same fcgi:// backend. The benefit of this form is that it allows the normal mapping of URI to filename to occur in the server, and the local filesystem result is passed to the backend. When FastCGI is configured this way, the server can calculate the most accurate PATH_INFO.
However, my testing with the Proxy by Handler method wasn't successful.
I hope you find my reply useful, and do keep us updated if you get to the point of having a production-ready configuration available; I'm sure the AtoM community will appreciate it.
Thanks, Jim
Thanks Dan!
I had previously found the blog post from J Grant Forrest about Atom 2.5 on CentOS 8 and carefully reviewed that, though my searches hadn't previously discovered your wiki. Thanks for that link. I believe I have the same Apache httpd config as described in J Grant's excellent post, but I am not getting the same results.
I did go through the last couple years worth of posts in this group tagged CentOS before posting. Many of them are CentOS but using nginx, rather than Apache httpd, and the ones that were httpd were generally about an unrelated issue and didn't provide the web server config.
I also looked at some of the earlier guides (Like the one Stefano did for RHEL 7.1), but that too does not cover the Apache httpd config.
It seems like at least a few of your clients have been able to get older versions of AtoM working with Apache httpd without much issue, which makes it all the more puzzling why we're seeing an issue. We have lots of httpd proxying to PHP-FPM for other PHP applications we run (both in-house and opensource), so it's not like this is completely new to my site. I can't remember the last time I've been this stymied by a web application.
Thanks,
Tim