Chapter 14. Appendix: System configuration


14.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 Kickstart, 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 tools 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.

14.2. Using DNF

The rhel10/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.

14.3. Network configuration

The default images include the NetworkManager dynamic network control and configuration system, and bootc attempts to connect by using DHCP on every interface with a cable plugged in. You can apply a temporary network configuration, by setting up the /run/NetworkManager/conf.d directory.

However, if you need to use static addressing or more complex networking such as VLANs, bonds, bridges, teams, among others, you can use different ways. Regardless of the way you choose to configure networking, it results as a configuration for NetworkManager, which takes the form of NetworkManager keyfiles.

Host Network Configuration options
Complex networking configuration often also requires per-machine state. You can generate machine-specific container images that have, for example, static IP addressing included. You can also include code to generate network configuration from inside the image by inspecting the MAC address of the host.
Network configuration options available

The following are the available options for configuring static IP, and how the configuration should be done:

  • By using a Containerfile: Create a container image with static IP or include code to generate network configuration from inside the image based on MAC address.
  • By using Anaconda: You can use an Anaconda Kickstart to configure networking, including Wi-Fi, for bare-metal installations. The configuration is stored by default in /etc/NetworkManager/system-connections/, and is inherently per-machine state.
  • By using kernel arguments: Add kernel parameters on first boot to define networking configuration. On the first boot of a machine, enter kernel arguments that define networking configuration. The kernel arguments are mostly defined in the dracut.cmdline man page. You can apply these kernel arguments on first boot by using different methods. When using bootc install, you can also set per-machine kernel arguments by using --karg.
  • By using NetworkManager key files: nmcli or nm-initrd-generator

Generating a NetworkManager keyfiles by using nmcli

The nmcli NetworkManager command line tool provides an offline mode that does not communicate with the NetworkManager daemon and just writes the keyfile content to standard output.

  • Run the nmcli tool for each connection profile you want to create:

    $ nmcli --offline connection add \
            type ethernet ifname enp1s0 \
            ipv4.method manual ipv4.addresses 192.0.0.1/24 \
            ipv6.method disabled
    
    [connection]
    id=ethernet-enp1s0
    uuid=ff242096-f803-425f-9a77-4c3ec92686bd
    type=ethernet
    interface-name=enp1s0
    
    [ethernet]
    
    [ipv4]
    address1=192.0.0.1/24
    method=manual
    
    [ipv6]
    addr-gen-mode=default
    method=disabled
    [proxy]
    Copy to Clipboard

See the settings man page for a list of the properties that can be specified by using nmcli. Bash autocompletion is available.

Generating NetworkManager Keyfiles by using nm-initrd-generator

NetworkManager contains the nm-initrd-generator tool, that can generate keyfiles from dracut kernel argument syntax. You can use the tool to either convert from kernel arguments to keyfiles or to just quickly generate some keyfiles giving a small amount of input and then modify some more detailed settings.

  • Generate keyfiles for a bond by using nm-initrd-generator:

    $ podman run --rm -ti quay.io/<namespace>/<image>:<tag> /usr/libexec/nm-initrd-generator -s -- "ip=bond0:dhcp" "bond=bond0:ens2,ens3:mode=active-backup,miimon=100" "nameserver=8.8.8.8"
    
    * Connection 'bond0' *
    
    [connection]
    id=bond0
    uuid=643c17b5-b364-4137-b273-33f450a45476
    type=bond
    interface-name=bond0
    multi-connect=1
    permissions=
    
    [ethernet]
    mac-address-blacklist=
    
    [bond]
    miimon=100
    mode=active-backup
    
    [ipv4]
    dns=8.8.8.8;
    dns-search=
    may-fail=false
    method=auto
    
    [ipv6]
    addr-gen-mode=eui64
    dns-search=
    method=auto
    
    [proxy]
    
    * Connection 'ens3' *
    
    [connection]
    id=ens3
    uuid=b42cc917-fd87-47df-9ac2-34622ecddd8c
    type=ethernet
    interface-name=ens3
    master=643c17b5-b364-4137-b273-33f450a45476
    multi-connect=1
    permissions=
    slave-type=bond
    
    [ethernet]
    mac-address-blacklist=
    
    * Connection 'ens2' *
    
    [connection]
    id=ens2
    uuid=e111bb4e-3ee3-4612-afc2-1d2dfff97671
    type=ethernet
    interface-name=ens2
    master=643c17b5-b364-4137-b273-33f450a45476
    multi-connect=1
    permissions=
    slave-type=bond
    
    [ethernet]
    mac-address-blacklist=
    Copy to Clipboard

The command generates three keyfiles for each interface: bond0, ens3, and ens2. You can use the generated output, add more settings or modify existing settings, and then commit the files into a container image.

Configuring a Static IP

  • You can use the following dracut kernel arguments:

    Template:

ip=${ip}::${gateway}:${netmask}:${hostname}:${interface}:none:${nameserver}
Copy to Clipboard

Example:

ip=10.10.10.10::10.10.10.1:255.255.255.0:myhostname:ens2:none:8.8.8.8
Copy to Clipboard

Writing configuration embedded in container images

Store the NetworkManager configuration embedded in container images in /usr/lib/NetworkManager/system-connections/ because this form is part of the immutable image state. You can also write configuration to /etc/NetworkManager/system-connections/ as part of the container image. The default OSTree 3-way merge, that is, using the old default configuration, the active /etc system, and the new default configuration, applies with any machine-specific configuration.

The keyfiles must have the 600 root-only access permissions, otherwise NetworkManager ignores them.

Disabling automatic configuration of Ethernet devices

By default, NetworkManager attempts to autoconfigure by using the DHCP or SLAAC addresses on every interface with a cable plugged in. In some network environments this might not be desirable. For that, it is possible to change the NetworkManager behavior by adding a configuration file, such as /usr/lib/NetworkManager/conf.d/noauto.conf.

  • Disable the NetworkManager autoconfiguration of Ethernet devices

    [main]
    # Do not do automatic (DHCP or SLAAC) configuration on ethernet devices
    # with no other matching connections.
    no-auto-default=*
    Copy to Clipboard

14.4. 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.

14.5. 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"
Copy to Clipboard
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.
# /usr/lib/systemd/system/bootc-fetch-apply-updates.service.d/99-proxy.conf
[Service]
EnvironmentFile=/etc/example-proxy.env
Copy to Clipboard
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 $HOME/.config/containers/containers.conf configuration file as a non-root user.

Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat