Skip to content
BranchesTags

Latest commit

 

History

8 Commits

Folders and files

NameName
Last commit message
Last commit date
.vscode
.vscode
 
 
fingerprints
fingerprints
 
 
scripts
scripts
 
 
README.md
README.md
 
 

Repository files navigation

Codio Virtual Desktops — Linux

This repository documents the Linux-based Codio Virtual Desktop (CVD) environment.

Its primary purpose is to help academic program deans, subject-matter experts (SMEs), course developers, and technical staff understand the capabilities, limitations, configuration, and provenance of the Linux CVD environment.

The repository also provides tools and configuration artifacts for:

  • Fingerprinting deployed CVD environments.
  • Distinguishing the common Codio Linux baseline from course-specific VM Stacks and runtime changes.
  • Comparing CVD configurations across courses.
  • Reproducing important CVD characteristics in local virtual machines.
  • Testing course software, automation scripts, and configuration changes outside production CVDs.
  • Supporting technical troubleshooting and environment diagnostics.

Important

A local virtual machine can approximate the software and desktop environment of a CVD, but it cannot exactly reproduce Codio's managed AWS infrastructure, networking, lifecycle controls, or platform integrations.

Contents

Purpose and Scope

The CVD used by a particular course is not necessarily identical to the Linux image originally supplied by Codio.

A deployed course CVD can contain several layers of configuration:

  1. Codio-managed AWS infrastructure.
  2. A Codio-provided Ubuntu machine image.
  3. A published VM Stack.
  4. Course-specific configuration.
  5. Changes made after an individual VM is instantiated.

Understanding which layer introduced a package, service, configuration file, desktop setting, or other characteristic is important when:

  • Designing or revising STEM courses.
  • Determining whether software is available to all CVD-enabled courses.
  • Building or updating a course VM Stack.
  • Developing course automation scripts.
  • Diagnosing student or faculty problems.
  • Evaluating CVD resource requirements.
  • Testing operating-system upgrades.
  • Replicating a course development environment locally.
  • Determining whether a problem originates with Codio, a VM Stack, a course configuration, or user changes.

This repository therefore treats provenance as part of the environment specification.

Architecture and Terminology

Codio IDE and Codio Box

The standard Codio development environment runs in a Codio Box associated with a project or assignment.

The Codio Box and a Standalone Virtual Machine are separate environments.

For example, Codio documents these working directories:

Environment Working directory
Codio Box /home/codio/workspace
Ubuntu Virtual Machine /home/ubuntu
Windows Virtual Machine C:\

Files can be transferred or synchronized between the Codio Box and the Virtual Machine using Codio's VM integration tools.

Standalone Virtual Machine

Codio supports a Standalone VM option at the course level.

Codio currently documents Ubuntu and Windows as supported operating-system choices for Standalone VMs.

When configuring an Ubuntu Standalone VM, Codio allows the course author to select either:

  • The Codio-provided Ubuntu Codio AMI.
  • A previously published custom VM Stack.

Codio documents the Ubuntu base image name as:

codio-aws-ubuntu-base

Codio AMI

An Amazon Machine Image (AMI) is an AWS machine-image template used to launch EC2 virtual machines.

Codio identifies codio-aws-ubuntu-base as the Ubuntu Codio AMI.

The public Codio documentation reviewed for this repository does not currently provide:

  • The underlying public AWS AMI ID.
  • A downloadable disk image.
  • An authoritative package inventory for the image.
  • An authoritative current Ubuntu release number for the image.
  • A complete build history for the image.

These characteristics must therefore be established through Codio documentation, direct observation, controlled comparison, or information supplied by Codio.

VM Stack

For Standalone Virtual Machines, Codio uses the term VM Stack for a saved VM configuration that can be selected for a course.

A course author can:

  1. Start with the Ubuntu Codio AMI or an existing VM Stack.
  2. Start the VM associated with an assignment.
  3. Install or configure the required software.
  4. Test the resulting environment.
  5. Publish the VM as an updated VM Stack.
  6. Select that VM Stack for the course.

Codio states that all assignments in a CVD-enabled course use the same VM Stack.

Note

Codio also uses the term Stack for software configurations associated with standard Codio Boxes. Although the concepts are related, a Codio Box Stack and a Standalone VM Stack should not be assumed to be technically identical. This repository uses VM Stack when specifically referring to the Standalone VM feature.

Course Master

This repository uses course master CVD as a working term for the faculty/development VM used to prepare, test, and publish the CVD environment for a course.

{{Confirm or replace "course master CVD" with the preferred terminology.}}

Runtime State

After a VM is instantiated from its VM Stack, faculty or students may make additional changes such as:

  • Installing packages.
  • Updating operating-system packages.
  • Changing configuration files.
  • Creating files.
  • Installing development tools.
  • Modifying desktop settings.
  • Authenticating applications or services.

These changes are runtime state and should not automatically be interpreted as characteristics of the original VM Stack or Codio Ubuntu base image.

Environment Layer Model

The working model for this repository is:

Codio platform and AWS infrastructure
                |
                v
Ubuntu Codio AMI
codio-aws-ubuntu-base
                |
                v
Published VM Stack
                |
                v
Course deployment
                |
                v
Individual faculty/student VM
                |
                v
Runtime and user changes

A characteristic found in a course CVD should be assigned to a specific layer only when sufficient evidence exists.

If its origin cannot yet be established, it should remain classified as Unknown.

Baseline Definition and Provenance

What "baseline" means

In this repository, the CVD Linux baseline is the set of characteristics that can be established as belonging to the common Codio Ubuntu CVD environment before course-specific VM Stack customizations are applied.

The baseline is intended to answer questions such as:

  • Which operating system does Codio supply?
  • Which kernel family is used?
  • Which packages are present before course customization?
  • Which desktop environment is present?
  • Which Codio or AWS services are present?
  • Which accounts and permissions exist?
  • Which display and remote-desktop services are required?
  • Which settings are common to CVDs across STEM courses?

The baseline is not defined simply as everything found in one course's CVD.

Evidence classifications

Repository findings should use the following evidence classifications.

Classification Meaning
Documented Explicitly stated by Codio, Ubuntu/Canonical, AWS, or another authoritative source
Observed Directly measured in one or more CVD instances
Corroborated Observed independently in multiple course CVDs or environments
Inferred Strongly suggested by available evidence but not directly established
Unknown Origin or status cannot yet be determined

When appropriate, records should also identify the configuration layer:

Layer Meaning
codio-infrastructure Codio-managed platform or AWS integration
ubuntu-codio-ami Codio-provided Ubuntu machine image
vm-stack Published VM Stack
course Course-specific files or configuration applied separately
runtime Changes occurring after VM instantiation
unknown Layer has not yet been established

Codio Ubuntu Base Image

Codio documentation identifies the Linux Standalone VM base image as:

Property Current evidence
Codio name Ubuntu Codio AMI
Image name codio-aws-ubuntu-base
Cloud platform Amazon Web Services
Architecture {{Confirm baseline architecture; current observed IT 140 CVD is amd64/x86_64.}}
Ubuntu release {{Obtain an untouched Ubuntu Codio AMI fingerprint or authoritative Codio specification.}}
Kernel {{Obtain from untouched Ubuntu Codio AMI.}}
Public AMI ID {{Not currently located in public Codio documentation.}}
Image build date {{Obtain from Codio.}}
Default user ubuntu is documented as the Ubuntu VM working-directory account and observed in the IT 140 CVD
Home directory /home/ubuntu
Package manager APT
Administrative privileges {{Confirm specifically for Standalone Ubuntu VMs. Full sudo access is documented for Codio Boxes and observed in the IT 140 CVD.}}
Default connection methods Codio documents SSH and graphical VM access
Default package inventory {{Fingerprint untouched Ubuntu Codio AMI.}}
Default desktop environment {{Fingerprint untouched Ubuntu Codio AMI.}}

Ubuntu release and kernel caution

A Linux kernel version alone should not be used to determine the Ubuntu userspace release.

For example, Canonical currently publishes the 7.0.0-1009-aws AWS kernel in Ubuntu 24.04 LTS package repositories. The presence of that kernel therefore does not, by itself, prove that a machine is running Ubuntu 22.04 LTS.

The Ubuntu release should instead be established using evidence such as:

cat /etc/os-release
lsb_release -a

and, ideally, corroborated against an untouched Codio Ubuntu AMI.

Historical baseline candidate

The following has been reported as a possible earlier Ubuntu Codio AMI state:

Ubuntu 22.04.3 LTS
7.0.0-1009-aws x86_64 GNU/Linux

This combination is retained as a baseline candidate, not an established baseline, until its provenance can be verified.

{{Fingerprint an untouched Ubuntu Codio AMI or obtain the corresponding Codio image specification to confirm or correct this candidate.}}

Observed Linux CVD Environment

IT 140 reference specimen

A fresh IT 140 CVD instance was fingerprinted on August 7, 2026.

This specimen is useful for understanding a deployed CVD but must not be treated as the untouched Codio baseline. The IT 140 course master had previously undergone course-specific installation, configuration, and operating-system maintenance.

The specimen reported:

Characteristic Observed value
Operating system Ubuntu 24.04.4 LTS
Ubuntu codename Noble Numbat
Architecture x86-64 / amd64
Kernel 6.17.0-1019-aws
Cloud platform Amazon EC2
Hardware model t3.medium
Virtualization Amazon / KVM full virtualization
vCPUs 2
RAM Approximately 4 GiB
Swap Approximately 1.9 GiB zram
Virtual disk 30 GiB Amazon Elastic Block Store
Root filesystem ext4
Firmware/boot UEFI/GPT
Desktop environment Xfce 4.18
Display manager LightDM
Display protocol X11
Default user ubuntu, UID 1000
User home /home/ubuntu
Default timezone UTC
Default locale C.UTF-8
Python Python 3.12.3
Git Git 2.43.0
GitHub CLI GitHub CLI 2.96.0
Visual Studio Code VS Code 1.128.0

AWS characteristics observed

The reference specimen exposes several AWS-specific components that should not be expected to reproduce exactly on a local VM:

  • Amazon EC2 virtualization.
  • Amazon Elastic Block Store presented through NVMe.
  • Amazon Elastic Network Adapter.
  • AWS-specific Linux kernel.
  • EC2 instance metadata/network behavior.
  • EC2 instance-connect components.
  • AWS hibernation components.
  • Amazon SSM Agent.

Desktop characteristics observed

The current IT 140 specimen uses:

  • Xfce 4.18.
  • LightDM.
  • X11.
  • VNC-related services.
  • Xfce desktop, panel, window-manager, notification, keyboard, display, and power-management configuration.
  • A graphical desktop exposed through Codio's VM interface.

Observed services include:

  • lightdm.service
  • vncserver.service
  • NetworkManager.service
  • systemd-networkd.service
  • systemd-resolved.service
  • snapd.service
  • cups.service
  • chrony.service
  • cloud-init services

{{Determine which observed desktop and service components originate in the Ubuntu Codio AMI and which were added by the IT 140 VM Stack.}}

IT 140-specific state

The specimen also contains clear IT 140-specific state, including:

  • The ~/it140/ course directory.
  • IT 140 automation scripts.
  • IT 140 course repositories and supporting files.
  • Course-specific Visual Studio Code extensions.
  • Course-specific Git configuration.
  • Course-specific desktop launchers.
  • Python testing and linting tools used by IT 140.

These items must not be classified as part of the common CVD baseline without independent corroboration.

Fingerprinting

Purpose

Fingerprinting captures the observable configuration of a running CVD so that environments can be:

  • Documented.
  • Compared.
  • Reproduced.
  • Diagnosed.
  • Classified by configuration layer.
  • Checked for unintended changes.
  • Compared with local VM emulations.

The goal is not merely to collect system information. The long-term goal is to determine the delta between layers.

For example:

IT 140 CVD fingerprint
        -
Common CVD baseline fingerprint
        =
IT 140 VM Stack and course delta

As additional course CVDs are fingerprinted, common characteristics can be identified with greater confidence.

Current fingerprint coverage

The current fingerprinting approach captures information about:

  • User and operating-system identity.
  • Kernel and boot configuration.
  • Virtualization.
  • CPU and memory.
  • Block devices and filesystems.
  • PCI and USB devices.
  • Debian package architecture.
  • Installed and manually selected APT packages.
  • APT repositories.
  • Desktop environment.
  • Xfce configuration.
  • Desktop entries.
  • Shell configuration.
  • Development tools.
  • Python and Python packages.
  • Visual Studio Code and extensions.
  • Git configuration.
  • System services.
  • Fonts and Fontconfig.
  • Network interfaces, routes, and DNS configuration.
  • Course deployment files.
  • File hashes.
  • Configuration metadata.

Fingerprint outputs

Each fingerprint run should create its own directory rather than modifying a previous capture.

Recommended naming convention:

cvd_fingerprint_<context>_<hostname>_<YYYYMMDD_HHMMSS>/

Each fingerprint directory should contain:

README.txt
fingerprint.log
SHA256SUMS
<individual fingerprint artifacts>

Fingerprint comparison

Future comparison tooling should support:

  • Package additions.
  • Package removals.
  • Package version changes.
  • Service additions and removals.
  • Service enablement changes.
  • Kernel changes.
  • Operating-system changes.
  • Desktop configuration differences.
  • User/group differences.
  • Repository differences.
  • Development-tool differences.
  • File and configuration changes.

{{Define the canonical machine-readable fingerprint manifest and comparison-report format.}}

Baseline-identification strategy

A single course CVD cannot establish the common baseline.

The preferred process is:

  1. Fingerprint an untouched Ubuntu Codio AMI, if access becomes available.
  2. Fingerprint fresh CVDs from multiple courses.
  3. Compare installed packages, services, configuration, and files.
  4. Identify characteristics common across independently configured courses.
  5. Separate known course-specific VM Stack additions.
  6. Compare findings with Codio, Ubuntu, and AWS documentation.
  7. Classify each characteristic according to evidence and configuration layer.
  8. Maintain unresolved characteristics as unknown rather than guessing.

Pre-configured VM Stacks

Purpose of VM Stacks

A VM Stack allows a course to provide a pre-configured virtual machine rather than requiring each student to configure the base Ubuntu environment manually.

Typical VM Stack additions may include:

  • Programming languages.
  • Compilers and interpreters.
  • Development environments.
  • IDEs and editors.
  • Browser software.
  • Databases.
  • Libraries.
  • Testing tools.
  • Course-required command-line utilities.
  • Desktop configuration.
  • Services.
  • Course automation.
  • Security or usability configuration.

Codio VM Stack workflow

Codio's Standalone VM workflow allows an author to:

  1. Select the Ubuntu Codio AMI or an existing VM Stack.
  2. Start the Ubuntu VM.
  3. Install and configure required software.
  4. Test the environment.
  5. Publish the configured VM as a new or updated VM Stack.
  6. Select the published VM Stack for the course.

Codio recommends completing and testing the VM Stack before students begin using assignments.

Course-wide scope

Codio documents VM configuration at the course level and states that all assignments in a course use the same VM Stack.

This makes VM Stack design a course architecture decision, rather than an individual-assignment installation decision.

Updating a VM Stack

Publishing an updated VM Stack does not automatically migrate runtime changes from an already-running student VM.

Codio documents that students who began work before an updated VM Stack was published may need their VM reset to receive the new stack.

Caution

Resetting a student's Virtual Machine removes work stored in that VM. VM Stack changes should therefore be fully tested before deployment.

STEM VM Stack catalog

This repository should maintain a catalog of known STEM VM Stacks.

VM Stack Course(s) Base Major additions Last fingerprinted Status
IT 140 course CVD IT 140 Ubuntu Codio AMI + custom VM Stack Xfce desktop environment, VS Code, Chrome, Git, GitHub CLI, Python development environment, course automation, and supporting configuration are present in the deployed specimen; precise layer attribution remains under investigation 2026-08-07 Active / under analysis
{{VM Stack name}} {{Course(s)}} {{Base image or parent VM Stack}} {{Major additions}} {{YYYY-MM-DD}} {{Status}}

VM Stack records

Each documented VM Stack should eventually have its own directory containing, as applicable:

stacks/
└── <stack-id>/
    ├── README.md
    ├── fingerprints/
    ├── manifests/
    ├── scripts/
    └── differences/

A VM Stack README should identify:

  • Stack name.
  • Stack owner.
  • Courses using the stack.
  • Parent image or VM Stack.
  • Intended purpose.
  • Operating-system release.
  • Major installed packages.
  • Desktop environment.
  • Enabled services.
  • Configuration changes.
  • Build or provisioning scripts.
  • Fingerprint references.
  • Known limitations.
  • Last verification date.
  • Current status.

{{Add the Codio VM Stack IDs/version identifiers if they can be retrieved from the organization interface or Codio API.}}

Local CVD Emulation

Purpose of Local CVD Emulation

Local VM configurations allow faculty and staff to approximate a course CVD without modifying a production Codio environment.

Potential uses include:

  • Course development.
  • VM Stack planning.
  • Software compatibility testing.
  • Automation-script development.
  • Operating-system update testing.
  • Troubleshooting.
  • Regression testing.
  • Resource analysis.
  • Reproducing reported problems.
  • Comparing course configurations.

Emulation principle

Local emulation should reproduce the behavior relevant to course development, rather than attempting to reproduce every AWS implementation detail.

The preferred model is:

Local Ubuntu VM
       |
       v
Common CVD-compatible configuration
       |
       v
Course VM Stack overlay
       |
       v
Local approximation of course CVD

This allows common CVD configuration and individual course overlays to remain separate.

Provisional IT 140-compatible profile

Based on the August 7, 2026 IT 140 fingerprint, a useful provisional local VM configuration is:

Resource Provisional configuration
Architecture x86-64
vCPU 2
Memory 4 GiB
Disk 30 GiB minimum
Firmware UEFI
Partitioning GPT
Root filesystem ext4
Operating system Ubuntu 24.04 LTS
Desktop Xfce 4.18
Display manager LightDM
Display protocol X11
Shell Bash
Default user ubuntu
Swap zram where practical

This profile approximates the observed IT 140 CVD, not an established untouched Codio baseline.

Hypervisor profiles

The repository may contain local configurations for:

local-vm/
├── common/
├── hyper-v/
├── virtualbox/
├── vmware/
└── {{additional hypervisor}}/

Each hypervisor profile should document:

  • Supported host operating systems.
  • VM hardware configuration.
  • Firmware mode.
  • Virtual CPU configuration.
  • Memory.
  • Storage.
  • Network mode.
  • Display configuration.
  • Guest additions or integration tools.
  • Provisioning procedure.
  • Known differences from CVD.
  • Validation procedure.

{{Select the initial supported local hypervisor(s).}}

Provisioning

Where practical, local environments should be created reproducibly from scripts or declarative configuration rather than documented as a long series of manual changes.

Potential approaches include:

  • Shell provisioning scripts.
  • Cloud-init.
  • Packer.
  • Vagrant.
  • Hypervisor-native configuration files.
  • Other infrastructure-as-code tooling.

{{Select the preferred provisioning architecture after evaluating cross-platform requirements.}}

Validation

A locally emulated CVD should be fingerprinted using the same core fingerprinting logic as the reference CVD.

Validation should compare:

  • Operating system.
  • Architecture.
  • Package inventory.
  • Desktop environment.
  • Display session.
  • Services.
  • Shell environment.
  • Development tools.
  • Filesystems.
  • User configuration.
  • Course-specific tools.

Differences should be classified as:

  • Required match.
  • Expected platform difference.
  • Acceptable difference.
  • Unexplained difference.

Known Local-Emulation Differences

An ordinary local VM should not be expected to reproduce every characteristic of the Codio CVD.

AWS infrastructure

The observed IT 140 CVD uses Amazon EC2 infrastructure, including:

  • Amazon-specific virtualization.
  • Elastic Block Store.
  • NVMe virtual storage.
  • Elastic Network Adapter networking.
  • AWS-specific kernel packages.
  • EC2 initialization and management components.

A local VM running under Hyper-V, VirtualBox, VMware, or another hypervisor will expose different virtual hardware.

Instance type

The observed IT 140 specimen reports an AWS t3.medium instance with:

  • 2 vCPUs.
  • Approximately 4 GiB RAM.

Codio documents CVD performance options based on memory allocations of 1, 4, 8, or 16 GB.

{{Determine whether Codio guarantees particular EC2 instance types for each performance tier or may change the underlying instance family.}}

Networking

A local VM will not reproduce:

  • Codio-managed networking.
  • AWS VPC topology.
  • EC2 metadata behavior.
  • Codio port-forwarding behavior.
  • Codio authentication or session integration.
  • Codio-controlled external access.

Network behavior that materially affects course software should therefore be tested in Codio even when local VM testing succeeds.

Remote desktop

The local hypervisor's display mechanism will differ from Codio's browser-delivered graphical VM access.

The local VM should reproduce important guest-side components when needed, but reproducing Codio's browser delivery layer is outside the scope of local emulation.

Codio integration

Local VMs will not natively provide Codio-specific course functions such as:

  • Starting or opening a VM from a Codio assignment.
  • codio-tools integration.
  • File synchronization between the Codio Box and VM.
  • VM reset controls.
  • Course-level VM Stack selection.
  • Codio-managed assignment lifecycle.

Capabilities and Limitations

Administrative access

The observed IT 140 CVD ubuntu account belongs to the sudo group and has administrative capability.

Codio's general Linux environment documentation also describes full sudo access for Codio Boxes, with course-level controls available to restrict unauthorized software installation.

{{Confirm whether the same sudo-revocation mechanism applies specifically to Standalone Ubuntu VMs.}}

Package management

Observed CVDs use standard Ubuntu/Debian package management, including:

apt
dpkg

The IT 140 reference specimen uses Ubuntu Noble repositories together with additional repositories for software such as:

  • Microsoft Visual Studio Code.
  • Google Chrome.
  • GitHub CLI.

These third-party repositories are part of the observed course environment and should not be assumed to exist in the untouched Ubuntu Codio AMI.

Graphical software

The observed IT 140 CVD supports an Xfce graphical desktop and graphical applications.

Course designers should nevertheless validate graphics-intensive or latency-sensitive applications in the actual CVD environment because a browser-delivered remote desktop differs substantially from direct local rendering.

Resources

CVD workloads are constrained by the selected VM performance tier.

Course designers should consider:

  • RAM requirements.
  • CPU requirements.
  • Disk usage.
  • Startup time.
  • Update size.
  • Network downloads.
  • Background services.
  • Browser memory consumption.
  • IDE memory consumption.

Resource-intensive workloads should be tested under the same performance tier intended for students.

Persistence and reset behavior

A running CVD may contain student-created files and configuration changes.

Codio documents that resetting a VM to obtain an updated VM Stack can remove work stored in that VM.

Course design should therefore distinguish between:

  • Re-creatable environment state.
  • Course-provided files.
  • Student work.
  • Credentials and authentication state.
  • Data that must survive ordinary course activity.

Pair programming

Codio currently documents Pair Programming as unsupported for Virtual Machines.

Software licensing

Software placed into a VM Stack remains subject to its applicable license terms. Codio states that responsibility for software licensing rests with the organization or user installing the software.

Repository Structure

The target repository organization is:

.
├── README.md
├── baseline/
│   ├── README.md
│   ├── fingerprints/
│   ├── manifests/
│   └── comparisons/
├── stacks/
│   ├── README.md
│   └── <stack-id>/
│       ├── README.md
│       ├── fingerprints/
│       ├── manifests/
│       ├── scripts/
│       └── differences/
├── local-vm/
│   ├── README.md
│   ├── common/
│   ├── hyper-v/
│   ├── virtualbox/
│   └── vmware/
├── scripts/
│   ├── README.md
│   ├── fingerprint/
│   ├── compare/
│   ├── provision/
│   └── verify/
└── docs/
    └── README.md

{{Revise this structure as repository tooling and VM profiles are implemented.}}

baseline/

Contains evidence and specifications describing the common Linux CVD environment.

stacks/

Contains documentation and reproducible artifacts associated with specific STEM VM Stacks.

local-vm/

Contains local virtualization configurations and provisioning artifacts.

scripts/

Contains reusable tools for:

  • Fingerprinting.
  • Comparing environments.
  • Provisioning local VMs.
  • Verifying configurations.
  • Supporting diagnostics.

docs/

Contains technical documentation that is too detailed for the repository root README.

Change Management

Baseline changes

The baseline should be updated when evidence shows that Codio has changed the common Ubuntu CVD environment.

Potential indicators include:

  • Ubuntu release changes.
  • Kernel-family changes.
  • Default package changes.
  • Desktop changes.
  • Service changes.
  • Cloud infrastructure changes.
  • Default account or permission changes.
  • Codio integration changes.

A newly observed difference should not automatically redefine the baseline.

The change should first be classified as:

  • Codio baseline change.
  • VM Stack change.
  • Course change.
  • Runtime change.
  • Unknown.

VM Stack changes

A VM Stack change should be:

  1. Planned.
  2. Implemented in a development/master environment.
  3. Fingerprinted.
  4. Compared with its predecessor.
  5. Tested.
  6. Documented.
  7. Published.
  8. Verified from a newly instantiated VM.

Version identification

Each maintained baseline and VM Stack should eventually have a repository identifier independent of the operating-system version.

Recommended pattern:

<cvd-or-stack-id>-<YYYY-MM-DD>

or:

<cvd-or-stack-id>-<SemVer>

{{Select the canonical baseline and VM Stack versioning convention.}}

Historical records

Previous fingerprints and baseline specifications should normally be retained rather than overwritten.

This allows the repository to answer questions such as:

  • When did the operating system change?
  • Which VM Stack introduced a package?
  • Which course version used a particular environment?
  • Did a problem begin after an operating-system update?
  • Which local VM configuration corresponds to an older course deployment?

Security and Privacy

Fingerprinting tools operate on real faculty and student environments and must be designed conservatively.

Do not collect credentials

Fingerprinting scripts should not intentionally collect:

  • Passwords.
  • Authentication tokens.
  • Browser profiles.
  • Browser cookies.
  • GitHub CLI credential stores.
  • SSH private keys.
  • Cloud credentials.
  • Secret-service or desktop-keyring contents.
  • Application credential databases.

Minimize personal information

Fingerprint output should avoid or redact unnecessary:

  • Email addresses.
  • Usernames not required for technical analysis.
  • Authentication identifiers.
  • Public IP addresses when unnecessary.
  • Machine-specific identifiers.
  • Session identifiers.
  • Course or student data.

Review before sharing

Automated redaction is a safeguard, not a guarantee.

Caution

Every fingerprint directory must be reviewed before it is committed to this repository, attached to a support request, or shared outside its intended technical audience.

File permissions

Fingerprinting utilities should use restrictive permissions for generated output whenever practical.

Published VM Stack credentials

Credentials, authenticated browser sessions, private keys, personal account information, tokens, and password stores must not be intentionally included in a VM Stack intended for other faculty or students.

{{Document the approved VM Stack credential-sanitization and pre-publication verification procedure.}}

Contributing

Contributions should improve the reproducibility, accuracy, or understanding of the CVD environment.

Useful contributions include:

  • Fresh baseline fingerprints.
  • Course VM Stack fingerprints.
  • Environment comparisons.
  • Corrected provenance classifications.
  • Local VM configurations.
  • Provisioning scripts.
  • Verification scripts.
  • Documentation.
  • Confirmed CVD limitations.
  • Codio documentation references.

Evidence requirements

When adding a technical claim, identify the strongest available evidence.

Preferred source order is:

  1. Official Codio documentation or information supplied directly by Codio.
  2. Direct controlled observation of an untouched Codio environment.
  3. Official Ubuntu/Canonical or AWS documentation.
  4. Reproducible fingerprints from deployed CVDs.
  5. Multiple corroborating CVD fingerprints.
  6. Other reputable technical sources.
  7. Inference, clearly labeled as such.

Fingerprint submissions

Before committing a fingerprint:

  • Use the current fingerprinting script.
  • Start from the cleanest environment available.
  • Record the course and VM Stack context.
  • Record the collection date.
  • Record whether operating-system updates have been applied.
  • Review every generated file for sensitive information.
  • Preserve generated checksums.
  • Do not edit raw fingerprint artifacts except for documented redaction.

{{Define the final contribution and pull-request workflow.}}

Open Baseline Questions

The following questions remain unresolved and are intentionally documented rather than answered by assumption:

  • What Ubuntu release is currently contained in an untouched codio-aws-ubuntu-base image?
  • What is the current AWS AMI ID corresponding to codio-aws-ubuntu-base?
  • Is the Codio Ubuntu AMI publicly accessible from AWS, or only through Codio-managed infrastructure?
  • What is the oldest available historical Ubuntu Codio AMI?
  • Which desktop environment and VNC components are supplied directly by Codio?
  • Which packages are included in the untouched Ubuntu Codio AMI?
  • Which services are Codio-specific?
  • Which AWS agents are intentionally required by Codio?
  • Which changes in the IT 140 fingerprint originated from its published VM Stack?
  • Which changes resulted from subsequent APT maintenance?
  • Does Codio periodically replace the underlying Ubuntu Codio AMI independently of course VM Stacks?
  • Can Codio provide AMI build/version identifiers through the UI, API, or support channel?
  • Can a newly created course or controlled assignment expose the Ubuntu Codio AMI without an organization-specific VM Stack?
  • {{Add unresolved questions discovered while comparing additional STEM CVDs.}}

References

The following authoritative sources inform this repository.

Codio

  • Codio Documentation — Virtual Machines

    • Standalone VM configuration.
    • Supported Ubuntu and Windows VMs.
    • Ubuntu Codio AMI selection.
    • VM Stack publishing.
    • Course-level VM Stack behavior.
    • VM reset behavior.
    • Ubuntu VM working directory.
    • VM integration commands.

  • Codio Documentation — Sandboxes

    • Identifies the Ubuntu AMI image name as codio-aws-ubuntu-base.
    • Documents AWS EC2 image selection concepts.
    • Documents SSH and VNC connection modes for AWS EC2 sandbox environments.

  • Codio Documentation — Stacks

    • General Codio Stack concepts.
    • Stack versions.
    • Stack ownership.
    • Stack modifications.
    • Relationship between software configuration and project environments.

  • Codio Documentation — Stack Planning

    • General recommendations for minimizing unnecessary stacks and managing stack versions.

  • Codio Documentation — Create a Stack

    • Stack creation, descriptions, components, configuration documentation, and versioning practices.

  • Codio Documentation — Installing Software Packages

    • Ubuntu APT package management.
    • Administrative access in Codio Boxes.
    • Use of pre-configured Stacks.

Note

Codio's general Stack documentation primarily describes Codio project-server Boxes. VM-specific behavior in this repository should preferentially be based on Codio's Virtual Machines documentation where the two differ.

Codio Instructor Help Center

Codio Instructor Help Center - Overview: Getting Started - Content Authoring - Developing Code - Course Configuration - Teaching in Codio - Admin

Ubuntu and Canonical

  • Ubuntu Packages — linux-aws

    • Authoritative Ubuntu package information for AWS-specific Linux kernels.
    • Useful for determining which Ubuntu repositories publish observed kernel packages.

  • Ubuntu Server documentation

    • Operating-system configuration.
    • APT package management.
    • Networking.
    • systemd.
    • Cloud-init.

Amazon Web Services

  • Amazon EC2 documentation
    • Amazon Machine Images.
    • EC2 instance types.
    • Elastic Block Store.
    • Elastic Network Adapter.
    • EC2 virtualization and instance behavior.

Empirical reference data

  • Current SNHU STEM CVD fingerprints stored in this repository.
  • Current IT 140 CVD fingerprint collected from a fresh IT 140 course instance on August 7, 2026.
  • {{Add untouched Ubuntu Codio AMI fingerprint when available.}}

Repository Status

This repository is currently under active development.

The first-stage goal is to establish enough independent evidence to distinguish:

Common Codio Linux CVD baseline
              +
Course VM Stack
              +
Runtime changes
              =
Observed course CVD

Until an untouched Ubuntu Codio AMI can be fingerprinted or its contents are authoritatively documented by Codio, baseline characteristics that cannot be independently established will remain explicitly marked as Unknown, Inferred, or {{placeholder prompts}}.

About

No description, website, or topics provided.

Resources

Readme
Activity
Custom properties

Stars

0 stars

Watchers

0 watching

Forks

0 forks
Report repository

Releases

Packages

Used by

Contributors

Languages