mtpti5iD/redhat-docs_dataset huggingface dataset:
2.2. Optional Subscriptions and Repositories The packages provided in the following repositories are not required to install and configure a functioning Red Hat Virtualization environment. However, they are required to install packages that provide supporting functionality on virtual machines and client systems such as virtual machine resource monitoring. When one of these repositories is required to install a package, the steps required to enable the repository are provided in the appropriate location in the documentation. Table 2.4. Optional Subscriptions and Repositories Subscription Pool Repository Name Repository Label Details Red Hat Enterprise Linux Server Red Hat Enterprise Linux 7 Server - RH Common (v.7 Server for x86_64) rhel-7-server-rh-common-rpms Provides the ovirt-guest-agent-common package for Red Hat Enterprise Linux 7, which enables monitoring virtual machine resources on Red Hat Enterprise Linux 7 clients. Red Hat Enterprise Linux Server Red Hat Enterprise Virt Agent (v.6 Server for x86_64) rhel-6-server-rhv-4-agent-rpms Provides the ovirt-guest-agent-common package for Red Hat Enterprise Linux 6, which enables monitoring virtual machine resources on Red Hat Enterprise Linux 6 clients. Red Hat Enterprise Linux Server Red Hat Enterprise Virt Agent (v.5 Server for x86_64) rhel-5-server-rhv-4-agent-rpms Provides the rhevm-guest-agent package for Red Hat Enterprise Linux 5, which enables monitoring virtual machine resources on Red Hat Enterprise Linux 5 clients. Cinderlib for x86_64 Cinderlib option openstack-16-cinderlib-for-rhel-8-x86_64-rpms Provides cinderlib libraries for Cinderlib support in Red Hat Virtualization. Cinderlib for IBM POWER LE Cinderlib option for Power LE openstack-16-cinderlib-for-rhel-8-ppc64le-rpms Provides cinderlib libraries for Cinderlib support in Red Hat Virtualization.

Commands:
Chapter 6. Planning an SR-IOV deployment Optimize single root I/O virtualization (SR-IOV) deployments for NFV by setting individual parameters based on your Compute node hardware. To evaluate your hardware impact on the SR-IOV parameters, see Discovering your NUMA node topology . 6.1. Hardware partitioning for an SR-IOV deployment To achieve high performance with SR-IOV, partition the resources between the host and the guest. Figure 6.1. NUMA node topology A typical topology includes 14 cores per NUMA node on dual socket Compute nodes. Both hyper-threading (HT) and non-HT cores are supported. Each core has two sibling threads. One core is dedicated to the host on each NUMA node. The virtual network function (VNF) handles the SR-IOV interface bonding. All the interrupt requests (IRQs) are routed on the host cores. The VNF cores are dedicated to the VNFs. They provide isolation from other VNFs and isolation from the host. Each VNF must use resources on a single NUMA node. The SR-IOV NICs used by the VNF must also be associated with that same NUMA node. This topology does not have a virtualization overhead. The host, OpenStack Networking (neutron), and Compute (nova) configuration parameters are exposed in a single file for ease, consistency, and to avoid incoherence that is fatal to proper isolation, causing preemption, and packet loss. The host and virtual machine isolation depend on a tuned profile, which defines the boot parameters and any Red Hat OpenStack Platform modifications based on the list of isolated CPUs. 6.2. Topology of an NFV SR-IOV deployment The following image has two VNFs each with the management interface represented by mgt and the data plane interfaces. The management interface manages the ssh access, and so on. The data plane interfaces bond the VNFs to DPDK to ensure high availability, as VNFs bond the data plane interfaces using the DPDK library. The image also has two provider networks for redundancy. The Compute node has two regular NICs bonded together and shared between the VNF management and the Red Hat OpenStack Platform API management. Figure 6.2. NFV SR-IOV topology The image shows a VNF that uses DPDK at an application level, and has access to SR-IOV virtual functions (VFs) and physical functions (PFs), for better availability or performance, depending on the fabric configuration. DPDK improves performance, while the VF/PF DPDK bonds provide support for failover, and high availability. The VNF vendor must ensure that the DPDK poll mode driver (PMD) supports the SR-IOV card that is being exposed as a VF/PF. The management network uses OVS, therefore the VNF sees a mgmt network device using the standard virtIO drivers. You can use that device to initially connect to the VNF, and ensure that the DPDK application bonds the two VF/PFs. 6.3. Topology for NFV SR-IOV without HCI Observe the topology for SR-IOV without hyper-converged infrastructure (HCI) for NFV in the image below. It consists of compute and controller nodes with 1 Gbps NICs, and the director node. Figure 6.3. NFV SR-IOV topology without HCI

Commands:
Chapter 1. Upgrading Fuse on OpenShift Fuse 7.12 contains updates that enable it to work with OpenShift Container Platform (OCP) 4.9 or later. If you plan to upgrade to OCP 4.10, you must upgrade Fuse to version 7.11 before you upgrade OCP to version 4.10. Earlier versions of Fuse (prior to 7.10) do not support OCP 4.9 or later. For more information, see Fuse on OpenShift Guide .

Commands:
9.5. Designing an Account Lockout Policy An account lockout policy can protect both directory data and user passwords by preventing unauthorized or compromised access to the directory. After an account has been locked, or deactivated , that user cannot bind to the directory, and any authentication operation fails. Account deactivation is implemented through the operational attribute nsAccountLock . When an entry contains the nsAccountLock attribute with a value of true , the server rejects a bind attempt by that account. An account lockout policy can be defined based on specific, automatic criteria: An account lockout policy can be associated with the password policy ( Section 9.6, "Designing a Password Policy" ). When a user fails to log in with the proper credentials after a specified number of times, the account is locked until an administrator manually unlocks it. This protects against crackers who try to break into the directory by repeatedly trying to guess a user's password. An account can be locked after a certain amount of time has lapsed. This can be used to control access for temporary users - such as interns, students, or seasonal workers - who have time-limited access based on the time the account was created. Alternatively, an account policy can be created that inactivates user accounts if the account has been inactive for a certain amount of time since the last login time. A time-based account lockout policy is defined through the Account Policy Plug-in, which sets global settings for the directory. Multiple account policy subentries can be created for different expiration times and types and then applied to entries through classes of service. Additionally, a single user account or a set of accounts (through roles) can be deactivated manually. Note Deactivating a role deactivates all of the members of that role and not the role entry itself. For more information about roles, see Section 4.3.2, "About Roles" .

Commands:
Chapter 339. JSon or Yaml *Available as of Camel 3.1.0 The camel-openapi-java module supports both JSon and Yaml out of the box. You can specify in the request url what you want returned by using /openapi.json or /openapi.yaml for either one. If none is specified then the HTTP Accept header is used to detect if json or yaml can be accepted. If either both is accepted or none was set as accepted then json is returned as the default format.

Commands:
Chapter 1. Project APIs 1.1. Project [project.openshift.io/v1] Description Projects are the unit of isolation and collaboration in OpenShift. A project has one or more members, a quota on the resources that the project may consume, and the security controls on the resources in the project. Within a project, members may have different roles - project administrators can set membership, editors can create and manage the resources, and viewers can see but not access running containers. In a normal cluster project administrators are not able to alter their quotas - that is restricted to cluster administrators. Listing or watching projects will return only projects the user has the reader role on. An OpenShift project is an alternative representation of a Kubernetes namespace. Projects are exposed as editable to end users while namespaces are not. Direct creation of a project is typically restricted to administrators, while end users should use the requestproject resource. Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.2. ProjectRequest [project.openshift.io/v1] Description ProjectRequest is the set of options necessary to fully qualify a project request Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object

Commands:
Chapter 1. Knative Eventing Knative Eventing on OpenShift Container Platform enables developers to use an event-driven architecture with serverless applications. An event-driven architecture is based on the concept of decoupled relationships between event producers and event consumers. Event producers create events, and event sinks , or consumers, receive events. Knative Eventing uses standard HTTP POST requests to send and receive events between event producers and sinks. These events conform to the CloudEvents specifications , which enables creating, parsing, sending, and receiving events in any programming language. 1.1. Knative Eventing use cases: Knative Eventing supports the following use cases: Publish an event without creating a consumer You can send events to a broker as an HTTP POST, and use binding to decouple the destination configuration from your application that produces events. Consume an event without creating a publisher You can use a trigger to consume events from a broker based on event attributes. The application receives events as an HTTP POST. To enable delivery to multiple types of sinks, Knative Eventing defines the following generic interfaces that can be implemented by multiple Kubernetes resources: Addressable resources Able to receive and acknowledge an event delivered over HTTP to an address defined in the status.address.url field of the event. The Kubernetes Service resource also satisfies the addressable interface. Callable resources Able to receive an event delivered over HTTP and transform it, returning 0 or 1 new events in the HTTP response payload. These returned events may be further processed in the same way that events from an external event source are processed.

Commands:
Chapter 3. An active/passive NFS Server in a Red Hat High Availability Cluster This chapter describes how to configure a highly available active/passive NFS server on a two-node Red Hat Enterprise Linux High Availability Add-On cluster using shared storage. The procedure uses pcs to configure Pacemaker cluster resources. In this use case, clients access the NFS file system through a floating IP address. The NFS server runs on one of two nodes in the cluster. If the node on which the NFS server is running becomes inoperative, the NFS server starts up again on the second node of the cluster with minimal service interruption. This use case requires that your system include the following components: Two nodes, which will be used to create the cluster running the Apache HTTP server. In this example, the nodes used are z1.example.com and z2.example.com . A power fencing device for each node of the cluster. This example uses two ports of the APC power switch with a host name of zapc.example.com . A public virtual IP address, required for the NFS server. Shared storage for the nodes in the cluster, using iSCSI, Fibre Channel, or other shared network block device. Configuring a highly available active/passive NFS server on a two-node Red Hat Enterprise Linux High requires that you perform the following steps. Create the cluster that will run the NFS server and configure fencing for each node in the cluster, as described in Section 3.1, "Creating the NFS Cluster" . Configure an ext4 file system mounted on the LVM logical volume my_lv on the shared storage for the nodes in the cluster, as described in Section 3.2, "Configuring an LVM Volume with an ext4 File System" . Configure an NFS share on the shared storage on the LVM logical volume, as described in Section 3.3, "NFS Share Setup" . Ensure that only the cluster is capable of activating the LVM volume group that contains the logical volume my_lv , and that the volume group will not be activated outside of the cluster on startup, as described in Section 3.4, "Exclusive Activation of a Volume Group in a Cluster" . Create the cluster resources as described in Section 3.5, "Configuring the Cluster Resources" . Test the NFS server you have configured, as described in Section 3.6, "Testing the Resource Configuration" . 3.1. Creating the NFS Cluster Use the following procedure to install and create the NFS cluster. Install the cluster software on nodes z1.example.com and z2.example.com , using the procedure provided in Section 1.1, "Cluster Software Installation" . Create the two-node cluster that consists of z1.example.com and z2.example.com , using the procedure provided in Section 1.2, "Cluster Creation" . As in that example procedure, this use case names the cluster my_cluster . Configure fencing devices for each node of the cluster, using the procedure provided in Section 1.3, "Fencing Configuration" . This example configures fencing using two ports of the APC power switch with a host name of zapc.example.com .

Commands:
Chapter 9. Logging Logging is important in troubleshooting and debugging. protonJ2 uses slf4j as its logger for full configuration options see Slf4j Manual . 9.1. Configuring a simple logger with slf4j To configure a simple logger using slf4j create a file `simplelogger.properties and configure like so: Example Simple Logger 9.2. Enabling protocol logging The following code writes AMQP frames to the console. Example: Logging AMQP frames ConnectionOptions options = new ConnectionOptions(); options.traceFrames(true); Alternatively you get set the environment variable PN_TRACE_FRM to true;

Commands:
org.slf4j.simpleLogger.logFile=System.out org.slf4j.simpleLogger.defaultLogLevel=warn org.slf4j.simpleLogger.showDateTime=true org.slf4j.simpleLogger.dateTimeFormat=yyyy-MM-dd HH:mm:ss,SSS org.slf4j.simpleLogger.log.org.apache.qpid.protonj2=warn org.slf4j.simpleLogger.log.org.apache.qpid.protonj2.client=warn
ConnectionOptions options = new ConnectionOptions(); options.traceFrames(true);
2.5. Persistence and Firewall Marks with Keepalived In certain situations, it may be desirable for a client to reconnect repeatedly to the same real server, rather than have a load balancing algorithm send that request to the best available server. Examples of such situations include multi-screen web forms, cookies, SSL, and FTP connections. In these cases, a client may not work properly unless the transactions are being handled by the same server to retain context. Keepalived provides two different features to handle this: persistence and firewall marks . 2.5.1. Persistence When enabled, persistence acts like a timer. When a client connects to a service, Load Balancer remembers the last connection for a specified period of time. If that same client IP address connects again within that period, it is sent to the same server it connected to previously - bypassing the load-balancing mechanisms. When a connection occurs outside the time window, it is handled according to the scheduling rules in place. Persistence also allows the administrator to specify a subnet mask to apply to the client IP address test as a tool for controlling what addresses have a higher level of persistence, thereby grouping connections to that subnet. Grouping connections destined for different ports can be important for protocols which use more than one port to communicate, such as FTP. However, persistence is not the most efficient way to deal with the problem of grouping together connections destined for different ports. For these situations, it is best to use firewall marks . 2.5.2. Firewall Marks Firewall marks are an easy and efficient way to group ports used for a protocol or group of related protocols. For instance, if Load Balancer is deployed to run an e-commerce site, firewall marks can be used to bundle HTTP connections on port 80 and secure, HTTPS connections on port 443. By assigning the same firewall mark to the virtual server for each protocol, state information for the transaction can be preserved because the LVS router forwards all requests to the same real server after a connection is opened. Because of its efficiency and ease-of-use, administrators of Load Balancer should use firewall marks instead of persistence whenever possible for grouping connections. However, administrators should still add persistence to the virtual servers in conjunction with firewall marks to ensure the clients are reconnected to the same server for an adequate period of time.

Commands:
2.2.8. Securing Sendmail Sendmail is a Mail Transfer Agent (MTA) that uses the Simple Mail Transfer Protocol (SMTP) to deliver electronic messages between other MTAs and to email clients or delivery agents. Although many MTAs are capable of encrypting traffic between one another, most do not, so sending email over any public networks is considered an inherently insecure form of communication. It is recommended that anyone planning to implement a Sendmail server address the following issues. 2.2.8.1. Limiting a Denial of Service Attack Because of the nature of email, a determined attacker can flood the server with mail fairly easily and cause a denial of service. By setting limits to the following directives in /etc/mail/sendmail.mc , the effectiveness of such attacks is limited. confCONNECTION_RATE_THROTTLE - The number of connections the server can receive per second. By default, Sendmail does not limit the number of connections. If a limit is set and reached, further connections are delayed. confMAX_DAEMON_CHILDREN - The maximum number of child processes that can be spawned by the server. By default, Sendmail does not assign a limit to the number of child processes. If a limit is set and reached, further connections are delayed. confMIN_FREE_BLOCKS - The minimum number of free blocks which must be available for the server to accept mail. The default is 100 blocks. confMAX_HEADERS_LENGTH - The maximum acceptable size (in bytes) for a message header. confMAX_MESSAGE_SIZE - The maximum acceptable size (in bytes) for a single message.

Commands:
23.9. Set the Root Password Setting up a root account and password is one of the most important steps during your installation. The root account is used to install packages, upgrade RPMs, and perform most system maintenance. Logging in as root gives you complete control over your system. Note The root user (also known as the superuser) has complete access to the entire system; for this reason, logging in as the root user is best done only to perform system maintenance or administration. Figure 23.31. Root Password Use the root account only for system administration. Create a non-root account for your general use and use the su command to change to root only when you need to perform tasks that require superuser authorization. These basic rules minimize the chances of a typo or an incorrect command doing damage to your system. Note To become root, type su - at the shell prompt in a terminal window and then press Enter . Then, enter the root password and press Enter . The installation program prompts you to set a root password [11] for your system. . You cannot proceed to the stage of the installation process without entering a root password. The root password must be at least six characters long; the password you type is not echoed to the screen. You must enter the password twice; if the two passwords do not match, the installation program asks you to enter them again. You should make the root password something you can remember, but not something that is easy for someone else to guess. Your name, your phone number, qwerty , password, root , 123456 , and anteater are all examples of bad passwords. Good passwords mix numerals with upper and lower case letters and do not contain dictionary words: Aard387vark or 420BMttNT , for example. Remember that the password is case-sensitive. If you write down your password, keep it in a secure place. However, it is recommended that you do not write down this or any password you create. Warning Do not use one of the example passwords offered in this manual. Using one of these passwords could be considered a security risk. To change your root password after you have completed the installation, run the passwd command as root . If you forget the root password, see Resolving Problems in System Recovery Modes in the Red Hat Enterprise Linux 6 Deployment Guide for instructions on how to set a new one. [11] A root password is the administrative password for your Red Hat Enterprise Linux system. You should only log in as root when needed for system maintenance. The root account does not operate within the restrictions placed on normal user accounts, so changes made as root can have implications for your entire system.

Commands:
Chapter 7. Configuring cost models to accurately report costs Now that you configured your integrations to collect cost and usage data in cost management, you can configure cost models to associate prices to metrics and usage. A cost model is a framework that uses raw costs and metrics to define calculations for the costs in cost management. You can record, categorize, and distribute the costs that the cost model generates to specific customers, business units, or projects. In Cost Models , you can complete the following tasks: Classifying your costs as infrastructure or supplementary costs Capturing monthly costs for OpenShift nodes and clusters Applying a markup to account for additional support costs To learn how to configure a cost model, see Using cost models .

Commands: