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 …
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
use relayd(8) instead of nginx for redirecting static content elsewhere
use httpd(8) instead of nginx to serve static content
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 …