vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Identifying inactive identities 

Identities are considered inactive when they haven't logged in or been in use in 30 days. You can review which users, service IDs, trusted profiles, and API keys in your account are inactive. You might want to remove inactive identities if they are no longer needed. Removing access for inactive identities can reduce the risk of unauthorized access to your IBM Cloud resources and help you manage access more efficiently. To manage inactive identities, you must be assigned the Administrator role on the IAM Identity Service.

When you delete an identity from the table, for example a user, and click Update report, it takes a few minutes for a new report to exclude the deleted user.



 Managing inactive identities in the console 

To view inactive identities in the console, complete the following steps:



1. In the IBM Cloud console, click Manage > Access (IAM), and select Inactive identities.
2. Click Update report to view the most recent report of the inactive identities in your account.

Only the most recent report is available. Reports older than a day are deleted when generating a new report.
3. Select a tab to review a list of inactive identities.
4. To delete inactive identities that are no longer in use, click the Actions icon ![Actions icon](https://cloud.ibm.com/docs-content/v1/content/4d8c6eec891cff72b666dc24bd3211810c77fb42/icons/action-menu-icon.svg) > Remove.



Before you delete an identity, confirm that they are inactive for at least 30 days.

To learn more about the implications of removing or deleting identities in your account, review the following documentation:



* [Removing users from an account](https://cloud.ibm.com/docs/account?topic=account-remove&interface=ui)
* [Deleting service IDs](https://cloud.ibm.com/docs/account?topic=account-serviceids&interface=uidelete_serviceid)
"maxAllowedRetrievals": 2
}'



 JSON response 

{
"maxAllowedRetrievals": 2,
"creationDate": "2020-08-18T19:54:57Z",
"expirationDate": "2020-08-18T19:59:57Z",
"remainingRetrievals":2
}

 retrieve the import token after it expires
$ curl -X GET "https://us-south.kms.cloud.ibm.com/api/v2/import_token" -H "authorization: Bearer $ACCESS_TOKEN" -H "bluemix-instance: $KP_INSTANCE_ID" -H "content-type: application/vnd.ibm.kms.import_token+json"





 JSON response 

{
"metadata": {
"collectionType": "application/vnd.ibm.kms.error+json",
"collectionTotal": 1
},
"resources": [
{
"errorMsg": "Conflict: Import Token could not be retrieved. Please see reasons for more details.",
"reasons":
{
"code": "IMPORT_TOKEN_EXPIRED_ERR",
"message": "The import token has expired.",
"status": 409,
"moreInfo": "https://cloud.ibm.com/apidocs/key-protect"
}
]
}
]
}







 Example 2 

Using the CLI, create an import token, allow it to expire, then attempt to retrieve it.

 create an import token that expires in 5 minutes (300 seconds) and allows 2 retrievals
$ ibmcloud kp import-token create -e 300 -m 2

Created Expires Max Retrievals Remaining Retrievals
2020-08-18 19:39:06 +0000 UTC 2020-08-18 19:44:06 +0000 UTC 2 2

 sleep 300 seconds, which allows the import token to expire
(Current fees for post-expiration renewal can be found here: [https://www.ibm.com/cloud/dns](https://www.ibm.com/cloud/dns)). If You signed up for any other services in conjunction with Your domain registration, these services may be automatically renewed when Your domain registration is renewed, and You may incur additional renewal fees unless You cancel in advance. IBM Cloud sends domain renewal reminders via email to the registered owner contact in accordance with the ICANN Expired Registration Recovery Policy. The notices are sent as follows:



* IBM Cloud will send a first renewal reminder notice approximately 30 days before the domain registration expires, and a second notice approximately 1 week before expiration. Both of those notices will be sent to the email address on file for the owner of the domain registration.
* IBM Cloud will send ONE more renewal reminder notice by email to the owner of the domain registration 3 days after expiration.



If You fail to renew Your domain name, You agree that IBM Cloud may choose to renew it on Your behalf, in which case You will have a grace period during which You may reimburse IBM Cloud for the renewal and keep Your domain name. The renewal grace period is currently 30 days but is subject to change under the terms of Section 2 of this Agreement.

If You do not reimburse IBM Cloud for the renewal during the renewal grace period, Your domain name will be placed on hold and flagged for deletion after which You will have a 30-day period during which You may pay IBM Cloud a redemption fee and redeem Your domain name. The current redemption fee, which is subject to change, can be found at [https://www.ibm.com/cloud/dns](https://www.ibm.com/cloud/dns). If You do not redeem Your domain name prior to the end of the redemption grace period IBM Cloud may, at its sole discretion, delete Your domain name or transfer it to another registrant on Your behalf.





 Term of Agreement; Modifications 

This Agreement continues in full force and effect as long as You have any domain name registered through IBM Cloud.
except ClientError as be:
print("CLIENT ERROR: {0}n".format(be))
except Exception as e:
print("Unable to get bucket protection config: {0}".format(e))





 Upload a protected object 

Objects in protected buckets that are no longer under retention (retention period has expired and the object does not have any legal holds), when overwritten, will again come under retention. The new retention period can be provided as part of the object overwrite request or the default retention time of the bucket will be given to the object.



 Value Type Description 

 Retention-Period Non-negative integer (seconds) Retention period to store on the object in seconds. The object can be neither overwritten nor deleted until the amount of time that is specified in the retention period has elapsed. If this field and Retention-Expiration-Date are specified a 400 error is returned. If neither is specified the bucket's DefaultRetention period will be used. Zero (0) is a legal value assuming the bucket's minimum retention period is also 0. 
 Retention-expiration-date Date (ISO 8601 Format) Date on which it will be legal to delete or modify the object. You can only specify this or the Retention-Period header. If both are specified a 400 error will be returned. If neither is specified the bucket's DefaultRetention period will be used. 
 Retention-legal-hold-id string A single legal hold to apply to the object. A legal hold is a Y character long string. The object cannot be overwritten or deleted until all legal holds associated with the object are removed. 



def put_object_add_legal_hold(bucket_name, object_name, file_text, legal_hold_id):
print("Add legal hold {0} to {1} in bucket {2} with a putObject operation.n".format(legal_hold_id, object_name, bucket_name))

cos.put_object(
Bucket=bucket_name,
Key=object_name,
Body=file_text,
RetentionLegalHoldId=legal_hold_id)
Token lifetime begins again each time a user signs in. For example, you set your refresh token lifetime to 10 days. An access token and a refresh token are created when the user signs in for the first time. If the user returns to your app 3 days later, they wouldn't need to sign in again. But, if the user waited 12 days after their initial sign-in, and then returned to your app, they would need to sign in again. For more information about tokens, check out [Understanding tokens](https://cloud.ibm.com/docs/appid?topic=appid-tokenstokens).

When you set token expiration, the values apply to all the providers that you make available. If you want to customize your tokens further, try calling the API to [map custom claims](https://cloud.ibm.com/docs/appid?topic=appid-customizing-tokens) so that the user information is available at run time. When you work with the API, the customization times are configured differently.



1. Go to the Manage Authentication > Authentication settings tab of the service dashboard.
2. In the Sign-in Expiration tab, toggle refresh token to Enabled.
3. For each token type, add a value for each token type as described in the following table.



Table 3. Token types and customization options

 Token type Description Default Options 

 [Access](https://cloud.ibm.com/docs/appid?topic=appid-tokensaccess) The length of time for which access tokens are valid. The smaller the value, the more protection that you have in cases of token theft. 60 minutes Any value in the range 5 - 1440 
 [Refresh](https://cloud.ibm.com/docs/appid?topic=appid-tokensrefresh) The length of time for which refresh tokens are valid. The smaller the number, the more frequently a user must sign themselves in. 30 days Any value in the range 1 - 90
Why did the creation of an alternative account owner trusted profile fail? 

  What’s happening 

A trusted profile is created without the classic infrastructure permissions that an alternative account owner is normally assigned. You receive an error after you create the trusted profile.

> An error occured while trying to apply the admin flag for this account. An error occurred. Try again later. Only 1 TrustedProfile per account may be set as the alternate master user.

  Why it’s happening 

You might already have an alternative account owner trusted profile in the account. You can set only one trusted profile as the alternative account owner.

  How to fix it 

Delete the trusted profile that has an error. Check the account for an existing trusted profile with alternative account owner access, which is indicated by an alt account owner tag. If no such profile exists, try creating the trusted profile again.

For more information, see [Setting an alternative account owner](https://cloud.ibm.com/docs/account?topic=account-classic-infra-owner).
<ID>delete-after-3-days</ID>
<Filter />
<Status>Enabled</Status>
<AbortIncompleteMultipartUpload>
<DaysAfterInitiation>3</DaysAfterInitiation>
</AbortIncompleteMultipartUpload>
</Rule>
</LifecycleConfiguration>

You can also combine rules. This configuration cancels inactive uploads after 5 days, archives any objects 90 days after creation, and deletes any objects with the prefix foo/ after 180 days .

<LifecycleConfiguration>
<Rule>
<ID>archive-first</ID>
<Filter />
<Status>Enabled</Status>
<Transition>
<Days>90</Days>
<StorageClass>GLACIER</StorageClass>
</Transition>
</Rule>
<Rule>
<ID>then-delete</ID>
<Filter>
<Prefix>foo/</Prefix>
</Filter>
<Status>Enabled</Status>
<Expiration>
<Days>180</Days>
</Expiration>
</Rule>
<Rule>
<ID>delete-after-3-days</ID>
<Status>Enabled</Status>
<AbortIncompleteMultipartUpload>
<DaysAfterInitiation>3</DaysAfterInitiation>
</AbortIncompleteMultipartUpload>
</Rule>
</LifecycleConfiguration>
Show more





 Using the API and SDKs 

You can programmatically manage lifecycle rules by using the REST API or the IBM COS SDKs.

REST API reference

This implementation of the PUT operation uses the lifecycle query parameter to set lifecycle settings for the bucket. This operation allows for a single lifecycle policy definition for a bucket.
Sign in attempts per account Yes 200 per second All sign-in attempts for the instance are blocked for 1 minute. 
 Sign up attempts per account Yes 200 per second All sign-up attempts for the instance are blocked for 1 minute. 
 Email sending request No 10 emails in 5 minutes per user Email requests for the user are blocked for 30 minutes. 
 SMS sending request No 10 SMS in 5 minutes per user SMS requests for the user are blocked for 30 minutes. 
 MFA code characters No 6 numeric characters The code automatically has 6 characters that must be input by the user. 
 MFA code expiration No 15 minutes If a user does not validate their code within 15 minutes, they can request that another code is sent as long as the authentication session is not expired. Within the authentication session, the code can be sent multiple times. Once the authentication session expires, the user must repeat the login process from the beginning. 



For more information, see the [rate limit management API](https://us-south.appid.cloud.ibm.com/swagger-ui//Management%20API%20-%20Config/mgmt.updateRateLimitConfig).





 Ingress annotation 

Be sure to review the following limitations before you configure your annotation.



* Refresh tokens are not currently supported.
* IBM Cloud® Kubernetes Service supports one Ingress per namespace. If you already have one, you can update the existing Ingress configuration or use a different namespace.
* The annotation does not work behind a proxy.







 Extensions 



* The response from your pre-mfa extension point must not exceed 10 KB. If it does, the request is canceled and the user is required to complete MFA.
* If it takes App ID longer than 5 seconds to establish a connection to your pre-mfa extension point, or if the request takes longer than 7 seconds to complete, the request is canceled and the user is required to complete MFA.
expiration_time The time in seconds from the creation of an import token that determines how long it remains valid. The minimum value is 300 seconds (5 minutes), and the maximum value is 86400 (24 hours). The default value is 600 (10 minutes). 
 use_count The number of times that an import token can be retrieved within the expiration time before it is no longer accessible. The default value is 1. 



A successful POST api/v2/import_token request creates an import token for your service instance. The response body contains the metadata that is associated with your import token, such as the creation date and policy details. The following snippet shows example output.

{
"creationDate": "2019-04-08T16:58:29Z",
"expirationDate": "2019-04-08T17:18:29Z",
"maxAllowedRetrievals": 1,
"remainingRetrievals": 1
}







 Creating an import token with the CLI 

Complete the following steps to create an import token using the Key Protect CLI, which is integrated in Hyper Protect Crypto Services:



1. [Set up the Key Protect CLI](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-set-up-cli).
2. Create an import token with the following command:

ibmcloud kp import-token create

You can find more parameters for this command in the [Key Protect CLI reference](https://cloud.ibm.com/docs/key-protect?topic=key-protect-cli-plugin-key-protect-cli-referencekp-import-token-create).







 Retrieving an import token with the API 

Retrieve the import token that's associated with your Hyper Protect Crypto Services service instance by making a GET call to the following endpoint.

https://api.<region>.hs-crypto.cloud.ibm.com:<port>/api/v2/import_token



1.
Secret deletion blocked com.ibm.cloud.secrets-manager.secret_deletion_blocked An event is sent when a secret is unable to be deleted because it is locked. Low 
 Secret revocation blocked com.ibm.cloud.secrets-manager.secret_revocation_blocked An event is sent when a secret is unable to be revoked because it is locked. Low 
 Secret rotation blocked com.ibm.cloud.secrets-manager.secret_rotation_blocked An event is sent when a secret is unable to be rotated because it is locked. Low 
 Secret expiration blocked com.ibm.cloud.secrets-manager.secret_expiration_blocked An event is sent when a secret is unable to expire because it is locked. High 
 Secret version data deleted com.ibm.cloud.secrets-manager.secret_version_data_deleted An event is sent when a secret version's data is deleted. Low 
 Test event com.ibm.cloud.secrets-manager.test_event An event is sent when a test notification is forwarded to Event Notifications. Low 



secret_about_to_expire events are sent only once, on the specified day. This means that if you specify that a secret is to expire in 10 days, you receive a single notification when the secret has 10 days left. You do not receive a notification at any other time, for example, when the secret has 9 days left.



 Supported secret types 

The following table lists the Secrets Manager events that can be generated based on secret types that are supported in the service.



Table 2. Actions that generate events based on secret type

 Event name Event type Occurrence Arbitrary IAM credentials Key-value User credentials Imported certificates Private certificates Public certificates 

 Secret created com.ibm.cloud.secrets-manager.secret_created One time ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/991f60ddbe3ab0a9aa69481a07a0a73b359fa329/icons/checkmark-icon.svg) 
 Secret creation failed com.ibm.cloud.secrets-manager.secret_creation_failed One time !
* CIS does not show private content or handle form submission (POSTs) if your server is down. Visitors are shown an error on checkout page or items require a login to view.
* To trigger Serve Stale Content, your web server must be returning a standard HTTP Error code of 502 or 504 timeout. Serve Stale Content also works when we encounter issues contacting your origin (Errors 521 & 523), timeouts (522 & 524), SSL errors (525 & 526) or an unknown error (520). Serve Stale Content is not triggered for other HTTP response codes, such as 404s, 500, 503, database connection errors, internal server error, or empty replies from server.
* Serve Stale Content does not work if a "Cache Everything" page rule is enabled with the "Edge Cache Expire TTL" lower than the caching frequency, because the "Edge Cache Expire TTL" causes the Serve Stale Content cache to be purged in the corresponding interval.









 Origin Cache Control 

You can use the Origin Cache Control Page Rule setting to determine what content is cached from your origin and how often the content is updated, which has an effect on reliability and on performance. By default, if no settings are changed and no headers that prevent caching are sent from your origin server, CIS caches all static content with certain extensions. These types of content include images, CSS, and JavaScript. This caching is primarily for performance reasons.

To set up Origin Cache Control use page rules to turn on specific headers that give the wanted behavior with respect to each resource of your content. To understand how to use Origin Cache Control, some more general explanation of page rules and overall caching behavior for CIS is required to provide context, which is covered in the next several sections. Three methods exist that you can use to control caching in general, and Origin Cache Control is the second one.

Setting Origin Cache Control invokes caching rules that seek to adhere closely to internet best practices and RFCs, primarily with respect to revalidation. For example, the CIS default behavior with max-age=0 is not to cache at all, whereas setting Origin Cache Control caches, but it always revalidates.



 Setting up Origin Cache Control 

To enable Origin Cache Control, follow these steps:
After these certificates are automatically renewed, there is no further action that needs to be taken.

If the CA is offline, unreachable, or the CA TLS certificate has expired, the certificates cannot be automatically renewed. The peer or ordering node displays a warning message indicating that certificate expiration is approaching or has occurred and you need to take action.

Peer and ordering node enrollment certificates can be renewed from the console, by opening the node tile and clicking the Settings icon. Click Update certificates to renew either the enrollment or TLS certificate. See detailed instructions for the [peer](https://cloud.ibm.com/docs/blockchain?topic=blockchain-cert-mgmtcert-mgmt-enroll-tls-peer) and [ordering node](https://cloud.ibm.com/docs/blockchain?topic=blockchain-cert-mgmtcert-mgmt-enroll-tls-ordering-node) enrollment and TLS certificates. Note that when a certificate is updated, the node is restarted.





 Admin certificates 

Organization MSP admin certificates cannot be automatically renewed. Instead, you need to follow the manual certificate renewal process, included in this topic, to update these certificates. If you have a large number of channels on your network, Ansible playbooks, also described later in this topic, are available to update admin certificates that have not yet expired across the channels on your network in a bulk action.







 Certificate types and actions 

When certificates expire, nodes can no longer process transactions and your applications can no longer interact with your network. Therefore, before a certificate expires, you need to enroll the identity again to generate a new certificate, a process referred to as "certificate renewal".

The following tables describe the types of certificates that you need to manage, how to view their expiration date, and how to maintain them.



 CA TLS certificate 



Table 1. How to manage the CA certificates

 Certificate Description How generated Default expiration How to view expiration How to renew Impact if expires What to do if expired 

 CA TLS certificate Used to trust the CA server. Contains the public key that must be shared with all members in the organization that want to transact with any node in the organization.
The access is permanently forbidden and tied to the application logic, such as insufficient rights to a resource.





 Context 

This error message occurs when an instance policy prevents access to a resource. For example, if the request originated from a public IP address and the instance policy prohibits access from a public IP address, then you will receive this error message.







 20 - Signature is invalid 



 Message 

Signature is invalid

Reason code: INVALID_SIG_EXP_ERR





 HTTP status code 

422 - Unprocessable Entity

The HTTP 422 Unprocessable Entity response status code indicates that the server understands the content type of the request entity, and the syntax of the request entity is correct, but it was unable to process the contained instructions.

The client should not repeat this request without modification.





 Context 

An error occurred when a key was rewrapped.

If you get this error please contact [IBM support](https://cloud.ibm.com/unifiedsupport/supportcenter)







 21 - The action could not be performed on... 



 Message 

The action could not be performed on the key because the key is expired

Reason code: KEY_EXPIRED_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 

This error occurs when restoring a deleted key after the key has expired.



 Example 

A key restore request fails because the key is delete and the key has expired.

The following steps will create this error.



1. Create a key material (payload) and an expiration date
2. Create a root key using the key material and the expiration date
3. Capture the key id
4. Allow the expiration date to pass
5. Delete the key
6. Restore the key, which fails because you cannot restore a deleted key after the expiration date



 step 1 - create a key material (payload) and an expiration date