mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 26. Device Mapper Multipathing (DM Multipath) and Storage for Virtual Machines Red Hat Enterprise Linux 7 supports DM Multipath and storage for virtual machines . 26.1. Storage for Virtual Machines Red Hat Enterprise Linux 7 supports the following file systems or online storage methods for virtual storage: Fibre Channel iSCSI NFS GFS2 Virtualization in Red Hat Enterprise Linux 7 uses libvirt to manage virtual instances. The libvirt utility uses the concept of storage pools to manage storage for virtualized guests. A storage pool is a storage that can be divided into smaller volumes or allocated directly to a guest. Volumes of a storage pool can be allocated to virtualized guests. Following are the categories of available storage pools: Local storage pools Local storage includes storage devices, files or directories directly attached to a host, local directories, directly attached disks, and LVM Volume Groups. Networked (shared) storage pools Networked storage covers storage devices shared over a network using standard protocols. It includes shared storage devices using Fibre Channel, iSCSI, NFS, GFS2, and SCSI RDMA protocols, and is a requirement for migrating virtualized guests between hosts. For more information on types of storage pool supported by Red Hat Enterprise Linux, see the Red Hat Virtualization Deployment and Administration Guide .

Commands:
8.8. Configuring nfsexport and nfsserver Resources This section describes the issues and considerations to take into account when configuring an nfsexport or an nfsserver resource. The nfsexport resource agent works with NFSv2 and NFSv3 clients. When using nfsexport , you must do the following: Ensure that nfs and nfslock are enabled at boot. Add RPCNFSDARGS="-N 4" to the /etc/sysconfig/nfs file on all cluster nodes. The "-N 4" option prevents NFSv4 clients from being able to connect to the server. Add STATDARG="-H /usr/sbin/clunfslock" to the /etc/sysconfig/nfs file on all cluster nodes. Add nfslock="1" to the service component in the cluster.conf file. Structure your service as follows: The nfsserver resource agent works with NFSv3 and NFSv4 clients. When using nfsserver , you must do the following: Ensure that nfs and nfslock are disabled at boot Ensure that nfslock="1" is not set for the service. Structure your service as follows: When configuring a system to use the nfsserver resource agent for use with NFSv3 and NFSv4, you must account for the following limitations: Configure only one nfsserver resource per cluster. If you require more, you must use restricted failover domains to ensure that the two services in question can never start on the same host. Do not reference a globally-configured nfsserver resource in more than one service. Do not mix old-style NFS services with the new nfsserver in the same cluster. Older NFS services required the NFS daemons to be running; nfsserver requires the daemons to be stopped when the service is started. When using multiple file systems, you will be unable to use inheritance for the exports; thus reuse of nfsclient resources in services with multiple file systems is limited. You may, however, explicitly define target and path attributes for as many nfsclients as you like.

Commands:
<service nfslock="1" ... > <fs name="myfs" ... > <nfsexport name="exports"> <nfsclient ref="client1" /> <nfsclient ref="client2" /> </nfsexport> </fs> <ip address="10.1.1.2" /> </service>
<service ... > <fs name="myfs" ... > <nfsserver name="server"> <nfsclient ref="client1" /> <nfsclient ref="client2" /> <ip address="10.1.1.2" /> </nfsserver> </fs> </service>
Chapter 14. Updating and upgrading the Load-balancing service Perform regular updates and upgrades so that you can get the latest Red Hat OpenStack Platform Load-balancing service (octavia) features and bug fixes. Section 14.1, "Updating and upgrading the Load-balancing service" Section 14.2, "Updating running Load-balancing service instances" 14.1. Updating and upgrading the Load-balancing service The Load-balancing service (octavia) is a part of a Red Hat OpenStack Platform (RHOSP) update or upgrade. Prerequisites Schedule a maintenance window to perform the upgrade, because during the upgrade the Load-balancing service control plane is not fully functional. Procedure Perform the RHOSP update as described in the Performing a minor update of Red Hat OpenStack Platform guide. After the maintenance release is applied, if you need to use new features, then rotate running amphorae to update them to the latest amphora image. Additional resources Performing a minor update of Red Hat OpenStack Platform guide Section 14.2, "Updating running Load-balancing service instances" Section 2.2, "Load-balancing service (octavia) feature support matrix" 14.2. Updating running Load-balancing service instances Periodically, you can update a running Load-balancing service instance (amphora) with a newer image. For example, you might want to update an amphora instance during the following events: An update or upgrade of Red Hat OpenStack Platform (RHOSP). A security update to your system. A change to a different flavor for the underlying virtual machine. During an RHOSP update or upgrade, director automatically downloads the default amphora image, uploads it to the overcloud Image service (glance), and then configures the Load-balancing service (octavia) to use the new image. When you fail over a load balancer, you force the Load-balancing service to start an instance (amphora) that uses the new amphora image. Prerequisites New images for amphora. These are available during an RHOSP update or upgrade. Procedure Source your credentials file. Example List the IDs for all of the load balancers that you want to update: Fail over each load balancer: Note When you start failing over the load balancers, monitor system utilization, and as needed, adjust the rate at which you perform failovers. A load balancer failover creates new virtual machines and ports, which might temporarily increase the load on OpenStack Networking. Monitor the state of the failed over load balancer: The update is complete when the load balancer status is ACTIVE . Additional resources loadbalancer in the Command line interface reference

Commands:
source ~/overcloudrc
openstack loadbalancer list -c id -f value
openstack loadbalancer failover <loadbalancer_id>
openstack loadbalancer show <loadbalancer_id>
2.5. Creating Control Groups Use the cgcreate command to create cgroups. The syntax for cgcreate is: where: -t (optional) - specifies a user (by user ID, uid) and a group (by group ID, gid) to own the tasks pseudofile for this cgroup. This user can add tasks to the cgroup. Note Note that the only way to remove a task from a cgroup is to move it to a different cgroup. To move a task, the user has to have write access to the destination cgroup; write access to the source cgroup is not necessary. -a (optional) - specifies a user (by user ID, uid) and a group (by group ID, gid) to own all pseudofiles other than tasks for this cgroup. This user can modify access of the tasks in this cgroup to system resources. -g - specifies the hierarchy in which the cgroup should be created, as a comma‐separated list of subsystems associated with hierarchies. If the subsystems in this list are in different hierarchies, the group is created in each of these hierarchies. The list of hierarchies is followed by a colon and the path to the child group relative to the hierarchy. Do not include the hierarchy mount point in the path. For example, the cgroup located in the directory /cgroup/cpu_and_mem/lab1/ is called just lab1 - its path is already uniquely determined because there is at most one hierarchy for a given subsystem. Note also that the group is controlled by all the subsystems that exist in the hierarchies in which the cgroup is created, even though these subsystems have not been specified in the cgcreate command - refer to Example 2.5, "cgcreate usage" . Because all cgroups in the same hierarchy have the same controllers, the child group has the same controllers as its parent. Example 2.5. cgcreate usage Consider a system where the cpu and memory subsystems are mounted together in the cpu_and_mem hierarchy, and the net_cls controller is mounted in a separate hierarchy called net . Run the following command: The cgcreate command creates two groups named test-subgroup , one in the cpu_and_mem hierarchy and one in the net hierarchy. The test-subgroup group in the cpu_and_mem hierarchy is controlled by the memory subsystem, even though it was not specified in the cgcreate command. Alternative method To create a child of the cgroup directly, use the mkdir command: For example:

Commands:
cgcreate -t uid : gid -a uid : gid -g subsystems : path
~]# cgcreate -g cpu,net_cls:/test-subgroup
~]# mkdir /cgroup/ hierarchy / name / child_name
~]# mkdir /cgroup/cpu_and_mem/group1
9.2. National Industrial Security Program Operating Manual (NISPOM) The NISPOM (also called DoD 5220.22-M), as a component of the National Industrial Security Program (NISP), establishes a series of procedures and requirements for all government contractors with regard to classified information. The current NISPOM is dated February 28, 2006, with incorporated major changes from March 28, 2013. The NISPOM document can be downloaded from the following URL: http://www.nispom.org/NISPOM-download.html .

Commands:
3.10. Power Capping Red Hat Enterprise Linux 7 supports the power capping features found in recent hardware, such as HP Dynamic Power Capping (DPC), and Intel Node Manager (NM) technology. Power capping allows administrators to limit the power consumed by servers, but it also allows managers to plan data centers more efficiently, because the risk of overloading existing power supplies is greatly diminished. Managers can place more servers within the same physical footprint and have confidence that if server power consumption is capped, the demand for power during heavy load will not exceed the power available. HP Dynamic Power Capping Dynamic Power Capping is a feature available on select ProLiant and BladeSystem servers that allows system administrators to cap the power consumption of a server or a group of servers. The cap is a definitive limit that the server will not exceed, regardless of its current workload. The cap has no effect until the server reaches its power consumption limit. At that point, a management processor adjusts CPU P-states and clock throttling to limit the power consumed. Dynamic Power Capping modifies CPU behavior independently of the operating system, however, HP's integrated Lights-Out 2 (iLO2) firmware allows operating systems access to the management processor and therefore applications in user space can query the management processor. The kernel used in Red Hat Enterprise Linux 7 includes a driver for HP iLO and iLO2 firmware, which allows programs to query management processors at /dev/hpilo/d X ccb N . The kernel also includes an extension of the hwmon sysfs interface to support power capping features, and a hwmon driver for ACPI 4.0 power meters that use the sysfs interface. Together, these features allow the operating system and user-space tools to read the value configured for the power cap, together with the current power usage of the system. For further details of HP Dynamic Power Capping, see the HPE Knowledge Article HP ProLiant Gen8 Server Series - Power Capping and Dynamic Power Capping Settings in iLO 4 and RBSU , available from https://support.hpe.com/hpsc/doc/public/display?docId=mmr_sf-EN_US000006556 . Intel Node Manager Intel Node Manager imposes a power cap on systems, using processor P-states and T-states to limit CPU performance and therefore power consumption. By setting a power management policy, administrators can configure systems to consume less power during times when system loads are low, for example, at night or on weekends. Intel Node Manager adjusts CPU performance using Operating System-directed configuration and Power Management (OSPM) through the standard Advanced Configuration and Power Interface . When Intel Node Manager notifies the OSPM driver of changes to T-states, the driver makes corresponding changes to processor P-states. Similarly, when Intel Node Manager notifies the OSPM driver of changes to P-states, the driver changes T-states accordingly. These changes happen automatically and require no further input from the operating system. Administrators configure and monitor Intel Node Manager with Intel Data Center Manager (DCM) software.

Commands:
Part II. Configuring Single-Node Messaging Systems Part II begins with a guide to getting started with JBoss EAP 7 messaging by using the helloworld-mdb quickstart. Configuration options available to any installation follow, including topics such as security and persistence. For configuration relating to multiple installations of JBoss EAP 7, including topics such as clustering, high availability, and connecting to another server, see Part III, Configuring Multi-Node Messaging Systems .

Commands:
Getting Started Guide Red Hat Single Sign-On 7.6 For Use with Red Hat Single Sign-On 7.6 Red Hat Customer Content Services

Commands:
unzip rhsso-7.6.zip or tar -xvzf rh-sso-7.6.tar.gz
> Expand-Archive -Path 'C:Downloads\rhsso-7.6.zip' -DestinationPath 'C:\Downloads'
./bin/jboss-cli.sh
> .\bin\jboss-cli.bat
patch apply <path-to-zip>/rh-sso-7.6.11-patch.zip
./bin/jboss-cli.sh --file=docs/examples/enable-elytron-se17.cli
> .\bin\jboss-cli.bat --file=docs\examples\enable-elytron-se17.cli
cd bin ./standalone.sh
> ...\bin\standalone.bat
unzip <filename>.zip
cd bin ./standalone.sh -Djboss.socket.binding.port-offset=100
> ...\bin\standalone.bat -Djboss.socket.binding.port-offset=100
> ...\bin\standalone.bat -D"jboss.socket.binding.port-offset=100"
unzip <filename>.zip
cd bin
./jboss-cli.sh --file=adapter-elytron-install-offline.cli
> jboss-cli.bat --file=adapter-elytron-install-offline.cli
./standalone.sh
> ...\standalone.bat
<subsystem xmlns="urn:jboss:domain:keycloak:1.1"/>
<subsystem xmlns="urn:jboss:domain:keycloak:1.1"> </subsystem>
<subsystem xmlns="urn:jboss:domain:keycloak:1.1"> <secure-deployment name="WAR MODULE NAME.war"> <realm>demo</realm> <auth-server-url>http://localhost:8180/auth</auth-server-url> <public-client>true</public-client> <ssl-required>EXTERNAL</ssl-required> <resource>vanilla</resource> </secure-deployment> </subsystem>
<subsystem xmlns="urn:jboss:domain:keycloak:1.1"> <secure-deployment name="vanilla.war"> </subsystem>
git clone https://github.com/redhat-developer/redhat-sso-quickstarts cd redhat-sso-quickstarts/app-profile-jee-vanilla/config
mvn clean wildfly:deploy
Appendix D. Working with files encrypted using Ansible Vault Red Hat recommends encrypting the contents of deployment and management files that contain passwords and other sensitive information. Ansible Vault is one method of encrypting these files. More information about Ansible Vault is available in the Ansible documentation . D.1. Encrypting files You can create an encrypted file by using the ansible-vault create command, or encrypt an existing file by using the ansible-vault encrypt command. When you create an encrypted file or encrypt an existing file, you are prompted to provide a password. This password is used to decrypt the file after encryption. You must provide this password whenever you work directly with information in this file or run a playbook that relies on the file's contents. Creating an encrypted file The ansible-vault create command prompts for a password for the new file, then opens the new file in the default text editor (defined as USDEDITOR in your shell environment) so that you can populate the file before saving it. If you have already created a file and you want to encrypt it, use the ansible-vault encrypt command. Encrypting an existing file D.2. Editing encrypted files You can edit an encrypted file using the ansible-vault edit command and providing the Vault password for that file. Editing an encrypted file The ansible-vault edit command prompts for a password for the file, then opens the file in the default text editor (defined as USDEDITOR in your shell environment) so that you can edit and save the file contents. D.3. Rekeying encrypted files to a new password You can change the password used to decrypt a file by using the ansible-vault rekey command. The ansible-vault rekey command prompts for the current Vault password, and then prompts you to set and confirm a new Vault password.

Commands:
ansible-vault create variables.yml New Vault password: Confirm New Vault password:
ansible-vault encrypt existing-variables.yml New Vault password: Confirm New Vault password: Encryption successful
ansible-vault edit variables.yml New Vault password: Confirm New Vault password:
ansible-vault rekey variables.yml Vault password: New Vault password: Confirm New Vault password: Rekey successful
Chapter 2. Introduction to Debezium Debezium is a distributed platform that converts information from your existing databases into event streams, enabling applications to detect, and immediately respond to row-level changes in the databases. Debezium is built on top of Apache Kafka and provides a set of Kafka Connect compatible connectors. Each of the connectors works with a specific database management system (DBMS). Connectors record the history of data changes in the DBMS by detecting changes as they occur, and streaming a record of each change event to a Kafka topic. Consuming applications can then read the resulting event records from the Kafka topic. By taking advantage of Kafka's reliable streaming platform, Debezium makes it possible for applications to consume changes that occur in a database correctly and completely. Even if your application stops unexpectedly, or loses its connection, it does not miss events that occur during the outage. After the application restarts, it resumes reading from the topic from the point where it left off. The tutorial that follows shows you how to deploy and use the Debezium MySQL connector with a simple configuration. For more information about deploying and using Debezium connectors, see the connector documentation. Additional resources Debezium connector for Db2 Debezium connector for MongoDB Debezium connector for MySQL Debezium connector for Oracle Database Debezium connector for PostgreSQL Debezium connector for SQL Server

Commands:
Chapter 7. Using pagination in the API The API paginates responses for collections. This means that while a collection might contain tens or hundreds of thousands of objects, in each web request, only a limited number of results are returned for API performance reasons. When you receive the result for a collection, something similar to the following appears: {'count': 25, '': 'http://testserver/api/v2/some_resource?page=2', '': None, 'results': [ ... ] } Procedure Request the page given by the "" sequential URL, to get to the page. Use the page_size=XX query string parameter to change the number of results returned for each request. The page_size has a default maximum limit of 200, which is enforced when a user tries a value beyond it, for example, ?page_size=1000 . However, you can change this limit by setting the value in /etc/tower/conf.d/<some file>.py to something higher. For example, MAX_PAGE_SIZE=1000 . Use the page query string parameter to retrieve a particular page of results: http://<server name>/api/v2/model_verbose_name?page_size=100&page=2 The preceding and following links returned with the results set these query string parameters automatically. Do not request page sizes greater than 200. The user interface uses smaller values to avoid scrolling.

Commands:
{'count': 25, 'next': 'http://testserver/api/v2/some_resource?page=2', 'previous': None, 'results': [ ... ] }
http://<server name>/api/v2/model_verbose_name?page_size=100&page=2
Chapter 12. ca This chapter describes the commands under the ca command. 12.1. ca get Retrieve a CA by providing its URI. Usage: Table 12.1. Positional arguments Value Summary URI The uri reference for the ca. Table 12.2. Command arguments Value Summary -h, --help Show this help message and exit Table 12.3. Output formatter options Value Summary -f {json,shell,table,value,yaml}, --format {json,shell,table,value,yaml} The output format, defaults to table -c COLUMN, --column COLUMN Specify the column(s) to include, can be repeated to show multiple columns Table 12.4. JSON formatter options Value Summary --noindent Whether to disable indenting the json Table 12.5. Shell formatter options Value Summary --prefix PREFIX Add a prefix to all variable names Table 12.6. Table formatter options Value Summary --max-width <integer> Maximum display width, <1 to disable. you can also use the CLIFF_MAX_TERM_WIDTH environment variable, but the parameter takes precedence. --fit-width Fit the table to the display width. implied if --max- width greater than 0. Set the environment variable CLIFF_FIT_WIDTH=1 to always enable --print-empty Print empty table if there is no data to show. 12.2. ca list List CAs. Usage: Table 12.7. Command arguments Value Summary -h, --help Show this help message and exit --limit LIMIT, -l LIMIT Specify the limit to the number of items to list per page (default: 10; maximum: 100) --offset OFFSET, -o OFFSET Specify the page offset (default: 0) --name NAME, -n NAME Specify the ca name (default: none) Table 12.8. Output formatter options Value Summary -f {csv,json,table,value,yaml}, --format {csv,json,table,value,yaml} The output format, defaults to table -c COLUMN, --column COLUMN Specify the column(s) to include, can be repeated to show multiple columns --sort-column SORT_COLUMN Specify the column(s) to sort the data (columns specified first have a priority, non-existing columns are ignored), can be repeated --sort-ascending Sort the column(s) in ascending order --sort-descending Sort the column(s) in descending order Table 12.9. CSV formatter options Value Summary --quote {all,minimal,none,nonnumeric} When to include quotes, defaults to nonnumeric Table 12.10. JSON formatter options Value Summary --noindent Whether to disable indenting the json Table 12.11. Table formatter options Value Summary --max-width <integer> Maximum display width, <1 to disable. you can also use the CLIFF_MAX_TERM_WIDTH environment variable, but the parameter takes precedence. --fit-width Fit the table to the display width. implied if --max- width greater than 0. Set the environment variable CLIFF_FIT_WIDTH=1 to always enable --print-empty Print empty table if there is no data to show.

Commands:
openstack ca get [-h] [-f {json,shell,table,value,yaml}] [-c COLUMN] [--noindent] [--prefix PREFIX] [--max-width <integer>] [--fit-width] [--print-empty] URI
openstack ca list [-h] [-f {csv,json,table,value,yaml}] [-c COLUMN] [--quote {all,minimal,none,nonnumeric}] [--noindent] [--max-width <integer>] [--fit-width] [--print-empty] [--sort-column SORT_COLUMN] [--sort-ascending | --sort-descending] [--limit LIMIT] [--offset OFFSET] [--name NAME]