Filip Chabik

DevOps Engineer, Husband & Dad.

Transition of the Mac platform to 'Apple Silicon' →

Unsurprisingly, the transition of the Mac platform to ‘Apple Silicon’—an as of yet unspecified custom chipset—was announced. The parallels to the Intel transition announcement in 2005 were obvious and likely entirely intentional. Apple is conveying the message: “we’ve done this before, we know what we are doing.”

Out of all the things on this years’ WWDC, I think this one is the most exciting to me. I haven’t been Apple user back in the PowerPC to Intel transition and honestly this one is a bit different — after all, they want to move Mac to the in-house silicon this time. Outstanding performance per watt will definitely make a huge difference, especially in the laptops market. One of the additional perks appears to be possibility to run iOS and iPadOS apps natively — though can’t think of any use case for myself, I guess games might be a good example.

This transition is going to be tricky though. While moving from PowerPC removed Apple from being “industry’s weirdos” using Power architecture and embrace standard being x86, they are now moving away from it when it’s essentially still a standard. Linux on ARM is a thing, though it’s still early days, even with the whole Raspberry Pi and alike movement. Windows is tough sell on anything else than x86, likely for years to come. Compatibility-wise I’m very curious how Apple is going to tackle these things. Exciting times for sure.

DoT w/ Stubby & dnsmasq on macOS

4th May 2020

OK, let’s start with DoT definition:

DNS over TLS (DoT) is a security protocol for encrypting and wrapping Domain Name System (DNS) queries and answers via the Transport Layer Security (TLS) protocol. The goal of the method is to increase user privacy and security by preventing eavesdropping and manipulation of DNS data via man-in-the-middle attacks.

There are, of course, multiple ways to use DoT on macOS.1 I took the approach of dnsmasq + Stubby simply because I had already planned playing with the former – editing /etc/hosts has bitten me so many times, that I finally gave up and decided to use some tiny DNS instead. Additionally I wanted to get rid of at least some trackers, counters, analytics and, potentially, ads.

  1. One alternative would be to use Unbound

Load Balancing PHP-FPM with HAProxy and FastCGI →

The better alternative is to run the script in its own process and leave the task of receiving HTTP requests to the web server. FastCGI allows you to separate the web server (or proxy) and the running script by defining the communication protocol between the two. Performance benchmarks indicate that separating scripts into their own process equates to a boost in performance.

That was always one of the key differences between Apache and NGINX. Doesn’t really apply these days, but while mod_php is still doing well, NGINX has never adopted anything like it and kept being simply reverse-proxy and cache things. I much prefer NGINX’s approach and it’s great to see that HAProxy can now be used as a viable alternative.

There’s still value using web server for this kind of task, but now it really depends on the software stack already in place and needs. While caching and additional, web server specific, functionality makes more sense in production environment, for testing or maybe even staging purposes HAProxy may be more than enough.

Kernel 5.6 →

As mentioned the last time, I’m still tracking and building latest kernel releases. 5.6 was on my radar for some time and I’m going to stick to it for longer period. One of the most important features1 of this release is addition of WireGuard. I was building it in for the older releases but now this step and patch is no longer necessary as it’s part of mainline 🎉

One of the differences though is the place where it should be enabled:

-> Device Drivers
  -> Network device support
    -> WireGuard secure network tunnel

Latest bcc (version 0.14.0) released recently added support for kernels up to 5.6 as well.

  1. At least to me 🤷🏻‍♂️ 

TLS version and ciphers from NGINX in ELK →

Claudio Kuenzler:

In the past 20 years we have moved from SSL to TLS (yet we’re still talking about SSL certificates, funny isn’t it). According to Wikipedia’s Transport Layer Security page, this is the release history:

SSL 1.0 -> Never officially released due to security flaws
SSL 2.0 -> 1995, deprecated in 2011
SSL 3.0 -> 1996, deprecated in 2015
TLS 1.0 -> 1999, deprecated in 2020
TLS 1.1 -> 2006
TLS 1.2 -> 2008
TLS 1.3 -> 2018

It’s crazy to think that the modern TLS 1.2 is already 12 years old. Not long ago I dropped everything older than 1.2 and introduced support for 1.3 + I’m using only modern ciphers. But this is easily done on a blog with almost no traffic.