Quadlet containers are managed by using a unit file with the .container file extension. It must also contain a [Container] section, for example:

[Unit]
Description=your-description
After=local-fs.target

[Container]
Image=container-registry.oracle.com/os/oraclelinux:8-slim
Exec=your-command-here

[Install]
# Start by default on boot
WantedBy=multi-user.target default.target

To create a Quadlet container that runs with root permissions, store that .container file in either of the /usr/share/containers/systemd/ or /etc/containers/systemd/ directories, and then reload Systemd services:

sudo systemctl daemon-reload

To create a Quadlet container that runs with standard user permissions, administrators can create quadlet files in the /etc/containers/systemd/users/${USER_ID} directory for each individual user, or individual users can store .container files in their' $HOME/.config/containers/systemd/ directory, and then reload Systemd services:

systemctl --user daemon-reload

To examine the unit files that have been created, you can use the -dryrun option with the quadlet command:

/usr/libexec/podman/quadlet -dryrun

Add the -user option for Quadlet containers that run without root permissions.

You can now manage the Quadlet the same way as any other Systemd service by using the systemctl command. For example, to start a quadlet container called myoracle that was confirmed during the dry run, run the following command:

sudo systemctl start myoracle

For more information, see the podman-systemd.unit(5) manual pages.

In Oracle Linux 9, you can use the Podman login shell to run shell commands in a container. This feature provides the advantage of ensuring that users are kept within established boundaries while working inside containers. Users are configured to use the /usr/bin/podmansh shell command instead of normal shells such as /bin/bash. The command starts the user's session in a rootless container called podmansh. This container continues to run until the user exits the session, at which point the container is removed.

Administrators configure users to use this feature through Quadlet files. These files define the parameters for users when they work in containers, such as the visibility of the host system when users are in the containers, access limitations, security privileges, and resource usage. For more information, see About Quadlets.

The following is an example of how you can configure a user to use the Podman login shell and other set parameters when working in a container. Assume that the quadlet applies to a specific ${USER_ID}, and the quadlet is podmansh.container.

[Unit]
Description=The Podmansh container
After=local-fs.target

[Container]
Image=container-registry.oracle.com/os/oraclelinux:8-slim
ContainerName=podmansh
RemapUsers=keep-id
RunInit=yes

Exec=sleep infinity

[Install]
RequiredBy=default.target

You can define more parameters in the [Container] section to further specify what a user can do when inside a container. See the podman-systemd.unit(5) manual page for details.

Note that the name of the container (ContainerName) must be podman. In this manner, the /usr/bin/podmansh shell command runs podman exec in the podmansh container.

The user with the ID that matches the quadlet's ${USER_ID} would log in as follows:

ssh user@systemname

All the settings defined for the user in the quadlet file transparently run without any need for user or administrator intervention.

The Podman login shell and other defined parameters combine to isolate the user and therefore ensures container security. The container is removed at the end of a session, and logging back in re-creates the same confined environment for the user. So, working with containers becomes more straightforward.

To generate a Systemd service wrapper for an individual container and store it in the $HOME/.config/systemd/user directory:

podman generate systemd --name containername > $HOME/.config/systemd/user/container-containername.service

To generate a Podman service wrapper for a specific pod, use the following command:

podman generate systemd --name podname

However, to include generating service wrapper configuration files for all the containers within a pod itself, use the --file option with the command. In this case, run the command in the directory where you intend to generate the files.

Suppose that in $HOME/.config/systemd/user, you want to generate Podman service wrappers for both mypod and its containers. You would run the following commands:

cd $HOME/.config/systemd/user/
podman generate systemd --files --name mypod

With this command, the service wrapper that's responsible for mypod includes dependencies on each of the container wrappers that are required for the pod to run successfully.

If you start or stop the pod by using its Systemd service wrapper, the container services automatically trigger the same action.

As a root user, you can start a container if its service configuration is stored in /etc/systemd/system/, for example:

sudo systemctl start container-containername.service

As a standard user, if you stored a service configuration in $HOME/.config/systemd/user, you can start the container in the same way but you must use the --user option:

systemctl --user start container-containername.service

Starting the service wrapper for a pod uses a parallel command syntax, as follows:

sudo systemctl start pod-podname.service

You can restart the service wrapper for a container or pod by using the systemctl restart command. The following command restarts a pod as a standard user:

systemctl --user restart pod-podname.service

If you start or restart a pod, all containers that are part of the pod are equally started or restarted.

You can stop a container or pod by using the systemctl stop command. The following command stops a pod as a standard user:

systemctl --user stop pod-podname.service

If you start or restart a pod, all containers that are part of the pod are equally started or restarted.

You can check the current status of any service wrapper you create for containers or pods with the systemctl status command, for example:

systemctl --user status container-containername.service