- Connect with community users on topics of interest for less formal learning sessions.
- Accomplish the above with minimal tool requirements for the end-users/students.
- Assess needed and currently available tools then determine how best to implement these in an automated fashion using best practices (what can be referred to as drinking our own champagne.)
These are pretty straightforward goals on the surface but some proved to have less-than-obvious challenges in their actual execution. Firstly, the goal of connecting with community specifically for learning sessions or information is tightly wound in the Eucalyptus goals. I didn't need to reinvent the wheel here; indeed most, if not all, open source projects and companies have a very good understanding of this (or, if they don't they learn fast lest they face the wrath of the internet.) As I said earlier most of our interaction on a community level is done via IRC as well as within our ticketing systems and email lists. These methods are as old as the open source movement itself so I won't go into great detail about this. I will say that specifically we had the goals of maintaining existing channels of communication and taking into account bandwidth limitations of those interested.
It is easy for me to assume everyone has broadband but the fact is many of the people we connect with (and some of our staff) have very remote, low-bandwidth or otherwise constricted connectivity. This means IRC is a natural answer: it uses very little bandwidth. To compliment an IRC session we initially wanted to use a service similar to Mikogo, Adobe Connect, Cisco WebEx or GoToMeting to be able to show examples as discussion progressed in the IRC channel. Bandwidth limitations made these choices less than optimal despite their attractiveness in feature set. We assumed dial-up access for all and worked to that end to provide the lowest bandwidth-consuming solution.
What we settled on as a compliment to the IRC channel was to use a virtual instance spun up with some basic tools needed installed: namely GNU Screen, an ssh daemon and some basic configuration tweaks to user accounts. This was a low-enough bandwidth solution to be acceptable and offered real-time examples to augment the IRC discussion, viewable on any machine with an ssh client, which covers not just Linux/Mac/Windows, but also android and iOS.
I should point out this isn't an original idea: many people over the years have done this from university workshops to Red Hat learning sessions or Ubuntu Classroom. If you're thinking at this point "So what? That's not new...", you would be absolutely correct. The goal of this series of posts is not to share a revolutionary idea, but to give the reasoning, technical specs and how-to tips I have culled from various internet sources and worked with coworkers here at Eucalyptus to put together in one place. After all, there is at least a 20 year old history of existence of these tools. These tools, however, are not the first choice in most corporate environments and use may be waning. (I have no data to back up that claim, but it feels that way.) Obviously what I am detailing is related mostly to dealing with shell or command-line topics. If you need to detail flashy windowed UI's, you probably want one of the other conferencing softwares mentioned above. Since quite a lot (if not all) of Linux administration, or, if you will, Eucalyptus cloud administration, can be done from the command line our needs were specific: show the students a shell.
In the next post in this series I will detail specifics learned from adapting information culled around the internet to our specific needs and implementation: I will focus on setting up screen on a remote host for everyone to watch the presenter give examples and tutorial walk-throughs as well as an attempt at documenting best-practices for user administration, tool installation and other needed system tweaks.