|
|
This page contains basic operations and tips for building and using a sandbox. If you do not have an _intermediate definition_, check the page [Generating a Sandbox](3.0/Generating%20a%20Sandbox).
|
|
|
|
|
|
# Sandbox Manager
|
|
|
|
|
|
The Sandbox Manager is a command-line script that manages the sandbox building process. After successfully installing CSC, the Sandbox Manager can be accessed from any location as `manage-sandbox`. It is a wrapper for Vagrant. Vagrant can also be used directly to manage sandboxes in most cases.
|
|
|
|
|
|
```
|
|
|
manage-sandbox [-h] [-d SANDBOX_DIRECTORY]
|
|
|
[-m [MACHINES [MACHINES ...]]] [-v]
|
|
|
[--ansible-vars ANSIBLE_VARS] [-o {devnull,stdout}]
|
|
|
[-e {devnull,stdout}]
|
|
|
{build,destroy,access,suspend,resume,shutdown,reload}
|
|
|
```
|
|
|
Sandbox Manager has multiple commands. As the first mandatory argument, it expects a command's name. The commands are:
|
|
|
|
|
|
| Command | Description |
|
|
|
| :---: | :--- |
|
|
|
| `build` | Instantiates the sandbox or a virtual machine from an intermediate definition. It also turns on a virtual machine shut down using the `shutdown` command. |
|
|
|
| `destroy` | Destroys an instance of a sandbox. |
|
|
|
| `access` | Accesses a particular virtual machine of the sandbox using SSH. Only one target machine can be accessed at a time (see `-m`)|
|
|
|
| `suspend` | Suspends a running sandbox or virtual machine. It saves the internal state of all affected virtual machines. |
|
|
|
| `resume` | Resumes a suspended sandbox or a virtual machine, and restores its previous internal state. |
|
|
|
| `shutdown` | Shuts down a sandbox or a virtual machine. |
|
|
|
| `reload` | Restarts the sandbox or a virtual machine. (shutdown+build) |
|
|
|
|
|
|
Every command has additional options (mostly optional):
|
|
|
|
|
|
| Short | Long | Description |
|
|
|
| :---: | :---: | :--- |
|
|
|
| `-d` | `--sandbox-directory` | Path to the intermediate definition directory (where the Vagrantfile is located). If it is not specified, the current working directory is used as the sandbox directory. |
|
|
|
| `-m` | `--machines` | List of virtual machine names the command should be applied to. If no machine is specified, all machines of the sandbox will be affected. The `access` command expects exactly one machine (there is no default in this case). |
|
|
|
| `-v` | `--verbose` | Shows the output of Vagrant and Ansible on the command-line. |
|
|
|
| | `--ansible-vars` | Variables can be specified for Ansible. Expects a string of variable names and values (`var1:val1;var2:val2`). This feature does not work on intermediate definitions generated with CSC 2.0.1 or less. |
|
|
|
| `-o` | `--out` | Where the command-line output should go. Possible values are `devnull` or `stdout` (default) |
|
|
|
| `-e` | `--err` | Where the error output should go. Possible values are `devnull` or `stdout` (default) |
|
|
|
|
|
|
# Vagrant
|
|
|
|
|
|
Since the Sandbox Manager provides only limited functionality, Vagrant can also be used for advanced features. The sandbox can be managed entirely using Vagrant commands, but some features may not be available without the Sandbox Manager in the future. (Currently only the `--ansible-vars` option has such limitations.)
|
|
|
|
|
|
After building the virtual machines with `vagrant up`, here is a list of commands that might be useful. All commands must be run from the directory containing the Vagrantfile (the intermediate definition directory).
|
|
|
|
|
|
* `vagrant status` lists all virtual machines and their status
|
|
|
* `vagrant destroy -f` destroys all virtual machines
|
|
|
* `vagrant destroy device_name -f` destroys the virtual machine `device_name`
|
|
|
* `vagrant up device_name` creates only the machine `device_name`
|
|
|
* `vagrant ssh device_name` connects to the virtual machine `device_name` using SSH (keys are handled automatically by Vagrant)
|
|
|
|
|
|
For more Vagrant commands, visit the [Vagrant documentation](https://www.vagrantup.com/docs/cli) page.
|
|
|
|
|
|
**Important**: Do not change the Vagrantfile while the virtual machines are running. Destroy all machines before any change. Changing the Vagrantfile while the machines are up may cause that Vagrant could not destroy them automatically afterward (using `vagrant destroy -f`). If this happens, open VirtualBox GUI and remove the virtual machines manually.
|
|
|
|
|
|
# Testing the network
|
|
|
|
|
|
After a successful `vagrant up`, you may need to test the network routing:
|
|
|
|
|
|
1. Log in to a host with `$ vagrant ssh device_name`.
|
|
|
2. Ping a host from a different network with `$ ping other_device_name`.
|
|
|
3. If the networks are connected with a router and the routing works, ping gives an output (circa every second) about the transmitted packets. If ping cannot access the other host, no such output is produced.
|
|
|
|
|
|
If the test is unsuccessful, try to restart networking with `$ sudo service networking restart` or rebuild the virtual machines (`$ vagrant destroy -f` then `$ vagrant up`).
|
|
|
|
|
|
# Complementary web portal for training delivery
|
|
|
|
|
|
If you are an instructor and need a portal for presenting task assignments, which will be completed by students in the sandbox, and checking the answers submitted by students, you may use [CTFd](https://github.com/CTFd/CTFd). We at Masaryk University successfully [deployed CTFd using Docker](https://docs.ctfd.io/docs/deployment/installation#docker) to a single VM in our cloud and used it for a homework assignment for 200 students. You can try a [live CTFd demo](https://demo.ctfd.io) to familiarize yourself with the portal. |
|
|
\ No newline at end of file |