Sunday, December 30, 2012

Pi Lab - Physical Layout of a Pod

In the previous two posts I outlined an idea for a relatively low cost hardware environment for teaching system administration to high-school and early college level students.  In the first post I created a parts list for the parts of the lab.  In the second I create a manifest for each student's gear and for a working unit I called a Pod

Providing a Grounding for Remote Access



In thinking about the PiLab and what I would like to be able to do with it, I realized that I had made a mistake right at the start. I was focused on emphasizing the remote access non-graphical (non visual) aspect of system administration. I was aware still that I needed some visualization elements to give the students a means to see the effects of what they were doing. I was thinking about creating a set of monitors that work at multiple levels and which could be seen to change as the students turn their idle disjoint computers into a network of interacting services

I started thinking about how I'd lay out the lessons to introduce the systems to the students and then let them play and I realized I'd missed an opportunity with my focus on avoiding physical access.

What I realized is that, if I design the layout of the pod, the placement of devices and cable routing then I can design a session in which the students assemble their pod and can watch the monitors as each component is correctly placed, cabled and powered up. Then when the students begin work over the network they will have a visual reference to the components and connections with which they are working.


This week I've been working to make the idea a bit more concrete.  In this post I'm presenting a physical layout for a single pod. The pods are the units of student control.  Each pod will support 4 students.  Each student gets her own Raspberry Pi.  The pod provides power control and access to the console of each Pi.  It also provides power control and console access to the uplink router for the pod.

Physical Layout


The diagram below shows one possible physical layout for a pod.


The lab include 5 Raspberry Pi's.  The fifth unit is the Head Node.  This node is powered on when the pod has power.  It is the end point for the consoles for the 4 student Pi units and for the lab router. The head node also controls power to second power strip which powers the USB hub and the first three Pi units.

The pod is designed to be build on a plywood backing board approximately 42x56cm (17x22in).  All of the hardware except the Pi units have mounting holes on the back.  The Pi units can be affixed with velcro straps tacked to the board.  Additional velcro straps can be tacked along the cable runs to dress the cables.

Power Control


The PowerUSB Basic units have four sockets, but one is always on.  These will power the head node (from the first power strip) and the USB hub (from the second).  Two of the PowerUSB sockets are controlled by mechanical relays and can provide 4A.  The second power strip is plugged into one of these.  The router and the remaining 4 Pi units are plugged into the switched sockets.

In this configuration, every component except the head node can be powered by the head node itself.  The head node exposes its network port and console serial line which can in turn be used to control the pod as a whole.

Student Assembly


The Pi lab is designed to allow the students to assemble and cable the pod from components and cables.  They will get a chance to handle the parts.  The cables should be cut to length where possible and labeled.  Where the cable lengths are fixed, the pod back board should provide a means to dress the cables with slack loops.

While one of the goals of the course is to show the students how to work remotely using the network and command line, the exercise of assembling the pod and (hopefully) observing as it comes to life for the first time will give the students a sense of the hardware that is on the other end of the network.

Next: The management infrastructure


The next job is to design the infrastructure layer.  The goal there is to provide the next level network and host installation services for the lab Pi units.  It would be possible to add USB storage to the PiLab head node but I think it's preferable to provide the OS and monitoring from outside.  The monitoring must include both passive and active probes for the nodes.  It must provide near real-time graphical feedback of the Pod state to the students.  Back to work!

Wednesday, December 26, 2012

PiLab - A network lab for teaching System Administrators.

I'm getting fired up about the idea of creating an inexpensive computer lab aimed at teaching System Administration.  The creation of the Raspberry Pi and the availability of some inexpensive but rootable home routing hardware and USB power control make it possible to design and implement an environment for students to learn and break things.

There have been interminable round-and-round discussions in the Sysadmin community formed by the USENIX LISA SIG and LOPSA over the last two decades and so far few have come to any lasting result. (The LOPSA Mentorship Program is one that's excellent and ongoing and I encourage you to look at it both as a guide and a learner).  I have no idea if this will be any more successful or enduring, but at least it's different. I'm willing to throw it against the wall and see if it sticks.

So I've created a Github project to collect and track ideas.  At first they'll be my ideas but I know I can't do this myself so I'd really love contributions of ideas and work.  I'll need sysadmins of all stripes as well as writers editors and educators to help.

With lots of hope and trepidation I'd like to introduce...


- Mark

References

Monday, December 24, 2012

A Modest Pi-Posal?

Cool Geek Toys for Education!

Ever since I heard about the Raspberry Pi project I've been trying to figure out how best to use them for their intended purpose: Teaching. 

I've always despised what our secondary schools typically call "Computer Education".  My daughters came home complaining about hours learning how to embed images in office documents.  For a whole term.  There are obvious exceptions, but in general it seems you need to have an inspired and empowered teacher who offers something outside class time to get much else.

I've also thought a bit about how system administration as a profession is (not) taught in higher education.  There have been the Certification Wars.  The Coders vs Non-coders and even the Anti-Degreers.  One thing that's occurred to me is that the elements I use daily in my work aren't really beyond the capabilities of someone with a reasonable grasp of Algebra and Logic.  At least superficially your typical motivated 9th grader could understand it.

Now I realize I'm a bit of an odd bird in the teaching area.  I'm a professional system administrator.  My first thought isn't about soldering or motors or cool screens.  It's not about building web sites with Rails or JBoss.  It's not about Android games or HTML5 Canvas and Javascript.  My first thought is "they should get a chance to run through the steam tunnels!"

I have taught some.  I worked at a community theater teaching children's theater on and off for 20 years.  I have two girls.  I know that the lure of a blinking cursor can't, by itself, compete with all of the audio and video opportunities out there on all scales.  The Big, the Flashy, and the Colorful all start with an advantage even when there's little content that's not obscured by the noise.  I know I have to draw students in somehow, but that way isn't available.  I'll have to be sneaky.  I'll have to make sure they think there's something cool (or scary) just around the next corner. Which there is.   That's what kept me busy for all these years.

Now there are elements of systems and networks that can be visualized.  The filesystem tree and the network itself can be mapped. Network traffic can be graphed, sorted, filtered and color coded. If I can find a way so that the student work has effects which can be seen I'll have some means of giving the students more visceral feedback.  There's nothing inherently graphical about computers or networks.  That's one of the messages I mean to bring to the students.  My job in designing a lab and a course is keeping them interested long enough for them to get it.

I've also read a whole bunch of books on tech topics.  One set that stand out in my mind are the "Think *" series by Allen Downey.  The first book "Think Python" was originally written to teach Java to high school students, and its original title was "How to Think Like a Computer Scientist".  These are neither traditional tech topic books, nor are they traditional classroom textbooks.  They are comprehensive in their topics, but they encourage exploration and self-learning in a way that I have not seen in any other books.  These are the inspiration for what I'd like to do.

A Pi Pod Lab

I have a number of goals to meet to create a teaching environment for System Administration and several points in which it will be different from lab for teaching graphics or hardware hacking.

  • The lab must be inexpensive.
    If it's going to be implemented in schools or clubs resources will be limited.
  • The lab environment must be modular.
    The lab environment should scale to accommodate small and large groups.
  • Student dues are less than $75 for materials.
    The student goes home with a Pi model B and enough additional hardware to make it run.
  • No commercial software should be needed.
    The students must be able to use existing workstations with minimal changes.
  • Remote Access and Control
    Physical access to the lab must not be required for students.
    The instructor should be able to restore the lab to initial state without physical access.
  • Physical Composition
    The lab components should be suitable for student access without danger of injury or damage.
    Ideally the students should be able to assemble and disassemble the lab from components.
  • CLI Control Interface
    The lab components will be controlled by various CLI interfaces through the head node.
    The Pi nodes will NOT have dedicated graphical displays.
  • Visualization
    The head node will provide some graphical visualization of the network and host status.
That's a short list. There are more that will come up.

Selecting the Components

Since it's already decided that a Raspberry Pi will be the central component of the lab, it's time to look at how to tie several of them together.  I'd really like for the students to be able to manage the power and console remotely.  I'd also like for them to be able to manage the first hop switch/router if possible. Ideally they could re-install the operating system from scratch without physical access.  This would require some kind of PXE based boot service on the student network.

It is required that the lab be accessible from the school network, but it should be possible to restrict outbound traffic from the lab to protect the hosting network.  Ideally the lab is also accessible directly from the internet, but it may be necessary for safety and security to require some authenticated access to reach it from outside.

In my experience I've worked mostly with medium and large scale enterprise network hardware. So of course my first thought for a router is a Cisco Catalyst gear.  Surely I could find some used gear on the web that would be suitable. Even when you whittle it down to the smallest managed components though, used and refurb hardware  runs into hundreds of dollars.  I thought that there would be APC switched PDUs on the used market, but no. A simple 8 port 15A switched PDU runs many hundreds of dollars.  This clearly isn't going to work.

Return to the Hacker Market

I really didn't want to build the lab from totally hacked up hardware.  I've worked with X10 power controls, but I don't find managing them to be very easy.  The units are bulky and trivial noise on the line can make them unreliable.  I could use another Pi for a router, but that would require another stage of configuration and management that I'm not prepared for.  I really wanted something in the middle.  The hardware should be commercially packaged, but I should be able to replace the OS with something designed for the job I have in mind.

I have heard of several home router hacks and I recently heard a talk CeroWRT (an update of OpenWRT with the Codel anti-bufferbloat algorithm implemented in the network stack).  I'd bought a Netgear WNDR 3800 router and re-flashed it with CeroWRT.  It only has 4 downlink ports, but it has an accessible USB port and it has a set of pins installed to provide a TTL serial console.  With the addition of a TTL to USB cable I could control and monitor the router out of band.  This would let me give the students access without fear of losing connectivity if they damaged it.  It's also $100US online.

I still needed power control.  On a whim I searched for "USB managed power" and came up with a hit. A company aptly named Power USB makes four port USB controlled 15A strips and they go for $70US retail. Who knew? With those two components I have the makings of a 4 Pi unit I'm calling a pod.

The remaining components are easier.  I need a powered USB hub to aggregate the Pi consoles, the router console and the power controller. A 7 port hub will do. I need some small high quality 5V 1A USB power converters but those are easy to come by. I need a TTL to USB serial cable for each Pi and for the router.  Those are now available pre-built by AdaFruit on the Newark/Element 14 site. 

I have every thing I need.  Now to lay it out, create a manifest and price the whole thing.

A "Pod" Component Map

This below is the map I came up with.  It includes 4 Raspberry Pi for the lab units, one Netgear router as the first hop for the lab, a 7 port powered USB 2.0 hub,  one PowerUSB Basic 4 port PDU and a 5th Pi as the "Head Node" to control the whole thing.  The diagram also includes the lab gateway router which will be required to isolate the lab components while providing connectivity.



Manifest

Student Gear

This is the hardware that will be given to the student at the end of the session and replaced at the beginning of the next.  The cost of this hardware is covered under the student dues.


Not the $75US I was hoping for and it doesn't account for shipping, etc, but it's close.
For the lab I may also want shorter USB power cables to keep them neat.

Pi Pod Gear

This section lists the stuff that's needed to make one pod, suitable to contain four student Pis.  Prices are approximate.  Network cables should be custom made to fit when the enclosure design is complete.


All that should go in an enclosure of uncertain dimensions and design.  I should probably add a set of Velcro ties to keep the cables neat and I'd really love to label all the cables with a Bradey cable labeller. That will come with the enclosure design.

Infrastructure

In addition to the Pis and the pods, a certain amount of infrastructure will be needed to provide connectivity, security and control of the lab pods themselves.  This includes the gateway router, and network service system which can provide PXE boot and install files for the pod hosts. The infrastructure I envision would support up to four pods and could be extended fairly easily in units of four more pods.


This places the starting cost for a single pod at $650 in reusable parts and $320 in student gear. Each new pod will cost and additional $380US. Hopefully I can design an enclosure that I can build for under $100.  If so that's actually on-par with Lego Mindstorms NXT for a comparable sized group.

Any mech eng people out there want to try building an enclosure for the pod?

I need to build one of these up and start looking at how to use it.  Ideas?

 References

Hardware

  • Raspberry Pi Model B
    http://www.raspberrypi.org
  • PowerUSB Basic
    http://www.pwrusb.com/powerUSB-basic.html
  • Netgear WNDR3800
    http://www.netgear.com/home/products/wirelessrouters/high-performance/wndr3800.aspx
  • Adafruit TTL-USB serial cable
    http://adafruit.com/products/954
  • Newark/Element 14
    http://www.newark.com

Linux Distributions

  • Raspbian
    http://www.raspbian.org
  • Arch Linux ARM, Raspberry Pi
    http://archlinuxarm.org/platforms/armv6/raspberry-pi
  • Fedora Remix for Raspberry Pi
    https://fedoraproject.org/wiki/Raspberry_Pi
  • CeroWRT (Router)
    http://www.bufferbloat.net/projects/cerowrt