Re: [swinog] RANCID alternative
Hey Stan Great idea. One feature I've been missing in rancid for a long time is the possibility to have a one-stop-shop for emergency recovery. While the configuration is saved to CVS, the IOS and other important files such as vlan.dat are missing. It would be great, if this new tool would include a backup-function for the file-system on the router/switch, so that it can be fully restored after an emergency (including all important files). Kind regards, Viktor On 11.10.2010 8:34, Stanislav Sinyagin wrote: hi all, I'm currently working on a new open-source project. Many of you know the imperfections of RANCID software, and this project is made to dramatically change this. In README section at http://github.com/ssinyagin/gerty you will find the short concept overview and more in-depth documentation. At the moment the proof of concept is ready: it can store Cisco configuration into files, as well as output of other commands, such as show isis neighbors. It will be polished and finalized during next months, and I'll be able to present it at a SwiNOG meeting in Spring or Summer. your feedback will be appreciated. cheers, stan ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RANCID alternative
hi Viktor, I'm not sure if this feature would be available out-of-the-box in the first release, but there will be a Perl API for you to automate any interactive CLI scenario and report the result (success or error message). so, basically you will be able to automate commands like copy vlan.dat tftp://1.1.1.1; and track the failures. cheers, stan - Original Message From: Viktor Steinmann st...@stony.com To: swinog@lists.swinog.ch Sent: Sun, October 17, 2010 11:57:19 AM Subject: Re: [swinog] RANCID alternative Hey Stan Great idea. One feature I've been missing in rancid for a long time is the possibility to have a one-stop-shop for emergency recovery. While the configuration is saved to CVS, the IOS and other important files such as vlan.dat are missing. It would be great, if this new tool would include a backup-function for the file-system on the router/switch, so that it can be fully restored after an emergency (including all important files). Kind regards, Viktor On 11.10.2010 8:34, Stanislav Sinyagin wrote: hi all, I'm currently working on a new open-source project. Many of you know the imperfections of RANCID software, and this project is made to dramatically change this. In README section at http://github.com/ssinyagin/gerty you will find the short concept overview and more in-depth documentation. At the moment the proof of concept is ready: it can store Cisco configuration into files, as well as output of other commands, such as show isis neighbors. It will be polished and finalized during next months, and I'll be able to present it at a SwiNOG meeting in Spring or Summer. your feedback will be appreciated. cheers, stan ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RANCID alternative
Hi, Stanislav, everyone -- On 11 Oct 2010, at 19:34, Stanislav Sinyagin ssinya...@yahoo.com wrote: I'm currently working on a new open-source project. Many of you know the imperfections of RANCID software, and this project is made to dramatically change this. This is great news, we use rancid all of the time, and find that adding functionality and bespoke behaviour is quite hard work, further when we deviate our custom changes to the scripts it makes it harder to track mainline rancid releases. I love your idea to make the custom behaviour work as pure configuration and via a plugin architecture. Please do preserve the best features of rancid, the main is that configuration is backed up into a version control system, so inspecting former config dating back months or years is possible. Using svn rather than cvs would be nice so that we can run it alongside our codebase. A choice of version control back ends would make a lot of people happy I think. :-) Also, make sure there is an option to 'blank out' passwords in the stored configuration. Some way to import the former rancid cvs database might be a neat feature, but we can probably survive without this by running rancid in parallel with your software for six months or a year. It's really important that a community grows around this software, so that we can both contribute and download plugins for many vendors and config dialects. I'd be delighted to volunteer mailing list hosting. I also would really like to follow development in an rss format so that I can tune our noc guys in and we can start to help with testing and building the community when the features we really need are in the software. Congratulations on getting this far, good luck, and ask for help before you need it :-) Andy ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RANCID alternative
I read some of your wiki/files to see the project and it looks promising to me. I fully support andy's statement ,-) 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. 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?). Sometimes we update ~4k CPE's with clogin and parsing / checking the output can be painful ,-) But to come back to needed features for at least me to replace rancid: - CVS storage of configs (-- cvsweb.cgi to see / compare them) - threaded / parallel collection -- must be speedy ,) (we have ~5-6k devices in rancid; working fine today) - 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 ,-)) - toolset to access / massupdate devices - 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 ) - must support more than one vendor - and be flexible (we hacked in something for Quagga, some differt cisco policies, etc.) - should exist as a FreeBSD Port *smile* if you need any help in modules (especially cisco modules) let me know. -steven -Original Message- From: swinog-boun...@lists.swinog.ch [mailto:swinog-boun...@lists.swinog.ch] On Behalf Of Andy Davidson Sent: Tuesday, October 12, 2010 12:02 PM To: Stanislav Sinyagin Cc: swinog@lists.swinog.ch Subject: Re: [swinog] RANCID alternative Hi, Stanislav, everyone -- On 11 Oct 2010, at 19:34, Stanislav Sinyagin ssinya...@yahoo.com wrote: I'm currently working on a new open-source project. Many of you know the imperfections of RANCID software, and this project is made to dramatically change this. This is great news, we use rancid all of the time, and find that adding functionality and bespoke behaviour is quite hard work, further when we deviate our custom changes to the scripts it makes it harder to track mainline rancid releases. I love your idea to make the custom behaviour work as pure configuration and via a plugin architecture. Please do preserve the best features of rancid, the main is that configuration is backed up into a version control system, so inspecting former config dating back months or years is possible. Using svn rather than cvs would be nice so that we can run it alongside our codebase. A choice of version control back ends would make a lot of people happy I think. :-) Also, make sure there is an option to 'blank out' passwords in the stored configuration. Some way to import the former rancid cvs database might be a neat feature, but we can probably survive without this by running rancid in parallel with your software for six months or a year. It's really important that a community grows around this software, so that we can both contribute and download plugins for many vendors and config dialects. I'd be delighted to volunteer mailing list hosting. I also would really like to follow development in an rss format so that I can tune our noc guys in and we can start to help with testing and building the community when the features we really need are in the software. Congratulations on getting this far, good luck, and ask for help before you need it :-) Andy ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RANCID alternative
hi Andy and all, - Original Message From: Andy Davidson a...@nosignal.org On 11 Oct 2010, at 19:34, Stanislav Sinyagin ssinya...@yahoo.com wrote: I'm currently working on a new open-source project. Many of you know the imperfections of RANCID software, and this project is made to dramatically change this. Please do preserve the best features of rancid, the main is that configuration is backed up into a version control system, so inspecting former config dating back months or years is possible. Using svn rather than cvs would be nice so that we can run it alongside our codebase. A choice of version control back ends would make a lot of people happy I think. :-) Also, make sure there is an option to 'blank out' passwords in the stored configuration. There's already a way to filter out lines of configuration,based on regular expressions. I will also add a possibility to do search-and-replace, so that passwords would be blanked out (starred out?). In regards to SVN, I don't see any problems already: in your cron job, just do: svn add * svn commit -m `date` I don't foresee much need to add some special SVN handling to Gerty, but that may change :) Some way to import the former rancid cvs database might be a neat feature, but we can probably survive without this by running rancid in parallel with your software for six months or a year. the main sponsor for this project does not have RANCID at all, so I'm afraid it's a low priority task. The main purpose is to run some telnet automation, and I came up with a proposal for a generic framework which would eventually replace RANCID. It's really important that a community grows around this software, so that we can both contribute and download plugins for many vendors and config dialects. I'd be delighted to volunteer mailing list hosting. I also would really like to follow development in an rss format so that I can tune our noc guys in and we can start to help with testing and building the community when the features we really need are in the software. Re. mailing list - probably I'll set it up at Google Groups, as soon as there is enough material to share. RSS feed is already available: http://github.com/ssinyagin/gerty/commits/master Actually the cool thing about Git and Github.com is the new way of collaboration: you can clone the main project at any time, add your changes, and invite the project owner to merge the changes back into the mainline. The only drawback, one has to forget his SVN experience and read a book: http://progit.org/ Without a book, it's really uneasy to start understanding how Git works. Congratulations on getting this far, good luck, and ask for help before you need it :-) thanks, so far I'm good. It's a financed project, so I can dedicate my most productive daytime to it. cheers, stan ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RANCID alternative
hi again :) From: steven.glog...@swisscom.com steven.glog...@swisscom.com 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 swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
