Managing IT in a public school can be a rough gig. Penn Manor School District's IT Team manages more than 3,500 student Linux laptops and desktops, with hundreds of unique instructional requirements, spanning a multitude of subjects, departments, and grade levels. Budgets are lean, staffing is sparse, and classroom support needs continually grow. Given precious few human and fiscal resources, my team must band together to accomplish our educational mission and classroom technology goals.
Necessity and scarcity force us to work smart, but sans collaboration, we would simply drown. I think that may be why DevOps principles like automation, iteration, and orchestration resonate so strongly with our team; cooperative IT practices build better student experiences. DevOps is expected in the realms of system administration and application development, but what happens when the underlying practices and software tools are applied to schools? While codifying our operational framework, we uncovered a unique student learning opportunity.
Puppets are great classroom pets
It was 2010 when the first 600 Linux laptops began rolling out to classrooms in our seven elementary school buildings. We knew we had to think differently about device and patch management. There would be some commonality between elements of our elementary classroom systems, the default XFCE desktop environment, for example. But my team and I also wrestled with techniques to better support instructional technology requirements that varied widely by grade level.
Second-grade software can be dramatically different from programs in a sixth-grade classroom. My tiny team desperately needed a solution for managing classroom laptops as both cattle, and pets. Chad Billman, Penn Manor’s System Engineer, proposed open source Puppet as a solution. My team dove in and discovered that Puppet would be ideal for managing system patches, upgrades, and the dozens of little laptop settings and preferences needed by teachers at multiple grade levels. Puppet is used to set up network configurations, manage local accounts, define desktop preferences, and coordinate application installations. We even use it to manage quick-launch web shortcuts, which helps emerging readers quickly navigate to teacher-curated websites.
Better than a red pen
As our investment in classroom Linux laptops grew to nearly 1,800 elementary and middle school systems, the need for collaborative code review and version control became vital. District Puppet configs were moved to a local GIT/Gerrit server. Gerrit’s orchestration capabilities are essential to my team's operations, because Penn Manor School District encompasses 10 school buildings across a 110 square mile geographic footprint, which means we are essentially a distributed team. Beyond the obvious advantages of utilizing GIT for team code and configuration development, Gerrit’s side-by-side code review and approval tools help my staff easily review each other’s work from afar. Configuration bugs are revealed and stamped-out before they hit our student laptops and cause classroom calamity.
Automatic, for the pupil
Our success with Puppet, GIT, and Gerrit prepared us with processes and tools to tackle a huge instructional project, distributing Linux laptops to every one of our 1,700 high school students as part of a 1:1 laptop learning program. With a configuration and code review system in place, the next task was to build a continuous integration pipeline for the high school laptop system image.
During the ramp-up to the January 2014 program launch, we adopted an automated master image creation process for student laptops. The desired outcome was a fresh-off-the-press laptop image that incorporated up-to-the-minute security and application updates as well as our school environment configurations and preinstalled software. The master image would be used to reset loaner laptops after use, prepare new laptops for incoming new enrollments, or factory restore a laptop if a student were to muck up their system. (Our students have root access to their school-issued laptops, so mistakes are bound to happen).
To achieve this, images are generated via Packer, which merges our custom Puppet configurations with a local mirror of Ubuntu 14.04 OS, inclusive of the latest system updates. The entire image creation process is scheduled via Jenkins, which triggers a daily Packer build and outputs the master image VM to a designated file share. At the end of the pipeline, the image VM is feed into our multicast imaging system, an internally developed application called the Fast Linux Deployment Toolkit (FLDT). In addition to the daily build, Packer is also set to build an image and virtual machine for every configuration change pushed to Git. With the entire process automated, my team, or our student tech apprentices, can easily test a proposed configuration change in a VM, or actually image it onto a student laptop for real-world testing.
21st century public announcement system
With the laptops distributed, what happens when the next Firefox update or security patch lands 30 seconds later? When our students first receive the school-issued laptop, they receive a 15 minute tutorial, which includes guidance to run software updater on a regular basis. However, like adults, teenagers often disregard or simply forget about personal system maintenance. How do we urgently patch all systems or mass-push a required application?
Case in point: At the very start of the current academic year, with my team and support resources well over capacity, Pennsylvania schools received a surprise, last-minute, mandatory update to a critical student assessment and testing software program. The timing was terrible, but we had to coordinate the update as quickly as possible. Because we maintain SSH access to every student laptop, Ansible was a lifesaver. My team created an installation playbook for the required software, and easily connected to the laptop fleet over the course of a couple of school days. Of course, if our student laptops were online at all times, like servers, the process would have taken seconds.
Cool kids code…and collaborate
As we built better IT processes, we serendipitously created unique opportunities for our students. Gerrit is perfectly suited for our high school student help desk; a student apprentice can study and examine code and configurations, and learn from an authentic development model. What’s more exciting is that budding student programmers can actively participate in the design, development, and testing of the high school laptop image used by their peers. IT staff or teachers can then examine and review the submission before accepting or denying the student work. Several student help desk apprentices have actively contributed code and configuration adjustments. Specific examples of contributions to our master high school laptop image include the refinement of default trackpad settings, bug-squashing audio recording kinks, and the testing and integration of several key desktop software packages.
The student apprentices are having fun while participating in the authentic practice of continuous software delivery. What’s better than opening up Gerrit and seeing that your code was reviewed and merged? For our kids, I suspect it is more satisfying than passing a pop quiz on a random collection of facts easily found via a Google search. When we trust students, and directly involve them in the development of their own school software, the lines between developer and operator, teacher and student, begin to blur.
Special thanks to Chad Billman, the chief technical architect behind our DevOps projects and programs.
Education
A collection of articles from educators, students, advocates, parents, and more who are implementing open source in education and working toward a more open knowledge base for everyone.
1 Comment