You will do most work in this course by logging into remote Linux systems and running commands in a shell. This assignment prepares you for that workflow using the UIC CS Linux systems you already have access to.

You will:

  • Record a terminal session and commit it
  • Verify SSH works and collect a remote probe report
  • Create a Python virtual environment, install dependencies with pip, and freeze requirements
  • Complete a small Python script that reads, transforms, and writes a file

These skills are required for every programming assignment in this course.

Objective and Expected Learning Outcomes

By completing this assignment, you will be able to:

  1. Use core shell commands to orient yourself, inspect files, and validate results.
  2. Verify SSH works and run commands on a remote Linux system.
  3. Create and use a Python virtual environment (venv).
  4. Install third-party packages using pip and capture dependencies in requirements.txt.
  5. Produce and commit a session log as evidence of your workflow.
  6. Submit work using the development branch and a pull request into main.

Remote Systems

For this assignment, you must use one of the UIC system resources to do your work and a different system resource to run the SSH probe. Choose from the following UIC CS system resources are available to you:

  • systems1.cs.uic.edu
  • systems2.cs.uic.edu
  • systems3.cs.uic.edu
  • systems4.cs.uic.edu
  • cs494.cs.uic.edu

Grading is performed on cs494.cs.uic.edu, so your repository must run correctly there.

Note: Although not directly part of the assignment, you should ensure that SSH key-based access from your local machine (for example, your desktop or laptop) works with these remote systems. Having SSH keys properly set up will significantly simplify your development workflow throughout the course.

Shell Choice

Use any shell you want for interactive work (bash, zsh, tcsh, etc.) as long as it is available on your machine.

Course rule of thumb:

  • Interactive shell is your preference.
  • Scripts in this repository are written to run with /bin/sh or explicitly choose an interpreter via a shebang.

What You Are Given

Your GitHub Classroom repository includes:

  • scripts/remoteReadiness.py (has TODOs and imports required packages)
  • scripts/recordSession.sh (records a terminal session, you run this on the system’s resource you are doing the assignment on) -‘ scripts/remoteProbe.sh (collects a remote system probe over SSH, you are probing a different system’s resource)
  • config.yaml
  • data/raw/input.txt
  • requirements.txt (placeholder)
  • remoteReadiness.txt (reflection template)

Rules

  • Do all work on the development branch.
  • Do not commit .venv.
  • Do not commit generated outputs stored in data/processed.
  • You must commit logs/remoteReadinessSession.txt.
  • You must commit logs/remoteProbe.txt.
  • You must commit logs/timing.json.
  • Do not put passwords, tokens, or private keys into any committed file.

Instructions

Follow the steps below carefully and in order.

Part A: Record Your Work

From the repository root:

chmod u+x scripts/recordSession.sh
./scripts/recordSession.sh

This starts recording to:

  • logs/remoteReadinessSession.txt
  • logs/timing.json

Do all remaining work inside the recorded session. As you complete each part, record a checkpoint using the full path:

./scripts/checkpoint.sh "Part A"

Notes:

  • scripts/checkpoint.sh and scripts/finish.sh are created by recordSession.sh and are available while the recording session is active.
  • Do not assume checkpoint or finish are in your PATH. Always use ./scripts/checkpoint.sh and ./scripts/finish.sh.

You may pause the session by typing exit. To resume later:

./scripts/recordSession.sh --resume

When you are completely finished, finalize the session and then exit:

./scripts/finish.sh
exit

If you accidentally record sensitive information, edit logs/remoteReadinessSession.txt before committing.

Part B: Orientation Commands

Run and inspect the output of:

pwd
ls -lah
git status

Search and inspect repository contents:

grep -R -n "TODO" scripts
wc -l data/raw/input.txt
head -n 2 data/raw/input.txt
tail -n 2 data/raw/input.txt

Part C: SSH Setup and Remote Probe

This part requires key-based SSH login. The remote probe script runs SSH in non-interactive mode (it will not prompt for a password). If you cannot SSH to the target host without a password prompt, the probe step will fail.

Step C1: Ensure SSH keys exist

Check for an existing SSH key:

ls -lah ~/.ssh

If no id_ed25519 key exists, generate one:

ssh-keygen -t ed25519

Step C2: Install your SSH public key on the remote host

Pick one tested system (systems1, systems2, systems3, systems4, cs494) that is not the machine you are currently logged into.

Recommended (if available):

ssh-copy-id <netid>@cs494.cs.uic.edu

If ssh-copy-id is not available, use this manual method:

cat ~/.ssh/id_ed25519.pub | ssh <netid>@cs494.cs.uic.edu 'mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys'

Step C3: Test passwordless SSH access (required)

You must test SSH access on the same systems machine where you installed your key in Step C2.
The test must be performed on one of the approved systems machines:

systems1, systems2, systems3, systems4, or cs494.

This command must succeed without prompting for a password:

ssh <netid>@cs494.cs.uic.edu

Once logged in, verify basic access:

hostname
uname -a
exit

If SSH prompts for a password, your key was not installed correctly or was installed on a different machine. Repeat Step C2 and test again.

Step C4: Generate a remote probe report

Make the probe script executable:

chmod u+x scripts/remoteProbe.sh

Run the probe and capture its output from the same systems machine used in Steps C2 and C3:

./scripts/remoteProbe.sh cs494.cs.uic.edu > logs/remoteProbe.txt

This command assumes your local username matches your UIC NetID. If it does not, specify the username explicitly:

./scripts/remoteProbe.sh <netid>@cs494.cs.uic.edu > logs/remoteProbe.txt

The file logs/remoteProbe.txt is required for submission.

If the command exits immediately or produces an empty file, the most common cause is that passwordless SSH is not working yet (repeat Steps C2 and C3).

Part D: Python venv and pip Workflow

Step D1: Observe the initial failure

python3 scripts/remoteReadiness.py

You should see an import error for yaml or rich. This is expected.

Step D2: Create and activate a venv

python3 -m venv .venv
. .venv/bin/activate

Verify the environment:

which python
python --version
python -m pip --version

Step D3: Install dependencies

python -m pip install -U pip wheel
pip install pyyaml rich

Re-run:

python scripts/remoteReadiness.py

The import error should now be gone, but the script will not be correct until you complete the TODOs.

Step D4: Complete the TODOs in scripts/remoteReadiness.py

There are three places in the Python script marked with TODO comments. Each one must be completed exactly as described below.

TODO 1: loadConfig function (around line 30)

This function receives a path to the config.yaml file, but currently returns an empty dictionary. You must read and parse the YAML configuration file.

What to do:

  • Use configPath.read_text(encoding="utf-8") to read the file contents
  • Use yaml.safe_load() to parse the YAML text into a Python dictionary
  • Return the resulting dictionary

The hint in the code shows the exact one-liner you need.

TODO 2: transformText function (around line 37)

This function receives input text and a mode string, but currently returns the text unchanged. You must transform the text based on the mode.

What to do:

  • If mode is "upper", return text.upper()
  • If mode is "lower", return text.lower()
  • If mode is anything else, raise a ValueError, for example: raise ValueError(f"Invalid mode: {mode}")

TODO 3: main function (around line 50-52)

The mode and outputPath variables are currently hardcoded. You must read these values from the parsed configuration dictionary.

What to do:

  • Replace the hardcoded mode with mode = config["mode"]
  • Replace the hardcoded output path with outputPath = Path(config["outputPath"])

The config.yaml file contains keys such as mode and outputPath that your script must use.

When the script works correctly:

head -n 5 data/processed/output.txt

Do not commit data/processed/output.txt.

Step D5: Freeze requirements

pip freeze > requirements.txt

Part E: Reflection and Submission

  1. Fill out remoteReadiness.txt with your name, date, certification, and reflection paragraph.

  2. Ensure the recording is finalized:

./scripts/finish.sh
exit
  1. Confirm required files exist:
ls -lah logs

You must have:

  • logs/remoteReadinessSession.txt
  • logs/remoteProbe.txt
  • logs/timing.json
  1. Commit and push:
git status
git add scripts/remoteReadiness.py requirements.txt remoteReadiness.txt logs/remoteReadinessSession.txt logs/remoteProbe.txt logs/timing.json
git commit -m "Complete Remote Readiness assignment"
git push -u origin development
  1. Open a pull request from development into main. Do not merge it.

Submission Requirements

To receive credit, you must:

  1. Accept the GitHub Classroom assignment.
  2. Work on the development branch.
  3. Complete scripts/remoteReadiness.py.
  4. Generate logs/remoteProbe.txt via SSH.
  5. Record your session and timing data.
  6. Freeze requirements.txt.
  7. Complete remoteReadiness.txt.
  8. Push your work to development.
  9. Open a pull request into main.

Evaluation Criteria

You will receive full credit if:

  1. Your repository exists and is linked to GitHub Classroom.
  2. A development branch exists with commits.
  3. scripts/remoteReadiness.py runs successfully on cs494.cs.uic.edu after pip install -r requirements.txt.
  4. requirements.txt includes PyYAML and rich.
  5. logs/remoteProbe.txt exists and shows remote system probe output.
  6. logs/remoteReadinessSession.txt exists and shows a reasonable session transcript.
  7. logs/timing.json exists and shows timing data.
  8. remoteReadiness.txt is filled out with name, date, certification, and reflection.
  9. A pull request from development to main is open.
  10. .venv and data/processed are not committed.

Additional Resources

  • Git Documentation - Documentation for Git, including detailed explanations of commands, workflows, and concepts. This is the authoritative reference for understanding how Git works under the hood.
  • GitHub Docs - Comprehensive documentation for using GitHub features such as repositories, branches, pull requests, issues, and authentication. This is especially useful for understanding the GitHub web interface.
  • Python venv Documentation - Python documentation for creating and managing virtual environments using venv.
  • pip Documentation - Documentation for pip, covering package installation, dependency management, and common workflows.