Debian 11 →

Debian news:

After 2 years, 1 month, and 9 days of development, the Debian project is proud to present its new stable version 11 (code name bullseye), which will be supported for the next 5 years thanks to the combined work of the Debian Security team and the Debian Long Term Support team.

I’ve been rocking Gentoo on my NUC for some time, but eventually I moved to Debian Sid as I wanted to use “bare-metal” for packages building. While I do miss certain features of Gentoo, I immediately felt at home with Debian. Even with all of the systemd parts that rub me the wrong way – especially as was proven by other distros it’s not the only way1 – the overall experience is just right. Congrats to the Debian project for the bullseye release.

  1. OpenRC being prime example IMHO. 

BCC, libbpf & bpftrace updates

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.

NGINX Extended 1.20.1 update

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:

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

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.

NGINX Extended Security Update (3) →

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.

Dynamic Upstreams in HAProxy w/ Consul →

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.