Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!boulder!daemon
From: Watt-Alan@mickey.ycc.yale.edu
Newsgroups: comp.dcom.sys.cisco
Subject: Re: logging config
Message-ID: <35738@boulder.Colorado.EDU>
Date: 6 Jun 91 18:59:27 GMT
Sender: daemon@boulder.Colorado.EDU
Lines: 49

Rex Mammel (rexm@lookout.uswest.com) writes:
>Has anyone looked at logging the configuration
>mode entries.  We have several people in our network
>operations group, and it would be a good change control feature to 
>have an automatic record of changes to the AGS configuration.  

Keep your configurations in a text file which is under RCS or
SCCS or similar configuration control.  I keep mine as a set
of configuration templates, and generate the specific configuration
for each gateway with m4.  The welcome text includes the RCS revision
number of the last loaded configuration.

You do have the problem on gateways with configuration memory that
the operating configuration can diverge from the stored one; this
requires more in the way of discipline than tools to overcome.

I have found it somewhat irksome in the past that I cannot load a
configuration from a server on a running gateway and have it take
proper effect.  It is not possible to "clear" some configuration
parameters without knowing what they currently are (administrative
distance and static routes are common examples).  Thus loading a stored
configuration on a running gateway can have an additive rather than
absolute effect.  The only sure fix is a gateway reload, which is
probably what you should do anyway.

>Also, is there a good reason to prevent someone from looking at 
>the config listing from initial password level.  As far as we we
>can tell only changes, debugging and other sensitive
>operations need to be restricted. Is there a way to configure this?

There is the small matter of the privileged password.  I don't think
I'd want random people looking at my routing filter lists.  For the
same reason, I really don't want people looking at my access list
definitions, but that isn't privileged in the current scheme.  They
can't find out what a specific access list is applied to without
priviliges, but simply looking at the definitions can be fairly
suggestive.

	- Alan S. Watt
	  High Speed Networking, Yale University
	  Computing and Information Systems
	  Box 2112 Yale Station
	  New Haven, CT  06520-2112
	  (203) 432-6600 X394
	  Watt-Alan@Yale.Edu


Disclaimer:  "Make Love, Not War -- Be Prepared For Both"
		- Edelman's Sporting Goods [and Marital Aids?]