This is a puppet configuration for various SRComp related things, including the creation of a VM suitable for use at a competition event.
In particular, this configures the hosting of:
- SRComp HTTP
- SRComp Stream
- SRComp Screens
- An index page which links to the hosted services
An srcomp user is created which has access to update the compstate deployed
within the machine; this user is a suitable target for the
srcomp deploy command (and its siblings). Access to this user
over SSH is granted by adding public keys to
modules/compbox/files/srcomp-authorized_keys.
A Vagrantfile and top-level manifest are provided for local development using
Vagrant. This creates an Ubuntu based VM with port 80 forwarded to
port 8080 on the host machine. Visiting http://localhost:8080 on the host
should show a compbox welcome page once the VM is provisioned.
Note: since deployment of the vagrant box is a supported (but discouraged)
scenario, the Vagrantfile compensates for the removal of the insecure vagrant
public key SSH access by expecting that config.ssh.private_key_path will
include a private key whose public key has been added to
modules/compbox/files/main-user-authorized_keys.
Deployment is supported via three mechanisms:
- to a VM (setup instructions)
- under vagrant (note: this is discouraged)
- using a Raspberry Pi
Note that the default (insecure) credential-based access over ssh to the default
user (as well as root) are disabled. For the VM setup you should configure
your own admin account (the instructions guide doing this). For other two cases,
access to the main user is available via SSH using keys whose public keys are in
modules/compbox/files/main-user-authorized_keys.
However you run it, the compbox will provide the following services. These will all be allowed through its firewall, though if you are going to put it behind a proxy of any kind you'll need to ensure access to all of these is available:
SSH(needed for compstate deployment)NTP(to keep the screens clocks in sync)HTTPS(for the API, stream and hosted pages)
Note that, for the hosted VM case only, TLS is automatically configured via
Let's Encrypt. As a result in general there should be no need to put the compbox
behind a proxy. However such configurations do therefore also need insecure
HTTP access (which is used to bootstrap the HTTPS configuration).
The default state of a fresh machine is configured around the dummy compstate. Therefore the first time you deploy your own compstate you may get a warning that the compstate being deployed isn't related to the current deployment. This is obviously expected on your first deploy, but should be carefully regarded thereafter.
No attempt is made to test the puppet configuration directly. Instead, running
instances can be validated using scripts/check-pages.py. This downloads the
index page from the compbox and validates that all the pages which that links to
are accessible.
Note: this does not validate SSH or NTP access.
Once deployed it is possible to update a deployment using:
/etc/puppet/scripts/updateAt the test day we had an issue where even after enabling public_network
mode the VM still wasn't visible outside the host as it didn't get an IPv4
address for reasons unknown. This was solved on the test day by using
https://github.com/vinodpandey/python-port-forward to do port forwarding
on the host machine, and then just hitting the host instead of the VM
directly, which may well be a suitable solution if needed.