vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Create a file that is named chrootpw.ldif and add the following lines to it:

dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcRootPW
olcRootPW: {SSHA}FUMV8TZ9lZQxABxCBE5UZ+oU/dlwf/d4

Replace the olcRootPW value with the password hash that you generated in the previous step.
6. Import the basic schema by running the following commands:

ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/cosine.ldif
ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/nis.ldif
ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/inetorgperson.ldif
7. Generate a manager password by running the slappasswd command again. For example:

slappasswd

You see output that looks something like the following:

Example output:

{SSHA}TVW9z6WLIBC3EXtFHFWnb2EVlK7EZQ3b

Note the password hash that is generated (in this case, {SSHA}TVW9z6WLIBC3EXtFHFWnb2EVlK7EZQ3b) as you need it later.
8. Add the manager password and enable the manager account by creating a file that is named chdomain.ldif and adding the following lines to it:

 DC should be your domain
 specify the password generated above for "olcRootPW" section
dn: olcDatabase={1}monitor,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth"
Building applications by using buildpacks 

A build, or image build, is a mechanism that you can use to create a container image from your source code. Code Engine supports building from a Dockerfile and Cloud Native Buildpacks.

Before you begin



* [Set up your Code Engine CLI environment](https://cloud.ibm.com/docs/codeengine?topic=codeengine-install-cli).
* [Create and work with a project](https://cloud.ibm.com/docs/codeengine?topic=codeengine-manage-project).



All Code Engine users are required to have a Pay-as-you-Go account. Tutorials might incur costs. Use the Cost Estimator to generate a cost estimate based on your projected usage. For more information, see [Code Engine pricing](https://cloud.ibm.com/docs/codeengine?topic=codeengine-pricing).



 Step 1: Set up registry access 

Because the output of the build is an image that is stored in a container registry, you must [set up access](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registry) to an image registry for Code Engine. To store an image in Docker Hub, create the registry access by using the [ibmcloud ce secret create --format registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-secret-create) command. In the following example, use dockerhub as the name of the registry access and specify your Docker Hub ID as the username. For the Docker Hub password, you can specify your Docker Hub password or an [access token](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryaccess-private-docker-hub).

ibmcloud ce secret create --format registry --name dockerhub --server https://index.docker.io/v1/ --username username --password password

Example output
For more information about setting up the service ID and the corresponding API key, see [Create service IDs for the SO user, normal user, and anonymous user](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-best-practice-pkcs11-accessstep2-create-service-id-api-key).





 Crypto service 

As part of the PKCS #11 library initialization process, a gRPC connection is made from the PKCS #11 library to the IBM Cloud. The gRPC connection facilitates the PKCS #11 library to call Cryptoki functions, such as C_Encrypt, C_Decrypt, C_Sign, and C_Verify, which requires the use of a Hardware Security Module (HSM).





 Keystore 

Two major types of keystores are available:



* In-memory keystores: Stores key objects temporarily in memory. Key objects that are stored in the in-memory keystore are also known as session objects. Session objects in a specific session are destroyed when you call the C_CloseSession function for that session. Session objects in all sessions are destroyed after the C_Finalize function is called.
* Database-backed keystores: Stores key objects in databases. Key objects that are stored in the database-backed keystore are also known as token objects. If the sessionauth parameter is enabled and a password for the keystore is configured, the database-backed keystore is encrypted and authenticated. By default, the sessionauth parameter is disabled. For each service instance, a maximum of five authenticated keystores are supported. You can enable the sessionauth parameter to encrypt the generated keys into the keystore or to decrypt the key before you use it. The password can be 6 - 8 characters.



Keystore passwords are not stored in the service instance. You, as the keystore administrator, are responsible for maintaining a local copy of the passwords. If a password is lost, you need to contact the Support team to reset the keystore, which means all data in the keystore is cleared.
* This is your <ADMIN_API_KEY> = 'apiKey' in the file platformApiKey.json



4. Terminal will now be waiting for input
5. Create an alias queue that targets your default queue





* DEFINE QALIAS (DEV.ALIAS.QUEUE.1) TARGET (DEV.QUEUE.1)



* DEV.ALIAS.QUEUE.1 is our name for the alias queue
* DEV.QUEUE.1 is the default queue we are using in this tutorial





![Image showing 'runmqsc' followed with the password entry and the 'DEFINE QALIAS' command that creates an alias queue targeting the default queue](https://cloud.ibm.com/docs-content/v1/content/3a120b16db5fdc3e70d071af8a63ce5515c1b096/mqcloud/images/mqoc_ams_alias_queue.png)





 Test the alias queue before enabling queue manager AMS 

In order to demonstrate that the alias queue is working correctly and that the messages are currently on the default queue in plain text, you will now perform a 'put' of a message against the default queue and a 'get' of a message against the alias queue.



1. Switch to the app terminal
2. Run amqsputc to put a message on the default queue



* amqsputc DEV.QUEUE.1



3. The terminal will prompt you for a Password



* This is your <APP_API_KEY> = 'apiKey' in the file apiKey.json



4. Terminal will now be waiting for input. Enter a message



* Hit Enter key twice to exit from amqsputc!
Connecting an external application 

Each IBM Cloud® Databases for etcd deployment has connection strings specifically for drivers and applications. Connection strings are displayed within Endpoints in your deployment's Overview, and can also be retrieved from the [cloud databases CLI plug-in](https://cloud.ibm.com/docs/databases-cli-plugin?topic=databases-cli-plugin-cdb-referencedeployment-connections), and the [API](https://cloud.ibm.com/apidocs/cloud-databases-apidiscover-connection-information-for-a-deployment-f-e81026).

The connection strings can be used by any of the users on your deployment. While you can use the root user for all of your connections and applications, it might be better to generate users specifically for your applications to connect with. Documentation on creating users is on the [Creating Users and Getting Connection Strings](https://cloud.ibm.com/docs/databases-for-etcd?topic=databases-for-etcd-connection-strings) page.



 Using Connection Information 

Databases for etcd supports only the etcd v3 API and data store. Access to the v2 API is disabled.

The information an application needs to make a connection to your deployment is in the "etcd" section of your connection strings. The table contains a breakdown for reference.



Table 1. etcd/URI connection information

 Field Name Index Description 

 Type Type of connection - for etcd, it is "uri" 
 Scheme Scheme for a URI - for etcd, it is "https" 
 Path Path for a uri 
 Authentication Username The username that you use to connect. 
 Authentication Password A password for the user - might be shown as $PASSWORD 
 Authentication Method How authentication takes place; "direct" authentication is handled by the driver. 
 Hosts 0... A hostname and port to connect to 
 Composed 0... A URI combining Scheme, Authentication, Host, and Path 
 Certificate Name The allocated name for the self-signed certificate for database deployment 
 Certificate Base64 A base64 encoded version of the certificate. 





* 0...
ibmcloud ce secret update --name SECRET_NAME (--from-env-file FILE | --from-file FILE | --from-file KEY=FILE | --from-literal KEY=VALUE | --rm KEY) [--cert-chain-file CERT_CHAIN_FILE] [--email EMAIL] [--key-path KEY_PATH] [--known-hosts-path KNOWN_HOSTS_PATH] [--output OUTPUT] [--password PASSWORD] [--password-from-file PASSWORD_FROM_FILE] [--password-from-json-file PASSWORD_FROM_JSON_FILE] [--private-key-file PRIVATE_KEY_FILE] [--quiet] [--server SERVER] [--username USERNAME]



 Command Options 

--name, -n
: The name of the secret. This value is required.

--cert-chain-file, --ccf
: Specify a file containing the certificate chain provided by your certificate authority for a TLS secret. You must provide the path to the file as a value. This value is optional.

--email, --em
: The email address to access the registry server for a registry secret. This value is optional.

--from-env-file, -e
: Update a generic secret from a file which contains one or more lines that match the format KEY=VALUE. You must provide the path to the file as a value. Each line from the specified file is added as a key-value pair. Any lines in the specified file that are empty or begin with are ignored. This value is required if --from-literal or --from-file is not specified.

--from-file, -f
: Update a generic secret from a file. You must provide the path to the file as a value. This value is required if --from-literal or --from-env-file is not specified.

--from-literal, -l
: Update a generic secret from a key-value pair. Must be in KEY=VALUE format.
You now have a decrypted password and a floating IP address to connect to your Windows server. Use your preferred Remote Desktop client to connect to your server. To connect to your server, provide the floating IP address and the decrypted password. The username is Administrator by default. (If you are connecting from a client that is running the Windows Administrator account, use .administrator as the user ID to log on to RDP.)







 Next steps 

After you connect to your server, you can [manage your server](https://cloud.ibm.com/docs/vpc?topic=vpc-managing-bare-metal-servers).
name: rootdisk
- cloudInitNoCloud:
userData: |-
cloud-config
user: cloud-user
password: 'fedora-1-password'
chpasswd: { expire: False }
name: cloudinitdisk
Show more
2. Create the virtual machine in your cluster.

oc apply -f vm.yaml
3. Start the virtual machine.

virtctl start fedora-1 -n openshift-cnv
4. Verify the virtual machine is running.

oc get vm -n openshift-cnv

Example output.

NAME AGE STATUS READY
virtualmachine.kubevirt.io/fedora-1 16h Running True
5. From the OpenShift web console, log in to your VM by using the username and password you specified in the VirtualMachine config. For example, user: cloud-user and password: 'fedora-1-password'.



Congratulations! You just deployed a Fedora virtual machine on your Satellite cluster.

You can find more information about what to do next in the [OpenShift Virtualization Hands-on Lab](https://github.com/rdoxenham/openshift-virt-labs).





 Additional resources 



* [Running a Windows 2019 Server VM in IBM Cloud Satellite with OpenShift Virtualization](https://lisowski0925.medium.com/running-a-windows-2019-server-vm-in-ibm-cloud-satellite-with-openshift-virtualization-234aa9a01def).
* [Using the virtualization CLI tools](https://docs.openshift.com/container-platform/4.11/virt/virt-using-the-cli-tools.html)
* [Creating VMs](https://docs.openshift.com/container-platform/4.11/virt/virtual_machines/virt-create-vms.html)
For example, if the email specified is test@example.com, the domain name must be specified as example.com.
* The proxy access name is the name that is responsible for the connectivity from Proxy to Data Security Broker Manager (the IP, or DNS, or the Service Name). For example, dsb-nginx.



6. Create an Admin Account for the initial Data Security Broker Manager administrator by specifying the email address in the Configure Super Admin User page. This account is used to configure the subsequent components such as the keystore, data store connections, and Data Security Broker Shields. Click Continue.

Zoom

![Configure Super Admin User](https://cloud.ibm.com/docs-content/v1/content/57ab3ec034294d8a6de510b97bec3035d4654761/security-broker/images/superadmin.svg)

Configure Super Admin User
7. Configure Credential Keystore to establish an encrypted credential store for any system access credential or access key that the Data Security Broker Manager or Data Security Broker Shield utilize. Enter the Data Security BrokerSecret Key in the text field. For the Password field, enter a secure password or passphrase to secure the actual keystore. Enter the same string that you specified for the Password field in the Confirm Password text box. Click Finish to complete the Data Security Broker Manager configuration.

Zoom

![Configure Credential Keystore](https://cloud.ibm.com/docs-content/v1/content/57ab3ec034294d8a6de510b97bec3035d4654761/security-broker/images/secret_key.svg)

Configure Credential Keystore

The Data Security Broker Secret Key must contain at least 10 characters, a mixture of upper and lower case, including at least one numeric character. The Secret Key is used to generate a random key to encrypt the Keystore Config Password.
8.
The service can be provisioned from its [catalog page](https://cloud.ibm.com/catalog/services/logdnaat?callback=%2Fobserve%2Factivitytracker%2Fcreate) or from an existing [Observability Dashboard](https://cloud.ibm.com/observe/activitytracker).

The Activity Tracker with LogDNA service has a Lite plan that is free to use, but it only offers streaming events. To take advantage of the tagging, export, retention, and other features, you need to use one of the [paid plans](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-service_plan).





 Event fields 

A description of the common fields for an Activity Tracker event is on the [Event fields](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-event) page.





 List of events 

The following table lists the events that get sent to Activity Tracker from IBM® Db2® Warehouse on Cloud deployments:



 Action Description 

 <service_id>.backup-scheduled.create A scheduled backup of your deployment was created. If the backup failed, a "-failure" flag is included in the message. 
 <service_id>.backup.create A backup of your deployment was created. If the backup failed, a "-failure" flag is included in the message. 
 <service_id>.backup.restore A restore from backup was created. If the attempted restore failed, a "-failure" flag is included in the message. 
 <service_id>.restore.start A restore from backup was created. If the attempted restore failed, a "-failure" flag is included in the message. 
 <service_id>.user-password.update A user's password was updated. A "-failure" flag is included in the message if the attempt to update a user's password failed. 
 <service_id>.user.create A user was created. A "-failure" flag is included in the message if the attempt to create a user failed. 
 <service_id>.user.delete A user was deleted.
To change the value of a key-value pair in a defined secret, use the [secret update](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-secret-update) command. Let's update the mysecret-registry secret to use a different server.

ibmcloud ce secret update --name mysecret-registry --format registry --server <new_server> --username <new_username> --password <password>
2. Now that your secret is updated, use the secret get command to display details about a specific secret. If needed, use the --decode option to display the secret data as decoded. For example,

ibmcloud ce secret get --name mysecret-registry --decode

Example output

Getting generic secret 'mysecret-registry'...
OK

Name: mysecret-registry
ID: abcdefgh-abcd-abcd-abcd-c88e2775388e
Project Name: myproject
Project ID: 01234567-abcd-abcd-abcd-abcdabcd1111
Age: 21m
Created: 2023-03-07 20:00:45 +0000 UTC

Data:
---
email: ""
password: REDACTED
server: newserver
username: newuser









 Referencing secrets 

Your apps or jobs can consume and use the information that is stored in a secret by using environment variables.



 Referencing secrets from the console 

You can use the console to create environment variables for your apps and jobs that fully reference a secret or reference individual keys in a secret.

Before you can reference a secret, it must exist. See [create a secret](https://cloud.ibm.com/docs/codeengine?topic=codeengine-secret-create-ui). For this example, create a secret that is named target-secret with the key-value pair of TARGET=Sunshine.



1.
IBMid is the ID as a Service (IDaaS) from IBM® used to access IBM web-based services, including IBM Cloud resources. The IBMid is based on your company's email address and a password that is managed by IBMid. IBMid allows you to federate to your own corporate directory or a third-party Identity Provider (IdP) service that you might already be using such as Okta.<br><br>Federating to your own directory simplifies the process of adding users to your account as they will not require an IBMid with a separate password. However, there are cases where it might not be feasible for you to use IBMid federated to your corporate directory.<br><br>An alternative is to create an [IBM Cloud App ID](https://www.ibm.com/cloud/app-id) instance in your account and connect it to your chosen identity provider.<br><br>Consider the following options that are available to you:<br><br><br><br> * No federation: Your company email domain is not federated with IBMid, and you choose to keep it as is. Any user that uses your email domain can create their own IBMid, and the password they create is managed by IBMid. They can invite other users with an IBMid to their IBM Cloud account.<br> * Federate with IBMid: If your company's email domain is already federated, you can start configuring access to your account. If it is not already federated, a manual process with the IBMid federation team is required to establish federation. The decision to federate to your company's own directory needs to involve the person in your company that can make company-wide decisions when it comes to connecting to external parties for identity services. You need to ensure that this person is included in the process. Federating with IBMid can have an impact on web services that your company already uses with IBM.<br> * Federate with App ID and your IdP: This option requires the creation of an App ID instance. It is a self-service option with a low-usage fee. Choosing this option requires a custom URL to log in to IBM Cloud.
The script is set up to check out the pull request when a build job is triggered by a pull request open event or update event from one of the two forked repos.

case "$BITBUCKET_PR_SOURCE_HOST" in BITBUCKET_PR_SOURCE_HOST is an environment exported by pipeline if job is triggered by a bitbucket pull request
userA) userA should be replaced to anything to identify a forked repo's url
url="https://$username:$password@$BITBUCKET_PR_SOURCE_HOST" you need to provide username and password for repo-forked-A
;;
userB/repo-forked-B) userB/repo-forked-B should be replaced to anything to identify a forked repo's url
url="https://$username1:password1@$BITBUCKET_PR_SOURCE_HOST" you need to provide username1 and password1 for repo-forked-B
;;
esac
git fetch $url $BITBUCKET_PR_SOURCE_BRANCH BITBUCKET_PR_SOURCE_BRANCH is an environment exported by pipeline if job is triggered by a bitbucket pull request
git checkout FETCH_HEAD
Show more





 Build stage 

The build stage specifies a Builder type to indicate how to build the artifacts.

Many of the fields that are available in Build jobs are common across multiple Builder types.

The following Builder types are available:



Table 1. Builder types

 Builder type Description Supported job types 

 Simple Archives the current stage's input without modification for use by future stages. Typically, this builder type is useful only when the stage's input is from an SCM repository. Pipeline image version: Runs in a container by using a built-in docker image that provides various built-in commands. To adopt newer versions of those commands, use a newer image version. 
 Ant Uses Apache Ant files to manage the build job. Pipeline image version: Runs in a container by using a built-in docker image that provides various built-in commands.
1. Log in to Db2 on Cloud and click your service instance.
2. Click Service credentials.
3. Click New credential, then click Add.
4. After the credentials are created, click the down arrow beside the credential names to view the credentials.
5. In the following JSON document example, note the contents of the hostname, port, password, and username fields. You use these four components to make the public endpoint connection:







 Current plans connection string breakdown 



 Db2 on Cloud section 

The "db2" section contains information that is suited to applications that make connections to Db2 on Cloud.



Table 1. Db2 on Cloud / URI connection information

 Field Name Index Description 

 Type Type of connection - "URI" 
 Scheme Scheme for a URI - "db2" 
 Path Path for a URI - Database name. The default is bludb. 
 Authentication Username The user name that you use to connect 
 Authentication Password A password for the user 
 Authentication Method How authentication takes place; "direct" authentication is handled by the driver 
 Hosts 0... A host name and port to connect to 
 Composed 0... A URI combining Scheme, Authentication, Host, and Path 
 Certificate Name The allocated name for the self-signed certificate for database deployment 
 Certificate Base64 A base64 encoded version of the certificate 
 Host_ROS A host name and port to connect to read on standby 



0... indicates that there might be one or more of these entries in an array.





 CLI section 

The "cli" section contains information that is suited for connecting with db2.



Table 2. psql / cli connection information

 Field Name Index Description 

 Bin The recommended binary to create a connection; in this case it is db2 
 Composed A formatted command to establish a connection to your deployment. The command combines the Bin executable, Environment variable settings, and uses Arguments as command line parameters. 
 Environment A list of key/values you set as environment variables 
 Arguments 0... The information that is passed as arguments to the command shown in the Bin field