hi again :) > From: "[email protected]" <[email protected]>
> What I missed in Rancid was the option to extend commands per chassis / type. > Especially new devices such as ASR1k & Co. are not known and therefore some >stuff is missing. > Other stuff has to be excluded (e.g. tracelogs & foo.bar files which are >generated daily) for specific models. that's basically in the core of Gerty: you define a hierarchy of device classes, and there's a flexible way to assign device classes to specific devices. If the supplied methods aren't enough, you can subclass the corresponding Perl module and add your own pre-processing. There will be a module which imports devices from an SQL database, and then you have a full control on your inventory management. > What is also important is the option to use the tools to do some > mass-updates >(like with 'clogin'), maybe this can be improved with some intelligent >feedback > >options (e.g. task: "update interface" -> was is ok or did it failed? or IOS >upgrades - maybe with some options to do rollbacks?). All behaviour processing is based on Expect.pm from CPAN. So, with some Perl skills, you can add your own interactive procedure to talk to the devices. Also there's a clear distinction between Gerty's Perl modules and your own, and they would never mix up and overwritten by the installer. And of course you can always hire me to do some automation :-)) > But to come back to needed features for at least me to replace rancid: > - CVS storage of configs (--> cvsweb.cgi to see / compare them) see my previous email. SVN integration is pretty easy and does not actually require RANCID or anything else. With a couple of shell commands, you can do this already. > - threaded / parallel collection --> must be speedy ,) (we have ~5-6k > devices >in rancid; working fine today) it has already a forking mechanism: after all device information is fetched, the job is divided among as many child processes as you specify. I was once doing 200 parallel telnet sessions from a VM with 512MB RAM, and it was going smoothly. > - optional mail notification of diff's (e.g. by some categories? like a > change > >in interface ip's trigger an update? but then ignore configuration changes >for >VRF's to trigger a mail - but keep them in config-CVS ,-)) Gerty is extendable in any way you want it :) You can basically add a new post-processing Perl code that would do the magic required by your specific needs. Also there are tons of SVN repository tools which do this too. > - toolset to access / massupdate devices Gerty in itself is actually designed to be such a tool :-) > - configuration with wildcard syntax (we use "vpn-*" as hostname with > separate > >login for CPE's than core devices - different policies must be configurable >-> >see .cloginrc ) you assign different device classes to your devices, and it's up to you how you do this. Usually you would have some inventory database with hardware types, so generating the input for Gerty would be straightforward. > - must support more than one vendor - and be flexible (we hacked in > something >for Quagga, some differt cisco policies, etc.) are you kidding? I wouldn't even dare to post at SwiNOG if I did something for Cisco only :-) > - should exist as a FreeBSD Port *smile* I leave it to volunteers :) cheers, stan _______________________________________________ swinog mailing list [email protected] http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
