I have recently moved this, and a bunch of other sites I host, over to new infrastructure.
Unfortunately, for reasons I won’t bore you with (mainly because I’ve not yet figured them out), the standard ip-tables ban action in fail2ban has stopped working. However, since I am already behind a firewall, all I really need is to block the script kiddie attacks for the various website logins.
I already have some filters for this, so I wrote some quick actions to add these IP addresses to ban lists that can be used by Apache.
I have two flavours, one for apache 2 and another for apache2.4.
Usage
Copy the appropriate action config into your /etc/fail2ban/action.d directory, and enable the action in the usual way.
Then, to actually use the block list, you’re going to need to include it into your vhost config by referencing it in your <directory> block, e.g.:
<RequireAll>
Require all granted
Include /var/run/fail2ban/fail2ban.apache24
</RequireAll>
So, I’ve been using ownCloud for a while now as a convenient way to share certain files between all of my various devices. I’ve even learnt on How to Make a Minecraft Server, which has been pretty fun. The server is a PHP application, so it’s pretty easy to set up.
Anyway, I updated my server to use PHP 7.3, in order to run the latest Known code, among other things. PHP 7.3 is the latest stable code, and so is what everyone should be running, really.
This presented a bit of a problem, as ownCloud would only run on PHP version up to and including 7.2! The next version of ownCloud will apparently support PHP 7.3, however release schedules are slow, and I really needed to get my syncing up and running again.
The obvious solution would be to run PHP 7.2 for the ownCloud server, and then PHP 7.3 for everything else.
Installing PHP-FPM
If you’re running the old school mod_php apache module, the first thing you need to do is install PHP-FPM.
I had been meaning to do this anyway, as this is essentially the modern way of running PHP. It’s faster, gives you many more options for performance, and crucially for my purposes, decouples Apache from PHP meaning you have the option of running multiple versions.
On Debian based servers (mine is Debian, with a third party PHP 7.3 apt repository set up), this turns out to be incredibly easy:
apt-get install php7.3-fpm php7.2-fpm
You’ll also want to install all the PHP modules you need (pdo, gd, etc), but I’ll leave that as an exercise for the reader.
Two things to note here. Firstly, replace the a2dismod statement with whatever php version you currently have installed. Secondly, you’ll notice I didn’t enable the PHP 7.2 FPM config. This is because I want PHP 7.3 to be the default for all sites, but to be able to selectively enable PHP 7.2 on selective virtual hosts.
Checking phpinfo() should now show you something like this:
Note the PHP version and the Server API.
If you look at your server processes, you’ll also see both PHP 7.3 and PHP 7.2 FPM servers running:
# ps aux | grep php
root 1437 0.0 0.2 601224 34420 ? Ss Sep14 0:03 php-fpm: master process (/etc/php/7.3/fpm/php-fpm.conf)
www-data 1936 0.2 0.7 685708 113000 ? S 15:05 0:19 php-fpm: pool www
www-data 6650 0.2 0.7 688600 122332 ? S 09:04 1:08 php-fpm: pool www
www-data 6657 0.2 0.7 687132 125016 ? S 09:04 1:12 php-fpm: pool www
root 7658 0.0 0.2 591404 32916 ? Ss Sep14 0:03 php-fpm: master process (/etc/php/7.2/fpm/php-fpm.conf)
www-data 19281 0.1 0.3 673936 51792 ? S Sep14 2:16 php-fpm: pool www
www-data 19289 0.1 0.3 673836 49044 ? S Sep14 2:17 php-fpm: pool www
www-data 19290 0.1 0.3 673936 49760 ? S Sep14 2:18 php-fpm: pool www
root 21084 0.0 0.0 132340 924 pts/0 S+ 17:01 0:00 grep php
Configuring ownCloud’s VirtualHost to use PHP 7.2
So, now you need to modify your ownCloud VirtualHost to use the PHP 7.2 fast CGI server.
Again, this is really really easy, and is pretty much a cut and paste from the php7.2-fpm.conf file you’ll find in your /etc/apache2/conf-available directory.
Place the following somewhere in your ownCloud virtual host definition:
Now, when you run a phpinfo() on your ownCloud domain, you should see it running PHP 7.2!
Now I can get back to syncing my files, while running the latest PHP version for other domains.
This is a useful feature, and obviously can be used to get more than just slow to update software up and running. For a start, this technique will let me run a bleeding edge version of PHP like PHP 7.4 against, for example, my development version of Known, but keep my blog running the stable release.
Anyway, I thought this was cool. Hopefully you’ll find it useful too!
PHP 7 is now out, and Travis-CI supports it as part of their standard configuration (rather than forcing you to use the PHP nightly build). Last night I submitted a pull request to add PHP 7 support to the Known Travis build, which was a little bit problematic.
Known uses Apache + PHP-FPM, rather than the Travis default nginx setup, and while there are guides for getting this working on the Travis site, it seems that they’re not quite there for the PHP 7 build.
The PHP 7 build was running into this error:
[15-Feb-2016 23:14:58] WARNING: Nothing matches the include pattern '/home/travis/.phpenv/versions/7.0.3/etc/php-fpm.d/*.conf' from /home/travis/.phpenv/versions/7.0.3/etc/php-fpm.conf at line 125.
[15-Feb-2016 23:14:58] ERROR: No pool defined. at least one pool section must be specified in config file
[15-Feb-2016 23:14:58] ERROR: failed to post process the configuration
[15-Feb-2016 23:14:58] ERROR: FPM initialization failed
/home/travis/build.sh: line 45: 25862 Segmentation fault (core dumped) ~/.phpenv/versions/$(phpenv version-name)/sbin/php-fpm
This took a little while to diagnose, but in the end the fix was pretty simple. Basically it looks like the Travis PHP7 build of PHP-FPM expects, but can not find, a pool definition. You don’t need to customise it, just put a default one into PHP-FPM’s config directory.