vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Rotating your root keys 

It is a best practice to rotate your root keys (that is, to create a new version of the key) on a regular basis. Regular rotations reduce what is known as the "cryptoperiod" of the key, and can also be used in specific cases such as personnel turnover, process malfunctions, or the detection of a security issue.

If you suspect a key has been compromised, disable it as soon as possible. Check out [Disabling root keys](https://cloud.ibm.com/docs/key-protect?topic=key-protect-disable-keys) for more information.

Recall that root keys are not just used to create data encryption keys (DEKs), they are also used in conjunction with a master key (secured by IBM using a Hardware Security Module) to create a "wrap" of a DEK. The resulting "wrapped data encryption key" (WDEK) protects the DEK, which is used to encrypt data. If a user has a DEK they want to use, that key can be passed when creating a WDEK using the wrap call. If no DEK is specified, Key Protect creates the DEK for you.

Rotating to a new version of the root key does not immediately create a new WDEK, but it does mean that on the next wrap and re-wrap initiated by the user that the new root key will be used to create the new WDEK. Note that the new WDEK can also be unwrapped and used to read data encrypted with older versions of the DEK, and that old versions of the WDEK can still be unwrapped to obtain the DEK.

Each rotation creates a new "version" of the key, and you are charged on your IBM Cloud account per key version. Check out [Pricing](https://cloud.ibm.com/docs/key-protect?topic=key-protect-pricing-plan) for more information.



 Rotating manually or automatically 

Only root keys can be rotated using Key Protect. Standard keys cannot be rotated.

Root keys can be rotated manually or on a schedule set by the owner of the key. The option you choose depends on your preferences and the needs of your use case.
Authorize access with IAM Grant access to other users for Code Engine by using Cloud Identity and Access Management (IAM). IBM Cloud IAM provides secure authentication with the IBM Cloud platform, Code Engine, and all the resources in your account. Setting up proper user roles and permissions is key to limit who can access your resources. See [Managing user access](https://cloud.ibm.com/docs/codeengine?topic=codeengine-iam). 
 Disable external endpoints Deploy your application with a disabled external endpoint that is not exposed to external traffic by using the --visibility=private or visibility=project option. See [Options for visibility for a Code Engine application](https://cloud.ibm.com/docs/codeengine?topic=codeengine-application-workloadsoptionsvisibility). 
 Store images in private image registries Set up a private image registry, such as the one provided by IBM Cloud Container Registry, to control access to the registry and the images that can be deployed in Code Engine. Scan your images automatically with the [IBM Cloud Container Registry Vulnerability Advisor](https://cloud.ibm.com/docs/Registry?topic=Registry-va_index). You can also add access to your own custom private registry. See [Accessing container registries](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registry). 
 Build code from a private repository Store your source code in a private repository and then build to IBM Cloud Container Registry. See [Accessing private code repositories](https://cloud.ibm.com/docs/codeengine?topic=codeengine-code-repositories). 
 Use secrets to store sensitive information You can store information, such as passwords and SSH keys in a secret. For more information, see [Working with secrets](https://cloud.ibm.com/docs/codeengine?topic=codeengine-secret). 





 Supported TLS versions and cipher suites 

The Code Engine API and application endpoints support transport layer security (TLS) 1.2 (or higher) and the following cipher suites.



 TLS cipher suites
The create_ova command is provided as a system command on VIOS release 3.1.2.0, or later.

To see the contents of the RPM package, enter the rpm command as shown in the following example:

 rpm -qlp /tmp/create_ova-1.0-2.aix7.2.ppc.rpm
/opt/freeware/doc/create_ova-1.0
/opt/freeware/doc/create_ova-1.0/create_ova.pdf
/opt/freeware/licenses/create_ova-1.0
/opt/freeware/licenses/create_ova-1.0/LICENSE
/opt/ibm/sysmgt/cloudrdy
/opt/ibm/sysmgt/cloudrdy/EXTRAS/pv-1.6.0-1.aix6.1.ppc.rpm
/opt/ibm/sysmgt/cloudrdy/LICENSE
/opt/ibm/sysmgt/cloudrdy/bin/cloud_setup
/opt/ibm/sysmgt/cloudrdy/bin/create_ova
/opt/ibm/sysmgt/cloudrdy/bin/print_ovf
/opt/ibm/sysmgt/cloudrdy/doc/create_ova.pdf
/usr/share/man/man1/create_ova.1

Once you obtain the correct disk name (through virtual adapter mapping), you can create a virtual disk image and package the contents into an OVA. After the RPM is installed, the man page and the executable (create_ova) are available in the normal paths. Note that a link is made to /usr/bin/create_ova), so there is no need to set the user path. If you decide to perform an uninstall, any links, files, or directories that are tracked by the RPM for this package are removed. The following example contains a list of sample commands and output:

You can upload the ova.gz file into your Cloud Object storage account.
ibmcloud cdb deployment-connections example-deployment -u <newusername> --all [--endpoint-type <endpoint type>]

If you don't specify a user, the deployment-connections commands return information for the admin user by default. If you don't specify an endpoint type, the connection string returns the public endpoint by default. If your deployment has only a private endpoint, you must specify --endpoint-type private or the commands return an error. The user and endpoint type is not enforced. You can use any user on your deployment with either endpoint (if both exist on your deployment).

To use the ibmcloud cdb CLI commands, you must [install the Cloud Databases plug-in](https://cloud.ibm.com/docs/databases-for-mongodb?topic=databases-cli-plugin-cdb-referenceinstalling-the-cloud-databases-cli-plug-in).

API To retrieve user's connection strings from the API, use the [/users/{userid}/connections](https://cloud.ibm.com/apidocs/cloud-databases-apidiscover-connection-information-for-a-deployment-f-e81026) endpoint. You must specify in the path the user endpoint (public or private) in the returned connection strings. The user and endpoint type is not enforced. You can use any user on your deployment with either endpoint (if both exist on your deployment).

curl -X GET -H "Authorization: Bearer $APIKEY" 'https://api.{region}.databases.cloud.ibm.com/v4/ibm/deployments/{id}/users/{userid}/connections/{endpoint_type}'



 Connection String Breakdown 



 The MySQL Section 

The "mysql" section contains information that is suited to applications that make connections to mysql.



Table 1. mysql/URI connection information

 Field Name Index Description 

 Type Type of connection - for MySQL, it is "URI"
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. For example, you can set the NODE_ENV environment variable to production by putting a node_env.sh file that contains the following content under the /.profile.d directory:

export NODE_ENV=production;





 Preventing files and directories from being uploaded 

When you use the ibmcloud cf command line interface to deploy an app, you can save upload time by skipping certain files and directories that IBM Cloud can obtain elsewhere. To prevent these files and directories from being uploaded to IBM Cloud, you can create a .cfignore file at the root directory of your app.

The .cfignore file must be in UTF-8 format.

The .cfignore file contains the names of files and directories that you want to ignore, one name per line. You can use an asterisk (*) as a wildcard character. When you specify a directory, all files and subdirectories under that directory are also ignored. For example, the following content in the .cfignore file indicates that all the .swp files and all files and subdirectories under the tmp/ directory won't be uploaded to IBM Cloud.

.swp
tmp/
"resources": [
{
"type": "application/vnd.ibm.kms.key+json",
"name": "my-standard-key",
"description": "my-standard-key",
"extractable": true
}
]
}'
Show more





 JSON response from ibmcloud API 

{
"metadata": {
"collectionType": "application/vnd.ibm.kms.key+json",
"collectionTotal": 1
},
"resources": [
{
"type": "application/vnd.ibm.kms.key+json",
"id": "60d72058-ec53-4d77-b7ef-ba56443e76d5",
"name": "my-standard-key",
"description": "my-standard-key",
"state": 1,
"extractable": true,
"crn":"crn:v1:bluemix:public:kms:us-south:a/819bdf4436ef4c198fdf4f0b81d53116:87fa68d0-fa10-47d0-a201-603949808530:key:60d72058-ec53-4d77-b7ef-ba56443e76d5",
"imported": false,
"deleted": false
}
]
}









 13 - Missing body in request 



 Message 

Missing body in request

Reason code: NO_BODY_ERR





 HTTP status code 

400 - Bad Request

The HTTP 400 Bad Request response status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).

The client should not repeat this request without modification.





 Context
Depending on which Git tool integration you select, you can [configure the the GitHub tool integration](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-github) or you can configure the [Git Repos and Issue Tracking tool integration](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-grit).



To try a tutorial to create a custom toolchain, see [Create a custom toolchain](https://www.ibm.com/cloud/architecture/tutorials/create-a-custom-toolchain).





 Adding the Git tool integration to an existing toolchain with the API 

You can add a Git tool integration to any existing toolchain with the API.



1. [Obtain an IAM bearer token](https://cloud.ibm.com/apidocs/resource-controllerauthentication). Alternatively, if you are using an SDK, [obtain an IAM API key](https://cloud.ibm.com/iam/apikeys) and set the client options by using environment variables.

export CD_TOOLCHAIN_AUTH_TYPE=iam && export CD_TOOLCHAIN_APIKEY={iam_api_key} && export CD_TOOLCHAIN_URL=https://api.{region}.devops.cloud.ibm.com/toolchain/v2
2. [Determine the region and ID of the toolchain](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-toolchains_getting_started&interface=apiviewing-toolchain-api) that you want to add the Git tool integration to.
3. Add the Git tool integration to the toolchain. The following example shows how to add a Git tool integration that links to an existing repo on github.com. You can also add a Git tool integration with instructions to create, fork, or clone a new repo.
ibmcloud cdb deployment-connections example-deployment -u <newusername> --all [--endpoint-type <endpoint type>]

If you don't specify a user, the deployment-connections commands return information for the admin user by default. If you don't specify an endpoint type, the connection string returns the public endpoint by default. If your deployment has only a private endpoint, you must specify --endpoint-type private or the commands return an error. The user and endpoint type is not enforced. You can use any user on your deployment with either endpoint (if both exist on your deployment).

To use the ibmcloud cdb CLI commands, you must [install the Cloud Databases plug-in](https://cloud.ibm.com/docs/databases-for-mongodb?topic=databases-cli-plugin-cdb-referenceinstalling-the-cloud-databases-cli-plug-in).





 Getting Connection Strings from the API 

To retrieve user's connection strings from the API, use the [/users/{userid}/connections](https://cloud.ibm.com/apidocs/cloud-databases-apidiscover-connection-information-for-a-deployment-f-e81026) endpoint. You must specify in the path which user and which type of endpoint (public or private) is used in the returned connection strings. The user and endpoint type is not enforced. You can use any user on your deployment with either endpoint (if both exist on your deployment).

curl -X GET -H "Authorization: Bearer $APIKEY" 'https://api.{region}.databases.cloud.ibm.com/v4/ibm/deployments/{id}/users/{userid}/connections/{endpoint_type}'





 Connection String Breakdown 



 The Redis Section 

The "Redis" section contains information that is suited for your applications that make connections to Redis.



Table 1. redis/URI connection information

 Field Name Index Description 

 Type Type of connection - for Redis, it is "URI"
For more information about which multi-zone regions are designated as Financial Services Validated, see [Deploy your IBM Cloud resources only to approved multizone regions](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-best-practicesbest-practices-financial-services-regions).





 Adding a tool integration by using the console 

You can add tool integrations to your toolchain by using the console.



1. From the IBM Cloud console, click the menu icon ![hamburger icon](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/icon_hamburger.svg), and select DevOps.
2. On the Toolchains page, click a toolchain to open its Overview page. Alternatively, on the App details page in your app, click the toolchain name.
3. To see a list of tool integrations to add, click Add tool.
4. Click a tool integration that you want to add.
5. Enter any required information to configure the tool integration.
6. Click Create Integration to add the tool integration to your toolchain.







 Adding a tool integration with the API 

You can add tool integrations to your toolchain with the API.



1. [Obtain an IAM bearer token](https://cloud.ibm.com/apidocs/toolchainauthentication). Alternatively, if you are using an SDK, [obtain an IAM API key](https://cloud.ibm.com/iam/apikeys) and set the client options by using environment variables.

export CD_TOOLCHAIN_AUTH_TYPE=iam && export CD_TOOLCHAIN_APIKEY={iam_api_key} && export CD_TOOLCHAIN_URL={base_url}
2.
To retrieve all the connection information for a deployment named "example-deployment", use the following command.

ibmcloud cdb deployment-connections example-deployment -u <newusername> --all [--endpoint-type <endpoint type>]

If you don't specify a user, the deployment-connections commands return information for the admin user by default. If you don't specify an endpoint type, the connection string returns the public endpoint by default. If your deployment has only a private endpoint, you must specify --endpoint-type private or the commands return an error. The user and endpoint type is not enforced. You can use any user on your deployment with either endpoint (if both exist on your deployment).

To use the ibmcloud cdb CLI commands, you must [install the Cloud Databases plug-in](https://cloud.ibm.com/docs/databases-for-mongodb?topic=databases-cli-plugin-cdb-referenceinstalling-the-cloud-databases-cli-plug-in).





 Getting Connection Strings in the API 

To retrieve user's connection strings from the API, use the [/users/{userid}/connections](https://cloud.ibm.com/apidocs/cloud-databases-apidiscover-connection-information-for-a-deployment-f-e81026) endpoint. You must specify in the path which user and which type of endpoint (public or private) is to be used in the returned connection strings. The user and endpoint type is not enforced. You can use any user on your deployment with either endpoint (if both exist on your deployment).

curl -X GET -H "Authorization: Bearer $APIKEY" 'https://api.{region}.databases.cloud.ibm.com/v4/ibm/deployments/{id}/users/{userid}/connections/{endpoint_type}'





 Connection String Breakdown 



 The PostgreSQL Section 

The "postgres" section contains information that is suited to applications that make connections to PostgreSQL.



Table 1.
When creating a volume, the capacity value specified in the request must be a positive number between 10 GB and 2000 GB. See the [IBM Cloud Block Storage for VPC](https://cloud.ibm.com/docs/vpc-on-classic-block-storage?topic=vpc-on-classic-block-storage-block-storage-about) documentation for supported volume capacity values.





 volume_crn_account_id_mismatch 

Message: The CRN specified in the request does not belong to current user's account.

The Key Protect root key CRN does not match your IAM authorization account ID. Specify a different Key Protect root key CRN for your IAM account. See the [Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-getting-started-tutorial) documentation for more information.





 volume_crn_cname_mismatch 

Message: The CRN specified in the request cannot be used for the current environment.

The CRN that you specified in the request cannot be used in the current environment. Provide a CRN applicable to your environment.





 volume_encryption_key_crn_invalid 

Message: The volume encryption key CRN specified in the request is not valid.

The Key Protect CRN you provided is not valid. Obtain the CRN of the root key in the Cloud Identity and Access Management service. For more information, see the [IBM Cloud Block Storage for VPC](https://cloud.ibm.com/docs/vpc-on-classic-block-storage?topic=vpc-on-classic-block-storage-block-storage-encryption) documentation.





 volume_encryption_key_not_active 

Message: The volume encryption key specified in the request is not active.

Activate the exising key or provide a new key. If you cannot activate your own key, contact your system administrator or [customer support](https://cloud.ibm.com/docs/vpc-on-classic?topic=vpc-on-classic-getting-help-and-support).





 volume_encryption_key_not_authorized
To retrieve all the connection information for a deployment named "example-deployment", use the following command.

ibmcloud cdb deployment-connections example-deployment -u <newusername> --all [--endpoint-type <endpoint type>]

If you don't specify a user, the deployment-connections commands return information for the admin user by default. If you don't specify an endpoint type, the connection string returns the public endpoint by default. If your deployment has only a private endpoint, you must specify --endpoint-type private or the commands return an error. The user and endpoint type is not enforced. You can use any user on your deployment with either endpoint (if both exist on your deployment).

To use the ibmcloud cdb CLI commands, you must [install the Cloud Databases plug-in](https://cloud.ibm.com/docs/databases-for-mongodb?topic=databases-cli-plugin-cdb-referenceinstalling-the-cloud-databases-cli-plug-in).





 Getting Connection Strings with the API 

To retrieve user's connection strings from the API, use the [/users/{userid}/connections](https://cloud.ibm.com/apidocs/cloud-databases-apidiscover-connection-information-for-a-deployment-f-e81026) endpoint. You must specify in the path which user and which type of endpoint (public or private) should be used in the returned connection strings. The user and endpoint type is not enforced. You can use any user on your deployment with either endpoint (if both exist on your deployment).

curl -X GET -H "Authorization: Bearer $APIKEY" 'https://api.{region}.databases.cloud.ibm.com/v4/ibm/deployments/{id}/users/{userid}/connections/{endpoint_type}'





 More Users and Connection Strings 

Access to your Databases for Elasticsearch deployment is not limited to the admin user.
Getting started with Data Transfer Service 

You can use IBM Cloud® Data Transfer Service to send a USB 2.0 or USB 3.0 compatible device to an IBM Cloud data center. The device is connected directly to your network so you can remotely control the data transfer. The device is housed in a dedicated rack that is located in your data center and mounted as an iSCSI target. The data transfer service is ideal when you need to transfer large amounts of data without using IBM Cloud Private network. It's a service that is offered at no charge to all IBM Cloud customers.



 Accessing the Data Transfer Service screen 

You can manage data transfer requests by using the IBM Cloud console.



1. Log in to the [IBM Cloud console](https://cloud.ibm.com/login) with your unique credentials.
2. Select Storage > Data Migration > Data Transfer from the navigation bar to access the Data Transfer Service screen.

The Data Transfer screen is available only to the principal user of the account. To access this screen, contact the account owner.







 Submitting a data transfer request 

Data transfer requests are designed to inform the appropriate parties in our data centers to expect a shipment from a client. Requests are submitted through the [IBM Cloud console](https://cloud.ibm.com/login).

When you create a request, keep the following guidelines in mind.



* Ensure that the device that you want to send meets all [hardware requirements](https://cloud.ibm.com/docs/DataTransferService?topic=DataTransferService-abouthardware-requirements).
* Only one device can be associated with one request. If you want to send multiple devices, you must create a request for each device.
* If the device is to be returned, provide a pre-paid shipping label, and export documents as needed in the package so that the device can be returned after the transfer period.
* If you're shipping the device internationally, you're responsible to obtain all licensing, shipping, and customs clearance for the Device. Your responsibilities include paying any duties, taxes, and shipping costs to and from (if applicable) the IBM Cloud data center.
For more information about portable IP addresses, see [About subnets and IPs](https://cloud.ibm.com/docs/subnets?topic=subnets-about-subnets-and-ips).
4. Click Continue after you select the number of portable private IP addresses.
5. Select the VLAN where the portable private IP addresses to be routed and click Continue.
6. Complete the required contact information and click Place Order.
7. Repeat the ordering process to obtain the second required portable private network.
8. Click Network > IP Management > Subnets from the IBM Cloud infrastructure customer portal page to view your portable private networks and IP addresses after they are allocated. It is recommended to track your IP address assignments. Use the Notes section of the Subnets page for each IP address to reflect the machine to which it is assigned.







 Configuring vSphere 

You need to configure vSphere to reflect the addition of the portable private networks and make sure that they are logically segregated.



1. Go to your vSphere environment and create a virtual machine port group to reflect the addition of one of the portable IP blocks (two in total).



Virtual machine port group is labeled Share Network. One portable IP block is used for VMs that are placed on the default (primary) virtual machine port group. The other is used for data transfer between an AltaVault appliance and an exported Common Internet File System (CIFS)/Server Message Block (SMB) mount point.









 AltaVault Cloud Storage Gateway 

You can use AltaVault to integrate your on-premises environment with the cloud without the need to write scripts or applications by using REST APIs for IBM Cloud Object Storage. AltaVault exposes a CIFS/SMB or Network File System (NFS) mount point on the front end and securely connects to the IBM Cloud Object Storage interface on the back end. You can then mount or point to the mount points and copy data into and or recovering/restoring environments from the cloud securely.



 Deploying AltaVault in a Disaster Recovery Configuration 

Follow these steps to deploy AltaVault as a disaster recovery solution with IBM Cloud Object Storage.



 Before you get started