Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

此内容没有您所选择的语言版本。

7.3. Installing Using the pkispawn Utility

Read the following section carefully to ensure that you make the right choices when following the installation examples in this section.

7.3.1. About the pkispawn Utility
复制链接

In Red Hat Certificate System, administrators set up the individual public key infrastructure (PKI) subsystems by running the pkispawn utility.
The pkispawn utility requires a configuration file. This file contains parameters that are grouped into sections. These sections are stacked, so that parameters defined in earlier sections can be overridden by parameters defined in later sections. The sections are read in the following order:
  1. [DEFAULT]
  2. [Tomcat]
  3. The subsystem-specific sections: [CA], [KRA], [OCSP], [TKS], or [TPS]
During the setup, pkispawn:
  1. First reads the default values from the /etc/pki/default.cfg file.

    Important

    Do not edit the /etc/pki/default.cfg file. You will be instructed to create a configuration file that overrides the defaults when passed to the pkispawn utility. Parameters not set in the configuration file use the defaults. For details about using a configuration file, see Section 7.3.2, “Two-step Installation Using pkispawn”.
  2. Reads the administrator-provided configuration file mentioned above to override the default values.
  3. Performs the installation of the requested PKI subsystem.
  4. Passes the settings to a Java servlet that performs the configuration based on the settings.
For general information about pkispawn and examples, see the pkispawn(8) and pki_default.cfg(5) man pages.
For instructions about how to install a CA, KRA, or OCSP subsystem, see Section 7.3.2, “Two-step Installation Using pkispawn”.
For instructions about how to install a TKS or TPS subsystem, see Section 7.3.3, “Single-step Installation Using pkispawn (TMS-only)”.

7.3.2. Two-step Installation Using pkispawn
复制链接

To install a CA, KRA, or OCSP subsystem, use the pkispawn two-step installation to enable the administrator to manually update configuration files between the two parts of the installation.
The name two-step installation comes from the fact that the pkispawn utility is often run twice with a slightly different set of parameters in its overwrite configuration file to complete the installation.
The two-step installation is consisted of the following major parts:
  1. Installation using the pkispawn Utility (Step 1)
    During this step, pkispawn copies configuration files from the /usr/share/pki/ directory to the instance-specific /etc/pki/instance_name/ directory. Additionally, pkispawn sets the settings based on values defined in the deployment configuration file.
    This part of the installation contains the following substeps:
    1. Section 7.3.2.1, “Creating the Configuration File for the First Step of the Installation”
    2. Section 7.3.2.2, “Starting the pkispawn Step One Installation”
  2. Between-step configuration and customization
    For details, see Section 7.3.2.3, “Configuration Between the Two pkispawn Installation Steps”.
  3. Configuration Using the pkispawn Utility (Step 2)
    During this step, pkispawn is run to continue the installation based on the configuration files in the instance-specific /etc/pki/instance_name/ directory.
    For details about this part of the installation see Section 7.3.2.4, “Starting the pkispawn Step Two Installation”.
Depending on your environment, additional configuration and customization steps are required.
Create a text file for the pkispawn configuration settings, such as /root/pki/config.subsystem.txt, and fill it with the settings described below. Every setting must be added.

Important

This section describes a minimum configuration with Directory Server running on the same host as Certificate System. Depending on your environment, additional parameters may be necessary. For additional examples, see the EXAMPLES section in the pkispawn(8) man page.

Subsystem-independent Settings

Independently of the subsystem you install, the following settings are required in the configuration file in the:
  • [DEFAULT] section:
    1. Set a unique instance name: 
      pki_instance_name=instance_name
    2. Set the host name and security domain name: 
      pki_host=server.example.com
pki_security_domain_name=example.com Security Domain
pki_security_domain_user=caadmin
pki_security_domain_password=SD password

      Note

      Certificate System creates unique certificate nicknames based on these parameters and the instance name. The uniqueness of certificate nicknames is very important in keeping the HSM token shared by multiple PKI instances functional.
    3. Set the port numbers for the HTTP and HTTPS protocols: 
      pki_https_port=port_number
pki_http_port=port_number

      Important

      To run more than one Certificate System instance on the same host, you must set ports in the pki_https_port and pki_http_port parameters that are not used by any other service on the host. By default, Certificate System uses port 8080 for HTTP and 8443 for HTTPS.
    4. Set the HSM-specific parameters: 
      pki_hsm_enable=True
pki_hsm_libfile=HSM_PKCS11_library_path
pki_hsm_modulename=HSM_module_name
pki_token_name=HSM_token_name
pki_token_password=HSM_token_password


pki_audit_signing_token=HSM_token_name
pki_subsystem_token=HSM_token_name
pki_sslserver_token=HSM_token_name
      For further details, see Section 6.4.4, “Preparing for Installing Certificate System with an HSM”.
    5. If building an RSA Certificate System instance, use the following configuration: 
      pki_admin_key_algorithm=SHA256withRSA
pki_admin_key_size=4096
pki_admin_key_type=rsa
pki_sslserver_key_algorithm=SHA256withRSA
pki_sslserver_key_size=4096
pki_sslserver_key_type=rsa
pki_subsystem_key_algorithm=SHA256withRSA
pki_subsystem_key_size=4096
pki_subsystem_key_type=rsa
pki_audit_signing_key_algorithm=SHA256withRSA
pki_audit_signing_key_size=4096
pki_audit_signing_key_type=rsa
pki_audit_signing_signing_algorithm=SHA256withRSA
      Allowed choices for the key_algorithm parameters are:
      • SHA256withRSA
      • SHA384withRSA
      • SHA512withRSA

      Note

      You can set this parameter to each value specified in the ca.profiles.defaultSigningAlgsAllowed parameter in the CA's CS.cfg file. For details, see the Signing Algorithm Constraint section in the Red Hat Certificate System Administration Guide (Common Criteria Edition).
      Signature algorithm (RSA) must match key_type (rsa).
      Allowed choices for key_type is only rsa.
      Allowed choices for key_size are 2048 and 4096.
    6. To use Elliptic Curve Cryptography (ECC) instead of RSA when creating certificates, set: 
      pki_admin_key_algorithm=SHA256withEC
pki_admin_key_size=nistp256
pki_admin_key_type=ecc
pki_sslserver_key_algorithm=SHA256withEC
pki_sslserver_key_size=nistp256
pki_sslserver_key_type=ecc
pki_subsystem_key_algorithm=SHA256withEC
pki_subsystem_key_size=nistp256
pki_subsystem_key_type=ecc
pki_audit_signing_key_algorithm=SHA256withEC
pki_audit_signing_key_size=nistp256
pki_audit_signing_key_type=ecc
pki_audit_signing_signing_algorithm=SHA256withEC
      Allowed choices for the key_algorithm parameters are:
      • SHA256withEC
      • SHA384withEC
      • SHA512withEC

      Note

      You can set this parameter to each value specified in the ca.profiles.defaultSigningAlgsAllowed parameter in the CA's CS.cfg file. For details, see the Signing Algorithm Constraint section in the Red Hat Certificate System Administration Guide (Common Criteria Edition).
      Signature algorithm (EC) must match key_type (ecc).
      Allowed choices for key_size are:
      • nistp256
      • nistp384
      • nistp521
      Allowed choice for key_type is ecc
    7. Set the client directory of the bootstrap admin user: 
      pki_client_dir=bootstrap_admin_directory
      By default, the path is set to ~/.dogtag/instance_name/

      Important

      The pki_admin_* and pki_client_* parameters belong to the bootstrap user that is automatically created by the installation process. For further information about default roles (privileges) and the bootstrap user, see Section 2.6.6, “Users, Authorization, and Access Controls”.
      For descriptions about the parameters covered in this section, see the pki_default.cfg(5) man page.
    8. Set various passwords for the bootstrap admin user: 
      pki_admin_password=password
pki_client_database_password=password
pki_client_pkcs12_password=password
    9. Set the parameters for the LDAPS connection to Directory Server running on the same host: 
      pki_ds_database=back-end database name
pki_ds_hostname=hostname
pki_ds_secure_connection=True
pki_ds_secure_connection_ca_pem_file=path_to_CA_or_self-signed_certificate
pki_ds_password=password
    10. If you use a self-signed certificate in Directory Server use the following command to export it from the Directory Server's Network Security Services (NSS) database: 
      # certutil -L -d /etc/dirsrv/slapd-instance_name/ \
     -n "server-cert" -a -o /root/ds.crt
  • [Tomcat] section:
    1. Set the Tomcat JServ Protocol (AJP) port: 
      pki_ajp_port=Tomcat_AJP_port
    2. Set the Tomcat server port: 
      pki_tomcat_server_port=Tomcat_server_port

    Important

    To run more than one PKI subsystem instance on the same host, you must set ports in the pki_ajp_port and pki_tomcat_server_port parameters that are not used by any other service on the host. By default, the pki_ajp_port is set to 8009 and pki_tomcat_server_port to 8005.
For non-TMS, after you created the initial configuration file, add the subsystem-specific settings to it. See:
For TMS, to continue creating the configuration file for the pkispawn single-step Installation, see Section 7.3.3.1, “Creating the Configuration File for pkispawn single-step Installation”.

CA Settings

In addition to the section called “Subsystem-independent Settings”, you need the following settings in the [CA] section to install a CA:
  1. Enable random serial numbers by adding following setting: 
    pki_random_serial_numbers_enable=true
  2. Set the following parameters to specify the data of the bootstrap admin user, which will be automatically created during the installation: 
    pki_admin_nickname=bootstrap_CA_admin
pki_admin_name=bootstrap_CA_administrator_name
pki_admin_uid=caadmin
pki_admin_email=caadmin@example.com
    Certificate System assigns administrator and agent privileges to this bootstrap account. Use this account after the installation to create actual administrator, agent, and auditor accounts.
  3. Specify the HSM token for the subsystem-dependent certificates: 
    pki_ca_signing_token=HSM_token_name
pki_ocsp_signing_token=HSM_token_name
  4. If building an RSA-based CA, use the following configuration: 
    pki_ca_signing_key_algorithm=SHA256withRSA
pki_ca_signing_key_size=4096
pki_ca_signing_key_type=rsa
pki_ca_signing_signing_algorithm=SHA256withRSA
pki_ocsp_signing_key_algorithm=SHA256withRSA
pki_ocsp_signing_key_size=4096
pki_ocsp_signing_key_type=rsa
pki_ocsp_signing_signing_algorithm=SHA256withRSA
    Allowed choices for the key_algorithm parameters are:
    • SHA256withRSA
    • SHA384withRSA
    • SHA384withRSA

    Note

    You can set this parameter to each value specified in the ca.profiles.defaultSigningAlgsAllowed parameter in the CA's CS.cfg file. For details, see the Signing Algorithm Constraint section in the Red Hat Certificate System Administration Guide (Common Criteria Edition).
    Signature algorithm (RSA) must match key_type (rsa).
    Allowed choices for key_size parameters are:
    • 2048
    • 4096
    Allowed choices for key_type parameters are only rsa.
  5. By default, the key type for system certificates is rsa and the key length is 2048 bit. To use Elliptic Curve Cryptography (ECC) instead of RSA when creating certificates, set: 
    pki_ocsp_signing_key_algorithm=SHA256withEC
pki_ocsp_signing_key_size=nisp256
pki_ocsp_signing_key_type=ecc
pki_ocsp_signing_signing_algorithm=SHA256withEC
    Allowed choices for key_algorithm parameters are:
    • SHA256withEC
    • SHA384withEC
    • SHA512withEC

    Note

    You can set this parameter to each value specified in the ca.profiles.defaultSigningAlgsAllowed parameter in the CA's CS.cfg file. For details, see the Signing Algorithm Constraint section in the Red Hat Certificate System Administration Guide (Common Criteria Edition).
    Signature algorithm (EC) must match key_type (ecc).
    Allowed choices for key_size parameters are:
    • nistp256
    • nistp384
    • nistp521
    Allowed choices for key_type parameters is ecc.

Settings for Other Subsystems

In addition to the section called “Subsystem-independent Settings”, you need the following settings in the [CA], [KRA], or [OCSP] section to install a subordinate CA, KRA, or OCSP:
  1. Subsystems that are not a root CA use the two-step installation mechanism that is sometimes referred to as External CA. For the first step, add the following parameters under each respective subsystem-specific section: 
    pki_external=True
pki_external_step_two=False
  2. This step depends on the subsystem you are installing:
    Subordinate CA
    Add the following settings to the [CA] section:
    1. Add all settings from the [CA] section of the root CA.
    2. Set the output paths for the system certificate signing requests (CSR): 
      pki_ca_signing_csr_path=path
pki_ocsp_signing_csr_path=path
pki_audit_signing_csr_path=path
pki_sslserver_csr_path=path
pki_subsystem_csr_path=path
pki_admin_csr_path=path
    OCSP
    Set the following in the [OCSP] section:
    1. Specify the following parameters to set the data of the bootstrap OCSP admin user which is automatically created during the installation: 
      pki_admin_nickname=bootstrap_OCSP_admin
pki_admin_name=bootstrap_OCSP_administrator_name
pki_admin_uid=ocspadmin
pki_admin_email=ocspadmin@example.com
      Certificate System assigns administrator and agent privileges to this bootstrap account. Use this account after the installation to create actual administrator, agent, and auditor accounts.
    2. Specify the HSM token for the subsystem-dependent certificates: 
      pki_ocsp_signing_token=HSM_token_name
    3. If building an RSA Certificate System instance, use the following configuration: 
      pki_ocsp_signing_key_algorithm=SHA256withRSA
pki_ocsp_signing_key_size=4096
pki_ocsp_signing_key_type=rsa
pki_ocsp_signing_signing_algorithm=SHA256withRSA
      Allowed choices for the key_algorithm parameters are:
      • SHA256withRSA
      • SHA384withRSA
      • SHA384withRSA

      Note

      You can set this parameter to each value specified in the ca.profiles.defaultSigningAlgsAllowed parameter in the CA's CS.cfg file. For details, see the Signing Algorithm Constraint section in the Red Hat Certificate System Administration Guide (Common Criteria Edition).
      Signature algorithm (RSA) must match key_type (rsa).
      Allowed choices for key_size parameters are:
      • 2048
      • 4096
      Allowed choices for key_type parameters are only rsa.

      Note

      It is suggested to match your CA instance type (RSA or ECC) with your OCSP responder type (RSA or ECC).
    4. To use Elliptic Curve Cryptography (ECC) instead of RSA when creating certificates, set: 
      pki_ocsp_signing_key_algorithm=SHA256withEC
pki_ocsp_signing_key_size=nisp256
pki_ocsp_signing_key_type=ecc
pki_ocsp_signing_signing_algorithm=SHA256withEC
      Allowed choices for the key_algorithm parameters are:
      • SHA256withEC
      • SHA384withEC
      • SHA512withEC

      Note

      You can set this parameter to each value specified in the ca.profiles.defaultSigningAlgsAllowed parameter in the CA's CS.cfg file. For details, see the Signing Algorithm Constraint section in the Red Hat Certificate System Administration Guide (Common Criteria Edition).
      Signature algorithm (EC) must match key_type (ecc).
      Allowed choices for key_size parameters are:
      • nistp256
      • nistp384
      • nistp521
      Allowed choices for key_type parameters are only ecc.

      Note

      It is suggested to match your CA instance type (RSA or ECC) with your OCSP responder type (RSA or ECC).
    5. Set the output paths for the system certificate signing requests (CSR): 
      pki_ocsp_signing_csr_path=path
pki_audit_signing_csr_path=path
pki_sslserver_csr_path=path
pki_subsystem_csr_path=path
pki_admin_csr_path=path
    KRA
    Set the following in the [KRA] section:
    1. Specify the following parameters to set the data of the bootstrap KRA admin user which is automatically created during the installation: 
      pki_admin_nickname=bootstrap_KRA_admin
pki_admin_name=bootstrap_KRA_administrator_name
pki_admin_uid=kraadmin
pki_admin_email=kraadmin@example.com
      Certificate System assigns administrator and agent privileges to this bootstrap account. Use this account after the installation to create actual administrator, agent, and auditor accounts.
    2. Specify the HSM token for the subsystem-dependent certificates: 
      pki_transport_token=HSM_token_name
pki_storage_token=HSM_token_name
    3. RSA is the only key type supported for both the KRA storage and transport certificates. By default, the key length is 2048 bit. To choose a 4096 bit key instead, add the following parameters: 
      pki_transport_key_size=4096
pki_storage_key_size=4096
    4. Set the output paths for the system certificate signing requests (CSR): 
      pki_kra_signing_csr_path=path
pki_audit_signing_csr_path=path
pki_sslserver_csr_path=path
pki_subsystem_csr_path=path
pki_admin_csr_path=path

7.3.2.2. Starting the pkispawn Step One Installation
复制链接

After you prepared the configuration file as described in Section 7.3.2.1, “Creating the Configuration File for the First Step of the Installation”, start the first step of the installation:
  • For a root CA: 
    # pkispawn -f /root/pki/config.root-CA.txt -s CA
  • For a subordinate CA or other non-CA subsystems: 
    # pkispawn -f /root/pki/config.subsystem.txt -s subsystem
    Replace subsystem with one of the following subsystems: CA, KRA, or OCSP. For example, for a KRA installation: 
    # pkispawn -f /root/pki/config.KRA.txt -s KRA
After the installation step described in Section 7.3.2.2, “Starting the pkispawn Step One Installation” has finished successfully, you can manually update the instance-specific configuration files before Section 7.3.2.4, “Starting the pkispawn Step Two Installation” is performed, where the actual configuration begins.
For required procedures, perform the actions described in this section after you have completed step 1 of the pkispawn procedure.
For optional procedures, see Part III, “Configuring Certificate System”. Useful between-installation-step procedures include:
7.3.2.3.1. Enabling Signed Audit Logging
复制链接
The signed audit logging feature enables the prevention of unauthorized log manipulation.
For details, see Section 13.3.1, “Enabling and Configuring Signed Audit Log”.
7.3.2.3.2. Setting the KRA into Encryption Mode
复制链接
If you are using a Hardware Security Module (HSM) that does not support secure key extraction, it is necessary to set the Key Recovery Authority (KRA) into encryption mode. For details, see Section 12.2.2.2, “Solving Limitations of HSMs When Using AES Encryption in KRAs”.
7.3.2.3.3. Enabling OCSP
复制链接
For details about enabling the Online Certificate Status Protocol (OCSP) see Section 9.4.1.2, “Enabling Certificate Revocation Checking for Subsystems”.

7.3.2.4. Starting the pkispawn Step Two Installation
复制链接

After you have completed Section 7.3.2.3, “Configuration Between the Two pkispawn Installation Steps”, start the second step of the pkispawn installation:
  • Root CA: 
    # pkispawn -f /root/pki/config.root-CA.txt -s CA --skip-installation
    If the configuration step succeeds, the pkispawn utility displays an installation summary. For example: 
    ================================================================
                       INSTALLATION SUMMARY
================================================================

  Administrator's username:             caadmin
  Administrator's PKCS #12 file:
        /root/.dogtag/instance_name/ca_admin_cert.p12

  To check the status of the subsystem:
        systemctl status pki-tomcatd@instance_name.service

  To restart the subsystem:
        systemctl restart pki-tomcatd@instance_name.service

  The URL for the subsystem is:
        https://server.example.com:8443/ca/

  PKI instances will be enabled upon system boot

================================================================
  • Subordinate CA or other non-CA subsystems:
    1. Submit the CSRs to a CA to issue the certificates.
      One major difference between installing non-root CA subsystems and a root CA is that prior to running step two of the pkispawn utility, other subsystems require submitting the system certificate signing requests (CSR) to a CA:
      In the first step of the section called “Settings for Other Subsystems”, you added the *_csr_path parameters in the pkispawn configuration file for the subsystems to be installed. If the first step of pkispawn succeeded, Certificate System generated and stored the CSRs in the specified paths. These certificate requests are in PKCS#10 format and you must convert them to Certificate Management over CMS (CMC) format before submitting them to the CA. Follow instructions specified at 4.2. Creating Certificate Signing Requests in Red Hat Certificate System Administration Guide. You need the resulting system certificates when you execute the second step of the pkispawn command.
      Additionally, you need the issuing CA's certificate chain in PKCS#7 format. To retrieve it:
      1. Access the issuing CA's EE URL.
      2. Navigate to Retrieval Import CA Certificate Chain and click Display the CA certificate chain in PKCS#7 for importing into a server.
      3. Click Submit.
      4. Copy the displayed PKCS#7-formatted output into a text file, such as /root/pki/cert_chain.p7b, on the Certificate System host.
    2. Create a configuration file for the second step of the pkispawn command:
      1. Copy the pkispawn configuration file from the first step and edit the newly created file for step two of the pkispawn command:
        1. In the [DEFAULT] section, set the path to the issuing CA's certificate chain file you prepared in the previous step and the CA signing certificate's nickname. For example: 
          [DEFAULT]
pki_ca_signing_nickname=CA Signing Certificate
pki_ca_signing_cert_path=/root/pki/cert_chain.p7b
        2. Add the following settings to the subsystem-specific section ([CA], [KRA], or [OCSP]) depending on the subsystem you install:
          Subordinate CA
          pki_ca_signing_crt_path=/root/pki/subsystem/ocsp_signing.crt
pki_subsystem_crt_path=/root/pki/subsystem/subsystem.crt
pki_sslserver_crt_path=/root/pki/subsystem/sslserver.crt
pki_audit_signing_crt_path=/root/pki/subsystem/ca_audit_signing.crt
pki_admin_crt_path=/root/pki/subsystem/ca_admin.crt
pki_external_step_two=True
          OCSP
          pki_ocsp_signing_crt_path=/root/pki/subsystem/ocsp_signing.crt
pki_subsystem_crt_path=/root/pki/subsystem/subsystem.crt
pki_sslserver_crt_path=/root/pki/subsystem/sslserver.crt
pki_audit_signing_crt_path=/root/pki/subsystem/ocsp_audit_signing.crt
pki_admin_crt_path=/root/pki/subsystem/ocsp_admin.crt
pki_external_step_two=True
          KRA
          pki_storage_crt_path=/root/pki/subsystem/kra_storage.crt
pki_transport_crt_path=/root/pki/subsystem/kra_transport.crt
pki_subsystem_crt_path=/root/pki/subsystem/subsystem.crt
pki_sslserver_crt_path=/root/pki/subsystem/sslserver.crt
pki_audit_signing_crt_path=/root/pki/subsystem/kra_audit_signing.crt
pki_admin_crt_path=/root/pki/subsystem/kra_admin.crt
pki_external_step_two=True
    3. Run the pkispawn command: 
      # pkispawn -f /root/pki/config.subsystem.txt -s subsystem
      Replace subsystem with one of the following subsystems: CA, KRA, or OCSP. For example, for a KRA installation: 
      # pkispawn -f /root/pki/config.KRA.txt -s KRA

7.3.3. Single-step Installation Using pkispawn (TMS-only)
复制链接

TPS and TKS subsystems can be installed by using the pkispawn single-step installation process.
pkispawn requires a configuration file.
Follow the section called “Subsystem-independent Settings” to fill in the subsystem-independent part of the pkispawn configuration file.
In addition, under the [DEFAULT] section add the following: 
pki_security_domain_hostname=example.redhat.com
pki_security_domain_https_port=8443
pki_security_domain_user=caadmin
pki_security_domain_password=[SD password]
Then add the subsystem-specific section ([TKS] or [TPS]) as following:
TKS
Set the following in the [TKS] section:
  • Specify the following parameters to set the data of the bootstrap TKS admin user which is automatically created during the installation: 
    pki_admin_nickname=bootstrap_TKS_admin
pki_admin_name=bootstrap_TKS_administrator_name
pki_admin_uid=tksadmin
pki_admin_email=tksadmin@example.com
    Red Hat Certificate System assigns administrator and agent privileges to this bootstrap account. Use this account after the installation to create the administrator, and auditor accounts.
TPS
Set the following in the [TPS] section:
  1. Specify the following parameters to set the data of the bootstrap TPS admin user, which is automatically created during the installation: 
    pki_admin_nickname=bootstrap_TPS_admin
pki_admin_name=bootstrap_TPS_administrator_name
pki_admin_uid=tpsadmin
pki_admin_email=tpsadmin@example.com
    Red Hat Certificate System assigns administrator and agent privileges to this bootstrap account. Use this account after the installation to create the administrator, and the auditor accounts.
  2. Set the LDAP base DN of the TPS authentication database: 
    pki_authdb_basedn=base_DN_of_the_TPS_authentication_database
  3. Enable the server-side key generation and archival: 
    pki_enable_server_side_keygen=True

7.3.3.2. Running pkispawn for single-step Installation
复制链接

Run the pkispawn command:
# pkispawn -f /root/pki/config.TKS.txt -s TKS
or
# pkispawn -f /root/pki/config.TPS.txt -s TPS

7.3.3.3. Post-Installation for Single-Step Installation
复制链接

Follow the procedures below:
Once you completed the procedures above, follow Section 7.4, “Post-installation Tasks” for additional post-installation actions.
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2026 Red Hat返回顶部