Chapter 5. Supported image customizations
You can customize your image by adding customizations to your blueprint, such as:
- Adding an additional RPM package
- Enabling a service
- Customizing a kernel command line parameter.
Between others. You can use several image customizations within blueprints. By using the customizations, you can add packages and groups to the image that are not available in the default packages. To use these options, configure the customizations in the blueprint and import (push) it to RHEL image builder.
5.1. Selecting a distribution Copy linkLink copied to clipboard!
You can use the distro field to specify the distribution to use when composing your images or solving dependencies in the blueprint. If the distro field is left blank, the blueprint automatically uses the host’s operating system distribution. If you do not specify a distribution, the blueprint uses the host distribution. When you upgrade the host operating system, blueprints without a specified distribution build images by using the upgraded operating system version.
You can build images for older major versions on a newer system. For example, you can use a RHEL 10 host to create RHEL 9 and RHEL 8 images. However, you cannot build images for newer major versions on an older system.
You cannot build an operating system image that differs from the RHEL image builder host. For example, you cannot use a RHEL system to build Fedora or CentOS images.
Prerequisites
- You have created a blueprint.
Procedure
Customize the blueprint with the RHEL distribution to always build the specified RHEL image:
name = "blueprint_name" description = "blueprint_version" version = "0.1" distro = "different_minor_version"
name = "blueprint_name" description = "blueprint_version" version = "0.1" distro = "different_minor_version"Copy to Clipboard Copied! Toggle word wrap Toggle overflow For example:
name = "tmux" description = "tmux image with openssh" version = "1.2.16" distro = "rhel-9.6"
name = "tmux" description = "tmux image with openssh" version = "1.2.16" distro = "rhel-9.6"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Replace
"different_minor_version"to build a different minor version, for example, if you want to build a RHEL 9.6 image, usedistro = "rhel-96". On RHEL 9.5 image, you can build minor versions such as RHEL 9.4, RHEL 9.3, and earlier releases.
5.2. Selecting a package group Copy linkLink copied to clipboard!
Customize the blueprint with package groups. The groups list describes the groups of packages that you want to install into the image. The package groups are defined in the repository metadata. Each group has a descriptive name that is used primarily for display in user interfaces, and an ID that is commonly used in Kickstart files. In this case, you must use the ID to list a group. Groups have three different ways of categorizing their packages: mandatory, default, and optional. Only mandatory and default packages are installed in the blueprints. It is not possible to select optional packages.
The name attribute is a required string and must match exactly the package group id in the repositories.
Currently, there are no differences between packages and modules in osbuild-composer. Both are treated as an RPM package dependency.
Prerequisites
- You have created a blueprint.
Procedure
Customize your blueprint with a package:
[[groups]] name = "<group_name>"
[[groups]] name = "<group_name>"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Replace
group_namewith the name of the group. For example:[[groups]] name = "anaconda-tools"
[[groups]] name = "anaconda-tools"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3. Selecting a package Copy linkLink copied to clipboard!
Customize the blueprint with packages and modules.
-
The
nameattribute is a required string and can be an exact match, or a filesystem glob that uses*for wildcards, and?for character matching. -
The
versionattribute is an optional string can be an exact match or a filesystem glob of the version that uses*for wildcards, and?for character matching. If you do not enter a version, the system uses the latest version in the repositories.
When you use a virtual provides as the package name, the version glob must be *. Consequently, you are not able to freeze the blueprint, because the provider expands into multiple packages with their own names and versions.
Currently, there are no differences between packages and modules in osbuild-composer. Both are treated as an RPM package dependency.
Prerequisites
- You have created a blueprint.
Procedure
Customize your blueprint with a package:
[[packages]] name = "<package_name>"
[[packages]] name = "<package_name>"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Replace
package_namewith the name of the group. For example, thetmux-2.9a, and theopenssh-server-8.*packages.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4. Embedding a container Copy linkLink copied to clipboard!
You can customize your blueprint to embed the latest RHEL container. The containers list contains objects with a source, and optionally, the tls-verify attribute.
The container list entries describe the container images to be embedded into the image.
-
source- Mandatory field. It is a reference to the container image at a registry. This example uses theregistry.access.redhat.comregistry. You can specify a tag version. The default tag version is latest. -
name- The name of the container in the local registry. -
tls-verify- Boolean field. The tls-verify boolean field controls the transport layer security. The default value is true.
The embedded containers do not start automatically. To start it, create systemd unit files or quadlets with the files customization.
Prerequisites
- You have created a blueprint.
Procedure
To embed a container from
registry.access.redhat.com/ubi10/ubi:latestand a container from your host, add the following customization to your blueprint:Copy to Clipboard Copied! Toggle word wrap Toggle overflow You can access protected container resources by using a
containers-auth.jsonfile. See Container registry credentials.
5.5. Setting the image hostname Copy linkLink copied to clipboard!
The customizations.hostname is an optional string that you can use to configure the final image hostname. This customization is optional, and if you do not set it, the blueprint uses the default hostname.
Prerequisites
- You have created a blueprint.
Procedure
Customize the blueprint to configure the hostname:
[customizations] hostname = "<base_image>"
[customizations] hostname = "<base_image>"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.6. Specifying additional users Copy linkLink copied to clipboard!
Add a user to the image, and optionally, set their SSH key. All fields for this section are optional except for the name.
Prerequisites
- You have created a blueprint.
Procedure
Customize the blueprint to add a user to the image:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow The GID is optional and must already exist in the image. Optionally, a package creates it, or the blueprint creates the GID by using the
[[customizations.group]]entry.Replace
password_hashwith the actualpassword hash. To generate thepassword hash, use a command such as:python3 -c 'import crypt,getpass;pw=getpass.getpass();print(crypt.crypt(pw) if (pw==getpass.getpass("Confirm: ")) else exit())'$ python3 -c 'import crypt,getpass;pw=getpass.getpass();print(crypt.crypt(pw) if (pw==getpass.getpass("Confirm: ")) else exit())'Copy to Clipboard Copied! Toggle word wrap Toggle overflow Replace the other placeholders with suitable values.
Enter the
namevalue and omit any lines you do not need.Repeat this block for every user to include.
5.7. Specifying additional groups Copy linkLink copied to clipboard!
Specify a group for the resulting system image. Both the name and the gid attributes are mandatory.
Prerequisites
- You have created a blueprint.
Procedure
Customize the blueprint with a group:
[[customizations.group]] name = "<group_name>" gid = <number>
[[customizations.group]] name = "<group_name>" gid = <number>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Repeat this block for every group to include. For example:
[[customizations.group]] name = "widget" gid = 1130
[[customizations.group]] name = "widget" gid = 1130Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.8. Setting SSH key for existing users Copy linkLink copied to clipboard!
You can use customizations.sshkey to set an SSH key for the existing users in the final image. Both user and key attributes are mandatory.
Prerequisites
- You have created a blueprint.
Procedure
Customize the blueprint by setting an SSH key for existing users:
[[customizations.sshkey]] user = "root" key = "PUBLIC-SSH-KEY"
[[customizations.sshkey]] user = "root" key = "PUBLIC-SSH-KEY"Copy to Clipboard Copied! Toggle word wrap Toggle overflow For example:
[[customizations.sshkey]] user = "root" key = "SSH key for root"
[[customizations.sshkey]] user = "root" key = "SSH key for root"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.9. Appending a kernel argument Copy linkLink copied to clipboard!
You can append arguments to the boot loader kernel command line. By default, RHEL image builder builds a default kernel into the image. However, you can customize the kernel by configuring it in the blueprint.
Prerequisites
- You have created a blueprint.
Procedure
Append a kernel boot parameter option to the defaults:
[customizations.kernel] append = "<kernel_option>"
[customizations.kernel] append = "<kernel_option>"Copy to Clipboard Copied! Toggle word wrap Toggle overflow For example:
[customizations.kernel] name = "kernel-debug" append = "nosmt=force"
[customizations.kernel] name = "kernel-debug" append = "nosmt=force"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.10. Building RHEL images by using the real-time kernel Copy linkLink copied to clipboard!
To build a RHEL image by using the real-time kernel (kernel-rt), you need to override a repository so that you can then build an image in which kernel-rt is correctly selected as the default kernel. Use the .json from the /usr/share/osbuild-composer/repositories/ directory. Then, you can deploy the image that you built to a system and use the real time kernel features.
The real-time kernel runs on AMD64 and Intel 64 server platforms that are certified to run Red Hat Enterprise Linux.
Prerequisites
- Your system is registered and RHEL is attached to a RHEL for Real Time subscription.
Procedure
Create the following directory:
mkdir /etc/osbuild-composer/repositories/
# mkdir /etc/osbuild-composer/repositories/Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy the content from the
/usr/share/osbuild-composer/repositories/rhel-10.jsonfile to the new directory:cp /usr/share/osbuild-composer/repositories/rhel-10.json /etc/osbuild-composer/repositories
# cp /usr/share/osbuild-composer/repositories/rhel-10.json /etc/osbuild-composer/repositoriesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Edit the
/etc/osbuild-composer/repositories/rhel-10.jsonfile to include the RT kernel repo:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Restart the service:
systemctl restart osbuild-composer
# systemctl restart osbuild-composerCopy to Clipboard Copied! Toggle word wrap Toggle overflow Confirm that the
kernel-rthas been included into the.jsonfile:composer-cli sources list composer-cli sources info kernel-rt
# composer-cli sources list # composer-cli sources info kernel-rtCopy to Clipboard Copied! Toggle word wrap Toggle overflow You will see the URL that you have previously configured.
Create a blueprint. In the blueprint, add the "[customizations.kernel]" customization. The following is an example that contains the "[customizations.kernel]" in the blueprint:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Push the blueprint to the server:
composer-cli blueprints push rt-kernel-image.toml
# composer-cli blueprints push rt-kernel-image.tomlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Build your image from the blueprint you created. The following example builds a (
.qcow2) image:composer-cli compose start rt-kernel-image qcow2
# composer-cli compose start rt-kernel-image qcow2Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Deploy the image that you built to the system where you want to use the real time kernel features.
Verification
After booting a VM from the image, verify that the image was built with the
kernel-rtcorrectly selected as the default kernel.cat /proc/cmdline BOOT_IMAGE=(hd0,got3)/vmlinuz-6.12.0-0.el10_0_.x86_64+rt...
$ cat /proc/cmdline BOOT_IMAGE=(hd0,got3)/vmlinuz-6.12.0-0.el10_0_.x86_64+rt...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.11. Setting time zone and NTP Copy linkLink copied to clipboard!
You can customize your blueprint to configure the time zone and the Network Time Protocol (NTP). Both timezone and ntpservers attributes are optional strings. If you do not customize the time zone, the system uses Universal Time, Coordinated (UTC). If you do not set NTP servers, the system uses the default distribution.
Prerequisites
- You have created a blueprint.
Procedure
Customize the blueprint with the
timezoneand thentpserversyou want:[customizations.timezone] timezone = "TIMEZONE" ntpservers = "NTP_SERVER"
[customizations.timezone] timezone = "TIMEZONE" ntpservers = "NTP_SERVER"Copy to Clipboard Copied! Toggle word wrap Toggle overflow For example:
[customizations.timezone] timezone = "US/Eastern" ntpservers = ["0.north-america.pool.ntp.org", "1.north-america.pool.ntp.org"]
[customizations.timezone] timezone = "US/Eastern" ntpservers = ["0.north-america.pool.ntp.org", "1.north-america.pool.ntp.org"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteSome image types, such as Google Cloud, already have NTP servers set up. You cannot override it because the image requires the NTP servers to boot in the selected environment. However, you can customize the time zone in the blueprint.
5.12. Customizing the locale settings Copy linkLink copied to clipboard!
You can customize the locale settings for your resulting system image. Both language and the keyboard attributes are mandatory. You can add many other languages. The first language you add is the primary language and the other languages are secondary.
Prerequisites
- You have created a blueprint.
Procedure
Set the locale settings:
[customizations.locale] languages = ["<language>"] keyboard = "<keyboard>"
[customizations.locale] languages = ["<language>"] keyboard = "<keyboard>"Copy to Clipboard Copied! Toggle word wrap Toggle overflow For example:
[customizations.locale] languages = ["en_US.UTF-8"] keyboard = "us"
[customizations.locale] languages = ["en_US.UTF-8"] keyboard = "us"Copy to Clipboard Copied! Toggle word wrap Toggle overflow List the values supported by the languages:
localectl list-locales
$ localectl list-localesCopy to Clipboard Copied! Toggle word wrap Toggle overflow List the values supported by the keyboard:
localectl list-keymaps
$ localectl list-keymapsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.13. Customizing firewall Copy linkLink copied to clipboard!
Set the firewall for the resulting system image. By default, the firewall blocks incoming connections, except for services that enable their ports explicitly, such as sshd.
If you do not want to use the [customizations.firewall] or the [customizations.firewall.services], either remove the attributes, or set them to an empty list []. If you only want to use the default firewall setup, you can omit the customization from the blueprint.
The Google template explicitly disables the firewall for their environment. You cannot override this behavior by setting the blueprint.
Prerequisites
- You have created a blueprint.
Procedure
Customize the blueprint with the following settings to open other ports and services:
[customizations.firewall] ports = ["<ports>"]
[customizations.firewall] ports = ["<ports>"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow Where
portsis an optional list of strings that contain ports or a range of ports and protocols to open. You can configure the ports by using the following format:port:protocolformat. You can configure the port ranges by using theportA-portB:protocolformat. For example:[customizations.firewall] ports = ["22:tcp", "80:tcp", "imap:tcp", "53:tcp", "53:udp", "30000-32767:tcp", "30000-32767:udp"]
[customizations.firewall] ports = ["22:tcp", "80:tcp", "imap:tcp", "53:tcp", "53:udp", "30000-32767:tcp", "30000-32767:udp"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow You can use numeric ports, or their names from the
/etc/servicesto enable or disable port lists.Specify which firewall services to enable or disable in the
customizations.firewall.servicesection:[customizations.firewall.services] enabled = ["<services>"] disabled = ["<services>"]
[customizations.firewall.services] enabled = ["<services>"] disabled = ["<services>"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow You can check the available firewall services:
firewall-cmd --get-services
$ firewall-cmd --get-servicesCopy to Clipboard Copied! Toggle word wrap Toggle overflow For example:
[customizations.firewall.services] enabled = ["ftp", "ntp", "dhcp"] disabled = ["telnet"]
[customizations.firewall.services] enabled = ["ftp", "ntp", "dhcp"] disabled = ["telnet"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteThe services listed in
firewall.servicesare different from theservice-namesavailable in the/etc/servicesfile.
5.14. Enabling or disabling services Copy linkLink copied to clipboard!
You can control which services to enable during the boot time. Some image types already have services enabled or disabled to ensure that the image works correctly and you cannot override this setup. The [customizations.services] settings in the blueprint do not replace these services, but add the services to the list of services already present in the image templates.
Prerequisites
- You have created a blueprint.
Procedure
Customize which services to enable during the boot time:
[customizations.services] enabled = ["services"] disabled = ["services"]
[customizations.services] enabled = ["services"] disabled = ["services"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow For example:
[customizations.services] enabled = ["sshd", "cockpit.socket", "httpd"] disabled = ["postfix", "telnetd"]
[customizations.services] enabled = ["sshd", "cockpit.socket", "httpd"] disabled = ["postfix", "telnetd"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.15. Kickstart file injection in an ISO image Copy linkLink copied to clipboard!
You can use the [customization.installer] blueprint customization to add your own Kickstart file in your builds for ISO installers such as, image installer or edge installer, and gain more flexibility when building ISO images for bare metal deployments.
Booting the ISO on a machine with an existing operating system or data can be destructive, because the Kickstart is configured to automatically reformat the first disk on the system.
You can choose the following options to add your own Kickstart file:
- Setting all values during the installation process.
-
Enabling the
unattended = truefield in the Kickstart, and getting a fully unattended installation with defaults. Injecting your own Kickstart by using the Kickstart field. This can result in both a fully unattended installation if you specify all required fields, or the installation program prompts you for some fields that might be missing.
The Anaconda installer ISO image types support the following blueprint customization:
[customizations.installer] unattended = true sudo-nopasswd = ["user", "%wheel"]
[customizations.installer] unattended = true sudo-nopasswd = ["user", "%wheel"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow unattended: Creates a Kickstart file that makes the installation fully automatic. This includes setting the following options by default:- text display mode
-
en_US.UTF-8language and locale -
us keyboardlayout -
UTC time zone -
zerombr,clearpart, andautopartto automatically wipe and partition the first disk -
network options to enable
dhcpandauto-activation
The following is an example:
sudo-nopasswd: Adds a snippet to the Kickstart file that, after installation, creates drop-in files in /etc/sudoers.d to allow the specified users and groups to run sudo without a password. The groups must be prefixed with %. For example, setting the value to ["user", "%wheel"] creates the following Kickstart %post section:
As an alternative, you can include a custom Kickstart by using the following customization:
osbuild-composer automatically adds the command that installs the system: liveimg or ostreesetup, if it is relevant for the image-installer, or edge-installer image types. You cannot use the [customizations.installer.kickstart] customization in combination with any other installer customizations.
5.16. Specifying a partition mode Copy linkLink copied to clipboard!
Use the partitioning_mode variable to select how to partition the disk image that you are building. You can customize your image with the following supported modes:
-
auto-lvm: It uses the raw partition mode, unless there are one or more filesystem customizations. In that case, it uses the LVM partition mode. -
lvm: It always uses the LVM partition mode, even when there are no extra mount points. -
raw: It uses raw partitions even when there are one or more mount points.
Prerequisites
- You have created a blueprint.
Procedure
You can customize your blueprint with the
partitioning_modevariable by using the following customization:[customizations] partitioning_mode = "lvm"
[customizations] partitioning_mode = "lvm"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.17. Custom file system configuration specification Copy linkLink copied to clipboard!
You can specify a custom filesystem configuration in your blueprints and therefore create images with a specific disk layout, instead of the default layout configuration. By using the non-default layout configuration in your blueprints, you can benefit from:
- Security benchmark compliance
- Protection against out-of-disk errors
- Improved performance
- Consistency with existing setups
The OSTree systems do not support the filesystem customizations, because OSTree images have their own mount rule, such as read-only. The following image types are not supported:
-
image-installer -
edge-installer -
edge-simplified-installer
Additionally, the following image types do not support filesystem customizations, because these image types do not create partitioned operating system images:
-
edge-commit -
edge-container -
tar -
container
For release distributions before 9.4, the blueprint supports the following mountpoints and their sub-directories:
-
/is the root mount point -
/var -
/home -
/opt -
/srv -
/usr -
/app -
/data -
/tmp
You cannot specify arbitrary custom mount points on the following mount points and their sub-directories:
-
/bin -
/dev -
/etc -
/lib -
/lib64 -
/lost+found -
/proc -
/run -
/sbin -
/sys -
/sysroot -
/var/lock -
/var/run
You can customize the filesystem in the blueprint for the /usr custom mount point, but its subdirectory is not allowed.
If you have more than one partition in the customized image, you can create images with a customized file system partition on LVM and resize those partitions at runtime. To do this, you can specify a customized filesystem configuration in your blueprint and therefore create images with the required disk layout. The default filesystem layout remains unchanged if you use plain images without file system customization, and cloud-init resizes the root partition.
The blueprint automatically converts the file system customization to an LVM partition.
You can use the custom file blueprint customization to create new files or to replace existing files. The parent directory of the file you specify must exist, otherwise, the image build fails. Ensure that the parent directory exists by specifying it in the [[customizations.directories]] customization.
If you combine the files customizations with other blueprint customizations, it might affect the functioning of the other customizations, or it might override the current files customizations.
5.17.1. Custom files specification in the blueprint Copy linkLink copied to clipboard!
With the [[customizations.files]] blueprint customization you can:
- Create new text files.
Modifying existing files.
WarningThis can override the existing content.
- Set user and group ownership for the file you are creating.
- Set the mode permission in the octal format.
You cannot create or replace the following files:
-
/etc/fstab -
/etc/shadow -
/etc/passwd -
/etc/group
You can create customized files and directories in your image, by using the [[customizations.files]] and the [[customizations.directories]] blueprint customizations. You can use these customizations only in the /etc directory.
These blueprint customizations are supported by all image types, except the image types that deploy OSTree commits, such as edge-raw-image, edge-installer, and edge-simplified-installer.
If you use the customizations.directories with a directory path which already exists in the image with mode, user, or group already set, the image build fails to prevent changing the ownership or permissions of the existing directory.
5.17.2. Custom directories specification in the blueprint Copy linkLink copied to clipboard!
With the [[customizations.directories]] blueprint customization you can:
- Create new directories.
- Set user and group ownership for the directory you are creating.
- Set the directory mode permission in the octal format.
- Ensure that parent directories are created as needed.
With the [[customizations.files]] blueprint customization you can:
- Create new text files.
- Modifying existing files. WARNING: this can override the existing content.
- Set user and group ownership for the file you are creating.
- Set the mode permission in the octal format.
You cannot create or replace the following files:
-
/etc/fstab -
/etc/shadow -
/etc/passwd -
/etc/group
The following customizations are available:
Customize the filesystem configuration in your blueprint:
[[customizations.filesystem]] mountpoint = "MOUNTPOINT" minsize = MINIMUM-PARTITION-SIZE
[[customizations.filesystem]] mountpoint = "MOUNTPOINT" minsize = MINIMUM-PARTITION-SIZECopy to Clipboard Copied! Toggle word wrap Toggle overflow The
MINIMUM-PARTITION-SIZEvalue has no default size format. The blueprint customization supports the following values and units: kB to TB and KiB to TiB. For example, you can define the mount point size in bytes:[[customizations.filesystem]] mountpoint = "/var" minsize = 1073741824
[[customizations.filesystem]] mountpoint = "/var" minsize = 1073741824Copy to Clipboard Copied! Toggle word wrap Toggle overflow Define the mount point size by using units. For example:
[[customizations.filesystem]] mountpoint = "/opt" minsize = "20 GiB"
[[customizations.filesystem]] mountpoint = "/opt" minsize = "20 GiB"Copy to Clipboard Copied! Toggle word wrap Toggle overflow [[customizations.filesystem]] mountpoint = "/var" minsize = "1 GiB"
[[customizations.filesystem]] mountpoint = "/var" minsize = "1 GiB"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Define the minimum partition by setting
minsize. For example:[[customizations.filesystem]] mountpoint = "/var" minsize = 2147483648
[[customizations.filesystem]] mountpoint = "/var" minsize = 2147483648Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create customized directories under the
/etcdirectory for your image by using[[customizations.directories]]:Copy to Clipboard Copied! Toggle word wrap Toggle overflow The blueprint entries are described as following:
-
pathMandatory. Enter the path to the directory that you want to create. It must be an absolute path under the/etcdirectory. -
modeOptional. Set the access permission on the directory, in the octal format. If you do not specify a permission, it defaults to0755. The leading zero is optional. -
userOptional. Set a user as the owner of the directory. If you do not specify a user, it defaults toroot. You can specify the user as a string or as an integer. -
groupOptional. Set a group as the owner of the directory. If you do not specify a group, it defaults toroot. You can specify the group as a string or as an integer. -
ensure_parentsOptional. Specify whether you want to create parent directories as needed. If you do not specify a value, it defaults tofalse.
-
Create customized file under the
/etcdirectory for your image by using[[customizations.directories]]:Copy to Clipboard Copied! Toggle word wrap Toggle overflow The blueprint entries are described as following:
-
pathMandatory. Enter the path to the file that you want to create. It must be an absolute path under the/etcdirectory. -
modeOptional. Set the access permission on the file, in the octal format. If you do not specify a permission, it defaults to0644`. The leading zero is optional. -
userOptional. Set a user as the owner of the file. If you do not specify a user, it defaults toroot. You can specify the user as a string or as an integer. -
groupOptional. Set a group as the owner of the file. If you do not specify a group, it defaults toroot. You can specify the group as a string or as an integer. -
dataOptional. Specify the content of a plain text file. If you do not specify a content, it creates an empty file.
-
5.18. Volume groups and logical volumes naming specification in the blueprint Copy linkLink copied to clipboard!
You can use RHEL image builder for the following operations:
-
Create RHEL disk images with advanced partitioning layout. You can create disk images with custom mount points, LVM-based partitions and LVM-based SWAP. For example, change the size of the
/and the/bootdirectories by using theconfig.tomlfile. -
Select which file system to use. You can choose between
ext4andxfs. - Add swap partitions and LVs. The disk images can contain LV-based SWAP.
- Change names of LVM entities. The Logical Volumes (LV) and Volume Groups (VG) inside the images can have custom names.
The following options are not supported:
- Multiple PVs or VGs in one image.
- SWAP files
-
Mount options for non-physical partitions, such as
/dev/shm, and/tmp.
You can add custom names for VG and LG where the file systems reside, for example: