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!

I’ve been following 13.0 starting around the same time last year. It was my coming back to FreeBSD after few years break. I instantly felt at home with it and I also wanted to use all the things “my way”. I customized /etc/make.conf and /etc/src.conf, I switched to git repositories whenever they were available etc. All the fun stuff. FreeBSD behaved on my NUC rock solid all the time – I did bring some rain onto myself (you can’t avoid it when you mess around with bleeding edge), but never to a degree that wouldn’t be recoverable (thank goodness for bectl) this way or another. At some point this year I started preparing for this release and was going more and more towards defaults and eventually I switched back to freebsd-update and portsnap. Being able to do these things without a hitch is a testament of how good of operating system FreeBSD is. Now go try it out!

Jim Salter writes on Ars Technica:

Unfortunately for Netgate, neither its sponsored code nor the week-long sprint by Donenfeld, Dunwoodie, and Evans seem likely to make it into FreeBSD 13.0. Presented with one deeply flawed port and another massively rushed overhaul, the FreeBSD team will most likely disable the WireGuard module entirely for 13.0-RELEASE and revisit for 13.1-RELEASE.

As expected, WireGuard support has been dropped in RC3 of 13.0-RELEASE. What’s even worse of not having WireGuard in is the fact that developers who tried their best to fix everything that was wrong with its implementation received… Bashing from Scott Long. It’s not the first time when Netgate’s CEO is acting like a 5 year old. I’m not linking to his “article” on the Netgate’s blog cause it’s simply not worth anybody’s time.

It is worthwhile though to have a look into this mailing list post by Jason A. Donenfeld (WireGuard’s author). Just to give you some idea:

It makes sense to communicate with your customers about things with your upcoming products if you feel it’s necessary. But threatening that you’re going to highlight “that extreme caution should be taken in any future dealings with you” sounds to me like a threat of some intense slander. And again, attacking security researchers and kernel programmers who took time to rewrite code to make it better before a release deadline… That’s …wow. I wish you would not go on the attack like that.

Wow indeed.

Daniel Morante writes on Unibia:

GlusterFS (GFS) is the open source equivalent to Microsoft’s Distributed Filesystem (DFS). It’s a service that replicates the contents of a filesystem in real time from one server to another. Clients connect to any server and changes made to a file will replicate automatically. It’s similar to something like rsync or syncthing, but much more automatic and transparent. A FreeBSD port has been available since v3.4, and (as of this post) is currently at version 8.0 with 9.0 being released soon.

Full disclosure: I never heard of DFS 🤷🏻‍♂️ When it comes to clustered systems, Microsoft definitely wouldn’t be my first choice. I did however work with AIX GPFS and also with VxFS on multiple platoforms, including Solaris and Linux. There’s also of course cLVM, its implementation on AIX via HACMP and Linux has got something too. I did play with GlusterFS in production for the first time in ~2014 – it was not great. There were many broken parts and some of the things were not really self-contained and relied on userland tools like rsync to be supported and in the right versions. But it did leap forward, eventually stabilized and became, well, to me at least, a golden standard for clustered filesystems on Linux. I’m really happy to see that there is an attempt to get it ported to FreeBSD – it seems to me that it has the potential to combine excellent ZFS baking in this OS with the distributed capabilities as a cherry on top of it.

GlusterFS on FreeBSD is not yet what I would call production quality. There are a few know bugs and performance problems that could ruin your day. The most notable is the fact that GlusterFS uses poll instead of kqueue/kevent. There is also an issue where GlusterFS is (sometimes) unable to correctly find the process ID of the self-heal daemon, causing volume heal commands to fail[…] Other annoyances include the fact that there are still some Linuxisms within the codebase and testing framework. This means GlusterFS might make some Linux specific system calls or look for certain files to be in unexpected locations.

I get it, it’s not there yet, but from the looks of it, it seems that there’s not a lot missing. I’m gonna keep my eye on and fingers crossed for this one 🤞🏻 In the meantime, the linked post is a great introduction not only to GlusterFS, but also to bhyve.

I learned about Project 365 from this post by Joe Hribar. By the end of 2019 I decided to give it a shot myself for 2020 – little did I know how difficult of a year it’s going to be. It was also a leap year, so my Project 365 became Project 366.