From a9fa8313731f1860fddb228ff9a3a6ecdfbec3fc Mon Sep 17 00:00:00 2001 From: Maximilian Kolb Date: Thu, 30 Jan 2025 09:17:44 +0100 Subject: [PATCH] Modularize Planning for Foreman guide --- .../con_foreman-deployment-planning.adoc | 2 + .../con_foreman-overview-and-concepts.adoc | 5 + ...ooting-requirements-with-managed-dhcp.adoc | 26 ++++ ...ting-requirements-with-unmanaged-dhcp.adoc | 29 ++++ guides/common/modules/con_http-booting.adoc | 4 + .../modules/con_provisioning-concepts.adoc | 6 + .../modules/con_pxe-booting-requirements.adoc | 24 ++++ guides/common/modules/con_pxe-booting.adoc | 8 ++ guides/common/modules/con_pxe-sequence.adoc | 11 ++ guides/common/modules/con_secure-boot.adoc | 19 +++ ...-infrastructure-organization-concepts.adoc | 2 +- ...ers-provided-and-required-by-foreman.adoc} | 9 +- guides/doc-Planning_for_Project/master.adoc | 30 ++-- .../topics/Provisioning_Concepts.adoc | 132 ------------------ 14 files changed, 158 insertions(+), 149 deletions(-) create mode 100644 guides/common/modules/con_foreman-deployment-planning.adoc create mode 100644 guides/common/modules/con_foreman-overview-and-concepts.adoc create mode 100644 guides/common/modules/con_http-booting-requirements-with-managed-dhcp.adoc create mode 100644 guides/common/modules/con_http-booting-requirements-with-unmanaged-dhcp.adoc create mode 100644 guides/common/modules/con_http-booting.adoc create mode 100644 guides/common/modules/con_provisioning-concepts.adoc create mode 100644 guides/common/modules/con_pxe-booting-requirements.adoc create mode 100644 guides/common/modules/con_pxe-booting.adoc create mode 100644 guides/common/modules/con_pxe-sequence.adoc create mode 100644 guides/common/modules/con_secure-boot.adoc rename guides/{doc-Planning_for_Project/topics/Required_Technical_Users.adoc => common/modules/ref_technical-users-provided-and-required-by-foreman.adoc} (89%) delete mode 100644 guides/doc-Planning_for_Project/topics/Provisioning_Concepts.adoc diff --git a/guides/common/modules/con_foreman-deployment-planning.adoc b/guides/common/modules/con_foreman-deployment-planning.adoc new file mode 100644 index 00000000000..6cea8c47ec3 --- /dev/null +++ b/guides/common/modules/con_foreman-deployment-planning.adoc @@ -0,0 +1,2 @@ +[id="{project-context}-deployment-planning"] += {Project} deployment planning diff --git a/guides/common/modules/con_foreman-overview-and-concepts.adoc b/guides/common/modules/con_foreman-overview-and-concepts.adoc new file mode 100644 index 00000000000..fc21ff722e8 --- /dev/null +++ b/guides/common/modules/con_foreman-overview-and-concepts.adoc @@ -0,0 +1,5 @@ +[id="{project-context}-overview-and-concepts"] += {Project} overview and concepts + +{ProjectName} is a centralized tool for provisioning, remote management, and monitoring of multiple {EL} deployments. +With {Project}, you can deploy, configure, and maintain your systems across physical, virtual, and cloud environments. diff --git a/guides/common/modules/con_http-booting-requirements-with-managed-dhcp.adoc b/guides/common/modules/con_http-booting-requirements-with-managed-dhcp.adoc new file mode 100644 index 00000000000..89386a4b2a6 --- /dev/null +++ b/guides/common/modules/con_http-booting-requirements-with-managed-dhcp.adoc @@ -0,0 +1,26 @@ +[id="http-booting-requirements-with-managed-dhcp"] += HTTP booting requirements with managed DHCP + +To provision machines through HTTP booting ensure that you meet the following requirements: + +.Client requirements +For HTTP booting to work, ensure that your environment has the following client-side configurations: + +* All the network-based firewalls are configured to allow clients on the subnet to access the {SmartProxy}. +For more information, see xref:{smart-proxy-context}-networking_{context}[]. +* Your client has access to the DHCP and DNS servers. +* Your client has access to the HTTP UEFI Boot {SmartProxy}. + +.Network requirements +* Optional: If the host and the DHCP server are separated by a router, configure the DHCP relay agent and point to the DHCP server. + +.{Project} requirements +Although TFTP protocol is not used for HTTP UEFI Booting, {Project} uses TFTP {SmartProxy} API to deploy boot loader configuration. + +For HTTP booting to work, ensure that {Project} has the following configurations: + +* Both {ProjectServer} and {SmartProxy} have DNS configured and are able to resolve provisioned host names. +* The UDP ports 67 and 68 are accessible by the client so that the client can send and receive a DHCP request and offer. +* Ensure that the TCP port 8000 is open for the client to download the boot loader and Kickstart templates from the {SmartProxy}. +* The TCP port {smartproxy_port} is open for the client to download the boot loader from the {SmartProxy} using the HTTPS protocol. +* The subnet that functions as the host's provisioning interface has a DHCP {SmartProxy}, an HTTP Boot {SmartProxy}, a TFTP {SmartProxy}, and a Templates {SmartProxy} diff --git a/guides/common/modules/con_http-booting-requirements-with-unmanaged-dhcp.adoc b/guides/common/modules/con_http-booting-requirements-with-unmanaged-dhcp.adoc new file mode 100644 index 00000000000..af07509a794 --- /dev/null +++ b/guides/common/modules/con_http-booting-requirements-with-unmanaged-dhcp.adoc @@ -0,0 +1,29 @@ +[id="http-booting-requirements-with-unmanaged-dhcp"] += HTTP booting requirements with unmanaged DHCP + +To provision machines through HTTP booting without managed DHCP ensure that you meet the following requirements: + +.Client requirements +* HTTP UEFI Boot URL must be set to one of: +** `\http://{smartproxy-example-com}:8000` +** `\https://{smartproxy-example-com}:{smartproxy_port}` +* Ensure that your client has access to the DHCP and DNS servers. +* Ensure that your client has access to the HTTP UEFI Boot {SmartProxy}. +* Ensure that all the network-based firewalls are configured to allow clients on the subnet to access the {SmartProxy}. +For more information, see xref:{smart-proxy-context}-networking_{context}[]. + +.Network requirements +* An unmanaged DHCP server available for clients. +* An unmanaged DNS server available for clients. +In case DNS is not available, use IP address to configure clients. + +.{Project} requirements +Although TFTP protocol is not used for HTTP UEFI Booting, {Project} use TFTP {SmartProxy} API to deploy boot loader configuration. + +* Ensure that both {ProjectServer} and {SmartProxy} have DNS configured and are able to resolve provisioned host names. +* Ensure that the UDP ports 67 and 68 are accessible by the client so that the client can send and receive a DHCP request and offer. +* Ensure that the TCP port 8000 is open for the client to download boot loader and Kickstart templates from the {SmartProxy}. +* Ensure that the TCP port {smartproxy_port} is open for the client to download the boot loader from the {SmartProxy} through HTTPS. +* Ensure that the host provisioning interface subnet has an HTTP Boot {SmartProxy} set. +* Ensure that the host provisioning interface subnet has a TFTP {SmartProxy} set. +* Ensure that the host provisioning interface subnet has a Templates {SmartProxy} set. diff --git a/guides/common/modules/con_http-booting.adoc b/guides/common/modules/con_http-booting.adoc new file mode 100644 index 00000000000..7aafb1b6cfb --- /dev/null +++ b/guides/common/modules/con_http-booting.adoc @@ -0,0 +1,4 @@ +[id="http-booting"] += HTTP booting + +You can use HTTP booting to boot systems over a network using HTTP. diff --git a/guides/common/modules/con_provisioning-concepts.adoc b/guides/common/modules/con_provisioning-concepts.adoc new file mode 100644 index 00000000000..5b01f87b0cc --- /dev/null +++ b/guides/common/modules/con_provisioning-concepts.adoc @@ -0,0 +1,6 @@ +[id="provisioning-concepts"] += Provisioning concepts + +An important feature of {ProjectName} is unattended provisioning of hosts. +To achieve this, {ProjectName} uses DNS and DHCP infrastructures, PXE booting, TFTP, and Kickstart. +Use this chapter to understand the working principle of these concepts. diff --git a/guides/common/modules/con_pxe-booting-requirements.adoc b/guides/common/modules/con_pxe-booting-requirements.adoc new file mode 100644 index 00000000000..84fece77a3d --- /dev/null +++ b/guides/common/modules/con_pxe-booting-requirements.adoc @@ -0,0 +1,24 @@ +[id="pxe-booting-requirements"] += PXE booting requirements + +To provision machines using PXE booting, ensure that you meet the following requirements: + +.Network requirements +* Optional: If the host and the DHCP server are separated by a router, configure the DHCP relay agent and point to the DHCP server. + +.Client requirements +* Ensure that all the network-based firewalls are configured to allow clients on the subnet to access the {SmartProxy}. +For more information, see xref:{smart-proxy-context}-networking_{context}[]. + +* Ensure that your client has access to the DHCP and TFTP servers. + +.{Project} requirements +* Ensure that both {ProjectServer} and {SmartProxy} have DNS configured and are able to resolve provisioned host names. +* Ensure that the UDP ports 67 and 68 are accessible by the client to enable the client to receive a DHCP offer with the boot options. +* Ensure that the UDP port 69 is accessible by the client so that the client can access the TFTP server on the {SmartProxy}. +* Ensure that the TCP port 80 is accessible by the client to allow the client to download files and Kickstart templates from the {SmartProxy}. +* Ensure that the host provisioning interface subnet has a DHCP {SmartProxy} set. +* Ensure that the host provisioning interface subnet has a TFTP {SmartProxy} set. +* Ensure that the host provisioning interface subnet has a Templates {SmartProxy} set. +* Ensure that DHCP with the correct subnet is enabled using the {Project} installer. +* Enable TFTP using the {Project} installer. diff --git a/guides/common/modules/con_pxe-booting.adoc b/guides/common/modules/con_pxe-booting.adoc new file mode 100644 index 00000000000..4a13f6a7770 --- /dev/null +++ b/guides/common/modules/con_pxe-booting.adoc @@ -0,0 +1,8 @@ +[id="pxe-booting"] += PXE booting + +Preboot execution environment (PXE) provides the ability to boot a system over a network. +Instead of using local hard drives or a CD-ROM, PXE uses DHCP to provide host with standard information about the network, to discover a TFTP server, and to download a boot image. +ifdef::satellite[] +For more information about setting up a PXE server see the Red{nbsp}Hat Knowledgebase solution https://access.redhat.com/solutions/163253[How to set-up/configure a PXE Server]. +endif::[] diff --git a/guides/common/modules/con_pxe-sequence.adoc b/guides/common/modules/con_pxe-sequence.adoc new file mode 100644 index 00000000000..1c04187c422 --- /dev/null +++ b/guides/common/modules/con_pxe-sequence.adoc @@ -0,0 +1,11 @@ +[id="pxe-sequence"] += PXE sequence + +. The host boots the PXE image if no other bootable image is found. +. A NIC of the host sends a broadcast request to the DHCP server. +. The DHCP server receives the request and sends standard information about the network: IP address, subnet mask, gateway, DNS, the location of a TFTP server, and a boot image. +. The host obtains the boot loader `image/pxelinux.0` and the configuration file `pxelinux.cfg/00:MA:CA:AD:D` from the TFTP server. +. The host configuration specifies the location of a kernel image, `initrd` and Kickstart. +. The host downloads the files and installs the image. + +For an example of using PXE Booting by {ProjectServer}, see {ProvisioningDocURL}provisioning-workflow_provisioning[Provisioning Workflow] in _{ProvisioningDocTitle}_. diff --git a/guides/common/modules/con_secure-boot.adoc b/guides/common/modules/con_secure-boot.adoc new file mode 100644 index 00000000000..a01c7dc0693 --- /dev/null +++ b/guides/common/modules/con_secure-boot.adoc @@ -0,0 +1,19 @@ +[id="secure-boot"] += Secure boot + +When {Project} is installed on {EL} using `{foreman-installer}`, grub2 and shim boot loaders that are signed by Red Hat are deployed into the TFTP and HTTP UEFI Boot directory. +PXE loader options named "SecureBoot" configure hosts to load `shim.efi`. + +On Debian and Ubuntu operating systems, the grub2 boot loader is created using the `grub2-mkimage` unsigned. +To perform the Secure Boot, the boot loader must be manually signed and key enrolled into the EFI firmware. +Alternatively, grub2 from Ubuntu or {EL} can be copied to perform booting. + +Grub2 in {EL} 8.0-8.3 were updated to mitigate https://access.redhat.com/security/vulnerabilities/grub2bootloader[Boot Hole Vulnerability] and keys of existing {EL} kernels were invalidated. +To boot any of the affected {EL} kernel (or operating system installer), you must enroll keys manually into the EFI firmware for each host: + +[options="nowrap" subs="+quotes,attributes"] +---- +# pesign -P -h -i /boot/vmlinuz- +# mokutil --import-hash +# reboot +---- diff --git a/guides/common/modules/ref_additional-resources-project-infrastructure-organization-concepts.adoc b/guides/common/modules/ref_additional-resources-project-infrastructure-organization-concepts.adoc index d685281d180..9a611f34913 100644 --- a/guides/common/modules/ref_additional-resources-project-infrastructure-organization-concepts.adoc +++ b/guides/common/modules/ref_additional-resources-project-infrastructure-organization-concepts.adoc @@ -1,4 +1,4 @@ [id="additional-resources-project-infrastructure-organization-concepts_{context}"] = Additional resources -* For examples of {Project} deployment, see xref:part-Deployment_Planning[]. +* For examples of {Project} deployment, see xref:{project-context}-deployment-planning[]. diff --git a/guides/doc-Planning_for_Project/topics/Required_Technical_Users.adoc b/guides/common/modules/ref_technical-users-provided-and-required-by-foreman.adoc similarity index 89% rename from guides/doc-Planning_for_Project/topics/Required_Technical_Users.adoc rename to guides/common/modules/ref_technical-users-provided-and-required-by-foreman.adoc index 84b24aad043..e05be68e717 100644 --- a/guides/doc-Planning_for_Project/topics/Required_Technical_Users.adoc +++ b/guides/common/modules/ref_technical-users-provided-and-required-by-foreman.adoc @@ -1,8 +1,5 @@ -:numbered!: - -[appendix] -[[chap-Documentation-Architecture_Guide-Required_Technical_Users]] -== Technical users provided and required by {Project} +[id="technical-users-provided-and-required-by-{project-context}"] += Technical users provided and required by {Project} During the installation of {Project}, system accounts are created. They are used to manage files and process ownership of the components integrated into {Project}. @@ -17,8 +14,6 @@ Do not change the home and shell directories of system accounts because they are Because of potential conflicts with local users that {Project} creates, you cannot use external identity providers for the system users of the {Project} base operating system. -[[tabl-Documentation-Architecture_Guide-Technical_Users_Provided_and_Required_by_Satellite]] - .Technical users provided and required by {Project} [options="header"] |==== diff --git a/guides/doc-Planning_for_Project/master.adoc b/guides/doc-Planning_for_Project/master.adoc index a848510eee8..672d652ad0b 100644 --- a/guides/doc-Planning_for_Project/master.adoc +++ b/guides/doc-Planning_for_Project/master.adoc @@ -15,11 +15,7 @@ ifdef::satellite[] include::common/modules/proc_providing-feedback-on-red-hat-documentation.adoc[leveloffset=+1] endif::[] -[id="Project_Overview_and_Concepts_{context}"] -= {Project} overview and concepts - -{ProjectName} is a centralized tool for provisioning, remote management, and monitoring of multiple {EL} deployments. -With {Project}, you can deploy, configure, and maintain your systems across physical, virtual, and cloud environments. +include::common/modules/con_foreman-overview-and-concepts.adoc[] include::common/assembly_content-and-patch-management-with-project.adoc[leveloffset=+1] @@ -33,20 +29,36 @@ include::common/assembly_tools-for-administration-of-project.adoc[leveloffset=+1 include::common/assembly_supported-usage-and-versions-of-project-components.adoc[leveloffset=+1] -[[part-Deployment_Planning]] -= {Project} deployment planning +include::common/modules/con_foreman-deployment-planning.adoc[] include::common/assembly_deployment-path.adoc[leveloffset=+1] include::common/assembly_common-deployment-scenarios.adoc[leveloffset=+1] -include::topics/Provisioning_Concepts.adoc[] +include::common/modules/con_provisioning-concepts.adoc[leveloffset=+1] + +include::common/modules/con_pxe-booting.adoc[leveloffset=+2] + +include::common/modules/con_pxe-sequence.adoc[leveloffset=+3] + +include::common/modules/con_pxe-booting-requirements.adoc[leveloffset=+3] + +include::common/modules/con_http-booting.adoc[leveloffset=+2] -include::topics/Required_Technical_Users.adoc[] +include::common/modules/con_http-booting-requirements-with-managed-dhcp.adoc[leveloffset=+3] + +include::common/modules/con_http-booting-requirements-with-unmanaged-dhcp.adoc[leveloffset=+3] + +ifdef::foreman-el,katello,orcharhino[] +include::common/modules/con_secure-boot.adoc[leveloffset=+2] endif::[] :!numbered: +[appendix] +include::common/modules/ref_technical-users-provided-and-required-by-foreman.adoc[leveloffset=+1] +endif::[] + [appendix] include::common/modules/ref_glossary-of-terms-used-in-project.adoc[leveloffset=+1] diff --git a/guides/doc-Planning_for_Project/topics/Provisioning_Concepts.adoc b/guides/doc-Planning_for_Project/topics/Provisioning_Concepts.adoc deleted file mode 100644 index bc81e30bfae..00000000000 --- a/guides/doc-Planning_for_Project/topics/Provisioning_Concepts.adoc +++ /dev/null @@ -1,132 +0,0 @@ -[[chap-Architecture_Guide-Provisioning_Concepts]] - -== Provisioning concepts -An important feature of {ProjectName} is unattended provisioning of hosts. -To achieve this, {ProjectName} uses DNS and DHCP infrastructures, PXE booting, TFTP, and Kickstart. -Use this chapter to understand the working principle of these concepts. - -=== PXE booting -Preboot execution environment (PXE) provides the ability to boot a system over a network. -Instead of using local hard drives or a CD-ROM, PXE uses DHCP to provide host with standard information about the network, to discover a TFTP server, and to download a boot image. -ifdef::satellite[] -For more information about setting up a PXE server see the Red{nbsp}Hat Knowledgebase solution https://access.redhat.com/solutions/163253[How to set-up/configure a PXE Server]. -endif::[] - -==== PXE sequence - -. The host boots the PXE image if no other bootable image is found. -. A NIC of the host sends a broadcast request to the DHCP server. -. The DHCP server receives the request and sends standard information about the network: IP address, subnet mask, gateway, DNS, the location of a TFTP server, and a boot image. -. The host obtains the boot loader `image/pxelinux.0` and the configuration file `pxelinux.cfg/00:MA:CA:AD:D` from the TFTP server. -. The host configuration specifies the location of a kernel image, `initrd` and Kickstart. -. The host downloads the files and installs the image. - -For an example of using PXE Booting by {ProjectServer}, see {ProvisioningDocURL}provisioning-workflow_provisioning[Provisioning Workflow] in _{ProvisioningDocTitle}_. - -==== PXE booting requirements -To provision machines using PXE booting, ensure that you meet the following requirements: - -.Network requirements - -* Optional: If the host and the DHCP server are separated by a router, configure the DHCP relay agent and point to the DHCP server. - -.Client requirements - -* Ensure that all the network-based firewalls are configured to allow clients on the subnet to access the {SmartProxy}. -For more information, see xref:{smart-proxy-context}-networking_{context}[]. - -* Ensure that your client has access to the DHCP and TFTP servers. - -.{Project} requirements -* Ensure that both {ProjectServer} and {SmartProxy} have DNS configured and are able to resolve provisioned host names. -* Ensure that the UDP ports 67 and 68 are accessible by the client to enable the client to receive a DHCP offer with the boot options. -* Ensure that the UDP port 69 is accessible by the client so that the client can access the TFTP server on the {SmartProxy}. -* Ensure that the TCP port 80 is accessible by the client to allow the client to download files and Kickstart templates from the {SmartProxy}. -* Ensure that the host provisioning interface subnet has a DHCP {SmartProxy} set. -* Ensure that the host provisioning interface subnet has a TFTP {SmartProxy} set. -* Ensure that the host provisioning interface subnet has a Templates {SmartProxy} set. -* Ensure that DHCP with the correct subnet is enabled using the {Project} installer. -* Enable TFTP using the {Project} installer. - -[[http-booting]] -=== HTTP booting -You can use HTTP booting to boot systems over a network using HTTP. - -[[http-booting-requirements]] -==== HTTP booting requirements with managed DHCP -To provision machines through HTTP booting ensure that you meet the following requirements: - -.Client requirements - -For HTTP booting to work, ensure that your environment has the following client-side configurations: - -* All the network-based firewalls are configured to allow clients on the subnet to access the {SmartProxy}. -For more information, see xref:{smart-proxy-context}-networking_{context}[]. -* Your client has access to the DHCP and DNS servers. -* Your client has access to the HTTP UEFI Boot {SmartProxy}. - -.Network requirements -* Optional: If the host and the DHCP server are separated by a router, configure the DHCP relay agent and point to the DHCP server. - -.{Project} requirements -Although TFTP protocol is not used for HTTP UEFI Booting, {Project} uses TFTP {SmartProxy} API to deploy boot loader configuration. - -For HTTP booting to work, ensure that {Project} has the following configurations: - -* Both {ProjectServer} and {SmartProxy} have DNS configured and are able to resolve provisioned host names. -* The UDP ports 67 and 68 are accessible by the client so that the client can send and receive a DHCP request and offer. -* Ensure that the TCP port 8000 is open for the client to download the boot loader and Kickstart templates from the {SmartProxy}. -* The TCP port {smartproxy_port} is open for the client to download the boot loader from the {SmartProxy} using the HTTPS protocol. -* The subnet that functions as the host's provisioning interface has a DHCP {SmartProxy}, an HTTP Boot {SmartProxy}, a TFTP {SmartProxy}, and a Templates {SmartProxy} - -==== HTTP booting requirements with unmanaged DHCP -To provision machines through HTTP booting without managed DHCP ensure that you meet the following requirements: - -.Client requirements - -* HTTP UEFI Boot URL must be set to one of: -** `\http://{smartproxy-example-com}:8000` -** `\https://{smartproxy-example-com}:{smartproxy_port}` -* Ensure that your client has access to the DHCP and DNS servers. -* Ensure that your client has access to the HTTP UEFI Boot {SmartProxy}. -* Ensure that all the network-based firewalls are configured to allow clients on the subnet to access the {SmartProxy}. -For more information, see xref:{smart-proxy-context}-networking_{context}[]. - -.Network requirements - -* An unmanaged DHCP server available for clients. -* An unmanaged DNS server available for clients. -In case DNS is not available, use IP address to configure clients. - -.{Project} requirements - -Although TFTP protocol is not used for HTTP UEFI Booting, {Project} use TFTP {SmartProxy} API to deploy boot loader configuration. - -* Ensure that both {ProjectServer} and {SmartProxy} have DNS configured and are able to resolve provisioned host names. -* Ensure that the UDP ports 67 and 68 are accessible by the client so that the client can send and receive a DHCP request and offer. -* Ensure that the TCP port 8000 is open for the client to download boot loader and Kickstart templates from the {SmartProxy}. -* Ensure that the TCP port {smartproxy_port} is open for the client to download the boot loader from the {SmartProxy} through HTTPS. -* Ensure that the host provisioning interface subnet has an HTTP Boot {SmartProxy} set. -* Ensure that the host provisioning interface subnet has a TFTP {SmartProxy} set. -* Ensure that the host provisioning interface subnet has a Templates {SmartProxy} set. - -ifdef::foreman-el,katello,orcharhino[] -=== Secure boot - -When {Project} is installed on {EL} using `{foreman-installer}`, grub2 and shim boot loaders that are signed by Red Hat are deployed into the TFTP and HTTP UEFI Boot directory. -PXE loader options named "SecureBoot" configure hosts to load `shim.efi`. - -On Debian and Ubuntu operating systems, the grub2 boot loader is created using the `grub2-mkimage` unsigned. -To perform the Secure Boot, the boot loader must be manually signed and key enrolled into the EFI firmware. -Alternatively, grub2 from Ubuntu or {EL} can be copied to perform booting. - -Grub2 in {EL} 8.0-8.3 were updated to mitigate https://access.redhat.com/security/vulnerabilities/grub2bootloader[Boot Hole Vulnerability] and keys of existing {EL} kernels were invalidated. -To boot any of the affected {EL} kernel (or operating system installer), you must enroll keys manually into the EFI firmware for each host: - -[options="nowrap" subs="+quotes,attributes"] ----- -# pesign -P -h -i /boot/vmlinuz- -# mokutil --import-hash -# reboot ----- -endif::[]