A Self-Contained Local Access Point for Workshops

If you conduct hands-on technical training classes or workshops, you may have experienced some delay at the start of the session in getting all the participants configured and connected so they can start working. In my experience, it’s common to burn half a day and sometimes more dealing with setup and connection issues on everyone’s workstation or laptop.

Strangely, even when participants are using similar equipment the gremlins of software and networking find ways to give each person a unique problem. Often, we have to call in a local expert to diagnose network issues.

Trainers and consultants address the issue in various ways.

We might ask the host to provide Internet access to all participants. Many companies prefer not to do this as it introduces a security risk. As for rented public venues, some charge very high rates to open up Internet access to all the participants of an event, although most will provide a single connection for the facilitator or presenter.

We might ask the host to configure internal servers with the resources needed for the workshop. Many companies prefer not to do this because it requires extra labor on the part of their technical staff, they don’t want to load your code and other workshop materials on their network, and/or they worry that you might see or download proprietary material either intentionally or inadvertently.

We might prepare thumb drives with the workshop code and handouts so that participants can load the material on their machines. Many companies disable support for external media on their machines for security reasons. In that case, participants have no way to load anything from an outside source onto their machines.

We might prepare virtual machines that are preconfigured for the workshop or training class, so that participants need not spend any time at all setting up their machines other than having a hypervisor installed. Many companies don’t allow all technical staff members to install hypervisors on their individual workstations or laptops. The same solution could work with a cloud service, but not if the company doesn’t allow Internet access.

We might live with the situation by limiting the workshop activities to tasks that can be performed locally on each machine. That approach prevents participants from using version control, downloading dependencies from an artifact repository, and using a continuous integration server, and limits the activities participants can practice during the session. In these cases, our hosts (and participants) might complain that the workshop isn’t “realistic” enough, even if the cause is the very constraints they have imposed.

Yet Another Attempted Solution

Is there a way to provide participants with an artifact repository, a continuous integration server, and a version control system in a way that doesn’t require us to carry a lot of equipment with us, doesn’t eat into the resources of our laptops, and doesn’t introduce a threat surface on our laptops?

This article describes one possible solution: A Raspberry Pi configured as a wireless access point, but expressly not as a wireless bridge, and loaded with an artifact repository server, a continuous integration server, and a version control server. The unit fits in the palm of your hand and doesn’t require a monitor, keyboard, or mouse. It easily fits in the box of supplies you already have for your workshop or class.

Overview of What is on the Raspberry Pi

Raspberry Pi 3B+ configured with:

• Wireless access point support (but no Internet pass-through)
• Jenkins continuous integration server
• Gogs Github server
• Sonatype Nexus artifact repository server

Components:

• CanaKit Raspberry Pi Complete Starter Kit – 32 GB Edition (PI3-STR32-C4-BLK-R17)
• Generic USB power cable extender with on/off switch
• Jenkins continuous integration server
• Gogs Github server
• Sonatype Nexus Repository Manager

Configuring the Raspberry Pi

Here’s a step-by-step guide to configuring a Raspberry Pi this way:

Raspberry Pi Configuration (PDF)

You can do something similar to support your training and consulting activities, if it makes sense in your situation.

Provisioning the Raspberry Pi

The details will depend on what you plan to do during your class or workshop. Load whatever source repositories you will need into Gogs. Load whatever dependencies there are for the workshop project(s) into Sonatype Nexus. Configure Jenkins the way you need it to support the workshop project(s).

Configure Nexus for NPM Packages

Out of the box, Sonatype Nexus isn’t set up for NPM repositories. See Configuring Nexus as a npm repo in the Sonatype Nexus help docs.

Configure Nexus for Nuget Packages and VisualStudio

Out of the box, Sonatype Nexus isn’t set up for Nuget repositories. See Virtual Nuget Repositories in the Sonatype Nexus help docs.

Set Up an Information Radiator for Build Status

You can set up a computer attached to a monitor and connect to the Jenkins server at http://172.16.4.1:8080. This can display build status to the room during your session.

Workshop Participants’ Access

The servers are exposed at these URLs:

• Jenkins: http://172.16.4.1:8080
• Nexus: http://172.16.4.1:8081
• Gogs: http://172.16.4.1:3000

Use the Workshop Gogs Instance for Git

From the client system’s perspective, Gogs is the same as a Github or GitLab server. Have participants initialize their projects by cloning from the workshop repository, and the remote URL will already be set.

git clone git://172.16.4.1:3000/yourusername/yourproject.git

Pull Dependencies from This Nexus

Workshop participants can configure their build tools to access this Nexus for dependencies. Even better, you can ensure things are defined appropriately in the workshop projects that participants clone from Gogs.

Gradle: build.gradle file

repositories {
    maven {
        url "http://172.16.4.1:8081"
    }
}

Maven: pom.xml file

<repositories>
    <repository>
      <id>workshop-repo</id>
      <name>Our local artifact repository</name>
      <url>http://172.16.4.1:8081</url>
    </repository>
</repositories>

sbt: build.sbt file

resolvers += "Nexus" at "http://172.16.4.1:8081/nexus/content/groups/public"

Scala is a JVM language and sbt uses the Maven repository format for dependencies, but you have to declare a resolver explicitly. For more information please see the Sonatype Nexus SBT help topic.

Bundler: Gemfile file

source "http://172.16.4.1:8081"

NPM: set registry

Either run the command or edit the .npmrc file (not both). Command:

npm config set registry http://172.16.4.1:8081/repository/npm-all/

Edit the .npmrc file:

registry = http://172.16.4.1:8081/repository/npm-all/

Nuget: Add source

Tell Nuget to look for the workshop repository (the command is a single line; it may wrap in your browser):

nuget sources add -name NuGetNexus -source http://172.16.4.1:8081/nexus/service/local/nuget/nuget-public

Also see Integration of Nuget Repositories in VisualStudo in the Sonatype Nexus help docs.

Conclusion

We hope this approach may be of help to some who do workshops and training at public and client venues.