[rancid] Cisco ASA 8.2 software - changes....

[Brian Ipsen]

Hi

After I upgraded one of our ASA5500-series boxes to software 8.2 - I get notification about the change below every time rancid is run:

- !Flash: 114 43 May 12 2009 02:06:03 coredumpinfo/coredump.cfg
+ !Flash: 114 43 May 12 2009 03:06:14 coredumpinfo/coredump.cfg

The timestamp changes - depending on when the check is run... Is there an easy way of excluding this info from the config collection ??

Med venlig hilsen / Kind regards
Brian Ipsen
 
_______________________________________________
Rancid-discuss mailing list
Rancid-...@shrubbery.net
http://www.shrubbery.net/mailman/listinfo.cgi/rancid-discuss

[alex]

On Tuesday 12 May 2009 13:16:32 Brian Ipsen wrote:

> I get notification about the change below every time rancid is run:
>
> - !Flash: 114 43 May 12 2009 02:06:03 coredumpinfo/coredump.cfg
> + !Flash: 114 43 May 12 2009 03:06:14 coredumpinfo/coredump.cfg

If you're getting core dumps that often, you might want to investigate why.

alexd

[john heasley]

Tue, May 12, 2009 at 02:16:32PM +0200, Brian Ipsen:

> Hi
>
> After I upgraded one of our ASA5500-series boxes to software 8.2 - I get notification about the change below every time rancid is run:
>
> - !Flash: 114 43 May 12 2009 02:06:03 coredumpinfo/coredump.cfg
> + !Flash: 114 43 May 12 2009 03:06:14 coredumpinfo/coredump.cfg
>
> The timestamp changes - depending on when the check is run... Is there an easy way of excluding this info from the config collection ??

what is that file for?

[Sam.H...@gtri.gatech.edu]

I have been having the same issue since we upgraded to the new 8.2 code. Opened a case with TAC and was told that this was normal behavior in the new 8.2 code. The coredump.cfg file that I have contains three entries, they are there so that if I want to enable coredump in the config that it new how to configure it when needed. The TAC engineer suggested that I issue the no coredump enable command. When I told him that I had done that and that the configuration file timestamp still change at various times, he informed me that this was a normal behavior for the 8.2 code.

Still looking for a way to exclude this from rancid when the check is run aginst my devices that are now running the new 8.2 code.

________________________________________
From: rancid-disc...@shrubbery.net [rancid-disc...@shrubbery.net] On Behalf Of Brian Ipsen [b...@rackpeople.dk]
Sent: Tuesday, May 12, 2009 8:16 AM
To: rancid-...@shrubbery.net
Subject: [rancid] Cisco ASA 8.2 software - changes....

[Justin Shore]

john heasley wrote:
> Tue, May 12, 2009 at 02:16:32PM +0200, Brian Ipsen:
>> Hi
>>
>> After I upgraded one of our ASA5500-series boxes to software 8.2 - I get notification about the change below every time rancid is run:
>>
>> - !Flash: 114 43 May 12 2009 02:06:03 coredumpinfo/coredump.cfg
>> + !Flash: 114 43 May 12 2009 03:06:14 coredumpinfo/coredump.cfg
>>
>> The timestamp changes - depending on when the check is run... Is there an easy way of excluding this info from the config collection ??
>
> what is that file for?

I upgraded to 8.2(1) tonight as well and now I'm seeing the same thing.
I haven't been keeping up with this list and so I didn't know about
the new "feature" until I started investigating why I was suddenly
getting these messages; Google pointed me to the list archives.

Is there an easy way to alter the script to use a regex that can then
exclude certain strings like "coredump" from the dir outputs?

I'll put a call into TAC next week and raise hell about this. There's
no excuse for this file's timestamp to be hit every time someone does a
'show run' (which is apparently the trigger for this "feature").
Besides, there's a big in disabling the 'coredump enable' command in
global config:

ASA(config)# no coredump enable
Type help or '?' for a list of available commands.

It shouldn't return a help string like that.

Justin

[Justin Shore]

Justin Shore wrote:
> I'll put a call into TAC next week and raise hell about this. There's
> no excuse for this file's timestamp to be hit every time someone does a
> 'show run' (which is apparently the trigger for this "feature").

I opened my case with TAC last week and asked for it to be escalated to
the DE folks. My TAC engineer ran the case up the flagpole for me and
this issue is now acknowledged to be and is officially logged as a bug.
The BugID is CSCsz85597.

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsz85597

My engineer suggested downgrading to the latest 8.0.4 interim release as
a temporary workaround while the DE folks address the bug and work it
into a maintenance release, hopefully for 8.2. It should be a really
simple fix so hopefully it doesn't take too long. The engineer said
that at least one other person is now attached to this bug and they too
were running RANCID.

[Peter Serwe]

Anybody running a configuration management system that checks the same things is going to log the change,
it just so happens that rancid is particularly complete about checking for differences.

For that matter, rancid isn't really a full-fledged configuration management system, but most of what anyone really
wants to use one for is encompassed in rancid's functionality.  Any functioning configuration differ that is as complete
as rancid would pick up the changes, it just so happens that most people don't run one, or look at the diffs, because
the rest of them don't email out the changes like rancid does out of the box.

I haven't noticed, FWIW, the same behavior in the 7.2.4 branch.

Peter

--
ピーター

[Justin Shore]

Peter Serwe wrote:
> Anybody running a configuration management system that checks the same
> things is going to log the change,
> it just so happens that rancid is particularly complete about checking
> for differences.
>
> For that matter, rancid isn't really a full-fledged configuration
> management system, but most of what anyone really
> wants to use one for is encompassed in rancid's functionality. Any
> functioning configuration differ that is as complete
> as rancid would pick up the changes, it just so happens that most people
> don't run one, or look at the diffs, because
> the rest of them don't email out the changes like rancid does out of the
> box.
>
> I haven't noticed, FWIW, the same behavior in the 7.2.4 branch.

It's a new "feature" added in 8.2. I agree, other config management
systems should pick this up to and I'm sure they do. In fact I took
that position when I opened my TAC case. RANCID being the best, most
popular config management system out there (is that pudding on my nose?)
accounts for a proportionally larger amount of calls on this issue than
the competitors.

[Sam.H...@gtri.gatech.edu]

We to were having the same issue, we did the following to Rancid to keep it from reporting on the file every time it was updated. So far, working like a champ.

 

 

The correct part to edit is the ShowFlash function between ~lines 564 and 577.  I added one line under this one:

 

/\s+vlan\.dat$/ && next;

 

to look like this:

/\s+vlan\.dat$/ && next;

/.*coredumpinfo.*/ && next;

 

It now ignores any lines in the flash drive directory listing that contain "coredumpinfo".  The '.*' before and after are probably not necessary but it was added.

 

Sam

[john heasley]

Fri, May 29, 2009 at 08:11:47AM -0400, Sam.H...@gtri.gatech.edu:

> We to were having the same issue, we did the following to Rancid to keep it from reporting on the file every time it was updated. So far, working like a champ.
>
>
>
> The correct part to edit is the ShowFlash function between ~lines 564 and 577. I added one line under this one:
>
>
>
> /\s+vlan\.dat$/ && next;
>
>
>
> to look like this:
>
> /\s+vlan\.dat$/ && next;
>
> /.*coredumpinfo.*/ && next;

still, what is the file? is it configuration, which exists in the
show conf, and therefore can just be filtered? or is a coredump, which
you'd want to know about changes.

ie: should rancid filter it, or say here's the DDTS (Thanks Justin)?

>
>
> It now ignores any lines in the flash drive directory listing that contain "coredumpinfo". The '.*' before and after are probably not necessary but it was added.
>
>
>
> Sam
>
>
>
> From: rancid-disc...@shrubbery.net [mailto:rancid-disc...@shrubbery.net] On Behalf Of Peter Serwe
> Sent: Thursday, May 28, 2009 10:59 PM
> To: Justin Shore
> Cc: rancid-...@shrubbery.net
> Subject: [rancid] Re: Cisco ASA 8.2 software - changes....
>
> Anybody running a configuration management system that checks the same things is going to log the change,
> it just so happens that rancid is particularly complete about checking for differences.
>
> For that matter, rancid isn't really a full-fledged configuration management system, but most of what anyone really
> wants to use one for is encompassed in rancid's functionality. Any functioning configuration differ that is as complete
> as rancid would pick up the changes, it just so happens that most people don't run one, or look at the diffs, because
> the rest of them don't email out the changes like rancid does out of the box.
>
> I haven't noticed, FWIW, the same behavior in the 7.2.4 branch.
>
> Peter
>

> On Thu, May 28, 2009 at 7:17 PM, Justin Shore <jus...@justinshore.com<mailto:jus...@justinshore.com>> wrote:
> Justin Shore wrote:
> > I'll put a call into TAC next week and raise hell about this. There's
> > no excuse for this file's timestamp to be hit every time someone does a
> > 'show run' (which is apparently the trigger for this "feature").
> I opened my case with TAC last week and asked for it to be escalated to
> the DE folks. My TAC engineer ran the case up the flagpole for me and
> this issue is now acknowledged to be and is officially logged as a bug.
> The BugID is CSCsz85597.
>
> http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsz85597
>
> My engineer suggested downgrading to the latest 8.0.4 interim release as
> a temporary workaround while the DE folks address the bug and work it
> into a maintenance release, hopefully for 8.2. It should be a really
> simple fix so hopefully it doesn't take too long. The engineer said
> that at least one other person is now attached to this bug and they too
> were running RANCID.
>
> Justin
>
> _______________________________________________
> Rancid-discuss mailing list

> Rancid-...@shrubbery.net<mailto:Rancid-...@shrubbery.net>
> http://www.shrubbery.net/mailman/listinfo.cgi/rancid-discuss
>
>
>
> --
> ????

[Justin Shore]

Here's the contents of mine:

ASA# more disk0:/coredumpinfo/coredump.cfg
CD_ENA=no
CD_FILESYSTEM=disk0:
CD_COMP=yes

It looks like some developer decided to store configuration parameters
in a file on the disk rather than in the running-config. I downgraded
last night but I fully expect the file to be updated with other config
if I were to actually enable the coredump feature. I don't know where
the actual coredumps would be stored however. It could be in the
coredumpinfo directory so excluding the directory and all its contents
might not be a good thing. Excluding the coredump.cfg file wouldn't be
such a bad thing though.

Justin

[john heasley]

Fri, May 29, 2009 at 02:56:33PM -0500, Justin Shore:

> Here's the contents of mine:
>
> ASA# more disk0:/coredumpinfo/coredump.cfg
> CD_ENA=no
> CD_FILESYSTEM=disk0:
> CD_COMP=yes

looks useless to me; seems that info is either in the config or the
file contents should be displayed by rancid, and filter the file from
the flash listing.

Index: rancid.in
===================================================================
RCS file: /home/rancid/.CVS/rancid/bin/rancid.in,v
retrieving revision 1.255
diff -d -u -r1.255 rancid.in
--- rancid.in 20 Apr 2009 19:56:27 -0000 1.255
+++ rancid.in 29 May 2009 21:20:41 -0000
@@ -705,6 +705,8 @@
}

/\s+(multiple-fs|nv_hdr|vlan\.dat)$/ && next;
+ # filter coredumpinfo/coredump.cfg
+ /\s+oredumpinfo\/coredump.cfg$/ && next;
ProcessHistory("FLASH","","","!Flash: $_");
}
ProcessHistory("","","","!\n");

[Justin Shore]

All,

The coredump.cfg bug introduced in v8.2 code on the ASAs has been
acknowledged as a bug and has been fixed. The bugID is CSCsz85597:

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsz85597

The interim release 8.2(1)-3 hasn't been officially released but it is
available if you have a contract and point TAC to the bugID. I'm
running it now and apart from a probably unrelated Proxy ARP issue I
haven't run into any problems. RANCID is as happy as can be now.

Justin

_______________________________________________
Rancid-discuss mailing list
Rancid-...@shrubbery.net

http://www.shrubbery.net/mailman/listinfo.cgi/rancid-discuss