Adventures with Rails: Part Un

I have taken on my next project at work of creating a web management interface for the L****** portal since none was provided. Almost all of the maintenance tasks that need to occur on a daily basis start with an SSH connection to the server the portal runs on. This is an issue for us (any probably everyone else) as granting a shell account to non-essential personnel on a production machine is a big no-no.

Financial Aid employees will be able to upload images, quickly search and replace content in their channels, send Targeted Announcements through a simple wizard (one that will even create the population selection in Banner and automatically transfer and import it into L******.

The help desk will be able to view user account information, check if accounts are disabled, override passwords temporarily, etc.

Our department will be able to do everything including the kitchen sink. The end goal is to never SSH into the production machine again – instead relying on this website for all common maintenance tasks.

To deliver this promised functionality, I have decided to go with Ruby on Rails for several reasons. Below, is my initial mock up of the website, with some of the areas already fleshed out somewhat:

This design is the same design I used on the Testing Center’s online registration. I really like the workflow, grouping all functions in categories, and displaying a “Dashboard” to the user.

Thanks to Rail’s MVC architecture, making a navigational bread crumb was painless. Because of its symantic URIs, I can parse the controller and action names, and build links accordingly. This is a huge advantage in implementation over ASP.NET’s offering (requiring an explicit XML file)

Authentication is done, thanks to ‘net/ldap’. I considered using Aurora for user management, but implementing LDAP was just too simple without it. Permissions will be delegated in a slightly different manner anyways, with each module in the website having its own access per user.

I have made a proof-of-concept with “List Users” taking advantage of the L****** commands to spit out needed information. Much of the statistics that will be gathered via this website will be performed by parsing through terminal output. It works reliably enough to consider a successful test, but there is much room for improvement.

Next on the list of things to do will be speeding up the SSH commands’ responses. I would like to cache repeated output, and also reuse the SSH session’s channel instance globally (instead of creating/destroying each new instance).

I would also like to detach the SSH response from the page loading. Currently if the SSH command takes 15 seconds to return data (which is typical), the website “loads” the page for 15 seconds before completing. Perhaps an asynchronous population of table data is in order?

I was surprised at how fast the prototyping in Rails has gone. It has only been a few days and I feel like I have really made some in roads.

More updates to come.