Checking the cluster configuration

You must check and edit the shared sections of the compiled custom resource file before you apply it to the operator.

About this task

In all cases, check the <Required> values for the image_pull_secrets and images parameters in the shared_configuration section. For more information, see Shared configuration parameters.

Table 1. Checking `<Required>` parameters for selected images
Parameter	Description
dbcompatibility_init_container	Repository from where to pull the Application Engine `init_container` and the corresponding tag.
image_pull_secrets	Secrets in your target namespace to pull images from the specified repository.

Procedure

Locate the shared_configuration section in the custom resource (CR) file in the YAML View in the OCP console or the file that you created by using the deployment script, then check and correct the deployment parameters.
The custom resource templates can include the following parameters:
License parameters
Note: You can ignore the sc_deployment_license and sc_deployment_baw_license parameters if they do not appear in your custom resource.

sc_deployment_license, which can be non-production, or production.

sc_deployment_fncm_license, which can be: user, non-production, or production.

sc_deployment_baw_license, which can be: user, non-production, or production.

Note: You can ignore the fncm and baw parameters if they do not appear in your custom resource.
Platform parameters
sc_deployment_platform, which can be "OCP" or "ROKS".

sc_ingress_enable, must be set to true to create an ingress on ROKS.
Sizing parameters

sc_deployment_profile_size, which determines the profile of your deployment. The default is small, but you can change the profile to medium or large.

Storage parameters
These parameters are mandatory.

sc_slow_file_storage_classname

sc_medium_file_storage_classname

sc_fast_file_storage_classname

sc_block_storage_classname
Content pattern parameters
The following content pattern parameters can be true or false.

sc_content_initialization

sc_content_verification

Note: You can ignore these parameters if you are not installing the content pattern.
Optional: Configure the root secret, external SSL/TLS certificate secret, and the trusted certificate list.

The custom YAML file includes the root_ca_secret, external_tls_certificate_secret, and trusted_certificate_list parameters. The root_ca_secret parameter is the name of the secret that contains the root CA signer certificate for the Cloud Pak. If the secret does not exist, then a self-signed signer certificate is generated. For more information, see Providing the root CA certificate.

For production environments, it is likely that you want to use your own certificates that are trusted by your clients. The external_tls_certificate_secret parameter is used to store a wildcard certificate, which can be more convenient than a certificate for each subdomain. A multi-domain wildcard certificate can also be used to secure multiple domains and their subdomain names. For more information, see Providing certificates for external routes.

Important: If you choose to use self-signed certificates, certain features of the product might not work as expected because of modern browser restrictions that are related to self-signed certificates. A browser blocks any redirect to a site that uses a certificate that is not signed by a root CA that is trusted by the browser. This can result in access issues for business applications.

The trusted_certificate_list parameter can be used to trust root CA certificates for external services. For more information, see Connecting securely with external services.
Check the resource_registry_configuration section.

Automatic backup for the Resource Registry is recommended. For more information, see Enabling Resource Registry disaster recovery.
Check the values for the image_pull_secrets parameter, the sc_image_repository parameter, and for the Application Engine repositories.
All components use the same docker image repository. By default, the IBM Entitlement Registry is used "cp.icr.io".
```
shared_configuration:
  sc_image_repository: cp.icr.io
  image_pull_secrets:
  - ibm-entitlement-key
```
For an air gap installation, make sure that the sc_image_repository parameter is set to the default value. The images section is needed only if your environment is offline (air gapped deployment).
```
shared_configuration:
  sc_image_repository: cp.icr.io
  image_pull_secrets:
  - ibm-entitlement-key
  images:
     dbcompatibility_init_container:
       repository: <registry_url>:5000/<namespace>/dba-dbcompatibility-initcontainer
       tag: <version> 
     pull_policy: IfNotPresent
```
The <version> number is 23.0.1.

Note: The images section is needed only if your environment is offline (air gapped deployment).

If you loaded the images to a local registry, enter your values in the sc_image_repository parameter, and edit the ibm-entitlement-key secret with the local "Registry Server Address" (for example mycorp-docker-local.mycorp.com) and the user credentials to pull the images from your registry.
```
sc_image_repository: <registry_domain_name>/<project-name>
```
Note: If your custom resource does not include BAA, you do not see these lines in your custom resource file.
Optional: If you did not run the cp4a-prerequisites.sh script and selected an LDAP in your deployment, then enter the parameter values for your LDAP instance in the ldap_configuration section.
Authorization does not work in the cluster if the LDAP parameter values do not match what is required by your LDAP design. LDAP designs can vary significantly, so the default values are not always the correct values. For improved performance, limit access to the minimum number of users and groups. Make sure that the pagination, base DNs, or SCIM attribute mappings parameters are set correctly. For more information, see LDAP configuration.

If you need to create a secret for the lc_bind_secret parameter to store the bind dn and bind password, then go ahead and create it.
```
oc create secret generic my-ldap-tds-secret --from-literal=ldapUsername="cn=root" --from-literal=ldapPassword="XXXXXXXX"
```
Verify that the LDAP bind secret is set properly in the OCP console or by running the following command:
```
oc extract secret/my-ldap-tds-secret --to=-
```
Important: When the LDAP password expires or changes, you must remember to update this secret with the new password, and then restart any pods that got stuck or failed as a result of the LDAP being inaccessible.

Set the value in the custom resource file.

If you want to use SSL-enabled LDAP in your container environment, you must create the SSL secret with the certificate of the LDAP server.
1. Get the root CA that is used to sign your LDAP server and save it to a certificate, for example ldap-server-cert.crt. See OpenSSL for instructions to export the root CA of your external service.
2. To create the secret, run the following command.
```
oc create secret generic secretName --from-file=tls.crt=your_cert_path/ldap-server-cert.crt
```
  Substitute your values for secretName and your_cert_path/ldap-server-cert.crt. The certificate and key files must be in Privacy Enhanced Mail (PEM) format.
3. After you obtain the certificate and create the secret, you enable SSL and provide the secret name in the custom resource YAML file in the ldap_configuration section.
```
ldap_configuration:
  …
    lc_ldap_ssl_enabled: true
    lc_ldap_ssl_secret_name: "<secretName>"
```
  Set the enabled parameter to true and provide your own secret name.
If you want to use ROKS Virtual Private Cloud (VPC) infrastructure, make sure that you adjust your configuration in the following ways.
- Your LDAP server must be in the same VPC as the ROKS VPC.
- The custom resource parameter lc_ldap_server must be set to the internal IP or internal DNS, for example:
```
lc_ldap_server: 10.240.0.16
```
Optional: If you did not run the cp4a-prerequisites.sh script, enter the parameter values for your data source instance in the datasource_configuration section.

Your deployment might need several databases. Follow the configuring instructions for each component to complete this section.
Optional: Modify the default value of the sc_iam.default_admin_username parameter for the IBM Identity and Management (IM) foundational service.