Admin

Last week, the VPN provider I previously used went dark for days and went back with no explanation. They have an history of not communicating much and their support does suck but TBH I almost never used it, nevertheless I felt it was time for a change. I asked on BlueSky for feedback and one of the suggestions caught my eye: IVPN.
They have very good reviews, support WireGuard and an OpenBSD developer worked there. Their documentation is very Linux-centric but very well put, yet -of course- it lacks examples for NetBSD. So here’s a simple way of setting up a WireGuard VPN with IVPN on NetBSD.

I got myself a brand new 43 inches monitor, it’s amazing, the visual comfort is life changing.
It all worked pretty much immediately except one little annoying thing: 9 times out of 10, when putting the monitor to sleep with xset dpms force off and waking it up by hitting a key, it would not detect the HDMI signal for about the 30 longest seconds ever.

I finally found that if I change from X11 to the console (Ctrl-Alt-F1 then Ctrl-Alt-F7), it would detect the signal instantly. I suspected that a simple resolution change would do the trick, but changing resolution would also mess the windows positions. Fortunately, here’s what xrandr saw:

Ok this is possibly the easiest thing on earth but I didn’t see any clear documentation on the topic apart from a simple text file which actually helped.

The server runs into a FreeBSD jail, I won’t cover this part as there are plenty of good documentation on this matter already.

The first step is obviously to install nsd, for example using pkg:

# pkg install nsd

My master DNS server runs BIND so there’s no specifics regarding nsd, here’s the most basic configuration the slave needs:

At $(DAYJOB) I was asked to generate some kind of daily report, and I thought ansible would do the job; we basically want to have a couple of key metrics like load average, memory, disk… you see the deal. The result is to be send to MatterMost using mattermost’s ansible module.

It took me way too much time to understand how to update a single variable in order to build a mardown table that would be sent as a single request to the MatterMost server, until neith_speed told me to use hostvars in order to have access to the data gathered by the play for every host.

While searching for an elasticsearch tail -f, I stumble upon this nice piece of software that does exactly that. Reading the configuration file I noticed the server_kibana-proxy section and wondered if that meant that elasticsearch could be queried via kibana, and it turns out that yes, you don’t have to expose ES port (:9200), you can use kibana’s API instead, in particular the console API to be able to query ES directly.

How misleading and complicated this task should be that I’m writing such an article in 2022?
Anyway, if you struggle compiling a simple, standalone Linux kernel module on Debian, Ubuntu, Mint and the like, here’s the recipe:

• Fetch linux-source-<version> and linux-headers-<version>

$ sudo apt install linux-source-5.4.0 linux-headers-$(uname -r)

Do not use apt-get source linux-source-<version>, only pain will you find.

• Untar the fetched archive where you’d like

$ tar jxvf /usr/src/linux-source-5.4.0.tar.bz2

• Copy your current kernel configuration

$ cd linux-source-5.4.0
$ cp /boot/config-$(uname -r) .config

• Prepare the build environment

$ make oldconfig scripts prepare modules_prepare

• Copy current kernel exported symbols file

$ cp /usr/src/linux-headers-$(uname -r)/Module.symvers .

• Build the module you need

$ make -C . M=arch/x86/kvm

• Test it

$ sudo insmod arch/x86/kvm/kvm-intel.ko

Eventually backup the current loaded module (modinfo <module>), replace it with your freshly built one and don’t forget to depmod -a.

While my main workstation is a Linux Mint machine, I occasionally use my OSX ${WORK} laptop for traveling and composing. I’m not really fond of the OS, but at least it’s an UNIX-like, and pkgin runs well with it ;)
When I’m “on the go”, I like to try things and play along with technologies I’m currently obsessed with, among them Kubernetes.
On OSX, the natural choice is to go with minikube, it’s kind of integrated and does the job well, but if you tried it already and also happen to run docker for OSX you might have found yourself struggling with versions and consistency between the two. Added to this that I wanted to have a fully functional Linux virtual machine, preferably Debian GNU/Linux, there was way too much inconsistencies and wasted disk and CPU space to come. So I dug by myself and found a clean and fast solution by spawning my own virtual machine using OSX native hypervisor, which runs Canonical’s microk8s, a nicely done snap package to install a fully working and modular Kubernetes cluster on a Linux machine.

Here’s a procedure I came up with in order to migrate an elasticsearch 1.1 database to version 6 (actually 6.4 but probably any 6.x version).

1. Fire up a temporary elasticsearch version 1.1

Fetch the tar.gz version from https://www.elastic.co/downloads/past-releases/filebeat-1-1-2 and untar it.

Use the following basic configuration file

$ egrep -v '^[[:space:]]*(#|$)' ~/tmp/elasticsearch-1.1.2/config/elasticsearch.yml 
http.port: 9202
transport.tcp.port: 9302
path.conf: /home/imil/tmp/elasticsearch-1.1.2/config
path.data: /var/db/elasticsearch

Note that I changed the standard ports to $((standard_port + 2)).

From the untarred directory, lauch elasticsearch

Assume the following scenario: your {Open,Free}BSD pf-enabled (yes, I know what’s missing and it’s a pity, I am well aware of it) gateway connects to an OpenVPN server. This server pushes a couple of routes to your gateway that you’d like to be able to reach from within your own private network. As routers on the other end don’t have routes to your network(s), mandatory NAT is to be configured, but let’s also assume those routes are subject to change, and there’s more than a couple of them, some kind of dynamic rule adding should be considered.

I’m diving into Kubernetes for a couple of months now. Discovering the possibilities and philosophy behind the hype definitely changed my mind. Yes, it is huge (in every sense ;) ) and it does change the way we, ex-sysops / ops / syasdmins do our work. Not tomorrow, not soon, now.

I’ve had my hands on various managed kubernetes clusters like GKE (Google Container Engine), EKS (AWS Elastic Container Service) or the more humble minikube but I’m not happy when I don’t understand what a technology is made of. So I googled and googled (yeah sorry Qwant and duckduckgo I needed actual answers), until I found >many >incredibly >useful resources.