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.

End-of-Semester update

So wow. It's been a while since I've had time to write in the blog. Between classes, exams, and presentations, it seems like I don't have time to do anything anymore.

To start off, I believe I may have been barking up the wrong tree when I talked about sockets-I was considering using them in the same manner a tabbed web browser does to ensure that data is sent to the correct tab. The socket binds locally to an insignificant, unique port, so traffic requested from that socket is then redirected back to it. However it seems that NoteBook (The Perl module to create tabs) may have it's own method of managing and delivering content to the correct window. The documentation and examples for this module are sporadic at best, I have needed to reference multiple sources to assemble an (almost) complete version of the documentation. The program can detect when a certain tab is active, if each tab has a unique identifier, it should be simple to block traffic to all tabs except the active one.

I haven't pushed any code in a while-this is because I am not a fan of putting experimental code on the public repository, though I have done it in the past. Once I complete my testing and determine the best method for handling the traffic to and from the remote device, I will push the code update which contains this option.

I am currently shooting for a mid-January release date for version 1 of the project. This will be a version of the client that is specifically tailored to work with RPI's Cisco routers, with the hope that the client will be in a state of readiness to be distributed to the incoming class of Network Engineering students in the Spring. To make this deadline, it is likely that most of the connection information will be hardcoded, (as it is already for my testing purposes) so a user will only need to enter the pod number for their devices, and the program will open all the relevant connections.

Once the initial release is complete and functional, I plan to expand the program, adding the ability to customize connection information to make the program more universal. I would also like to expand it's use to include SSH connections, as telnet is not often used outside of secured academic environments.

I'm hoping to complete my code testing sometime in the next 48-72 hours and should have a major update to the repository by the end of the weekend.