[rancid] Cisco ASA 8.2 software

Discussion:

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

Brian Ipsen

2009-05-12 12:16:32 UTC

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

alex

2009-05-12 19:34:40 UTC

Permalink

- !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

2009-05-12 21:44:39 UTC

Permalink

Post by Brian Ipsen
Hi
- !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?

Justin Shore

2009-05-23 07:19:54 UTC

Permalink

Post by john heasley

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

2009-05-29 02:17:46 UTC

Permalink

Post by Justin Shore
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

Peter Serwe

2009-05-29 02:58:40 UTC

Permalink

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

Post by Justin Shore

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
http://www.shrubbery.net/mailman/listinfo.cgi/rancid-discuss

--
$B%T!<%?!<(B

Justin Shore

2009-05-29 04:44:40 UTC

Permalink

Post by 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.

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.

Justin

S***@gtri.gatech.edu

2009-05-29 12:11:47 UTC

Permalink

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

From: rancid-discuss-***@shrubbery.net [mailto:rancid-discuss-***@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

john heasley

2009-05-29 18:56:08 UTC

Permalink

Post by S***@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.
/\s+vlan\.dat$/ && next;
/\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)?

Post by S***@gtri.gatech.edu
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
Sent: Thursday, May 28, 2009 10:59 PM
To: Justin Shore
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

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
http://www.shrubbery.net/mailman/listinfo.cgi/rancid-discuss
--
????
_______________________________________________
Rancid-discuss mailing list
http://www.shrubbery.net/mailman/listinfo.cgi/rancid-discuss

Justin Shore

2009-05-29 19:56:33 UTC

Permalink

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

Post by john heasley

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)?

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
http://www.shrubbery.net/mailman/listinfo.cgi/rancid-discuss
--
????
_______________________________________________
Rancid-discuss mailing list
http://www.shrubbery.net/mailman/listinfo.cgi/rancid-discuss

john heasley

2009-05-29 21:21:51 UTC

Permalink

Post by Justin Shore
ASA# more disk0:/coredumpinfo/coredump.cfg
CD_ENA=no
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");

Post by Justin Shore
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

Post by john heasley

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)?

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
http://www.shrubbery.net/mailman/listinfo.cgi/rancid-discuss
--
????
_______________________________________________
Rancid-discuss mailing list
http://www.shrubbery.net/mailman/listinfo.cgi/rancid-discuss

Justin Shore

2009-07-07 04:35:48 UTC

Permalink

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

S***@gtri.gatech.edu

2009-05-13 05:12:22 UTC

Permalink

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-discuss-***@shrubbery.net [rancid-discuss-***@shrubbery.net] On Behalf Of Brian Ipsen [***@rackpeople.dk]
Sent: Tuesday, May 12, 2009 8:16 AM
To: rancid-***@shrubbery.net
Subject: [rancid] Cisco ASA 8.2 software - changes....

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