rancid and relays using usercmd patch

As I've blogged before, rancid is a really awesome new cisco config differ.

I monitor about 100 devices, and all was well so far.
Now I've come across a device that I can't reach directly from my rancid host. It's not possible to create a direct network connection, or to use ssh tunnels or netcat to forward those ports using a relay host.
Instead I found a much simpler and more elegant solution. Albeit this involves patching rancid.


After playing with ProxyCommands and netcat I came across this patch on the rancid-discuss list from 2006.
The principle seems simple, elegant but still straight forward. Extending the clogin script to define a new method that can use custom commands to establish the connection.
This is accomplished by adding two new commands.

add method testrouter {usercmd}
add usercmd testrouter {ssh} {-t} {termserver01} {cu -l /dev/tty01 -s 9600}
add usercmd_chat testrouter {Connected.} {\r}

In my case I wanted to ssh to the relay host, and then telnet to my device from there. This is how I set that up:

add method my-alias usercmd
add usercmd my-alias {ssh} {-t} {rancid@my-relay-host} {telnet my-device}
add user my-alias rancid
add password my-alias rancid

Two caveats to this situation:

• The username on my-relay-host must match the username used on the device my-alias.
• This requires password less authentication to my-relay-host. I've used ssh standard key exchange.

Read More

TortoiseSVN 1.8.0 and NTLM Authentication on Windows

Subversion 1.8.0 was released recently, and my favorite svn client was updated, too. I had hoped this update to go down smooth, just like going from 1.6 to 1.7 in the past.
This time around there are some authentication issues it seems. TortoiseSVN has dropped neon and relies now solely on serf to handle HTTP(S) authentication.

The release notes mention some server-side configuration changes for optimal performance, but they fail to mention that serf doesn't play nice with NTLM authentication. It does work well with Kerberos though.

So, if you've set up Apache like I described here or here, just add this line to make Kerberos the default and have  TSVN 1.8.0 play nice with single-sign-on.

SSPIPackage Negotiate

This will change the default authentication schema (NTLM) to Kerberos. This will cause TortoiseSVN < 1.8 to prompt for username and password, because the underlying neon library cannot handle Kerberos. TortoiseSVN 1.8 and later will be fine though.
You can force older clients to use serf for specific servers though. I've previously written about it here.

There is a big discussion going on in the subversion-dev mailing list about how to best fix this behavior. It is expected that TortoiseSVN 1.8.1 will include a fix for this issue.

This issue and the fact that most SVN tools still haven't been built on top of subversion 1.8 means that you should stay on TortoiseSVN 1.7.x for now.

Read More