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 …