Category Archives: Apache

Software Collections Apache 2.4.25 but no HTTP/2 with Firefox

Posted on by

It took a bit of working out but Apache version 2.4.25 from softwarecollections.org is compiled against OpenSSL 1.0.1. Unfortunately that means it doesn’t support the ALPN TLS extensions that are required for Firefox/Chrome to use HTTP/2 with a web site.

There is a newer version in testing (2.4.27) which is compiled against 1.0.2 and that does work 🙂

The following updates a system but as it’s a non-release version you’ll need to consider whether you want to run it or not.

yum --enablerepo=centos-sclo-rh-testing update httpd24 httpd24-httpd httpd24-nghttp2 httpd24-mod_ssl httpd24-runtime httpd24-libnghttp2 httpd24-httpd-tools

This version is in testing for RHSCL version 3.0 apparently.

https://www.redhat.com/archives/sclorg/2017-October/msg00012.html

 

Apache change to ‘event’ mode

Posted on by

This is certainly going to make things more interesting at work for a while where we use mod_php a lot! When I say a lot I mean all bar one line of business application uses it.

https://blog.remirepo.net/post/2017/11/17/Fedora-27-changes-in-http-and-php

Switch of the Apache HTTP server in event mode

Since the first days of the distribution, the severs use the prefork MPM.

For obvious performance reasons, we choose to follow the upstream project recommendations and to use the event MPM by default.

This change is also required to have the full benefit and feature of the HTTP/2 protocol via mod_http2.

Switching the servers from prefork and mod_php to event and php-fpm going to take some work and some thinking as to how it can be scripted. We have hundreds of web sites (and PHP settings per site using php_admin_value/php_value Apache commands) and this change will make it to RHEL 8 I guess.

WordPress auto updates not working

Posted on by

So for the last few days we’ve been waiting for WordPress to auto update on some work web sites having installed the Auto Updates plug-in and activating it. All it does is enable some built in functions in WordPress using a nice web designer accessible way.

No joy though 🙁

The plug-ins and themes that were waiting to be updated were still waiting.

I was then able to find this plug-in from WordPress – Background Update Tester – via a post by Wendy Cholbi.

It was a bit worrying that it hadn’t been updated for a couple of years but as this is being tested on a staging site I wasn’t overly concerned if the site broke. The fact that it was written by WordPress themselves was an added plus that it was less likely to cause issues.

Installing it added an extra link under the Dashboard option called Update Tester which lead to a status page and that said;

PASS: Your WordPress install can communicate with WordPress.org securely.
PASS: No version control systems were detected.
FAIL: Your installation of WordPress prompts for FTP credentials to perform updates. (Your site is performing updates over FTP due to file ownership. Talk to your hosting company.)

A nice error message that I could resolve 🙂

A quick SSH to the web server to check the user permissions on the files and they were all owned by one of our in-house web developers.

chown apache -R *
chmod -R g+w *

Refresh the page and everything looks good for future auto-updating

Dashboard :: Update Tester page shows;

Automatic background updates require a number of conditions to be met.

PASS: Your WordPress install can communicate with WordPress.org securely.
PASS: No version control systems were detected.
PASS: Your installation of WordPress doesn’t require FTP credentials to perform updates.
PASS: All of your WordPress files are writable.

And the Dashboard :: Updates page says;

You have the latest version of WordPress. Future security updates will be applied automatically.

I don’t like that I have to make the files updatable by the Apache user (and the web server). That to me opens up the possibility of a security issue in the future but on balance waiting on over worked web developers to update the WordPress installation is a bigger issue.

NextCloud PHP errors

Posted on by

After updating NextCloud to 10.0.2 I was getting a ton of errors in my log files and the NextCloud desktop client wouldn’t sync;

[Tue Dec 27 15:47:11.548182 2016] [proxy_fcgi:error] [pid 20114] [client <IP address>:58648] Invalid status line from script ‘<filename>.jpg': 0

I had this with 10.0.1 but I just ignored it and reverted to 10.0.0 as I didn’t have time to look in to it.

With the Christmas break I was able to and 5 minutes later I found this;
https://help.nextcloud.com/t/unable-to-access-directories-starting-with-a-hash-sign/6308/4

The issue appears to be down to the way that PHP-FPM was being accessed by Apache.

I was using something similar to;

ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://127.0.0.1:$port/var/www/owncloud/\

Changing it to the following enabled NextCloud to work fine (again)

<FilesMatch \.php$>
  SetHandler "proxy:fcgi://127.0.0.1:$port"
</FilesMatch>

I’m assuming something changed in the code which impacted the above as none PHP files are accessed through a PHP script but I’m just glad its working again.