vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Managing logging instances in the Observability UI 

You can manage your logging instances through the Observability dashboard in IBM Cloud.



 Launch the logging UI 

Complete the following steps to launch the logging web UI:



1. [Log in to your IBM Cloud account](https://cloud.ibm.com/login).
2. Click the Menu icon ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/f61dbc5d84bf0c89e477a05cab04c72f429e1b7a/icons/icon_hamburger.svg) > Observability.
3. Click Logging to go to the Logging UI.

The list of instances that are available on IBM Cloud is displayed.







 Managing logging instance 

In the Logging UI, you can manage your logging instances.



* You can view all instances across all locations. You can also specify 1 location and view the instances that are available in that location.
* You can view all instances across all the resource groups in your account. You can also select 1 resource group and view the instances that are available in that resource group.
* You can configure the instances in your account to collect platform logs. [Learn more](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-config_svc_logs).
* You can create instances. [Learn more](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-provision).



For each instance, you can view the following information:



* The status of an instance
* The resource group that is associated with an instance
* The region where the instance is provisioned
* The instances that are configured to collect automatically platform logs
* The service plan of an instance



You can also view sources. If you select Add log sources for an instance, a new page opens where you can find instructions on how to configure logging agents to forward logs to this instance.

You might see the Add log sources disabled.
Enabling TLS security for MQ channels in MQ on Cloud 

MQ on Cloud queue managers older than version 9.2.1 revision 2 were configured by default without TLS security. Later versions have TLS security on administration and application channels. This guide explains TLS security and allows you to upgrade earlier queue managers to the same security level as the newer ones. The later sections show how to download the required certificates for applications to connect to your queue manager.

The application or administration software needs to trust a public certificate for the MQ on Cloud queue manager certificate. This can be the issuer certificate, or the individual queue manager certificate. Both are available for download from the MQ on Cloud service console.

You will need to gather some data from your MQ on Cloud queue instance:



1. The administration user's username and password.
2. An application user's username and password.
3. The certificate chain ending in the queue manager certificate, starting from the root CA certificate.
4. The description of the queue manager formatted in JSON (called CCDT data).



The following paragraphs will guide you through gathering the data from the MQ on Cloud console, and will also guide you through the process of setting up a keystore to manage trusted public certificates on your local machine. Subsequent pages linked from the end of this document will show you how to remotely administer using TLS, and also how to connect the C and JMS MQ samples to the queue manager.

The following description will be altering the CLOUD.ADMIN.SVRCONN channel - this will allow the administrator to connect securely. Similarly, we will alter the CLOUD.APP.SVRCONN channel, which will be used by applications such as the C or JMS samples.

You will need access to the MQ tools for your operating system (for example runmqakm). These are part of an MQ installation on Linux and Windows, and have recently been made available in the [MacOS toolkit for Developers](https://developer.ibm.com/components/ibm-mq/tutorials/mq-macos-dev/).
Best practices for assigning access 

After you set up your enterprise and account structure within the enterprise, you're ready to start planning how you want to organize resources and assign access to identities. These best practices provide you with the basic building blocks to enable successful and secure app development in IBM Cloud®.



 How IAM access works 

After you set up and organize resource groups in your account, you can take advantage of a couple of strategies to streamline the access management process:

Access groups
: You can minimally manage the number of assigned policies by giving the same access to all identities in an access group instead of assigning the same access multiple times per individual user, service ID, or trusted profile. Users must be invited to your account before you can add them to an access group. If a user qualifies for a trusted profile that is a member of the access group, you don't need to invite them to your account.

Trusted profiles
: If your organization has an enterprise directory, trusted profiles can reduce the time and effort to manage access. It simplifies the login process to your IBM Cloud account for federated users in your enterprise. You can automatically grant federated users or compute resources access to your account by creating trusted profiles. For federated users, add conditions based on SAML attributes to define which federated users can apply a profile. For compute resources, specify specific resources, or add conditions based on resource attributes to define which compute resources can apply a profile. For both entity types, the level of access that is granted is determined by the access policies that are specified within each trusted profile, or the access groups that the trusted profile is a member of. However, trusted profiles don't require federated users to be invited to an account, and only users that are federated by an external identity provider (IdP) can apply a trusted profile.

When you're a member of multiple access groups, all policies apply at once when you access an account. As a federated user, you might have the option to apply different trusted profiles, but you select just one profile to apply when you log in. For example, if you want to complete developer-related tasks, select the Developer profile when you log in.
The decision to federate to your company's own directory needs to involve the person in your company that can make company-wide decisions when it comes to connecting to external parties for identity services. You need to ensure that this person is included in the process. Federating with IBMid can have an impact on web services that your company already uses with IBM.<br> * Federate with App ID and your IdP: This option requires the creation of an App ID instance. It is a self-service option with a low-usage fee. Choosing this option requires a custom URL to log in to IBM Cloud. In addition, an App ID instance and configuration of the federation to your IdP is required for every IBM Cloud account.<br><br><br><br>For a deeper dive, use the following guides and documentation:<br><br><br><br> * [IBM Cloud SAML Federation Guide](https://www.ibm.com/cloud/blog/ibm-cloud-saml-federation-guide)<br> * [IBM Cloud login sequences](https://cloud.ibm.com/docs/account?topic=account-account-getting-startedsignup-federated).<br><br><br><br>Use the following documentation topics when you are ready to federate:<br><br><br><br> * [IBMid Enterprise Federation Adoption Guide](https://www.ibm.com/docs/en/ief)<br> * [Enable authentication from an external identity provider using App ID](https://cloud.ibm.com/docs/account?topic=account-idp-integration).<br><br><br> 
 <br><br> * Activate a subscription code<br><br><br> With an IBM Cloud subscription, you get discounted usage for platform services and support by committing to a minimum spending commitment for a certain period of time. After you buy a subscription for platform or support credit, you must add the credit to your account by applying a subscription code to your stand-alone account or enterprise. Applying the code ensures that the credit is added to your account, and you don't have unexpected overage charges.
The following example shows how you can reference values from your secret as environment variables in the container spec section of your deployment YAML. You can also mount the secret as a volume. By referencing values from your secret, you can decouple this configuration information from your deployment to keep your containerized app portable.



* [Help me decide whether to use a Kubernetes ConfigMap or Secret object for variables](https://cloud.ibm.com/docs/containers?topic=containers-plan_deployvariables).
* To create a secret, see the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/secret/).



For centralized management of all your secrets across clusters and injection at application runtime, try [IBM Cloud Secrets Manager](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-tutorial-kubernetes-secrets).

apiVersion: apps/v1
kind: Deployment
metadata:
name: wasliberty
spec:
replicas: 3
template:
...
spec:
...
containers:
- name: wasliberty
...
env:
- name: username
valueFrom:
secretKeyRef:
name: wasliberty
key: username
- name: password
valueFrom:
secretKeyRef:
name: wasliberty
key: password
...
---
apiVersion: v1
kind: Secret
metadata:
name: wasliberty
labels:
app: wasliberty
type: Opaque
data:
username: dXNlcm5hbWU=
password: cGFzc3dvcmQ=
Show more





 Persistent volumes for container storage 

Persistent volumes (PVs) interface with physical storage to provide persistent data storage for your container workloads.

The following example shows how you can add persistent storage to your app.
Onboarding a Terraform template by using the CLI 

This tutorial walks you through how to onboard a Terraform template to your account by using the CLI. By completing this tutorial, you learn how to create a private catalog and import the template. After that, you can validate that the template can create resources, or run a script, and you can make it available to users who have access to your account.



 Before you begin 



1. Verify that you're using a Pay-As-You-Go or Subscription account. See [Viewing your account type](https://cloud.ibm.com/docs/account?topic=account-account_settingsview-acct-type) for more details.
2. Upload your source code to a release in your GitHub or GitLab repository. See [Setting up your source code repository](https://cloud.ibm.com/docs/sell?topic=sell-source-repo-setup).
3. Make sure you're assigned the following [IAM access](https://cloud.ibm.com/docs/account?topic=account-groups):



* Editor role on the catalog management service
* Viewer role on all resource groups in your account
* Writer role on the Secrets Manager service



4. Install the IBM Cloud CLI and the IBM Cloud Schematics plug-in. See [Setting up the CLI](https://cloud.ibm.com/docs/schematics?topic=schematics-setup-cli) for more information.
5. Create your [Terraform template](https://cloud.ibm.com/docs/schematics?topic=schematics-create-tf-config).



1. Review the list of [supported images](https://cloud.ibm.com/docs/vpc?topic=vpc-about-images).
2.
* Users can collaborate on resources and services within an individual account only. Resources can't be moved between accounts.







 Setting up access policies in an enterprise 

As always, follow the best practice for assigning the minimal number of access policies and levels of access. By using these techniques, you spend less time assigning access to users and more time on developing in IBM Cloud while ensuring that you don't provide too much access to users who don't need it.

Access groups are a useful tool for assigning access to a group of users and service IDs that all need the same access. By using access groups, you can streamline access management by assigning the minimal number of access policies to groups of users. As an example, if you have five users that you want to manage all of the billing and account management-related tasks for the enterprise, you can add them to an Administrators access group. In the access group, you can assign two policies: one with the administrator role on the Billing account management service and one with the administrator role on all account management services in the account. As users change job responsibilities or teams, you can add or remove users from the access group instead of adding or removing the same policies from the individual users. See [Assigning enterprise access](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-assign-access-enterprise) for more information.





 Working with resources in an enterprise 

Create resources only in child accounts that you import or create within the enterprise. Although it's possible to create resources within the enterprise account, it's not a best practice for the following reasons:



* The enterprise account is always a direct child of the enterprise and can't be moved, so you won't have the flexibility to change how usage is reported for the resources.
* The enterprise account contains the users and access for managing the enterprise and its billing, so only users with those responsibilities should be added to the account.



Users within each account in the enterprise can create, use, and collaborate on resources just as you can in a stand-alone account. For details, see [Managing resources](https://cloud.ibm.com/docs/account?topic=account-manage_resource).
The account selector displays the account name and account number.
* How can I join accounts?

The account owner, organization manager, or a user with the correct permissions can invite you to join their account.



* If you're new to IBM Cloud®, you receive an email that contains all the information you need.
* As an existing member of IBM Cloud®, you can accept the invitation in your notifications, by email, or by using the CLI to onboard to the new account. To accept invitations in the CLI, use the [ibmcloud login](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_cliaccept-invitation-to-join-a-new-account-) command.



* Can I switch between multiple accounts?

If you have access to more than one account, you can click your account name in the console menu bar to switch to another account.

![A screen capture of the account selector in the console menu bar. The account selector displays the account name and account number, and you select the current account to display a list of other accounts that you can access.](https://cloud.ibm.com/docs/images/account-faq.svg)

Figure 2. Account selector displays all accounts to which you have access
* Can I move data between IBM Cloud accounts?

Data can't be directly migrated from one IBM Cloud account to another. But, you might be able to re-create configurations and add them to another account. Consider the following approaches:



* Save your applications and replicate them in different accounts by using GitHub or another code repository.
* Review the applicable documentation to determine whether your infrastructure services can be backed up and re-created in different accounts.
* Use manifests and other documented methods to rebuild your applications and services by using documented methods to back up and restore your data.



Users with a Basic, Advanced, or Premium support plan can open a [Support case](https://cloud.ibm.com/unifiedsupport/supportcenter) for assistance with data migration questions.
* Can I bookmark a console page for a specific account?
Consider connecting the Monitoring agent over the private network.





 Setting up private service endpoints 

Private network endpoints support routing services over the IBM Cloud private network instead of the public network. A private network endpoint provides a unique IP address that is accessible to you without a VPN connection.



 Step 1: Enabling your account 

If you want to use connections over the public internet, you do not have to enable Service Endpoints on your IBM Cloud account.

To use private network endpoints, you must enable the Virtual routing and forwarding (VRF) account feature.

You must first enable virtual routing and forwarding in your account, and then you can enable the use of IBM Cloud private service endpoints.



* To enable VRF, you create a support case.
* To enable service endpoints, you use the IBM Cloud CLI. For more information about how to enable your account, see [Enabling VRF and service endpoints](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpoint).







 Step 2: Enforcing API calls through private endpoints 

After your account is enabled for VRF and service endpoints, you can configure a Monitoring instance to only allow API calls through the private endpoints.

After you provision an instance of the Monitoring service, you can use the following CLI command to update the instance configuration and enforce private endpoints for all API commands:

ibmcloud resource service-instance-update <my-service-instance> --service-endpoints 'private'

Or you can use the [Resource Controller API](https://cloud.ibm.com/apidocs/resource-controller), with a PATCH request to the [/resource_instances/{id}](https://cloud.ibm.com/apidocs/resource-controllerupdate-a-resource-instance) endpoint.

After you enable private endpoints, the API calls that are made through a public endpoint are rejected.





 Step 3: Configuring a Monitoring agent to connect through private endpoints 

After your account is enabled for VRF and service endpoints, you can configure a Monitoring agent to connect to an IBM Cloud Monitoring instance through the private network.
Ordering Direct Link Dedicated on Classic 

As you prepare to order Direct Link on Classic, review the general process that your organization follows for obtaining the Dedicated service, including the locations where each service is available, globally. When you're ready to place your order, follow the step-by-step instructions.

The colocation or Network Service Provider (NSP) does not need to be an IBM Cloud Direct Link Business Partner to connect you to a Direct Link Dedicated service.

To determine which Direct Link solution is best for your networking environment, see [How do I know which Direct Link solution to order?](https://cloud.ibm.com/docs/direct-link?topic=direct-link-get-started-with-ibm-cloud-direct-linkget-started-solution-to-order)

You can choose from the following two options.



 Option 1 - Colocated in an IBM Cloud PoP or data center 



1. Verify your colocation provider's capabilities to reach the appropriate Meet Me Room and cross-connect into the IBM Cloud environment.
2. Use the [IBM Cloud console ![External link icon](https://cloud.ibm.com/docs-content/v1/content/icons/launch-glyph.svg)](https://cloud.ibm.com/login) to order Direct Link Dedicated on Classic and complete the requested information. You can request assistance from IBM Cloud Sales engineers. When you are ready to create your order, you are prompted to read and agree to the [Direct Link Dedicated prerequisites](https://cloud.ibm.com/docs/direct-link?topic=direct-link-ibm-cloud-dl-dedicated-prerequisites).
3. IBM Cloud provides Letters of Authorization (LOA) for connections that use IBM Cloud. When you have the LOA, supply it to your colocation provider, then have them order a cross connect (and any required inter-campus connectivity) by using the IBM Cloud CFA (Customer Facility Assignment) information in the LOA.

This process usually takes 2 - 10 business days to complete, depending on the facility vendor and the order priority you specify. It includes the setup of the patch for the IBM Cloud termination port.
* Private VLAN number and the Data Center in which it is created. You use this network information when you establish network connectivity to IBM Cloud Private network space.
* The devices configured under this VLAN. This list includes all the ESXi hosts and Citrix DaaS components like Cloud Connectors and Active Directory. Click any of the links to view the server details.
* /24 portable subnet with 256 IP addresses that is created per your Citrix DaaS order. You need to create VMs on this portable subnet. Multiple portable subnets are shown.
* Storage details like NFS.





You can search for details about your server on the Classic infrastructure Resource List page. Your Citrix DaaS servers are provisioned with two tags: CVAD and Resource location name. The resource location name is the name that you provided during the ordering process. To verify that your servers are provisioned, use these tags to filter for the servers in the Resource List page.





 Step 2: (Optional) Provision a virtual server instance for management 

You can provision a virtual server instance with a Windows operating system to manage your Citrix DaaS for IBM Cloud for IBM Cloud. You can use a jump box to start a Remote Desktop session to access the Active Directory server and Citrix Cloud Connectors. You can also add vCenter and esxi details in the hosts files for name resolution.

You must provision the virtual server instance with the same network details as the other service components that are attached to the resource location.





 Step 3. Establish network connectivity for Active Directory Topology 



 IBM Cloud 

If you chose IBM Cloud Active Directory topology and are using the Active Directory in IBM Cloud as your only domain controller, no further network configuration is required. The Cloud Connectors are joined to the Active Directory server domain and are configured to communicate with Citrix Cloud. You might have to create users with the necessary privileges. You can also create bulk users in Active Directory. For more information, see this step-by-step guide on how to [Create bulk users in Active Directory](https://activedirectorypro.com/create-bulk-users-active-directory/).





 Extended (Multisite) 



1.
The IBM Cloud Kubernetes Service up to release 1.18 relies on unique usernames in an account. To work correctly, you must ensure that all usernames are unique across all IdPs. This means that you must make sure that the usernames that are onboarded to your account from IBMid and users that are onboarded to your account by an IAM IdP don't overlap. Otherwise, the IBM Cloud Kubernetes Service RBAC rules might get confused and give incorrect permissions.

If you are working with an external IdP, it is recommended that you connect with one external IdP only and let users onboard automatically through this IdP.

Don't invite users by using the IBM Cloud invite process since this works only for users with IBMids. If you used IBM Cloud invites for your account, you would end up with a mixture of users coming from IBMid and users being automatically onboarded from your external IdP. This can easily lead to confusion because IBMid users log in through the IBM Cloud website while users from your external IdP must log in with a special URL. This can lead to duplicate usernames in one account, which is strongly discouraged due to limitations in the Kubernetes Service as previously mentioned.





 Using IdP data to build trusted profiles 

After you have enabled and connected your IdP, you can start [creating trusted profiles](https://cloud.ibm.com/docs/account?topic=account-create-trusted-profile). To build trust with federated users, you can use the personal data from your IdP to search attribute names and values that exist in your organization.

If the users that you are creating a trusted profile for use IBM Cloud App ID, you should create the trusted profile as an IBM Cloud App ID user, and likewise for IBMid. This way, your own SAML attributes can give you an idea of how to structure the trusted profile conditions. Other users with the same IdP can have different SAML attributes and you should use your own only as a hint. To use attributes in a claim that are different than your own, input them manually.

The conditions that you create filter out or allow federated users to apply the trusted profile depending on which attributes the federated users are assigned in your corporate user directory.