Category Archives: Technology

Posted on
by

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.

Next, you want to switch over your config:

a2dismod php7.3
a2enmod proxy_fcgi setenvif
a2enconf php7.3-fpm
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:

<FilesMatch ".+\.ph(ar|p|tml)$">
SetHandler "proxy:unix:/run/php/php7.2-fpm.sock|fcgi://localhost"
</FilesMatch>

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!

Posted on
by

So, I’ve been quite busy recently.

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 (
   location varchar(128),
   latitude DECIMAL(11,8),
   longitude DECIMAL(11,8)
);

Into which, as you might expect, you’d want to import a long list of location coordinates from a CSV file structured as follows:

location, latitude, longitude
"Oxford", 51.7520, 1.2577
"Edinburgh", 55.9533, 3.1883

Now, in your SQL, execute the following query:

LOAD DATA LOCAL INFILE 'locations.csv' 
INTO TABLE locations
FIELDS
  TERMINATED BY ','
  ENCLOSED BY '"'
  LINES TERMINATED BY '\n'
IGNORE 1 ROWS (location, latitude, longitude);

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. 

Hope you find this useful too!

Posted on
by

Today was a very frustrating day.

So, yesterday, I did a rollup of software on my main work machine. I performed an apt-get upgrade as I have done a thousand times before. Logged off, and went to bed.

This morning, when tried to log on, after I’d entered my details on the login screen, I was greeted by a blank screen for about 2 minutes, before being kicked back to the login screen.

Hmm..

This kind of thing had happened before, and in the past it was just a matter of installing the vendor NVidia drivers for my card. Sometime back in the day the distro provided nvidia drivers had stopped working, so using the vendor ones was the way to go (this has since changed).

No joy. So, I began diving in and pulling at the various ends in an attempt to unravel this knotted ball of string.

Watching the logs, I noticed that just before the login process got thrown back to lightdm, I got a bunch of…

Activated service 'org.freedesktop.systemd1' failed: Process org.freedestop.systemd1 exited with status 1

…appearing in my syslog.

So, something was suddenly up with systemd, but I was nonthewiser.

My setup at home is that I have a server which has my home directory and users exported by NFS/NIS to various machines, so there was nothing actually on the work machine. Sod it I thought, nuke the site from orbit. So, I reinstalled, just in case I had bawked something up over the years.

The fresh install made me create a new user, fine. I installed all the graphics drivers, and was able to log in just fine. Great! So, installed the various bits of software, set up NIS/NFS, could log in on console… great! Logged in through gdm3… aaaand. Nothing. Same error. Switched to lightdm. Same thing.

But… the local user worked. Must be something in my user’s home dir, after all that. So, unmounted my home directory, and tried to log in as a fresh user… still no joy. But the local user could log in…

Hmmm….

Lightbulb!

As a hunch, I copied the user line from my server’s /etc/passwd into my local machine’s /etc/passwd… and bingo, I was able to log in.

So, what looks like has happened is that a recent change (within the last week or so) has broken NIS user support for systemd/dbus. So, when the window manager was trying to start the services it needed to run, it wasn’t able to, since the user it was attempting to use couldn’t be found. Lightdm/Pam still functioned with NIS, so my thinking is that there’s something about the environment that’s looking directly at /etc/passwd for something, or to validate uids.. I’m not an expert.

So, if any of you are in a similar situation, hopefully this blog post will stop you from losing an entire day of work!

My askubuntu ticket is over here, and I’ll keep updated should I find a better solution than this rather crufty hack.