Red Hat SummitEste conteúdo não está disponível no idioma selecionado.
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.
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
/rundirectory -
The
/rundirectory is an API filesystem that is defined to be deleted when the system is restarted. Use the/rundirectory 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/systemddirectory. For example, thesystemctl edit --runtime myservice.servicedynamically changes the configuration of themyservice.serviceunit, without persisting the changes. - NetworkManager
-
Use a
/run/NetworkManager/conf.ddirectory for applying temporary network configuration. Use thenmcli connection modify --temporarycommand to write changes only in memory. Without the--temporaryoption, the command writes persistent changes. - podman
-
Use the
podman run --rmcommand to automatically remove the container when it exits. Without the--rmoption, thepodman runcommand 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
dnfas a part of a container build -
You can use the
RUN dnf installdirective in the Containerfile. - Using
dnfat runtime
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-builderYou 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.
# /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"
- Defining drop-in units for core services
-
The
bootcandpodmantools commonly need proxy configuration. At the current time,bootcdoes not always run as asystemdunit.
# /usr/lib/systemd/system/bootc-fetch-apply-updates.service.d/99-proxy.conf [Service] EnvironmentFile=/etc/example-proxy.env
- Defining proxy use for podman
systemdunits Using the Podman
systemdconfiguration, similarly addEnvironmentFile=/etc/example-proxy.env.You can set the configuration for proxy and environment settings of
podmanand containers in the/etc/containers/containers.confconfiguration file as a root user or in the$HOME/.config/containers/containers.confconfiguration file as a non-root user.
