It’s been awhile since my last post! Life changes, and so has my work responsibilities. Lately, I’ve been working a lot with MongoDB, specifically MongoDB Atlas. In fact, I have started utilizing an Atlas replicaset as the backing database for a new website. In order to reducing my bill each month, I developed a way to shutdown my test replicasets each evening.

Recently, I discovered that MongoDB Atlas and Mongo Ops Manager do not have the ability to send alerts directly to Microsoft Teams. Since I’ve been using rust more frequently, I decided to create a small web service that receives MongoDB alerts, and transforms them into compatible Microsoft Teams Cards, before posting them to a specified Teams incoming webhook.

With any deployment of OpenBSD, it is always advisable to have some sort of monitoring enabled. In the past, I have used zabbix as the monitoring solution for both public findelabs servers, as well as my personal OpenBSD servers. I was going to write an article about the installation and configuration of the web frontend and the postures backend, but I kept putting it off as the configuration was rather clunky. Last week, I ended up moving over to a Grafana dashboard with prometheus as the monitoring system.

This post is for a new rust project that I have been working on lately. I haven’t really touched rust much for nearly a year, but sometimes projects come up that necessitate a statically typed language. The program is a rust network proxy designed for use in HA redis deployments.

Since I have been recently experimenting with OpenBSD 6.6 on Google Cloud Compute, I put together a small bootstrap script to help with new deployments to GCP. It is still in it’s infant stages, but so far it will deploy a couple different scripts on top of the typical basic findelabs OpenBSD bootstrap.

Back when this article was written, on setting up a relayd load-balancer with two back-end httpd servers, relayd did not have the capability of handling multiple tls relays with unique domain names. This meant that each tls relay required a unique IP per domain. This was in part due to the fact that relayd had no SNI support. I am happy to say that with OpenBSD 6.6, this is no longer the case.

This tutorial outlines a simple way to get OpenBSD working on GCE, utilizing only OpenBSD to create the image and send up into gcloud.

Years ago, I always felt that creating a functioning mail server was a project full of pitfalls and speedbumps. Luckily OpenBSD makes the configuration of a working mail server relatively easy. However, creating a working server is only one piece of the puzzle. DNS must also be properly configured to help ensure that your emails actually reach their destinations. This article highlights some of the lessons I learned while creating the mail server for this domain.

In order to ensure that a website is highly available, OpenBSD has a couple of very functional solutions available that work very well together; relayd and httpd. Until this point, this site has been running on a small VM in the cloud, but recently, we have adopted a more highly available configuration.

This article is regarding a script that I’ve never gotten to work properly on OpenBSD, and only works correctly (currently) in Linux. This script is used to access and run commands across multiple servers in parallel.

Edit: This script now works fine on OpenBSD, with the only requirement being to install the flock package! Also, this script is actively being ported to being 100% POSIX compliant, which should enable any shell to run it without issue.