Recompile NGINX with OpenSSL 1.0.2+ for HTTP/2

No matter how “stable” your “surroundings” are, eventually you will face HTTP/2 and all those requirements to run it on your server using Linux and some HTTP daemon. One of those requirements will be the OpenSSL version 1.0.2 (with ALPN support).

You might be lucky and you will find proper package of the OpenSSL for your Linux distribution. But then, you might be required to recompile your HTTP daemon from source. Yes, I’m in this situation now: Debian 8, OpenSSL 1.0.2 from “backports” and NGINX 1.10 (from DotDeb.org or NGINX.org).

Thanks to the Ramūnas (colleague of mine) for the link Recompile NGINX with OpenSSL 1.0.2+ for HTTP/2 via ALPN – Ubuntu 14.04 – this helps me to deal quicker with NGINX on Debian 8 at least for development environment.

When Puppet fails to add new APT software repositories

What a day! Day in console, day with Debian, day with Puppet! The day when you get error from Puppet and search for solution just because you miss error or notice message.

What I do: I add few Debian APT repositories with Puppet for provisioning and then install software from those repositories on the same run. Nothing special… but I’m getting an error:

==> default: Error: /Stage[main]/Apt::Update/Exec[apt_update]: Failed to call refresh: /usr/bin/apt-get update returned 100 instead of one of [0]
==> default: Error: /Stage[main]/Apt::Update/Exec[apt_update]: /usr/bin/apt-get update returned 100 instead of one of [0]

Of course, everything fails.

If you search for solution over the Internet – you will find many different suggestions, but most of them go around executing apt-get update and playing around using custom Exec['apt_get_update'] but nothing helped in my situation.

After a short brake and rebooting the host I’ve tried one more time the same unchanged script. Yes, that sounds insane – running same failing script and wait for different result but this time I’ve read every notice and error from Puppet and found next notices:

==> default: Notice: /Stage[main]/Main/Apt::Source[nodesource]/Apt::Setting[list-nodesource]/File[/etc/apt/sources.list.d/nodesource.list]/ensure: created
==> default: Notice: /Stage[main]/Main/Apt::Source[mysql]/Apt::Setting[list-mysql]/File[/etc/apt/sources.list.d/mysql.list]/ensure: created
==> default: Notice: /Stage[main]/Main/Apt::Source[dotdeb]/Apt::Setting[list-dotdeb]/File[/etc/apt/sources.list.d/dotdeb.list]/ensure: created
==> default: Notice: /Stage[main]/Apt::Update/Exec[apt_update]/returns: E: The method driver /usr/lib/apt/methods/https could not be found.

That tiny notice I’ve missed is the root of all my problems. The package apt-transport-https was missing. Actually it was added using old Puppet syntax.

Adding: require => Package['apt-transport-https'] to apt::source that uses HTTPS solved the problem. No custom Exec['apt_get_update'] needed, everything works as described in Adding new sources or PPAs.

So, the lesson of the day: read all errors and notices and analyze them, update your Puppet modules and change your code according to changes in Puppet syntax.

Lint PHP files in parallel

One of the quickest and minimal code quality checks in software development is a simple syntax check. In case of PHP we have php -l <path/to/file.php>, nothing smart, nothing fancy.

In case of check automation or continuous integration you even may use Phing task PhpLintTask – runs perfectly and fails build f someone occasionally commits code with syntax errors.

But if you have many files, many CPU cores and fast enough disk – you can lint your PHP files in parallel with PHP Parallel Lint. I’ve tried this tool today and it runs twice faster than standard Phing task using serial approach.

Do you refactor?

Refactoring is a part of our daily routine when we write code, at least it should be even in legacy projects.

One of the goals of refactoring – clean, readable and understandable code.

You can find good example how to start refactoring by reading  Cleaning up Code: Is Refactoring for Aesthetics worth It?

That article partly based on Clean Code and I recommend you to apply Clean Code rules in your project, as I do.

New Oracle VirtualBox release – 5.1

Tool I use, VirtualBox, has a new version released 5.1. If you are new to this tool – Oracle has an announcement Oracle VM VirtualBox 5.1.0 is now available!, but for me it has two most important changes: Improved Performance and Improved Linux integration. I hope VirtualBox will be much faster now.

Release is out there in repository, just type sudo apt-get install virtualbox-5.1 and upgrade if you can. Because I can’t – another tool, Vagrant, that depends on VirtualBox, stops working. Issue Support Virtualbox 5.1 #7411 is already closed, but there is no stable version release with that patch. for now So I’ll wait until Vagrant 1.8.5 released.