Announcing Labkeeper

It's been nearly a year since I had to take the community lab offline to relocate my home, and I still get frequent emails asking when it will be returned. Sadly, my plan to host it with my current employer didn't pan out, and I'm still searching for a suitable host in the Raleigh-Durham, North Carolina area. (If you might be able to give the lab a good physical home, please let me know!)

I also get a lot of emails asking if I can share the scheduling application I used to make the lab available. In short, no, I can't. Not because I don't want to or because it's secret, but simply because that code was written specifically for the packetlife.net site and is not in the least bit portable. But these requests got me thinking: A lot of people obviously would like to be able to share their labs, they just need a platform. Maybe I could rewrite and improve upon the scheduling application to spin it off as its own service.

If you follow me on Twitter, you may have caught one or two references to a new project recently. Indeed, this is exactly what I've been working on for the past couple months during my precious free time: A centralized authentication and scheduling service people can use to make their own training labs available to friends, coworkers, or the general public. I call it Labkeeper.

How it Works

Many of us networkers and other IT folk have a collection of hardware we use for training purposes. The community lab was a great example: Half a rack worth of routers, switches, firewalls, and other gear suitable for replicating a number of topologies for both real-world and academic purposes. Most lab owners use a console server to consolidate console access to their lab devices and to facilitate remote connectivity to physical consoles. As labs typically spend most of their time sitting idle, it can be beneficial to share a lab among friends or coworkers. But scheduling lab time can be a hassle, especially when trying to coordinate access among a large number of people.

Labkeeper aims to solve this problem by coupling lab scheduling with lab authentication. When a user reserves a block of available time on a lab's schedule, he or she is issued a set of credentials which are valid only during that specific window of time, and only for that specific lab (or a set of specific devices within that lab). When the reservation begins, the user connects to the lab's console server via Telnet or SSH and enters the provided credentials. The console server authenticates the user against a custom RADIUS daemon running at the Labkeeper.net and, if successful, grants the user access to the requested lab device.

This isn't too different from how the community lab scheduling system worked, however I've moved from FreeRADIUS to a custom RADIUS daemon which allows for much more robust operation. For example, Labkeeper can identify console servers not only by IP address but also by a domain name provided by the user during login. People who don't have a static public IP at home and rely on a dynamic DNS service like No-IP can log in as username@myhomelab.no-ip.biz to force authentication against the lab associated with that domain. The custom RADIUS daemon also allows for very granular control over reservation and console port validation.

A lab comprises at least one console server and typically several lab devices, which can be arranged into up to four logical pods. It is possible to reserve one pod while a friend reserves another to collaborate on lab configurations. Console servers, pods, and devices are all created by a lab owner via Labkeeper's web interface. Ports may be created on console servers and have lab devices attached to them. This results a virtual construction of a lab's physical console connections.

Lab owners can upload photos and topology drawings of their labs and configure reservation time limits, opening and closing hours, profile details, and other attributes. A lab can be open to the public or reserved for members by invitation only.

Next Steps

Labkeeper is at the point now where it needs a handful of skilled, passionate, and above all patient beta testers. I expect a fair amount of interest in the project, so allow me to spell out the requirements for those wish to help out.

To apply as a beta tester, you must have the following:

• A console server which supports RADIUS authentication (example: a Cisco router w/async WIC, an Opengear box, etc.)
• Prior experience configuring and using the console server
• An Internet connection over which the console server can be reached remotely via Telnet/SSH
• At least one lab device connected to the console server (more is better but not required)
• A few spare hours here and there to help test and troubleshoot at your leisure
• Patience

If you're interested in becoming a beta tester AND you meet the above requirements, please shoot me a quick email with the following info:

• Desired username
• The console server(s) and gear in your lab

In a vain attempt to mitigate chaos, I'll be adding beta testers slowly to the site over the next few weeks as bugs and usability issues are addressed. My thanks to all those who apply. I'm very excited at the level of interest Labkeeper has seen so far and hope to open the site for general registration before the end of the year.