vania-janet/multiturn-rag-retrieval-data huggingface dataset:
; then echo "-w 0"; else echo "-b 0"; fi)
cat $HOME/<path-to-tlsca-admin>/msp/cacerts/<tls_root_cert>.pem | base64 $FLAG

The command prints the TLS CA root cert as a base64 encoded sting.

LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNHRENDQWI2Z0F3SUJBZ0lVWUVQWnprNXV2b3dobEtacG5JMXplODdIQUlnd0NnWUlLb1pJemowRUF3SXcKWFRFTE1Ba0dBMVVFQmhNQ1ZWTXhGekFWQmdOVkJBZ1REazV2Y25Sb0lFTmhjbTlzYVc1aE1SUXdFZ1lEVlFRSwpFd3RJZVhCbGNteGxaR2RsY2pFUE1BMEdBMVVFQ3hNR1JtRmljbWxqTVE0d0RBWURWUVFERXdWMGJITmpZVEFlCkZ3MHhPVEExTURNeE16STVNREJhRncwek5EQTBNamt4TXpJNU1EQmFNRjB4Q3pBSkJnTlZCQVlUQWxWVE1SY3cKRlFZRFZRUUlFdzVPYjNKMGFDQkRZWEp2YkdsdVlURVVNQklHQTFVRUNoTUxTSGx3WlhKc1pXUm5aWEl4RHpBTgpCZ05WQkFzVEJrWmhZbkpwWXpFT01Bd0dBMVVFQXhNRmRHeHpZMkV3V1RBVEJnY3Foa2pPUFFJQkJnZ3Foa2pPClBRTUJCd05DQUFRdSs2UnZWd2w5T2dDVlAraEVxbjVxdExRVG9LWkw4a1lic0pOeU1JbERoc3hlNWx6cW1zQkoKbTk2eUR2TVV6OSsxL2pzb1M4M1JqMVAwc3M2TnJNb3FvMXd3V2pBT0JnTlZIUThCQWY4RUJBTUNBUVl3RWdZRApWUjBUQVFIL0JBZ3dCZ0VCL3dJQkFUQWRCZ05WSFE0RUZnUVVnUEc4anJEK1BxVjdoelc3WDlsbTFrMS91WjR3CkZRWURWUjBSQkE0d0RJY0VxVGJESW9jRUNwbnBkVEFLQmdncWhrak9QUVFEQWdOSUFEQkZBaUVBenk3cHJZaVMKQmlDVWdYeWRkY09WMm9mZmtqaEI0N091QXFjQWNqZS9SWkVDSUdKZFgzZ1ErTDRIN3duY1RoZkwrenU1ejV1UApGUWhXTmlNS3hQWEYrZnYwCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K

Provide this string to the tls_root_certs field of the API request.
<-- </ol> --><-- </section "id="section-ibp-v2-apis-msp" "> --><-- <section "id="section-ibp-v2-apis-config" "> --> Creating a configuration file You need to complete a configuration file in order to create a peer or ordering node by using the APIs. This file is provided to the API as the config object in the request body of the API call. If you are creating multiple ordering nodes, you need to provide a configuration file for each node that you want to create in an array to the API request. For example, for a five node raft ordering service, you need to create an array of five configuration files. You can provide the same file for each node as long as the enrollID's that you provide have a sufficiently high enrollment limit. You need to deploy a CA and follow the steps to register and enroll the required identities before you complete the file.The template for the configuration file can be found below: {
"enrollment": {
"component": {
"cahost": "",
"caport": "",
"caname": "",
"catls": {
"cacert": ""
},
"enrollid": "",
"enrollsecret": "",
"admincerts": ""]
},
"tls": {
"cahost": "",
"caport": "",
"caname": "",
"catls": {
"cacert": ""
To achieve high availability, repeat the steps 2 - 4 to add an NLB 2.0 in each zone where you have app instances.
6. Optional: An NLB service also makes your app available over the service's NodePorts. [NodePorts](https://cloud.ibm.com/docs/containers?topic=containers-nodeport) are accessible on every public and private IP address for every node within the cluster. To block traffic to NodePorts while you are using an NLB service, see [Controlling inbound traffic to network load balancer (NLB) or NodePort services](https://cloud.ibm.com/docs/containers?topic=containers-network_policiesblock_ingress).



Next, you can [register an NLB subdomain](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer_hostname).





 Setting up an NLB 2.0 in a single-zone cluster 

Before you begin:



* Important: Complete the [NLB 2.0 prerequisites](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer-v2ipvs_provision).
* You must have an available portable public or private IP address to assign to the NLB service. For more information, see [Configuring subnets for clusters](https://cloud.ibm.com/docs/containers?topic=containers-subnets).
* Ensure that you have the [Writer or Manager IBM Cloud IAM service access role](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms) for the default namespace.
* When cluster nodes are reloaded or when a cluster master update includes a new keepalived image, the load balancer virtual IP is moved to the network interface of a new node. When this occurs, any long-lasting connections to your load balancer must be re-established. Consider including retry logic in your application so that attempts to re-establish the connection are made quickly.



To create an NLB 2.0 service in a single-zone cluster:



1.
In addition to that IP address, pick up the floating IP address that's attached to the login node.







 Accessing the LSF Application Center 

Complete the following steps to access the LSF Application Center:



1. Open a new command-line terminal.
2. Run the following command to access the LSF Application Center GUI:

ssh -L 8080:localhost:8080 -J root@{FLOATING_IP_ADDRESS} lsfadmin@{MANAGEMENT_NODE_IP_ADDRESS}

where MANAGEMENT_NODE_IP_ADDRESS needs to be replaced with the management node IP address that is associated with <cluster_prefix>-management-host-0 and FLOATING_IP_ADDRESS needs to be replaced with the login node floating IP address. To find the management and login node IPs, see the instructions for [Gathering IP addresses](https://cloud.ibm.com/docs/ibm-spectrum-lsf?topic=ibm-spectrum-lsf-accessing-lsf-guigathering-ip-addresses).
3. Open a browser on your local machine and run [http://localhost:8080](http://localhost:8080).
4. To access the LSF Application Center GUI, enter the default user as lsfadmin and enter the password that you configured when you created your workspace.
Clusters that do not use a system channel can join and unjoin ordering nodes to an application channel. You can verify if a cluster does or does not use a system channel by clicking the cluster's tile and looking near the Orderer Type text.

Joining an orderer to an application channel will make it either a follower or a consenter. It will be a consenter if the node is found in the the channel's config block in the consenters section. Otherwise the orderer will be a follower. Both types of orderers will receive transaction/block data, but only a consenter can vote and play a role in the consensus algorithm. A node can be promoted from a follower to a consenter by first joining it to the channel, and then editing the channel's config to add it as a consenter. Similarly these steps can be reversed to demote an orderer and unjoin it completely if need be.

Joining an orderer to the application channel can be started by clicking the cluster's tile. Next click either the plus sign on a channel tile or the Join channel blue button. Follow the prompts and select which orderer nodes to join. Then click Submit. Once an orderer has joined it will begin downloading blocks to catch up to the current level.







 Removing ordering service nodes 

If a user wants to delete an ordering node, it must first remove the node from all channels where it is a consenter. This is because the console does not distinguish between a deleted node and an unavailable node, and will keep an ordering node as part of its consenter set until it is removed.

As a result, when you delete a node, a check is performed to see if it is a consenter on any channels. If it is, you will not be able to delete the node until it has been removed as a consenter from all channels. After removing the node as a consenter from all channels, you will be able to delete the node by clicking the trash can icon. Note that this action will have to be taken in the console where the node was created.

As part of this same process, make sure to reach out to the other console operators to let them know that the node has been deleted so they can remove the tile from their console.
In addition to the base operating system, the image includes the Spectrum Scale software packages that allow for the Spectrum Scale shared file system to be automatically mounted and ready for use after the creation and configuration of the cluster is complete.





 Step 3: Gather public IP address 

You need to provide your public IP addresses from where you want to access the environment after it's provisioned. You provide these public IP addresses in the remote_cidr_blocks deployment value. For more information, see [Deployment values](https://cloud.ibm.com/docs/hpc-spectrum-scale?topic=hpc-spectrum-scale-deployment-values).





 Step 4: Identify cluster deployment location 

You need to decide where you want your cluster deployed by choosing an IBM Cloud region and availability zone. You provide this location information when you configure your workspace. For more information, see [Region and data center locations for resource deployment](https://cloud.ibm.com/docs/overview?topic=overview-locations).





 Step 5: Next steps 

After you've gathered the necessary input values to define your cluster configuration, you are ready to deploy your IBM Spectrum Scale cluster. The Spectrum Scale cluster can be deployed on IBM Cloud by using the IBM Cloud catalog tile, Schematics UI, Schematics CLI, or the Schematics APIs. If you want to deploy your cluster by using the CLI or API, review the prerequisites for your interface of choice:



* [Setting up the IBM Cloud Schematics CLI](https://cloud.ibm.com/docs/hpc-spectrum-scale?topic=hpc-spectrum-scale-setting-up-cli)
* [Setting up the IBM Cloud Schematics API](https://cloud.ibm.com/docs/hpc-spectrum-scale?topic=hpc-spectrum-scale-setting-up-api)



After you've created and gathered your information and reviewed any additional prerequisites for your interface of choice, you are ready to begin [Creating a workspace](https://cloud.ibm.com/docs/hpc-spectrum-scale?topic=hpc-spectrum-scale-creating-workspace).
From a resource allocation perspective, it is possible to join the same peers to multiple channels. The design of the peer ensures that the data from one channel cannot pass to another through the peer. However, because the peer will store a separate ledger for each channel, it is necessary to ensure that the peer has enough processing power and storage to handle the transaction and data load.

Deploying your peer

Use your console to perform the following steps:



1. On the Nodes page, click Add peer.
2. Make sure the option to Create a peer is selected. Then click Next.
3. Give your peer a Display name of Peer Org2.
4. The Advanced deployment options are only available in paid clusters and can be safely ignored for purposes of this tutorial. For more information about these options, see the links below.



* [State database](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-adv-deploymentibp-console-adv-deployment-level-couch)
* [Multizone Kubernetes cluster](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-haibp-console-ha-multi-zone) (Multizone HA) This option is only visible when your cluster is configured for multizone support.
* [Use your own CA certificate and private key](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-adv-deploymentibp-console-adv-deployment-third-party-ca)
* [Hardware Security Module (HSM)](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-adv-deploymentibp-console-adv-deployment-cfg-hsm)
* [Resource allocation](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-adv-deploymentibp-console-adv-deployment-allocate-resources)



5. Click Next.
If your data store is large, consider using a persistent volume claim instead of relying on the node's ephemeral storage. For more information, see [Configuring jobs to use PVC](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-backup-restorepvc).

Complete the following steps to back up IBM Watson® Discovery data by using the backup scripts:



1. Enter the following command to set the current namespace where your Discovery instance is deployed:

oc project <namespace>
2. Get the backup script from the [GitHub repository](https://github.com/watson-developer-cloud/doc-tutorial-downloads/tree/master/discovery-data/latest).

You need all of the files in the repository to complete a backup and restore. Follow the instructions in GitHub Help to clone or download a compressed file of the repository.
3. Make each script an executable file by running the following command:

chmod +x <name-of-script>

Replace <name-of-script> with the name of the script.
4. Run the all-backup-restore.sh script.

./all-backup-restore.sh backup [ -f backup_file_name ] [--pvc]

The -f backup_file_name parameter is optional. The name watson_discovery_<timestamp>.backup is used if you don't specify a name.

The --pvc parameter is optional. For more information about when to use it, see [Configuring jobs to use PVC](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-backup-restorepvc). By default, the backup and restore scripts create a tmp directory in the current directory that the script uses for extracting or compressing backup files.

If you run into issues with the backup, rerun the backup command and include the --use-job parameter.
Performance optimizations can be done at this stage to reduce maintenance requirements, and make low response times possible.

In this case, with a Node.js based action at hand, the Invoker starts a Node.js container. Then, it injects the code from myAction, runs it with no parameters, extracts the result, saves the logs, and destroys the Node.js container.





 8. Storing the results: CouchDB again 

After the result is obtained by the Invoker, it is stored into the whisks database as an activation under the assigned activation ID. The whisks database lives in CouchDB.

In this specific case, the Invoker gets the resulting JSON object back from the action, grabs the log that was written by Docker, includes them all in the activation record, and stores the record in the database. Refer to the following example:

{
"activationId": "31809ddca6f64cfc9de2937ebd44fbb9",
"response": {
"statusCode": 0,
"result": {
"hello": "world"
}
},
"end": 1474459415621,
"logs": [
"2016-09-21T12:03:35.619234386Z stdout: Hello World"
],
"start": 1474459415595,
}

Note how the record contains both the returned result and the logs that were written. The record also contains the start and end time of the invocation of the action. Activation records contain more fields, but this example is stripped down for simplicity.

Now you can use the REST API (start from step 1 again) to obtain your activation and thus the result of your action. To do so, run this command:

ibmcloud fn activation get 31809ddca6f64cfc9de2937ebd44fbb9

In summary, you can see how a simple ibmcloud fn action invoke myAction command passes through different stages of the Cloud Functions system.
Before you shut down the AIX VM, grab the IPv6 details.
2. Gather the IP interface and adapter configuration details by using smitty.
3. Run the /usr/sbin/rsct/bin/lsnodeid command to grab the nodeid.
4. Confirm that the nodeid matches the output from cat /etc/ct_node_id and cat /var/ct/cfg/ct_node_id.
5. Power down the AIX VM and restart it by using your custom boot image.
6. Re-create the same network configuration as on the IBM boot image by using smitty.
7. Validate that the RSCT packages are at least 3.2.1 or later by running the lslpp -L rsct. command.
8. Run the /usr/sbin/rsct/bin/lsnodeid command. This will likely not match the data from the IBM boot image.
9. Generate a nodeid to match the original boot ID. Start RMC again and wait 15 minutes.

/usr/sbin/rsct/bin/rmcctrl -p
odmdelete -o CuAt -q name=cluster0 (optional before the recfgct command)
/usr/sbin/rsct/install/bin/recfgct – I value from /etc/ct_node_id (on the original IBM boot disk collected above)
10. Run the /usr/sbin/rsct/bin/lsnodeid command.
11. The output should be the same as the output from the IBM boot image.
oc logs <ibm-ocs-operator-controller-manager-a1a1a1a> -n kube-system
6. Describe NooBaa and review the Events section of the output for any error messages.

oc describe noobaa -n openshift-storage
7. Describe the ibm-storage-metrics-agent pod and review the Events section in the output for any error messages.

oc get pods -n kube-system -l name=ibm-storage-metrics-agent

NAME READY STATUS RESTARTS AGE ibm-storage-metrics-agent-8685869cc6-79qzq
8. Review the logs from the ibm-storage-metrics-agent.

oc logs ibm-storage-metrics-agent-xxx -n kube-system
9. Describe the ocscluster and review the output for error messages.

oc describe ocscluster <ocscluster-name> -n openshift-storage
10. Gather data about the cluster by using the oc adm must-gather command.

oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:latest --dest-dir=ocs_mustgather
11. For classic clusters or Satellite clusters that use local volumes on the worker node, make sure that the disk-by-id for the volumes that you used for the osd-device-path and mon-device-path parameters exists on the worker nodes. For more information about how to retrieve these volume IDs, see [Gathering your device details](https://cloud.ibm.com/docs/openshift?topic=openshift-deploy-odf-classicodf-classic-get-devices)
12. [Review the troubleshooting documentation for steps to solve common errors](https://cloud.ibm.com/docs/openshift?topic=openshift-sitemapsitemap_openshift_data_foundation).
Identify the UUID for secondary volume (vdb1) partition.

blkid | grep /dev/vdb1

/dev/vdb1: UUID="a65690bf-0c5e-467b-bb27-7c1558f1ed65" TYPE="xfs" PARTUUID="c4022fcb-01"
6. Enter this UUID command in fstab to make the mounts persistent after it restarts.

UUID= a65690bf-0c5e-467b-bb27-7c1558f1ed65 /data xfs defaults 1 2
7. Create a mount point and mount the created file system.

mkdir /data

mount /data
8. Make sure that mysql is not running and copy the contents from default location to /data.

service mysql stop
rsync -av /var/lib/mysql /data

This command creates directory mysql under /data and copies the contents.
9. Update the configuration files.



1. Update /etc/mysql/mysql.conf.d/mysqld.cn:



* Set datadir=/data/mysql
* Set server-id=1
* Set log_bin=/data/mysql/mysql-bin.log
* Comment out all bind-addresses.



2. Update /etc/apparmor.d/tunables/alias:



* Set /var/lib/mysql -> /data/mysql/





10. Restart services.

systemctl restart apparmor
systemctl restart mysql.service
systemctl enable mysql.service



5. Repeat all the steps from 3 and 4 in the second mysql node in the second zone. Set the server-id in the cnf file to 2 instead of 1.







 Set up replication between the two nodes 



1.
kubectl edit configmap sysdig-agent -n ibm-observe
3. Make changes. Add the events section or update the section.

Note: Refer to vi editor instructions to learn how to make changes.

For example, you might want to collect Kubernetes pod pulling events and filter out other pod events that are collected by default. You still want to collect default Kubernetes events for nodes and replicationControllers.

events:
kubernetes:
pod:
- Pulling
4. Save the changes.



Changes are applied automatically.

Another example where you can see how to collect a subset of Kubernetes events: You only want to monitor pulling, pulled, and failed events for pods.



* Option 1: Define the sequence on entries as a bulleted list:

events:
kubernetes:
pod:
- Pulling
- Pulled
- Failed
* Option 2: Define the sequence on entries in a bracketed single line:

events:
kubernetes:
pod: [Pulling, Pulled, Failed]



For more information on how to work with custom events, see [Working with custom events](https://docs.sysdig.com/en/event-types.html).





 Disabling collection of events 

To disable a monitoring agent from collecting Kubernetes events, you must modify the sysdig-agent-configmap.yaml file. Set the Kubernetes entry in the events section to none.

Complete the following steps:



1. Set up the cluster environment. Run the following commands:

First, get the command to set the environment variable and download the Kubernetes configuration files.

ibmcloud ks cluster config --cluster <cluster_name_or_ID>
2. Edit the sysdig-agent-configmap.yaml file.

Run the following command:

kubectl edit configmap sysdig-agent -n ibm-observe
3. Make changes. Add the events section or update the section.

events:
After the telemetry definition is applied, you can see Envoy access logs through the istio-proxy container.





 Setting up logging with IBM Log Analysis 

Seamlessly manage logs for your app container and the Envoy proxy sidecar container in each pod by deploying Log Analysis agents to your worker nodes to forward logs to IBM® Log Analysis.

To use [IBM Log Analysis](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-getting-started), you deploy a logging agent to every worker node in your cluster. This agent collects logs with the extension .log and extensionless files that are stored in the /var/log directory of your pod from all namespaces, including kube-system. These logs include logs from your app container and the Envoy proxy sidecar container in each pod. The agent then forwards the logs to the IBM Log Analysis service.

To get started, set up logging for your cluster by following the steps in [Managing Kubernetes cluster logs with IBM Log Analysis](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-tutorial-use-logdna).





 Setting up monitoring with IBM Cloud Monitoring 

Gain operational visibility into the performance and health of your Istio-managed apps by deploying a Monitoring agent to your worker nodes to forward metrics to IBM Cloud® Monitoring.

To deploy monitoring agents to your cluster, complete the following steps.



1. [Provision an instance of IBM Cloud Monitoring](https://cloud.ibm.com/observe/monitoring/create).
2. [Configure a monitoring agent in your cluster.](https://cloud.ibm.com/docs/monitoring?topic=monitoring-kubernetes_cluster)
3. In the [Monitoring console](https://cloud.ibm.com/observe/monitoring), click Open Dashboard for the instance that you provisioned.
4. In the Monitoring UI, click Add new dashboard.
5. Search for Istio and select one of the Monitoring predefined Istio dashboards.
The deployment is successful when you see one or more logging pods. The number of logging pods equals the number of worker nodes in your cluster. All pods must be in a Running state.







 Step 4: Launch the logging dashboard and view logs 

To launch the logging dashboard through the IBM Cloud console, complete the following steps:



1. Log in to your [IBM Cloud account](https://cloud.ibm.com/login).
2. From the menu ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/f61dbc5d84bf0c89e477a05cab04c72f429e1b7a/log-analysis/icons/icon_hamburger.svg), select Observability.
3. Select Logging. The list of IBM Log Analysis service instances that are available on IBM Cloud is displayed.
4. Select one instance and click View IBM Log Analysis. The logging dashboard opens. Note: With the Free service plan, you can tail your latest logs only. For more information, see [Viewing logs](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-view_logsview_logs).







 Next steps 



* [Filter logs](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-view_logsview_logs_step5)
* [Search logs](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-view_logsview_logs_step6)
* [Define views](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-view_logsview_logs_step7)



Note: Some of these features require a plan upgrade.