From Chris.Davis at principia.edu Thu Apr 8 16:11:05 2021 From: Chris.Davis at principia.edu (Chris Davis) Date: Thu, 8 Apr 2021 16:11:05 +0000 Subject: [rancid] Reporting subsets of Rancid data. Message-ID: We have 2 major campuses, and we've always reported our config diffs and pretty much everything else to all members of our small network team. All the switch configs are co-located in the same directory, etc. But now, one campus is complaining that they don't want to see all the config diffs from the other because it's difficult to know if they have data in the config diff report. I was asked if it was possible to split the report into 2, one for each campus. The IP addresses are such that it would be possible to identify them easily. But rancid just seems to be focused on reporting what is in the directory. I'm not sure I'd want to go to great effort to make this kind of thing happen, just to have it break every time I update Rancid. Our boss is keen on network knowing everything on either campus (we back one another up to a high level of degree). Is it easy to carve up the reporting based on IP ranges and provide different email addresses for each set of reports without impacting the future upgrading process? I just want to be able to say I investigated it, but I think the boss would be against it anyway. Thanks. Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.w.anderson at gmail.com Thu Apr 8 16:34:21 2021 From: dan.w.anderson at gmail.com (Dan Anderson) Date: Thu, 8 Apr 2021 12:34:21 -0400 Subject: [rancid] Reporting subsets of Rancid data. In-Reply-To: References: Message-ID: <0b67591e-a13d-4bb3-87c2-00cce7a284a6@Spark> If you created an additional set of groups, you could do a group per campus and send the reports/diffs for each group or groups to different e-mail addresses based on the entries in your /etc/aliases file. That's 100% supported and wouldn't change during upgrades. People who wanted to see all of the reports/diffs would be in all of the group aliases and those who didn't would only be in a subset. Something along the lines of campus1_switches: boss_person, campus1_people campus2_switches: boss_person, campus2_people, campus1_people -- Dan On Apr 8, 2021, 12:11 PM -0400, Chris Davis , wrote: > We have 2 major campuses, and we've always reported our config diffs and pretty much everything else to all members of our small network team.? All the switch configs are co-located in the same directory, etc.? But now, one campus is complaining that they don't want to see all the config diffs from the other because it's difficult to know if they have data in the config diff report.? I was asked if it was possible to split the report into 2, one for each campus.? The IP addresses are such that it would be possible to identify them easily.? But rancid just seems to be focused on reporting what is in the directory.? I'm not sure I'd want to go to great effort to make this kind of thing happen, just to have it break every time I update Rancid.? Our boss is keen on network knowing everything on either campus (we back one another up to a high level of degree).? Is it easy to carve up the reporting based on IP ranges and provide different email addresses for each set of reports without impacting the future upgrading process? ? I just want to be able to say I investigated it, but I think the boss would be against it anyway. > > Thanks. > Chris > _______________________________________________ > Rancid-discuss mailing list > Rancid-discuss at www.shrubbery.net > https://www.shrubbery.net/mailman/listinfo/rancid-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.kerse at gmail.com Fri Apr 9 05:07:33 2021 From: daniel.kerse at gmail.com (Daniel Kerse) Date: Fri, 9 Apr 2021 17:07:33 +1200 Subject: [rancid] Reporting subsets of Rancid data. In-Reply-To: <0b67591e-a13d-4bb3-87c2-00cce7a284a6@Spark> References: <0b67591e-a13d-4bb3-87c2-00cce7a284a6@Spark> Message-ID: This is totally supported. It?s simply a matter of arranging your device groups and email aliases in a way that meets your teams requirements. Speaking of which, how are people maintaining their mailing lists for Rancid these days? Is majordomo still best of breed here? I looked at it a while ago but my rancid servers can?t receive email, only send. So I don?t think that?s going to work. Part of me still wants to me email subscriptions more of a self-service thing and it?s nice to be able to do that without editing the aliases file. On Fri, 9 Apr 2021 at 4:34 AM, Dan Anderson wrote: > If you created an additional set of groups, you could do a group per > campus and send the reports/diffs for each group or groups to different > e-mail addresses based on the entries in your /etc/aliases file. That's > 100% supported and wouldn't change during upgrades. People who wanted to > see all of the reports/diffs would be in all of the group aliases and those > who didn't would only be in a subset. > > > Something along the lines of > > campus1_switches: boss_person, campus1_people > campus2_switches: boss_person, campus2_people, campus1_people > > -- Dan > On Apr 8, 2021, 12:11 PM -0400, Chris Davis , > wrote: > > We have 2 major campuses, and we've always reported our config diffs and > pretty much everything else to all members of our small network team. All > the switch configs are co-located in the same directory, etc. But now, one > campus is complaining that they don't want to see all the config diffs from > the other because it's difficult to know if they have data in the config > diff report. I was asked if it was possible to split the report into 2, > one for each campus. The IP addresses are such that it would be possible > to identify them easily. But rancid just seems to be focused on reporting > what is in the directory. I'm not sure I'd want to go to great effort to > make this kind of thing happen, just to have it break every time I update > Rancid. Our boss is keen on network knowing everything on either campus > (we back one another up to a high level of degree). Is it easy to carve up > the reporting based on IP ranges and provide different email addresses for > each set of reports without impacting the future upgrading process? I > just want to be able to say I investigated it, but I think the boss would > be against it anyway. > > Thanks. > Chris > _______________________________________________ > Rancid-discuss mailing list > Rancid-discuss at www.shrubbery.net > https://www.shrubbery.net/mailman/listinfo/rancid-discuss > > _______________________________________________ > Rancid-discuss mailing list > Rancid-discuss at www.shrubbery.net > https://www.shrubbery.net/mailman/listinfo/rancid-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skyeh at uidaho.edu Fri Apr 9 16:31:08 2021 From: skyeh at uidaho.edu (Hagen, Skye (skyeh@uidaho.edu)) Date: Fri, 9 Apr 2021 16:31:08 +0000 Subject: [rancid] Reporting subsets of Rancid data. In-Reply-To: References: <0b67591e-a13d-4bb3-87c2-00cce7a284a6@Spark> Message-ID: We went a different route, we don?t e-mail from RANCID. In fact, I don?t think that server is setup to send e-mail. Instead, we syslog the log files from RANCID, and send them to our SIEM (Splunk). People can create their own alerts, we don?t have to maintain distribution lists. This does not get us the diffs, it just notes that a device was updated. If someone want to see the diff, they use our web front end to the version control system. We do this by wrapping RANCID with a shell script that runs RANCID, then parses the log files. The script is below, if anyone is interested. Skye Hagen Network Engineer University of Idaho #!/usr/bin/sh # This shell script is the main script for running RANCID. This puts # the whole package together. # # It runs RANCID for all groups, and sends the RANCID logs to syslog. # Function to send a RANCID log to syslog LogIt() { # This routine will take a single RANCID log file, condense it, and # send it to syslog. # # Parameters # $1 - The name of the RANCID log file to process # Build temp files ERR=$(mktemp) ADD=$(mktemp) UPD=$(mktemp) LOG=$(mktemp) # Get the name of the rancid group GRP=$(expr match $1 '.*\/\([a-z]*\)\.') # Get new devices grep "Added " $1 > $ADD # Get updated devices grep "Checking in " $1 > $UPD # Get and reduce errors to a single line per device grep "clogin error" $1 | sort | uniq -c > $ERR # Compute some statistics on added, updated and errors ADDCNT=$(wc -l < $ADD) UPDCNT=$(wc -l < $UPD) ERRCNT=$(wc -l < $ERR) # Create a file of the lines to send to syslog grep "starting:" $1 > $LOG cat $ADD >> $LOG cat $UPD >> $LOG cat $ERR >> $LOG echo "Added=$ADDCNT Updated=$UPDCNT Errors=$ERRCNT" >> $LOG grep "ending:" $1 >> $LOG # Send the file to syslog logger -s -f $LOG -p local0.info -t "rancid-run Group=$GRP " # Clean up temp files rm $LOG $UPD $ADD $ERR } # ===== Main routine # Run default ENVFILE to get the LOGDIR. ENVFILE="/rancid/etc/rancid.conf" . $ENVFILE # Test user and test/set a lock file LOCKFILE="/rancid/locks/processing" USER="rancid" WHOAMI=$(whoami) if [ $WHOAMI != $USER ] then echo "This routine must be run as user $USER." exit fi if [ -e $LOCKFILE ] then echo "Lock file $LOCKFILE exists." exit fi touch $LOCKFILE # Run RANCID echo "Running rancid-run" /rancid/bin/rancid-run # Because RANCID does not syslog directly, we will need to convert # the RANCID logs to syslog events. And, we don't know the name of # the log files. But, we do know the directory that the log files are # stored in. We also know that they will be newer than the date/time # on our lock file. So, we use 'find' to find all log files in the # LOGDIR newer than the lock file, and process them one at a time. LOGS=$(find $LOGDIR -type f -newer $LOCKFILE) for FILE in $LOGS do LogIt $FILE done # Now, remove the lock file rm $LOCKFILE From: Rancid-discuss On Behalf Of Daniel Kerse Sent: Thursday, April 8, 2021 10:08 PM To: Dan Anderson Cc: rancid-discuss at www.shrubbery.net Subject: Re: [rancid] Reporting subsets of Rancid data. This is totally supported. It?s simply a matter of arranging your device groups and email aliases in a way that meets your teams requirements. Speaking of which, how are people maintaining their mailing lists for Rancid these days? Is majordomo still best of breed here? I looked at it a while ago but my rancid servers can?t receive email, only send. So I don?t think that?s going to work. Part of me still wants to me email subscriptions more of a self-service thing and it?s nice to be able to do that without editing the aliases file. On Fri, 9 Apr 2021 at 4:34 AM, Dan Anderson > wrote: If you created an additional set of groups, you could do a group per campus and send the reports/diffs for each group or groups to different e-mail addresses based on the entries in your /etc/aliases file. That's 100% supported and wouldn't change during upgrades. People who wanted to see all of the reports/diffs would be in all of the group aliases and those who didn't would only be in a subset. Something along the lines of campus1_switches: boss_person, campus1_people campus2_switches: boss_person, campus2_people, campus1_people -- Dan On Apr 8, 2021, 12:11 PM -0400, Chris Davis >, wrote: We have 2 major campuses, and we've always reported our config diffs and pretty much everything else to all members of our small network team. All the switch configs are co-located in the same directory, etc. But now, one campus is complaining that they don't want to see all the config diffs from the other because it's difficult to know if they have data in the config diff report. I was asked if it was possible to split the report into 2, one for each campus. The IP addresses are such that it would be possible to identify them easily. But rancid just seems to be focused on reporting what is in the directory. I'm not sure I'd want to go to great effort to make this kind of thing happen, just to have it break every time I update Rancid. Our boss is keen on network knowing everything on either campus (we back one another up to a high level of degree). Is it easy to carve up the reporting based on IP ranges and provide different email addresses for each set of reports without impacting the future upgrading process? I just want to be able to say I investigated it, but I think the boss would be against it anyway. Thanks. Chris _______________________________________________ Rancid-discuss mailing list Rancid-discuss at www.shrubbery.net https://www.shrubbery.net/mailman/listinfo/rancid-discuss _______________________________________________ Rancid-discuss mailing list Rancid-discuss at www.shrubbery.net https://www.shrubbery.net/mailman/listinfo/rancid-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From heas at shrubbery.net Fri Apr 9 20:57:14 2021 From: heas at shrubbery.net (heasley) Date: Fri, 9 Apr 2021 20:57:14 +0000 Subject: [rancid] rancid diff mail destination (was Reporting subsets of Rancid data.) Message-ID: Fri, Apr 09, 2021 at 05:07:33PM +1200, Daniel Kerse: > Speaking of which, how are people maintaining their mailing lists for > Rancid these days? Is majordomo still best of breed here? I looked at it a > while ago but my rancid servers can?t receive email, only send. So I don?t > think that?s going to work. > > Part of me still wants to me email subscriptions more of a self-service > thing and it?s nice to be able to do that without editing the aliases file. You could use Mailman, a feature superset of majorodomo, which supplies an extensive web interface such that your rancid server may continue to disallow smtp in-bound but still allow users to manage their subscriptions, whether they receive a digest, view archives, etc. From heas at shrubbery.net Fri Apr 9 21:10:48 2021 From: heas at shrubbery.net (heasley) Date: Fri, 9 Apr 2021 21:10:48 +0000 Subject: [rancid] Reporting subsets of Rancid data. In-Reply-To: <0b67591e-a13d-4bb3-87c2-00cce7a284a6@Spark> References: <0b67591e-a13d-4bb3-87c2-00cce7a284a6@Spark> Message-ID: Thu, Apr 08, 2021 at 12:34:21PM -0400, Dan Anderson: > If you created an additional set of groups, you could do a group per campus and send the reports/diffs for each group or groups to different e-mail addresses based on the entries in your /etc/aliases file. That's 100% supported and wouldn't change during upgrades. People who wanted to see all of the reports/diffs would be in all of the group aliases and those who didn't would only be in a subset. > > > Something along the lines of > > campus1_switches: boss_person, campus1_people > campus2_switches: boss_person, campus2_people, campus1_people > > -- Dan Another option is parse the diff with a rancid.conf:DIFFSCRIPT script; awk out the diffs by IP or whatever and email them to -a and -b AND send them to stdout which will go to rancid- (ie: the cumulative). Yet another option is to add a rancid.conf knob that allows the admin to create their own script to perform the diff AND email them. Leaving the default and the rancid--admin mail as the current process. the script would have to accept some arguments to know where to send the diffs, and so forth. Is that of general interest? > On Apr 8, 2021, 12:11 PM -0400, Chris Davis , wrote: > > We have 2 major campuses, and we've always reported our config diffs and pretty much everything else to all members of our small network team.? All the switch configs are co-located in the same directory, etc.? But now, one campus is complaining that they don't want to see all the config diffs from the other because it's difficult to know if they have data in the config diff report.? I was asked if it was possible to split the report into 2, one for each campus.? The IP addresses are such that it would be possible to identify them easily.? But rancid just seems to be focused on reporting what is in the directory.? I'm not sure I'd want to go to great effort to make this kind of thing happen, just to have it break every time I update Rancid.? Our boss is keen on network knowing everything on either campus (we back one another up to a high level of degree).? Is it easy to carve up the reporting based on IP ranges and provide different email addresses for each set of reports without impacting the future upgrading process? ? I just want to be able to say I investigated it, but I think the boss would be against it anyway. > > > > Thanks. > > Chris > > _______________________________________________ > > Rancid-discuss mailing list > > Rancid-discuss at www.shrubbery.net > > https://www.shrubbery.net/mailman/listinfo/rancid-discuss > _______________________________________________ > Rancid-discuss mailing list > Rancid-discuss at www.shrubbery.net > https://www.shrubbery.net/mailman/listinfo/rancid-discuss From williama at precisely.com Wed Apr 14 12:42:22 2021 From: williama at precisely.com (Aaron Williamson) Date: Wed, 14 Apr 2021 12:42:22 +0000 Subject: [rancid] Issues with DELLOS10 module Message-ID: This has been bugging me for a long time, hoping maybe someone here can help. We have several Dell EMC Networking OS10 switches and have included the DELLOS10 module into rancid. It seems to work perfectly except for one small thing. Please see the trail of notifications below that I received from rancid. The configuration on the device is not changing, and does not ever have any character(s) before the "! Version". It is as if the command "exit" to leave the ssh session is being partially captured. These particular switches do take a little extra time to log in and get to a prompt...meaning 2 or 3 seconds. What is interesting is that if I manually run "export NOPIPE YES; rancid -t dellos10 -dl defdc-swc192.syncsort.network" and view the .raw file, I never see these additional characters. However, it happens every hour via the scheduled rancid-run. Is there some kind of timeout or wait/sleep command I can tweak that might help...or any other ideas? Thank in advance for your help. Aaron Index: configs/defdc-swa192.syncsort.network =================================================================== retrieving revision 1.57 diff -u -4 -r1.57 defdc-swa192.syncsort.network @@ -3,9 +3,9 @@ ! ! ! ! - ex! Version 10.4.3.4 + ! Version 10.4.3.4 ! ip vrf default ! ip domain-name syncsort.network Index: configs/defdc-swa192.syncsort.network =================================================================== retrieving revision 1.56 diff -u -4 -r1.56 defdc-swa192.syncsort.network @@ -3,9 +3,9 @@ ! ! ! ! - ! Version 10.4.3.4 + ex! Version 10.4.3.4 ! ip vrf default ! ip domain-name syncsort.network Index: configs/defdc-swa192.syncsort.network =================================================================== retrieving revision 1.55 diff -u -4 -r1.55 defdc-swa192.syncsort.network @@ -3,9 +3,9 @@ ! ! ! ! - x! Version 10.4.3.4 + ! Version 10.4.3.4 ! ip vrf default ! ip domain-name syncsort.network Index: configs/defdc-swa192.syncsort.network =================================================================== retrieving revision 1.54 diff -u -4 -r1.54 defdc-swa192.syncsort.network @@ -3,9 +3,9 @@ ! ! ! ! - ex! Version 10.4.3.4 + x! Version 10.4.3.4 ! ip vrf default ! ip domain-name syncsort.network ? Aaron Williamson Principal Systems Engineer Precisely.com p +1 317-572-1849
m +1 (317) 213-0894
ATTENTION: ----- The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. From me at falz.net Wed Apr 14 17:54:48 2021 From: me at falz.net (Chris Wopat) Date: Wed, 14 Apr 2021 12:54:48 -0500 Subject: [rancid] Ciena Waveserver - fluctuating power values round 2 Message-ID: Hi folks, Way back in the before times, we had reported an issue where one of the commands that RANCID runs constantly has some churn values, and to get it filtered. https://shrubbery.net/pipermail/rancid-discuss/2018-August/010346.html This discussion started on list, went off-list for testing, and it seemed fixed. I'm not sure what happened, but the issue is back. We didnt notice it for quite some times because: * I believe our testing was with the dev branch at the time (3.99) and we just left it there for a while. * Unrelated to rancid, but the system that auto creates our rancid config file, stopped adding the waveservers to it about 6 months ago and uhh, we didn't notice until recently. I believe during this 6 month gap, we actually properly upgraded to 3.13, and now that we fixed item 1) above noticed the issue. To re-summarize, the last column of this ascii cell - 'Power (W)' always has churn, here's an example of a recent diff. This is a subsection of the 'chassis show' command, a non-wrapped output of this can be found here: https://falz.net/static/waveserver-1.6-chassis.txt example diff below: ! +------------------------- POWER SUPPLY STATUS ---------------------------------------+-----------+ ! | Slot | Oper | Type | Model | Serial Number | Part Number / Rev | Power (W) | ! +--------+--------+---------+------------------+---------------+----------------------+-----------+ - ! | PSU-1 | Normal | DC | WS DC PSU | K846S2004RABP | 186-1501-900/AB | 260.0 | + ! | PSU-1 | Normal | DC | WS DC PSU | K846S2004RABP | 186-1501-900/AB | 260.5 | ! +--------+--------+---------+------------------+---------------+----------------------+-----------+ - ! | PSU-2 | Normal | DC | WS DC PSU | K846S2004ZABP | 186-1501-900/AB | 311.5 | + ! | PSU-2 | Normal | DC | WS DC PSU | K846S2004ZABP | 186-1501-900/AB | 312.0 | ! +--------+--------+---------+------------------+---------------+----------------------+-----------+ Not sure what best way is to re-test this - heasley would you like the entire output from the device, from the command, something else? Thanks, Chris From williama at precisely.com Mon Apr 12 18:36:33 2021 From: williama at precisely.com (Aaron Williamson) Date: Mon, 12 Apr 2021 18:36:33 -0000 Subject: [rancid] Issues with DELLOS10 module Message-ID: This has been bugging me for a long time, hoping maybe someone here can help. We have several Dell EMC Networking OS10 switches and have included the DELLOS10 module into rancid. It seems to work perfectly except for one small thing. Please see the trail of notifications below that I received from rancid. The configuration on the device is not changing, and does not ever have any character(s) before the "! Version". It is as if the command "exit" to leave the ssh session is being partially captured. These particular switches do take a little extra time to log in and get to a prompt...meaning 2 or 3 seconds. What is interesting is that if I manually run "export NOPIPE YES; rancid -t dellos10 -dl defdc-swc192.syncsort.network" and view the .raw file, I never see these additional characters. However, it happens every hour via the scheduled rancid-run. Is there some kind of timeout or wait/sleep command I can tweak that might help...or any other ideas? Thank in advance for your help. Aaron Index: configs/defdc-swa192.syncsort.network =================================================================== retrieving revision 1.57 diff -u -4 -r1.57 defdc-swa192.syncsort.network @@ -3,9 +3,9 @@ ! ! ! ! - ex! Version 10.4.3.4 + ! Version 10.4.3.4 ! ip vrf default ! ip domain-name syncsort.network Index: configs/defdc-swa192.syncsort.network =================================================================== retrieving revision 1.56 diff -u -4 -r1.56 defdc-swa192.syncsort.network @@ -3,9 +3,9 @@ ! ! ! ! - ! Version 10.4.3.4 + ex! Version 10.4.3.4 ! ip vrf default ! ip domain-name syncsort.network Index: configs/defdc-swa192.syncsort.network =================================================================== retrieving revision 1.55 diff -u -4 -r1.55 defdc-swa192.syncsort.network @@ -3,9 +3,9 @@ ! ! ! ! - x! Version 10.4.3.4 + ! Version 10.4.3.4 ! ip vrf default ! ip domain-name syncsort.network Index: configs/defdc-swa192.syncsort.network =================================================================== retrieving revision 1.54 diff -u -4 -r1.54 defdc-swa192.syncsort.network @@ -3,9 +3,9 @@ ! ! ! ! - ex! Version 10.4.3.4 + x! Version 10.4.3.4 ! ip vrf default ! ip domain-name syncsort.network ? Aaron Williamson Principal Systems Engineer Precisely.com p +1 317-572-1849
m +1 (317) 213-0894
ATTENTION: ----- The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control.