What do people use for knowledgebases? I'm looking for a better (preferably open source) way to track change plans, event resolutions, etc. e.g. an easy way to dig up what the changes that occured on a system were for, who did them, etc. Obviously rancid et al shows us what changed when, but not the change plan that was responsbile or what problem it solved. Possibly adopting a new ticketing system as part of this, so if people have built such system on top of RT, etc, that would be good to know. Thanks
On Wed, Mar 24, 2004 at 10:06:19AM -0800, Steve Francis wrote:
e.g. an easy way to dig up what the changes that occured on a system were for, who did them, etc. Obviously rancid et al shows us what changed when, but not the change plan that was responsbile or what problem it solved.
An internal Wiki with a page dedicated to each machine or machine-class. There's good integration between TWiki and Bugzilla, but we have the classic dichotomy of ticket systems vs bug-trackers: Bugzilla is better for software, RT is better for hardware and networks. Wikis greatly increase the retention and availability of knowledge: they are easy to use, so people *do* use them; they are easy to search, so people do that, too. -dsr-
On Wed, 24 Mar 2004, Steve Francis wrote:
I'm looking for a better (preferably open source) way to track change plans, event resolutions, etc.
e.g. an easy way to dig up what the changes that occured on a system were for, who did them, etc. Obviously rancid et al shows us what changed when, but not the change plan that was responsbile or what problem it solved.
I like RCS better than RANCID for config change tracking, although an ideal system would probably involve both. RANCID is great for alerting you to changes people "forgot" to report, or to unauthorized network changes, since it goes and diffs the configs whether a change has happened or not. Tracking config changes in RCS the way I've done it and seen it done elsewhere involves manually checking the config out before making changes, and manually copying the config to the TFTP server and checking it back in whenever a change has been made. It's a bit more work, but it prompts the user for an explanation of the changes whenever a config is checked back in. This isn't a good defense against somebody who doesn't want their config changes to be known about, but if people are serious about using it you get a "this person did this because of this as reported in this ticket number" notation to go along with every configuration change. -Steve
Date: Wed, 24 Mar 2004 10:52:15 -0800 (PST) From: Steve Gibbard <scg@gibbard.org> Sender: owner-nanog@merit.edu
On Wed, 24 Mar 2004, Steve Francis wrote:
I'm looking for a better (preferably open source) way to track change plans, event resolutions, etc.
e.g. an easy way to dig up what the changes that occured on a system were for, who did them, etc. Obviously rancid et al shows us what changed when, but not the change plan that was responsbile or what problem it solved.
I like RCS better than RANCID for config change tracking, although an ideal system would probably involve both.
RANCID is great for alerting you to changes people "forgot" to report, or to unauthorized network changes, since it goes and diffs the configs whether a change has happened or not.
Tracking config changes in RCS the way I've done it and seen it done elsewhere involves manually checking the config out before making changes, and manually copying the config to the TFTP server and checking it back in whenever a change has been made. It's a bit more work, but it prompts the user for an explanation of the changes whenever a config is checked back in.
This isn't a good defense against somebody who doesn't want their config changes to be known about, but if people are serious about using it you get a "this person did this because of this as reported in this ticket number" notation to go along with every configuration change.
You can use RANCID by manually calling control_rancid to update a single router in the archive and I have written some trivial mods to save a log message of why the change took place and who made it. CVS is a big win over RCS IMHO and the expect scripts in RANCID ame life much easier. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634
I like RCS better than RANCID for config change tracking, although an ideal system would probably involve both.
Indeed, an ideal management framework would include: 1. A tool in which to record the desired (past, current, future) state of network devices. Bonus points for having a difference engine capable of providing the difference between revisions in the form of config statements. 2. A tool in which to record the actual state of network devices (rancid falls into this category). 3. A tool to reconcile 1 and 2. Bonus points for an ability to differentiate planned-but-yet-to-be-applied changes (i.e. the current revision in tool 2's repository matches a les-than-current revision in tool 1's repository) from unauthorized changes detected by tool 2 but not documented in tool 1. More bonus points for applying the difference engine described in tool 1 to propose the configuration statements necessary to undo unauthorized changes. Stephen
Indeed, an ideal management framework would include:
0. a system to generate all pieces of network configuration from high-level descriptions and enterprise data such as dns, ip addr assignments, ... at least those parts of configuration which are not created dynamically by self-configuring components.
1. A tool in which to record the desired (past, current, future) state of network devices. Bonus points for having a difference engine capable of providing the difference between revisions in the form of config statements.
2. A tool in which to record the actual state of network devices (rancid falls into this category).
3. A tool to reconcile 1 and 2. Bonus points for an ability to differentiate planned-but-yet-to-be-applied changes (i.e. the current revision in tool 2's repository matches a les-than-current revision in tool 1's repository) from unauthorized changes detected by tool 2 but not documented in tool 1. More bonus points for applying the difference engine described in tool 1 to propose the configuration statements necessary to undo unauthorized changes.
randy
On Wed, Mar 24, 2004 at 10:06:19AM -0800, Steve Francis wrote:
What do people use for knowledgebases?
I'll second the suggestion for an informal wiki; simple, zero-policy, and allows people to cross-reference information in a far richer manner than you can get out of most "knowledge base" applications. Plus, if you have a team of a few people, one or more will usually take on an unofficial role of "wiki mom", cleaning up the worst of the grammatical errors, adding and maintaining links, etc. -- Edward S. Marshall <esm@logic.net> http://esm.logic.net/ Felix qui potuit rerum cognoscere causas.
participants (7)
-
dsr＠tao.merseine.nu -
esm＠logic.net -
Kevin Oberman -
Randy Bush -
Stephen Stuart -
Steve Francis -
Steve Gibbard