In June latest release of libbpf has landed in Ubuntu repositories for impish (upcoming 21.10 release). I grabbed the 0.4.0 version and backported it to bionic, focal, groovy and hirsute – these are test builds and are available from the following PPA:

sudo add-apt-repository ppa:hadret/libbpf
sudo apt-get update

Right now these are not really used for anything. In the future though, I’d like to build against them as it’s done in the upcoming releases of Ubuntu and Debian (I had no luck with such builds myself, especially for the older LTS releases).

Latest versions of BCC (v0.21.0) and bpftrace (v0.13.0) are now available from the bpftrace PPA for bionic, focal, groovy and hirsute:

sudo add-apt-repository ppa:hadret/bpftrace
sudo apt-get update

I had a broken build against bpfcc PPA so this one is going to lag behind until the next release – this is because Launchpad doesn’t allow to upload new original tarballs more than once for a given version per repository, even if the broken packages are deleted.

BCC and bpftrace builds went fine and were tested – they work, but the thing is, that both are being build against LLVM versions that are available in the official Ubuntu repositories. This means that only focal and hirsute are being build against LLVM12 and are not being hit by this bug: Accessing pointers broken on LLVM <12 #1305. bionic builds are using LLVM9 and groovy’s are stuck on LLVM11. What I think I’ll do is to try and backport/transplant official LLVM repository to be build on some Launchpad PPA so that I could potentially use it to build against LLVM12 for these two – probably I’ll keep the versions that don’t require additional 3rd-party repositories around, with the caveat of being hit but the mentioned bug.

Last month I patched NGINX Extended against the CVE-2021-23017. I was still having trouble with upgrading to anything higher than 1.19.5 though – which I wrote about back in January. I was getting to the point where I started to explore alternatives when I finally got it building properly.

There are some changes involved though as I had to drop the following modules:

• http-upstream-check
• http-upstream-fair
• nchan

If you rely on any or all of these, please don’t upgrade. Few modules had also been upgraded, namely:

• http-fancyindex to version 0.5.1
• http-modsecurity to version 1.0.2
• http-upsync to version 2.1.3
• rtmp to version 1.2.2

At the moment the latest stable build 1.20.1 is available in the mainline PPA for bionic, focal, groovy (last release) and hirsute (first release). Here’s a quick recap on how to grab it:

sudo add-apt-repository ppa:hadret/nginx-mainline
sudo apt-get update
sudo apt-get install nginx-full

For the upcoming future the plan is simple: migrate 1.20.1 build to the stable PPA branch and prepare 1.21 in the mainline. But for that to happen I need to do some proper testing of the 1.20 builds first.

A security issue in nginx resolver was identified, which might allow an attacker who is able to forge UDP packets from the DNS server to cause 1-byte memory overwrite, resulting in worker process crash or potential other impact.

That’s the essence of the CVE-2021-23017 that was published on May 25. I patched NGINX Extended few days later for bionic, focal and groovy Ubuntu releases. hirsute will join the builds eventually.

Additionally there was a minor bugfix release for ModSecurity, v1.0.2. It’s now also available in the PPA.

Back in December 2019 I wrote a post about Dynamic Upstreams in NGINX w/ Consul and here’s the summary:

I find combination of Consul for service-discovery and NGINX with basing its upstream configuration on it extremely powerful. As I also mentioned multiple times already – I think Upsync is one of the most elegant solutions for combining these two lovely pieces of technology together. I hope that this article will push you into direction of having less things hardcoded and plenty more dynamic and discoverable.

I still find NGINX with Upsync combination to be one of the cleanest and most elegant solutions to the problem of having upstreams provided dynamically. That said, HAProxy just up the ante by building in support for Consul, quote:

When you register more instances of the same service, HAProxy will fill in these disabled server slots, which lets you scale up or down in many cases without a reload.

And that’s the beauty. The entire control over the backends being in and out is under Consul control and HAProxy just routes through it dynamically. Yet again raises as a viable alternative to a fully-blown HTTP server. Respect.

Recently I wanted to go through the bunch of facts from different parts of the infrastructure I maintain. I’ve been already collecting Ansible facts in Redis to speed things up and then I noticed that they are actually still stored in JSON. I always had a soft spot for SQLite and I toyed with the idea of having Ansible facts in a queryable form. The missing piece? Something to transfer these JSON facts from Redis to SQLite. Let’s script it!