diff options
| -rw-r--r-- | docs/tutorials/image_signing.md | 26 | ||||
| -rw-r--r-- | docs/tutorials/mac_win_client.md | 4 | ||||
| -rw-r--r-- | docs/tutorials/podman_tutorial.md | 14 | ||||
| -rw-r--r-- | docs/tutorials/remote_client.md | 18 | ||||
| -rw-r--r-- | docs/tutorials/rootless_tutorial.md | 8 |
5 files changed, 36 insertions, 34 deletions
diff --git a/docs/tutorials/image_signing.md b/docs/tutorials/image_signing.md index f0adca9af..0d1d63de2 100644 --- a/docs/tutorials/image_signing.md +++ b/docs/tutorials/image_signing.md @@ -34,7 +34,7 @@ Now let’s assume that we run a container registry. For example we could simply start one on our local machine: ```bash -> sudo podman run -d -p 5000:5000 docker.io/registry +sudo podman run -d -p 5000:5000 docker.io/registry ``` The registry does not know anything about image signing, it just provides the remote @@ -44,11 +44,11 @@ have to take care of how to distribute the signatures. Let’s choose a standard `alpine` image for our signing experiment: ```bash -> sudo podman pull docker://docker.io/alpine:latest +sudo podman pull docker://docker.io/alpine:latest ``` ```bash -> sudo podman images alpine +sudo podman images alpine REPOSITORY TAG IMAGE ID CREATED SIZE docker.io/library/alpine latest e7d92cdc71fe 6 weeks ago 5.86 MB ``` @@ -56,11 +56,11 @@ docker.io/library/alpine latest e7d92cdc71fe 6 weeks ago 5.86 MB Now we can re-tag the image to point it to our local registry: ```bash -> sudo podman tag alpine localhost:5000/alpine +sudo podman tag alpine localhost:5000/alpine ``` ```bash -> sudo podman images alpine +sudo podman images alpine REPOSITORY TAG IMAGE ID CREATED SIZE localhost:5000/alpine latest e7d92cdc71fe 6 weeks ago 5.86 MB docker.io/library/alpine latest e7d92cdc71fe 6 weeks ago 5.86 MB @@ -84,7 +84,7 @@ We can see that we have two signature stores configured: Now, let’s push and sign the image: ```bash -> sudo -E GNUPGHOME=$HOME/.gnupg \ +sudo -E GNUPGHOME=$HOME/.gnupg \ podman push \ --tls-verify=false \ --sign-by sgrunert@suse.com \ @@ -97,7 +97,7 @@ If we now take a look at the systems signature storage, then we see that there is a new signature available, which was caused by the image push: ```bash -> sudo ls /var/lib/containers/sigstore +sudo ls /var/lib/containers/sigstore 'alpine@sha256=e9b65ef660a3ff91d28cc50eba84f21798a6c5c39b4dd165047db49e84ae1fb9' ``` @@ -107,14 +107,14 @@ The default signature store in our edited version of the local staging signature store: ```bash -> sudo bash -c 'cd /var/lib/containers/sigstore && python3 -m http.server' +sudo bash -c 'cd /var/lib/containers/sigstore && python3 -m http.server' Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ... ``` Let’s remove the local images for our verification test: ``` -> sudo podman rmi docker.io/alpine localhost:5000/alpine +sudo podman rmi docker.io/alpine localhost:5000/alpine ``` We have to write a policy to enforce that the signature has to be valid. This @@ -142,13 +142,13 @@ below example, copy the `"docker"` entry into the `"transports"` section of your The `keyPath` does not exist yet, so we have to put the GPG key there: ```bash -> gpg --output /tmp/key.gpg --armor --export sgrunert@suse.com +gpg --output /tmp/key.gpg --armor --export sgrunert@suse.com ``` If we now pull the image: ```bash -> sudo podman pull --tls-verify=false localhost:5000/alpine +sudo podman pull --tls-verify=false localhost:5000/alpine … Storing signatures e7d92cdc71feacf90708cb59182d0df1b911f8ae022d29e8e95d75ca6a99776a @@ -164,14 +164,14 @@ accessed: As an counterpart example, if we specify the wrong key at `/tmp/key.gpg`: ```bash -> gpg --output /tmp/key.gpg --armor --export mail@saschagrunert.de +gpg --output /tmp/key.gpg --armor --export mail@saschagrunert.de File '/tmp/key.gpg' exists. Overwrite? (y/N) y ``` Then a pull is not possible any more: ```bash -> sudo podman pull --tls-verify=false localhost:5000/alpine +sudo podman pull --tls-verify=false localhost:5000/alpine Trying to pull localhost:5000/alpine... Error: error pulling image "localhost:5000/alpine": unable to pull localhost:5000/alpine: unable to pull image: Source image rejected: Invalid GPG signature: … ``` diff --git a/docs/tutorials/mac_win_client.md b/docs/tutorials/mac_win_client.md index 9e0798bbf..af2668e10 100644 --- a/docs/tutorials/mac_win_client.md +++ b/docs/tutorials/mac_win_client.md @@ -36,7 +36,7 @@ $ systemctl --user enable --now podman.socket You will need to enable linger for this user in order for the socket to work when the user is not logged in. ``` -$ sudo loginctl enable-linger $USER +sudo loginctl enable-linger $USER ``` You can verify that the socket is listening with a simple Podman command. @@ -55,7 +55,7 @@ host: In order for the client to communicate with the server you need to enable and start the SSH daemon on your Linux machine, if it is not currently enabled. ``` -$ sudo systemctl enable -s sshd +sudo systemctl enable --now -s sshd ``` #### Setting up SSH diff --git a/docs/tutorials/podman_tutorial.md b/docs/tutorials/podman_tutorial.md index 85b95af04..c15de67a6 100644 --- a/docs/tutorials/podman_tutorial.md +++ b/docs/tutorials/podman_tutorial.md @@ -41,7 +41,7 @@ Note: If you add *-a* to the *ps* command, Podman will show all containers. You can "inspect" a running container for metadata and details about itself. We can even use the inspect subcommand to see what IP address was assigned to the container. As the container is running in rootless mode, an IP address is not assigned and the value will be listed as "none" in the output from inspect. ```console -$ podman inspect -l | grep IPAddress\": +podman inspect -l | grep IPAddress\": "SecondaryIPAddresses": null, "IPAddress": "", ``` @@ -60,7 +60,7 @@ curl http://<IP_address>:8080 ### Viewing the container's logs You can view the container's logs with Podman as well: ```console -$ sudo podman logs --latest +podman logs --latest 10.88.0.1 - - [07/Feb/2018:15:22:11 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" 10.88.0.1 - - [07/Feb/2018:15:22:30 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" 10.88.0.1 - - [07/Feb/2018:15:22:30 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" @@ -71,7 +71,7 @@ $ sudo podman logs --latest ### Viewing the container's pids And you can observe the httpd pid in the container with *top*. ```console -$ sudo podman top <container_id> +podman top <container_id> UID PID PPID C STIME TTY TIME CMD 0 31873 31863 0 09:21 ? 00:00:00 nginx: master process nginx -g daemon off; 101 31889 31873 0 09:21 ? 00:00:00 nginx: worker process @@ -81,6 +81,8 @@ $ sudo podman top <container_id> Checkpointing a container stops the container while writing the state of all processes in the container to disk. With this a container can later be restored and continue running at exactly the same point in time as the checkpoint. This capability requires CRIU 3.11 or later installed on the system. +This feature is not supported as rootless; as such, if you wish to try it, you'll need to re-create your container as root, using the same command but with sudo. + To checkpoint the container use: ```console sudo podman container checkpoint <container_id> @@ -124,18 +126,18 @@ curl http://<IP_address>:8080 ### Stopping the container To stop the httpd container: ```console -sudo podman stop --latest +podman stop --latest ``` You can also check the status of one or more containers using the *ps* subcommand. In this case, we should use the *-a* argument to list all containers. ```console -sudo podman ps -a +podman ps -a ``` ### Removing the container To remove the httpd container: ```console -sudo podman rm --latest +podman rm --latest ``` You can verify the deletion of the container by running *podman ps -a*. diff --git a/docs/tutorials/remote_client.md b/docs/tutorials/remote_client.md index ad506d19a..e39d804a6 100644 --- a/docs/tutorials/remote_client.md +++ b/docs/tutorials/remote_client.md @@ -29,19 +29,19 @@ You will need to [install Podman](https://podman.io/getting-started/installation Before performing any Podman client commands, you must enable the podman.sock SystemD service on the Linux server. In these examples, we are running Podman as a normal, unprivileged user, also known as a rootless user. By default, the rootless socket listens at `/run/user/${UID}/podman/podman.sock`. You can enable this socket permanently using the following command: ``` -$ systemctl --user enable podman.socket +systemctl --user enable --now podman.socket ``` You will need to enable linger for this user in order for the socket to work when the user is not logged in: ``` -$ sudo loginctl enable-linger $USER +sudo loginctl enable-linger $USER ``` This is only required if you are not running Podman as root. You can verify that the socket is listening with a simple Podman command. ``` -$ podman --remote info +podman --remote info host: arch: amd64 buildahVersion: 1.16.0-dev @@ -54,13 +54,13 @@ host: In order for the Podman client to communicate with the server you need to enable and start the SSH daemon on your Linux machine, if it is not currently enabled. ``` -$ sudo systemctl enable -s sshd +sudo systemctl enable --now -s sshd ``` #### Setting up SSH Remote Podman uses SSH to communicate between the client and server. The remote client works considerably smoother using SSH keys. To set up your ssh connection, you need to generate an ssh key pair from your client machine. ``` -$ ssh-keygen +ssh-keygen ``` Your public key by default should be in your home directory under ~/.ssh/id_rsa.pub. You then need to copy the contents of id_rsa.pub and append it into ~/.ssh/authorized_keys on the Linux server. You can automate this using ssh-copy-id. @@ -75,13 +75,13 @@ The first step in using the Podman remote client is to configure a connection. You can add a connection by using the `podman-remote system connection add` command. ``` -$ podman-remote system connection add myuser --identity ~/.ssh/id_rsa ssh://192.168.122.1/run/user/1000/podman/podman.sock +podman-remote system connection add myuser --identity ~/.ssh/id_rsa ssh://192.168.122.1/run/user/1000/podman/podman.sock ``` This will add a remote connection to Podman and if it is the first connection added, it will mark the connection as the default. You can observe your connections with `podman-remote system connection list`: ``` -$ podman-remote system connection list +podman-remote system connection list Name Identity URI myuser* id_rsa ssh://myuser@192.168.122.1/run/user/1000/podman/podman.sock ``` @@ -89,7 +89,7 @@ myuser* id_rsa ssh://myuser@192.168.122.1/run/user/1000/podman/podman.s Now we can test the connection with `podman info`: ``` -$ podman-remote info +podman-remote info host: arch: amd64 buildahVersion: 1.16.0-dev @@ -101,7 +101,7 @@ host: Podman-remote has also introduced a “--connection” flag where you can use other connections you have defined. If no connection is provided, the default connection will be used. ``` -$ podman-remote system connection --help +podman-remote system connection --help ``` ## Wrap up diff --git a/docs/tutorials/rootless_tutorial.md b/docs/tutorials/rootless_tutorial.md index 3b9cbd2d0..9d8851bc8 100644 --- a/docs/tutorials/rootless_tutorial.md +++ b/docs/tutorials/rootless_tutorial.md @@ -6,14 +6,14 @@ Prior to allowing users without root privileges to run Podman, the administrator ## cgroup V2 support -The cgroup V2 Linux kernel feature allows the user to limit the amount of resources a rootless container can use. If the Linux distribution that you are running Podman on is enabled with cgroup V2 then you might need to change the default OCI Runtime. The default runtime `runc` does not currently work with cgroup V2 enabled systems, so you have to switch to the alternative OCI runtime `crun`. +The cgroup V2 Linux kernel feature allows the user to limit the amount of resources a rootless container can use. If the Linux distribution that you are running Podman on is enabled with cgroup V2 then you might need to change the default OCI Runtime. Some older versions of `runc` do not work with cgroup V2, you might have to switch to the alternative OCI runtime `crun`. -The alternative OCI runtime support for cgroup V2 can be turned on at the command line by using the `--runtime` option: +The alternative OCI runtime support for cgroup V2 can also be turned on at the command line by using the `--runtime` option: ``` -sudo podman --runtime /usr/bin/crun +podman --runtime crun ``` -or by changing the value for the "Default OCI runtime" in the containers.conf file either at the system level or at the [user level](#user-configuration-files) from `runtime = "runc"` to `runtime = "crun"`. +or for all commands by changing the value for the "Default OCI runtime" in the containers.conf file either at the system level or at the [user level](#user-configuration-files) from `runtime = "runc"` to `runtime = "crun"`. ## Administrator Actions |