« first day (14 days earlier)      last day (111 days later) » 

01:58
anyone here
 
5 hours later…
06:54
I'm here. Sometimes
07:14
@JohnJensen, your profile mentions automation, I would be interested in hearing about your automation work
07:25
hey Mike
I'm actually somewhat of a novice. I learned Perl and started to pick up python at the new gig
wrote some code that uses exscript and networkx to generate MPLS paths for LSP's based on the arp tables of brocade kit
we'd originally tried to do strict hops in the manual ERO's all the way through, but that didn't work out so well
if there were 2 equal cost paths, sometimes the script would pick a secondary path that transited the same physical link as the primary :-)
so i wound up just doing strict for the first immediate hop and loose for the loopback of the remote device
python is proving to be fun, definitely feels like there's a lower "barrier of entry" for writing modules etc. than perl
plus the OO feels nicer to me
I worked for an ISP that was using TE as well... we did not have tunnel automation at the time, and I wound up doing the same thing for routing LSPs
perl has moose nowadays but you don't get that for free :-)
good stuff
I was a perl guy for about 10 years and finally got fed up with the bad error messages... one day I tried python and I've been hooked ever since... OO makes a lot of automation easier, if you code the classes correctly
are you using exscript on linux or windows?
yeah, that's still kind of where i fall short a bit. perl OO seemed really kludgy and i never quite understood it fully (at least until python gave me some more context) but i managed to "work my way around it" by just writing tons of procedural code
or functional code? is that the right term?
but yeah, trying to break myself of that habit
exscript on linux
i've also done some hacking on ncclient
i'd love to get us to where we rely mostly on NETCONF
wish that was more mainstream
seems like Juniper were the only ones that got that part right
I haven't done much work with netconf yet... actually that's been on my list to investigate for a while... are you doing netconf with Cisco gear, or is it mostly junos?
07:34
brocade actually
I'm curious how that Aaron person will fare with the IOS-XR XML agent
but previously Cisco didn't do netconf well at all
they wouldn't properly serialize their configs into xml
*xml elements anyway
you'd just have a bunch of "cisco config" snippets in CDATA's or something like that
:-)
Brocade is good (they have the fundamentals there, they just need to get more of their configuration directives NETCONF-accessible, but they're getting there), but JunOS is the best IMO
yeah, that (cisco issues with xml serialization) makes sense... I don't do much xml work... when you say cisco config in CDATAs, you mean you'd have to hack around cisco's XML problems with static configurations in CDATA elements?
no i mean, you'd see like literal Cisco config in CDATA elements
ah, instead of an XML element heirarchy
ya
trying to find an example
John, I'm curious do you ever write any C code?
07:40
I wish
Do you?
I've read through a bit of tac_plus and quagga code
but i haven't written any C
ok... my C is fairly infantile... but have this idea that what I really need (and maybe other people too) is a python interface to putty...
that would require some C skills... I'm trying to find some people to team up with who'd be interested in that kind of a project
what are the goals/use cases?
(brb stepping out for a smoke - where are you located btw?)
A truly cross-platform CLI scrapper
pexpect is basically only written for linux... it requires a PTY, and that's out of the question on windows... exscript may have better cross platform support, but the scope of that project is a much higher-level API than what I want... I just want a cross-platform API to automate telnet / ssh without involving how you parse vendor-specific login methods
np... I'm in Austin, TX
cool. heard the music scene is pretty awesome there
what do you mean by parsing vendor-specific login messages?
i mean anything expect-based is going to require some amount of prompt interpretation
yeah, Austin has got awesome music... not that I can ever get out any more... we just had our first child last year, so that's eating our ability to do the music club scene
07:52
Congratulations! No kids for me yet, but getting married in July
and the fiancee recently got a job as a manager for a baby clothing/accessories/etc store
so I can probably assume my kid-free days are numbered. :-)
exscript focuses on giving you an API to login to a Cisco or Juniper... contrast with pexpect, which has lower-level send() or expect() methods...
oh, yeah, it does, but you can also use the python module directly, which is what i do
lol... yeah, I don't care what they say before marriage... my wife and I "weren't planning to have kids either"
but yeah exscript does sit on top of pexpect, but you also get the handy accounts management and "threading" (not sure if it's real threading or not) and things like that
I didn't realize exscript was using pexpect under the covers...
07:55
ya
at least I thought it was
s/thought/assumed :-)
I wonder how he gets it working on windows... I have seen some ugly hacks to get pexpect up on windows, but that's not what I want for this library... in fact that's why I want it... linux, windows, and OSX support from the beginning... simple installation, and one api with consistent behavior on all platforms
anyway, that's my pet project... one day I will figure out how to start it :)
well it sounds like a good idea IMO! I wish I knew more C, otherwise I'd totally volunteer to do what I could to help get it off the ground
also would be good to include NETCONF support :D
no problems... I just like to network with other scripters for ideas
although to be fair that would probably introduce a ton of scope creep initially
true... netconf protocol would be a natural addition after I got the basic telnet / ssh stuff working
putty supports raw sockets, so I think it's possible
08:01
do you mean initiating socket connections from putty, or to putty itself?
from putty... netconf is a higher level protocol, but similar client-server model as telnet and ssh
oh yeah, but the underlying transport is SSH anyway
just to "not port 22" :-)
if you take a look at the ncclient code he's using paramiko to do the transport
I looked at paramiko, but there is no telnet support... and python's native telnet hasn't really got me that excited
we still have devices that are only telnet
08:04
hm
getting downtime in our environment is hard... we get one real maintenance window a year, at best
you can interact with the C stdlib in python yeah? wonder how hard it would be to make a basic telnet client
wowzas
you still in the SP industry?
yes, but that only gets me telnet... I want both
no electronics manufacturing... I work at a semiconductor fab... 24x7x365
they have people making chips on thanksgiving and christmas
:-(
i thought robots did all that
well, the robots need guidance... and a network :-)
08:07
well, if you got the telnet part down, wouldn't paramiko be able to do the rest? or is it not that great on windows?
I look at putty as a way to abstract support for both telnet and ssh across platforms...
ah, i see
if I write stdlib c to get a decent telnet client on linux, then I have to deal with porting to windows
doh
that's right
putty solves all that... they do the nasty cross-platform stuff... I just surf on top of their work
actually there is already a putty project that interfaces with Lua...
08:09
tbh how many linux folks use putty on linux though? :-)
or would you just omit the putty bits for the linux port
that's not really an issue... I can redistribute putty with the library
nobody even has to know I'm shipping putty with it... although it would be obvious during compilation... and of course, from the name of the library
fair point
well, i'm off to bed. if you want to drop me an e-mail it's in my profile. even though i don't write C, i'm keen to help out in any way I can - if you manage to get the time :-)
good chatting with you
sure thing... good talking with you too... I'll shoot you an email with my contact info
sweet, sounds good. ttys
 
3 hours later…
11:04
hi
 
3 hours later…
13:38
If you haven't read it yet, tools.ietf.org/html/rfc2549
 
3 hours later…
16:36
But read rfc1149, first.

« first day (14 days earlier)      last day (111 days later) »