mtpti5iD/redhat-docs_dataset huggingface dataset:
20.2. Using volume_key as an Individual User As an individual user, volume_key can be used to save encryption keys by using the following procedure. Note For all examples in this file, /path/to/volume is a LUKS device, not the plaintext device contained within. blkid -s type /path/to/volume should report type ="crypto_LUKS" . Procedure 20.1. Using volume_key Stand-alone Run: A prompt will then appear requiring an escrow packet passphrase to protect the key. Save the generated escrow-packet file, ensuring that the passphrase is not forgotten. If the volume passphrase is forgotten, use the saved escrow packet to restore access to the data. Procedure 20.2. Restore Access to Data with Escrow Packet Boot the system in an environment where volume_key can be run and the escrow packet is available (a rescue mode, for example). Run: A prompt will appear for the escrow packet passphrase that was used when creating the escrow packet, and for the new passphrase for the volume. Mount the volume using the chosen passphrase. To free up the passphrase slot in the LUKS header of the encrypted volume, remove the old, forgotten passphrase by using the command cryptsetup luksKillSlot .

Commands:
volume_key --save /path/to/volume -o escrow-packet
volume_key --restore /path/to/volume escrow-packet
Chapter 2. Installation This chapter guides you through the steps to install AMQ .NET in your environment. 2.1. Prerequisites You must have a subscription to access AMQ release files and repositories. To use AMQ .NET on Red Hat Enterprise Linux, you must install the the .NET Core 3.1 developer tools. For information, see the .NET Core 3.1 getting started guide . To build programs using AMQ .NET on Microsoft Windows, you must install Visual Studio. 2.2. Installing on Red Hat Enterprise Linux Procedure Open a browser and log in to the Red Hat Customer Portal Product Downloads page at access.redhat.com/downloads . Locate the Red Hat AMQ Clients entry in the INTEGRATION AND AUTOMATION category. Click Red Hat AMQ Clients . The Software Downloads page opens. Download the AMQ Clients 2.9.0 .NET Core .zip file. Use the unzip command to extract the file contents into a directory of your choosing. USD unzip amq-clients-2.9.0-dotnet-core.zip When you extract the contents of the .zip file, a directory named amq-clients-2.9.0-dotnet-core is created. This is the top-level directory of the installation and is referred to as <install-dir> throughout this document. Use a text editor to create the file USDHOME/.nuget/NuGet/NuGet.Config and add the following content: <?xml version="1.0" encoding="utf-8"?> <configuration> <packageSources> <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3"/> <add key="amq-clients" value=" <install-dir> /nupkg"/> </packageSources> </configuration> If you already have a NuGet.Config file, add the amq-clients line to it. Alternatively, you can move the .nupkg file inside the <install-dir> /nupkg directory to an existing package source location. 2.3. Installing on Microsoft Windows Procedure Open a browser and log in to the Red Hat Customer Portal Product Downloads page at access.redhat.com/downloads . Locate the Red Hat AMQ Clients entry in the INTEGRATION AND AUTOMATION category. Click Red Hat AMQ Clients . The Software Downloads page opens. Download the AMQ Clients 2.9.0 .NET .zip file. Extract the file contents into a directory of your choosing by right-clicking on the zip file and selecting Extract All . When you extract the contents of the .zip file, a directory named amq-clients-2.9.0-dotnet is created. This is the top-level directory of the installation and is referred to as <install-dir> throughout this document.

Commands:
unzip amq-clients-2.9.0-dotnet-core.zip
<?xml version="1.0" encoding="utf-8"?> <configuration> <packageSources> <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3"/> <add key="amq-clients" value=" <install-dir> /nupkg"/> </packageSources> </configuration>
GitOps CLI (argocd) reference Red Hat OpenShift GitOps 1.15 Configuring the GitOps CLI and logging in to the Argo CD server in the default mode Red Hat OpenShift Documentation Team

Commands:
argocd completion bash > argocd_bash_completion
sudo cp argocd_bash_completion /etc/bash_completion.d/
If the login session times out, you can use the `relogin` command to log in again. When done using the `argocd` commands, you can log out using the `logout` command.
ADMIN_PASSWD=USD(oc get secret openshift-gitops-cluster -n openshift-gitops -o jsonpath='{.data.admin\.password}' | base64 -d)
SERVER_URL=USD(oc get routes openshift-gitops-server -n openshift-gitops -o jsonpath='{.status.ingress[0].host}')
argocd login --username admin --password USD{ADMIN_PASSWD} USD{SERVER_URL}
argocd login --username admin --password '<password>' openshift-gitops.openshift-gitops.apps-crc.testing
'admin:login' logged in successfully Context '<server_url>' updated
argocd --core app list --repo-server-name openshift-gitops-repo-server
ARGOCD_REPO_SERVER_NAME=openshift-gitops-repo-server argocd --core app list
argocd --core --kube-context kubeadmin-local app list --repo-server-name openshift-gitops-repo-server
ARGOCD_REPO_SERVER_NAME=openshift-gitops-repo-server argocd --core --kube-context kubeadmin-local app list
KUBECONFIG=~/.kube/custom_config argocd --core app list --repo-server-name openshift-gitops-repo-server
KUBECONFIG=~/.kube/custom_config argocd --kube-context kubeadmin-local --core app list --repo-server-name openshift-gitops-repo-server
argocd
argocd version
argocd version --client
argocd version --server <server_url>
argocd version -o json
argocd version --short -o yaml
argocd help
argocd help admin
source <(argocd completion bash)
source <(argocd completion zsh) compdef _argocd argocd
21.3.2. Starting Printer Setup Printer setup process varies depending on the printer queue type. If you are setting up a local printer connected with USB, the printer is discovered and added automatically. You will be prompted to confirm the packages to be installed and provide the root password. Local printers connected with other port types and network printers need to be set up manually. Follow this procedure to start a manual printer setup: Start the Printer Configuration tool (see Section 21.3.1, "Starting the Printer Configuration Tool" ). Go to Server New Printer . In the Authenticate dialog box, type the root user password and confirm. Select the printer connection type and provide its details in the area on the right.

Commands:
Chapter 1. Introduction to AMQ Broker on OpenShift Container Platform Red Hat AMQ Broker 7.12 is available as a containerized image for use with OpenShift Container Platform (OCP) 4.14, 4.15, 4.16, 4.17 and 4.18. AMQ Broker is based on Apache ActiveMQ Artemis. It provides a message broker that is JMS-compliant. After you have set up the initial broker pod, you can quickly deploy duplicates by using OpenShift Container Platform features. 1.1. Version compatibility and support For details about OpenShift Container Platform image version compatibility, see: OpenShift Container Platform 4.x Tested Integrations Note All deployments of AMQ Broker on OpenShift Container Platform now use RHEL 8 based images. 1.2. Unsupported features External clients cannot use the topology information provided by AMQ Broker When an AMQ Core Protocol JMS Client or an AMQ JMS Client connects to a broker in an OpenShift Container Platform cluster, the broker can send the client the IP address and port information for each of the other brokers in the cluster, which serves as a failover list for clients if the connection to the current broker is lost. The IP address provided for each broker is an internal IP address, which is not accessible to clients that are external to the OpenShift Container Platform cluster. To prevent external clients from trying to connect to a broker using an internal IP address, set the following configuration in the URI used by the client to initially connect to a broker. Client Configuration AMQ Core Protocol JMS Client useTopologyForLoadBalancing=false AMQ JMS Client failover.amqpOpenServerListAction=IGNORE 1.3. Document conventions This document uses the following conventions for the sudo command, file paths, and replaceable values. The sudo command In this document, sudo is used for any command that requires root privileges. You should always exercise caution when using sudo , as any changes can affect the entire system. For more information about using sudo , see Managing sudo access . About the use of file paths in this document In this document, all file paths are valid for Linux, UNIX, and similar operating systems (for example, /home/... ). If you are using Microsoft Windows, you should use the equivalent Microsoft Windows paths (for example, C:\Users\... ). Replaceable values This document sometimes uses replaceable values that you must replace with values specific to your environment. Replaceable values are lowercase, enclosed by angle brackets ( < > ), and are styled using italics and monospace font. Multiple words are separated by underscores ( _ ) . For example, in the following command, replace <project_name> with your own project name. USD oc new-project <project_name>

Commands:
oc new-project <project_name>
Chapter 1. Preparing to deploy OpenShift Data Foundation When you deploy OpenShift Data Foundation on OpenShift Container Platform using local storage devices, you can create internal cluster resources. This approach internally provisions base services and all applications can access additional storage classes. Before you begin the deployment of Red Hat OpenShift Data Foundation using local storage, ensure that your resource requirements are met. See requirements for installing OpenShift Data Foundation using local storage devices . On the external key management system (KMS), When the Token authentication method is selected for encryption then refer to Enabling cluster-wide encryption with the Token authentication using KMS . Ensure that you are using signed certificates on your Vault servers. After you have addressed the above, follow these steps in the order given: Install the Red Hat OpenShift Data Foundation Operator . Install Local Storage Operator . Find the available storage devices . Create the OpenShift Data Foundation cluster service on IBM Z . 1.1. Requirements for installing OpenShift Data Foundation using local storage devices Node requirements The cluster must consist of at least three OpenShift Container Platform worker or infrastructure nodes with locally attached-storage devices on each of them. Each of the three selected nodes must have at least one raw block device available. OpenShift Data Foundation uses the one or more available raw block devices. The devices you use must be empty, the disks must not include Physical Volumes (PVs), Volume Groups (VGs), or Logical Volumes (LVs) remaining on the disk. For more information, see the Resource requirements section in the Planning guide . 1.2. Enabling cluster-wide encryption with KMS using the Token authentication method You can enable the key value backend path and policy in the vault for token authentication. Prerequisites Administrator access to the vault. A valid Red Hat OpenShift Data Foundation Advanced subscription. For more information, see the knowledgebase article on OpenShift Data Foundation subscriptions . Carefully, select a unique path name as the backend path that follows the naming convention since you cannot change it later. Procedure Enable the Key/Value (KV) backend path in the vault. For vault KV secret engine API, version 1: For vault KV secret engine API, version 2: Create a policy to restrict the users to perform a write or delete operation on the secret: Create a token that matches the above policy:

Commands:
vault secrets enable -path=odf kv
vault secrets enable -path=odf kv-v2
echo ' path "odf/*" { capabilities = ["create", "read", "update", "delete", "list"] } path "sys/mounts" { capabilities = ["read"] }'| vault policy write odf -
vault token create -policy=odf -format json
10.6. Cloning TKS Subsystems Configure the master subsystem and back up the keys. Create the clone subsystem instance using the pkispawn utility. An example of the configuration file required by pkispawn when cloning TKS subsystems: Restart the clone instance. For the TKS, enroll a smart card and then run an ldapsearch to make sure that the same key information is contained in both databases.

Commands:
pkispawn -s <subsystem> -f myconfig.txt
[DEFAULT] pki_admin_password= <Secret.123> pki_client_database_password= <Secret.123> pki_client_pkcs12_password= <Secret.123> pki_ds_password= <Secret.123> pki_security_domain_password= <Secret.123> pki_security_domain_hostname= <master_ca_hostname> pki_security_domain_https_port= <master_ca_https_port> pki_security_domain_user=caadmin [TKS] pki_clone=True pki_clone_pkcs12_password= <Secret.123> pki_clone_pkcs12_path= <path_to_pkcs12_file> pki_clone_replicate_schema=True pki_clone_uri=https:// <master_subsystem_host:master_subsystem_https_port> pki_issuing_ca=https:// <ca_hostname:ca_https_port>
pki-server restart instance_name
Chapter 8. Upgrading the overcloud Upgrade Red Hat OpenStack Platform content across the whole overcloud on each stack in your environment. 8.1. Upgrading RHOSP on all nodes in each stack Upgrade all overcloud nodes to Red Hat OpenStack Platform (RHOSP) 17.1 for each stack, starting with the main stack. Note You must ensure that the pacemaker is running on all controllers before you upgrade the overcloud nodes. For information about the duration and impact of this upgrade procedure, see Upgrade duration and impact . Procedure Log in to the undercloud host as the stack user. Source the stackrc undercloud credentials file: Upgrade RHOSP on all nodes in your main stack: Important Do not modify the --limit option. You must upgrade all nodes in the stack at once to avoid breaking your workloads. If you need assistance, contact Red Hat Support. Replace <stack> with the name of the overcloud stack that you want to upgrade the nodes on. Repeat this step for each stack in your RHOSP deployment. Note If you have a multi-cell environment, you must upgrade RHOSP on the cell stacks before you upgrade RHOSP on the overcloud stack.

Commands:
source ~/stackrc
openstack overcloud upgrade run --yes --stack <stack> --debug --limit allovercloud,undercloud --playbook all
6.6. RHEA-2015:1364 - new packages: scap-workbench New scap-workbench packages are now available for Red Hat Enterprise Linux 6. The scap-workbench packages provide a GUI utility for scanning Security Content Automation Protocol (SCAP) content. This enhancement update adds the scap-workbench packages to Red Hat Enterprise Linux 6. (BZ# 1152954 ) All users who require scap-workbench are advised to install these new packages.

Commands:
12.2. Types The main permission control method used in SELinux targeted policy to provide advanced process isolation is Type Enforcement. All files and processes are labeled with a type: types define a SELinux domain for processes and a SELinux type for files. SELinux policy rules define how types access each other, whether it be a domain accessing a type, or a domain accessing another domain. Access is only allowed if a specific SELinux policy rule exists that allows it. The following types are used with Postfix. Different types all you to configure flexible access: postfix_etc_t This type is used for configuration files for Postfix in the /etc/postfix/ directory. postfix_data_t This type is used for Postfix data files in the /var/lib/postfix/ directory. postfix_var_run_t This type is used for Postfix files stored in the /run/ directory. postfix_initrc_exec_t This type is used for transition of Postfix executable files to the postfix_initrc_t domain. postfix_spool_t This type is used for Postfix files stored in the /var/spool/ directory. Note To see the full list of files and their types for Postfix, run the following command:

Commands:
~]USD grep postfix /etc/selinux/targeted/contexts/files/file_contexts
Chapter 51. Data objects Data objects are the building blocks for the rule assets that you create. Data objects are custom data types implemented as Java objects in specified packages of your project. For example, you might create a Person object with data fields Name , Address , and DateOfBirth to specify personal details for loan application rules. These custom data types determine what data your assets and your decision services are based on. 51.1. Creating data objects The following procedure is a generic overview of creating data objects. It is not specific to a particular business asset. Procedure In Business Central, go to Menu Design Projects and click the project name. Click Add Asset Data Object . Enter a unique Data Object name and select the Package where you want the data object to be available for other rule assets. Data objects with the same name cannot exist in the same package. In the specified DRL file, you can import a data object from any package. Importing data objects from other packages You can import an existing data object from another package directly into the asset designers like guided rules or guided decision table designers. Select the relevant rule asset within the project and in the asset designer, go to Data Objects New item to select the object to be imported. To make your data object persistable, select the Persistable checkbox. Persistable data objects are able to be stored in a database according to the JPA specification. The default JPA is Hibernate. Click Ok . In the data object designer, click add field to add a field to the object with the attributes Id , Label , and Type . Required attributes are marked with an asterisk (*). Id: Enter the unique ID of the field. Label: (Optional) Enter a label for the field. Type: Enter the data type of the field. List: (Optional) Select this check box to enable the field to hold multiple items for the specified type. Figure 51.1. Add data fields to a data object Click Create to add the new field, or click Create and continue to add the new field and continue adding other fields. Note To edit a field, select the field row and use the general properties on the right side of the screen.

Commands:
Preface Red Hat OpenShift Data Foundation supports deployment on any platform that you provision including bare metal, virtualized, and cloud environments. Both internal and external OpenShift Data Foundation clusters are supported on these environments. See Planning your deployment and Preparing to deploy OpenShift Data Foundation for more information about deployment requirements. To deploy OpenShift Data Foundation, follow the appropriate deployment process based on your requirement: Internal mode Deploy using local storage devices Deploy standalone Multicloud Object Gateway component External mode

Commands:
Chapter 6. Configuring a GFS2 File System in a Pacemaker Cluster The following procedure is an outline of the steps required to set up a Pacemaker cluster that includes a GFS2 file system. On each node in the cluster, install the High Availability and Resilient Storage packages. Create the Pacemaker cluster and configure fencing for the cluster. For information on configuring a Pacemaker cluster, see Configuring the Red Hat High Availability Add-On with Pacemaker . On each node in the cluster, enable the clvmd service. If you will be using cluster-mirrored volumes, enable the cmirrord service. After you enable these daemons, when starting and stopping Pacemaker or the cluster through normal means using pcs cluster start , pcs cluster stop , service pacemaker start , or service pacemaker stop , the clvmd and cmirrord daemons will be started and stopped as needed. On one node in the cluster, perform the following steps: Set the global Pacemaker parameter no_quorum_policy to freeze . Note By default, the value of no-quorum-policy is set to stop , indicating that once quorum is lost, all the resources on the remaining partition will immediately be stopped. Typically this default is the safest and most optimal option, but unlike most resources, GFS2 requires quorum to function. When quorum is lost both the applications using the GFS2 mounts and the GFS2 mount itself cannot be correctly stopped. Any attempts to stop these resources without quorum will fail which will ultimately result in the entire cluster being fenced every time quorum is lost. To address this situation, you can set the no-quorum-policy=freeze when GFS2 is in use. This means that when quorum is lost, the remaining partition will do nothing until quorum is regained. After ensuring that the locking type is set to 3 in the /etc/lvm/lvm.conf file to support clustered locking, Create the clustered LV and format the volume with a GFS2 file system. Ensure that you create enough journals for each of the nodes in your cluster. Configure a clusterfs resource. You should not add the file system to the /etc/fstab file because it will be managed as a Pacemaker cluster resource. Mount options can be specified as part of the resource configuration with options= options . Run the pcs resource describe Filesystem command for full configuration options. This cluster resource creation command specifies the noatime mount option. Verify that GFS2 is mounted as expected. (Optional) Reboot all cluster nodes to verify GFS2 persistence and recovery.

Commands:
yum groupinstall 'High Availability' 'Resilient Storage'
chkconfig clvmd on chkconfig cmirrord on
pcs property set no-quorum-policy=freeze
pvcreate /dev/vdb vgcreate -Ay -cy cluster_vg /dev/vdb lvcreate -L5G -n cluster_lv cluster_vg mkfs.gfs2 -j2 -p lock_dlm -t rhel7-demo:gfs2-demo /dev/cluster_vg/cluster_lv
pcs resource create clusterfs Filesystem device="/dev/cluster_vg/cluster_lv" directory="/var/mountpoint" fstype="gfs2" "options=noatime" op monitor interval=10s on-fail=fence clone interleave=true
mount |grep /mnt/gfs2-demo /dev/mapper/cluster_vg-cluster_lv on /mnt/gfs2-demo type gfs2 (rw,noatime,seclabel)
3.5. Post-installation Considerations for Clients 3.5.1. Removing Pre-Identity Management Configuration The ipa-client-install script does not remove any LDAP and SSSD configuration from the /etc/openldap/ldap.conf and /etc/sssd/sssd.conf files. If you modified the configuration in these files before installing the client, the script adds the new client values, but comments them out. For example: To apply the new Identity Management configuration values: Open /etc/openldap/ldap.conf and /etc/sssd/sssd.conf . Delete the configuration. Uncomment the new Identity Management configuration. Server processes that rely on system-wide LDAP configuration might require a restart to apply the changes. Applications that use openldap libraries typically import the configuration when started.

Commands:
BASE dc=example,dc=com URI ldap://ldap.example.com #URI ldaps://server.example.com # modified by IPA #BASE dc=ipa,dc=example,dc=com # modified by IPA