vania-janet/multiturn-rag-retrieval-data huggingface dataset:
[Hyper-V Installation Guide, 17.2.0](https://public.dhe.ibm.com/cloud/bluemix/network/vra/18_vrouter_hyper-v_installation_5600.pdf) This guide describes how to install and upgrade the AT&T Vyatta vRouter running on Hyper-V systems. 
 [Linux KVM Installation Guide, 17.2.0](https://public.dhe.ibm.com/cloud/bluemix/network/vra/18_vrouter_linux_kvm_installation_5600.pdf) This guide describes how to install and upgrade the AT&T Vyatta vRouter running on Linux KVM environment. 
 [Quick Start Guide, 17.2.0](https://public.dhe.ibm.com/cloud/bluemix/network/vra/18_vrouter_quick_start_5600.pdf) This guide gets you started using and configuring the AT&T products that run on the AT&T Vyatta Network Operating System. It describes how to deploy the router and introduces you to the CLI and web GUI interfaces that you can use to access, configure, and manage the router. 
 [Static Route Tag Addendum](https://public.dhe.ibm.com/cloud/bluemix/network/vra/18_basic_routing_configuration_5600_addendum.pdf) This addendum to the Vyatta Basic Routing Configuration Guide describes the Static Route Tag functionality that was added to Release 17.2.0 of the AT&T Vyatta vRouter. 
 [Firewall Configuration Guide, Addendum 1801](https://public.dhe.ibm.com/cloud/bluemix/network/vra/18_firewall_configuration_5600_addendum.pdf) This addendum describes firewall functionality that was updated on the AT&T Vyatta vRouter in release 1801.
* Try to access the IPMI IP through different browser.
* Update your browser and or Java to access IPMI IP.
* If you still have problems, contact [support](https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-gettinghelp).







 Why isn't RDP working? 

If you can access your server, but RDP isn't working, it might be caused by one of the following reasons.



* [RDP traffic is blocked](https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-troubleshooting-bare-metalbm-blocked-RDP-traffic).
* [Inadequate client access licenses](https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-troubleshooting-bare-metalbm-inadequate-client-access-licenses).
* [Pending Windows updates](https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-troubleshooting-bare-metalbm-pending-windows-updates).





 RDP traffic is blocked 

RDP traffic (port 3389) might be blocked by the Windows firewall, hardware firewall, or gateway (Vyatta, AT&T, Juniper, FortiGate). Check that your firewall allows RDP traffic.





 The server has inadequate client access licenses 

RDP might not work because of inadequate client access licenses that are installed on the server. For more information, contact [support](https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-gettinghelp).





 The server has pending Windows updates 

If your server has pending Windows updates, install the latest updates, restart the server, and try to access RDP.







 Why can't I connect to a server through the public IP? 

If you can't connect to a server through the public IP, it might be caused by one of the following reasons.



* Public traffic is blocked by your firewall or gateway (Vyatta, AT&T, Juniper, FortiGate).
The directory path of the source repo identifies which files to deploy to the provided cluster group.



 Configure the target Red Hat OpenShift cluster to deploy the app to 

If the API key has the required access, the following fields automatically load by using the API key that is either created, retrieved from a vault, or manually specified. If the API key is valid, values for the Branch name and Cluster group are automatically populated. You can update any of these fields to match your configuration.



* IBM Cloud API Key: The API key that is used to interact with the ibmcloud CLI tool in several tasks. Use one of the following methods to specify the API key that you want to use:



* Click the key icon to import an existing API key from a secret vault of your choice.
* Copy and paste an existing API key.
* Click New to create an API key.
* Generate a new api-key if you don’t have an existing API key.



You can immediately save the generated API key to an existing secrets vault of your choice.
* Cluster namespace: Specify a name for the [cluster namespace](https://docs.openshift.com/online/pro/dev_guide/projects.htmldev-guide-projects) that you want to deploy the app to.
* Branch: Specify the Git branch of your source repo.
* Path: Specify the directory path of your source repo.
* Cluster group: Select the IBM Cloud Satellite cluster group where you want to deploy your app.
* Configuration name: Specify the name for the Satellite config. This name is used to create Satellite config versions that are used to create Satellite subscriptions.



Zoom

![IBM Cloud Satellite details](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/cd-only-satellite-Sat-config.png)

Figure 7. IBM Cloud Satellite Config details

Click Continue.







 Step 5: Complete the toolchain setup
* [A security group is blocking RDP traffic](https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-troubleshooting-virtual-serversecurity-group-blocking-rdp-traffic)





 RDP traffic is blocked 

RDP traffic (port 3389) might be blocked by the Windows® firewall, hardware firewall, or gateway (Vyatta, AT&T, Juniper, Fortigate). Check that your firewall allows RDP port 3389.





 The server has inadequate client access licenses 

RDP might not work because of inadequate client access licenses that are installed on the server. For more information, contact [support](https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-gettinghelp).





 The server has pending Windows updates 

If your server has pending Windows updates, install the latest updates, restart the server, and try to access RDP.





 RDP traffic is blocked by a security group 

If you're using a security group, make sure that you allow RDP (port 3389) traffic. For more information, see [Creating security groups and rules](https://cloud.ibm.com/docs/security-groups?topic=security-groups-creating-security-groups).







 Why can't I connect to a server through the public IP? 

Public traffic might be blocked by your firewall or gateway (Vyatta, AT&T, Juniper, Fortigate).

If the firewall isn't an issue, check whether the public gateway IP is configured for the public network card and try pinging the public gateway. For more help, contact [support](https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-gettinghelp).





 Why is the internet disconnected? 

If your internet is disconnected, it might be caused by one of the following reasons.



* [Internet is blocked by firewall or gateway](https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-troubleshooting-virtual-serverinternet-blocked-by-firewall-or-gateway)
Check whether you can ping IBM DNS servers (10.0.80.11, 10.0.80.12), if you configured DNS servers for the public network card.

If you have Linux servers, add the following entries in the /etc/resolv.conf file:

nameserver 10.0.80.11 and nameserver 10.0.80.12







 Why does the portal show that my server is disconnected even though it's running? 

If your portal shows that the server is disconnected, but the server is running, it might be caused by one of the following reasons.



* [Your firewall or gateway rules are blocking ping](https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-troubleshooting-virtual-serverfirewall-or-gateway-rules-blocking-ping)
* [A security group is blocking ping](https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-troubleshooting-virtual-serversecurity-group-blocking-ping)





 Firewall or gateway rules are blocking the ping 

If your firewall or gateway (Vyatta, AT&T, Juniper, Fortigate) blocks ping traffic, then the status of your servers shows "disconnected" in the portal. Check that your firewall rules allow ping traffic from IBM Cloud® IP ranges. For more information about IP ranges, see [IBM Cloud® IP ranges](https://cloud.ibm.com/docs/cloud-infrastructure?topic=cloud-infrastructure-ibm-cloud-ip-ranges).





 Security group is blocking the ping 

If you're using a security group, make sure that you allow ping traffic from the IBM Cloud® IP ranges. For more information, see [Creating security groups and rules](https://cloud.ibm.com/docs/security-groups?topic=security-groups-creating-security-groups)







 Why is my migration not working? 

If your migration is stuck or didn't complete properly, create a [support case](https://cloud.ibm.com/docs/get-support?topic=get-support-get-supportfaqopen-support-case) for assistance.
[Direct Link Connect ordering](https://cloud.ibm.com/docs-content/v1/content/b698ea8660e1f51664f7479f870bbf8840335d06/dl//images/public-range.png)

Manual-select IP Public Range



Write down and retain the connection name and the service key that was generated from the order.
3. Send the name of the connection and the generated service key to the AT&T Service Provider team. If you are granted permission by AT&T to order Direct Link Connect through the Equinix Fabric portal, complete your order using the Equinix Cloud Exchange (ECX) Fabric portal.





 AT&T TAO / NetBond Essentials notes when ordering using the Equinix Fabric portal 



1. In the IBM Cloud Direct Link 2 profile, click Create Connection.

Zoom

![Equinix ordering](https://cloud.ibm.com/docs-content/v1/content/b698ea8660e1f51664f7479f870bbf8840335d06/dl//images/equinix-ibm-cloud-2.png)

Equinix ordering
2. Very Important - On the Connection Details page, for the IBM Cloud Account ID, AT&T must enter the service key (for example, aaa-bbbb-cccc) that was generated when you provisioned your direct link. You can find this key on the Direct Link details page.

Zoom

![Connection Details](https://cloud.ibm.com/docs-content/v1/content/b698ea8660e1f51664f7479f870bbf8840335d06/dl//images/equinix-connection-details.png)

Connection Details







 AT&T TAO / NetBond Essentials submits your Equinix order using the Equinix Fabric portal 

After the order is completed, AT&T will need to notify you that the Equinix order was submitted.
(https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/openshift/images/cs_clusters_planning_internet.png)

Figure 1. Network setup for a cluster that runs internet-facing workloads



 Worker-to-worker communication in classic clusters with internet-facing workloads 

To achieve this setup, you create a cluster by connecting worker nodes to public and private VLANs.

If you create the cluster with both public and private VLANs, you can't later remove all public VLANs from that cluster. Removing all public VLANs from a cluster causes several cluster components to stop working. Instead, create a new worker pool that is connected to a private VLAN only.





 Worker-to-master and user-to-master communication in classic clusters with internet-facing workloads 

You can choose to allow worker-to-master and user-to-master communication over the public and private networks, or over the public network only.



* Public and private cloud service endpoints: Your account must be enabled with VRF and enabled to use service endpoints. Communication between worker nodes and master is established over both the private network through the private cloud service endpoint and the public network through the public cloud service endpoint. The master is publicly accessible to authorized cluster users through the public cloud service endpoint.
* Public service endpoint: If you don’t want to or can't enable VRF for your account, your worker nodes and authorized cluster users can automatically connect to the Kubernetes master over the public network through the public cloud service endpoint.







 Worker communication to other services or networks with internet-facing workloads 

Your worker nodes can automatically, securely communicate with other IBM Cloud services that support private cloud service endpoints over your IBM Cloud infrastructure private network. If an IBM Cloud service does not support private cloud service endpoints, workers can securely communicate with the services over the public network. You can lock down the public or private interfaces of worker nodes by using Calico network policies for public network or private network isolation.
Managing owners 



  Assigning owners to objects 



1.  Go to Databases.
2.  Select the database in which you want to create a function.
3.  Select an object type and object.
For example, Synonyms.
4.  Select Assign owner from the overflow menu.
The* Assign owner* window appears and the current owner of the object is displayed.
5.  Choose an owner.
6.  Click Assign.







  Removing owners from object 

To drop an owner, you must be the object owner, the admin user, or have appropriate object privileges. If you don’t have the privilege, you can request your admin to grant it to you.



1.  Go to Databases.
2.  Select the database in which you want to create a function.
3.  Select an object type and object.
For example, Synonyms.
4.  Select Drop owner from the overflow menu.
5.  Click Drop.
This utility takes a number of parameters.



* /RU – the user to run the job as. This is needed if the user you want to use is logged out.
* /RP – the password for the user.
* /SC – set to DAILY
* /TN – the name of the job. Call it backup
* /TR – the path to the backup.bat file you created.
* /ST – the time to start the task. This is in the 24-hour time format. 01:05:00 is 1:05 AM. 13:05:00 would be 1:05 PM.





schtasks /Create /RU username /RP "password" /SC DAILY /TN Backup /TR C:pathtobackup.bat /ST 01:05:00





 Mac and Linux 



1. Create a text file called backup.sh somewhere on your computer, and paste the command that you used in the section [syncing a Directory](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-rclonerclone-sync-directory). It looks something like the following. Specify the full path to the rclone executable and don’t forget to save the file.



!/bin/sh
/full/path/to/rclone sync /path/to/my/backup/directory RemoteName:newbucket



2. Make the script executable with chmod.



chmod +x backup.sh



3. Edit crontabs.



sudo crontab -e



4. Add an entry to the bottom of the crontabs file. Crontabs are straight forward: the first five fields describe in order minutes, hours, days, months, and weekdays. Using * denotes all. To make the backup.sh run at Daily at 1:05 AM, use something that looks like this:



5 1 * * * /full/path/to/backup.sh



5. Save the crontabs and you’re ready to go.
Network setup for a cluster that runs internet-facing workloads



 Worker-to-worker communication in classic clusters with internet-facing workloads 

To achieve this setup, you create a cluster by connecting worker nodes to public and private VLANs.

If you create the cluster with both public and private VLANs, you can't later remove all public VLANs from that cluster. Removing all public VLANs from a cluster causes several cluster components to stop working. Instead, create a new worker pool that is connected to a private VLAN only.





 Worker-to-master and user-to-master communication in classic clusters with internet-facing workloads 

You can choose to allow worker-to-master and user-to-master communication over the public and private networks, or over the public network only.



* Public and private cloud service endpoints: Your account must be enabled with VRF and enabled to use service endpoints. Communication between worker nodes and master is established over both the private network through the private cloud service endpoint and the public network through the public cloud service endpoint. The master is publicly accessible to authorized cluster users through the public cloud service endpoint.
* Public service endpoint: If you don’t want to or can't enable VRF for your account, your worker nodes and authorized cluster users can automatically connect to the Kubernetes master over the public network through the public cloud service endpoint.







 Worker communication to other services or networks with internet-facing workloads 

Your worker nodes can automatically, securely communicate with other IBM Cloud services that support private cloud service endpoints over your IBM Cloud infrastructure private network. If an IBM Cloud service does not support private cloud service endpoints, workers can securely communicate with the services over the public network. You can lock down the public or private interfaces of worker nodes by using Calico network policies for public network or private network isolation. You might need to allow access to the public and private IP addresses of the services that you want to use in these Calico isolation policies.

If your worker nodes need to access services in private networks outside of your IBM Cloud account, you can configure and deploy the strongSwan IPSec VPN service in your cluster or leverage IBM Cloud IBM Cloud Direct Link services to connect to these networks.
[DevSecOps Tekton Pipeline](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/devsecops_set-up_cd_tekton_pipeline_orig.png)

Figure 14. DevSecOps Tekton Pipeline





 Deploy 

Configure the target Kubernetes cluster where the application is deployed. Choose the target Kubernetes cluster that you intend to use as the production or stage environment. The toolchain deploys the build application image to the cluster and runs the acceptance-test and other compliance checks.





 IBM Cloud API Key 

The API key is used to interact with the ibmcloud CLI tool in several tasks. If you created a cluster, an API to access the cluster and stored the key in a secure vault (any of Key Protect, Secrets Manager, or HashiCorp Vault), as prerequisite you can use the same in this step.

- Option-1: An existing key can be imported from an existing Secret Provider intance created as prerequisites (Key Protect Instance, Secret Manager Instance or HashiCorp Vault) by clicking the key icon (Recommended)
- Option-2: An existing key can be copy & pasted (Not Recommended)
- Option-3: A new key can be created from here by clicking New +. Generate a new api-key if you don’t have one or copy an existing key to the field.The newly generated API key can be immediately saved to an existing Key Protect instance

Click the Key icon to use an existing key from your Secret Provider.



* Provider: The Secret Provider that stores your API Key to access the cluster, as linked to your toolchain earlier. It can be a Key Protect Instance, Secret Manager Instance, or HashiCorp Vault Instance.
* Resource Group: Resource Group that the Secrets Manager Provider belongs.
* Secret name: Name or alias of the secret, that is, API Key.



When the API Key field is filled, the registry and cluster related fields are filled automatically.

Zoom

!
Why can’t I connect to my Elasticsearch deployment? 

If you encounter errors when connecting to your IBM Cloud® Databases for Elasticsearch deployment, review these common causes and resolutions.

You receive an error message or fail to connect to a Databases for Elasticsearch deployment. If reviewing application logs, you might see errors that mention intermittent connection timeouts or unable to connect.

Review the following information to troubleshoot and resolve common connectivity problems:



*  An unsecured connection is a common cause of connectivity errors. All Databases for Elasticsearch connections use TLS/SSL encryption; Databases for Elasticsearch rejects unsecured connections. To avoid errors, make sure you configured a secure connection. Refer to [Getting Started](https://cloud.ibm.com/docs/databases-for-elasticsearch?topic=databases-for-elasticsearch-getting-started) for an example of a secure connection.
*  If you are using a private endpoint, make sure that you specify connection strings that contain the private endpoint (see [Credentials for Private Endpoints](https://cloud.ibm.com/docs/databases-for-elasticsearch?topic=cloud-databases-service-endpointscredentials-for-private-endpoints)) and that you followed the steps in [Connecting through Private Endpoints](https://cloud.ibm.com/docs/databases-for-elasticsearch?topic=cloud-databases-service-endpointsprivate-endpoint-connections).
*  If your application log captures a short connection interruption, that behavior is expected as a normal part of operations for this managed service. You want to design your applications to retry connections when errors are caused by a temporary loss in connectivity to your deployment or to IBM Cloud. However, if you experience several minutes of connection interruption check the Cloud Status for the service. For more information, see [Application-level High-Availability](https://cloud.ibm.com/docs/databases-for-elasticsearch?topic=databases-for-elasticsearch-high-availabilityapplication-level-high-availability).
Why can’t I connect to my MongoDB deployment? 

If you encounter errors when connecting to your IBM Cloud® Databases for MongoDB deployment, review these common causes and resolutions.

You receive an error message or fail to connect to a Databases for MongoDB deployment. If reviewing application logs, you might see errors that mention intermittent connection timeouts or unable to connect.

Review the following information to troubleshoot and resolve common connectivity problems:



*  An unsecured connection is a common cause of connectivity errors. All Databases for MongoDB connections use TLS/SSL encryption; Databases for MongoDB rejects unsecured connections. To avoid errors, make sure you configured a secure connection. Refer to [Getting Started](https://cloud.ibm.com/docs/databases-for-mongodb?topic=databases-for-mongodb-getting-started) for an example of a secure connection.
*  If you are using a private endpoint, make sure that you specify connection strings that contain the private endpoint (see [Credentials for Private Endpoints](https://cloud.ibm.com/docs/databases-for-mongodb?topic=cloud-databases-service-endpointscredentials-for-private-endpoints)) and that you followed the steps in [Connecting through Private Endpoints](https://cloud.ibm.com/docs/databases-for-mongodb?topic=cloud-databases-service-endpointsprivate-endpoint-connections).
*  If your application log captures a short connection interruption, that behavior is expected as a normal part of operations for this managed service. You want to design your applications to retry connections when errors are caused by a temporary loss in connectivity to your deployment or to IBM Cloud. However, if you experience several minutes of connection interruption check the Cloud Status for the service. For more information, see [Application-level High-Availability](https://cloud.ibm.com/docs/databases-for-mongodb?topic=databases-for-mongodb-high-availabilityapplication-level-high-availability).
[Bridging Configuration Guide, 17.2.0](https://public.dhe.ibm.com/cloud/bluemix/network/vra/18_bridging_configuration_5600.pdf) This guide describes how to configure layer 2 bridging on AT&T products that run on the AT&T Vyatta Network Operating System. 
 [DMVPN Configuration Guide, 17.2.0](https://public.dhe.ibm.com/cloud/bluemix/network/vra/18_dmvpn_configuration_5600.pdf) This guide describes how to configure Dynamic Multipoint Virtual Private Network (DMVPN) on AT&T products that run on the AT&T Vyatta Network Operating System. 
 [Firewall Configuration Guide, 17.2.0](https://public.dhe.ibm.com/cloud/bluemix/network/vra/18_firewall_configuration_5600.pdf) This guide describes firewall functionality on the AT&T Vyatta vRouter. 
 [High Availability Configuration Guide, 17.2.0](https://public.dhe.ibm.com/cloud/bluemix/network/vra/18_high_availability_configuration_5600.pdf) This guide describes how to configure AT&T products that run on the AT&T Vyatta Network Operating System to provide high availability. 
 [IGMP and MLD Configuration Guide, 17.2.0](https://public.dhe.ibm.com/cloud/bluemix/network/vra/18_igmp_and_mld_configuration_5600.pdf) This guide describes how to configure Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) protocol on AT&T products that run on the AT&T Vyatta Network Operating System.