A while ago I decided to ditch my Windows machine at home as I never really felt at home with the way Windows made me handle the system and the overall `ergonomics' of the OS. Sure, things got better with the introduction of powershell, winget and the Microsoft Terminal but still I always felt like working against the OS and not with it and most of the time I was using my Huawei Matebook running OpenBSD. But more and more often I needed a commercial OS especially due to the pandemic going on.

Having had fond enough memories of macOS from my time at one of my last employers I decided to treat myself to a new M1 based macbook and it’s now being months and frankly, I loved almost every moment of it. Especially running macOS alongside nixpkgs is something that I really enjoy.

But with the move I lost the tools I used to generate the static pages for my blog as they are not readily available as a nixpkg and as my whole blog thingy was very makeshifty I finally decided to jump boat and convert my blog over to hugo. The conversion has been pretty straightforward, easy and enjoyable so far. Despite a steep learning curve, at least for me it was. But after getting more and more into the flow of how stuff work with hugo things started to become easier the pieces of the puzzle fell more and more into their place.

Funnily enough, the structure I created for running my old blog with sblg and a bunch of shell scripts really helped me making the switch and really eased my way into converting the blog into hugo’s go templating and no kidding, hugo really is blazing fast and having hugo -D server running in a shell and manipulation files or working on a new blog post is instantaneous. The amazing speed makes the whole process easy and provides a fantastically low bar for getting back into blogging!

So if you are on the lookout for a static site generator give hugo a chance 😀.

At my day job I often have to resolve a MAC address to a vendor. Since a while I was using https://hwaddr.com but always had 2 gripes with the service they provide:

1. too much advertisements
2. can’t use it from the CLI

so I decided to embark on a journey to create my own site to give me a clutter free service that I can also facilitate from the CLI and thus lladdr.info was born. As I am not too much of a fan of python and gunicorn I decided to try something new and used the project as a vessel to learn some go. Killing two birds with one stone.

So now I can check my mac addresses quickly via CLI and my browser:

Source can be found here

CAVEAT

OUI will only be fetched at service start and not refreshed during the lifetime of the process. Not really mobile friendly at the moment.

There was a discussion lately at my workplace about how to label cables. Currently our cables at the datacenter sadly haven’t been labelled by the previous staff which makes tracing them a nightmare as cables tend to span multiple racks.

So I went ahead and proposed some types of labels I came across in my career so far; about one I’d like to write about here: label each cable at both ends with a word that’s unique across all our sites. Why a word and not a number like e.g. ANSI/TIA 606-C promotes? We deal a lot with 3rd party and non IT remote hands and I found words to be more robust than numbers against spelling errors.

Imagine e.g. that you need to find cable 123080. There’s the risk that an introduced spelling error might lead to the wrong cable being decommissioned. Just imagine a snafu and you misspelled the number in any of the following places:

• while writing the ticket for the remote hands
• while printing the actual label
• while documenting the cable’s current connection
• you grabbed the wrong cable with a similar number back then after a long and exhausting day at work not spotting the error

There is literally no chance for anybody to recognize if 123080 really is the cable number we are searching or if it really should be e.g. 132080. Using words really helps in that regard as it addresses the following points:

• typos can be easily recognized and fixed by humans, sometimes even silently
• grabbing the wrong label can be easily recognized (wait, this is bert but I was suppossed to install hugo!)

Cables will be connected to the chosen word for the rest of it’s lifetime, no matter where the cable will be repurposed. This reduces the amount of labels you actually need to print and moving a cable does not require to issue new labels which comes especially handy on our remote sites where we can’t expect a 3rd party to have a label printer ready to issue new labels which are unique to our company. This leaves us with one …

This is more a personal reminder than anything else. Also this expects an installation following this guide.

• stop netbox: rcctl stop netbox
• upgrade source: cd /var/www/netbox && git pull
• checkout 3.0.10: git checkout v3.0.10
• adjust upgrade.sh:

  diff --git a/upgrade.sh b/upgrade.sh
  index 67b8aaa89..0d694daf3 100755
  --- a/upgrade.sh
  +++ b/upgrade.sh
  @@ -7,7 +7,7 @@
   # Python 3.7 or later.
   #  
   #   cd "$(dirname "$0")"
   #   -VIRTUALENV="$(pwd -P)/venv"
   #   +VIRTUALENV="$(pwd -P)/env"
   #    PYTHON="${PYTHON:-python3}"
   #     
   #      # Remove the existing virtual environment (if any)
   #      @@ -20,7 +20,7 @@ else
   #       fi
   #        
   #         # Create a new virtual environment
   #         -COMMAND="${PYTHON} -m venv ${VIRTUALENV}"
   #         +COMMAND="virtualenv --system-site-packages ${VIRTUALENV}"
   #          echo "Creating a new virtual environment at ${VIRTUALENV}..."
   #           eval $COMMAND || {
   #              echo "--------------------------------------------------------------------"
  

• run upgrade script: bash upgrade.sh
• start the service: rcctl start netbox

Ever since dywis0r made me aware of netbox I was planning on getting my hands dirty with it. But only after looking loads of videos on the topic and after being `forced’ to use it at work has I been able to finally get enough momentum going to start the journey for myself.

At the beginning of it lay another topic I was successfully procrastinating since a very long time: a suffiently detailed network diagram which was both useful and pleasing to the eye. Being interested especially in isometric network diagrams I started working on that very foundation for better documentation of my home network. A journey which led me down a rabbit hole at which’s bottom I found inkscape to be the best tool available for my different needs. It’s not the most effective tool for drawing a network diagram but I had a nice produce after a steep learning curve. But this is another story.

Back to the topic at hand. After drawing the diagram and cleaning up my network from countless redesigns leaving artifacts of me learning and labbing at home I started on working on netbox. After some further research I found what I think to be a good starting point over at Jasper’s blog. I used it as a skeletton but wanted to

1. use relayd(8) instead of nginx for redirecting static content elsewhere
2. use httpd(8) instead of nginx to serve static content
3. use rc(8) instead of supervisord

in large parts due to the software already laying around and the target system already had httpd running. The architecture will more or less look like this:

Other than that you get same as with Jasper’s setup:

The following documents the steps needed to setup NetBox on OpenBSD. I am running NetBox on a PC Engines APU which holds up fairly well and I have since migrated my own setup from RackTables to NetBox, primarily because of the API functionality NetBox offers which allows for integration with SaltStack. But more on that some other …