vania-janet/multiturn-rag-retrieval-data huggingface dataset:
If not set, the context instance specified by ibmcloud cis instance-set INSTANCE is used.--output: Specify output format, only JSON is supported.<-- </section "id="section-upload-cert-options" "> --><-- <section "id="section-upload-cert-examples" "> --> Examples Upload a custom certificate for domain 31984fea73a15b45779fa0df4ef62f9b. ibmcloud cis certificate-upload 31984fea73a15b45779fa0df4ef62f9b --json '{"certificate": "-----BEGIN CERTIFICATE-----nMIIDtTCCAp2gAwIBAgIJAMHAwfXZ5/PWMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNVnBAYTAkFVMRMwEQYDVQQIEwpTb21lLVN0YXRlMSEwHwYDVQQKExhJbnRlcm5ldCBXnaWRnaXRzIFB0eSBMdGQwHhcNMTYwODI0MTY0MzAxWhcNMTYxMTIyMTY0MzAxWjBFnMQswCQYDVQQGEwJBVTETMBEGA1UECBMKU29tZS1TdGF0ZTEhMB8GA1UEChMYSW50nZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBnCgKCAQEAwQHoetcl9+5ikGzV6cMzWtWPJHqXT3wpbEkRU9Yz7lgvddmGdtcGbg/1nCGZu0jJGkMoppoUo4c3dts3iwqRYmBikUP77wwY2QGmDZw2FvkJCJlKnabIRuGvBnKwzESIXgKk2016aTP6/dAjEHyo6SeoK8lkIySUvK0fyOVlsiEsCmOpidtnKX/a+5n0GjB79CJH4ER2lLVZnhePFR/zUOyPxZQQ4naHf7yu/b5jhO0f8fwt+pyFxIXjbEIndZliWRkRMtzrHOJIhrmJ2A1J7iOrirbbwillwjjNVUWPf3IJ3M12S9pEewooaeO2nizNTERcG9HzAacbVRn2Y2SWIyT/18QIDAQABo4GnMIGkMB0GA1UdDgQWBBT/LbE4n9rWf288N6sJA5BRb6FJIGDB1BgNVHSMEbjBsgBT/LbE49rWf288N6sJA5BRb6FJInGKFJpEcwRTELMAkGA1UEBhMCQVUxEzARBgNVBAgTClNvbWUtU3RhdGUxITAfBgNVnBAoTGEludGVybmV0IFdpZGdpdHMgUHR5
In an enterprise environment, work with your corporate domain administrator to obtain the necessary certificates. However, if the custom domain is within your control and you want quickly create a certificate that is not self-certified, then you can optionally use the [Let's Encrypt](https://letsencrypt.org/) service and [Certbot](https://certbot.eff.org/) to obtain a certificate.



1. Install [Certbot](https://certbot.eff.org/). Certbot is a client for the [Automatic Certificate Management Environment (ACME)](https://letsencrypt.org/2019/03/11/acme-protocol-ietf-standard.html/) protocol for automating interactions between a CA and a server. The Let's Encrypt service uses this client to verify domain ownership and issue certificates. From the [Certbot Instructions page](https://certbot.eff.org/instructions), select Other as the software and select the operating system for your workstation to obtain the applicable information to install the Certbot command line.
2. Run the following command to create your certificate. This example command creates a certificate for the example.com and www.example.com custom domains. Be sure to update the command for your own custom domain.

certbot certonly --manual --preferred-challenges dns --email webmaster@example.com --server https://acme-v02.api.letsencrypt.org/directory --agree-tos --domain example.com --domain www.example.com
3. To verify that you own the domain, set a TXT record with your domain registrar for the domains that you requested in the previous step with values that were provided with the Certbot tool output; for example, _acme_challenge.example.com and _acme_challenge.ww.example.com. After you set the TXT record, continue with the Certbot command.
4. Certbot retrieves the certificate that is signed by Let's Encrypt.
Higher numbers are tried first.

<-- </ul> -->

<-- </ul> -->

<-- </ul> -->

Sample JSON data: {
"certificates":
{
"id":"5a7805061c76ada191ed06f989cc3dac",
"priority":2
},
{
"id":"da534493b38266b17fea74f3312be21c",
"priority":1
}
] ! !
}
-s, --json-str: Deprecated. The JSON data used to change the custom certificates' priority.-j, --json-file: Deprecated. A file contains input JSON data.-i, --instance: Instance name or ID. If not set, the context instance specified by ibmcloud cis instance-set INSTANCE is used.--output: Specify output format, only JSON is supported.<-- </section "id="section-change-priority-custom-options" "> --><-- <section "id="section-change-priority-custom-examples" "> --> Examples Change custom certificates' priority for domain 31984fea73a15b45779fa0df4ef62f9b. ibmcloud cis certificate-priority-change 31984fea73a15b45779fa0df4ef62f9b --json '{"certificates": {"id":"5a7805061c76ada191ed06f989cc3dac", "priority":2},{"id":"9a7806061c88ada191ed06f989cc3dac","priority":1}] ! ! ! }' -i "cis-demo"
* For IBM domains, you must also have an on-premises DNS resolver that points to either the user's DNS (Direct Link) or the custom resolver (Transit Gateway) in your VPC. You can then connect directly to the VPE and access IBM Cloud services.
* If accessing the VPC from another VPC, you only need a custom resolver, which forwards to the custom resolver in the VPC that has the VPE.



2. Create a VPE. For more information, see [Creating an endpoint gateway](https://cloud.ibm.com/docs/vpc?topic=vpc-ordering-endpoint-gateway).
3. Attach a new or existing security group (or modify the default security group) to allow inbound traffic to the VPE.



* Enable this feature within an account that has a VPC with a VPE already provisioned. To do so, you must [create a custom resolver](https://cloud.ibm.com/docs/dns-svcs?topic=dns-svcs-custom-resolver) before you can access the VPE over IBM Cloud Direct Link.

For IBM domains, you must have an on-premises DNS resolver that points to either the user's DNS (Direct Link) or the custom resolver (Transit Gateway) in your VPC. Then, you can connect directly to the VPE and access IBM Cloud services.

For resolutions of the VPE endpoints, you must forward the DNS requests to the custom resolvers within the DNS service that is provisioned within your VPC so that it can resolve the VPE addresses.



3. Verify that you have access from the direct link:

You should now be able to access a VPC API endpoint from an on-prem network through your Direct Link. You can use this VPC API endpoint over IBM Cloud Direct Link to provision additional resources in your VPC, such as VPEs for other IBM Cloud services.
Private ALBs do not reference the IBM-provided Ingress subdomain and instead require a [custom domain](https://cloud.ibm.com/docs/containers?topic=containers-managed-ingress-setupingress-custom-domain).

The subdomain is registered in the following format.

<cluster_name>.<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud

The following table describes each portion of the subdomain.



Understanding the Ingress subdomain format

 Subdomain component Description 

 * The wildcard for the subdomain is registered by default for your cluster. 
 <cluster_name> The name of your cluster.<br><br><br><br> * If the cluster name is 26 characters or fewer and the cluster name is unique in this region, the entire cluster name is included and is not modified: myclustername.<br> * If the cluster name is 26 characters or fewer and there is an existing cluster of the same name in this region, the entire cluster name is included and a dash with six random characters is added: myclustername-ABC123.<br> * If the cluster name is 26 characters or greater and the cluster name is unique in this region, only the first 24 characters of the cluster name are used: myveryverylongclusternam.<br> * If the cluster name is 26 characters or greater and there is an existing cluster of the same name in this region, only the first 17 characters of the cluster name are used and a dash with six random characters is added: myveryverylongclu-ABC123.<br><br><br> 
 <globally_unique_account_HASH> A globally unique HASH is created for your IBM Cloud account. All subdomains that you create for NLBs in clusters in your account use this globally unique HASH. 
 0000 The first and second characters indicate a public or a private (internal) subdomain. 00 indicates a subdomain that has a public DNS entry. i0 indicates a subdomain that has a private DNS entry.
--syslog-protocol When the logging type is syslog<, the transport layer protocol. You can use the following protocols: udp, tls, or tcp. When forwarding to a rsyslog server with the udp protocol, logs that are over 1KB are truncated. 
 --ca-cert Required: When the logging type is syslog and the protocol is tls, the Kubernetes secret name that contains the certificate authority certificate. 
 --verify-mode When the logging type is syslog and the protocol is tls, the verification mode. Supported values are verify-peer and the default verify-none. 
 --skip-validation Optional: Skip the validation of the org and space names when they are specified. Skipping validation decreases processing time, but an invalid logging configuration does not correctly forward logs. 







 Forwarding logs to your own server over the udp or tcp protocols 



1. Ensure that you have the [Editor or Administrator IBM Cloud IAM platform access role](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms).
2. For the cluster where the log source is located: [Log in to your account. If applicable, target the appropriate resource group. Set the context for your cluster.](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster)
3. Set up a server that accepts a syslog protocol in 1 of 2 ways:
: Set up and manage your own server or have a provider manage it for you. If a provider manages the server for you, get the logging endpoint from the logging provider.
: Run syslog from a container. For example, you can use this [deployment .yaml file](https://github.com/IBM-Cloud/kube-samples/blob/master/deploy-apps-clusters/deploy-syslog-from-kube.yaml) to fetch a Docker public image that runs a container in your cluster.
[Image showing bob receiving plain-text message](https://cloud.ibm.com/docs-content/v1/content/3a120b16db5fdc3e70d071af8a63ce5515c1b096/mqcloud/images/mqoc_app_ams_pt_getpq.png)





* Note that the message comes back in plain text while reading the queue, as this is how it is stored on the target queue.





This test confirms that alice and bob can send and receive messages on the target queue. Next step is to create the configuration required by AMS for end to end security. This includes creating keystores and certificates for these users to enforce signing and encryption of messages.





 Setup Keystores for alice and bob 

Application AMS is based on public/private key encryption with keys stored in standard X.509 certificates, which in turn are stored in a platform-appropriate keystore. These certificates are the same type of certificates that are used for MQ Secure Sockets Layer (SSL) and Transport Layer Security (TLS) encryption, and in fact the application can utilize the same certificates and keystores for both, if desired. This tutorial creates new keystore and certificates for users alice and bob.

All of alice's steps have to be executed in alice's command shell and all of bob's steps to be executed in bob's command shell.



1. Create directories for setting up keystores

For alice:
- On Mac: mkdir -p /alice/.mqs
- On Linux: mkdir -p /home/alice/.mqs
- On Windows: mkdir %HOMEDRIVE%Usersalice.mqs

For bob:
- On Mac: mkdir -p /bob/.mqs
- On Linux: mkdir -p /home/bob/.mqs
- On Windows: mkdir %HOMEDRIVE%Usersbob.mqs
2. Create key database

For alice:
[Checkbox icon](https://cloud.ibm.com/docs-content/v1/content/ff5860bfede49db3197c4bbba7f7123769bdc068/icons/checkbox-icon.svg) View the IBM Cloud Open Service Broker API documentation Review the criteria that the broker must meet. The IBM Cloud Open Service Broker extends the Open Service Broker 2.12 specification. For more information, see [Open Service Broker API](https://cloud.ibm.com/apidocs/resource-controller/ibm-cloud-osb-api). Documentation 
 ![Checkbox icon](https://cloud.ibm.com/docs-content/v1/content/ff5860bfede49db3197c4bbba7f7123769bdc068/icons/checkbox-icon.svg) Develop your service broker Use your development environment and IBM Cloud resources to develop your broker. Development environment and documentation 
 ![Checkbox icon](https://cloud.ibm.com/docs-content/v1/content/ff5860bfede49db3197c4bbba7f7123769bdc068/icons/checkbox-icon.svg) Host your Open Service Broker The hosted location of the service broker must follow Transport Layer Security (TLS) protocol version 1.2. The service broker must be hosted as part of an app that can respond to REST API calls, and it must meet IBM Cloud security guidelines. Development environment and documentation 
 ![Checkbox icon](https://cloud.ibm.com/docs-content/v1/content/ff5860bfede49db3197c4bbba7f7123769bdc068/icons/checkbox-icon.svg) Test your hosted Open Service Broker Validate each of the API endpoints your service broker supports by running curl commands against your hosted service broker. Validate your service broker by running curl commands against the different endpoints you’re enabling. Development environment and documentation 
 !
After the VLAN is provisioned, you can request to trunk the hosts. VLAN must be trunked to all hosts in your cluster through IBM Cloud Classic portal (Classic Infrastructure > Network > Gateway appliances). Then, add the ESX hosts to a wanted NSX-T VLAN transport zone, for example tz-bridge.
3. On the edge cluster uplink distributed port group, enable Promiscuous mode and Forged transmits for bridging. Add these settings to the wanted NSX-T VLAN transport zone, for example tz-bridge.
4. When you configure an NSX-T overlay segment, you can specify an Edge bridge profile to enable layer 2 bridging. Use the VLAN ID of the additional bridged VLAN on your configuration.
5. Provision your servers (for example Bare Metal Servers) normally to the VLAN, and after the provisioning you can change the IP configuration to match your NSX-T overlay design. Logically, you can attach the server to the same subnet as configured on your NSX-T overlay segment.
6. After the change, your server's default gateway is Tier 1 (T1) gateway's IP address. You can then communicate with the VMs on your overlay segments and use NSX-T gateway firewalls.



To use the capability, you can either use the existing workload edge cluster, or deploy a new edge cluster for bridging. If you use the existing workload edge cluster, you must create the edge bridge profile by using that cluster and change the existing-distributed port group to allow Promiscuous mode and Forged transmits. This setup shares the capacity of the private uplinks from the edge nodes for both private routed and bridged traffic. Transport zones are defined in the edge host switch (N-VDS), for example add the new tz-bridge to nvds-edge-private.

Zoom

!
As an account owner or admin, review the existing access policies for all Key Protect users in your account to ensure that they are assigned the appropriate levels of access. To learn more about Key Protect roles and permissions, see [Managing user access](https://cloud.ibm.com/docs/key-protect?topic=key-protect-manage-access).







 September 2019 



 27 September 2019 

Key Protect supports fine-grain access
: As an account admin, you can now assign fine-grained access to individual keys within a Key Protect instance. To learn more about granting access, see [Granting access to keys](https://cloud.ibm.com/docs/key-protect?topic=key-protect-grant-access-keys).





 16 September 2019 

Transport keys deprecated, replaced with import tokens
: On 20 March 2019, [Key Protect announced transport keys](https://cloud.ibm.com/docs/key-protect?topic=key-protect-key-protect-key-protect-relnotesadded-transport-keys-beta) as a beta feature for importing encryption keys to the cloud with an extra layer of security. We're happy to announce that the feature has now reached its end of beta period. The following API methods have changed:



* POST api/v2/lockers is now POST api/v2/import_token
* GET api/v2/lockers is now GET api/v2/import_token
* GET api/v2/lockers/{id} is no longer supported



You can now create [import tokens](https://cloud.ibm.com/docs/key-protect?topic=key-protect-importing-keysusing-import-tokens) to enable added security for keys that you upload to Key Protect.

To find out more about your options for importing keys, check out [Bringing your encryption keys to the cloud](https://cloud.ibm.com/docs/key-protect?topic=key-protect-importing-keys).
The following diagram shows an example of a multisite – multitenant topology. It consists of a two layer Tier-0 design with three edge clusters. The routing table separation is done at Tier-1 and optionally also at the regional Tier-0 level. For this, consider two edge clusters in the two data centers or zones in a multizone region. And also, one edge cluster deployed across the multizone region with edge nodes in each participating zone or data center.

Zoom

![Multisite – multitenant example topology](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/v2t-diagrams-2-zone-mt.svg)

Figure 5. Multisite – multitenant example topology



1. The vCenter Server automation deploys a single site solution, which can be manually expanded to support the target multisite topology. The deployment includes a single vCenter and three NSX-T Managers that are deployed on the cluster on the initial IBM Cloud data center location. You must expand the compute capacity to have resources available in the other IBM Cloud data center or zone in the specific IBM Cloud multizone region.
2. The vCenter Server automation deploys two edge cluster transport nodes and a single edge cluster for your Tier-0 and Tier-1 gateways. The default Tier-1 Gateway is not necessary, and it can be removed.
3. In the initial IBM Cloud data center, access to private network is provided though private uplinks, which are attached to a portable subnet on a private primary VLAN on the IBM Cloud private network. If you provision your instance with public interfaces, access to public network is provided though public uplinks, which are attached to a portable subnet on a public VLAN on the IBM Cloud public network. The uplinks have specific IP addresses to this data center and they cannot move between the data centers.
4. You must deploy two additional edge cluster transport nodes manually.
: Crawls all entries, then filters out any entries that were inserted, updated, or deleted since the last crawl.

Crawling new and modified content
: Runs an LDAP query against the data source server to pick up any entries that were inserted or updated only.

For more information, see [Crawl schedule options](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-collectionscrawlschedule).
7. Configure a secure connection to the directory.

Server type
: Choose your server type from the following options:



* IBM Security Directory Server
* Microsoft Active Directory
* Oracle Directory Server



LDAP protocol
: If you want to encrypt data and verify the server certificate over Transport Layer Security (TLS), choose ldaps.

LDAP host name
: Specify the hostname of the directory server. For example: <ldap-hostname>.mydomain.com.

LDAP host port
: By default, the LDAP port is 389 and the LDAP-S port is 636.

LDAP binding username
: If the directory server requires credentials, the username that is used to bind to the directory service.

In most cases, this username is a distinguished name (DN). The username is case-sensitive.

LDAP binding user password
: The password that is associated with the username.
8. Specify the information that you want to index from the directory.

LDAP Base DN
: The object where you want to start the crawl.

LDAP directories have a hierarchical tree structure of objects. The base search distinguished name specifies the subtree in which you want the crawl to be constrained.

DN is a distinguished name that is defined by a series of relative distinguished names separated by commas. Each relative distinguished name consists of an attribute name-and-value pair that represents an object in a directory.

For example, in Active Directory, attributes can include a common name (CN) such as Jane Doe and an organizational unit (OU) such as Research.
Then, create a new edge cluster for the Tier-0 and Tier-1 Gateways through NSX-T. This overlay topology is highly scalable and it is possible to automate, for example, by using Ansible and Terraform.

The following diagram shows an example of a multisite – single tenant network topology. It consists of a two layer Tier-0 design with three edge clusters. Two edge clusters in the two data centers or zones in a multizone region, and one edge cluster deployed across the multizone region with edge nodes in each participating zone or data center.

Zoom

![Multisite – single tenant example topology](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/arch-pattern-2-zone.svg)

Figure 1. Multisite – single tenant example topology



1. The vCenter Server automation deploys a single site solution, which can be manually expanded to support the target multisite topology. The deployment includes a single vCenter and three NSX-T Managers that are deployed in the cluster on the initial IBM Cloud data center location. You must expand the compute capacity to have resources available in the other IBM Cloud data center or zone in the specific IBM Cloud multizone region.
2. The vCenter Server automation deploys two edge cluster transport nodes and a single edge cluster for your Tier-0 and Tier-1 Gateways. You do not need the default Tier-1 Gateway, and it can be removed.
3. In the initial IBM Cloud data center, the access to private network is provided through private uplinks. They are attached to a portable subnet in a private primary VLAN on the IBM Cloud private network. If you provision your instance with public interfaces, the access to public network is provided through public uplinks. They are attached to a portable subnet on a public VLAN on the IBM Cloud public network. The uplinks have IP addresses specific to this data center and they cannot move between the data centers.
4. You must manually deploy two additional edge cluster transport nodes.
Layer 7 pool 

A Layer 7 (L7) pool is a logical grouping of the servers (members) for handling incoming requests.

The Layer 7 load balancing feature can direct the incoming traffic to different back-end pools based on the policies and rules. This feature is supported by associating multiple L7 pools with a load balancer. Layer 7 pools are used with the Layer 7 policies whose action is redirect to pool.

L7 pools support both HTTP and HTTPS as the back-end protocol.



  Session persistence 

Session persistence can be configured for each Layer 7 pool. For more information, see [Advanced traffic management with IBM Cloud Load Balancer](https://cloud.ibm.com/docs/loadbalancer-service?topic=loadbalancer-service-advanced-traffic-management-with-ibm-cloud-load-balancer).





  Layer 7 members 

Back-end servers that are associated with a Layer 7 pool are called Layer 7 members.

The same back-end server can be added multiple times to L7 pools, by specifying a different port number each time.





  Configure health checks 

The health check definition is mandatory for each Layer 7 pool. The system pre-populates a default health check configuration for L7 pools.

You can customize these settings to suit your application needs:



*  Interval - The interval in seconds between two consecutive health check attempts.
*  Timeout - The maximum amount of time the system waits for a response to the health check request.
*  MaxRetries - The maximum number of additional health check attempts that the system makes before declaring the service unhealthy.
*  UrlPath - The HTTP URL path for the Layer 7 health check.