By stretch | Tuesday, September 3, 2013 at 12:23 a.m. UTC
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 firstname.lastname@example.org 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.
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
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.
Posted in Announcements
September 3, 2013 at 7:03 a.m. UTC
It's working well so far! :)
September 3, 2013 at 12:25 p.m. UTC
So it will be like a cloud platform for all the labs around the world?
Or would you share this platform as open source project on github or somewhere else?
It's written in python works with django framework?
Thanks a lot!
September 3, 2013 at 12:34 p.m. UTC
@johnny: Both, actually. The code is maintained in a public repository to hopefully encourage collaboration, but it's being developed as a centralized service rather than something an end user would install locally. Most people are more interested in running the lab itself than a scheduling system for it.
And yes, like Packet Life, Labkeeper is built on the Django Python framework.
September 3, 2013 at 1:14 p.m. UTC
Just found it on github and later saw your post... I'm going to learn some python, and help you to contribute and make the best lab environment!
September 3, 2013 at 10:39 p.m. UTC
I love this idea, and I'm strongly considering opening my equipment to this project. My biggest concern is if anything can be done about certain kinds of malicious behavior. A potential example is someone disabling STP on purpose and leaving it that way to eat up the CPU time on the equipment.
September 4, 2013 at 12:30 a.m. UTC
@WaxTrax!: Although Labkeeper can't do anything to control what a user does in the lab once authenticated, you do have the option of restricting your lab to members only. You can invite only people you trust to use the lab.
September 5, 2013 at 3:46 a.m. UTC
I'm curious how the autentication works. Anyone that goes to telnet://IP:PortNumber will be able to access my devices. Regardless of if they are on the schedule or not.
What needs to be configured on the remote end, aka my home lab?
September 5, 2013 at 3:44 p.m. UTC
Just a quick idea for a feature....
Once a reservation has expired, the an automated service would kick in and logs to each device under that reservation and either erase the hardware or loads a basic config for the next lab user to have.
A little in house clean up.... or maybe a rule for each user to "erase the config at the end of your lab time"
LabKeeper is a great idea.. Best of luck !!
BTW - have you considered monetizing the lab time ? (to help recover some basic operational cost such as the electrical bill/AC/Floor Space/etc)
September 8, 2013 at 8:51 p.m. UTC
Looking forward to this.
As far as monetizing, I'd rather give you my business than Bookeo, so definitely keep that on the table, even if only through donations, as I'd definitely be there.
Any time frame for letting selected beta peeps know ? I sent you the e-mail a few days ago and forgot to mention that my access servers do work with radius, and pretty much anything else under the sun.