HowTo: Nginx with HTTP2 support on Debian Jessie

The original problem:

  • SPDY has been replaced by HTTP2, which is better in a number of ways
  • As of June 2016, Chrome has dropped support for SPDY
  • HTTP2 uses ALPN
  • ALPN requires OpenSSL 1.0.2
  • Debian Stable (aka Jessie aka v8) and others OSes only had 1.0.1

What’s changed:

Procedure:

  • Add jessie-backports and jessie-nginx-http2 (ansible playbook)
  • Upgrade openssl them from the correct place: sudo apt-get install -t jessie-backports openssl
  • sudo apt-get install nginx-full (which should pull in various libnginx-mod packages)
  • Change any references in your Nginx config files from spdy to http2
  • Run sudo nginx -t to verify the configuration is valid
  • Start server

Verify HTTP2 is working (Chrome or Opera):

Developer Tools, Network tab, reload page, enable the Protocol column, look for H2, which means HTTP2.

Extra step for LetsEncrypt / Certbot compatibility:

A few days after doing this I got the following error when my weekly cronjob for renewing LetsEncrypt certificates ran:

    build/temp.linux-x86_64-2.7/_openssl.c:415:30: fatal error: openssl/opensslv.h: No such file or directory
     #include <openssl/opensslv.h>

And on running it manually I had this:

The following packages have unmet dependencies:
 libssl-dev : Depends: libssl1.0.0 (= 1.0.1t-1+deb8u6) but 1.0.2k-1~bpo8+1 is to be installed
 Recommends: libssl-doc but it is not going to be installed

The solution was just to pull in libssl-dev from jessie-backports too:

apt-get install -t jessie-backports libssl-dev

Note, in my case, I have a git clone of certbot rather than a packaged version, though it is now available as a backport for Debian Jessie.

Troubleshooting: Where has the PhpStorm PHP 7 Compatibility Inspection gone?

If you’ve read this guide to checking PHP code for PHP 7 compatibility / used the inspection in the past, you may notice that it’s apparently disappeared – you’re supposed to be able to choose Run Inspection by Name… and choose PHP 7 Compatibility from the list.

This is because it’s been merged with the Language Level inspection.

So:

  • Preferences > Languages and Frameworks > PHP
  • set desired PHP Language Level under Development environment
  • Run inspection by name…
  • choose Language Level

Thanks to Jetbrains Support for helping me with that..

(Tested with PhpStorm 2017.1 EAP)

WordPress REST API security risks

I’d recommend any WordPress users install the disable-JSON-API plugin.  This will prevent anonymous access to WP REST API endpoints, such as /wp-json/wp/v2/users – which provides a list of usernames (API docs).

The REST API was introduced in WordPress 4.7 and is (unfortunately) on by default with no option in settings to turn it off – the idea is it will in time be used for AJAX in some of the admin system, not just external requests.   There is a good change if you were running 4.7.0 or 4.7.1 and did not immediately upgrade to the 4.7.2 security release posts may have been defaced.

Also be aware that the WordPress readme.html file no longer displays complete version numbers – e.g. it will show 4.7 rather than 4.7.2.  (a step backward, IMHO).  Though you might not be aware however you can get the version number by clicking on the WordPress icon at the left of the admin bar (and of course, WP-CLI users can do: wp core version)

Git apply no output / no effect – troubleshooting Drupal patches

Be aware that for Drupal, when testing patches from the core issues queue, you can only use the git apply command on the main repository:

https://git.drupal.org/project/drupal.git (browse code)

(i.e. choose 8.2.x or 8.3.x according to issue )

and not on drupal-composer/drupal-project (e.g. a DrupalVM install)

This is logical, the commit IDs in the .patch file simply can’t be found in that repo, so git skips them.  Instead you should use:

patch -p1 < example.patch

…as described here. (You still use -R to reverse it.)

What’s less helpful is git apply will give you no warning there’s a problem – you’ll run the command, see [ok] but no other output, as though it had worked.

Likewise using any of these switches won’t print anything to the screen:

--verbose
--summary
--check

Annoying, the instructions for  --check imply it might tell you:

Instead of applying the patch, see if the patch is applicable to the current working tree and/or the index file and detects errors. Turns off “apply”.

(See also)

Suggested Checklist

  • create a new branch for the patch you’re testing
  • run git diff to check the files have actually been altered
  • run drush cr too to reset cache/UI etc. before testing

Obscure techniques for developers to minimise macOS CPU, disk I/O and power consumption

updated Sat 11 Feb 2017

Me writing this blog post

Assuming you’ve done all the obvious things, e.g.: remove unwanted apps, close apps that don’t need to be open, remove System Preference pane based apps you can do without, tidy the Login Items list, free up sufficient disk space, upgrade RAM, remove unnecessary browser extensions etc.

  • Exclude every website, Git repository and virtual machine on your Mac from Spotlight search.  This made an incredible difference in CPU activity for me (the mdworker and mds processes are what to look for in Activity Monitor).
  • Reduce the quantity of files in your Dropbox folder. It can’t cope with hundreds of thousands of files, or at least the indexing process on initial login can become lengthy and CPU intensive as you near Dropbox’s own estimate of 300,000 files.  Avoid having any Git repositories in there – just make sure you (a) have local backups (Time Machine only backs up certain files and directories) (b) you’re pushing to GitHub, Bitbucket or somewhere else off-site regularly.   Download AWS CLI and sync a .tar.gz occasionally with an S3 bucket.
  • If you use PhpStorm, turn off all the Language Injections you don’t need, turn off all the Inspections you don’t need and remove any unnecessary plugins.  You’ll almost certainly have a handful of candidates for each of those three areas – i.e. languages or frameworks you never use.  Just familiarise yourself with what’s available every now and again so if you do work on an unusual project you have a better chance of remembering to turn the necessary options back on.

(P.S. I’m still using El Capitan 10.11.6 and have no plans to upgrade for several months.)

Mac load average

$ sysctl -n vm.loadavg
{ 1.29 1.38 1.45 }

If you think the Mac load average seems high compared to Linux, here’s an explanation of how it’s calculated.  The CPU idle % is a more useful measure of how loaded your system is (the above measurement was taken with 97% idle CPU).