What a Macro Looks Like

I've been meaning to write this blog post for a very long time. I know I haven't updated in a while, there were some things outside of RCOS that happened, and as a result I was forced to move a date for a Cisco Certification exam up about nine days. So I needed to put everything else aside to study for this newly pushed up exam, which I am also pleased to report that I passed.

So I am still hard at work on the Internetwork Management Program. Recently, I have been working toward adding features to macro commonly used connections. What this will look like, is basically the program will create a file to store user entered data in the form of "deviceId address:port". These files will be stored with some unique tagging in the working directory of the project (or perhaps some other user specified location). Upon program start, it will identify these files to be displayed in the File menu, by name or some other convention.

The data in the file is then sucked into a hash (key, value mapping) in the form of deviceId => address (with an optional port number tagged on to the address. The colon in the original file is parsed out with some cool regular expression action). The deviceId is a human-defined name which is displayed in the tab. Then, it runs the same connect script to generate tabs and connect to devices.

Depending on your version of Perl, you may see an error like 'useless use of array element in void context' when running the r38 of the program. This is in a function which currently has no way to be executed from the program, and thus can safely be ignored. When this function actually gets integrated into the program the warning will be fixed.

Long Time, No Update!

It's been a while since I've had time to write in the blog. I spent the past 10 days studying intensely for my Cisco Certified Network Associate-Security exam. Normally, I would not spend such a large amount of time preparing, however, these exams from Cisco cost $250 each time to take, so it is not something to be undertaken lightly. I am pleased to write, however, that I took the exam this past Wednesday and passed with a perfect score of 1000/1000!! I look forward to having my life back, including more time to work on INMP.

So here's what's in the works. I gave my second presentation to RCOS on last Friday. The presentation went well, I had a lot to talk about and ran a little short on time, and thus was not able to demonstrate all the features I wanted. Still, I feel the talk went well and I am really pleased with how the project is turning out so far.

In my last update, I wrote about a way I had thought to improve the save functionality. Right now, the function writes each line of the running-configuration to a file one line at a time, looking for an 'interface' line to add the 'no shutdown' command after. Perl's operations on text file are very fast, so this is not a limiting factor, especially for the small-scale networks built in RPI's network classes. I thought I could gain some speed by writing the entire running-configuration to a file and then adding the 'no shutdown' line afterward. It turns out, this is actually somewhat complicated to do, so I am going to push this goal aside for now, as I don't want to be spinning my wheels trying to accomplish one small task.

After my presentation on Friday, I received an awesome suggestion from fellow RCOS member Joe Dougherty. It boils down to, what if the tabs for each connection knew what device they were connected too, and a timed-out connection could be restarted merely striking a single key? I have started to include functionality so that the tabs keep track of what device they are connected too, again however, as awesome as this idea is, I don't want to let it distract me from my primary goal in the remaining part of the semester, which is adding macros for commonly used devices so as to make the software more useful outside of RPI. I am going to work on both of these goals concurrently, and in a best-case scenario, have them both done for the end of the semester.

Fix last week's bug

Unfortunately, I am a bit behind this week. However, with some help from fellow RCOS member Joe Dougherty, I have fixed the 'no shut' bug I wrote about last week. Using his idea, I also have some thoughts about how I can re-write that function of the program to hopefully provide an overall boost in speed.

Hopefully will get back on track this weekend/next week and have more substantial stuff to write about.

Oh, no, another bug!!

More on that later. I like chronological blog entries.

First off, fellow RCOS member Tim Horton was kind enough to point out some errors in the licensing for INMP, and was kind enough to point me in the right direction of fixing them. The code is now properly licensed under GPLv2. Thanks, Tim!

Secondly, fellow RCOS member David Doria was kind enough to point out some problems in documentation of software. I updated the documentation for newest version of the software and also wrote a small Perl script which tests the user's machine to ensure it is properly set up to run INMP. The script detects missing modules and explains how to install them, then instructs how to start the software. Thanks for pointing out this documentation issue, David!

David's e-mail about this really got me thinking. I really want to package the software into a .deb/.rpm package to make installation simple. I'd also like some type of automated installation for any missing Perl modules on the user's system. Since I've never done anything like this before, this week was a lot of research as opposed to code development.

However, the bug in the title must now take the priority. There is a pretty big problem with the functions to propagate 'no shut' command to the proper interfaces. In hindsight, I should have realized this would happen when I wrote the original script for that, and am a bit embarrassed to admit I am only discovering it now. Nevertheless, I have a few ideas about how to fix it, and will likely post another entry in the next few days detailing my success or lack thereof.

That's it for now.

Live Testing!

So I am happy to report that the software survived it's first 'real-world' test, as I used it for my classwork on Thursday. I also thought of some more features to add to aid in it's use, particularly I will look at the ability to dismiss a specific tab to reduce clutter in labs which don't need all 11 devices. Also will make the tabs expand to fill the entire width of the client, because right now they are only 2-4 characters long, and when switching across multiple devices quickly this becomes a problem.

In other news, I would like to thank Tim Horton, both for the youtube upload of last week presentation which may found here and for helping me with some licensing issues in the code.

"I need 15 more minutes." "What? You've had 11 hours and you need 15 more minutes?"

That was the scene at about 6:45 this morning, when everyone was getting ready to show off their work at Hackathon. I needed 15 more minutes to fix a bug I was working on.

So yes, I survived the 12 hour Hackathon event!! The updates to the repository are here. The work from Hackathon starts at r24 and continues all the way to r31!!! I committed often during the event so I would have a log of all the stuff I did to write about it here. So here's how it went, in order:

1) I started small to get my mood set. Deleted some old code that was no longer necessary, and added title bars to all the windows that say something meaningful.

2) Added scrollbars to the telnet windows. You can now scroll up and down to the history command I/O. Not sure how deep it goes, but it's pretty deep.

3) Added what I call the semi-dynamic sizing feature. Tk widgets don't always take kindly to being resized, such as when a user hits the maximized button. The best I can do is allow for user to input desired height and width, in characters, of the telnet windows when creating them.

4) Added a function to disconnect from devices. Because the save and restore scripts contain automated code to connect, do their thing, and disconnect, there can not be any active connections to the devices during that time.

5) Key bindings! I talked about this to the RCOS last Friday. Anytime now there is an 'OK' dialog box, you don't need to physically click the button. (You still can, though!!) Hitting the 'Enter' key on your keyboard accomplishes the same task.

6) Save the best for last. This feature is the breakthrough that sets INMP apart from any other software out there. Without a doubt, the most annoying thing about working with Cisco routers, especially here at RPI, is that router interfaces are shutdown by default. Especially here in the lab, after erasing a previous configuration and loading in your own, you need to physically type 'no shut' at each interface. Well, not any more. When saving configurations through the INMP, it automatically inserts a 'no shut' command into the saved file exactly where it's supposed to be. I.e, only to the interfaces that actually need to have 'no shut' issued to them.

So the software is now at the point where I do not have a problem telling people 'Go download this software and check it out.' I know between Friday and today, a couple people have expressed interest in using it. I will be doing full live testing of it this week in my laboratory work on Tuesday and Thursday, and I hope other Linux users in the Networking classes do so as well.

So overall, I would say the Hackathon was a huge success. Nice too to see that there was a very strong RCOS presence. I know I certainly made tremendous progress and hope the other students did as well. The host, Mike, hinted there may be another one before the end of the semester, I hope it becomes a reality.

Fix Bugs, Get to Top of Observatory.

But seriously. The two bugs I blogged about on Thursday are mostly fixed. The issue with the same telnet session eating up multiple tabs is completely fixed, and the the program also now exits correctly when choosing File->Exit from the menu, but still doesn't when clicking the x-button.

Look for more detailed blog update after Hackathon tonight.

Progress!

I am happy to report that I have made significant progress on the client. There are still a couple of bugs that I am working on, but I expect that they will be worked out very shortly. So for now, the client will connect to devices, and I have also added the core functionality from my backend scripts, including save, restoring, and initializing. The client is a little bit ugly right now, but fixes will come after I get the functionality bugs worked out.

The primary bug I am fixing is that the client does not always exit properly; that is to say, even though the window is closed, the client still seems to be running in the background. I am going to work a way to ensure that clicking that 'x' button on the client sends the proper exit signals to the program.

The second major bug is sometimes the client gets stuck sending the different telnet sessions to the tabs, and sometimes sends the same session to some multiple tabs. With some pointers from some guys in a Perl chatroom, the faulty lines of code have been identified, and I am working on a fix.

The hackathon is this Saturday, which is basically a 12 hour codefest. I will be working on this project the entire time, with the primary goal of fixing the above two mentioned bugs. After, I will work towards improving the looks of the client. I am hoping to make significant progress at that event, and will blog after, or perhaps during it.

I will also be giving my first presentation to the RCOS on this Friday, March 4th. The slides which I present will appear in my repository after my talk.

Research, Research, Research!

Unfortunately, not much in the way of source code development in the last week. When I decided to switch to Glade to design the UI, that naturally required a lot of reading to bring me up to speed. Unfortunately, Glade is not well documented, and the documentation for using it with Perl is even worse. So, after some time of reading some sporadic, and often ancient, blog posts from geeks around the world, I decided to switch to something more uniform.

Joe Dougherty, a fellow RCOS member, spends a lot of time hyping Qt. As it turns out, with good reason. It's kind of a lot like Glade, with a drag and drop widget style interface, except all the documentation is one place, and it's actually good. So I'm going to play around with it and see what it produces.

Of course, Qt is an interface for C++ programs. So, the obvious question is, how does this affect (effect?) the work I've done in Perl already? Well, the answer to that question is, it doesn't, really. The Perl scripts interface directly with the Cisco routers to run their function and then terminate. So the Qt application will handle the user interaction events, and if the user wishes to execute one of Perl scripts, (for example, to save configurations) this can be called by going to File->Save, for example. The cool thing is that since Perl itself is basically one big C program, it is easy to call a Perl function from C. If Qt does prove to work out, I may invest some time in porting the Perl functions to C++. But that's a ways in the future at this point.

So I'm a little bit behind already (ugh!) but I'm looking forward to taking the long weekend to work on this and get back on to my schedule.

Also, I have improved the speed of the restore function (which loads configurations from a text file into the 11 devices) to the point where it is actually faster than a human manually performing the same task. Booyah!!

Glade!

I've discovered this thing called Glade. It's a Unix tool to speedily create GUI applications in the Gtk environment. This is a bit of a departure from previous versions of what I was doing, trying to use Perl's built-in GUI functionality to work my program. Glade, using Gtk, offers several advantages over the built-in Perl stuff:

1) Speedy, drag-and-drop interface. It's easy to create a widget-based GUI simply from dragging and dropping widgets on to the canvas. Whereas the built in Perl GUI module requires writing all the design code by hand (<-That is hellish, I've needed to do it in class and it does not look pretty), this alternative is actually much faster and I do not need to get hung up on little things like changing numbers in a multi-hundred line code file to make things look good.

2) One less thing to install. The Perl/Tk library is an extension to Perl which does not come installed with Perl by default, most of the time. Gtk, of course, is essential to Linux running the GNOME desktop, and is also easy to add to XFCE and KDE based distributions as well. So this will insure a greater degree of cross-distribution compatibility.

3) It looks better. Perl/Tk is a pain to get to look good, however, I was always of the opinion that if an application is functional, then looks should be secondary. But, as long as there is an option that looks better while retaining all the same functionality, I might as well go for it.

So of course, Glade does not write any actual code, it is just a design tool. So it is basically a front-end GUI which will be manipulated in the background by Perl scripts. The Gtk-widget based GUI's are similar to the ones built by native Perl applications, so this is all pretty familiar to me, I just need to read the documentation on the Gtk Perl modules so I know what functions do what. So it's a little bit of backtracking in development, but it's a new semester and I have new resolve to get this working.

So, to that end, I am setting a hard and fast goal to have the GUI working completely with Telnet operations within one week. Then I can focus on adding other bells and whistles that will really set apart the INMP from other programs.