vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Data can be labeled by using the Discovery product user interface, or by using the API. For more information about labeling with the API, see [Labeling data](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-information-securitylabeling).

To label data with the product user interface:



1. Open the Projects page by selecting My Projects.
2. Select Data usage and GDPR.
3. Choose the GDPR data label tab.
4. Set the Label data with customer ID toggle to on. The Customer ID field appears.
5. Enter a unique ID for the customer in the Customer ID field. Do not include personal data in a Customer ID.
6. Click Save ID.



After the Customer ID (customer_id) field is set, all data that is uploaded during the current browser session is labeled with the specified Customer ID. (You cannot label data that is added by crawling external data sources.)

Adding a Customer ID labels the documents, notices, dictionaries, and training data within that URL domain from that point forward, including each instance under that domain. Any actions, including document uploads, that occurred in the Discovery product user interface before the Customer ID field was added are not labeled.

If you switch domains or browsers, empty the browser cache, or start an incognito session after you specify your Customer ID by using the Discovery product user interface, the Customer ID is not retained, and your data is not labeled. If you must switch domains or browsers, after the switch, open the GDPR data label tab, enter the Customer ID again, and then click Save ID.

If an existing Customer ID needs to be changed:



1. Delete the data associated with that Customer ID. For instructions, see [Deleting labeled data](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-information-securitydeletingdata).
2. Follow the instructions to label data with the Discovery product user interface, or by using the API.
3. Upload or crawl the data.









 Deleting labeled data
To customize which parameters are required for users to specify during the installation and which ones are hidden from users, select a parameter and click Edit. Click the checkboxes to configure the values and click Save.







 Step 4: Edit output value descriptions 

You can improve the descriptions for your Terraform template's output values to help users better understand the purpose of the parameters. The description of any output value that you include in your template can be updated.

To add output values, you need to include them in a new imported version of your Terraform template.

Complete the following steps to edit the product's output value descriptions:



1. Click Configure version > Next.
2. From the Output value descriptions section, provide a new description for the parameter that you want to update.
3. Click Next.







 Step 5: Define IAM access 

After you configure your deployment values, you can add the service access and platform access roles that are required to install your product from the IBM catalog.

Use the following steps to define your product's access:



1. Click Configure version > Next > Next.
2. Click Add.
3. Select the service and the required service and platform access.



* The service access role allows access for using the service and performing service API calls.
* The platform access role enables actions to be performed on platform resources, such as creating an instance, connecting instances to apps, and assigning user access.



4. Click Save.







 Step 6: Set the license requirements 

If users are required to accept any license agreements beyond the IBM Cloud Services Agreement, provide the URL to each agreement.



1. From the Add license agreements tab, click Add license.
2. Enter the name and URL, and click Add license.
3. Enter all additional license agreements, and click Next.







 Step 7: Review your readme file 

When users install the software, they can view product information by clicking the Readme file link. This information is generated from the readme file that you uploaded to your source repository.



1. From the Edit readme tab, click the Edit icon !
For more information about the authorized_keys file, see [Format of the authorized_keys file](https://www.ibm.com/docs/en/zos/2.5.0?topic=daemon-format-authorized-keys-file) and [Configuring new users to access your z/OS virtual server instance](https://cloud.ibm.com/docs/vpc?topic=vpc-vsi_is_connecting_zosnew-sshkey-zos).







 Step 3. Configuring new users to access your z/OS virtual server instance 

To allow others to access your z/OS virtual server instance by using their own z/OS user IDs and own SSH keys after the instance is created, you must create each user profile and add each SSH public key into the authorized_keys file on the z/OS virtual server instance.



1. You can use one of the following methods to create a new z/OS user ID in the RACF (Resource access control facility):



* Issuing the ADDUSER command.
* Enrolling the user through the TSO/E Information Center Facility (ICF) panels. For more information about administering the Information Center Facility, see [z/OS TSO/E Administration](https://www.ibm.com/docs/en/zos/2.5.0?topic=tsoe-zos-administration).



Here is an example of using the ADDUSER command to create a user profile. Suppose you want to create a user profile for user Steve H., a member of Department A. You want to assign the following values:



* STEVEH for the user ID
* DEPTA for the default connect group
* DEPTA for the owner of the STEVEH user profile
* R3I5VQX for the initial password
* Steve H. for the user's name



Steve H. does not require any of the user profile segments except TSO. The TSO segment values that you want to set to start with are 123456 for the account number and PROC01 for the logon procedure.

To create a user profile with these values, you can run the following commands:
To assign access to All Identity and Access enabled services, specify serviceType for the name attribute, and use the valueservice. To assign access to All Account Management services, specify serviceType for the name attribute, and use the valueplatform_service. To assign access to the subset of account management services All IAM Account Management services, specify service_group_id for the name attribute, and use the valueIAM.





 Inviting users by using Terraform 

You can invite users to your IBM Cloud account by using Terraform.



1. Create an argument in your main.tf file. The following example invites users by using the ibm_iam_user_invite resource, where users are the list of user email IDs to invite.

resource "ibm_iam_user_invite" "invite_user" {
users = ["test@in.ibm.com"]
}

For more information, see the argument reference details on the [Terraform Identity and Access Management (IAM)](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/iam_user_invite) page.
2. Provision the resources from the main.tf file. For more information, see [Provisioning Infrastructure with Terraform](https://www.terraform.io/cli/run).



1. Run terraform plan to generate a Terraform execution plan to preview the proposed actions.

terraform plan
2. Run terraform apply to create the resources that are defined in the plan.

terraform apply









 Canceling or resending pending invitations 

After inviting new users to join your account, IBM Cloud requires all except VPN-only users to accept the invitation to become an active user in your account.

The invitation expires after 30 days. New users to IBM Cloud can accept an invitation only by using the invitation link that they received through email.

You can cancel an invitation for any users that are shown in a Processing or Pending state in the Status column of the [Users page](https://cloud.ibm.com/iam/users).
For example, Open an account, Get policy information, or Get a weather forecast.

The name can be up to 512 characters in length.

This node name is shown to customers or service desk personnel to express the purpose of this branch of the dialog, so take some time to add a name that is concise and descriptive.
4. In the If assistant recognizes field, enter a condition that, when met, triggers your assistant to process the node.

To start off, you typically want to add an intent as the condition. For example, if you add open_account here, it means that you want the response that you will specify in this node to be returned to the user if the user input indicates that the user wants to open an account.

As you begin to define a condition, a box is displayed that shows you your options. You can enter one of the following characters, and then pick a value from the list of options that is displayed.



Condition builder syntax

 Character Lists defined values for these artifact types 

 `#` intents 
 `@` entities 
 `@{entity-name}:` {entity-name} values 
 `$` context-variables that you defined or referenced elsewhere in the dialog 



You can create a new intent, entity, entity value, or context variable by defining a new condition that uses it. If you create an artifact this way, be sure to go back and complete any other steps that are necessary for the artifact to be created completely, such as defining sample utterances for an intent.

To define a node that triggers based on more than one condition, enter one condition, and then click the plus sign (+) icon next to it. If you want to apply an OR operator to the multiple conditions instead of AND, click the and that is displayed between the fields to change the operator type. AND operations are executed before OR operations, but you can change the order by using parentheses. For example: $isMember:true AND ($memberlevel:silver OR $memberlevel:gold)

The condition you define must be less than 2,048 characters in length.
Experimental and beta features should not be used when implementing a solution that requires the labeling and deletion of data.



 Specifying a customer ID 

To associate a customer ID with data, include the X-Watson-Metadata header with the request that passes the information. You pass the string customer_id={id} as the argument of the header. The following example associates the customer ID my_customer_ID with the data passed with a POST /v1/synthesize request:

IBM Cloud

curl -X POST -u "apikey:{apikey}" --header "X-Watson-Metadata: customer_id=my_customer_ID" --header "Content-Type: application/json" --header "Accept: audio/wav" --data "{"text":"hello world"}" --output hello_world.wav "{url}/v1/synthesize"

IBM Cloud Pak for Data

curl -X POST --header "Authorization: Bearer {token}" --header "X-Watson-Metadata: customer_id=my_customer_ID" --header "Content-Type: application/json" --header "Accept: audio/wav" --data "{"text":"hello world"}" --output hello_world.wav "{url}/v1/synthesize"

A customer ID can include any characters except for the ; (semicolon) and = (equals sign). Specify a random or generic string for the customer ID; do not specify a personally identifiable string, such as an email address or Twitter ID. You can specify different customer IDs with different requests. A customer ID that you specify is associated with the instance of the service whose credentials are used with the request; only credentials for that instance of the service can delete data associated with the ID.

Use the X-Watson-Metadata header with the following methods:



* With HTTP requests:



* POST /v1/synthesize
* GET /v1/synthesize



The customer ID is associated with data that is sent with the request.
* With WebSocket requests:



* /v1/synthesize
On the Device tab, select View Virtual Server Details and View Virtual Dedicated Host Details to add these permissions to the user’s profile.





 Adding specific device-level permissions in the customer portal 

To provide access at a specific device level, continue to the following steps.



1. Click the Device Access icon to access the Device Access screen.
2. Click the Quick Access tab.
3. From the Device Type drop-down list, select All virtual servers and All dedicated hosts.
4. Select the Automatically grant access when new devices are added checkbox if the associated user needs to always have access to this device type.
5. Verify that the correct devices are selected.
6. Click Update device access.



You can also use the SoftLayer_User_Customer::addBulkDedicatedHostAccess API service to give a user access to one or more dedicated hosts. For more information, see [Adding Bulk Dedicated Host Access](https://softlayer.github.io/reference/services/SoftLayer_User_Customer/addBulkDedicatedHostAccess/).







 Next steps 

User permissions are updated immediately after the changes are submitted. If permissions are granted, the user can view or interact with the selected features. If permissions are removed, the user can no longer view or interact with the selected features. Permissions can be updated again at any time.
Assign the custom roles to the anonymous user service ID 

To assign the custom roles that are defined in [Step 1](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-best-practice-pkcs11-accessstep1-create-custom-roles) to the anonymous user service ID, follow these steps:

To assign access to the keystore for the anonymous user, follow these steps:



1. From the menu bar, click Manage > Access (IAM), and select Service IDs to browse the existing service IDs in your account.
2. Hover your mouse over the Anonymous user service ID, and click the Actions icon ![Actions icon](https://cloud.ibm.com/docs-content/v1/content/217f108cc44e2ce15fb692d4b57b4c628464e908/icons/action-menu-icon.svg) to open a list of options.
3. From the options menu, click Assign access.
4. Click Access policy.
5. Under Service, select Hyper Protect Crypto Services and click Next.
6. Under Resources, select Specific resources.
7. Select the Service Instance ID attribute type, enter the Hyper Protect Crypto Services service instance ID that you want to grant access to, and click Next.
8. Under Roles and actions, check the boxes for Key operator and click Next.
9. (Optional) Under Conditions (optional), click Review to check the access policy.
10. After confirmation, click Add > Assign.









 What's next 

Continue to read

[Performing cryptographic operations with the PKCS #11 API](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-set-up-pkcs-api) on how to use the PKCS #11 API.
You have now configured SSSD to use LDAP for user authentication on your RHEL 8 system with the LDAP server "ibmsymphony.com".





 Step 4: Configure Symphony cluster 

Now that you've configured the LDAP client authentication, you need to configure the Symphony cluster that is hosted on the LDAP client to point to the OLDAP server, which ensures that the integration of the Symphony cluster with OLDAP server is possible for user management.

The steps add the existing user “symphonyuser01” that's created in the OLDAP server to the Symphony cluster.

To complete the following steps, you need to use a Symphony cluster user account with high privileges. Only an account with high privileges can add the users to the Symphony cluster and then assign roles to them. Howvever, if the newly added user is assigned the CLUSTER_Admin role, then that user can also complete the following steps for subsequently added users.



1. To add the existing user, “symphonyuser01”, which was created in the OLDAP server, to the Symphony cluster, you need to log in as the cluster administrator, and then run the following commands:

[root@icgen2host-172-19-1-69 ] su symadmin
bash-4.4$ egosh user logon -u Admin -x Admin
Admin@HPCCluster> user add
user account: symphonyuser01
password:
password(type again, please):
User account < symphonyuser01 > added successfully
Admin@HPCCluster> user logoff
Logged off successfully
2. Log in with the user that was added in the previous step to the Symphony cluster by running the following command:

[root@hpcc-symphony-primary-0 ] su symphonyuser01
[symphonyuser01@hpcc-symphony-primary-0 root]$ egosh
egosh> user logon -u symphonyuser01 -x welcome2
Logged on successfully
symphonyuser01@HPCCluster> resource list
NAME status mem swp tmp ut it pg r1m r15s r15m ls
curl -X POST https://us-south.appid.cloud.ibm.com/management/v4/39a37f57-a227-4bfe-a044-93b6e6060b61/applications/ -H 'Content-Type: application/json' -H 'Authorization: Bearer <IAMToken>' -d '{"name": "ApplicationName"}'

Example response:

{
"clientId": "111c22c3-38ea-4de8-b5d4-338744d83b0f",
"tenantId": "39a37f57-a227-4bfe-a044-93b6e6060b61",
"secret": "ZmE5ZDQ5ODctMmA1ZS00OGRiLWExZDMtZTA1MjkyZTc4MDB4",
"name": "ApplicationName",
"oAuthServerUrl": "https://us-south.appid.cloud.ibm.com/oauth/v4/39a37f57-a227-4bfe-a044-93b6e6060b61"
}



2. Add an application.yml configuration file to the /springbootsample/src/main/resources/ directory. You can complete your configuration with the information from your service credentials.

security:
oauth2:
client:
clientId: <clientID>
clientSecret: <clientSecret>
accessTokenUri: <oauthServerURL>/token
userAuthorizationUri: <oauthServerURL>/authorization
resource:
userInfoUri: <oauthServerURL>/userinfo



For a step-by-step example, check out [this blog](https://www.ibm.com/cloud/blog/creating-spring-boot-applications-app-id){: external!







 Using App ID with other languages
* By navigating to the Applications tab of the App ID dashboard. If you don't already have one, you can click Add application to create a new one.
* By making a POST request to the [/management/v4/<tenantID>/applications endpoint](https://us-south.appid.cloud.ibm.com/swagger-ui/!/Applications/registerApplication).

Request format:

curl -X POST https://us-south.appid.cloud.ibm.com/management/v4/39a37f57-a227-4bfe-a044-93b6e6060b61/applications/ -H 'Content-Type: application/json' -H 'Authorization: Bearer <IAMToken>' -d '{"name": "ApplicationName"}'

Example response:

{
"clientId": "111c22c3-38ea-4de8-b5d4-338744d83b0f",
"tenantId": "39a37f57-a227-4bfe-a044-93b6e6060b61",
"secret": "ZmE5ZDQ5ODctMmA1ZS00OGRiLWExZDMtZTA1MjkyZTc4MDB4",
"name": "ApplicationName",
"oAuthServerUrl": "https://us-south.appid.cloud.ibm.com/oauth/v4/39a37f57-a227-4bfe-a044-93b6e6060b61"
}



3. Create an Open ID Connect Client feature and define the following placeholders. Use the service credentials to fill the placeholders.

<openidConnectClient
clientId='{{site.data.keyword.appid_short_notm}} client_ID'
clientSecret='{{site.data.keyword.appid_short_notm}} Secret'
You can create and apply [user tags](https://cloud.ibm.com/docs/vpc?topic=vpc-block-storage-aboutstorage-about-user-tags) and [access management tags](https://cloud.ibm.com/docs/vpc?topic=vpc-block-storage-aboutstorage-about-mgt-tags) to volumes to better control and organize your Block Storage for VPC resources across the VPC.



 User tags for Block Storage for VPC volumes 

User tags are uniquely identified by a Cloud Resource Name (CRN) identifier. When you create a user tag, you provide a unique name within your billing account. You can define user tags in label or key-value format.

You can [add user tags](https://cloud.ibm.com/docs/vpc?topic=vpc-managing-block-storage&interface=uiadd-user-tags-volumes-ui) when you create a Block Storage for VPC volume or when you update an existing volume. You can also add tags to a boot or data volume during [instance creation](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-block-storage&interface=uicreate-from-vsi). For boot volumes, you edit the boot volume to add tags. For data volumes, you can add tags when you create and attach them to the instance, or add them to existing data volumes. Volume user tags are also used by [backup policies](https://cloud.ibm.com/docs/vpc?topic=vpc-backup-service-about) to create automatic backup snapshots of the volume. Create, view, and manage user tags from the UI, CLI, API, or Terraform, and remove then at any time.





 Access management tags for Block Storage for VPC volumes 

[Access management tags](https://cloud.ibm.com/docs/vpc?topic=vpc-iam-getting-started&interface=ui) help organize access control by creating flexible resource groupings, enabling your Block Storage for VPC resources to grow without requiring updates to IAM policies.
For more information, see [Creating new CA admins](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-identitiesibp-console-identities-ca-admin).





 Registering identities 

The first step in creating an identity is known as registration. During registration, an enroll ID and secret are created which can be used by a node or an org administrator to enroll this identity by generating a signing certificate and private key.

You need to enter the following information when you register a new identity with your CA.



* Enroll ID and Enroll Secret: This identity has an ID and secret, which is analogous to a username and password, that you specify during the deployment of your CA. You can use this admin ID and secret to create certificates with this identity by using this console or the Fabric CA client.
* Type: When the CA was deployed, the administrator specified the types of identities issued by the CA. Common examples of identity types include peer, orderer, admin, and client (applications). Select the identity type for this user from the list of available types.
* Affiliation: (Optional) Advanced users only. This field is only visible if affiliations are defined for your CA. An affiliation is the part of an organization that you want to associate with this user. For example, this could be a department or unit that operates an application or a peer. It is possible to restrict a particular CA admin to be able to register only users within their own department within an organization by setting their affiliation. CA affiliations are defined by using the Fabric CA [Affiliation Command](https://hyperledger-fabric-ca.readthedocs.io/en/release-1.4/clientcli.htmlaffiliation-command). The default affiliation that is available when you clear the Use root affiliation checkbox is ibp.
* Maximum Enrollments: Optionally, enter the number of times that you can enroll or generate certificates by using this identity. Specifying a limited number of enrollments helps protect the security of your nodes and applications. It defaults to unlimited enrollments.
In the IBM Cloud console, click Manage > Access (IAM), and select Access Groups.
2. Click Create.
3. Enter a unique name to identify your access group and an optional description.
4. Click Create.



Next, continue to set up your group by adding users or service IDs:



1. Select the name of the group that you want to update.
2. Click Add users.
3. Select the users that you want to add from the list, and click Add to group.
4. To add service IDs to the group, click Service IDs.
5. Select the IDs that you want to add from the list, and click Add to group.







 Assign access to your groups 

After you create your access groups, you can assign access to all members of the group with one or more policies. By assigning a group of users access to a group of resources with a single policy, you reduce the overall number of policies that you need to manage.



1. From the Access tab, click Assign access.
2. Select a single service or group of services. Then, click Next.
3. Scope the access to all resource or specific resources based on attributes. Then, click Next.
4. Select the level of access that you want to assign.

If you're assigning access to IAM-enabled services, some services support the use of advanced operators to grant access to resources that satisfy specific naming conventions. See [Assigning access by using wildcard policies](https://cloud.ibm.com/docs/account?topic=account-wildcard) for more information.
5. Click Review.
6. Click Add to add your policy configuration to your policy summary.
7. Click Assign to assign all added access to your access group.









 Step 2: Invite users 

You can invite one or multiple users in a single invite. If you invite multiple users in one invitation, the same access is assigned to each user. However, you can invite users to your account with no access, and assign them access later.



1.