Generating configuration files is quite simple, but how to ensure that the result of a configuration template is useful?
Today, I released the next version of the Product Database. There are two primary new features: the product replacement options and the new Product Check. The previous Bulk EoL check was removed and replaced by the Product Check. These product replacement options (or product migrations) are created based on the data provided by the Cisco EoX API or using an Excel upload.
This post is the last one within a series that I’ve created primarily at the beginning of 2016. The topic was on How to build your own Network Config Generator. The last post within the series was some time ago and I like to finish it today with a short review of the process and my experience during the time.
Almost a year ago, I start a side project to create a web service that automates End-of-Life (EoL) checks. It targets primarily to equipment from Cisco Systems. My primary intention was to learn Django and some other web technologies. Furthermore, I liked to play with the Cisco API console (more specific the Cisco EoX API). I used the first version now for quite some time. Some months ago, I decided to extend this Project a little bit. The first step was a review of what I’ve done last year. I recognized fast that the code needs some updates...
This post is part of the series “How to build your own Network Configuration Generator”. You find the overview about the entire series here. The last state of the code is available at the Network Configuration Generator GitHub repository. This post discuss the first use case, where we provide the generated configurations “to the outside world”. I’ll like to show you today, how the Network Configuration Generator can be used on an “Appliance” to provide configurations using FTP and TFTP.