From dpfleger at pfleger.org  Mon Nov  1 22:44:00 2004
From: dpfleger at pfleger.org (Dan Pfleger)
Date: Mon, 01 Nov 2004 14:44:00 -0800
Subject: Bug when using SSH on CatOS devices
In-Reply-To: <20041031200449.GN81532@freesbee.wheel.dk>
References: <20041028232051.GS26832@shrubbery.net>
 <20041026113333.GO66193@freesbee.wheel.dk>
 <20041027234953.GW19776@shrubbery.net>
 <20041028071326.GI66193@freesbee.wheel.dk>
 <20041028232051.GS26832@shrubbery.net>
Message-ID: <5.1.1.5.2.20041101141419.033dc6d8@mail.pfleger.org>

Hi Michael,
Don't know if anyone responded, but I've seen similar problems on older 
Extremes when it would omit EOL(s) at random places.

In this case, it looks like CatOS or the SSH client is omitting/munging the 
terminal's last \r\n based on your line:
   Switch> (enable) exitConnection to switch.foo.bar closed by remote host.

My solution for Extreme's was a bit of a hack, but it went something like 
the additional lines below.  Don't think it is worth putting in a patch 
unless this is a more common problem, but rather just a one off 
solution.  I forget if you need to put in a \n to make the file diff 
correctly or not, but you might need to re-output the line too if it is not 
100% consistent.

Hope this helps...
  TOP: while(<INPUT>) {
       tr/\015//d;
       if (/> \(enable\) ?exit$/) {
             $clean_run=1;
             last;
       }
       # Check and see if it was a "less clean" run.
       elsif (/> \(enable\) ?exitConnection to (\S+) closed by remote host\./){
             $clean_run=1;
             last;
       }
  }



At 12:04 PM 10/31/2004, Michael Lyngb?l wrote:
>On 28.10.2004 16:20:51 +0000, john heasley wrote:
>
> > > > > I'm using RANCID 2.3.1 to get config from a bunch of Cisco 6500 
> running
> > > > > CatOS 6.4.
> > > > >
> > > > > Login is via SSH (on FreeBSD 5.3 w/ OpenSSH 3.8.1p1).
> > > > >
> > > > > cat5rancid has the following code at around line 1062:
> > > > >
> > > > >    TOP: while(<INPUT>) {
> > > > >        tr/\015//d;
> > > > >        if (/> \(enable\) ?exit$/) {
> > > > >            $clean_run=1;
> > > > >            last;
> > > > >        }
> > > > >
> > > > > where $clean_run would be set to true if the prompt matches 'exit'.
> > > > > However when using SSH the exit becomes:
> > > > >
> > > > >    Switch> (enable)Connection to switch.foo.bar closed by remote 
> host.
> > > > >    Connection to switch.foo.bar closed.
> > > >
> > > > does it do this when you ssh in manually?
> > >
> > > Yes, eg. when I do:
> > >
> > >     clogin -c 'sh ver' switch.foo.bar
> >
> > I meant "ssh switch.foo.bar"
>
>Oh, sorry. No:
>
>Switch> (enable) exitConnection to switch.foo.bar closed by remote host.
>Connection to switch.foo.bar closed.





From mcooper at blueyonder.co.uk  Thu Nov  4 18:21:01 2004
From: mcooper at blueyonder.co.uk (Mark Cooper)
Date: Thu, 04 Nov 2004 18:21:01 +0000
Subject: jerancid for ERX's with "service manual-commit"?
In-Reply-To: <20040903191014.GC78196@partan.com>
References: <F6A1F63C31CAF14FB71251F06B340C1708B8E231@ZANEVS01.cc-ntd1.covad.com> <20040903191014.GC78196@partan.com>
Message-ID: <418A730D.90202@blueyonder.co.uk>

Andrew Partan wrote:

> On Fri, Sep 03, 2004 at 12:04:50PM -0700, Williamson, Todd wrote:
> 
>>I altered bin/jerancid to issue "show running-configuration exclude
>>interface atm" instead of "show configuration".  I also tried it without
>>the "exclude interface atm" piece and with a 1200 second timeout (there
>>are *a lot* of pre-provisioned atm sub-interfaces in our configs).
>>
>>but jerancid's debug output always indicates the following:

Think this is related to the same problem I'm seeing which is jerancid 
b0rking when coming across things not 'in sync'

I commented out the following lines in jerancid and everything works fine:-
         # fail if the RP is amid the auto-sync process
#       return(-1) if (/auto-sync enabled/ && !/in sync/);
         # fail if the RP is amid the auto-sync process
#       return(-1) if (/active\/standby/ && !/not sync/);

I haven't supplied a patch as yet as I saw this as a kludge until I 
could find out from Juniper what its all about ;)

HTH

-- 

Mark Cooper
http://pvrhw.goldfish.org/ - Open Source PVR Hardware Database


From TWilliam at Covad.COM  Thu Nov  4 19:33:29 2004
From: TWilliam at Covad.COM (Williamson, Todd)
Date: Thu, 4 Nov 2004 11:33:29 -0800
Subject: jerancid for ERX's with "service manual-commit"?
Message-ID: <AF696B16DAC33B46B1911BAD0CCECF7F0356262F@ZANEVS03.cc-ntd1.covad.com>

> -----Original Message-----
> From: Mark Cooper 
> Subject: Re: jerancid for ERX's with "service manual-commit"?
> 
> Think this is related to the same problem I'm seeing which is 
> jerancid 
> b0rking when coming across things not 'in sync'
> 
> I commented out the following lines in jerancid and 
> everything works fine:-
>          # fail if the RP is amid the auto-sync process
> #       return(-1) if (/auto-sync enabled/ && !/in sync/);
>          # fail if the RP is amid the auto-sync process
> #       return(-1) if (/active\/standby/ && !/not sync/);
> 
> I haven't supplied a patch as yet as I saw this as a kludge until I 
> could find out from Juniper what its all about ;)

that's just about what i changed to get it working.  i altered the sync
test case and changed the configuration command a bit for use with
"service manual-commit" ("show config" doesn't work in this case); the
"exclude interface atm" piece is there to keep the clogin sessions from
timing out and cull the cruft from the config (lots of pre-prov'ed ATM
subinterfaces):

prodeng01:rancid$ diff jerancid.old jerancid
266c266
<       return(-1) if (/active\/standby/ && !/not sync/);
---
>       return(-1) if (/active\/standby/ && /not sync/);
545c545
<       'show configuration'    => "WriteTerm"
---
>       'show running-configuration exclude interface atm'      =>
"WriteTerm"
556c556
<       "show configuration"
---
>       "show running-configuration exclude interface atm"


everything has been working fine since removing the negation of the
negative ;)  

i'd love to help out (rancid makes my life so much easier :)  if there's
any assistance i can offer with respect to e-series testing, please
contact me off-list.

thanks,
todd

> 
> HTH
> 
> -- 
> 
> Mark Cooper
> http://pvrhw.goldfish.org/ - Open Source PVR Hardware Database
> 

todd


From justin at grote.name  Mon Nov  8 04:15:21 2004
From: justin at grote.name (Justin Grote)
Date: Sun, 7 Nov 2004 21:15:21 -0700
Subject: Rancid Subversion 2.3.1 Patch
Message-ID: <5310441839.20041107211521@grote.name>

Greetings,

As promised, here is a patch to rancid 2.3.1 to enable Subversion support. It is a drop-in replacement for rancid, meaning it functions exactly the same, all the configuration files/procedures are exactly the same as well. The only thing that has been modified is that the backend has just been converted from CVS to Subversion. 

This is just a proof of concept and is NOT SUPPORTED BY THE RANCID TEAM. I've been running this in place of 2.3.1 for about a month now and it has functioned flawlessly, including diffs, updates mailouts,  and every other functionality I could test. (I made this version a few hours after I posted about it on this list, took no time at all).

RANCID devs, please see my final note at the bottom and let me know what you think.

This patch is also available temporarily at http://myweb.cableone.net/rastan/rancidSVN.diff (I'm in the middle of switching hosting providers so my primary site is down)



You, of course, need to have Subversion on your system to run this. Most of the major Linux distributions come with subversion (it's almost as ubiquitous as CVS in new distributions!), including SuSE 9.1, Fedora (Red Hat) Core 2, Mandrake 10, Gentoo, Debian, etc.

To apply the patch, extract the rancid-2.3.1.tar.gz source package, place the patch incide the rancid-2.3.1 directory that is created, and then from inside the rancid-2.3.1 directory type:

# patch -p1 < rancidSVN.diff
(# is your prompt, do not include it)

Then install as normal.

Some notes:

- If you want to use your existing rancid CVS history with this tool, you can use the excellent cvs2svn tool to convert your existing history over to subversion: http://cvs2svn.tigris.org/

- Thanks to subversion, you can move and/or rename router entries and still preserve their history. You can even move them between groups safely! To do this, check out a separate copy of the repository, then svn mv <config> <newconfiglocation>. Edit your router.db files as necessary, then do an svn commit. Rancid will be none the wiser.

- Since I coded it as a drop-in replacement, your repository has to be on the same server. I do have a working version that allows your repository to be hosted anywhere subversion lets it. I've set up a test environment with multiple rancid's collecting config info for different sets of routers and then committing to a central repository. It is quite cool and opens up a lot of possibilities for making rancid more scalable.

***************
Note to Devs:
***************
I hope this proof of concept gives you an example that you can play with and see how subversion works. I think that it's improvements over CVS are highly compelling to be used in rancid. The next version I plan to work on would be a non-intrusive patch that would add subversion support as a configurable option. It would be a simple switch in rancid.conf such as USESUBVERSION=yes. Let me know if you are interested and I'll publish my development repository if you want to keep tabs on it (my repository is in Subversion, naturally) ;). 

______________________________
Justin Grote
Network Architect, CCNA
JWG Networks
Email: nospam-justin at grote.name (remove nospam-)
SMS:   nospam-rastan at vtext.com (remove nospam-)
Phone: (208) 631-5440
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rancidSVN.diff
Type: application/octet-stream
Size: 5498 bytes
Desc: not available
Url : http://www.shrubbery.net/pipermail/rancid-discuss/attachments/20041107/be4c0857/attachment.obj 

From r.oliver at chello.nl  Mon Nov  8 08:37:28 2004
From: r.oliver at chello.nl (r.oliver)
Date: Mon, 8 Nov 2004 09:37:28 +0100
Subject: Rancid Subversion 2.3.1 Patch
In-Reply-To: <5310441839.20041107211521@grote.name>
Message-ID: <20041108083724.PTID2038.amsfep14-int.chello.nl@pebbles>

Hi Justin,

Is there an app similar to cvsweb or viewcvs for view a subversion tree?

Cheers

Rod Oliver 

> -----Original Message-----
> From: owner-rancid-discuss at shrubbery.net 
> [mailto:owner-rancid-discuss at shrubbery.net] On Behalf Of Justin Grote
> Sent: Monday, November 08, 2004 5:15 AM
> To: rancid-discuss at shrubbery.net
> Subject: Rancid Subversion 2.3.1 Patch
> 
> Greetings,
> 
> As promised, here is a patch to rancid 2.3.1 to enable 
> Subversion support. It is a drop-in replacement for rancid, 
> meaning it functions exactly the same, all the configuration 
> files/procedures are exactly the same as well. The only thing 
> that has been modified is that the backend has just been 
> converted from CVS to Subversion. 
> 
> This is just a proof of concept and is NOT SUPPORTED BY THE 
> RANCID TEAM. I've been running this in place of 2.3.1 for 
> about a month now and it has functioned flawlessly, including 
> diffs, updates mailouts,  and every other functionality I 
> could test. (I made this version a few hours after I posted 
> about it on this list, took no time at all).
> 
> RANCID devs, please see my final note at the bottom and let 
> me know what you think.
> 
> This patch is also available temporarily at 
> http://myweb.cableone.net/rastan/rancidSVN.diff (I'm in the 
> middle of switching hosting providers so my primary site is down)
> 
> 
> 
> You, of course, need to have Subversion on your system to run 
> this. Most of the major Linux distributions come with 
> subversion (it's almost as ubiquitous as CVS in new 
> distributions!), including SuSE 9.1, Fedora (Red Hat) Core 2, 
> Mandrake 10, Gentoo, Debian, etc.
> 
> To apply the patch, extract the rancid-2.3.1.tar.gz source 
> package, place the patch incide the rancid-2.3.1 directory 
> that is created, and then from inside the rancid-2.3.1 directory type:
> 
> # patch -p1 < rancidSVN.diff
> (# is your prompt, do not include it)
> 
> Then install as normal.
> 
> Some notes:
> 
> - If you want to use your existing rancid CVS history with 
> this tool, you can use the excellent cvs2svn tool to convert 
> your existing history over to subversion: http://cvs2svn.tigris.org/
> 
> - Thanks to subversion, you can move and/or rename router 
> entries and still preserve their history. You can even move 
> them between groups safely! To do this, check out a separate 
> copy of the repository, then svn mv <config> 
> <newconfiglocation>. Edit your router.db files as necessary, 
> then do an svn commit. Rancid will be none the wiser.
> 
> - Since I coded it as a drop-in replacement, your repository 
> has to be on the same server. I do have a working version 
> that allows your repository to be hosted anywhere subversion 
> lets it. I've set up a test environment with multiple 
> rancid's collecting config info for different sets of routers 
> and then committing to a central repository. It is quite cool 
> and opens up a lot of possibilities for making rancid more scalable.
> 
> ***************
> Note to Devs:
> ***************
> I hope this proof of concept gives you an example that you 
> can play with and see how subversion works. I think that it's 
> improvements over CVS are highly compelling to be used in 
> rancid. The next version I plan to work on would be a 
> non-intrusive patch that would add subversion support as a 
> configurable option. It would be a simple switch in 
> rancid.conf such as USESUBVERSION=yes. Let me know if you are 
> interested and I'll publish my development repository if you 
> want to keep tabs on it (my repository is in Subversion, 
> naturally) ;). 
> 
> ______________________________
> Justin Grote
> Network Architect, CCNA
> JWG Networks
> Email: nospam-justin at grote.name (remove nospam-)
> SMS:   nospam-rastan at vtext.com (remove nospam-)
> Phone: (208) 631-5440
> 



From justin at grote.name  Mon Nov  8 17:07:56 2004
From: justin at grote.name (Justin Grote)
Date: Mon, 8 Nov 2004 10:07:56 -0700
Subject: Rancid Subversion 2.3.1 Patch
In-Reply-To: <20041108083724.PTID2038.amsfep14-int.chello.nl@pebbles>
References: <5310441839.20041107211521@grote.name>
 <20041108083724.PTID2038.amsfep14-int.chello.nl@pebbles>
Message-ID: <1412231716.20041108100756@grote.name>

ViewCVS does work with a subversion tree. My personal favorite is Chora
(part of the Horde framwork) at http://www.horde.org/chora

______________________________
Justin Grote
Network Architect, CCNA
JWG Networks
Email: nospam-justin at grote.name (remove nospam-)
SMS:   nospam-rastan at vtext.com (remove nospam-)
Phone: (208) 631-5440

------------------------------
Original Message Follows
------------------------------
ro> Hi Justin,

ro> Is there an app similar to cvsweb or viewcvs for view a subversion tree?

ro> Cheers

ro> Rod Oliver 

>> -----Original Message-----
>> From: owner-rancid-discuss at shrubbery.net 
>> [mailto:owner-rancid-discuss at shrubbery.net] On Behalf Of Justin Grote
>> Sent: Monday, November 08, 2004 5:15 AM
>> To: rancid-discuss at shrubbery.net
>> Subject: Rancid Subversion 2.3.1 Patch
>> 
>> Greetings,
>> 
>> As promised, here is a patch to rancid 2.3.1 to enable 
>> Subversion support. It is a drop-in replacement for rancid, 
>> meaning it functions exactly the same, all the configuration 
>> files/procedures are exactly the same as well. The only thing 
>> that has been modified is that the backend has just been 
>> converted from CVS to Subversion. 
>> 
>> This is just a proof of concept and is NOT SUPPORTED BY THE 
>> RANCID TEAM. I've been running this in place of 2.3.1 for 
>> about a month now and it has functioned flawlessly, including 
>> diffs, updates mailouts,  and every other functionality I 
>> could test. (I made this version a few hours after I posted 
>> about it on this list, took no time at all).
>> 
>> RANCID devs, please see my final note at the bottom and let 
>> me know what you think.
>> 
>> This patch is also available temporarily at 
>> http://myweb.cableone.net/rastan/rancidSVN.diff (I'm in the 
>> middle of switching hosting providers so my primary site is down)
>> 
>> 
>> 
>> You, of course, need to have Subversion on your system to run 
>> this. Most of the major Linux distributions come with 
>> subversion (it's almost as ubiquitous as CVS in new 
>> distributions!), including SuSE 9.1, Fedora (Red Hat) Core 2, 
>> Mandrake 10, Gentoo, Debian, etc.
>> 
>> To apply the patch, extract the rancid-2.3.1.tar.gz source 
>> package, place the patch incide the rancid-2.3.1 directory 
>> that is created, and then from inside the rancid-2.3.1 directory type:
>> 
>> # patch -p1 < rancidSVN.diff
>> (# is your prompt, do not include it)
>> 
>> Then install as normal.
>> 
>> Some notes:
>> 
>> - If you want to use your existing rancid CVS history with 
>> this tool, you can use the excellent cvs2svn tool to convert 
>> your existing history over to subversion: http://cvs2svn.tigris.org/
>> 
>> - Thanks to subversion, you can move and/or rename router 
>> entries and still preserve their history. You can even move 
>> them between groups safely! To do this, check out a separate 
>> copy of the repository, then svn mv <config> 
>> <newconfiglocation>. Edit your router.db files as necessary, 
>> then do an svn commit. Rancid will be none the wiser.
>> 
>> - Since I coded it as a drop-in replacement, your repository 
>> has to be on the same server. I do have a working version 
>> that allows your repository to be hosted anywhere subversion 
>> lets it. I've set up a test environment with multiple 
>> rancid's collecting config info for different sets of routers 
>> and then committing to a central repository. It is quite cool 
>> and opens up a lot of possibilities for making rancid more scalable.
>> 
>> ***************
>> Note to Devs:
>> ***************
>> I hope this proof of concept gives you an example that you 
>> can play with and see how subversion works. I think that it's 
>> improvements over CVS are highly compelling to be used in 
>> rancid. The next version I plan to work on would be a 
>> non-intrusive patch that would add subversion support as a 
>> configurable option. It would be a simple switch in 
>> rancid.conf such as USESUBVERSION=yes. Let me know if you are 
>> interested and I'll publish my development repository if you 
>> want to keep tabs on it (my repository is in Subversion, 
>> naturally) ;). 
>> 
>> ______________________________
>> Justin Grote
>> Network Architect, CCNA
>> JWG Networks
>> Email: nospam-justin at grote.name (remove nospam-)
>> SMS:   nospam-rastan at vtext.com (remove nospam-)
>> Phone: (208) 631-5440
>> 



From justin at grote.name  Thu Nov 11 16:06:50 2004
From: justin at grote.name (Justin Grote)
Date: Thu, 11 Nov 2004 09:06:50 -0700
Subject: Rancid Subversion 2.3.1 Patch (Minor Bugfix)
Message-ID: <1026716361.20041111090650@grote.name>

I received a couple reports that the diff function wasn't working for them. I guess some systems have their GCC diff set to "diff -U 4" instead of just "diff". I fixed this so SVN uses it's internal diff function instead of relying on an external one (although an external one can be used with subversion if necessary. Here's the updated patch. Use this patch against the rancid-2.3.1 sources in exactly the same manner as the previous patch.

Thanks for the positive response!

______________________________
Justin Grote
Network Architect, CCNA
JWG Networks
Email: nospam-justin at grote.name (remove nospam-)
SMS:   nospam-rastan at vtext.com (remove nospam-)
Phone: (208) 631-5440
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rancid-2.3.1-SVN.diff
Type: application/octet-stream
Size: 5279 bytes
Desc: not available
Url : http://www.shrubbery.net/pipermail/rancid-discuss/attachments/20041111/77a2f3e5/attachment.obj 

From bob at netsurf.net  Wed Nov 24 19:05:25 2004
From: bob at netsurf.net (Bob Bosiljevac)
Date: Wed, 24 Nov 2004 14:05:25 -0500 (EST)
Subject: Using rancid to hop from router to router
In-Reply-To: <Pine.LNX.4.44.0410141336000.8690-100000@white.netsurf.net>
References: <Pine.LNX.4.44.0410141336000.8690-100000@white.netsurf.net>
Message-ID: <Pine.LNX.4.58.0411202144030.20373@zed>

Here's what I was able to do leveraging off of Krzysztof's dssh method
idea.....

in .clogin:

add method 10.10.10.10 dssh:intermediate.router.net
add password 10.10.10.10 cisco cisco

and where intermediate.router.net has its own .clogin entries and works
perfectly fine in the original way.

Then mods to clogin as follows:
	- some global variables needed to tell if were two hopping
	- adding the dssh connection method code which will spawn clogin
	  to the intermediate router and return control to the rest of
	  this clogin instance (recursion! :-)
	- using the two hop variable to log off two times, once for each
          router

This assumes that you will use telnet to get from the first router to the
second. Also, IP address clashes can be resolved by using different DNS
names for the same second (internal) IP or by creating unique hostname
entries in the config of the first hop router.

This seems to solve the initial problem. It just needs more error
handling.

Bob.


This is for # $Id: clogin.in,v 1.72 2004/01/11 05:39:15 heas Exp $

$ diff -U3  clogin.orig clogin
--- clogin.orig Fri Feb 20 12:54:39 2004
+++ clogin      Fri Nov 12 12:59:52 2004
@@ -58,6 +58,8 @@
 # attempt at platform switching.
 set platform ""

+set two_hop 0
+
 # Find the user in the ENV, or use the unix userid.
 if {[ info exists env(CISCO_USER) ] } {
     set default_user $env(CISCO_USER)
@@ -289,6 +291,7 @@
 proc login { router user userpswd passwd enapasswd cmethod cyphertype } {
     global spawn_id in_proc do_command do_script platform
     global prompt u_prompt p_prompt e_prompt sshcmd
+    global two_hop env
     set in_proc 1
     set uprompt_seen 0

@@ -316,6 +320,22 @@
                send_user "\nError: rsh failed: $reason\n"
                exit 1
            }
+       } elseif [string match "dssh*" $prog] {
+               send_user "\ntrying dssh method \n"
+           regexp {dssh(:([^[:space:]]+))*} $prog command suffix hophost
+           if {"$hophost" == ""} {
+###            set retval [ catch {spawn telnet $router} reason ]
+           } else {
+               set retval [ catch {spawn $env(HOME)/bin/clogin $hophost} reason ]
+               expect "*#"
+               send "telnet $router\r"
+               set two_hop 1
+           }
+           if { $retval } {
+               send_user "\nError: dssh failed: $reason\n"
+               exit 1
+           }
+
        } else {
            puts "\nError: unknown connection method: $prog"
            return 1
@@ -476,6 +496,7 @@
 # Run commands given on the command line.
 proc run_commands { prompt command } {
     global in_proc platform
+    global two_hop
     set in_proc 1

     # If the prompt is (enable), then we are on a switch and the
@@ -571,6 +592,10 @@

     if { [ string compare "extreme" "$platform" ] } {
        send "exit\r"
+       if { $two_hop } {
+               expect "*#"
+               send "exit\r"
+       }
     } else {
        send "quit\r"
     }


On Thu, 14 Oct 2004, Krzysztof Adamski wrote:

> From: Krzysztof Adamski <kadamski at netsurf.net>
> To: Tony Tauber <ttauber at 1-4-5.net>
> Cc: rancid-discuss at shrubbery.net
> Date: Thu, 14 Oct 2004 14:05:15 -0400 (EDT)
> Subject: Re: Using rancid to hop from router to router
>
> I started hacking the code a bit, but stopped when I run out of knowledge of tcl
> :-)
>
> Here is what I did for the auth part to the .clogin:
>
> add method 128.1.253.33 dssh:abc.example.com
> add user 128.1.253.33 testuser
> add password 128.1.253.33 testpass enablepass
> add hoppassword 128.1.253.33 2ndenablepass
>
> and in clogin (this code will login to abc.example.com router:
>         } elseif [string match "dssh*" $prog] {
>                 send_user "\ntrying dssh method $hoppassword\n"
>             regexp {dssh(:([^[:space:]]+))*} $prog command suffix hophost
>             if {"$hophost" == ""} {
> ###             set retval [ catch {spawn telnet $router} reason ]
>             } else {
>                 set retval [ catch {spawn $sshcmd -c $cyphertype -x -l $user $hophost} reason ]
>             }
>             if { $retval } {
>                 send_user "\nError: dssh failed: $reason\n"
>                 exit 1
>             }
>
> This is where my knowledge of tcl stopped me from getting any further.
>
> K
>
> On Thu, 14 Oct 2004, Tony Tauber wrote:
>
> > On Wed, 13 Oct 2004, Krzysztof Adamski wrote:
> >
> > > I need to collect the config from routers that are not directly
> > > reachable by the host that rancid runs on. I can ssh to the first
> > > router, then telnet to the ones that I need the config from. Since
> > > my knowledge of expect and TCL is nonexistent and before I try to
> > > reinvent the wheel I was wondering if anybody has modified
> > > the clogin script to to this extra hop?
> > >
> > > K
> >
> > I have a similar need.  In some cases CLI access to the routers is
> > only available via term server and in some cases routers beyond the
> > ones that are connected to the term server can be reached via telnet
> > or SSH from that first router.
> >
> > >From reviewing the archives, some similar threads have come up over
> > the years related to the term server case and your case seems pretty
> > related.  I started hacking away but never finished.
> >
> > The problem seems to me to be that the __login scripts are responsible
> > for the connection *and* the authentication.  Furthermore, the
> > hostname passed to __rancid and thus to __login is taken as the DNS
> > name of the thing you want to connect to.  This results in ambiguity
> > down the line if, say, you want to telnet to a device and then telnet
> > to different down-stream devices or connect via different async ports
> > on a term server.
> >
> > I think what needs to happen is to allow an override of the
> > devicename/connection linkage by passing a switch with this info.
> > As it is, the devicename is overloaded.  Also, it'd be nice/necessary
> > to allow one to run the authentication bits separately from the
> > connection bits so one could pass different username/password for
> > these different devices.
> >
> > That's the general idea as I see it.  If people want to discuss or try
> > and flesh out further the change, it'd be welcome since it does seem
> > to be useful functionality to add.
> >
> > Tony
> >
>