vania-janet/multiturn-rag-retrieval-data huggingface dataset:
VMware HCX mobility, extension, protection actions can be initiated from the HCX User Interface or from within the vCenter Server Navigator screen's menus.





 HCX Cloud and HCX Connector 

In the HCX site-to-site architecture, an HCX source environment and an HCX destination environment exist. Depending on the environment, a specific HCX installer is used, either HCX Connector (previously HCX Enterprise) or HCX Cloud. HCX Connector is always deployed as the source. HCX Cloud is typically deployed as the destination, but it can be used as the source in cloud-to-cloud deployments. In HCX-enabled public clouds, the cloud provider deploys HCX Cloud. The public cloud tenant deploys HCX Connector on-premises.

The source and destination sites are paired together for HCX operations. An HCX Connector cannot be paired with another HCX Connector.

In both the source and destination environments, HCX is deployed to the management zone, next to each site's vCenter Server, which provides a single plane (HCX Manager) for administering VMware HCX. This HCX Manager provides a framework for deploying HCX service VMs across both the source and destination sites. VMware HCX administrators are authenticated, and each task authorized through the existing vSphere SSO identity sources. VMware HCX mobility, extension, protection actions can be initiated from the HCX User Interface or from within the vCenter Server Navigator screen's menus.





 HCX-IX Interconnect Appliance (HCX-IX) 

The HCX-IX service appliance provides replication and vMotion-based migration capabilities over the Internet and private lines to the destination site whereas providing strong encryption, traffic engineering, and VM mobility.





 HCX WAN Optimization Appliance (HCX-WO) 

The VMware HCX WAN Optimization service improves performance characteristics of the private lines or Internet paths by applying WAN optimization techniques like the data de-duplication and line conditioning. It makes performance closer to a LAN environment. It accelerates onboarding to the destination site by using Internet and VPN.
--inventory cpdPlatformOperator 
--action configure-creds-airgap 
--args "--registry cp.icr.io --user cp --pass $PRD_ENTITLED_REGISTRY_APIKEY --inputDir ${OFFLINEDIR}"
3. Get the name of your Watson Assistant by running the following command:

oc get wa
4. Edit and save the CR.

a) Run the following command to edit the CR. In the command, replace INSTANCE_NAME with the name of the Watson Assistant instance:

oc edit wa INSTANCE_NAME

b) Edit the CR by adding the following lines:

appConfigOverrides:
container_images:
integrations:
image: cp.icr.io/cp/watson-assistant/servicedesk-integration
tag: 20220106-143142-0ea3fbf7-wa_icp_4.0.5-signed@sha256:7078fdba4ab0b69dbb93f47836fd9fcb7cfb12f103662fef0d9d1058d2553910
5. Wait for the Watson Assistant operator to pick up the change and start a new integrations pod. This might take up to 10 minutes.
6. After the new integrations pod starts, the old pod terminates. When the new pod starts, the server starts locally and the log looks similar to the following example:

oc logs -f ${INTEGRATIONS_POD}
[2022-01-07T01:33:13.609] [OPTIMIZED] db.redis.RedisManager - Redis trying to connect. counter 1
[2022-01-07T01:33:13.628] [OPTIMIZED] db.redis.RedisManager - Redis connected
[2022-01-07T01:33:13.629] [OPTIMIZED] db.redis.RedisManager - Redis is ready to serve!
Create and apply a new cipher suite 

A cipher suite is a combination of authentication, encryption, Message Authentication Code (MAC) and key exchange algorithms used to negotiate the security settings for SSL and TLS protocols. [: shortdesc]

To guarantee proper authentication you must ensure your Citrix Netscaler VPX uses the best combination of ciphers.

To learn more about SSL cipher suites and other best practices visit the following links:



* [Scoring an A+ at SSLlabs.com with Citrix NetScaler](https://www.citrix.com/blogs/2018/05/16/scoring-an-a-at-ssllabs-com-with-citrix-netscaler-q2-2018-update/) – Q2 2018 update (refer to steps three and five in the command guide)
* [SSL and TLS Deployment Best Practices](https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices23-use-secure-cipher-suites)
* [How Do I Setup ECC on NetScaler?](https://support.citrix.com/article/CTX205289)



This topic focuses on specific and required configurations for SSL ciphers. The information in the previous links may provide additional settings that can be applied to optimize SSL operation.

To create a new Cipher Suite that prioritizes AEAD, ECDHE, and ECDSA ciphers, perform the following procedure:



1. Enter the following commands simultaneously in your Citrix VPX CLI, and ensure they are all applied:

add ssl cipher SSLLABS
bind ssl cipher SSLLABS -cipherName TLS1.2-ECDHE-ECDSA-AES128-GCM-SHA256
bind ssl cipher SSLLABS -cipherName TLS1.2-ECDHE-ECDSA-AES256-GCM-SHA384
bind ssl cipher SSLLABS -cipherName TLS1.2-ECDHE-ECDSA-AES128-SHA256
For more information about configuring Informix client driver for SSL connection, refer to the Informix Security Guide's [Secure sockets layer protocol](http://www.ibm.com/support/knowledgecenter/SSGU8G_14.1.0/com.ibm.sec.doc/ids_ssl_001.htm) topic in IBM Knowledge Center.





 InformixHQ 

The web-based monitoring and administration tool, InformixHQ, is also configured and running. The HQ Server and Agent processes run as the OS user "informixhqu". Using a browser connect to InformixHQ at [https://127.0.0.1:8443/](https://127.0.0.1:8443/). Details about the initial credentials can be found in the /opt/informix/hq/config/informixhq-server.properties file.
You can choose to store previously received nonces to compare against the nonce included in the request. If the nonce in the request was used before, do not accept the request. This action can help prevent replay attacks.
3. Hash Message Authentication Code (HMAC) located in the request's "Authorization" header

This value is a string that is hashed by using the HMAC-SHA256 algorithm that uses the provided secret string as the key, and then encoded into Base64. You need to construct the string, hash it, encode it to Base64, and then compare the result to the signature in the "Authorization" header. If they do not match, do not accept the request. See next section for details on creating the HMAC signature.





 Comparing the HMAC signatures 

To verify the HMAC signature that is located in the request's "Authorization" header, you need to create a comparison string. Complete the following steps to create the string:



1. Create the canonical string.

The canonical string must contain the following data:



* Method Type - POST in this case (must be uppercase)
* Content Type - Found in the "Content-Type" header
* Payload - The body of the request. This example assumes that the JSON string is decoded into a native associative array or dictionary.
* Nonce - Found in the "X-IBM-Nonce" header



To create the canonical string, combine the canonical string data in the following EXACT order with no delimiters:

Method Type + Content Type + Payload['id'] + Payload['serviceName'] + Payload['event'] + Payload['timestamp'] + Nonce
2. Hash the canonical string.

The hashing algorithm that is used in the transient virtual server webhook is HMAC-SHA256, which is a keyed hashing algorithm. The key to use is the secret that was provided when the webhook was set up.
3. Encode the hashed canonical string to Base64.
4. Compare the resulting string to the signature in the 'Authorization' header.

Use a timing-attack safe string comparison function.
Securing the Linux hardened repository server 

This step describes the Ansible® playbook that secures the Linux® hardened backup repository server after it is added to the Veeam® backup infrastructure. The playbook does the following tasks:



* (Optional) [Adds a user](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-veeam-cr-sag-lhbrsecureveeam-cr-sag-lhbrsecure-user) named ansible.
* [Secures the SSH access](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-veeam-cr-sag-lhbrsecureveeam-cr-sag-lhbrsecure-ssh).



The playbook can be written locally on your laptop by using an editor, such as Visual Studio Code, and transferred to the automation server swlibansible directory, or edited locally on the automation server in a text editor, such as vi or nano.



 Creating the playbook 

The playbook secure_lhbr.yml starts with the following code:

- hosts: lhbr
vars:
vbr_ip: <vbr_ip>
ansible_ip: <ansible_ip>

Replace <vbr_ip> and <ansible_ip> in the previous code snippet with the values that you captured in the earlier steps.





 Adding a user 

The task to add an automation user so that the server can be maintained, such as updated, is optional.

Without the automation user, the server has no remote SSH access as the root user is unable to connect through SSH, and the veeamuser has no SSH access. Access to the server is possible through the remote console through the IPMI connection.

If you choose this optional task, then you need to change the Ansible inventory file hosts to ansible_user=ansible.

The following code snippet does these actions:



* Adds a user named ansible.
* Copies the ansible user's public key to the authorized_hosts file.
- -c
- sysctl -e -w net.core.somaxconn=32768; sysctl -e -w net.ipv4.ip_local_port_range="1025 65535";
image: alpine:3.6
imagePullPolicy: IfNotPresent
name: sysctl
resources: {}
securityContext:
privileged: true
2. Patch each of your deployments.

kubectl patch deployment <deployment_name> --patch pod-patch.yaml
3. If you changed the net.core.somaxconn value in the kernel settings, most apps can automatically use the updated value. However, some apps might require you to manually change the corresponding value in your app code to match the kernel value. For example, if you're tuning the performance of a pod where an NGINX app runs, you must change the value of the backlog field in the NGINX app code to match. For more information, see this [NGINX blog post](https://www.nginx.com/blog/tuning-nginx/).







 Optimizing network keepalive sysctl settings 

If a pod has long running TCP connections that are occasionally disconnected when they are idle for a period of time, it might help to change the sysctl keepalive settings for the pod.

These scenarios and suggested settings are also described in the [Troubleshooting Outgoing Connection Issues with IBM VPC Public and Service Gateways](https://www.ibm.com/cloud/blog/troubleshooting-outgoing-connection-issues-with-ibm-vpc-public-and-service-gateways) blog.

The following sysctl network values can be set on all worker nodes in a cluster by using the daemonset described in the [Modifying worker node kernel settings](https://cloud.ibm.com/docs/containers?topic=containers-kernelworker-kernel-ds) section. However, there currently isn't a way to set these sysctl keepalive settings on all pods by default in a cluster.
"notificationChannelIds": [],
"severity": 0,
"actions": [
{
"afterEventNs": 1000000000,
"beforeEventNs": 1000000000,
"isLimitedToContainer": false,
"type": "POLICY_ACTION_CAPTURE",
"filter": "proc.name=cat or proc.name=vi",
"name": "string",
"bucketName": "",
"storageType": "S3"
}
],
"type": "falco"
}
Show more

See the [command options](https://cloud.ibm.com/docs/workload-protection?topic=workload-protection-workload-protection-policy-cliss_policy_options) for a description of additional options.
Administering your instance 

These topics cover several tasks and areas involved with administering your instance of IBM Watson® Assistant.



 Topic Description 

 [Managing access](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-access-control) You can give other people access to your Watson Assistant instance and resources, and control the level of access they get. 
 [Managing your plan](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-admin-managing-plan) A Watson Assistant plan information reference and steps on upgrading your plan. 
 [Using IBM Cloud Acitivity Tracker to audit user activity](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-admin-auditing) As a security officer, auditor, or manager, you can use the Activity Tracker service to track how users and applications interact with Watson Assistant. 
 [Securing your assistant](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-admin-securing) Data privacy, security, and governance solutions. 
 [Backing up and restoring data](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-admin-backup-restore) Back up and restore your data by downloading, and then uploading the data. 
 [High availability and disaster recovery](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-admin-recovery) Watson Assistant is highly available within multiple IBM Cloud® locations (for example, Dallas and Washington, DC). However, recovering from potential disasters that affect an entire location requires planning and preparation. 
 [Failover options](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-admin-failover) This topic explains some actions you can take to increase the availability of Watson Assistant for your organization. 
 [Adding support for global audiences](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-admin-language-support) Watson Assistant supports individual features to varying degrees per language.
Accepting provider-created connections 

This topic shows you how to accept provider-created connections (create, edit, delete connections) and enable BGP MD5 authentication.



 Accepting a Direct Link creation request 



1. Log in to the IBM Cloud [Direct Link console](https://cloud.ibm.com/interconnectivity/direct-link), then click the Direct Link name in the table to show its details.
2. In the Actions section, click Review to review the direct link configuration. The Review configuration panel displays.
3. Review your settings and click Accept. The Finalize creation panel displays.
4. Select a resource group, routing type, and billing type. Then, select the checkbox indicating that you agree to the Direct Link prerequisites and click Create.
Optionally, you can enable MD5 authentication. For instructions, see [Enabling MD5 authentication for BGP peers](https://cloud.ibm.com/docs/dl?topic=dl-accepting-the-provider-created-connectiondl-enable-md5-provider).







 Accepting a Direct Link edit request 



1. Log in to the IBM Cloud [Direct Link console](https://cloud.ibm.com/interconnectivity/direct-link), then click the Direct Link name in the table to show its details.
2. In the Actions section, click Review to review the direct link configuration.

The Review configuration panel displays.
3. Review your settings, select the checkbox indicating that you agree to the Direct Link prerequisites, and click Accept.







 Enabling MD5 authentication for BGP peers 

Optionally, you can enable MD5 authentication to secure the BGP session by allowing routing of messages only from routers using a shared authentication key.

You must configure the same BGP MD5 authentication key on both your Edge router and the IBM cross-connect router (XCR). The shared authentication key on the IBM device must be stored in your HPCS or Key Protect instance and shared with the Direct Link service.

To enable MD5 authentication after submitting your order, follow these steps:



1.
Evaluating gates 

IBM Cloud® DevOps Insights gates check whether your test results comply with a defined policy. If the policy is not met, the gate fails by default. You can also configure gates to act in an advisory role to allow pipeline progression even after failure.



 Before you begin 

[Publish your test results](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-publish-test-cli).

[Create a policy with rules](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-defining-policies-rules).





 Defining gates for Continuous Delivery 

Place your gates before the build promotion in your pipeline to check the quality of the build against your policies. Policies ensure that it is safe to promote your application from one environment to the next.

After you create the policy, you can use the following script for gate evaluation:

install the DevOps Insights plugin
ibmcloud plugin install -f doi

 Login to IBMCloud if you are not already logged in. Assumes that $API_KEY environment variable has been set as a secured property
ibmcloud login --apikey $API_KEY --no-region

 The following line assumes that MY_APP_NAME and MY_BUILD_NUMBER environment variables have already been set. POLICY is the name of the policy being evaluated.
ibmcloud doi gate-evaluate --logicalappname="$MY_APP_NAME" --buildnumber="$MY_BUILD_NUMBER" --policy "$POLICY_NAME"





 Viewing gate evaluation 

You can view the results of the gate evaluation on the Risk Analysis page, which relies on the presence of a gate after a staging deployment job in your pipeline. Make sure that you have a gate after you deploy to the staging environment, but before you deploy to a production environment.



1. From the IBM Cloud console, click the menu icon !
If you use the IBM-provided Ingress subdomain, you can use the IBM-provided TLS certificate. If you use a custom domain, you can use your own TLS certificate to manage TLS termination.
* [Re-encrypt package before you forward it to upstream apps](https://cloud.ibm.com/docs/containers?topic=containers-comm-ingress-annotationsssl-services-support): The ALB decrypts HTTPS requests before forwarding traffic to your apps. If you have apps that require HTTPS and need traffic to be encrypted before it is forwarded to those upstream apps, you can use the ssl-services annotation. If your upstream apps can handle TLS, you can optionally provide a certificate that is contained in a one-way or mutual-authentication TLS secret.



To secure the service-to-service communication, you can use [Istio's mutual TLS authentication](https://istio.io/latest/docs/concepts/security/mutual-tls-authentication). Istio is an open source service that gives developers a way to connect, secure, manage, and monitor a network of microservices, also known a service mesh, on cloud orchestration platforms like Kubernetes.







 Persistent storage 

Review supported options for encrypting and protecting your data on persistent storage in IBM Cloud.

By default, all IBM Cloud storage solutions automatically encrypt your data at rest with an IBM-managed encryption key at no additional cost. For more information, see the following links.



* [Classic NFS File Storage for Classic](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-mng-dataencryptvolume)
* [Classic Block Storage](https://cloud.ibm.com/docs/BlockStorage?topic=BlockStorage-mng-data)
* [VPC Block Storage](https://cloud.ibm.com/docs/vpc?topic=vpc-block-storage-aboutvpc-storage-encryption)
* The SECURE flag must be set to true to use a secure SSL/TLS connection to send metrics to the collector.
* Set sysdig_capture_enabled to false to disable the capture feature. By default is set to true. For more information, see [Working with captures](https://cloud.ibm.com/docs/monitoring?topic=monitoring-capturescaptures).



If cURL is not available, you must install it. For example, for an Ubuntu bare metal, run the following command: sudo apt-get update. Then, run the install command: sudo apt-get install curl.

For example, see the following sample command to install a monitoring agent that forwards metrics to a monitoring instance in US South (Dallas):

curl -sL https://ibm.biz/install-sysdig-agent | sudo bash -s -- -a xxxxxxxxxxxxx -c ingest.us-south.monitoring.cloud.ibm.com --collector_port 6443 --secure true -ac "sysdig_capture_enabled: false" --tags sourceType:baremetal,location:dallas
4. Configure the agent for non-orchestrated environments.

Open the dragent.yaml file that is located in /opt/draios/etc/.

Add the following configuration parameter:

feature:
mode: monitor_light

Restart the agent. Run the following command:

service dragent restart







 Step 2: Launch the monitoring UI to verify that you are getting data to monitor the bare metal server 

Complete the following steps to launch the web UI:



1. [Log in to your IBM Cloud account](https://cloud.ibm.com/login).

After you log in with your user ID and password, the IBM Cloud console opens.
2. Click the Menu icon !
Deploying the Key Protect console to Satellite 

After you have [successfully deployed your Satellite location](https://cloud.ibm.com/docs/satellite?topic=satellite-getting-started) and [configured your HSM](https://cloud.ibm.com/docs/key-protect?topic=key-protect-satellite-hsm-deploy), you're ready to deploy IBM® Key Protect for IBM Cloud® on Satellite.

While the IBM Console is used to create the Key Protect service on Satellite, the console itself cannot currently be used to access the Key Protect APIs that are used to create keys or perform other key actions (such as rotating keys, deleting keys, editing keys, and so on). Those key actions must be performed through direct calls to the [Key Protect APIs](https://cloud.ibm.com/apidocs/key-protect) or by using the CLI.



 Before you begin 

Before you can deploy Key Protect on Satellite, you must have created a Satellite location and have both deployed and [correctly configured](https://cloud.ibm.com/docs/key-protect?topic=key-protect-satellite-hsm-deploy) at least two HSMs. You must also have [gathered the information about the HSM that Satellite needs to consume](https://cloud.ibm.com/docs/key-protect?topic=key-protect-satellite-hsm-deploysatellite-hsm-ui-values) and have [deployed the IBM Cloud Databases service in your Satellite location](https://cloud.ibm.com/docs/docs/cloud-databases?topic=cloud-databases-satellite-on-prem). You must also have been added to the allowlist, which can be achieved through your contact with the service representative.

Because the HSM information is not verified until after Key Protect has been provisioned (an operation that can take more than an hour), it is important to ensure these fields are filled out correctly when first attempting to create a Key Protect on Satellite location.



* HSM IP address: The IP address of your HSM. This is needed in order to connect to the worker nodes that you assigned to Key Protect.
* UI
* API







 Creating root keys 

Use IBM® Key Protect for IBM Cloud® to create root keys with the IBM Cloud console.

Use IBM® Key Protect for IBM Cloud® to create root keys programmatically with the Key Protect API.

Root keys are symmetric key-wrapping keys that are used to protect the security of encrypted data in the cloud. For more information about root keys, see [Protecting data with envelope encryption](https://cloud.ibm.com/docs/key-protect?topic=key-protect-envelope-encryption).

Encryption keys that are created in one region can be used to encrypt data stores located in any region within IBM Cloud.

You can specify an expiration date when creating a root key. After performing the wrap, unwrap, rewrap, get key, or get key metadata actions on a key, an associated IBM Cloud® Activity Tracker event will send information on the date that the key expires and how many days are left until that day arrives. You can also [configure an alert](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-alertsalerts_step3_preset) that will notify you days before key expiration. For more information on monitoring key expiration via IBM Cloud Activity Tracker, see [IBM Cloud Activity Tracker events](https://cloud.ibm.com/docs/key-protect?topic=key-protect-at-events).



 Creating root keys in the console 

[After you create an instance of the service](https://cloud.ibm.com/docs/key-protect?topic=key-protect-provision), complete the following steps to create a root key in the IBM Cloud console.

If you enable [dual authorization settings for your Key Protect instance](https://cloud.ibm.com/docs/key-protect?topic=key-protect-manage-dual-auth), keep in mind that any keys that you add to the service require an authorization from two users to delete keys.



1. [Log in to the IBM Cloud console](https://cloud.ibm.com/login/).
2.