docs: remove prompt symbols from shell snippets

Remove prompt symbols (`$`, `%`) for ease of copy-pasting

Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
This commit is contained in:
Akihiro Suda
2024-10-29 01:38:24 +09:00
parent 4ad9f7fd36
commit c8f5d033c2
4 changed files with 34 additions and 34 deletions
+2 -2
View File
@@ -24,8 +24,8 @@ but for most users the security benefit is identical.
The provided `memfd-bind@.service` file can be used to get systemd to manage
this daemon. You can supply the path like so:
```
% systemctl start memfd-bind@$(systemd-escape -p /usr/bin/runc)
```bash
systemctl start memfd-bind@$(systemd-escape -p /usr/bin/runc)
```
Thus, there are three ways of protecting against CVE-2019-5736, in order of how
+11 -11
View File
@@ -34,18 +34,18 @@ The recommended systemd version is 244 or later. Older systemd does not support
Make sure you also have the `dbus-user-session` (Debian/Ubuntu) or `dbus-daemon` (CentOS/Fedora) package installed, and that `dbus` is running. On Debian-flavored distros, this can be accomplished like so:
```console
$ sudo apt install -y dbus-user-session
$ systemctl --user start dbus
```bash
sudo apt install -y dbus-user-session
systemctl --user start dbus
```
## Rootless
On cgroup v2 hosts, rootless runc can talk to systemd to get cgroup permissions to be delegated.
```console
$ runc spec --rootless
$ jq '.linux.cgroupsPath="user.slice:runc:foo"' config.json | sponge config.json
$ runc --systemd-cgroup run foo
```bash
runc spec --rootless
jq '.linux.cgroupsPath="user.slice:runc:foo"' config.json | sponge config.json
runc --systemd-cgroup run foo
```
The container processes are executed in a cgroup like `/user.slice/user-$(id -u).slice/user@$(id -u).service/user.slice/runc-foo.scope`.
@@ -60,11 +60,11 @@ memory pids
To allow delegation of other controllers, you need to change the systemd configuration as follows:
```console
# mkdir -p /etc/systemd/system/user@.service.d
# cat > /etc/systemd/system/user@.service.d/delegate.conf << EOF
```bash
sudo mkdir -p /etc/systemd/system/user@.service.d
cat <<EOF | sudo tee /etc/systemd/system/user@.service.d/delegate.conf
[Service]
Delegate=cpu cpuset io memory pids
EOF
# systemctl daemon-reload
sudo systemctl daemon-reload
```
+8 -8
View File
@@ -35,8 +35,8 @@ descriptors to preserve. Instead, it takes how many file descriptors (not
including `stdio` or `LISTEN_FDS`) should be passed to the container. In the
following example:
```
% runc run --preserve-fds 5 <container>
```bash
runc run --preserve-fds 5 <container>
```
`runc` will pass the first `5` file descriptors (`3`, `4`, `5`, `6`, and `7` --
@@ -46,8 +46,8 @@ In addition to `--preserve-fds`, `LISTEN_FDS` file descriptors are passed
automatically to allow for `systemd`-style socket activation. To extend the
above example:
```
% LISTEN_PID=$pid_of_runc LISTEN_FDS=3 runc run --preserve-fds 5 <container>
```bash
LISTEN_PID=$pid_of_runc LISTEN_FDS=3 runc run --preserve-fds 5 <container>
```
`runc` will now pass the first `8` file descriptors (and it will also pass
@@ -136,8 +136,8 @@ not a terminal (some `ssh` implementations only look for a terminal on stdin).
Another way is to run runc under the `script` utility, like this
```console
$ script -e -c 'runc run <container>'
```bash
script -e -c 'runc run <container>'
```
[tty_ioctl(4)]: https://linux.die.net/man/4/tty_ioctl
@@ -150,8 +150,8 @@ the contained process (this is not necessarily the same as `--preserve-fds`'s
passing of file descriptors -- [details below](#runc-modes)). As an example
(assuming that `terminal: false` is set in `config.json`):
```
% echo input | runc run some_container > /tmp/log.out 2> /tmp/log.err
```bash
echo input | runc run some_container > /tmp/log.out 2> /tmp/log.err
```
Here the container's various `stdio` file descriptors will be substituted with
+13 -13
View File
@@ -15,20 +15,20 @@ framework.
## Running integration tests
The easiest way to run integration tests is with Docker:
```
$ make integration
```bash
make integration
```
Alternatively, you can run integration tests directly on your host through make:
```
$ sudo make localintegration
```bash
sudo make localintegration
```
Or you can just run them directly using bats
```
$ sudo bats tests/integration
```bash
sudo bats tests/integration
```
To run a single test bucket:
```
$ make integration TESTPATH="/checkpoint.bats"
```bash
make integration TESTPATH="/checkpoint.bats"
```
@@ -36,11 +36,11 @@ To run them on your host, you need to set up a development environment plus
[bats (Bash Automated Testing System)](https://github.com/bats-core/bats-core#installing-bats-from-source).
For example:
```
$ cd ~/go/src/github.com
$ git clone https://github.com/bats-core/bats-core.git
$ cd bats-core
$ ./install.sh /usr/local
```bash
cd ~/go/src/github.com
git clone https://github.com/bats-core/bats-core.git
cd bats-core
./install.sh /usr/local
```
> **Note**: There are known issues running the integration tests using