How the Community Lab Works

The following information isn't needed to use the lab; rather, it has been provided for the curious and anyone interested in replicating the community lab's setup for their own purposes.

Lab System Components

The lab can be described as an agglomeration of distinct, interdependent building blocks. Briefly, these are:

Lab devices

The devices accessed by end users

Support devices

Devices which have been deployed to support the lab topology or access to the lab, but are not intended for public access (for example, the frame relay switch)

Console server

Serves as the lab's "brain," providing remote IP access to the physical serial consoles of lab gear

Scheduling application

The portion of packetlife.net where users schedule lab reservations

Scheduling database

Maintains start and end times, device block allocations, and authentication information for all user reservations past, present, and future

RADIUS Daemon

Queried by the console server; authenticates users against the authentication database

Authentication database

Contains the authentication credentials only for active reservations; consists of tables independent from the scheduling database

cron task

An automated process set to run hourly responsible for synchronizing the authentication database with the scheduling database.

Lab Devices

Lab devices are interconnected to one another in a generic topology but kept necessarily isolated from the "real" world for security and safety reasons. The physical console of each lab device is connected to a designated port on the console server.

Console Server

The lab uses an Opengear CM4116 console server (graciously sponsored by Opengear) to provide remote terminal access over IP to the physical consoles of lab equipment.

Scheduling Application

A user must reserve lab devices before he can use them. A reservation is essentially a [user, time, devices] tuple, dictating who can access what lab equipment at what time.

The lab uses a custom web application for scheduling, written on Django and tightly integrated with the rest of the site. Because of its niche, non-portable nature, the source code for the application is not made available. However, its functionality is trivial to replicate with any of many generic scheduling applications.

It's important to note that each reservation has a unique set of credentials associated with it (the "user" component of the tuple). These are the credentials issued to the reservation's owner at the time of its creation and are used to access lab devices while the reservation is active.

RADIUS Daemon

Upon connecting to the console server, a lab user is prompted for a username and password (these are the credentials associated with his reservation). The console server then forwards these credentials to the RADIUS server, which checks them against the authentication database. If there is a match, the user is permitted access to the appropriate device's console.

MySQL Database

Both the scheduling and RADIUS information exist within a shared MySQL database. This isn't necessary, but is done out of convenience (entries in the RADIUS tables can be directly managed as objects in the scheduling app).

cron Task

A cron task is run hourly to synchronize the authentication database with the scheduling database. This includes:

• Deleting any credentials from expired reservations
• Copying the authentication credentials for any active reservations from the scheduling database

This script also sends a command to the console server, instructing it to kick off any users still logged on from an expired reservation. This is accomplished by remote SSH execution of a custom script installed on the console server.

Putting it all Together

Step 1: A user submits a reservation through the form on the lab schedule app.

Step 2: An entry is created in the scheduling database with the necessary information:

• Start time
• Duration
• Device blocks
• Random password

Step 3: When the reservation's start time is reached, the cron task copies the username(s) and password associated with the reservation from the scheduling database to the authentication database.

Step 4: The user connects to the console server via Telnet or SSH on the appropriate TCP port and provides the appropriate username and password for that device.

Step 5: The console server forwards the credentials provided by the user to the RADIUS server. They are checked against the authentication database and a subsequent success or reject response is sent to the console server.

Step 6: Assuming successful authentication, the user is permitted access to the console server. The Telnet/SSH session is bridged directly to the serial port of the associated lab device.

Step 7: When the reservation's end time is reached, the cron task deletes the reservation's now-expired credentials from the authentication database. It also issues a command via SSH to the console server, telling it to disconnect any Telnet/SSH sessions from that reservation which are still open.