[rancid] Checking for root

[Matthew Walster]

More often than not, people are coming to me with RANCID issues that have
arisen because someone has been impatient and decided to run rancid-run
manually rather than letting the next run initiate manually.

The only problem with that is that they tend to run it as "root" rather
than the rancid user.

Would it be worth putting a check in so that rancid-run script won't run
unless it's as a non-privileged user (or even better, build it into the
automake run to discover the intended final user).

Simple code sample:

if [[ $EUID -eq 0 && $force -ne 1 ]]
then
echo "Run this as the RANCID user!"
exit 1
fi

There's a "force" option there, just in case you really did run it as root,
which seems like bad practice to me...

Just a thought!

Matthew Walster

[Alan McKinnon]

On 06/06/2013 16:45, Matthew Walster wrote:
> More often than not, people are coming to me with RANCID issues that
> have arisen because someone has been impatient and decided to run
> rancid-run manually rather than letting the next run initiate manually.
>
> The only problem with that is that they tend to run it as "root" rather
> than the rancid user.
>
> Would it be worth putting a check in so that rancid-run script won't run
> unless it's as a non-privileged user (or even better, build it into the
> automake run to discover the intended final user).
>
> Simple code sample:
>
> if [[ $EUID -eq 0 && $force -ne 1 ]]
> then
> echo "Run this as the RANCID user!"
> exit 1
> fi
>
> There's a "force" option there, just in case you really did run it as
> root, which seems like bad practice to me...
>
> Just a thought!


+1

I'm all in favour of scripts not letting themselves be run as root. The
automake idea is better still, as permissions and ownerships issues from
running scripts as the wrong user can be very annoying to track down,
and that problem never resolves.

Personally, I also always apply this rule forcefully with no recourse:

Anyone who abuses the root account loses the root account.

Naturally, this is not a technical solution :-)

--
Alan McKinnon
***@gmail.com

[heasley]

Thu, Jun 06, 2013 at 04:57:10PM +0200, Alan McKinnon:
> On 06/06/2013 16:45, Matthew Walster wrote:
> > More often than not, people are coming to me with RANCID issues that
> > have arisen because someone has been impatient and decided to run
> > rancid-run manually rather than letting the next run initiate manually.
> >
> > The only problem with that is that they tend to run it as "root" rather
> > than the rancid user.
> >
> > Would it be worth putting a check in so that rancid-run script won't run
> > unless it's as a non-privileged user (or even better, build it into the
> > automake run to discover the intended final user).
> >
> > Simple code sample:
> >
> > if [[ $EUID -eq 0 && $force -ne 1 ]]
> > then
> > echo "Run this as the RANCID user!"
> > exit 1
> > fi
> >
> > There's a "force" option there, just in case you really did run it as
> > root, which seems like bad practice to me...
> >
> > Just a thought!
>
>
> +1
>
> I'm all in favour of scripts not letting themselves be run as root. The
> automake idea is better still, as permissions and ownerships issues from
> running scripts as the wrong user can be very annoying to track down,
> and that problem never resolves.
>
> Personally, I also always apply this rule forcefully with no recourse:
>
> Anyone who abuses the root account loses the root account.

s/abuses/doesnt know what theyre doing with/

anyway, i dont care for such checks, i know what my UID is and things that
think they must protect me from myself are just annoying and its not the
Unix manner. but, if folks would like this, i'd be willing to add a check
that is enabled by a rancid.conf option, which i believe would be sufficient,
right?

[Matthew Walster]

On 6 June 2013 16:34, heasley <***@shrubbery.net> wrote:

> Thu, Jun 06, 2013 at 04:57:10PM +0200, Alan McKinnon:
> > Anyone who abuses the root account loses the root account.
>
> s/abuses/doesnt know what theyre doing with/
>

​Some of those that have done this have done it absent mindedly, they are
just used to doing "sudo xyz" if "xyz" didn't work in the first place.​



> anyway, i dont care for such checks, i know what my UID is and things that
> think they must protect me from myself are just annoying and its not the
> Unix manner. but, if folks would like this, i'd be willing to add a check
> that is enabled by a rancid.conf option, which i believe would be
> sufficient,
> right?


That would be great if you could incorporate it into a future release --
it's caught quite a few people out (most of whom should know better, but
were touching RANCID for the first time adding a new router or similar
through puppet then running rancid-run manually).

It's not an urgent or important feature by any rate, but it'd be a great
thing to see!

M​​

[Alex DEKKER]

On 2013-06-06 16:34, heasley wrote:
> i'd be willing to add a check that is enabled by a rancid.conf
> option,
> which i believe would be sufficient, right?

If it's not the default, then it will catch instances where a
forward-thinking admin [or package maintainer] thinks to enable it; it
won't help noobs setting RANCID working on their own.

alexd

[heasley]

Thu, Jun 06, 2013 at 09:52:50PM +0100, Alex DEKKER:
> On 2013-06-06 16:34, heasley wrote:
> > i'd be willing to add a check that is enabled by a rancid.conf
> > option,
> > which i believe would be sufficient, right?
>
> If it's not the default, then it will catch instances where a
> forward-thinking admin [or package maintainer] thinks to enable it; it
> won't help noobs setting RANCID working on their own.

so, ./configure --noobpid ?

how about just adding the check to rancid.conf? that affects everything that
reads it, the check can be customized (like adding a timer), or completely
disabled w/o an arg/etc.

> alexd
> _______________________________________________
> Rancid-discuss mailing list
> Rancid-***@shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/rancid-discuss

[Aaron Dudek]

Seems like a good compromise. Assuming the person installing knows to add
it.

On Friday, June 7, 2013, heasley wrote:

> Thu, Jun 06, 2013 at 09:52:50PM +0100, Alex DEKKER:
> > On 2013-06-06 16:34, heasley wrote:
> > > i'd be willing to add a check that is enabled by a rancid.conf
> > > option,
> > > which i believe would be sufficient, right?
> >
> > If it's not the default, then it will catch instances where a
> > forward-thinking admin [or package maintainer] thinks to enable it; it
> > won't help noobs setting RANCID working on their own.
>
> so, ./configure --noobpid ?
>
> how about just adding the check to rancid.conf? that affects everything
> that
> reads it, the check can be customized (like adding a timer), or completely
> disabled w/o an arg/etc.
>
> > alexd
> > _______________________________________________
> > Rancid-discuss mailing list
> > Rancid-***@shrubbery.net <javascript:;>
> > http://www.shrubbery.net/mailman/listinfo.cgi/rancid-discuss
> _______________________________________________
> Rancid-discuss mailing list
> Rancid-***@shrubbery.net <javascript:;>
> http://www.shrubbery.net/mailman/listinfo.cgi/rancid-discuss
>

[heasley]

Sat, Jun 08, 2013 at 03:04:20PM -0400, Aaron Dudek:
> Seems like a good compromise. Assuming the person installing knows to add
> it.

new installations would get it be default, others might merge it when updating,
but existing installations would not otherwise.

> On Friday, June 7, 2013, heasley wrote:
>
> > Thu, Jun 06, 2013 at 09:52:50PM +0100, Alex DEKKER:
> > > On 2013-06-06 16:34, heasley wrote:
> > > > i'd be willing to add a check that is enabled by a rancid.conf
> > > > option,
> > > > which i believe would be sufficient, right?
> > >
> > > If it's not the default, then it will catch instances where a
> > > forward-thinking admin [or package maintainer] thinks to enable it; it
> > > won't help noobs setting RANCID working on their own.
> >
> > so, ./configure --noobpid ?
> >
> > how about just adding the check to rancid.conf? that affects everything
> > that
> > reads it, the check can be customized (like adding a timer), or completely
> > disabled w/o an arg/etc.
> >
> > > alexd
> > > _______________________________________________
> > > Rancid-discuss mailing list
> > > Rancid-***@shrubbery.net <javascript:;>
> > > http://www.shrubbery.net/mailman/listinfo.cgi/rancid-discuss
> > _______________________________________________
> > Rancid-discuss mailing list
> > Rancid-***@shrubbery.net <javascript:;>
> > http://www.shrubbery.net/mailman/listinfo.cgi/rancid-discuss
> >

[Matthew Walster]

On 7 June 2013 16:22, heasley <***@shrubbery.net> wrote:

> Thu, Jun 06, 2013 at 09:52:50PM +0100, Alex DEKKER:
> > If it's not the default, then it will catch instances where a
> > forward-thinking admin [or package maintainer] thinks to enable it; it
> > won't help noobs setting RANCID working on their own.
>
> so, ./configure --noobpid ?
>

​As hilarious as that would be... ;)


> how about just adding the check to rancid.conf? that affects everything
> that
> reads it, the check can be customized (like adding a timer), or completely
> disabled w/o an arg/etc.


It'd be great if it was default-on though. Just my opinion though, like you
say, it's only people unfamiliar with how RANCID works and think they're
being helpful by running rancid-run immediately after altering a router.db

M​​

[Alan McKinnon]

On 06/06/2013 17:34, heasley wrote:
> Thu, Jun 06, 2013 at 04:57:10PM +0200, Alan McKinnon:
>> On 06/06/2013 16:45, Matthew Walster wrote:
>>> More often than not, people are coming to me with RANCID issues that
>>> have arisen because someone has been impatient and decided to run
>>> rancid-run manually rather than letting the next run initiate manually.
>>>
>>> The only problem with that is that they tend to run it as "root" rather
>>> than the rancid user.
>>>
>>> Would it be worth putting a check in so that rancid-run script won't run
>>> unless it's as a non-privileged user (or even better, build it into the
>>> automake run to discover the intended final user).
>>>
>>> Simple code sample:
>>>
>>> if [[ $EUID -eq 0 && $force -ne 1 ]]
>>> then
>>> echo "Run this as the RANCID user!"
>>> exit 1
>>> fi
>>>
>>> There's a "force" option there, just in case you really did run it as
>>> root, which seems like bad practice to me...
>>>
>>> Just a thought!
>>
>>
>> +1
>>
>> I'm all in favour of scripts not letting themselves be run as root. The
>> automake idea is better still, as permissions and ownerships issues from
>> running scripts as the wrong user can be very annoying to track down,
>> and that problem never resolves.
>>
>> Personally, I also always apply this rule forcefully with no recourse:
>>
>> Anyone who abuses the root account loses the root account.
>
> s/abuses/doesnt know what theyre doing with/
>
> anyway, i dont care for such checks, i know what my UID is and things that
> think they must protect me from myself are just annoying and its not the
> Unix manner. but, if folks would like this, i'd be willing to add a check
> that is enabled by a rancid.conf option, which i believe would be sufficient,
> right?


That could work but I'd prefer a build time option, lets the sysadmin
decide what global rules are in play.

It's a concession to reality - rancid is extensively used in corporate
and semi-corporate environments where the sysadmin often doesn't get to
decide who the other users are. Lesser of two evils - bend TheUnixWay a
little, or have to deal with chown a lot


--
Alan McKinnon
***@gmail.com

[heasley]

Sat, Jun 08, 2013 at 09:20:23PM +0100, Matthew Walster:
> > how about just adding the check to rancid.conf? that affects everything
> > that
> > reads it, the check can be customized (like adding a timer), or completely
> > disabled w/o an arg/etc.
>
>
> It'd be great if it was default-on though. Just my opinion though, like you
> say, it's only people unfamiliar with how RANCID works and think they're
> being helpful by running rancid-run immediately after altering a router.db

Like I said, only new installations would get this by default, but how about
this patch:

Index: etc/rancid.conf.sample.in
===================================================================
--- etc/rancid.conf.sample.in (revision 2704)
+++ etc/rancid.conf.sample.in (working copy)
@@ -8,6 +8,11 @@
# Collating locale
LC_COLLATE="POSIX"; export LC_COLLATE
#
+# Check that the effective UID is not root, which could lead to permissions
+# problems for user who is supposed to be running rancid.
+eval `id | sed -e 's/(.*//'`
+test "$uid" -eq 0 && echo "Do not run $0 as root!" && exit 1
+#
# Create files w/o world read/write/exec permissions, but read/exec permissions
# for group.
umask 027

[Matthew Walster]

On 28 June 2013 16:14, heasley <***@shrubbery.net> wrote:

> +eval `id | sed -e 's/(.*//'`
> +test "$uid" -eq 0 && echo "Do not run $0 as root!" && exit 1
>

Would it not make more sense just to compare $UID -- that's set by the
shell. Essentially, you'd end up with:

if [[ $UID == 0 ]]
then
echo "Do not run $0 as root!"
exit 1
fi

Either way works, though.​​

[Ed Ravin]

On Sat, Jun 29, 2013 at 11:18:46PM +0100, Matthew Walster wrote:
> On 28 June 2013 16:14, heasley <[1]***@shrubbery.net> wrote:
>
> +eval `id | sed -e 's/(.*//'`
> +test "$uid" -eq 0 && echo "Do not run $0 as root!" && exit 1
>
> Would it not make more sense just to compare $UID -- that's set by the
> shell. Essentially, you'd end up with:
> if [[ $UID == 0 ]]

Not sure if every shell supports that, remember RANCID has to run in a
lot of environments, like on Solaris systems where the /bin/sh feature set
seems to date back to 1985.

However, since we already need Perl to run the RANCID commands, how about
this:

uid=`perl -e 'print "$<\n"'`
test "$uid" -eq 0 && echo "Do not run $0 as root!" && exit 1

[heasley]

Sat, Jun 29, 2013 at 10:17:04PM -0400, Ed Ravin:
> On Sat, Jun 29, 2013 at 11:18:46PM +0100, Matthew Walster wrote:
> > On 28 June 2013 16:14, heasley <[1]***@shrubbery.net> wrote:
> >
> > +eval `id | sed -e 's/(.*//'`
> > +test "$uid" -eq 0 && echo "Do not run $0 as root!" && exit 1
> >
> > Would it not make more sense just to compare $UID -- that's set by the
> > shell. Essentially, you'd end up with:
> > if [[ $UID == 0 ]]
>
> Not sure if every shell supports that, remember RANCID has to run in a
> lot of environments, like on Solaris systems where the /bin/sh feature set
> seems to date back to 1985.

correct.

> However, since we already need Perl to run the RANCID commands, how about
> this:
>
> uid=`perl -e 'print "$<\n"'`
> test "$uid" -eq 0 && echo "Do not run $0 as root!" && exit 1
>
that'd work, but i think $> is the variable that you want.

[Hagen, Skye]

Rancid 2.3.6 does not collect VLAN information on a Cisco ME-3600 switch.
This is because the ME-3600 does not support VTP, and returns 'Invalid
command'. Rancid will only collect VLAN info on switches if the VTP mode
is transparent or server. The ShowVTP subroutine sets a flag
($DO_SHOW_VLAN) if the VTP mode is server or transparent. The ShowVLAN
routine immediately returns if this flag is not set, bypassing the VLAN
info.

My quick and dirty change was to set the flag in ShowVTP, if the type is
ME-3600. I do this before entering the while loop, so that the flag is set
before the subroutine exits because of the invalid command test. I'm not
sure that this is the best way to correct this, but it works in my
environment.

# This routine parses "show vtp status"
sub ShowVTP {
print STDERR " In ShowVTP: $_" if ($debug);

$DO_SHOW_VLAN = 1 if ($type =~ /^ME-3600X/); # ME-3600 doesn't support
VTP
while (<INPUT>) {
tr/\015//d;
last if (/^$prompt/);
next if (/^(\s*|\s*$cmd\s*)$/);
return(1) if /^\s*\^\s*$/;
return(1) if (/Line has invalid autocommand /);
return(1) if (/(Invalid (input|command) detected|Type help or )/i);
#return(1) if ($type !~ /^(2900XL|3500XL|6000)$/);
return(-1) if (/command authorization failed/i);
next if (/^Configuration last modified by/);
# the pager can not be disabled per-session on the PIX
if (/^(<-+ More -+>)/) {
my($len) = length($1);
s/^$1\s{$len}//;
}

if (/^VTP Operating Mode\s+:\s+(Transparent|Server)/) {
$DO_SHOW_VLAN = 1;
}
ProcessHistory("COMMENTS","keysort","I0","!VTP: $_");
}
ProcessHistory("COMMENTS","keysort","I0","!\n");
return(0);
}

[heasley]

Wed, Aug 07, 2013 at 06:49:27PM +0000, Hagen, Skye:
> Rancid 2.3.6 does not collect VLAN information on a Cisco ME-3600 switch.
> This is because the ME-3600 does not support VTP, and returns 'Invalid
> command'. Rancid will only collect VLAN info on switches if the VTP mode
> is transparent or server. The ShowVTP subroutine sets a flag
> ($DO_SHOW_VLAN) if the VTP mode is server or transparent. The ShowVLAN
> routine immediately returns if this flag is not set, bypassing the VLAN
> info.
>
> My quick and dirty change was to set the flag in ShowVTP, if the type is
> ME-3600. I do this before entering the while loop, so that the flag is set
> before the subroutine exits because of the invalid command test. I'm not
> sure that this is the best way to correct this, but it works in my
> environment.

should the check really be the reversed? if it _is_ a vtp client, skip
show vlan.

> # This routine parses "show vtp status"
> sub ShowVTP {
> print STDERR " In ShowVTP: $_" if ($debug);
>
> $DO_SHOW_VLAN = 1 if ($type =~ /^ME-3600X/); # ME-3600 doesn't support
> VTP
> while (<INPUT>) {
> tr/\015//d;
> last if (/^$prompt/);
> next if (/^(\s*|\s*$cmd\s*)$/);
> return(1) if /^\s*\^\s*$/;
> return(1) if (/Line has invalid autocommand /);
> return(1) if (/(Invalid (input|command) detected|Type help or )/i);
> #return(1) if ($type !~ /^(2900XL|3500XL|6000)$/);
> return(-1) if (/command authorization failed/i);
> next if (/^Configuration last modified by/);
> # the pager can not be disabled per-session on the PIX
> if (/^(<-+ More -+>)/) {
> my($len) = length($1);
> s/^$1\s{$len}//;
> }
>
> if (/^VTP Operating Mode\s+:\s+(Transparent|Server)/) {
> $DO_SHOW_VLAN = 1;
> }
> ProcessHistory("COMMENTS","keysort","I0","!VTP: $_");
> }
> ProcessHistory("COMMENTS","keysort","I0","!\n");
> return(0);
> }
>
>
>
> _______________________________________________
> Rancid-discuss mailing list
> Rancid-***@shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/rancid-discuss

[Hagen, Skye]

I agree, reversing the logic makes more sense. I knew there was a better answer than mine. For right now, I'll leave that to you for a future release.

Thanks, Skye.
________________________________________
From: heasley <***@shrubbery.net>
Sent: Thursday, August 08, 2013 8:17 AM
To: Hagen, Skye
Cc: rancid-***@shrubbery.net
Subject: Re: [rancid] Rancid not collecting VLAN info on Cisco ME-3600

Wed, Aug 07, 2013 at 06:49:27PM +0000, Hagen, Skye:
> Rancid 2.3.6 does not collect VLAN information on a Cisco ME-3600 switch.
> This is because the ME-3600 does not support VTP, and returns 'Invalid
> command'. Rancid will only collect VLAN info on switches if the VTP mode
> is transparent or server. The ShowVTP subroutine sets a flag
> ($DO_SHOW_VLAN) if the VTP mode is server or transparent. The ShowVLAN
> routine immediately returns if this flag is not set, bypassing the VLAN
> info.
>
> My quick and dirty change was to set the flag in ShowVTP, if the type is
> ME-3600. I do this before entering the while loop, so that the flag is set
> before the subroutine exits because of the invalid command test. I'm not
> sure that this is the best way to correct this, but it works in my
> environment.

should the check really be the reversed? if it _is_ a vtp client, skip
show vlan.

> # This routine parses "show vtp status"
> sub ShowVTP {
> print STDERR " In ShowVTP: $_" if ($debug);
>
> $DO_SHOW_VLAN = 1 if ($type =~ /^ME-3600X/); # ME-3600 doesn't support
> VTP
> while (<INPUT>) {
> tr/\015//d;
> last if (/^$prompt/);
> next if (/^(\s*|\s*$cmd\s*)$/);
> return(1) if /^\s*\^\s*$/;
> return(1) if (/Line has invalid autocommand /);
> return(1) if (/(Invalid (input|command) detected|Type help or )/i);
> #return(1) if ($type !~ /^(2900XL|3500XL|6000)$/);
> return(-1) if (/command authorization failed/i);
> next if (/^Configuration last modified by/);
> # the pager can not be disabled per-session on the PIX
> if (/^(<-+ More -+>)/) {
> my($len) = length($1);
> s/^$1\s{$len}//;
> }
>
> if (/^VTP Operating Mode\s+:\s+(Transparent|Server)/) {
> $DO_SHOW_VLAN = 1;
> }
> ProcessHistory("COMMENTS","keysort","I0","!VTP: $_");
> }
> ProcessHistory("COMMENTS","keysort","I0","!\n");
> return(0);
> }
>
>
>
> _______________________________________________
> Rancid-discuss mailing list
> Rancid-***@shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/rancid-discuss

[heasley]

Thu, Aug 08, 2013 at 04:37:56PM +0000, Hagen, Skye:
> I agree, reversing the logic makes more sense. I knew there was a better answer than mine. For right now, I'll leave that to you for a future release.

I think this works, but is based on rancid 3.0a2.

Index: lib/ios.pm.in
===================================================================
--- lib/ios.pm.in (revision 2722)
+++ lib/ios.pm.in (working copy)
@@ -1730,7 +1730,7 @@
s/^$1\s{$len}//;
}

- if (/^VTP Operating Mode\s+:\s+(Transparent|Server)/) {
+ if (/^VTP Operating Mode\s+:\s+(Client)/) {
$DO_SHOW_VLAN = 1;
}
ProcessHistory("COMMENTS","keysort","I0","!VTP: $_");
@@ -1744,7 +1744,7 @@
my($INPUT, $OUTPUT, $cmd) = @_;
print STDERR " In ShowVLAN: $_" if ($debug);

- ($_ = <$INPUT>, return(1)) if (!$DO_SHOW_VLAN);
+ ($_ = <$INPUT>, return(1)) if ($DO_SHOW_VLAN);

while (<$INPUT>) {
tr/\015//d;
@@ -1762,6 +1762,7 @@
my($len) = length($1);
s/^$1\s{$len}//;
}
+ return(0) if (/no virtual lans configured/i);

ProcessHistory("COMMENTS","keysort","IO","!VLAN: $_");
}

>
> Thanks, Skye.
> ________________________________________
> From: heasley <***@shrubbery.net>
> Sent: Thursday, August 08, 2013 8:17 AM
> To: Hagen, Skye
> Cc: rancid-***@shrubbery.net
> Subject: Re: [rancid] Rancid not collecting VLAN info on Cisco ME-3600
>
> Wed, Aug 07, 2013 at 06:49:27PM +0000, Hagen, Skye:
> > Rancid 2.3.6 does not collect VLAN information on a Cisco ME-3600 switch.
> > This is because the ME-3600 does not support VTP, and returns 'Invalid
> > command'. Rancid will only collect VLAN info on switches if the VTP mode
> > is transparent or server. The ShowVTP subroutine sets a flag
> > ($DO_SHOW_VLAN) if the VTP mode is server or transparent. The ShowVLAN
> > routine immediately returns if this flag is not set, bypassing the VLAN
> > info.
> >
> > My quick and dirty change was to set the flag in ShowVTP, if the type is
> > ME-3600. I do this before entering the while loop, so that the flag is set
> > before the subroutine exits because of the invalid command test. I'm not
> > sure that this is the best way to correct this, but it works in my
> > environment.
>
> should the check really be the reversed? if it _is_ a vtp client, skip
> show vlan.
>
> > # This routine parses "show vtp status"
> > sub ShowVTP {
> > print STDERR " In ShowVTP: $_" if ($debug);
> >
> > $DO_SHOW_VLAN = 1 if ($type =~ /^ME-3600X/); # ME-3600 doesn't support
> > VTP
> > while (<INPUT>) {
> > tr/\015//d;
> > last if (/^$prompt/);
> > next if (/^(\s*|\s*$cmd\s*)$/);
> > return(1) if /^\s*\^\s*$/;
> > return(1) if (/Line has invalid autocommand /);
> > return(1) if (/(Invalid (input|command) detected|Type help or )/i);
> > #return(1) if ($type !~ /^(2900XL|3500XL|6000)$/);
> > return(-1) if (/command authorization failed/i);
> > next if (/^Configuration last modified by/);
> > # the pager can not be disabled per-session on the PIX
> > if (/^(<-+ More -+>)/) {
> > my($len) = length($1);
> > s/^$1\s{$len}//;
> > }
> >
> > if (/^VTP Operating Mode\s+:\s+(Transparent|Server)/) {
> > $DO_SHOW_VLAN = 1;
> > }
> > ProcessHistory("COMMENTS","keysort","I0","!VTP: $_");
> > }
> > ProcessHistory("COMMENTS","keysort","I0","!\n");
> > return(0);
> > }
> >
> >
> >
> > _______________________________________________
> > Rancid-discuss mailing list
> > Rancid-***@shrubbery.net
> > http://www.shrubbery.net/mailman/listinfo.cgi/rancid-discuss