Revised init-background.sh for authors of challenges that upgrade to Solver version 0.5.4+

init-background.sh

#!/bin/bash

# Log script activity (https://serverfault.com/a/103569)
exec 3>&1 4>&2
trap 'exec 2>&4 1>&3' 0 1 2 3
exec 1>/var/log/init-background.log 2>&1
set -x

# Add any installations or configurations here that the scenario may need
# 

# Common curl switches
echo '-s' >> ~/.curlrc

# =========================
# Do not modify lines below

# The Solver command-line tool cannot be committed to each challenge and installed via assets. Mostly because
# scenarios limit the asset size to below 10Mb. Instead, this script downloads the solver utility from a public source.
# The version of the solver release should be the exact version the author testing the scenario with. Authors are
# encourage to periodically upgrade the solver release when new ones are available.
#
# Each time a scenario starts, this script is called from the background script (init-background.sh). If the solver
# download fails the scenario will not work correctly. To greatly reduce this risk, the download of
# the same version of solver comes from two independent sources:
#
# 1) GitHub container registry
# 2) GitHub solver release page
#
# The two sources are still related to GitHub, but they are different storage services. The latter is less reliable
# than the container registry.

# The 'solver create' command will install this script and ensure this version matches the utilized solver version.
SOLVER_VERSION=0.5.4      ##  <--- Make sure this is the latest release - https://github.com/javajon/katacoda-solver/releases

function verify_solver_install() {
  solver --version | grep $SOLVER_VERSION
  return $?
}

# First download request - download container image, create it, copy solver out of the container, delete container
SOLVER_CONTAINER_IMAGE=ghcr.io/javajon/solver
verify_solver_install
if [ $? -ne 0 ]; then
  ID=$(docker create $SOLVER_CONTAINER_IMAGE:$SOLVER_VERSION)
  docker cp "$ID":/application /usr/local/bin/solver

  verify_solver_install
  if [ $? -ne 0 ]; then
    echo "Failed to download solver from $SOLVER_CONTAINER_IMAGE:$SOLVER_VERSION"

    # Second download request - download solver linux binary from release page
    RELEASE="https://github.com/javajon/katacoda-solver/releases/download/$SOLVER_VERSION/solver-$SOLVER_VERSION-runner"
    wget -q -O solver $RELEASE
    chmod +x solver
    mv solver /usr/local/bin/

    verify_solver_install
    if [ $? -ne 0 ]; then
      echo "Failed to download solver from github release page: $RELEASE"
      # init-foreground displays messsage on linux prompt that there is a problem.
    fi
  fi

fi

# Signal to challenge controller that the startup is complete
echo 'done' > /opt/katacoda-background-finished

# Signal to init-foreground.sh that the startup is complete
echo 'done' > /opt/.backgroundfinished

@javajon I am using a custom VM image for my classes, and because of that I am pre-installing solver in the VM. It might be worth updating lines 43-44 to look something like this:

verify_solver_install
if [ $? -ne 0 ]; then
  ID=$(docker create $SOLVER_CONTAINER_IMAGE:$SOLVER_VERSION)
  docker cp "$ID":/application /usr/local/bin/solver
fi

So that you handle the situation where the right version is already installed.

If preinstalled, why have lines 18-61 in your scenario?

I just figured that this keeps my script closer to your recommendations, and it can still be used to update solver on the VM if I want/need to update the solver version more frequently then it is practical to rebuild the VM image and get O'Reilly to publish it.

True. Adjusted. We're considering hosting the binary in an apt registry to avoid the slower container download into a scenario just to obtain the solver binary.