From 063b320fd6864656e5f2894f0fec6a94f8c89f2c Mon Sep 17 00:00:00 2001 From: aisi-inspect <166920645+aisi-inspect@users.noreply.github.com> Date: Thu, 3 Oct 2024 14:02:29 +0000 Subject: [PATCH] Built site for gh-pages --- .nojekyll | 2 +- agents-api.html | 3 +- agents.html | 167 ++++++++++++++++++++++++------------------------ eval-logs.html | 2 +- index.html | 2 +- log-viewer.html | 2 +- search.json | 19 ++++-- sitemap.xml | 8 +-- tools.html | 97 +++++++++++++--------------- tutorial.html | 26 ++++---- vscode.html | 2 +- workflow.html | 2 +- 12 files changed, 168 insertions(+), 164 deletions(-) diff --git a/.nojekyll b/.nojekyll index f95ee5a4d..00bc099a0 100644 --- a/.nojekyll +++ b/.nojekyll @@ -1 +1 @@ -e5d55f6d \ No newline at end of file +fb91b253 \ No newline at end of file diff --git a/agents-api.html b/agents-api.html index b1f3f8cf8..eb1ef82a1 100644 --- a/agents-api.html +++ b/agents-api.html @@ -421,7 +421,7 @@
The state.completed
flag is automatically set to False
if max_messages
for the task is exceeded, so we check it at the top of the loop.
You can imagine several ways you might want to customise this loop:
The state.completed
flag is automatically set to False
if max_messages
for the task is exceeded, so we check it at the top of the loop.
You can imagine several ways you might want to customise this loop:
If there is a Sample setup
script it will be executed within the default sandbox environment after any Sample files
are copied into the environment. The setup
field can be either the script contents, a file path containing the script, or a base64 encoded Data URL.
The setup
script is by default interpreted as a bash script, however you can have it executed by another interpreter using a shebang comment. For example, this will be executed as a Python script:
#!/usr/bin/env python3
-
-print('hello from python')
If there is a Sample setup
bash script it will be executed within the default sandbox environment after any Sample files
are copied into the environment. The setup
field can be either the script contents, a file path containing the script, or a base64 encoded Data URL.
compose.yaml
services:
- default:
- build: .
- init: true
- command: tail -f /dev/null
- cpus: 1.0
- mem_limit: 0.5gb
- network_mode: none
services:
+ default:
+ build: .
+ init: true
+ command: tail -f /dev/null
+ cpus: 1.0
+ mem_limit: 0.5gb
+ network_mode: none
The init: true
entry enables the container to respond to shutdown requests. The command
is provided to prevent the container from exiting after it starts.
Here is what a simple compose.yaml
would look like for a local pre-built image named ctf-agent-environment
(resource and network limits excluded for brevity):
compose.yaml
services:
- default:
- image: ctf-agent-environment
- x-local: true
- init: true
- command: tail -f /dev/null
services:
+ default:
+ image: ctf-agent-environment
+ x-local: true
+ init: true
+ command: tail -f /dev/null
The ctf-agent-environment
is not an image that exists on a remote registry, so we add the x-local: true
to indicate that it should not be pulled. If local images are tagged, they also will not be pulled by default (so x-local: true
is not required). For example:
compose.yaml
services:
- default:
- image: ctf-agent-environment:1.0.0
- init: true
- command: tail -f /dev/null
services:
+ default:
+ image: ctf-agent-environment:1.0.0
+ init: true
+ command: tail -f /dev/null
If we are using an image from a remote registry we similarly don’t need to include x-local
:
compose.yaml
services:
- default:
- image: python:3.12-bookworm
- init: true
- command: tail -f /dev/null
services:
+ default:
+ image: python:3.12-bookworm
+ init: true
+ command: tail -f /dev/null
See the Docker Compose documentation for information on all available container options.
compose.yaml
services:
- default:
- image: ctf-agent-environment
- x-local: true
- init: true
- cpus: 1.0
- mem_limit: 0.5gb
- victim:
- image: ctf-victim-environment
- x-local: true
- init: true
- cpus: 1.0
- mem_limit: 1gb
services:
+ default:
+ image: ctf-agent-environment
+ x-local: true
+ init: true
+ cpus: 1.0
+ mem_limit: 0.5gb
+ victim:
+ image: ctf-victim-environment
+ x-local: true
+ init: true
+ cpus: 1.0
+ mem_limit: 1gb
The first environment listed is the “default” environment, and can be accessed from within a tool with a normal call to sandbox()
. Other environments would be accessed by name, for example:
# default sandbox environment
- sandbox() "victim") # named sandbox environment sandbox(
# default sandbox environment
+ sandbox() "victim") # named sandbox environment sandbox(
You can view more detailed logging around the creation and use of sandbox environments by using the sandbox
log level. For example:
$ inspect eval ctf.py --log-level sandbox
$ inspect eval ctf.py --log-level sandbox
The sandbox log level is just above warning
(so it will not show http
or debug
level messages).