vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Yes, you can set up [WireGuard](https://www.wireguard.com/) or [OpenVPN](https://openvpn.net/) servers on IBM Cloud, and build your own VPN tunnels from on-premises to IBM Cloud.
* What is the process of installing MotionPro on Windows, Mac, or Linux?



1. Uninstall your current version of MotionPro (if applicable).
2. Restart your system.
3. Download and install the latest version of MotionPro.





Virtual Router Appliance



* What is a VRA?

A IBM Cloud® Virtual Router Appliance (VRA) allows an IBM Cloud® customer to selectively route private and public network traffic through a full-featured enterprise router with firewall, traffic shaping, policy-based routing, VPN, and a host of other features. All VRA features are customer-managed. VRA gives an IBM Cloud customer a degree of control that is normally reserved for on-premises networks.
* What is a gateway appliance?

With a gateway appliance fixture, you can use the web portal or API to choose network segments (VLANs) to route through a VRA. You can change VLAN selections at any time. The gateway appliance also handles VRA High Availability (HA), configuring a second VRA to take over if the first one fails.
* I sometimes see references to terms like "Vyatta" and "vRouter." How do they relate to VRA?

Vyatta was open source, PC-based router software that was acquired and transitioned to closed source. Today, "Vyatta" and "Vyatta OS" describe commercial software adaptations that are derived from that closed source project. IBM VRA incorporates elements of Vyatta OS, along with substantial feature and service enhancements available exclusively through IBM Cloud.

"vRouter" was a short-lived rebranding of Vyatta by its then-owner. When seen in documentation, it can be considered synonymous with Vyatta.
* Is Vyatta 5400 still supported?
Why is notification absent at the destinations? 

Notification is not received at the destinations.

  What’s happening 

Notification is not received at the destinations, for example: SMTP_IBM, SMS_IBM.

  Why it’s happening 

The most common cause would be that conditions (rules) written for the topic does not match with the incoming payload.

  How to fix it 

If you are using static events (event type, event subtype and severity)



*  When both event type and event subtype are provided, then type attribute of incoming payload must be a combination of the type and subtype filter. For example, if event type is bluemix.certificate_manager and event subtype is expiring_in_90_days then type attribute in the incoming payload would be bluemix.certificate_manager:expiring_in_90_days.

"type":"bluemix.certificate_manager:expiring_in_90_days"
*  When only event type is provided in the stated example, then type attribute would be bluemix.certificate_manager.

"type":"bluemix.certificate_manager"
*  When event type, event subtype and severity are provided, where event type is bluemix.certificate_manager, event subtype is expiring_in_90_days and severity is LOW then type would be bluemix.certificate_manager:expiring_in_90_days and severity would be LOW.

"type":"bluemix.certificate_manager:expiring_in_90_days",
"severity": "LOW"
*  Event type, event subtype, and severity are termed as event conditions. Additionally, user can provide advanced conditions.



If both event conditions and advanced conditions are provided, then both condition types must be satisfied for a notification to be routed to a topic.
Why do the service credentials in my service binding to IBM Cloud Object Storage show as REDACTED? 

When you create a Code Engine service binding with an IBM Cloud Object Storage service instance, the service credentials show as REDACTED.

  What’s happening 

After you create a service binding to an Object Storage instance and you use your own service credential, the service credentials for the binding to your Code Engine app or job shows as REDACTED in the environment variables, instead of showing the service credential values.

  Why it’s happening 

To retrieve existing service credentials, Object Storage requires that the user (or service ID) that retrieves the service credential must have the additional IAM action of resource-controller.credential.retrieve_all. This IAM action is included in the COS Reader or the Platform Administrator access role.

  How to fix it 

Try one of these solutions.



1.  Do not use custom service credentials when you create service bindings to Object Storage with Code Engine. Instead, use the default service binding access policies and let Code Engine generate the credentials for you. See [Using the default service binding access policies](https://cloud.ibm.com/docs/codeengine?topic=codeengine-configure-bindaccessbind-auto-servid).
2.  If you want to use a custom service ID with Code Engine service bindings, you must also add the COS Reader service access when you assign access for the service ID. See [Using a custom service ID for service bindings](https://cloud.ibm.com/docs/codeengine?topic=codeengine-configure-bindaccessbind-custom-servid).
Managing Cloud Foundry access 

To manage access to account organizations and spaces, you must be the account owner, organization manager, or space manager. Currently, not all services can be managed by using Cloud IAM. You can continue to use Cloud Foundry roles for access to these service instances. Users are added to the org and space to which the instance belongs with a Cloud Foundry role assigned. When Cloud Foundry services become IAM-enabled, they are eligible to be migrated to a resource group.

IBM Cloud Foundry Public is deprecated with an end-of-support date of 1 June 2023. For more information, see [Deprecation of IBM Cloud Foundry](https://cloud.ibm.com/docs/cloud-foundry-public?topic=cloud-foundry-public-deprecation).

The following graphic outlines how Cloud Foundry orgs, spaces, and roles relate within an account. An account can have many users, orgs, and spaces. Each user can be assigned to as many orgs and spaces as necessary. You can set the level of access to work within each org and space by assigning a Cloud Foundry role.

Zoom

![Access by using Cloud Foundry orgs and spaces in an account](https://cloud.ibm.com/docs-content/v1/content/4d8c6eec891cff72b666dc24bd3211810c77fb42/account/images/cf-diagram.svg)

Figure 1. How access in an account works by using Cloud Foundry orgs, spaces, and roles



 Cloud Foundry roles 

Cloud Foundry roles grant access to organizations and spaces within the account. Cloud Foundry roles do not enable user permissions for completing actions within the context of a service across the account.

Cloud Foundry access is assigned by adding a user to an org and space, and then assigning an org role and space role. Depending on the type of role that is assigned, that user can complete specific actions for service instances that are added to a particular space.

Zoom

!
Managing Cloud Foundry access 

To manage access to account organizations and spaces, you must be the account owner, organization manager, or space manager. Currently, not all services can be managed by using Cloud IAM. You can continue to use Cloud Foundry roles for access to these service instances. Users are added to the org and space to which the instance belongs with a Cloud Foundry role assigned. When Cloud Foundry services become IAM-enabled, they are eligible to be migrated to a resource group.

IBM Cloud Foundry Public is deprecated with an end-of-support date of 1 June 2023. For more information, see [Deprecation of IBM Cloud Foundry](https://cloud.ibm.com/docs/cloud-foundry-public?topic=cloud-foundry-public-deprecation).

The following graphic outlines how Cloud Foundry orgs, spaces, and roles relate within an account. An account can have many users, orgs, and spaces. Each user can be assigned to as many orgs and spaces as necessary. You can set the level of access to work within each org and space by assigning a Cloud Foundry role.

Zoom

![Access by using Cloud Foundry orgs and spaces in an account](https://cloud.ibm.com/docs-content/v1/content/1e0945ee44f87283927af9404a8f2d077786db0c/cloud-foundry-public/includes/account/includes/account/images/cf-diagram.svg)

Figure 1. How access in an account works by using Cloud Foundry orgs, spaces, and roles



 Cloud Foundry roles 

Cloud Foundry roles grant access to organizations and spaces within the account. Cloud Foundry roles do not enable user permissions for completing actions within the context of a service across the account.

Cloud Foundry access is assigned by adding a user to an org and space, and then assigning an org role and space role. Depending on the type of role that is assigned, that user can complete specific actions for service instances that are added to a particular space.

Zoom

!
Managing Users and Permissions 

IBM Cloud® Messages for RabbitMQ uses RabbitMQ's [built-in access control](https://www.rabbitmq.com/access-control.htmlpermissions).

When you provision a new deployment in IBM Cloud, you are automatically given an admin user to access and manage RabbitMQ. You can also add users in the Service Credentials panel, which allows for access to RabbitMQ to be integrated with your IBM Cloud account and [IAM](https://cloud.ibm.com/docs/messages-for-rabbitmq?topic=cloud-databases-iam).

Since Messages for RabbitMQ comes with the RabbitMQ Management plug-in enabled, users' access is also controlled by [user tags](https://www.rabbitmq.com/management.htmlpermissions). These tags control what information is available to users through the management UI, rabbitmqadmin, and the RabbitMQ HTTP API.



 The admin user 

Every RabbitMQ deployment comes with an admin user. This admin user had full administrative privileges on your RabbitMQ deployment. Before you log in with the admin user, you need to [set its password](https://cloud.ibm.com/docs/messages-for-rabbitmq?topic=messages-for-rabbitmq-admin-password).

The primary difference between the admin user and any other users you add to your deployment is the ability to provision new vhosts and manage all other users' permissions and access.

It is the only user that is initially granted access to all the settings and configuration that is found in the Admin tab in the management UI.





 Service Credential Users 

Users that you [create through the Service Credentials panel](https://cloud.ibm.com/docs/messages-for-rabbitmq?topic=messages-for-rabbitmq-connection-stringsfrom-_service-credentials_) are given full permissions to configure, write, and read on the default Virtual Host.
For more information, see [Configuring ACLs and security groups for use with VPN](https://cloud.ibm.com/docs/vpc?topic=vpc-acls-security-groups-vpn).
* Does VPN for VPC support high-availability configurations?

Yes, VPN for VPC supports high availability in an Active-Standby configuration for policy-based VPNs, and Active-Active configuration for a static, route-based VPN.
* Are there plans to support SSL VPN?

No, only IPsec site-to-site is supported.
* Are there any caps on throughput for site-to-site VPNaaS?

Up to 650 Mbps of throughput is supported.
* Is Pre-Shared Key (PSK) and certificate-based IKE authentication supported for VPNaaS?

Only PSK authentication is supported.
* Can you use VPN for VPC as a VPN gateway for your IBM Cloud classic infrastructure?

No. To set up a VPN gateway in your classic environment, you must use an [IPsec VPN](https://cloud.ibm.com/catalog/infrastructure/ipsec-vpn).
* What does rekey collision cause?

If you use IKEv1, rekey collision deletes the IKE/IPsec security association (SA). To re-create the IKE/IPsec SA, set the connection admin state to down and then up again. You can use IKEv2 to minimize rekey collisions.
* Is it possible to view logs from the VPN gateway for debugging purposes?

Yes. You can find more information in [Using IBM Log Analysis to view VPN logs](https://cloud.ibm.com/docs/vpc?topic=vpc-using-log-analysis-to-view-vpn-logs).
* How can I send all traffic from the VPC side to the on-premises side in a policy-based VPN?

To send all traffic from the VPC side to the on-premises side, set peer CIDRs to 0.0.0.0/0 when creating a connection.
Enter an appropriate name for the scheduled action.
6. Click Recurring.
7. Select a date and time to run the scheduled action by using the predefined options for each pattern section (Monthly, Days, Hours, Minutes). Or choose a custom schedule by clicking what months, days, hours, and minutes that you want the schedule to run. \n Alternatively, you can select a date and time schedule by entering a cron expression. Click Cron and enter an appropriate cron expression.
8. If your instance group is dynamic, enter a minimum and or maximum instance group size to apply when this action runs. If your instance group is static, enter the instance group size to apply when this action runs.
9. Click Create.



24 hours after a scheduled action reaches a final status, such as Completed, Omitted, or Failed, the action is marked for deletion.







 Creating a scheduled action with the CLI 

You can create a scheduled scaling action for your auto-scaled instances by using the IBM Cloud CLI.



 Before you begin 

Make sure that you set up your IBM Cloud® CLI environment and your IBM Cloud VPC.

To create a scheduled action by using the CLI, you must complete the following steps:



1. Make sure that you have the required IBM Cloud Identity and Access Management (IAM) permissions to create instance group resources. For more information, see [Required permissions for VPC resources](https://cloud.ibm.com/docs/vpc?topic=vpc-resource-authorizations-required-for-api-and-cli-calls).
2. Create scaling policies to dynamically add or remove instances from your group based on the target utilization metrics that you define.







 Create a scheduled action 

Use the following command to create a scheduled action.

ibmcloud is instance-group-manager-action-create INSTANCE_GROUP MANAGER [--run-at RUN_AT | --cron CRON] [--membership-count MEMBERSHIP_COUNT | (--max-members MAX_MEMBERS --min-members MIN_MEMBERS)] [--name NAME] [--output JSON] [-q, --quiet]
Be aware that you need an "IBM Sponsor" (for example, an IBM employee that works as main contact between you and the IBMid team).

[IBM Cloud Self-Service Federation for External Identity Providers](https://www.ibm.com/cloud/blog/announcements/ibm-cloud-self-service-federation-for-external-identity-providers)
: Announcement for the IBM Cloud IAM feature to federate with an Identity Provider through SAML using IBM Cloud App ID.

[Enabling authentication from an external identity provider](https://cloud.ibm.com/docs/account?topic=account-idp-integration)
: Follow the steps necessary to integrate an IBM Cloud App ID service instance with IBM Cloud IAM so that your users can use your IBM Cloud account without creating IBMids. Review the section Setting IAM-specific attributes in App ID tokens to make sure that your users are correctly onboarded and displayed inside your IBM Cloud account.

[Control access to cloud resources](https://developer.ibm.com/tutorials/use-iam-access-groups-to-effectively-manage-access-to-your-cloud-resources/)
: This tutorial describes how to use Dynamic Rules in Access Groups so that you automate permission assignments based on attributes that your Identity Provider is sending to IBM Cloud via SAML. The tutorial itself was written for IBMid federation, but the same concept and steps also work with IBM Cloud App ID based federation.

[Using App ID instances to build dynamic rules in access groups](https://cloud.ibm.com/docs/account?topic=account-idp-integrationapp-id-dynamic-rules)
: In case you plan to use dynamic rule with IBM Cloud App ID-based federation, make sure to use the correct syntax for the "Identity Provider" setting inside the Dynamic Rule. The section in the link is describing how to build the correct "Identity Provider" identifier.

[Setting up IBM Cloud App ID with your Active Directory Federation Service](https://www.ibm.com/cloud/blog/setting-ibm-cloud-app-id-active-directory-federation-service)
: A description of how to set up an IBM Cloud App ID instance with Microsoft Active Directory.
* [IBM Cloud IAM platform access roles](https://cloud.ibm.com/docs/containers?topic=containers-access_referenceiam_platform)
* [IBM Cloud IAM service access roles](https://cloud.ibm.com/docs/containers?topic=containers-access_referenceservice)
* [Kubernetes resource permissions per RBAC role](https://cloud.ibm.com/docs/containers?topic=containers-access_referencerbac_ref)



The following image shows the different types of permissions and roles, the actions a role can perform, and how the roles relate to each other.

![user access permissions](https://cloud.ibm.com/docs-content/v1/content/b7b9235ce6abd45b66931867c388cf107d38e15b/cloud-native-journey/kubernetes-on-vpc/images/prepare-account/user_access.png)

Additionally, check [getting started with IAM and Virtual Private Cloud (VPC)](https://cloud.ibm.com/docs/vpc?topic=vpc-iam-getting-started).





 Next Steps 

The next step on the deployment journey is:



* [Provision a cluster](https://cloud.ibm.com/docs/cloud-native-journey?topic=cloud-native-journey-cloud-native-provision-cluster)
Other services like Data Engine need to access buckets to perform data analysis. And yet another category of services need access to subscribe to change notifications to trigger the execution of actions.
* [Event Notifications](https://cloud.ibm.com/docs/event-notifications?topic=event-notifications-getting-started): To push out information about events to subscribers, service instances need to access an Event Notifications instance.
* [Secrets Manager](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-getting-started): This service stores and provides to other services IAM API keys, SSL/TLS certificates, and other secrets. Hence, the dependent (source) services need to access Secrets Manager.
* [Cloud Internet Services (CIS)](https://cloud.ibm.com/docs/cis?topic=cis-getting-started): It manages domain names and other network data and, therefore, can be used for, e.g., certificate validation.



Note that the above list is not complete.









 Summary 

Accessing resources in different accounts, even sharing resources is common practice. There are several use cases where users benefit from resource sharing. They were discussed in the overview. A combination of user identity and password or an API key to access a resource often serves as authentication. Access can be scoped to a set of privileges, e.g., only allowing read access or some other restricted actions. Sometimes, these type of credentials can be created and managed by the accessing resource like an application or compute environment ("service binding"). An even tighter integration which does not require credentials is the concept of IBM Cloud service-to-service authorization. The accessing resource (source) and the accessed resource (target) are identified by their properties (authentication) and an access role is assigned (authorization). Such a relationship can be even established across account boundaries. This allows for a simple to configure, but yet secure cross-account resource sharing.



Summary of sharing and reuse capabilities across services

 Service Capability 

 Security and Observability
* [IBM Cloud IAM platform access roles](https://cloud.ibm.com/docs/containers?topic=containers-access_referenceiam_platform)
* [IBM Cloud IAM service access roles](https://cloud.ibm.com/docs/containers?topic=containers-access_referenceservice)
* [Kubernetes resource permissions per RBAC role](https://cloud.ibm.com/docs/openshift?topic=openshift-access_reference&interface=uirbac_ref)



The following image shows the different types of permissions and roles, the actions a role can perform, and how the roles relate to each other.

![user access permissions](https://cloud.ibm.com/docs-content/v1/content/b7b9235ce6abd45b66931867c388cf107d38e15b/cloud-native-journey/roks-on-vpc/images/prepare-account/user_access.png)

Additionally, check [getting started with IAM and Virtual Private Cloud (VPC)](https://cloud.ibm.com/docs/vpc?topic=vpc-iam-getting-started).





 Next Steps 

The next step on the deployment journey is:



* [Provision a cluster](https://cloud.ibm.com/docs/cloud-native-journey?topic=cloud-native-journey-cloud-native-roks-provision-cluster)
IBM Cloud IAM roles 

All services that are organized in a resource group in your account are managed by using IBM Cloud Identity and Access Management (IAM). Account owners are automatically assigned the account administrator role. As the account administrator, you can assign and manage access for users, create resource groups, create access groups, create trusted profiles, view billing details and track usage, and create service instances. You provide access for users, service IDs, access groups, and trusted profiles by creating policies that set a target for the subject of the policy to access and a role that defines what type of access that is allowed.



 IAM roles 

You can manage and define access based on specific roles for users and resources in your account.



* Platform management roles cover a range of actions, including the ability to create and delete instances, manage aliases, bindings, and credentials, and manage access. The platform roles are administrator, editor, operator, viewer. Platform management roles also apply to [account management services](https://cloud.ibm.com/docs/account?topic=account-account-servicesaccount-management-actions-roles) that enable users to invite users, manage service IDs, access policies, catalog entries, and track billing and usage depending on their assigned role on an account management service.
* Service access roles define a user or service’s ability to perform actions on a service instance, such as accessing the console or performing API calls. The most common service access roles are manager, writer, and reader. Each service maps particular actions for working with the service to each of these roles.

You might not see all of the roles that are listed here as options when you assign policies in the UI because only the roles available for the service that you chose are displayed. For more information on what roles are enabled and what actions each access role allows for each service, see the documentation for that service.
* Custom roles for a service can be created on the IAM Roles page by the account owner or a user assigned the administrator role on the role management service.

You can review the available roles and associated actions for a particular service by going to the [Roles](https://cloud.ibm.com/iam/roles) page, and selecting the service that you want to learn more about.