In some of my previous posts, I spent some time attempting to squeeze out the best NFS performance as possible from OpenBSD. This time, I wanted to run a similar test, but on Linux and see if the same findings were applicable.

I found the results rather interesting, as they show that Linux is capable of faster transfer speeds than OpenBSD, with much less work. Of course, this doesn’t make me dislike OpenBSD any less (obviously), as the OS is still capable of fast transfers, and I am not building any supercomputers at my home.

My original nfstest script on OpenBSD was tweaked for use on Linux recently. While modifying the script, I realized that there were some shortcomings to my original script.

Rsync was the original transfer method; however, after some testing and research, I realized that this method may have a little more overhead than originally realized.

At the behest of a fellow admin, who apparently digests solely rss feeds, and not content directly, my project this weekend became one to enable rss feeds within hugo.

Due to the relative simplicity of hugo, I figured that this task should be rather easy. Luckily, it was so.

Part two NFS performance tuning. I have some new data to publish. I reran the full NFS test, this time with the script transferring three files, with one sync and unmount in between the three transfers. I saw more interesting behavior that is worth noting, as well as publishing the script used to compile these logs.

Recently I’ve starting using my FreeBSD server as an active NFS server again, instead of just a giant file storage system for old pictures and docs. I prefer to keep as much data on a central storage system, that way, individual client machines can be rebuilt at a moments notice with no data loss.

Until a few months ago, my home desktop was running CentOS. Now it is a OpenBSD desktop running CWM, and I have noticed that the NFS client performance didn’t seem that great compared to the old Linux desktop. So, I figured it was time for some performance testing.

Since it has been a couple weeks since first starting to work with wireguard on OpenBSD, I figured it was about time to figure out how to get my OpenBSD desktop to act as a wireguard client. Who knows, perhaps this will one day allow me to drop my PIA VPN and shift exclusively to running my own personal VPN’s.

Well, I am no networking pro. I know there is a wg-quick script out there, but the couple of times that I tried it out on OpenBSD, it failed. I figured that there shouldn’t be that much to a wireguard tunnel, all I have to do is figure out how to establish the tunnel and force data out the tun device.

I’ve been running a OpenBSD server as my home router for a number of years now, moving between various configuration, scripts, and hardware. I’ve been running on the FW1 for a year now. I originally built the router as an escape from both ISP-provided router/modem combos, as well as custom firmware such as dd-wrt; I wanted more control.

Ever since I was a teenager, I always enjoyed the command line interface. It let me instruct EXACTLY what I wanted the OS to do, and have more control than any GUI out there. However, one area on my router that has always annoyed me was UPnP. This was, as far as I knew, a necessary evil. Without UPnP, online games had a difficult time with multiplayer.

A few years ago, I became fed up with my ISP-provided modem-router combo due to lagginess, sluggish DNS, and overall untrustworthiness. I ended up purchasing a Linksys WRT1900 and flashing it with dd-wrt, which chugged along happily for a couple years. However, later in its life, the router would sometimes stop responding, and lazily I would simply reboot it. Slowly, this pattern started occurring more and more frequently, up until the end of its life.

I decided to make a change. I had been using OpenBSD and Freebsd on and off for a better part of ten years, and I figured it was about time to move to a router that I could trust.

This is an announcement for a new repo I made on GitHub. Since I am constantly testing new deployments on vultr, I realized that it would make my life easier if I put all of my current projects into one public repo, to ease scripted deployments on Vultr.

This new repo will hopefully be the location of future projects, which may make their way into other public repos of mine. Be warned, it will probably be changing often, and may be broken at times.

In a previous article, I wrote of my OpenBSD-Wireguard ansible configuration that I’ve been using for my personal VPN’s recently.

Using Vultr’s startup scripts in addition to the OpenBSD-Wireguard ansible playbook, one is able to deploy a wireguard VPN to any of Vultr’s datacenters within ten minutes. This includes the OS installation by Vultr, as well as the playbook execution following a final reboot.