Tag Info

Hot answers tagged

50

Document the heck out of everything. There was a thread on Slashdot recently about starting documentation, which inspired me to write down my thoughts about documentation. My key points were: Principle #1: It Is Never Done Documentation is an on-going effort that will always lag behind what is in production. Changes are made ad-hoc, things moved around ...


45

It depends on the size of the network, number of users, number of nodes (computers, servers, printers, etc.) and the size of your IT staff, among other things. It also depends on your goal. Are you documenting the network for training and maintenance purposes, insurance/loss prevention, etc? Personally, I document my networks in such a way that I know I ...


14

Not to over simplify, but Sharepoint comes to mind.


13

I know that this isn't free, but I think the Altassian products could suit your needs. Specifically the Confluence Wiki could help with your documentation and the JIRA module could do issue/bug tracking.


13

since 2003 I'm documenting everything in our inhouse wiki. server hardware specs guarantie information network information and of course installed software and configuration workflows e.g. howto add or delete a user and give him/her access to all relevant services important links link to all your web-interfaces link to the monitoring URLs ...


12

Actually neither, we use Documentation As-a-Testcase That being said we have written documentation that goes with Documentation As-a-Manual. We had checklists in place but when growing we found them to be error prone and really failing on the system as a whole. We do however have kind of "Documentation As-a-Checklist" installed, that is - as mentioned ...


12

Unless there's going to be a lot of content switching tiers, I'd recommend separate wikis, as MW was never built for solid access control. Read http://www.mediawiki.org/wiki/Security_issues_with_authorization_extensions first and decide whether it's worth the effort. There's a lot of warnings and exploits that can circumvent the protection methods. If you ...


12

I've been a partner in a three person contracting / consulting service since June, 2004. We each mainly work our own "accounts", however we need to maintain documentation for each other to allow for "failover" between partners. Most of our Customers have some kind of internal IT staff, many of whom perform some amount of day-to-day maintenance, and we need ...


11

First, be careful not to document Active Directory itself. Microsoft has already done that. It is not your responsibility, and it will reduce the time you have to document the configurations, policies, and procedures specific to your installation. Here is a list of things that you should document. Explain your computer, user, domain, and OU naming ...


11

While you realize that while everyone wants (and needs) documentation, you also need to recognize that no-one has time to read and study the stuff. So, don't write documentation that needs to be studied - instead, structure your documentation in a way that allows someone to quickly find the information they need, when they need it - which may well be while ...


11

The first thing to realize is that not all find commands are created equal. The find you will find on a Linux system is different then what you will have on a BSD-based system like OSX. The reference you are going off is for Linux. For the find command the '-type' option is an expression and must be after the path. If you read further down the man page ...


10

You should work with your boss/HR people to have a series of written policies, adopted by the supervisors, that outline how various issues are handled and what is expected of employees. These can vary depending on the business, but basically you would have documents that specify what is and isn't allowed on your network and computer systems and what the ...


9

Writing is a discipline. I've done a lot of it, and I have as much of the basics down as an untrained person can get without documentation being a top part of my job. Time has shown me what documentation I produce will actually get read, and what will go on the Shelf of Eternal TL;DR. This is in fact the number one rule of writing anything: Know your ...


9

What to document? "EVERYTHING!". As a sysadmin you must assume that one day you will be run over in the parking lot by a user who is upset you wouldn't let them download porn on the work network. Your successor should be able to pick up your documentation, read it, and take your place with virtually no questions/problems (at least in the ideal fantasy ...


9

Check out RackTables: http://racktables.org/


9

All of these things should be documented in detail, although when the operation is standard for the operating system, application server, web server etc you may be able to assume the IT operations people know how to do that. Installation: document everything about how it is installed and configured, including how to tell if it is operating correctly. Tell ...


9

I find it's best to incorporate all of the following: Prose: A general overview in paragraph form, which helps with initial big picture and also can describe evolution over time Tables: Tabular lists, either address-keyed, environment-keyed, or machine-keyed (preferably all of the above) Diagrams: Definitely need diagrams with multiple levels of detail. ...


8

When writing mine I've always devolved into writing two three sets. The get-er-done checklist, with a MUCH LONGER appendix about the architecture of the system including why things are done the way they are, probable sticking points when coming online, and abstract design assumptions. followed by a list of probable problems and their resolutions, followed by ...


8

Of course you should care. After all, any job worth doing is a job worth doing well. 1.) It's already been said but it needs repeating for reiteration. Document, document, document. Use excel spreadsheets, notepaper, quill and parchment if you have to. Several thousand mead notebooks like in the movie "Se7en" if need be. Either way, lay it out clear, ...


8

Commenting on the tooling. We've tried online wiki's but found a number of limitations, which may be personal taste, but include document structure and most critically having to be connected to the documentation server. Being connected is a serious problem if you are either offline or onsite (obviously you can mitigate the onsite with a secured SSL ...


8

Disaster Recovery Plan is the proceedures the administrators do to restore normal business workflow. Business Continuity Plan is what end users do to remain productive when normal business workflow is interrupted.


8

I once used an analogy to explain how RAM is defective to a customer of mine. I started at normal voice level repeating ones and zeroes, then after a few seconds I threw a "TWO!" loudly in there. I then explained that their reaction was how Windows XP/Vista/7 reacts: It freaks out and Bluescreens.


8

I assume this is a long term documentation effort, not just trying to capture a snapshot of the current configuration. The wiki works now and might keep you sane for a while but if your environment changes quickly you will have a serious problem. You will always have to make sure the cron jobs are properly written, run in a timely fashion, get written for ...


8

You mean like RFC 5737? The blocks are: 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and 203.0.113.0/24 (TEST-NET-3)


8

The main user-visible differences since 0.23.x are: more language features like better conditionals - the Language Tutorial that you found is definitely the best way to find out what's available in manifests now. all your manifests and plugins (custom facts, custom types and providers) should now be in a module directory structure and you should be using ...


8

I don't know that there are industry standards, but there are plenty of options. Some have been discussed here: What is the most effective solution you used to label cables? What’s the best way to label cables in a data center I think the "standard" is Pick a labeling methodology for your site. Document it. Follow it. Kill anyone who deviates from it in ...


8

A customer just asked me for this, so I compiled a short list of links I have found useful over the years. Not necessarily in the best order, and by no means complete, but thought it might make a good addition for anyone hitting this question: http://www.nex7.com/readme1st (work in progress, can PM me if you have questions) ...


7

Mike, there are generally a few sources of good guides out there for security hardening. The DISA STIGs The NSA SRGs NIST CIS Benchmarks Vendor guidance SANS Books specific to hardening At my work, we use a combination of the DISA STIGs, along with puppet for Linux. I'd be more likely to say that is inadequate and push for some of the recommendations ...


7

This is a pretty tough question -- it's hard to come up with a "standard" template because every site is a little different, even schools (which are largely similar). I can give you the steps I typically follow. Physical Audit If the school already has an asset management system that should help with the physical bits: Every device should have an asset ...


7

You say you're building the sytems from scratch, so it sounds like you're more interested in the automated setup than you are grabbing configuration from a "live" system. The installation of every version of Windows since Windows 2000 has been fairly straightforward to automate via "answer files". Unattended Installation Fundamentals (Windows 2003) ...



Only top voted, non community-wiki answers of a minimum length are eligible