Merge branch 'fix/wetty' of https://github.com/opensourcecorp/worksho…

…p-linux into feature/iam-instance-profile

.github/workflows/main.yaml

@@ -2,21 +2,20 @@ name: main
 
 on:
   push:
-    branches: ['**']
+    branches: ["**"]
 
 jobs:
   main:
     runs-on: ubuntu-latest
 
     steps:
-    - name: Checkout repository
-      uses: actions/checkout@v4
+      - name: Checkout repository
+        uses: actions/checkout@v4
 
-    - name: Set up Go 1.19+
-      uses: actions/setup-go@v4
-      with:
-        go-version: '>=1.19'
+      - name: Set up Go 1.19+
+        uses: actions/setup-go@v4
+        with:
+          go-version: ">=1.19"
 
-    # Linux workshop
-    - name: CI
-      run: 'cd ./linux && bash ./scripts/ci.sh'
+      - name: CI
+        run: "bash ./scripts/ci.sh"

.pre-commit-config.yaml

@@ -0,0 +1,31 @@
+repos:
+- repo: https://github.com/pre-commit/pre-commit-hooks
+  rev: v4.6.0
+  hooks:
+    # Git style
+    - id: check-added-large-files
+    - id: check-merge-conflict
+    - id: check-vcs-permalinks
+    - id: forbid-new-submodules
+    - id: no-commit-to-branch
+
+    # Common errors
+    - id: end-of-file-fixer
+    - id: trailing-whitespace
+      args: [--markdown-linebreak-ext=md]
+      exclude: CHANGELOG.md
+    - id: check-yaml
+    - id: check-merge-conflict
+    - id: check-executables-have-shebangs
+
+- repo: https://github.com/jumanjihouse/pre-commit-hooks
+  rev: 3.0.0
+  hooks:
+    - id: shfmt
+      args: ['-l', '-i', '2', '-ci', '-sr', '-w']
+    - id: shellcheck
+- repo: https://github.com/antonbabenko/pre-commit-terraform
+  rev: 1.92.1
+  hooks:
+    - id: terraform_fmt
+    - id: terraform_docs

linux/Makefile → Makefile

@@ -15,6 +15,9 @@ yeet-aws:
 	@printf 'Waiting 30s for EC2 instances to hopefully process userdata...\n' && sleep 30
 	@make -s provision-aws
 
+connect-aws:
+	ssh -p 2332 admin@$(shell terraform -chdir=./terraform output -json | jq -r '.instance_ips.value[]')
+
 provision-local:
 # Don't re-provision DB at the same time, since it throws off team server tests
 	@vagrant provision db

README.md

@@ -1,4 +1,42 @@
-Workshops, Hackathons, etc
-==========================
+Linux System Breakfixing
+========================
 
-This repository houses workshop, etc. content put on by OpenSourceCorp.
+In this workshop, teams will work to fix the broken deployment of an application
+running on a Linux server.
+
+System Requirements
+-------------------
+
+Note that this workshop content was authored on a Debian Linux machine, and so
+the various scripts & utilities are written in support of that. There may be a
+few instances of code that is non-portable to BSDs like macOS, but should work
+fine on WSL.
+
+---
+
+As a ***workshop administrator***, you will need the following:
+
+- A terminal emulator capable of running the `bash` shell program
+
+- [HashiCorp Terraform](https://terraform.io) (if running workshop on a cloud
+  platform)
+
+- x
+
+In addition, for local testing you will need [HashiCorp
+Vagrant](https://www.vagrantup.com/), and at least one installation of a
+supported Vagrant provider. At the time of this writing, those supported
+providers were VirtualBox and `libvirt`. If on WSLv2 on Windows, you will have a
+MUCH easier time using the `libvirt` provider.
+
+---
+
+***Workshop participants*** will need the following:
+
+- An SSH client
+  - On Windows, this is typically `puTTY` as a standalone tool, or Git Bash or
+    WSL. macOS should already have the `ssh` client program installed.
+  - Note: participants will ***not*** need knowledge of SSH key management, etc.
+    -- auth to the team servers will be password-based.
+
+- Little enough knowledge of Linux OSes to not figure out how to cheat `:)`

linux/instructions/challenge_1.md → instructions/challenge_1.md

@@ -11,3 +11,5 @@ a Go binary.
 
 Take note of any error messages when trying to build it, and fix any issues you
 find.
+
+(NOTE: the built application needs to be named `app`, NOT `main`)

linux/instructions/challenge_4.md → instructions/challenge_4.md

@@ -24,4 +24,5 @@ look at the `/opt/app` directory again, you may have noticed that there is a
   correctly-installed app binary.
 
 Once you do that, be sure to check the `systemd` and/or `journald` logs of the
-new `app-deb.service` to make sure it's running successfully!
+new `app-deb.service` to make sure it's running successfully! (and, just like
+the last one, that it would keep running after a reboot)

linux/instructions/challenge_5.md → instructions/challenge_5.md

@@ -20,7 +20,9 @@ number is:
 
 1. Higher than `6000`
 
-1. *Not* `8080`
+2. *Not* `8080`
+
+3. *Not* managed by the `iptables` tool.
 
 Finally, you will want to figure out what firewall issue your own server has
 that seems to be causing problems, and fix it.

instructions/challenge_6.md

@@ -0,0 +1,20 @@
+Challenge 6: Git SSH Setup
+==========================
+
+We just got hired by a very famous movie star (who's name may not be disclosed)
+to create a new version of our app for their specific use case. Our lead
+engineers were working on putting together the new app, but they mysteriously
+dissappeared while on a golfing trip a few weeks past. We were told that the
+code was about ready to deploy, just hadn't gotten the chance to merge it into
+the main branch. See if you can figure out how to get it up and running.
+
+The name of the app is 'carrot-cruncher'. The last dev got the repo set up
+somewhere on disk, but they never said where... hopefully you'll able to find
+it. When you do, supposedly there was a new working branch pushed to the remote
+repo, so you'll need to figure out how to authenticate to that repo.
+
+There was a note in your team's documentation about a process that picks up keys
+in the local git server. Supposedly all you had to do was copy some file to the
+'ssh-keys/' directory near all the repos and git takes it from there? So I guess
+try that? Then clone the remote branches down, then you'll be off to the
+races... Good luck!

instructions/challenge_7.md

@@ -0,0 +1,8 @@
+Challenge 7: Git branch management
+==================================
+
+Great, now that you've got your SSH keys set up, you'll need to figure out which
+of those remote branches have the correct changes it get it merged in ASAP. Once
+you clone the repo, the working branch should be obvious... or so we were
+told... So we recommend you just try looking at/running the code the the
+different branches and see which one fits.