Chapter 13. Appendix: System configuration 13.1. Transient runtime reconfiguration You can perform a dynamic reconfiguration in the base image configuration. For example, you can run the firewall-cmd --permanent command to achieve persistent changes across a reboot. Warning The /etc directory is persistent by default. If you perform changes made by using tools, for example firewall-cmd --permanent , the contents of the /etc on the system can differ from the one described in the container image. In the default configuration, first make the changes in the base image, then queue the changes without restarting running systems, and then simultaneously write to apply the changes to existing systems only in memory. You can configure the /etc directory to be transient by using bind mounts. In this case, the etc directory is a part of the machine's local root filesystem. For example, if you inject static IP addresses by using Anaconda kickstarts, they persist across upgrades. A 3-way merge is applied across upgrades and each "deployment" has its own copy of /etc . The /run directory The /run directory is an API filesystem that is defined to be deleted when the system is restarted. Use the /run directory for transient files. Dynamic reconfiguration models In the Pull model, you can include code directly embedded in your base image or a privileged container that contacts the remote network server for configuration, and subsequently launch additional container images, by using the Podman API. In the Push model, some workloads are implemented by tooling such as Ansible. systemd You can use systemd units for dynamic transient reconfiguration by writing to /run/systemd directory. For example, the systemctl edit --runtime myservice.service dynamically changes the configuration of the myservice.service unit, without persisting the changes. NetworkManager Use a /run/NetworkManager/conf.d directory for applying temporary network configuration. Use the nmcli connection modify --temporary command to write changes only in memory. Without the --temporary option, the command writes persistent changes. podman Use the podman run --rm command to automatically remove the container when it exits. Without the --rm option, the podman run command creates a container that persists across system reboots. 13.2. Using dnf The rhel9/rhel-bootc container image includes dnf . There are several use cases: Using dnf as a part of a container build You can use the RUN dnf install directive in the Containerfile. Using dnf at runtime Warning The functionality depends on the dnf version. You might get an error: error: can't create transaction lock on /usr/share/rpm/.rpm.lock (Read-only file system) . You can use the bootc-usr-overlay command to create a writable overlay filesystem for /usr directory. The dnf install writes to this overlay. You can use this feature for installing debugging tools. Note that changes will be lost on reboot. Configuring storage The supported storage technologies are the following: xfs / ext4 Logical volume management (LVM) Linux Unified Key Setup (LUKS) You can add other storage packages to the host system. Storage with bootc-image-builder You can use the bootc-image-builder tool to create a disk image. The available configuration for partitioning and layout is relatively fixed. The default filesystem type is derived from the container image's bootc install configuration. Storage with bootc install You can use the bootc install to-disk command for flat storage configurations and bootc install to-filesytem command for more advanced installations. For more information see Advanced installation with to-filesystem . 13.3. Setting a hostname To set a custom hostname for your system, modify the /etc/hostname file. You can set the hostname by using Anaconda, or with a privileged container. Once you boot a system, you can verify the hostname by using the hostnamectl command. 13.4. Proxied Internet Access If you are deploying to an environment requiring internet access by using a proxy, you need to configure services so that they can access resources as intended. This is done by defining a single file with required environment variables in your configuration, and to reference this by using systemd drop-in unit files for all such services. Defining common proxy environment variables This common file has to be subsequently referenced explicitly by each service that requires internet access. Defining drop-in units for core services The bootc and podman tools commonly need proxy configuration. At the current time, bootc does not always run as a systemd unit. Defining proxy use for podman systemd units Using the Podman systemd configuration, similarly add EnvironmentFile=/etc/example-proxy.env . You can set the configuration for proxy and environment settings of podman and containers in the /etc/containers/containers.conf configuration file as a root user or in the USDHOME/.config/containers/containers.conf configuration file as a non-root user.

Commands:
/etc/example-proxy.env https_proxy="http://example.com:8080" all_proxy="http://example.com:8080" http_proxy="http://example.com:8080" HTTP_PROXY="http://example.com:8080" HTTPS_PROXY="http://example.com:8080" no_proxy="*.example.com,127.0.0.1,0.0.0.0,localhost"
/usr/lib/systemd/system/bootc-fetch-apply-updates.service.d/99-proxy.conf [Service] EnvironmentFile=/etc/example-proxy.env