Slashdot Mirror
Ask Slashdot: Documenting a Tangle of Network Devices?
LoudMusic writes "One of the many tasks of a network administrator is documenting the network so that other members of the administration and support teams can find devices on the network. Currently my organization uses Excel spreadsheets to handle this, and it's invariably error ridden. We also save a new file with the date in the name each time an update is made. I'd like to move this to a more intelligent database system, but the driving force for keeping it in spreadsheets is the ability to take the document offline, edit it, then upload this new revision to the file server when we have a connection again. Our clients often don't have reliable internet connections, especially when we're tearing their network apart and rebuilding it. The information we're currently documenting about an individual device are: device name, device model, description, IP address, MAC address, physical location, uplink switch & port, and VLAN. What tools exist that would allow us to have multiple users make updates both online and offline simultaneously, and synchronize changes into both the online and offline copies?"
Currently my organization uses Excel spreadsheets to handle this, and it's invariably error ridden.
In the real world, away from press releases, sadly, Excel is the real world enterprise DBMS for almost all corporations.
I also worked for a place that used a word processor for DBMS.
No codd normal forms, and joins/selects are done completely by intern / human power.
Basically all the "paperless office" did was make it slightly easier to do existing paper processes. No core technological/process changes.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Those could be handy with the right smartphone app. Shoot the QR and the app finds it in the database (not spreadsheet) and shows you the network diagram around it (as last known to be wired or scanned).
A tiny QR printer could be nice.
now we need to go OSS in diesel cars
>
Also another hint. If you have to deal with a lot of unmarked jacks throughout the building, enlist a helper or two and use wireless headsets. One person at the rack with a keen eye for a light going out, and another one or two elsewhere briefly unplugging ethernet cables from live machines. Makes identification of jacks actually quick and easy.
FYI: Most decent cable tracers will have a "blink" function. You plug in a module under the desk and it'll blink the switch status light with a pattern that's easy to pick out of a rack by glance. If the port's not cross-connected, then it's time to break out the tone and pickup wand.
"Tell me doctor, with all of your defenses, are there any provisions for an attack by killer bees?"
MediaWiki is your friend. I set up one for a company a few years ago any later started using it to document my responsibilities there, which cover almost the entire ICT system.
My part of the wiki starts on an ICT page, which is divided into sections for Hardware, Software and Telecom. Each contains a number of links to articles with table overviews that contain links to further, more specific articles. The Hardware section has links to eight articles: Servers, Workstations, Monitors, Ethernet networks, Printers Scanners, Wi-Fi and Ethernet switches. The Software section has links to seven articles: Software packages, Scripts, Domain names, IP subnets, Websites, Cronjobs and AFS volumes. The Telecom section has links to six articles: Phone numbers, telecom subscriptions, Modems, Faxes, Telephones and PBXs. For each of the articles mentioned I also created index pages and every single article has various external and internal links for easy navigation. I even created a series of terminology articles to explain various concepts and how they are important to the site.
With several years of Wikipedia experience, the idea of using a wiki for this purpose seemed obvious to me. However, what was not easy was coming up with the structure outlined above. I had first tried out a deeper hierarchy based on the various geographical locations involved, but backed out of that idea when it was clear that it would be too much work.
Producing this kind of documentation in as much detail as I have represents a lot of work, but it has its advantages. For example, it not only means that critical knowledge about the system is now much harder to lose and easier to share, I've also learned many new things about the system (such as all the hardware specs) and it has also forced me to research areas that I wasn't completely sure about.