Tagged: sitebook networking installation
November 17, 2017 at 8:49 PM #6192
Nick, I have been asked to help plan, deploy and configure a brand new ethernet installation for a local volunteer fire company. The last guy daisy-chained commercial routers, sometimes 3-deep, and has a pile of Cat5 speghetti. Only way to tell what cable connects what, is to unplug it and see what stops working.
As part of this, I want to make certain that whomever comes after me has full access to the entire thing.
Could you help me with developing the sitebook thing you talked about a few weeks back? I want to do right by the men and women who will rely on this system to be able to safely deal with whatever may come their way.
Thank you for your time and any hep you could provide.
On behalf of the Portage Volunteer Fire Company,
Portage, PennsylvaniaNovember 18, 2017 at 1:36 PM #6210
What comes to mind is OTRS with the ITSM module. You’d then have a CMDB, be able to track all changes with the CM module, and track all issues with the original OTRS functionality, which is basically ITSM’s incident management.
But this may be overkill.
The idea of a site book is simply doucmenting how something is built. So in your case you might start out with your example, you make a table that on switch “X”, port 1 goes to (hostA), port 2 goes to (hostB), etc. Entries in the site book for hosts might be something like, for hostA, intalled Xubuntu 16.04, added the gdrive-ocamlfuse repository at URI (ppa:alessandro-strada/ppa), installed G Drive Ocaml FUSE (google-drive-ocamlfuse), added repository… and so on. You might include whatever packages you install from Canonical’s own repositories too which are not installed by default with the base OS (which for the example would be equivalent to installing the xubuntu-desktop meta-package). And so for MS systems you might say, installed Win10, then Office365 (with product key XXXX-UYYYY-UUUZZZZ or whatever), and so on.
Specifically for networking gear and their attached hosts, I used to put a label on each end of each cable, which would have two designations on each label: what was on the label end, and what was on the other end. So for example on the host “BufExchange01”, the label would have bufexchange01 towards the connector end, and right next to it, for example, “hertelinternal03 port 7.” Likewise on the hertelinternal03 switch the label would be “hertelinternal03 port 7” on the connector end with bufexchange01 right next to that (but not towards the connector end). That would tell anyone who needed to unplug the cable that THAT cable belongs in port 7 and it connects BufExchange01.
All I’m saying is, something implementing ITSM such as OTRS::ITSM would be like keeping a site book electronically. Of course the downside is you have a bootstrapping problem with the OTRS system itself…you need the OTRS system to see how the OTRS system was built and maintained.
November 23, 2017 at 1:09 AM #6219
- This reply was modified 3 weeks, 6 days ago by RChandra.
RChandra is right. Just make a sketch of what’s connected to what. Even a word map (port 1 of device 1 is connected to port 1 of device 2) would be better than nothing.
This is overkill for what you’re talking about, but would give you some ideas:
Here’s a diagram example or three of different types:
You must be logged in to reply to this topic.