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.

Table 1. Checking `<Required>` parameters for selected images
Parameter	Description
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 OCP console YAML View 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
sc_deployment_license, which can be non-production, or production.
Platform parameters
sc_deployment_platform, which can be "OCP", "ROKS" or Other.

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.

Huge pages

sc_hugepages, enables the allocation of huge pages that are configured in the cluster to your BAI deployment. By default, huge pages allocation is not enabled. If you want your BAI deployment to use the huge pages that you enabled on the cluster, then set sc_hugepages.enabled to true. For more information, see Shared configuration.

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

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 .

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.
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:
     dba-keytool-initcontainer:
       repository: <registry_url>:5000/<namespace>/dba-keytool-initcontainer
       tag: <version> 
     pull_policy: IfNotPresent
```
The <version> number is 26.0.0.

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.
If required: If you did not run the bai-prerequisites.sh script and selected an LDAP in your deployment, then enter the appropriate 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. 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.
```
kubectl 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, and then set the value in the custom resource file.
```
kubectl 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.

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.
```
kubectl 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: Modify the default value (cpadmin) of the sc_iam.default_admin_username parameter for the Identity Management (IM) foundational service.

The IM admin username cannot be the same as a user in your LDAP. If your LDAP has a user with the name cpadmin, then set a different default admin username for IM.
Optional: Validate the value of sc_generate_sample_network_policies If it is YES is will generate network policies from the deployment.

For more information, see Shared configuration.