I didn’t really go with a plan, except to sort of see what other people were up to and help out where I could, with a backup plan of doing a bit of Known dev if I could.
In the end I helped guide some folks with setting up their own Known installs, and answer some questions about the Indieweb in general (apparently I’m a veteran now!).
Was a really fun event, and it was really great to hang out with a bunch of like minded smart people!
Temporarily location protected checkins
I had a conversation with one of the attendees, a fellow traveller, and I hit on a hopefully useful extension to the Known Checkin plugin – protected checkins.
Protected checkins will, when enabled for a post, protect your exact checkin location for 24 hours. Logged in users will still be able to see your exact location, as will logged out users after 24 hours have elapsed.
The use case here is for vulnerable people, as well as travel bloggers, backpackers and nomads, who want to share their location but not be particularly precise with the location while they’re there.
So, with this feature, you can check in to a location, but not share your precise location until much later, after you’ve presumably moved on.
Anyway, I thought it was a cute idea, hope you’ll find it useful!
So, I’ve been using ownCloud for a while now as a convenient way to share certain files between all of my various devices. 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.
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.
Next, you want to switch over your config:
a2enmod proxy_fcgi setenvif
systemctl restart apache2
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!
I’ve made some decisions in my personal life that have resulted in a bit of a change of direction and focus for me.
It’s been exciting, and has necessarily meant some changes. This has given me the opportunity to “sharpen my tools”, and so I’ve been getting around to playing with a bunch of technologies that have always been on my “weekend project” list, but they never made it up the priority list.
This isn’t directly related to the title of this article, but provides context. Since, as part of one of these projects, I found it necessary to populate a database with the contents of a bunch of rather unwieldy CSV files (within a docker container, so that their contents could be exposed by a NodeJS/Express REST API, but I digress).
It was while reading the various man pages, before launching in to writing a script, that I found this little gem. This meant I could do the import and provisioning of my docker instance straight from the /docker-entrypoint-initdb.d SQL scripts.
First, create your tables in the normal way, defining the data types that are represented in your CSV file. For example:
CREATE TABLE locations(
Into which, as you might expect, you’d want to import a long list of location coordinates from a CSV file structured as follows:
Now, in your SQL, execute the following query:
LOAD DATA LOCAL INFILE'locations.csv'
INTO TABLE locations
LINES TERMINATED BY'\n'
Which tells MariaDB to read each line from locations.csv into the locations table, skipping over the first line (which contains the header).
This little trick meant I was able to provision my api’s backend quickly and easily, without the need to hack together some arduous import script.