mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 7. Concurrent Versioning System The Concurrent Versioning System (CVS) is a free revision-control system. It is used to monitor and keep track of modifications to a central set of files which are usually accessed by several different users. It is commonly used by programmers to manage a source code repository and is widely used by open source programmers. In Red Hat Enterprise Linux, the cvs package provides CVS. Run the rpm -q cvs command to see if the cvs package is installed. If it is not installed and you want to use CVS, run the following command as the root user to install it: 7.1. CVS and SELinux The cvs daemon runs as cvs_t . By default in Red Hat Enterprise Linux, CVS is only allowed to read and write certain directories. The label cvs_data_t defines which areas the cvs daemon has read and write access to. When using CVS with SELinux, assigning the correct label is essential for clients to have full access to the area reserved for CVS data.

Commands:
~]# yum install cvs
2.35. RHEA-2011:0805 - new package: qpid-qmf New qpid-qmf packages are now available for Red Hat Enterprise Linux 6. The qpid-qmf package provides an extensible management framework layered on QPID messaging. This enhancement update adds the qpid-qmf package. The qpid-qmf package is now the top-level package for various QMF components which were previously packaged in their own RPM packages (specifically, the python-qmf and qpid-cpp packages). (BZ# 691836 ) All users who require qpid-qmf should install this new package.

Commands:
Part IV. Designing and building cases for case management As a developer, you can use Business Central to configure Red Hat Process Automation Manager assets for case management. Case management differs from Business Process Management (BPM). It focuses more on the actual data being handled throughout the case rather than on the sequence of steps taken to complete a goal. Case data is the most important piece of information in automated case handling, while business context and decision-making are in the hands of the human case worker. Red Hat Process Automation Manager includes the IT_Orders sample project in Business Central. This document refers to the sample project to explain case management concepts and provide examples. The Getting started with case management tutorial describes how to create and test a new IT_Orders project in Business Central. After reviewing the concepts in this guide, follow the procedures in the tutorial to ensure that you are able to successfully create, deploy, and test your own case project. Prerequisites Red Hat JBoss Enterprise Application Platform 7.4 is installed. For information about installing Red Hat JBoss Enterprise Application Platform 7.4, see Red Hat JBoss Enterprise Application Platform 7.4 Installation Guide . Red Hat Process Automation Manager is installed. For information about installing Red Hat Process Automation Manager, see Planning a Red Hat Process Automation Manager installation . Red Hat Process Automation Manager is running and you can log in to Business Central with the user role. For information about users and permissions, see Planning a Red Hat Process Automation Manager installation . The Showcase application is deployed. For information about how to install and log in to the Showcase application, see Using the Showcase application for case management .

Commands:
17.11. Attaching a Virtual Network to a Guest To attach a virtual network to a guest: In the Virtual Machine Manager window, highlight the guest that will have the network assigned. Figure 17.20. Selecting a virtual machine to display From the Virtual Machine Manager Edit menu, select Virtual Machine Details . Click the Add Hardware button on the Virtual Machine Details window. In the Add new virtual hardware window, select Network from the left pane, and select your network name ( network1 in this example) from the Network source menu. Modify the MAC address, if necessary, and select a Device model . Click Finish . Figure 17.21. Select your network from the Add new virtual hardware window The new network is now displayed as a virtual network interface that will be presented to the guest upon launch. Figure 17.22. New network shown in guest hardware list

Commands:
1.3. Leveraging SELinux with sVirt sVirt integrates virtualization into the existing security framework provided by SELinux (Security-Enhanced Linux), applying Mandatory Access Control (MAC) to virtual machines. The main objective of sVirt is to protect hosts and guests from attacks via security vulnerabilities in the hypervisor. SELinux secures a system by applying access policy across different processes. sVirt extends this capability to hosts and guests by treating each guest as a process, allowing administrators to apply similar policies designed to prevent malicious guests from accessing restricted resources. For more information on sVirt, refer to Chapter 4, sVirt .

Commands:
8.6. Converting a Bond to a Team It is possible to convert existing bonding configuration files to team configuration files using the bond2team tool. It can convert bond configuration files in ifcfg format to team configuration files in either ifcfg or JSON format. Note that firewall rules, alias interfaces, and anything that might be tied to the original interface name can break after the renaming because the tool will only change the ifcfg file, nothing else. To see some examples of the command format, issue the following command: New files will be created in a directory whose name starts with /tmp/bond2team.XXXXXX/ , where XXXXXX is a random string. After creating the new configuration files, move the old bonding files to a backup folder and then move the new files to the /etc/sysconfig/network-scripts/ directory. Example 8.1. Convert a Bond to a Team To convert a current bond0 configuration to team ifcfg , issue a command as root : Note that this will retain the name bond0 . To use a new name to save the configuration, use the --rename as follows: add the --json option to output JSON format files instead of ifcfg files. See the teamd.conf(5) man page for examples of JSON format. Example 8.2. Convert a Bond to a Team and Specify the File Path To convert a current bond0 configuration to team ifcfg , and to manually specify the path to the ifcfg file, issue a command as root : add the --json option to output JSON format files instead of ifcfg files. Example 8.3. Create a Team Configuration Using Bond2team It is also possible to create a team configuration by supplying the bond2team tool with a list of bonding parameters. For example: Ports can also be supplied on the command line as follows: See the bond2team(1) man page for further details. For an explanation of bonding parameters, see Section 7.7, "Using Channel Bonding"

Commands:
~]USD bond2team --examples
~]# /usr/bin/bond2team --master bond0
~]# /usr/bin/bond2team --master bond0 --rename team0
~]# /usr/bin/bond2team --master bond0 --configdir /path/to/ifcfg-file
~]# /usr/bin/bond2team --bonding_opts "mode=1 miimon=500"
~]# /usr/bin/bond2team --bonding_opts "mode=1 miimon=500 primary=enp1s0 primary_reselect-0" --port enp1s0 --port enp2s0 --port enp3s0 --port enp4s0
Preface Ansible Automation Platform Central Authentication is a third-party identity provider (idP) solution, allowing for a simplified single sign-on solution that can be used across the Ansible Automation Platform. Platform administrators can utilize central authentication to test connectivity and authentication, as well as onboard new users and manage user permissions by configuring and assigning them to groups. Along with OpenID Connect-based and LDAP support, central authentication also provides a supported REST API which can be used to bootstrap customer usage.

Commands:
17.4. Distributed Task Failover Red Hat JBoss Data Grid's distributed execution framework supports task failover in the following cases: Failover due to a node failure where a task is executing. Failover due to a task failure; for example, if a Callable task throws an exception. The failover policy is disabled by default, and Runnable , Callable , and DistributedCallable tasks fail without invoking any failover mechanism. JBoss Data Grid provides a random node failover policy, which will attempt to execute a part of a Distributed task on another random node if one is available. A random failover execution policy can be specified using the following as an example: Example 17.3. Random Failover Execution Policy The DistributedTaskFailoverPolicy interface can also be implemented to provide failover management. Example 17.4. Distributed Task Failover Policy Interface Report a bug

Commands:
DistributedExecutorService des = new DefaultExecutorService(cache); DistributedTaskBuilder<Boolean> taskBuilder = des.createDistributedTaskBuilder(new SomeCallable()); taskBuilder.failoverPolicy(DefaultExecutorService.RANDOM_NODE_FAILOVER); DistributedTask<Boolean> distributedTask = taskBuilder.build(); Future<Boolean> future = des.submit(distributedTask); Boolean r = future.get();
/** * DistributedTaskFailoverPolicy allows pluggable fail over target selection for a failed remotely * executed distributed task. * */ public interface DistributedTaskFailoverPolicy { /** * As parts of distributively executed task can fail due to the task itself throwing an exception * or it can be an Infinispan system caused failure (e.g node failed or left cluster during task * execution etc). * * @param failoverContext * the FailoverContext of the failed execution * @return result the Address of the Infinispan node selected for fail over execution */ Address failover(FailoverContext context); /** * Maximum number of fail over attempts permitted by this DistributedTaskFailoverPolicy * * @return max number of fail over attempts */ int maxFailoverAttempts(); }
Chapter 4. Technology previews This section provides an overview of Technology Preview features introduced or updated in this release of Red Hat Ceph Storage. Important Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend using them for production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information on Red Hat Technology Preview features support scope, see the Technology Preview Features Support Scope . cephadm bootstrapping process supports Red Hat Enterprise Linux 9 With this release, the Red Hat Enterprise Linux 8 based storage cluster cephadm bootstrapping process supports Red Hat Enterprise Linux 9. The containers are Red Hat Enterprise Linux 8 that requires Red Hat Enterprise Linux 9 server. Ceph object gateway in multi-site replication setup now supports a subset of AWS bucket replication API functionality With this release, Ceph Object Gateway now supports a subset of AWS bucket replication API functionality including {Put, Get, Delete} Replication operations. This feature enables bucket-granularity replication and additionally provides end-user replication control with the caveat that currently, buckets can be replicated within zones in an existing Ceph Object Gateway multi-site replication setup. SQLite virtual file system (VFS) on top of RADOS is now available With this release, the new libcephsqlite RADOS client library provides SQLite virtual file system (VFS) on top of RADOS. The database and journals are striped over RADOS across multiple objects for virtually unlimited scaling and throughput only limited by the SQLite client. Applications using SQLite might change to the Ceph VFS with minimal changes, usually just by specifying the alternate VFS. ingress flag to deploy NFS Ganesha daemons With this release, the --ingress flag can be used to deploy one or more NFS Ganesha daemons. The ingress service provides load balancing and high-availability for the NFS servers.

Commands:
Chapter 6. Overcommitting with KVM The KVM hypervisor automatically overcommits CPUs and memory. This means that more virtualized CPUs and memory can be allocated to virtual machines than there are physical resources on the system. This is possible because most processes do not access 100% of their allocated resources all the time. As a result, under-utilized virtualized servers or desktops can run on fewer hosts, which saves a number of system resources, with the net effect of less power, cooling, and investment in server hardware. 6.1. Overcommitting Memory Guest virtual machines running on a KVM hypervisor do not have dedicated blocks of physical RAM assigned to them. Instead, each guest virtual machine functions as a Linux process where the host physical machine's Linux kernel allocates memory only when requested. In addition the host's memory manager can move the guest virtual machine's memory between its own physical memory and swap space. Overcommitting requires allotting sufficient swap space on the host physical machine to accommodate all guest virtual machines as well as enough memory for the host physical machine's processes. As a basic rule, the host physical machine's operating system requires a maximum of 4GB of memory along with a minimum of 4GB of swap space. For advanced instructions on determining an appropriate size for the swap partition, see the Red Hat KnowledgeBase . Important Overcommitting is not an ideal solution for general memory issues. The recommended methods to deal with memory shortage are to allocate less memory per guest, add more physical memory to the host, or utilize swap space. A virtual machine will run slower if it is swapped frequently. In addition, overcommitting can cause the system to run out of memory (OOM), which may lead to the Linux kernel shutting down important system processes. If you decide to overcommit memory, ensure sufficient testing is performed. Contact Red Hat support for assistance with overcommitting. Overcommitting does not work with all guest virtual machines, but has been found to work in a desktop virtualization setup with minimal intensive usage or running several identical guest virtual machines with kernel same-page merging (KSM). For more information on KSM and overcommitting, refer to Chapter 7, KSM . Important When device assignment is in use, all virtual machine memory must be statically pre-allocated to enable direct memory access (DMA) with the assigned device. Memory overcommit is therefore not supported with device assignment.

Commands:
Appendix I. General Ansible settings These are the most common configurable Ansible parameters. There are two sets of parameters depending on the deployment method, either bare-metal or containers. Note This is not an exhaustive list of all the available Ansible parameters. Bare-metal and Containers Settings monitor_interface The interface that the Ceph Monitor nodes listen on. Value User-defined Required Yes Notes Assigning a value to at least one of the monitor_* parameters is required. monitor_address The address that the Ceph Monitor nodes listen too. Value User-defined Required Yes Notes Assigning a value to at least one of the monitor_* parameters is required. monitor_address_block The subnet of the Ceph public network. Value User-defined Required Yes Notes Use when the IP addresses of the nodes are unknown, but the subnet is known. Assigning a value to at least one of the monitor_* parameters is required. ip_version Value ipv6 Required Yes, if using IPv6 addressing. public_network The IP address and netmask of the Ceph public network, or the corresponding IPv6 address, if using IPv6. Value User-defined Required Yes Notes For more information, see Verifying the Network Configuration for Red Hat Ceph Storage . cluster_network The IP address and netmask of the Ceph cluster network, or the corresponding IPv6 address, if using IPv6. Value User-defined Required No Notes For more information, see Verifying the Network Configuration for Red Hat Ceph Storage . configure_firewall Ansible will try to configure the appropriate firewall rules. Value true or false Required No Bare-metal -specific Settings ceph_origin Value repository or distro or local Required Yes Notes The repository value means Ceph will be installed through a new repository. The distro value means that no separate repository file will be added, and you will get whatever version of Ceph that is included with the Linux distribution. The local value means the Ceph binaries will be copied from the local machine. ceph_repository_type Value cdn or iso Required Yes ceph_rhcs_version Value 4 Required Yes ceph_rhcs_iso_path The full path to the ISO image. Value User-defined Required Yes, if ceph_repository_type is set to iso . Container -specific Settings ceph_docker_image Value rhceph/rhceph-4-rhel8 , or cephimageinlocalreg , if using a local Docker registry. Required Yes ceph_docker_image_tag Value The latest version of rhceph/rhceph-4-rhel8 or the customtag given during the local registry configuration. Required Yes containerized_deployment Value true Required Yes ceph_docker_registry Value registry.redhat.io , or LOCAL_FQDN_NODE_NAME , if using a local Docker registry. Required Yes

Commands:
8.201. ricci 8.201.1. RHBA-2014:1539 - ricci bug fix and enhancement update Updated ricci packages that fix several bugs and add two enhancements are now available for Red Hat Enterprise Linux 6. The ricci packages contain a daemon and a client for remote configuring and managing of clusters. Bug Fixes BZ# 996195 When starting a cluster with the "ccs --start[all]" command or stopping a cluster with the "--stop[all]" command, resources were enabled or disabled automatically. Consequently, if the user wanted a cluster service to start on startup, a cluster could not be started without enabling the service. This update adds "--nodisable" and "--noenable" flags to allow users to start a cluster without enabling or disabling the services on the node. As a result, the user can stop and start nodes on a cluster without affecting their startup services. BZ# 1025053 Previously, the user was unable to configure UID and GID entries for the corosync utility in the cluster.conf file. As a consequence, the user could not configure access to corosync with the User Manager GUI. With this update, "--setuidgid" and "--rmuidgid" options have been added to the ccs utility, which can configure UID and GID entries. BZ# 1090642 Prior to this update, the ccs utility did not properly dispose of temporary files created when editing the cluster.conf file locally with the "-f" option. Consequently, a large number of temporary files could be left in the temporary directory. With this update, ccs properly removes temporary files it creates, and the file system temporary directory no longer fills up with a large number of files if multiple ccs commands using the "-f" option are executed. BZ# 1044122 Due to a bug in the design of the reboot_now.xml file and persisting state of the task batch, the ricci daemon could cause an unintentional reboot loop and unnecessary clutter in the directory with batches. This update fixes the task scheduling before reboot and addresses the problem with stale files. As a result, ricci no longer causes reboot loops and no longer leaves stale files from finished batch processing behind needlessly. In addition, this update adds the following Enhancements BZ# 1055424 The cluster schema in the ricci packages, used by the ccs utility for offline validation, has been updated. This update includes new options in resource and fence agents packages, and in the rgmanager utility and fenced cluster daemons. BZ# 917809 As users use CCS on the local node most frequently, the "ccs -h localhost [command]" command has been shortened to "ccs [command]". Users of ricci are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 6. Publishing and running your playbooks in Ansible Automation Platform The following procedures describe how to deploy your new playbooks in your instance of Ansible Automation Platform so that you can use them to run automation jobs. 6.1. Saving your project in SCM Save your playbook project as a repository in your source control management system, for example GitHub. Procedure Initialize your project directory as a git repository. Push your project up to a source control system such as GitHub. 6.2. Running your playbook in Ansible Automation Platform To run your playbook in Ansible Automation Platform, you must create a project in automation controller for the repository where you stored your playbook project. You can then create a job template for each playbook from the project. Procedure In a browser, log in to automation controller. Configure a Source Control credential type for your source control system if necessary. See the Creating new credentials section of the Automation controller user guide for more details. In automation controller, create a project for the GitHub repository where you stored your playbook project. Refer to the Projects chapter of the Automation controller user guide . Create a job template that uses a playbook from the project that you created. Refer to the Job Templates chapter of the Automation controller user guide . Run your playbook from automation controller by launching the job template. Refer to the Launching a job template section of the Automation controller user guide .

Commands:
5.2. Network Security Recommended Practices Network security is a critical part of a secure virtualization infrastructure. Refer to the following recommended practices for securing the network: Ensure that remote management of the system takes place only over secured network channels. Tools such as SSH and network protocols such as TLS or SSL provide both authentication and data encryption to assist with secure and controlled access to systems. Ensure that guest applications transferring sensitive data do so over secured network channels. If protocols such as TLS or SSL are not available, consider using one like IPsec. Configure firewalls and ensure they are activated at boot. Only those network ports needed for the use and management of the system should be allowed. Test and review firewall rules regularly. 5.2.1. Securing Connectivity to Spice The Spice remote desktop protocol supports SSL/TLS which should be enabled for all of the Spice communication channels (main, display, inputs, cursor, playback, record).

Commands: