INMP is moving in to the 21st century!! We now have a GUI client. Right now, it doesn't yet interact with software. To that end, please continue to use REVISION 10 of the software.
The graphical client is built in Perl, like the rest of the project, and uses the Perl/Tk module. This is an extension to Perl and is not tied to the desktop software, so I can hopefully ensure universal compatibility among all UNIX-based OS. The client further uses an extension to Tk known as NoteBook; this is what allows the ad hoc generation of the tabs. Each tab will be the telnet or SSH session to a Cisco device.
At some point in the future, the client will also feature a menu with configurable options. For instance, if the passwords to all devices you connect to are the same, you will be able to set this and have the password sent to all devices. It will also likely support some type of macro where you can save connections that you use often; so you can just hit one button and instantly connect to these devices. Furthermore, it will interact fully with the scripts to save and load configurations, so that this not longer needs to be done by entering text at a terminal.
I'm sure I've missed some of the features; basically, stay tune for further updates as the heart of this program begins to take shape!!
Friday, October 29, 2010
Monday, October 18, 2010
RCOS Presentation!
I gave my first presentation to the RCOS on Friday. It went well, lots of tough and interesting questions from crowd, as well as a host of awesome suggestions. The slides will appear at http://code.google.com/p/inmp/ shortly.
This week, I have plans to begin work on the GUI interface. I have decided to simply use Perl's built-in Tk interface for maximum compatibility-this way it can run on other desktops like KDE without pulling in a ton of dependencies.
That's about it for now. I should be back to more regular updates this week now that midterms are over.
This week, I have plans to begin work on the GUI interface. I have decided to simply use Perl's built-in Tk interface for maximum compatibility-this way it can run on other desktops like KDE without pulling in a ton of dependencies.
That's about it for now. I should be back to more regular updates this week now that midterms are over.
Friday, October 8, 2010
Ah, a Breakthrough!
I have spent much of this past week working on the restore script, which purpose is to grab configurations from a text file and load them into the routers and switches, to save much time versus doing the process manually. The good news is that the script works for the most part. Sometimes however, a command entered on a router or switch will output a message which is preceded by a %. These messages are good and are usually informative as well. Unfortunately, when running an automated script to load configuration files into a device, these message cause the program to terminate. Fortunately, the exact, specific nature of the problem (termination on any message beginning a %) makes it easy to fix. I am exploring a couple different solutions at the time of this writing, and will pick the best one.
I'll write very briefly, too, about another issue I encountered, and solved, during the week, as it was interesting to me. The interface I am using to send commands to the remote devices waits for a prompt to ensure that it is safe to send the command. The prompt may look something like this, at it's most basic level:
Router#
or, perhaps,
Switch#
This is a most basic prompt encountered when configuring devices. As increasingly complicated levels of configuration ensue, one may see increasingly complicated prompts. For example, a prompt when configuring an interface on a certain device may look like:
Router(config-if)#
This is also a basic prompt which was matched and considered safe to send commands too. In general, the interface accounted for any prompt with (config) in it. Some prompts, however, do not have this (config) and thus were not considered a matching prompt. The fix for this, was to simply alter the regular expression matching a prompt from 'config.*' (matching config followed by any text) to simply .* to match on any text that may appear there.
I'll write very briefly, too, about another issue I encountered, and solved, during the week, as it was interesting to me. The interface I am using to send commands to the remote devices waits for a prompt to ensure that it is safe to send the command. The prompt may look something like this, at it's most basic level:
Router#
or, perhaps,
Switch#
This is a most basic prompt encountered when configuring devices. As increasingly complicated levels of configuration ensue, one may see increasingly complicated prompts. For example, a prompt when configuring an interface on a certain device may look like:
Router(config-if)#
This is also a basic prompt which was matched and considered safe to send commands too. In general, the interface accounted for any prompt with (config) in it. Some prompts, however, do not have this (config) and thus were not considered a matching prompt. The fix for this, was to simply alter the regular expression matching a prompt from 'config.*' (matching config followed by any text) to simply .* to match on any text that may appear there.
Friday, October 1, 2010
A closer look at INMP
My last blog entry was set up a little bit hastily, so here is a more detailed look at INMP:
Managers of internetworks are often required to work with several devices at once-naturally, having several SSH windows open at once is not practical and contribute to screen clutter. Unfortunately, for users of Linux-based OS, there is no suitable program which can perform these functions. The built in terminal programs such as Gnome Terminal do not allow it to spawn a tab from within itself-thus making it impossible to automate the tab generation process.
Rather than needing to rely on some third-party software, to a bunch of scripts from another third party, the ideal solution is to have one program to manage the entire process-this is the goal of the INMP.
Currently, the program is a series of Perl scripts which are executed from the RoxTerm terminal program. Currently, the scripts are set up to work on the Cisco networking pods at RPI. As the software continues to grow, however, it will be a simple fix to allow it to connect to any router or switch. Currently existing scripts connect to the devices, run some initialization commands, and dump the running-configuration of all devices into a text file. There is also a script to restore data from the text file to the devices, though this is currently buggy. (i.e, it does not work.)
Getting these scripts working completely and bug free is the initial goal, as they will form the background of the final application. The final application will feature a Perl-built GUI featuring tabbed windows so that one can manage multiple devices at once. The program will support both Telnet and SSH connections, though in a real, corporate environment, Telnet should never be used.
Subscribe to:
Posts (Atom)