vania-janet/multiturn-rag-retrieval-data huggingface dataset:
[Learn about the ways that you can submit feedback](https://cloud.ibm.com/docs/overview?topic=overview-feedback). 
 <br><br> * Connect and get developer resources<br><br><br> Learn in-demand skills, build solutions with real sample code, and connect with a global community of developers. Bookmark [IBM Developer](https://developer.ibm.com/). 
 <br><br> * Ask questions and find answers on Stack Overflow<br><br><br> Ask questions or view responses on [Stack Overflow](https://stackoverflow.com/questions/tagged/ibm-cloud) by using the [ibm-cloud tag](https://stackoverflow.com/questions/tagged/ibm-cloud?tab=Newest) or expand to include more related [tags](https://stackoverflow.com/questions/tagged/ibm-cloud+or+ibm-cloud-code-engine+or+ibm-appid?tab=Newest). 
 <br><br> * Find an answer to your FAQ about support<br><br><br> Visit the FAQ library in the console to get answers about [frequently asked questions for getting support](https://cloud.ibm.com/docs?tab=faqs&tags=get-support). 
 <br><br> * Working with a Customer Success Manager (CSM)<br><br><br> A CSM is reserved for those clients who have made a significant commitment to employ IBM Cloud for their cloud-based solution. Assignment takes place by a nomination process with supporting criteria that does vary per geo location. Work through your local IBM Sales team or [Inbound Sales](https://www.ibm.com/cloud?contactmodule) for additional details on receiving a dedicated CSM resource. 
 <br><br> * Submit product ideas and feature requests<br><br><br> Submit your ideas and feature requests for review and possible implementation by the Product Management team. The Product Management team is responsible for the full lifecycle of an IBM Cloud product offering.
Account-based MFA options are available only with classic infrastructure accounts and only protect classic infrastructure resources. This type of MFA is tied to the account. If an administrator enables a different legacy MFA option for each account that a user is a member of, the user is prompted to authenticate a different way each time that they switch accounts.

If an account requires any ID-based MFA, that factor overrides any legacy account-based MFA options that are enabled and set up in a user's account. Therefore, even if a user has other MFA options, such as the following set up, the user is not prompted for them at login.

Time-based one-time passcode authentication (TOTP)
: TOTP can be set up by using an authentication app. Before an account owner or administrator can enable this setting for a user on the User details page, the user must set up authentication by going to Avatar icon ![Avatar icon](https://cloud.ibm.com/docs-content/v1/content/4d8c6eec891cff72b666dc24bd3211810c77fb42/icons/i-avatar-icon.svg)> Profile > Login settings. If this setting is enabled for a user, they are prompted for the passcode during login. Users with access to manage their own login settings by having the User-managed login setting that is turned on from their User details page can turn on and off this MFA setting.

Security questions
: Users can set up answers to the security questions that are available by going to Avatar icon ![Avatar icon](https://cloud.ibm.com/docs-content/v1/content/4d8c6eec891cff72b666dc24bd3211810c77fb42/icons/i-avatar-icon.svg)> Profile > Login settings. The user must set up the security questions and answers before an account owner or administrator can enable this setting on the User details page. Users with access to manage their own login settings by having the User-managed login setting that is turned on from their User details page can turn on and off this MFA setting.

External authentication
Dealing with Distributed Denial of Service attacks 

Distributed Denial of Service (DDoS) attacks are among the most common types of internet attacks that your website or host can encounter.



 What is a DDoS attack? 

A distributed denial of service (DDoS) attack is a malicious attempt to disrupt normal traffic of a server, service, or network by overwhelming the target or its surrounding infrastructure with a flood of internet traffic. DDoS attacks achieve effectiveness by utilizing many compromised computer systems as sources of attack traffic. Exploited machines can include computers and other networked resources such as IoT devices. From a high level, a DDoS attack is like a traffic jam clogging up a highway, preventing regular traffic from arriving at its destination.





 How DDoS attacks work 

An attacker gains control of a network of online machines to carry out a DDoS attack. Computers and other machines (such as IoT devices) are infected with malware, turning each one into a bot (or zombie). The attacker controls the group of bots, which is called a botnet.

After establishing a botnet, the attacker directs the machines by sending updated instructions to each bot using remote control. A targeted IP address can receive requests from a multitude of bots, causing the targeted server or network to overflow capacity. This creates a denial-of-service to normal traffic. Because each bot is a legitimate internet device, separating the attack traffic from normal traffic can be difficult.





 Common types of DDoS attacks 

DDoS attack vectors target varying components of a network connection. While nearly all DDoS attacks involve overwhelming a target device or network with traffic, attacks can be divided into three categories. An attacker can use one or multiple attack vectors, and might even cycle through these attack vectors based on countermeasures taken by the target.

Common types are:



* Application layer attacks (Layer 7)
* Protocol attacks (Layer 3 and Layer 4)
* Volumetric attacks (amplification attacks)





 Application layer attacks 

An application layer attack is sometimes referred to as a Layer-7 DDoS attack (in reference to the 7th layer of the OSI model).
* Optional: evidence-repo (text): URL of the repo that serves as an evidence locker for the application.
* Optional: incident-repo (text): URL of the repo that serves as the issues repo for the application.
* Optional: inventory-repo (text): URL of the repo that serves as the inventory repo for the application.





3. Optional: Set up manual triggers for each of the applications.



* You technically need only one manual trigger because its properties can be edited at call time, but it might be useful for teams to have pre-composed manual triggers to save them some steps in writing all the possible small differences between the apps.



4. Optional: Create timer Triggers for your applications.



* Its good practice to often rebuild and revalidate an application, so you can keep on top of any compliance and vulnerability issues, as well as any build issues.
* Make sure to configure the trigger properties the same way you configured the manual trigger because the timer trigger is just a manual trigger on a timer.
* Make sure you stagger your cron jobs from each other, otherwise you might overload the worker cluster and your jobs might suffer increased builds times or lag between stages.





For information on the other properties that can be set on the pipeline triggers or within the environment properties, see the [pipeline parameter catalog](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-pipeline-parm).





 Best practices for multiple applications 

Review the following best practices for multiple applications:



* It is best to name the triggers by the application name and then its purpose, so people can easily filter on them in the dashboard. For example, hello-world Git <branch> Trigger.
* Seek to maximize the usage of the trigger properties in the manual triggers to reduce the need to insert input values. It also has the helpful effect of moving those values to the top of the properties list, so there's no need to search for the properties that need to change.
Deploying your Infrastructure 

Use the following information to deploy and set up SAP HANA and/or SAP NetWeaver on IBM Cloud® Bare Metal Servers for Virtual Private Cloud (VPC).



 Setting up a VPC and subnet 

The following steps summarize the setup of VPC and subnets, which is detailed further in the [Create an IBM Cloud VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-a-vpc-using-the-ibm-cloud-console).



1. Click Menu icon![Menu icon](https://cloud.ibm.com/docs-content/v1/content/icons/icon_hamburger.svg) > VPC Infrastructure > Network > VPCs
2. Click Create.
3. Select a Location for the VPC. The location consists of a Geography and a Region.
4. Enter a unique Name for the VPC.
5. Select a Resource group. Use resource groups to organize your account resources for access control and billing purposes. For more information, see [Best practices for organizing resources in a resource group](https://cloud.ibm.com/docs/account?topic=account-account_setup) and [What makes a good resource group strategy?](https://cloud.ibm.com/docs/account?topic=account-account_setupresource-group-strategy).
6. Optional: Enter tags to help you organize and find your resources. You can add more tags later. For more information, see [Working with tags](https://cloud.ibm.com/docs/account?topic=account-tag).
7. Select whether the Default security group allows inbound SSH and ping traffic to bare metal server instances in this VPC. You can modify the default security group later.
8. Optional: Classic access. Select whether you want to enable your VPC to access classic infrastructure resources.
You can also use Advanced vMotion and storage vMotion between the environments. In addition, you can use services and tools from [Zerto](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-addingzertodr) or [Veeam](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-veeamvm_overview).



When you deploy a new vCenter Server with NSX-T instance, you get a new Active Directory (AD). If you customized your AD, you must migrate these changes to the AD of the new instance.

In your VM migration between the NSX-V and NSX-T environments, the new vCenter Server instance is provisioned with new storage, both vSAN and NFS.



 Considerations for NSX-V to NSX-T migrations 

To ensure that your migration is seamless and to minimize the downtime, design the migration and its phases and waves carefully. Due to the differences in the architecture, opens you the possibility redesign parts of your network instead of just mirroring the configurations to best match your requirements and NSX-T best practices.

If you do not think that you have skills in the house, you can get help from various service providers. IBM Cloud worked closely with PrimaryIO, who provides [an optional Pro Service](https://cloud.ibm.com/catalog/services/hdm-cloud-connect-nsx-v-to-nsx-t) to help you and accelerate your NSX-V to NSX-T migration.





 Related links 



* [Requirements for vCenter Server instances](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_orderinginstance-req)
* [NSX-T Data Center Migration Guide](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.2/migration/GUID-7899A104-2662-4FC9-87B2-F4688FAEBBBA.html)
On the new NSX-T based vCenter Server instance, [order the HCX Service](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-hcx_ordering). You can use private deployment, as all HCX traffic between the environments uses private connectivity in IBM Cloud private network. You must have outbound internet connectivity for HCX registration and updates.
4. After the HCX was deployed on the new target vCenter Server, provision HCX Manager on the old NSX-V based environment. You must have outbound internet connectivity for HCX registration and updates.
5. Establish Site Peering between the two environments from the old vCenter Server with NSX-V environment to the new vCenter Server with NSX-T environment. Then, create an HCX Service Mesh to enable the required services, such as Interconnect, L2 network extension, and the HCX migration services.
6. You can extend your NSX-V Logical Switches to NSX-T overlay segments with Network Extension service. Each HCX-NE can extend up to eight segments at a time, and you can create multiple HCX-NEs if needed.
7. Read the existing and create new network topology manually, by using scripts Migration Coordinator or third-party tools.
8. After the required networks are extended, you can start planning and migrating VMware workloads. HCX provides multiple ways for migration, such as Bulk Migration, Cold Migration, vMotion, and Replication Assisted vMotion. Refer to VMware documentation for the differences of these methods and how you can best use them in your workload migration.





 Considerations for migrating with HCX 

Each HCX-NE appliance can extend up to eight segments at a time, and you can create multiple HCX-NEs if needed. You can configure them when you create the service mesh.





 Related links 



* [Ordering VMware HCX in IBM Cloud](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-hcx_ordering)
In the sshd_config file, give access to the sshusers group:

AllowGroups sshusers
4. Verify that sshd reads the new configuration without breaking:

/usr/sbin/sshd –t

echo $?

If you get a 0 following the echo $? command, the new configuration is correct.

You can also get error messages similar to the following examples:

sshd_config: line 112: Bad configuration option: allowuser

sshd_config: terminating, 1 bad configuration options
5. After you fix all errors and have a correct configuration, restart sshd. The following command is an example command in a sysv-compatible system:

/etc/init.d/sshd restart



Make sure that you create a new SSH session without disconnecting your existing session. Verify that you can perform any actions with the users that you added.
About file share replication 

You can create replicas of your file shares by setting up a replication relationship between primary file shares in one zone to replica file shares in another zone. Using replication is a good way to recover from incidents at the primary site, when data becomes inaccessible or applications fail.

IBM Cloud® File Storage for VPC is available for customers with special approval to preview this service in the Frankfurt, London, Madrid, Dallas, Toronto, Washington, Sao Paulo, Sydney, Osaka, and Tokyo regions. Contact your IBM Sales representative if you are interested in getting access.



 Replication overview 

When you create a file share, you can set up replication. You create your file share in one zone of the region and a replica share in another zone in the same region. Based on the replication schedule, the service pulls data from the source file share to the replica file share.

You can choose how often you want to sync changes from the source share to the replica. You can specify daily, weekly, or monthly replication schedule conveniently in the UI. Or, you can specify replication by using a cronspec expression. Replications must be scheduled at least 1 hour apart. When a replica share is created, the first replica contains the data of the entire share. Thereafter, only the changes that occurred after the previous replication are added.

Data on the replica share is read-only. You can obtain read/write access to the data in two ways:



* [Fail over to the replication site](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-failover&interface=ui) - The read/writes from the source file share are paused and a final copy of the file share data is pulled into the replica share. The replica share becomes read/write accessible, and a reverse replication relationship is established. The original source file share now becomes the replica share and set to read-only. The service then begins pulling data from the new source file share.

If a source file share is compromised, replica shares are a good way to recover operations.
You can retrieve the MAC address for the PCI interface through the UI, [CLI](https://cloud.ibm.com/docs/vpc?topic=vpc-infrastructure-cli-plugin-vpc-referencebare-metal-server-network-interface), or [API](https://cloud.ibm.com/apidocs/vpc/latestlist-bare-metal-server-network-interfaces).







 Limitations of network interfaces 



1. VLAN interfaces with different VLAND IDs can be placed within different subnets. However, you need to associate VLAN interfaces with the same VLAN ID within the same subnet.

For example, you can create multiple VLAN interfaces with VLAN ID 111 within subnet A. However, if you create VLAN interfaces with VLAN ID 111 within subnet A and within subnet B, the two network interfaces can't work as expected.

You need to design your network properly before you create the network interfaces. A good practice is to set up a VLAN ID - subnet one-to-one mapping network topology.
2. In a VMware environment, traffic between VLAN network interfaces that have the same VLAN ID and are on the same bare metal server are typically switched by the standard vSwitch within the server and never reach the VPC network.

For example, on a bare metal server host, the default standard vSwitch is vSwitch0. You can create a port group with VLAN ID 111 and add it to vSwitch0. Traffic between network interfaces that is attached to port group 111 is controlled by vSwitch0.

This setting has the following consequence:



* Security group rules that control traffic between the network interfaces in port group 111 aren't applied. If you need security group rules, you need to use separate VLAN IDs for the VLAN interfaces.



3. In a distributed vSwitch topology, to enable vMotion in a specific port group, you need to make sure that the VLAN ID of this port group is included in the VLAN allowlist of all the bare metal servers.
* For more information about feature differences, see [the feature comparison table](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-version-chooseversion-choose-comparison).
* For more information about detailed API differences, see [API version comparison](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-migrate-to-v2-api).



Discovery v2 is available for all users of Plus or Enterprise plan instances, or Premium plan instances that were created after 15 July 2020. v2 is also available for IBM Watson® Discovery Cartridge for IBM Cloud Pak® for Data users.



 Migration overview 

Migrating from Discovery v1 to v2 is a multistep process that you can do independently.

The two versions of the Discovery service have many differences, but you can adopt techniques and utilities that were applied to a v1 instance for use with your new v2 instance.

To migrate from v1 to v2, you must complete the following high-level steps:



1. [Plan the migration](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-migrate-to-v2migrate-to-v2-plans).
2. [Transfer your documents](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-migrate-to-v2migrate-to-v2-docs).
3. [Update your application to use the v2 API](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-migrate-to-v2migrate-to-v2-difs).
4. Regression test and deploy the updated application.
5. [Delete your v1 plan service instance](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-migrate-to-v2migrate-to-v2-delete).



Some steps require you to make programmatic changes by using the API and others involve changes that you can make from the product user interface.





 Plan the migration
For more information, see [ffmpeg.org](https://www.ffmpeg.org).





 Tips for improving speech recognition 

The following tips can help you improve the quality of speech recognition:



* How you record audio can make a big difference in the service's results. Speech recognition can be very sensitive to input audio quality. To obtain the best possible accuracy, ensure that the input audio quality is as good as possible.



* Use a close, speech-oriented microphone (such as a headset) whenever possible and adjust the microphone settings if necessary. The service performs best when professional microphones are used to capture audio.
* Avoid using a system's built-in microphone. The microphones that are typically installed on mobile devices and tablets are often inadequate.
* Ensure that speakers are close to microphones. Accuracy declines as a speaker moves farther from a microphone. At a distance of 10 feet, for example, the service struggles to produce adequate results.



* Use a sampling rate no greater than 16 kHz (for broadband models) or 8 kHz (for narrowband models), and use 16 bits per sample. The service converts audio recorded at a sampling rate that is higher than the target model (16 kHz or 8 kHz) to the rate of the model. So larger frequencies do not result in enhanced recognition accuracy, but they do increase the size of the audio stream.
* Encode your audio in a format that offers data compression. By encoding your data more efficiently, you can send far more audio without exceeding the 100 MB limit. Because the dynamic range of the human voice is more limited than, say, music, speech can accommodate a bit rate that is lower than other types of audio. Nonetheless, IBM® recommends that you choose an audio format and compression algorithm carefully. For more information, see [Maximizing transcription accuracy](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-audio-formatsaudio-formats-recommendations).
* Speech recognition is sensitive to background noise and nuances of human speech.



* Engine noise, working devices, street noise, and background conversations can significantly reduce recognition accuracy.
* Regional accents and differences in pronunciation can also reduce accuracy.
Technologies 

Confused about the differences between authorization and authentication? You're not alone. Check out the following information to learn about specific terminology, processes, and the technologies that are used when you work with IBM Cloud® App ID.

Want to know more about some basic concepts of authorization and authentication? Look no further. In the following video you can learn about OAuth 2.0, grant types, OIDC, and more.



 OAuth 2 

[OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc6749) is open standard protocol that is used to provide app authorization.





 Open ID Connect (OIDC) 

[OIDC](https://openid.net/developers/specs/) is an authentication layer that works with OAuth 2. When you use OIDC and App ID together, your application credentials help to configure your OAuth endpoints. If you use the SDK, the endpoint URLs are built automatically. But, you can also build the URLs yourself by using your service credentials. The URL takes the following form: App ID service endpoint + "/oauth/v4" + /tenantID.

Example:

{
"clientId": "7eba72ef-b913-47b0-b3b6-54358bb69035",
"tenantId": "8f5aa500-357e-443a-aab6-bf878f852b5a",
"secret": "OWEzZGM4M2UtZjhlYS00MDI2LTkwNGItNDJmYzViMmU2YzIz",
"name": "testing",
"oAuthServerUrl": "https://us-south.appid.cloud.ibm.com/oauth/v4/8f5aa500-357e-443a-aab6-bf878f852b5a",