vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* authentication - Identifies what type of authentication mechanism to use while contacting a CMIS-compatible repository: Basic HTTP Authentication, NTLM, or WS-Security(Username token).
* enable-acl - Enables retrieving ACLs for crawled data. If you are not concerned about security for the documents in this collection, disabling this option increases performance by not requesting this information with the document and not retrieving and encoding this information. Value is either true or false.
* user-agent - A header sent to the server when crawling documents.
* method - The method (GET or POST) by which parameters are passed.
* url-logging - The extent to which crawled URLs are logged. Possible values are:



* full-logging - Log all information about the URL.
* refined-logging - Only log the information necessary to browse the crawler log and for the connector to function correctly; this is the default value.
* minimal-logging - Only log the minimum amount of information necessary for the connector to function correctly.



Setting this option to minimal-logging reduces the size of the logs and gain a slight performance increase due to the smaller I/O associated with minimizing the amount of data that is being logged.
* ssl-version - Specifies a version of SSL to use for HTTPS connections. By default the strongest protocol available is used.







 Configuring the CMIS Crawl Seed 

The following values can be configured for the CMIS crawl seed file. To set these values, open the file config/seeds/cmis-seed.conf and modify the following values specific to your use cases:



* url - The URL of a folder from the CMIS repository to be used as a starting point of the crawl, for example: cmis://alfresco.test.com:8080/alfresco/cmisatom?folderToProcess-workspace://SpacesStore/guid

To crawl from the root folder, you need to give the URL as: cmis://alfresco.test.com:8080/alfresco/cmisatom?folderToProcess-
* at - Unused option.
* default-allow - Internal use only.
* UI
* CLI







 Sharing private catalog products 

You can share products in your private catalog with users in your account, account groups within your enterprise, the entire enterprise, and even other enterprises that you have access to. By sharing your product, any user within the account, enterprise, or account groups can create an instance of your product.

The following flowchart shows three use cases for sharing your product. Each pathway addresses who you want to share your product with, if you need certain IAM permissions, and if you need approval through Partner Center Sell. If you need approval from Partner Center Sell, see [Selling on IBM Cloud](https://cloud.ibm.com/docs/sell).

If you received approval through Partner Center, you can share your product to any user.

Zoom

![A flow chart of the approvals and permissions that are necessary to share a product.](https://cloud.ibm.com/docs-content/v1/content/4d8c6eec891cff72b666dc24bd3211810c77fb42/account/images/Sharing-publishing.png)

Figure 1. Flow chart of the approvals and permissions that are necessary to share a product



 Before you begin 



1. You must be assigned the following access. For more information, see [Assigning users access](https://cloud.ibm.com/docs/account?topic=account-catalog-access).



* Editor role on the Enterprise account management service in the enterprise account.
* Administrator role on the Catalog Management account management service in the same account as your product.



2. Verify that at least one version of your product is in the ready state.







 Sharing your product by using the console 

When you share a product with enterprises, users in your account, or account groups, they can create instances of any version that is validated and in the ready state. Versions that are in the draft state are not shared with users. Complete the following steps to share your product:



1. In the IBM Cloud® console, click Manage > Catalogs > Private catalogs.
2.
AlgorithmID: kp.KP_QSC_ALGO_p384_KYBER768,
}
3. Compile the Key Protect SDK by running the following command:

LD_LIBRARY_PATH=$HOME/opt/oqssa/lib PKG_CONFIG_PATH=$HOME/opt/oqssa/lib/pkgconfig go build –-tags quantum









 Using Quantum Safe Key Protect endpoints via CURL 



 Prerequisites 

Before making a curl request to a Key Protect quantum safe enabled endpoint, follow these steps:



1. Download the [Open Quantum Safe Software Stack (OQSSA) script](https://github.com/IBM/oqssa/blob/master/build-oqssa.sh). This script will build and install all necessary dependencies ( liboqs, openssl, and libcurl) into your HOME directory folder ( $HOME/opt/oqssa/).
2. Make sure dependent packages required for building OQSSA are installed. You will need sudo permissions in order to install the dependency packages.



* Debian (Ubuntu) dependencies: libtool automake autoconf cmake (3.5 or above) make openssl libssl-dev build-essential git wget golang (1.14 or above) patch perl diffutils



If you are using a Debian distribution, copy the following code snippet to a file and execute it to verify that all necessary packages have been installed:

echo "Starting prerequisites verification"
CMAKE_VER_REQUIRED="3."
packages="libtool automake autoconf cmake make openssl libssl-dev git wget build-essential golang patch perl diffutils"
for REQUIRED_PKG in $packages
do
PKG_STATUS=$(dpkg-query -W --showformat='${Version},${Status}n' $REQUIRED_PKG|grep "install ok installed")
Ensure that your application servers are either on this subnet or reachable from this subnet. If necessary, enable VLAN spanning.
6. Select the allocation of public IPs for the load balancer.

This option applies to only the Public-to-Private load balancer type. If you select the option Allocate from a public subnet in this account, you must ensure that you have at least two public IPs available in a public subnet in the same data center. Also, ensure that traffic to TCP management port 56501 and your application's own ports are not blocked by firewalls that is deployed on your public VLANs.





 What's next 

[Configuring load-balancing options and placing your order](https://cloud.ibm.com/docs/loadbalancer-service?topic=loadbalancer-service-configure-load-balancing-parameters-and-place-order).
If you aren't sure where a bucket is located, there is an [extension to the bucket listing API](https://cloud.ibm.com/docs/cloud-object-storage/api-reference?topic=cloud-object-storage-compatibility-api-bucket-operationscompatibility-api-list-buckets-extended) that returns the location and storage class information for all buckets in a service instance.

When using Virtual Private Endpoints in an application that makes requests to IBM COS, it may be necessary to add some additional configuration for authentication. The IBM COS SDKs will automatically attempt to fetch an IAM token from https://iam.cloud.ibm.com/identity/token. If you are using a virtualized endpoint for token acquisition you will need alter the IAM endpoint appropriately.





 Regional Endpoints 

Buckets that are created at a regional endpoint distribute data across three data centers that are spread across a metro area. Any one of these data centers can suffer an outage or even destruction without impacting availability.

Public

Private

Direct



Table 1. Regional Endpoints

 Region Type Endpoint 

 us-south Public s3.us-south.cloud-object-storage.appdomain.cloud 
 us-east Public s3.us-east.cloud-object-storage.appdomain.cloud 
 eu-gb Public s3.eu-gb.cloud-object-storage.appdomain.cloud 
 eu-de Public s3.eu-de.cloud-object-storage.appdomain.cloud 
 au-syd Public s3.au-syd.cloud-object-storage.appdomain.cloud 
 jp-tok Public s3.jp-tok.cloud-object-storage.appdomain.cloud 
 jp-osa Public s3.jp-osa.cloud-object-storage.appdomain.cloud 
 ca-tor Public s3.ca-tor.cloud-object-storage.appdomain.cloud 
 br-sao Public s3.br-sao.cloud-object-storage.appdomain.cloud 
 eu-es Public s3.eu-es.cloud-object-storage.appdomain.cloud
* The viewer role provides the least amount of access for viewing instances and resource groups in an account.
* The operator role includes actions such as the ability to view instances and manage aliases, bindings, and credentials.
* The editor role includes actions the same actions of an operator role but also actions for creating, editing, deleting, and binding service instances.
* The administrator role includes everything for working with a service instance and assigning access to others for that service or instance that the policy is for.



While these are the most popular roles for assigning access in the platform, there are a second set of roles to consider called service roles. The actions mapped to these roles are defined by each service. Typically the actions mapped to these roles relate specifically to the ability to work with a service's APIs and UI.

For more information about the roles that can be assigned, see [IAM roles](https://cloud.ibm.com/docs/account?topic=account-userrolesiamusermanrol).





 Reducing time and effort to manage access 

There is a [limit](https://cloud.ibm.com/docs/account?topic=account-known-issuesiam_limits) on the total number of policies that are allowed in an account. You can use a few strategies to ensure that you don't reach the limit and to reduce the amount of time that you spend managing access for the identities in your account (users, service IDs, or trusted profiles):



* Use the principle of least privilege and assign only the access that is necessary. This can help you ensure that the identities in your account are limited to only the actions that you want to allow. For example, time-based conditions for access policies grant access during only the timeframe you specify, reducing the opportunity for attack in the event of a security breach. For more information, see [Limiting access with time-based conditions](https://cloud.ibm.com/docs/account?topic=account-iam-time-based&interface=ui).
* Add resources to a resource group to further minimize the number of necessary policies. For example, you might have a team working on a project that uses specific resources in your account.
Asia-Pacific TOK05 01 







 VLANs 

Network settings are based on your selection of Order new VLANs or Select existing VLANs.

One public VLAN and two private VLANs are required for your instance order. The two private VLANs are trunked into each IBM Cloud bare metal server.



 Order new VLANs 

Select to order one new public VLAN and two new private VLANs.





 Select existing VLANs 

Depending on the IBM Cloud data center that you selected, existing public and private VLANs might be available.

When you select to reuse existing public and private VLANs, specify the VLANs and subnets:



* Public VLAN is for public network access. If you select the Allocate a new one option for this field, a new public VLAN is allocated automatically. This field is only available on the Public and private network tab.
* Public primary subnet is assigned to physical hosts for public network access. If you select the Auto assigned option for this field, a new public primary subnet is selected automatically and a new one is created if necessary. This field is only available on the Public and private network tab.
* Private VLAN is for connectivity among the data centers and services within the IBM Cloud. If you select the Allocate a new one option for this field, a new private VLAN is allocated automatically.
* Private primary subnet is assigned to physical hosts for management traffic. If you select the Auto assigned option for this field, a new private primary subnet is selected automatically and a new one is created if necessary.
* Secondary private VLAN is for VMware features such as vSAN. You can select an existing secondary private VLAN or select to allocate a new one.



Ensure that the firewall configuration on the selected VLANs does not block the management data traffic. Also, ensure that all the VLANs that you select are in the same pod. ESXi servers cannot be provisioned on mixed-pod VLANs.

Optionally, use Advanced settings to configure portable subnets for VLANs.
: Removed all [virtual machine worker node flavors](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodesvm) that are 48 or more cores. You can still provision [bare metal worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodesbm) with 48 or more cores.





 8 May 2019 

API
: Added a link to the [global API swagger docs](https://containers.cloud.ibm.com/global/swagger-global-api//).

Cloud Object Storage
: [Added a troubleshooting guide for Cloud Object Storage](https://cloud.ibm.com/docs/containers?topic=containers-cos_pvc_pending) in your IBM Cloud Kubernetes Service clusters.

Kubernetes strategy
: Added a topic about [What knowledge and technical skills are good to have before I move my apps to IBM Cloud Kubernetes Service?](https://cloud.ibm.com/docs/containers?topic=containers-strategyknowledge).

Kubernetes version 1.14
: Added that the [Kubernetes 1.14 release](https://cloud.ibm.com/docs/containers?topic=containers-cs_versionsk8s_version_archive) is certified.

Reference topics
: Updated information for various service binding, logging, and nlb operations in the [user access](https://cloud.ibm.com/docs/containers?topic=containers-access_reference) and [CLI reference](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cli) pages.





 7 May 2019 

Cluster DNS provider
: [Explained the benefits of CoreDNS](https://cloud.ibm.com/docs/containers?topic=containers-cluster_dns) now that clusters that run Kubernetes 1.14 and later support only CoreDNS.

Edge nodes
These policies are not meant to block everything, nor do they necessarily meet any compliance requirements on their own. They are intended as a starting point and must be edited to meet your unique use cases. For more information, see the [README](https://github.com/IBM-Cloud/kube-samples/tree/master/calico-policies).

Whenever new locations for IBM Cloud Kubernetes Service and other IBM Cloud are enabled, the subnets for these locations are added to the Calico policies. Be sure to [watch the GitHub repository](https://github.com/IBM-Cloud/kube-samples/tree/master/calico-policies/public-network-isolation) for any updates to these policies.

When you apply the egress pod policies that are in this policy set, only network traffic to the subnets and ports that are specified in the pod policies is permitted. All traffic to any subnets or ports that are not specified in the policies is blocked for all pods in all namespaces. Because only the ports and subnets that are necessary for the pods to function in IBM Cloud Kubernetes Service are specified in these policies, your pods can't send network traffic over the private network until you add or change the Calico policy to allow them to.

Before you begin, [install and configure the Calico CLI, and set the context for your cluster to run Calico commands](https://cloud.ibm.com/docs/containers?topic=containers-network_policiescli_install).



1. Clone the IBM-Cloud/kube-samples repository.

git clone https://github.com/IBM-Cloud/kube-samples.git
2. Go to the private policy directory for the region that your cluster is in. Example command for a cluster in US South:

cd <filepath>/IBM-Cloud/kube-samples/calico-policies/private-network-isolation/us-south
3. Review each policy for any changes you might need to make.
* Create your required NSX-T network topology and configure the necessary network services.
* Configure an NSX-T Edge bridge to extend the NSX-V VXLAN/logical switch/virtual wire to an overlay segment in NSX-T.
* Use the VMware Migration Coordinator to migrate (copy across) the Distributed Firewall (dFW) configuration.
* The dFW only migration mode of the migration coordinator must be run only one time. After the dFW configuration is migrated to NSX-T, do not update the dFW configuration in the NSX-V environment.
* Switch the default gateway to the NSX-T environment.
* Use NSX-T Edge bridge and vSphere vMotion to migrate workload VMs to the overlay segment in NSX-T.
* Migrate the Security Tags to the workload VMs in NSX-T.
* Continue with all NSX-V logical switches until all VMs be evacuated from the NSX-V environment.
* Decommission the old vCenter Server with NSX-V environment.



Depending on the source environment complexity and the skills, experience and time commitments of your team you might want to engage professional services. This action can develop a migration plan and also run the migration for you.



 Considerations for migration 

You must be familiar with NSX-T concepts and administration tasks before any migrations. Review the following information:



* [VMware Learning for NSX-T education](https://www.vmware.com/learning.html)
* [IBM Cloud VMware NSX-T Architecture](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-nsx-t-design)
* [vCenter Server Overview](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_vcenterserveroverview)
"cacert": ""
},
"enrollid": "",
"enrollsecret": "",
"admincerts": ""]
},
"tls": {
"cahost": "",
"caport": "",
"caname": "",
"catls": {
"cacert": ""
},
"enrollid": "",
"enrollsecret": "",
"csr": {
"hosts": ""] !
}
}
}
}
Show more
Copy this entire file into a text editor where you can edit it and save it to your local file system as a JSON file. Use the steps below to complete this configuration file and use it to deploy an ordering service or peer.<-- <section "id="section-ibp-v2-apis-config-connx-info" "> --> Retrieve the CA connection information First, we need to provide the connection information of your CA on the IBM Blockchain Platform. You can use the console UI or the APIs to get the necessary information about your CA.If you are using the IBM Blockchain Platform console: Open the CA in your console and click Settings, then the Export button to export the CA information to a JSON file. You can use the values from this file to complete your configuration file.If your are using the APIs: You can call GET /ak/api/v2/components]GET _components] ! ! ! ! ! to get the connection information of your CA. If you created the CA with the Create a Fabric CA API, you can also find the necessary information in the response body.<-- <ul> --> * The "cahost" and "caport" values are visible in the ca_url field in the response body or CA JSON file that you exported.
View the Support page by clicking the question mark icon ![Support link icon](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/blockchain/images/support-link.png) in the upper right corner of the page. The IBM Blockchain Platform version is visible under the page heading.





 How do I get the latest Fabric version and Fabric functionalities on my IBM Blockchain Platform network? 

Depending on the contents of a Fabric release and IBM Blockchain Platform, it might only be necessary to upgrade nodes to get access to the latest features. However, often it is necessary to update channel configurations with the latest capabilities in order to get access to the latest Fabric features. In these cases, it is important to upgrade components and channels in a particular order:



1. Upgrade nodes to the latest Fabric versions. Note that nodes are always backward compatible with earlier versions and earlier capabilities. For more information about upgrading nodes, see [Upgrading to a new version of Fabric](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-govern-componentsibp-console-govern-components-upgrade).
2. Update channels with any new channel capabilities. If you update capabilities to a capability level (such as 2.0) before upgrading nodes to the Fabric version corresponding to a capability, the node may crash. For more information, see [Capabilities](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-governibp-console-govern-capabilities).



If you are moving from v1.4.x to v2.x, you may have to update your smart contracts to conform to new smart contract lifecycle. For more information, see [Upgrading to a new version of Fabric](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-smart-contracts-v2ibp-console-smart-contracts-v2).
Depending on the type of subnet, the Status and Description columns present different values for IP addresses.

For [Primary subnets](https://cloud.ibm.com/docs/subnets?topic=subnets-about-subnets-and-ipsprimary-subnets), the status and description columns give contextual usage information, but are not intended to inform customer behavior, because primary IP addresses are assigned automatically and managed by IBM Cloud. For primary IP addresses, the status column shows either Reserved or In use, dependent upon whether a resource is assigned to the IP address and whether or not you have access to that resource.

For [Secondary subnets](https://cloud.ibm.com/docs/subnets?topic=subnets-about-subnets-and-ipssecondary-subnets), only the IP addresses necessary for the subnet to function are marked Reserved. All IP addresses on routed subnets that are not marked with Reserved are available for use. [Static subnets](https://cloud.ibm.com/docs/subnets?topic=subnets-about-subnets-and-ipsstatic-subnets) do not require any reservations to function, so all IP addresses show a status of In use, and have a description of "Routed to <IP address><resource>". Here, <resource> can represent the targeted IP address subnet or compute hostname. [Portable subnets](https://cloud.ibm.com/docs/subnets?topic=subnets-about-subnets-and-ipsportable-subnet) do require some IP addresses in order to function. These IP addresses are shown with a status of Reserved, and are not available for use. The description column indicates why the IP address is reserved in these cases. [Unrouted subnets](https://cloud.ibm.com/docs/subnets?topic=subnets-re-routing-secondary-subnets) do not require any reservations to function, because these subnets are not routed on the {site.data.keyword.cloud_notm} network. These IP addresses are shown with a status of Unrouted and are not available for use until the subnet is routed again.
Connect the VPC to a [Transit Gateway](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-ordering-transit-gateway&interface=uitg-ui-creating-transit-gateway).
4. [Create a cloud connection](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-cloud-connectionscreate-cloud-connections) to connect the non-PER Power Systems Virtual Server workspace to the same transit gateway.



The Power Systems Virtual Server would then use the VPE's IP address to connect to COS. If the VPE has multiple IP addresses, you can set up custom DNS and a custom hostname to connect to COS.
3. Deploy a Nginx reverse proxy server in either the classic or VPC infrastructure.

Nginx is a mature, compact, and fast open source web server that excels at specialized tasks, including the reverse proxy server role. For information on setting up a Nginx reverse proxy server, see [Installing your Nginx reverse proxy](https://cloud.ibm.com/docs/direct-link?topic=direct-link-using-ibm-cloud-direct-link-to-connect-to-ibm-cloud-object-storagedirect-link-installing-your-nginx-reverse-proxy).





 Cloud Object Storage on AIX 

IBM Power Systems that are running AIX 7.2 TL3, or later, have a script that is located in the path, /usr/samples/nim/cloud_setup. The cloud_setup command installs the command-line environment for cloud storage services.

cloud_setup [-I | G | C] [-v]

-I: Install the necessary RPMs for universal CLI (supports COS).
-G: Install the necessary RPMs for gsutil CLI (Google Cloud Storage).
-C: Install the necessary RPMs for cloud-init.
-v: Enable debug output.



1. To begin, copy the file to the system that requires AWS and give it execute permission.
2.