NFS Client Tuning on Linux
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.
OpenBSD as a Wireguard Client
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.
Using Vultr Startup Scripts
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.
Using wireguard on OpenBSD
Earlier this week, I was casually discussing various VPN’s with my colleagues. I’ve tried my hand at OpenVPN a couple times in my life, but was turned off by the complicated setup, poor iOS compatibility (at the time), and slow reconnection speeds. The conversation quickly came to revolve around a relative newcomer to the VPN world: wireguard. With the promise of ease of use, minimalistic code base, proven security, wireguard threatens to take the VPN world by storm.
Deploying httpd with acme-client with Ansible
Having the ability to rebuild a server/router from scratch in minutes with confidence, versus slaving over all your configs, trying to get everything working is life changing. I can’t remember how many times I’ve rebuilt a computer, only to run into an issue that I KNOW I’ve fixed before… over a year ago. With ansible, all the work goes into the first deployment, giving you the ability to redeploy a server at a moments notice.
OpenBSD does require some extra options to work properly, as ansible seems to work best with Linux. Hopefully my struggles can help some of you.
OpenBSD with tmux
Being able to take off from work, and the next morning, be able to hop back into my tmux session from the day before is truly lifechanging. I used a custom screen config for a little while before stumbling across tmux. I read into tmux one day at work, and was simply amazed at how much easier it was to configure than screen! This led me to conduct an in-depth comparison between tmux and screen. Did you know, screen has some 254 known bugs? Some go back to 2005 the last time I checked.
Tmux is an active project that is significantly easier to configure, and just as stable in my experiance.
Using ifstated to watch an egress link
While developing my own OpenBSD router, I stumbled across a built-in service called ifstated. Previously, I was using a cronjob to run a script every five minutes to check the status of pppoe0. However, ifstated is able to do everything that my script could, in a more powerful way.
The inspiration for this configuration file originated heavily from calomel’s tutorial. I did modify a handful of items though, to better tailor it to my own router’s design.