vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Also when you request the certificates, you need to specify a Node Organizational Unit (OU) attribute for some certificates as indicated in the Node OU column in the following tables. Certificates can be in the format of a .pem file or a base64 encoded string.

When you create a peer or ordering node, you need to provide the following four certificates in PEM format. When you request these certificates from the third-party CA, you need to request a specific Node Organizational Unit (OU) attribute for some certificates as indicated in the Node OU column.



Table 1. Node certificates

 Node certificates Description Node OU Format 

 1. Peer or ordering node identity certificate The public certificate of the node’s identity. "peer" or "orderer" depending on the node type PEM 
 2. Peer or ordering node identity private key The private key corresponding to the public signing certificate. Make sure to keep this certificate safe, as it can be used to impersonate the node. PEM 
 3. Peer or ordering service TLS CA certificate The public signing certificate created by your external TLS CA that is used by the peer or ordering node. The certificate needs to contain the x.509 Subject alternative name (SAN) for the peer or ordering nodes. If you are using the [Fabric CA client](https://hyperledger-fabric-ca.readthedocs.io/en/release-1.4/clientcli.html) to enroll the identity, you specify the SAN by passing the --csr.hosts parameter on the enroll command. If the hostname is not yet known, you can specify a wildcard with the domain name, for example: --csr.hosts '.ibpv2-cluster.us-south.containers.appdomain.cloud,127.0.0.1'. PEM 
 4.Peer or ordering service TLS CA private key The private key corresponding to the signed certificate from your TLS CA that is used by the peer or ordering node for secure communications with other members on the network. PEM 





Table 2. MSP certificates

 MSP certificates Description Node OU Format 

 1. CA root certificate The root certificate of your external CA.
For example, when you deploy a Node.js app, you can specify the node app.js start command on the -c option:



ibmcloud cf push appname -p app_path -c "node app.js"



* Use the command option in the manifest.yml file. For example, when you deploy a Node.js app, you can specify the node app.js start command in the manifest file:



command: node app.js





 Adding user-defined environment variables 

User-defined environment variables are specific for an app. You have the following options to add a user-defined environment variable to a running app:



* Use the IBM Cloud user interface.



1. On the IBM Cloud Dashboard, click your app tile. The app details page is displayed.
2. Click Runtime > Environment Variables.
3. Click USER-DEFINED, then click ADD.
4. Fill in the required fields, then click SAVE.



* Use the ibmcloud cf command line interface. Add a user-defined variable by using the ibmcloud cf env-set command. For example:

ibmcloud cf env-set appname <environment_variable_name> <environment_variable_value>
* Use the manifest.yml file. Add value pairs in the file. For example:

env:
VAR1:<environment_variable_name>
VAR2:<environment_variable_value>
* After you add a user-defined environment variable, you can use the following sample Node.js code to get the value of the defined variable:

var myEnv = process.env.<environment_variable_name>;
console.log("My user defined = " + myEnv);







 Configuring the startup environment 

To configure the startup environment for your app, you can add shell scripts into the /.profile.d directory. The /.profile.d directory is under the build directory of your app. Scripts in the /.profile.d directory are run by IBM Cloud before the app is run.
console.log('createResourceAlias() response:n' + JSON.stringify(res.result, null, 2));
})
.catch(err => {
console.warn(err)
});





 Viewing an alias 

After you create a connection between an IAM-managed service and an app, the alias is displayed on the Connections tab of the connected app. Additionally, the alias is displayed as a running service instance on your resource list, and contains a Connections tab only when you open it.



1. Go to the your resource list.
2. From the Application Services table, click the name of the service instance to open the service details view. If it has a Connections tab only, it's an alias.







 Viewing an alias by using the API 

After you create a connection between an IAM-managed service and an app, you can view the alias by getting a list of all resource aliases for an instance or you can retrieve a resource alias by ID.



 Get a list of all resource aliases for an instance 

To get a list of all resource aliases for the instance, call the [Resource Controller API](https://cloud.ibm.com/apidocs/resource-controller/resource-controller?code=nodelist-resource-aliases-for-instance) as shown in the following example:



* Curl
* Java
* Python
* Go
* Node



curl -X GET https://resource-controller.cloud.ibm.com/v2/resource_instances/8d7af921-b136-4078-9666-081bd8470d94/resource_aliases -H 'Authorization: Bearer <IAM_TOKEN>'

ListResourceAliasesForInstanceOptions listResourceAliasesForInstanceOptions = new ListResourceAliasesForInstanceOptions.Builder()
.id(instanceGuid)
.build();

Response<ResourceAliasesList> response = service.listResourceAliasesForInstance(listResourceAliasesForInstanceOptions).execute();
"apikey": "SECRET",
"host": "SECRET",
"iam_apikey_description": "Auto-generated for key SECRET",
"iam_apikey_name": "cloudant-binding",
"iam_role_crn": "SECRET",
"iam_serviceid_crn": "SECRET",
"password": "SECRET",
"port": 443,
"url": "https://01234SECRET",
"username": "01234567-SECRET"
},
"iam_compatible": true,
"resource_instance_url": "/v2/resource_instances/SECRET",
"crn": "crn:v1:bluemix:public:cloudantnosqldb:us-south:a/0123456789507a53135fe6793c37cc74:SECRET"
}
]







 Deploy the Node.js Patient Backend Database App 

Now you'll create the Node.js app that will populate your Cloudant DB with patient data. It will also serve data to the front-end application deployed earlier.



1. Make sure you're your context is the project example-health:

oc project example-health
2. The following new-app commmand will make a build configuration and Deployment Configuration. The following demonstrates the CLI invocation of the add application (remember using the GUI console for the frontend):

oc new-app --name=patient-health-backend --as-deployment-config centos/nodejs-10-centos7https://github.com/IBM-Cloud/patient-health-backend
3. Back in the console, and in the Topology view of the Developer perspective, open the patient-health-backend app and wait for the build to complete. Notice that the Pod is failing to start. Click on the Pod logs to see:

> node app.js
: Wait for the build run to complete. This value is optional. The default value is true.

--wait-timeout, --wto
: The length of time in seconds to wait for the function to be ready. This value is required if the --wait option is specified. This value is ignored if the --no-wait option is specified. The default value is 600.





 Example 

ibmcloud ce fn update --name myfunction --runtime nodejs-18 --build-source main.js





 Example output 

Preparing function 'myfunction' for build push...
Updating function 'myfunction'...
Packaging files to upload from source path 'main.js'...
Submitting build run 'myfunction-run-111111-12345678'...
Creating image 'icr.io/ce--1a1a1-11c22def3rhz/function-myfunction:12345678-1111-dexla'...
Waiting for build run to complete...
Build run status: 'Running'
Build run completed successfully.
Run 'ibmcloud ce buildrun get -n myfunction-run-111111-12345678' to check the build run status.
Waiting for function 'myfunction' to become ready...
Function 'myfunction' is ready.
OK
Run 'ibmcloud ce function get -n myfunction' to see more details.

https://myfunction.11c22def3rhz.us-south.codeengine.appdomain.cloud

When you run ibmcloud ce fn get -n 'myfunction' to check the function status, the URL for your function is displayed.









 Job commands 

A job runs one or more instances of your executable code. Unlike applications, which handle HTTP requests, jobs are designed to run one time and exit. When you create a job, you can specify workload configuration information that is used each time that the job is run.
Generating API connection credentials 

The migration process to follow depends on the nature of your application. Generally for all cases the first step is to acquire an API Key and Authentication Token for your application to use.



1. Log in to the top-level dashboard of your new Watson IoT Platform service.
2. Select the Usage tab.
3. Click View Details link to bring up the Watson IoT Platform service information.
The following information is displayed:



* The six character orgID
* API Key and Token.
You should generate new API Keys for each of your applications, rather than using the API Key shown here. This allows you to set appropriate permissions for each application.
* Host URL.



4. Create an API key and authentication token combination for your application.
You will need these when you configure the application to connect to your organization.



1. Click Launch.
This will take you through to the underlying service dashboard, that you have used to administer the Watson IoT Platform Lite service.
2. Select Apps.
3. Click Generate API Key
4. Copy the API key and authentication token values that are listed.
5. Select a role appropriate to your application.
6. Add a comment so that you can easily identify this API key and authentication token combination.
7. Click Generate.
8. Important: Make a local copy of the authentication token. It cannot be re-created after you close the window.









 Updating Node-RED applications 

You will need to configure your Node-RED nodes to connect to your new Watson IoT Platform instance. Your ibmiot nodes will no longer be able to use the BluemixService authentication option so you need to select the API Key option instead.



1. Open the ibmiot node for editing.
2. Under node properties, select API Key.
3. For the API Key field, click the edit icon and then enter the API Key and Authentication Token that you saved from the previous step.
4. Save your changes and redeploy your Node-RED flow.
"profilesUrl": "https://us-south.appid.cloud.ibm.com",
"discoveryEndpoint": "https://us-south.appid.cloud.ibm.com/oauth/v4/b42f7429-fc24-48fa-b4f9-616bcb31cfd5/.well-known/openid-configuration"
}









 Obtaining an access token 

After your app is registered with App ID and you have obtained your credentials, you can make a request to the App ID authorization server to get an Access Token.



1. Make an HTTP POST request to the [/token endpoint](https://us-south.appid.cloud.ibm.com/swagger-ui//Authorization%20Server%20-%20Authorization%20Server%20V4/oauth-server.token). The authorization for the request is Basic auth with the client ID and secret being used as the username and password which are base64 encoded.

curl -X POST http://localhost:6002/oauth/v4/39a37f57-a227-4bfe-a044-93b6e6060b61/token -H 'Authorization: Basic base64Encoded{clientId:secret}' -H 'Content-Type: application/x-www-form-urlencoded' -d grant_type=client_credentials

Example response:

{
"access_token": "eyJhbGciOiJS...F9A",
"expires_in": "3600",
"token_type": "Bearer"
}







 Tutorial: End-to-end flow with the Node.js SDK 



getApplicationIdentityToken()
* [Any platform access role](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms)
* [The Writer or Manager service access role](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms)









 Step 1: Deploy an app and expose it by using an NLB 

The first lesson shows you how your app is exposed from multiple IP addresses and ports, and where public traffic is coming into your cluster.

Start by deploying a sample web server app to use throughout the tutorial. The echoserver web server shows data about the connection that is made to the cluster from the client, and you can test access to the PR firm's cluster. Then, expose the app by creating a network load balancer (NLB) 1.0 service. An NLB 1.0 service makes your app available over both the NLB service IP address and the worker nodes' node ports.

Want to use an Ingress application load balancer (ALB)? Instead of creating an NLB in steps 3 and 4, [create a service for the web server app](https://cloud.ibm.com/docs/containers?topic=containers-managed-ingress-setup) and [create an Ingress resource for the web server app](https://cloud.ibm.com/docs/containers?topic=containers-managed-ingress-setup). Then get the public IPs of your ALBs by running ibmcloud ks ingress alb ls --cluster <cluster_name> and use these IPs throughout the tutorial in place of the <loadbalancer_IP>.

The following image shows how the web server app is exposed to the internet by the public node port and public NLB at the end of Lesson 1.

Zoom

![At the end of Lesson 1, the web server app is exposed to the internet by the public node port and public NLB.]
In this example, the NLB has a virtual IP address of 169.61.23.130 and runs on the worker node that has the 10.73.13.25 private IP address. Requests are handled by the NLBs in various zones in a round-robin cycle.
3. The NLB encapsulates the client request packet (labeled as "CR" in the image) inside an IPIP packet (labeled as "IPIP"). The client request packet retains the client IP as its source IP address. The IPIP encapsulating packet uses the worker 10.73.14.25 IP as its source IP address.
4. The NLB routes the IPIP packet to a worker that an app pod is on and that has the private IP address 10.73.13.26. Note that each NLB routes requests to the app instances in its own zone and to app instances in other zones. Additionally, if multiple app instances are deployed in one zone, the NLB routes the requests between the app pods in the zone.
5. Worker 10.73.14.26 unpacks the IPIP encapsulating packet, and then unpacks the client request packet. The client request packet is forwarded to the app pod on that worker node.
6. Worker 10.73.14.26 then uses the source IP address from the original request packet, the client IP, to return the app pod's response packet directly to the client.
The client request packet is forwarded to the app pod on that worker node.
5. Worker 10.73.14.26 then uses the source IP address from the original request packet, the client IP, to return the app pod's response packet directly to the client.







 Traffic flow in a multizone cluster 

The following diagram shows how version 2.0 NLBs in each zone direct traffic from the internet to an app in a multizone cluster.

Zoom

![Expose an app in IBM Cloud Kubernetes Service by using an NLB 2.0](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/cs_loadbalancer_ipvs_multizone.png)

Figure 5. Expose an app in IBM Cloud Kubernetes Service by using an NLB 2.0



1. A request to your app uses the [DNS subdomain](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer_hostname) for your NLBs. You can also access the NLB in each zone by using its public IP address and port on the worker node. Note that by default, each NLB 2.0 is set up in one zone only. To achieve high availability, you must deploy an NLB 2.0 in every zone where you have app instances.
2. A DNS system service resolves the subdomain to the portable public IP address of one of the NLBs and its assigned port on the worker node. In this example, the NLB has a virtual IP address of 169.61.23.130 and runs on the worker node that has the 10.73.13.25 private IP address. Requests are handled by the NLBs in various zones in a round-robin cycle.
3. The NLB encapsulates the client request packet (labeled as "CR" in the image) inside an IPIP packet (labeled as "IPIP"). The client request packet retains the client IP as its source IP address.
Allow the worker nodes to connect to the Ingress LoadBalancer. To find the IPs needed to apply this rule, see [Allow worker nodes to connect to the Ingress LoadBalancer](https://cloud.ibm.com/docs/containers?topic=containers-vpc-security-groupvpc-security-group-loadbalancer-outbound). TCP 443 Ingress load balancer IPs 









 Required inbound and outbound rules for VPC ALBs 

By default, traffic rules for VPC ALBs are covered by the kube-<vpc-id> security group. Note that you should not modify this security group as doing so might cause disruptions in network connectivity between the cluster and the Kubernetes master. However, you can [remove the security group](https://cloud.ibm.com/docs/vpc-infrastructure-cli-plugin?topic=vpc-infrastructure-cli-plugin-vpc-reference&interface=clisecurity-group-target-remove) from your ALB and [replace it](https://cloud.ibm.com/docs/vpc-infrastructure-cli-plugin?topic=vpc-infrastructure-cli-plugin-vpc-reference&interface=clisecurity-group-target-add) with one that you create and manage. If you do so, you must make sure that the following traffic rules are still covered.



 Inbound rules 



Required inbound rules for VPC ALB security groups

 Rule purpose Protocol Port or Value Source 

 If you use your own security group for the LBaaS for Ingress and you expose any applications in your cluster with Ingress, you must allow TCP protocol to ports 443 or 80, or both. You can allow access for all clients, or you can allow only certain source IPs or subnets to access these applications. TCP 80 or 443 All sources, or specific source IP addresses or subnets 
 If you use your own security group for any LBaaS instances that you use to expose other applications, then within that security group you must allow any intended sources to access the appropriate ports and protocols.
Client Version: 4.11.5
Kustomize Version: v4.5.4

 zip
Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.
This is Zip 3.0 (July 5th 2008), by Info-ZIP.

 unzip
UnZip 6.00 of 20 April 2009, by Info-ZIP. Maintained by C. Spieler. Send

 git --version
git version 2.31.1

 curl
curl 7.61.1 (x86_64-redhat-linux-gnu) libcurl/7.61.1 OpenSSL/1.1.1k zlib/1.2.11 brotli/1.0.6 libidn2/2.2.0 libpsl/0.20.2 (+libidn2/2.2.0) libssh/0.9.6/openssl/zlib nghttp2/1.33.0

 wget
GNU Wget 1.19.5 built on linux-gnu.

 openssl version
OpenSSL 1.1.1k FIPS 25 Mar 2021

 make
GNU Make 4.2.1

 docker
Client:
Version: 20.10.18
API version: 1.41
Go version: go1.18.6
Git commit: b40c2f6
Built: Thu Sep 8 23:05:51 2022
OS/Arch: linux/amd64
Context: default

 dc --version
dc (GNU bc 1.07.1) 1.4.1

 ed --version
GNU ed 1.14.2

 skopeo --version
skopeo version 1.8.0
Show more





 Version 3.10 

To view the contents of version 3.10, from the running image, type default_versions.sh. The 3.x branch provides images with the current tool versions. The current Java™ version is Java™ 17. Node.js no longer uses nvm to manage different node.js versions.
In some organizations TLS signed certificates are generated for you by a central certificate authority (CA). In this scenario the CA public certificates must also be included in the PEM file in the order:



* private key
* customer generated certificate
* signer CA certificates



The example below generates a self-signed client certificate and private key and merges them into a single PEM file.

 Generate a new self-signed public certificate and private key
 (fill in the segments of the certificate as you wish when prompted)
openssl req -newkey rsa:2048 -nodes -keyout clientKey.pem -x509 -days 365 -out clientCert.pem

 Combine the private key and public certificate into a single file
cat clientKey.pem > clientCombined.pem
cat clientCert.pem >> clientCombined.pem

If the private key is encrypted you will need to decode it before importing it

Encrypted private keys look like this:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC

To decrypt the private key run the following command supplying the passphrase when prompted.

openssl rsa -in [encrypted.key] -out [decrypted.key]

To import your certificate into the queue manager key store:



1. In the service select the queue manager to configure
2. Click on the Key store tab
3. Click on the Import button ![Image showing how to import a certificate](https://cloud.ibm.com/docs-content/v1/content/3a120b16db5fdc3e70d071af8a63ce5515c1b096/mqcloud/images/mqoc_cert_import.png)
4. Click Browse Files and select your PEM file
5. Click Next
6. Give your certificate a label and click Save
7.
fabric-ca-client register --caname <ca_name> --id.name <name> --id.affiliation org1.department1 --id.type <component_type> --id.secret <secret> --tls.certfiles <ca_tls_cert_path>

Create a name and password for the component and then use them to replace name and secret. Make a note of this information. Set the --id.type to orderer if you are deploying an ordering node, or set it to peer if you are deploying a peer. The command might look similar to the following example:

fabric-ca-client register --caname ca --id.affiliation org1.department1 --id.name peer1 --id.secret peer1pw --id.type peer --tls.certfiles $HOME/fabric-ca-client/catls/tls.pem

You need to save the "enrollid" and "enrollsecret" from the command above for when you create your configuration file.

You can register an identity only once. If you experience a problem, try a command with a new username and password. As a security measure, use each identity, and the accompanying enrollID and secret, to deploy only one peer. While you can use one admin identity for several components (this is the recommended deployment strategy), do not reuse peer IDs and passwords.

When the command completes successfully, you should see information that is similar to the following example:

2018/06/18 16:53:00 INFO] Configuration file location: /fabric-ca-platform/admin/fabric-ca-client-config.yaml
2018/06/18 16:53:00 INFO] TLS Enabled
2018/06/18 16:53:00 INFO] ! ! ! ! ! ! ! TLS Enabled
Password: peerpw
* Node



curl -X POST 'https://iam.cloud.ibm.com/v1/policies' -H 'Authorization: Bearer $TOKEN' -H 'Content-Type: application/json' -d '{
"type": "access",
"description": "Editor role for SERVICE_NAME's RESOURCE_NAME",
"subjects": [
{
"attributes":
{
"name": "access_group_id",
"value": "exampleAccessGroupId"
}
]
}'
],
"roles":[
{
"role_id": "crn:v1:bluemix:public:iam::::role:Editor"
}
],
"resources":[
{
"attributes":
{
"name": "accountId",
"value": "$ACCOUNT_ID"
},
{
"name": "serviceName",
"value": "$SERVICE_NAME"
},
{
"name": "resource",
"value": "$RESOURCE_NAME",
"operator": "stringEquals"
}
]
}
]
}'

SubjectAttribute subjectAttribute = new SubjectAttribute.Builder()
.name("access_group_id")
.value(exampleAccessGroupId)
.build();

PolicySubject policySubjects = new PolicySubject.Builder()
.addAttributes(subjectAttribute)
.build();

PolicyRole policyRoles = new PolicyRole.Builder()
.roleId("crn:v1:bluemix:public:iam::::role:Editor")
.build();

ResourceAttribute accountIdResourceAttribute = new ResourceAttribute.Builder()
.name("accountId")