Living in a city with hard water has its benefits, adding trace minerals to every glass of water and not having to transfer mineral deposits to the insides of my coffee machine by hand.
Really, who wants to spend the weekend pulling apart the boiler, tubes and valves of a coffee machine and painting them with a light layer of soluble minerals.
The downside of hard water is occasionally having to strip said soluble minerals from the inside of coffee machines.
My weapon of choice is citric acid. I have a few options for purchase
1. Local grocery stores in 75 gram tubes – running at $30 per kilogram,
2. For $16 I can have one kilogram posted to me… or two kilograms for $24-ish,
3. Or, for $33 I can have five kilograms! As long as I keep it wrapped up (to reduce moisture absorption) it doesn’t go off… right?
A quick search comes across sites listing things to do with my surplus kilos of citric acid, but they’re also the sort of anti-technology “chemicals are scary” sites that promote paleo, raw, alkaline diets and crystal cancer treatments. I’m warming to the idea of a curated paid search/social media network.
First stop, see if my anyone from my local coffee clique is interested in a kilo.
Second step, pick up other ingredients to bulk out the 100kg of sherbet!
If you ever need a cubic meter of frozen lemonade try “Lemonade” ice pops.
Concentrate: 400 grams of sugar + 30 grams citric acid – top up to 1 litre.
Dilute to one part in ten with water and freeze.
Some time ago (319 days ago, to be precise) I logged into/signed up for Google Cloud Platform.
I got around to giving it a nudge a couple of weeks ago (my work is heavily AWS/Azure) and I’m wondering what to do with $300 of entirely untouched credits. They expire in the next couple of months
Perhaps trying a modest cluster of Folding@Home containers running under Kubernetes.
Or… if I’m thinking about isolating my GCP infrastructure away from my normal Google account for a little more security will I feel better about getting a fresh pile of credits and not asking Google to take them away if I haven’t used the ones they gave me this time…
Sunday mornings are a good time to pause for reflection.
The last couple of weeks I’ve occasionally glanced at Jetpack and then dismissed it as probably too bloated with premium features to have it running on my site.
Today I decided that the features of Jetpack probably merit an install (preferable to maintaining three or four other light plugins) , and there is a page to explicitly disable any surplus modules in the plugin (although not linked from the GUI).
All correct, I thought. Then I found the centralised management – which lets the associated wordpress.com login install arbitrary (uploaded!) plugins and invite new admin users.
Suddenly the wordpress.com user is high value and merits two factor authentication, recovery codes and explicit Sign Out clicks.
There’s good indication that there should be a related module to disable – the categories in in Jetpack modules show “Centralised Management (1)” but it doesn’t list anything when selected.
I’ve finally taken more of a dip into docker than “docker run hello-world”.
If you haven’t heard of docker before (I don’t judge!) here’s what Docker.com says:
Docker is a platform for developers and sysadmins to develop, deploy, and run applications with containers. The use of Linux containers to deploy applications is called containerization. Containers are not new, but their use for easily deploying applications is.
My requirements are pretty simple. Someone mentioned a thing called “WordPress” on the weekend which is, apparently, a thing.
Spoiled by a first look with an AWS marketplace image I wanted to get the shiniest, bells and whistles version of WordPress going on my permanent server. Boo! My server is running Ubuntu 16.04 – and its idea of modern packages leaves a bit to be desired.
To the rescue comes a WordPress docker container – which bundles in all the prerequisites that would be a pain to get going on 16.04.
I already have an Apache web server, Postfix mail server and MariaDB database server, so I just needed to spin up the container and wire it in to the existing services.
Simple right? And see how nicely the arrows extend the stick figure legs – it’s stilt walking day.
It works like this:
Browser contacts the Apache server
Apache terminates the SSL connection and proxies request over HTTP to the WordPress container (on port 8080)
The WordPress container does its thing (pulling content from the existing (non-docker) MariaDB server, and the page is returned by Apache.
WordPress inside a container works nicely, but if we want the uploaded content and any changes to configuration files to persist across container starts it has to have some persistent storage.
After creating a folder for the html content we can expose it to the container with “-v /var/lib/docker/datadir/wp-testingtesting/html:/var/www/html”
Networking and Security
The default network connectivity for a container is to use a bridged docker network. For simplicity I used –add-host to put a “dockerhost” entry in the container’s host resolution file:
docker container run --add-host dockerhost:172.17.0.1 ...
My Postfix allows connections from anywhere (it hosts my domain, so needs to accept mail). As the bridged docker subnet doesn’t use the local address range Postfix won’t let it relay – which is fine for now, and easily fixed by adding to the Postfix main.cf if/when I open registration/subscription from the internet.
ErrorInfo: SMTP Error: The following recipients failed: bogustestmail[email protected]: : Relay access denied
MariaDB did need some changes, it was only listening on the loop back address (127.0.0.1). A simple change to listening on 0.0.0.0 (so mariadb would listen on all addresses) and then inserting a firewall rule allowing connections from the docker0 interface got it going:
That all looks right, so why was WordPress responding with bizarre redirections like http://127.0.0.1 or even http://testingtesting.netwp-admin/…
It turns out that WordPress really, really doesn’t handle reverse proxy, and doesn’t cope with HTTPS termination well either. A few lines of PHP added at the start of wp-config.php gave WordPress enough context to return pages with the right redirections. I’m still pertty disappointed that it’s using absolute links which include the site path, but there’s probably an exceptionally good reason…