vania-janet/multiturn-rag-retrieval-data huggingface dataset:
In the hierarchy, the top domain is known as the parent domain, and has one or more child domains that are linked to it.
* Child domains - These domains link to a parent domain and inherit the address space of the parent, so the child is a subdomain. A child to one domain can also be the parent to other domains. A child domain name always includes the complete parent domain name. A child domain and its parent share a two-way transitive trust.
* Global catalog - A global catalog server is a domain controller that stores partial copies of all Active Directory objects in the forest. It stores a complete copy of all objects in the directory of the domain and a partial copy of all objects of all other forest domains. Users and administrators can find directory information regardless of which domain in the directory contains the data. It is replicated to every domain controller that is a member of that forest.
* AD Sites - In AD, a site represents a physical or logical entity that is defined on the domain controller. Each site is associated with a domain. Each site also has IP definitions of what IP addresses or ranges belong to that site. Domain controllers use site information to inform AD clients about domain controllers present within the closest site to the client.
* Site Links - Site links are used to establish links between AD sites. By configuring the site link properties such as schedule, replication cost, and interval, inter-site replication can be managed.
* Trust - A trust relationship is a logical relationship that is established between domains to allow authentication and authorization to shared resources. The authentication process verifies the identity of the user, and the authorization process determines what the user is allowed to do on a computer system or network.
* Directory - AD uses a structured data store as the basis for a logical, hierarchical organization of directory information. This data store, also known as the directory, contains information about AD objects. These objects typically include shared resources such as servers, volumes, printers, and the network user and computer accounts.
* Replication - A service that distributes directory data across a network. All domain controllers in a domain participate in replication and contain a complete copy of all directory information for their domain. Any change to directory data is replicated to all domain controllers in the domain.
git clone https://github.com/OpenVPN/easy-rsa.git
cd easy-rsa/easyrsa3
2. Create a Public Key Infrastructure (PKI) and Certificate Authority (CA):

./easyrsa init-pki
./easyrsa build-ca nopass

Check that the CA certificate is generated at path ./pki/ca.crt.
3. Generate a VPN server certificate:

./easyrsa build-server-full vpn-server.vpn.ibm.com nopass

Check that the VPN server public key is generated at path ./pki/issued/vpn-server.vpn.ibm.com.crt, and that the private key is at path ./pki/private/vpn-server.vpn.ibm.com.key.
4. Generate a VPN client certificate:

./easyrsa build-client-full client1.vpn.ibm.com nopass

Check that the VPN client public key is generated at path ./pki/issued/client1.vpn.ibm.com.crt, and that the private key is at path ./pki/private/client1.vpn.ibm.com.key.
5. If you need to create more VPN client certificates, repeat step 4.



Important considerations:



* In the preceding example, the VPN server and client certificates are signed by the same CA. To use different CAs to sign the client certificate, copy the easyrsa3 folder into a new path and follow steps 2 and 4.
* If you already have the VPN server certificate from other CAs, make sure that the certificate has the Extended key usage: TLS Web Client Authentication. You can use the following command to check the certificate information based on content of the encoded certificate file: cat YOUR-CERTIFICATE-FILE | openssl x509 -noout -text.
* If the certificate is used as the VPN client certificate to authenticate the client, you must upload the Certificate file and the Intermediate certificate file.
About Data Transfer Service 

With IBM Cloud® Data Transfer Service, you can send a USB 2.0 or 3.0 compatible device to a IBM Cloud data center to be connected directly to your network. The device is housed in a dedicated rack and is mounted as an iSCSI target. Advanced Format drives are now supported as well.



 Hardware requirements 



* Device must have a power supply that is 208v/220v compatible.
* Device must have a power plug that fits a standard 120v socket (NEMA 5-15P).
* Device must be USB 2.0 compatible (3.0 is now supported as well).
* Device must come with USB cable with USB A Male connector (standard plug that fits most computers).

Encrypted USB devices that require support for proprietary encryption software are not supported for data transfer.







 Pricing 



1. Initial request for service = $0
2. First two weeks of data transfer = $0

$25 per week is charged for extension.
3. Shipping cost to and from the IBM® data center including paying any duties and taxes.



As the Client, you are responsible for:



* Ensuring no import or export license is required to send the Device to the IBM® data center, or to return it to Client (if applicable).
* Ensuring that Client or any Client user whose data is included in the Content is not subject to any US Government order that revokes or denies their US export privileges. Notify IBM® immediately if Client or any such user becomes subject to any such order.
* Obtaining all licensing, shipping, and customs clearance for the Device. Client responsibilities include paying any duties, taxes, and shipping costs to and from (if applicable) the IBM® data center.
* Complying with all applicable laws that are associated with delivery and return of the Device, and the transfer of Content to the IBM® data center. This requirement includes privacy, import, and export laws.
* Having proper agreements in place with and obtaining all required permissions from the Client’s user for any user data that the Client wants to transfer to the Hardware.







 Making a request 



1.
Managing Connections 

Connections to your IBM Cloud® Databases for Redis deployment use resources, so it is important to consider how many connections you need to tune your deployment's performance.



 Redis Connection Limits 

At provision, IBM Cloud® Databases for Redis sets the maximum number of connections to your Redis deployment to 10,000. Leave some connections available, as a number of them are reserved internally to maintain the state and integrity of your database.

Exceeding the connection limit for your deployment can make your database unreachable by your applications. If your connection limit is reached, you see the following error.

ERR max number of clients reached



 Checking Redis Connection Limits 

To display your current client connections, use the following CLI command with your [admin user](https://cloud.ibm.com/docs/databases-for-redis?topic=databases-for-redis-user-managementthe-admin-user).

CLIENT LIST

The output can be filtered.

CLIENT LIST TYPE NORMAL

For more information, see [Redis CLIENT LIST](https://redis.io/commands/client-list/).







 Ending Redis Connections 

Due to the single-threaded nature of Redis, it is not possible to end a client connection while it is running a command. From the client point of view, the connection can never be closed in the middle of the execution of a command. However, the client will notice that the connection is closed only when the next command is sent (and results in network error).

The CLIENT KILL Command closes a client connection.

For more information, see [Redis CLIENT KILL documentation](https://redis.io/commands/client-kill/).





 Redis Connection Pooling 

One way to prevent exceeding the connection limit and ensure that connections from your applications are being handled efficiently is through connection pooling. Connection pooling minimizes the number of active connections against your deployment. For more information, see [The Pooling of Connections in Redis ](https://medium.com/geekculture/the-pooling-of-connections-in-redis-e8188335bf64) and [Connection Pools.]
When your response to an update in your support case is needed, the status is displayed as Waiting on client. If you don't provide a response within seven days, the status is updated to Resolved. The case is then closed if there's still no response after seven more days. For a description of each status type, see the following table:



Table 2. Support case status types

 Status Description 

 New A created case not yet viewed by a support engineer. 
 In progress A case that is under review. 
 Waiting on client The support engineer has left an inquiry on the case that needs the user's response. 
 Resolution provided The support engineer provided a resolution that the user needs to perform. 
 Resolved The support case is considered finished and ready to be closed. 
 Closed Case is closed by a support engineer and can't be reopened.
The client’s backup network adapter is not being accessed because it would mean accessing each VM to shut off the in-guest client backup schedule. Therefore, if a backup network is used, the backup might fail. This situation is temporary until all the VMs can be reached post migration to disable the in-guest backup client.

Bandwidth of a single network extension is theoretically 4 Gbps. However, this value can be the limit for all stretched networks within a single network extension pair and is not achievable by a single stretched network. A single stretched network can achieve 1 Gbps if enough underlay bandwidth is allotted and the latency is low (<10 ms).



 Proximity Routing option 

Without any type of route optimization, extended networks route back to the client side for any L3 access. This trombone-ing introduces an inefficient traffic pattern as packets need to travel back and forth between client (source) and cloud. This situation exists even for cases where both the source and destination VMs are in the cloud. The Proximity Routing feature of HCX was designed to address this issue and local egress of traffic.







 Related links 



* [Glossary of HCX components and terms](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-hcxclient-components)
* [Preparing the installation environment](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-hcxclient-planning-prep-install)
* [HCX Client deployment](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-hcxclient-vcs-client-deployment)
* [Monitoring parameters and components](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-hcxclient-monitoring)
* [HCX troubleshooting](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-hcxclient-troubleshooting)
Create a client key database and a stash file by using the GSKCapiCmd tool. For example, the following command creates a client key database that is called dashclient.kdb and a stash file that is called dashclient.sth:

gsk8capicmd_64 -keydb -create -db "dashclient.kdb" -pw "passw0rdpw0" -stash

where passw0rdpw0 is a password. The -stash option creates a stash file in the same path as that of the client key database, with a file extension of .sth. At connection time, GSKit uses the stash file to obtain the password to the client key database.

c. Add the certificate to the client key database. For example, the following gsk8capicmd command imports the certificate from the /<ssl_directory_name>/ssl/DigiCertGlobalRootCA.crt file into the client key database called dashclient.kdb:

gsk8capicmd_64 -cert -add -db "dashclient.kdb" -pw "passw0rdpw0" -label "DigiCert" -file "/<ssl_directory_name>/ssl/DigiCertGlobalRootCA.crt" -format ascii -fips

d. Update the values of the SSL_CLNT_KEYDB and SSL_CLNT_STASH database manager configuration parameters on the client to specify the client key database and the stash file. Examples follow:

db2 update dbm cfg using SSL_CLNT_KEYDB /<ssl_directory_name>/ssl/dashclient.kdb

db2 update dbm cfg using SSL_CLNT_STASH /<ssl_directory_name>/ssl/dashclient.sth

e. Catalog the Db2 Warehouse on Cloud node so that client applications can connect to it. Issue the following command:

db2 catalog tcpip node <node_name> remote <Db2_Warehouse_IP_address> server <port_number> security ssl
* [What is the expected behavior when loading the CNAME or hostname on your browser for the supported protocols?](https://cloud.ibm.com/docs/CDN?topic=CDN-troubleshoot-cdn-loading-cname-hostname)



* [Getting help and support for CDN](https://cloud.ibm.com/docs/CDN?topic=CDN-gettinghelp)



* [Go to product UI](https://cloud.ibm.com/cdn) [About this product](https://www.ibm.com/cloud/cdn)



Expand all | Collapse all

Collapse



1. [IBM Cloud Docs](https://cloud.ibm.com/docs)
2. [Content Delivery Network (CDN)](https://cloud.ibm.com/docs/CDN)
3.



Search in collection

Search in collection





LangSwitcher dropdown

English

Close menu

DeutschEnglish

EspañolFrançaisItaliano日本語한국어Português/Brasil简体中文繁體中文





 Controlling an HTTP client's cache duration * Last updated 2020-12-03 

When using a CDN, two levels of caching are available:



* Caching at the Edge occurs when a CDN Edge server caches a piece of content from the origin.
* Caching downstream from the Edge network of servers occurs when an user or HTTP client, such as a requesting browser, caches a piece of content from an Edge server.



The method that you choose to control how long content is cached at the requester, such as a browser, depends on the following factors:



* Whether the Respect Header setting is ON or OFF (default).
* Whether the origin server provides a max-age value in the Cache-Control header for a particular piece of content.



Regardless of how these factors change, your origin must provide a Cache-Control header for the intended content to the Edge, if you want Edge servers to send HTTP responses with the Cache-Control header for that content.
For example, the following command creates a client key database that is called dashclient.kdb and a stash file that is called dashclient.sth:

gsk8capicmd_64 -keydb -create -db "dashclient.kdb" -pw "passw0rdpw0" -stash

where passw0rdpw0 is a password. The -stash option creates a stash file in the same path as that of the client key database, with a file extension of .sth. At connection time, GSKit uses the stash file to obtain the password to the client key database.

c. Add the certificate to the client key database. For example, the following gsk8capicmd command imports the certificate from the /<ssl_directory_name>/ssl/DigiCertGlobalRootCA.crt file into the client key database called dashclient.kdb:

gsk8capicmd_64 -cert -add -db "dashclient.kdb" -pw "passw0rdpw0" -label "DigiCert" -file "/<ssl_directory_name>/ssl/DigiCertGlobalRootCA.crt" -format ascii -fips

d. Update the values of the SSL_CLNT_KEYDB and SSL_CLNT_STASH database manager configuration parameters on the client to specify the client key database and the stash file. Examples follow:

db2 update dbm cfg using SSL_CLNT_KEYDB /<ssl_directory_name>/ssl/dashclient.kdb

db2 update dbm cfg using SSL_CLNT_STASH /<ssl_directory_name>/ssl/dashclient.sth

e. Catalog the Db2 on Cloud node so that client applications can connect to it. Issue the following command:

db2 catalog tcpip node <node_name> remote <Db2_Warehouse_IP_address> server <port_number> security ssl

where:

<node_name> is your name for the node.
Note, these restrictions do not apply to HTTP workloads.

The private endpoint details allocated to your instance (as described in the service key) must be resolvable and routable from the network that the workload is running in. It is not possible to specify alternative hostname entries in the workload's bootstrap.servers properties as a way to route traffic from the external network.

The reason for this behavior is Kafka's two-step connection process. In the initial step, the hostnames that are provided in the client's bootstrap.servers property are used to establish the first bootstrap connection. However, the server then responds to the client with the actual endpoint hostname details it uses. These hostname details are the private endpoint details originally allocated to your instance and cannot be changed. Hence, the details must be resolvable and routable directly from the external network.

For more information, see [Accessing private API endpoints from an on-premises network by using IBM Cloud Direct Link](https://cloud.ibm.com/docs/vpc?topic=vpc-end-to-end-private-connectivity-vpe&interface=cli).







 What to do next 

Now you have connection and credential information, you can choose a Kafka client. For more information, see [Using the Kafka API](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-kafka_using).
* Dedicated: resources are allocated for a specific client (used for specific third-party considerations)
* Uncapped shared: shared among other clients
* Capped shared: shared, but resources do not expand beyond those that are requested (used mostly for licensing)



There is a core-to-vCPU ratio of 1:1. For shared processors, fractional cores round up to the nearest whole number. For example, 1.25 cores equals 2 vCPUs. For more information, see [How does shared processor performance compare to dedicated processors](https://community.ibm.com/community/user/power/blogs/pete-heyrman1/2020/06/16/how-does-shared-processor-performance-compare-to-d?CommunityKey=71e6bb8a-5b34-44da-be8b-277834a183b0&tab=recentcommunityblogsdashboard) and [Processor pricing](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-pricing-virtual-serverpricing-processor).

Dedicated processors

Shared processors



Table 1. Dedicated processors

 Dedicated processors 

 The hypervisor makes a 1:1 binding of a partition’s processor to a physical processor core. Once a VM is activated, the 1:1 binding is static in that a given operating system (OS) logical thread will always run on that same physical hardware. With a dedicated processor partition, you need to size the wanted number of cores to meet the peak demand of the partition. For example, if during a typical workday the CPU consumption is around four cores, but it peaks around eight cores, you need to configure the partition with eight cores. Otherwise, you might encounter queuing delays in dispatching applications because there are not enough cores to handle the peak demand. 







 How does my current environment compare to what's available through the Power Systems Virtual Server? 

If you'd like to compare your current environment's performance to what's available through the Power Systems Virtual Server offering, see the [IBM Power Systems Performance Report](https://www.ibm.com/downloads/cas/K90RQOW8).
Optional: If your app supports the [web app strategy](https://cloud.ibm.com/docs/appid?topic=appid-key-conceptsterm-web-strategy) in addition to or instead of the [API strategy](https://cloud.ibm.com/docs/appid?topic=appid-key-conceptsterm-api-strategy), add the nginx.ingress.kubernetes.io/auth-signin: https://$host/oauth2-<App_ID_service_instance_name>/start?rd=$escaped_request_uri annotation. Note that all letters in the service instance name must be in lowercase.



* If you specify this annotation, and the authentication for a client fails, the client is redirected to the URL of the OAuth2-Proxy for your App ID instance. This OAuth2-Proxy, which acts as the OIDC Relying Party (RP) for App ID, redirects the client to your App ID login page for authentication.
* If you don't specify this annotation, a client must authenticate with a valid bearer token. If the authentication for a client fails, the client's request is rejected with a 401 Unauthorized error message.





6. Re-apply your Ingress resources to enforce App ID authentication. After an Ingress resource with the appropriate annotations is re-applied, the ALB OAuth Proxy add-on deploys an OAuth2-Proxy deployment, creates a service for the deployment, and creates a separate Ingress resource to configure routing for the OAuth2-Proxy deployment messages. Do not delete these add-on resources.

kubectl apply -f <app_ingress_resource>.yaml -n namespace
7. Verify that App ID authentication is enforced for your apps.



* If your apps supports the [web app strategy](https://cloud.ibm.com/docs/appid?topic=appid-key-conceptsterm-web-strategy): Access your app's URL in a web browser.
[Order a Hardware Security Module (HSM)](https://cloud.ibm.com/docs/citrix-netscaler-vpx?topic=citrix-netscaler-vpx-order-the-ibm-hardware-security-module-hsm-) First, you'll order an HSM. 
 [Order a Citrix Netscaler VPX](https://cloud.ibm.com/docs/citrix-netscaler-vpx?topic=citrix-netscaler-vpx-order-a-citrix-netscaler-vpx) If you haven't already, you'll order a Citrix Netscaler VPX. 
 [Initialize the HSM](https://cloud.ibm.com/docs/citrix-netscaler-vpx?topic=citrix-netscaler-vpx-initialize-ibm-hardware-security-module-hsm-) Most configurations require initialization of the HSM device. Without this, only certain show commands can be executed. 
 [Create a partition](https://cloud.ibm.com/docs/citrix-netscaler-vpx?topic=citrix-netscaler-vpx-create-a-partition) A partition is a logical and independent space that is associated or attached to the client requesting or creating cryptographic objects in the HSM engine. 
 [Install the HSM client software](https://cloud.ibm.com/docs/citrix-netscaler-vpx?topic=citrix-netscaler-vpx-install-the-ibm-hardware-security-module-hsm-client-software) In this sub-section, VPX is installed with the software and utilities required to interact with the HSM. 
 [Establish the Network Trust Link (NTL)](https://cloud.ibm.com/docs/citrix-netscaler-vpx?topic=citrix-netscaler-vpx-establish-a-network-trust-link-ntl-) A Network Trust Link (NTL) is a secure channel for the Hardware Security Module (HSM) and the client to communicate.
This type of group is automatically deleted after 15 days of inactivity.

Favorite groups names must be unique. Unfavorite groups do not have this limitation.





 In what status is a CDN allowed to perform multiple file purges? 

Multiple file purges are allowed in the following states:



* Running
* Running - HTTP only
* CNAME configuration required
* Stopped







 Is IBM CDN compliant with Payment Card Industry Data Security Standard (PCI DSS)? 

Yes, IBM CDN is PCI DSS 3.2.1 compliant through our partner Akamai's certification. For more information, see the Akamai [Attestation of Compliance](https://www.akamai.com/uk/en/multimedia/documents/infosec/pci-dss-3.2-attestation-of-compliance.pdf).





 How to get the client IP address? 

Akamai Edge servers add the True-Client-IP and X-Forwarded-For headers in the requests to the origin. Then, in your backend origin server, you can get the client IP address from the value of the True-Client-IP, or extract the first IP in the chain of X-Forwarded-For.