mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 3. Creating a Virtual Machine After you have installed the virtualization packages on your Red Hat Enterprise Linux 7 host system, you can create virtual machines and install guest operating systems using the virt-manager interface. Alternatively, you can use the virt-install command-line utility by a list of parameters or with a script. Both methods are covered by this chapter. 3.1. Guest Virtual Machine Deployment Considerations Various factors should be considered before creating any guest virtual machines. The role of a virtual machine should be evaluated before deployment, but regular monitoring and assessment based on variable factors (load, amount of clients) should also be performed. The factors include: Performance Guest virtual machines should be deployed and configured based on their intended tasks. Some guest systems (for instance, guests running a database server) may require special performance considerations. Guests may require more assigned CPUs or memory based on their role and projected system load. Input/Output requirements and types of Input/Output Some guest virtual machines may have a particularly high I/O requirement or may require further considerations or projections based on the type of I/O (for instance, typical disk block size access, or the amount of clients). Storage Some guest virtual machines may require higher priority access to storage or faster disk types, or may require exclusive access to areas of storage. The amount of storage used by guests should also be regularly monitored and taken into account when deploying and maintaining storage. Make sure to read all the considerations outlined in Red Hat Enterprise Linux 7 Virtualization Security Guide . It is also important to understand that your physical storage may limit your options in your virtual storage. Networking and network infrastructure Depending upon your environment, some guest virtual machines could require faster network links than other guests. Bandwidth or latency are often factors when deploying and maintaining guests, especially as requirements or load changes. Request requirements SCSI requests can only be issued to guest virtual machines on virtio drives if the virtio drives are backed by whole disks, and the disk device parameter is set to lun in the domain XML file , as shown in the following example:

Commands:
<devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='block' device='lun'>
Part V. Deprecated Functionality This part provides an overview of functionality that has been deprecated in all minor releases up to Red Hat Enterprise Linux 7.5. Deprecated functionality continues to be supported until the end of life of Red Hat Enterprise Linux 7. Deprecated functionality will likely not be supported in future major releases of this product and is not recommended for new deployments. For the most recent list of deprecated functionality within a particular major release, refer to the latest version of release documentation. Deprecated hardware components are not recommended for new deployments on the current or future major releases. Hardware driver updates are limited to security and critical fixes only. Red Hat recommends replacing this hardware as soon as reasonably feasible. A package can be deprecated and not recommended for further use. Under certain circumstances, a package can be removed from a product. Product documentation then identifies more recent packages that offer functionality similar, identical, or more advanced to the one deprecated, and provides further recommendations.

Commands:
Chapter 11. References The following references are pointers to additional information that is relevant to SELinux and Red Hat Enterprise Linux but beyond the scope of this guide. Note that due to the rapid development of SELinux, some of this material may only apply to specific releases of Red Hat Enterprise Linux. Books SELinux by Example Mayer, MacMillan, and Caplan Prentice Hall, 2007 Tutorials and Help Tutorials and talks from Russell Coker http://www.coker.com.au/selinux/talks/ibmtu-2004/ Generic Writing SELinux policy HOWTO http://www.lurking-grue.org/writingselinuxpolicyHOWTO.html Red Hat Knowledgebase https://access.redhat.com/knowledgebase General Information NSA SELinux main website http://www.nsa.gov/selinux/ SELinux NSA's Open Source Security Enhanced Linux http://www.oreilly.com/catalog/selinux/ Technology Integrating Flexible Support for Security Policies into the Linux Operating System (a history of Flask implementation in Linux) http://www.nsa.gov/research/_files/selinux/papers/selsymp2005.pdf A Security Policy Configuration for the Security-Enhanced Linux http://www.nsa.gov/research/_files/selinux/papers/policy/policy.shtml Community SELinux community page http://selinuxproject.org/ IRC irc.freenode.net, #selinux, #fedora-selinux, #security History Quick history of Flask http://www.cs.utah.edu/flux/fluke/html/flask.html Full background on Fluke http://www.cs.utah.edu/flux/fluke/html/index.html

Commands:
Viewing and managing system inventory Red Hat Insights 1-latest Using inventory to easily track and manage your infrastructure Red Hat Customer Content Services

Commands:
{ "name": "Inventory Export", "format": "json", "sources": [ { "application": "urn:redhat:application:inventory", "resource": "urn:redhat:application:inventory:export:systems" } ] }
{ "name": "Inventory Export multiple sources", "format": "json", "sources": [ { "application": "urn:redhat:application:inventory", "resource": "urn:redhat:application:inventory:export:systems", "filters": {} }, { "application": "urn:redhat:application:notifications", "resource": "urn:redhat:application:notifications:export:events", "filters": {} } ] }
probe::socket.recvmsg.return Name probe::socket.recvmsg.return - Return from Message being received on socket Synopsis Values success Was receive successful? (1 = yes, 0 = no) protocol Protocol value flags Socket flags value name Name of this probe state Socket state value size Size of message received (in bytes) or error code if success = 0 type Socket type value family Protocol family value Context The message receiver. Description Fires at the conclusion of receiving a message on a socket via the sock_recvmsg function.

Commands:
socket.recvmsg.return
Chapter 1. Preparing to deploy OpenShift Data Foundation Deploying OpenShift Data Foundation on OpenShift Container Platform using dynamic storage devices provides you with the option to create internal cluster resources. This will result in the internal provisioning of the base services, which helps to make additional storage classes available to applications. Before you begin the deployment of OpenShift Data Foundation, follow these steps: Setup a chrony server. See Configuring chrony time service and use knowledgebase solution to create rules allowing all traffic. Optional: If you want to enable cluster-wide encryption using the external Key Management System (KMS) HashiCorp Vault, follow these steps: Ensure that you have a valid Red Hat OpenShift Data Foundation Advanced subscription. To know how subscriptions for OpenShift Data Foundation work, see knowledgebase article on OpenShift Data Foundation subscriptions . When the Token authentication method is selected for encryption then refer to Enabling cluster-wide encryption with the Token authentication using KMS . When the Kubernetes authentication method is selected for encryption then refer to Enabling cluster-wide encryption with the Kubernetes authentication using KMS . Ensure that you are using signed certificates on your Vault servers. Note If you are using Thales CipherTrust Manager as your KMS, you will enable it during deployment. Minimum starting node requirements An OpenShift Data Foundation cluster is deployed with minimum configuration when the standard deployment resource requirement is not met. See Resource requirements section in Planning guide. Disaster recovery requirements [Technology Preview] Disaster Recovery features supported by Red Hat OpenShift Data Foundation require all of the following prerequisites to successfully implement a disaster recovery solution: A valid Red Hat OpenShift Data Foundation Advanced subscription A valid Red Hat Advanced Cluster Management for Kubernetes subscription To know how subscriptions for OpenShift Data Foundation work, see knowledgebase article on OpenShift Data Foundation subscriptions . For detailed requirements, see Configuring OpenShift Data Foundation Disaster Recovery for OpenShift Workloads guide, and Requirements and recommendations section of the Install guide in Red Hat Advanced Cluster Management for Kubernetes documentation.

Commands:
1.3.4. Cluster Configuration System The Cluster Configuration System (CCS) manages the cluster configuration and provides configuration information to other cluster components in a Red Hat cluster. CCS runs in each cluster node and makes sure that the cluster configuration file in each cluster node is up to date. For example, if a cluster system administrator updates the configuration file in Node A, CCS propagates the update from Node A to the other nodes in the cluster (refer to Figure 1.8, "CCS Overview" ). Figure 1.8. CCS Overview Other cluster components (for example, CMAN) access configuration information from the configuration file through CCS (refer to Figure 1.8, "CCS Overview" ). Figure 1.9. Accessing Configuration Information The cluster configuration file ( /etc/cluster/cluster.conf ) is an XML file that describes the following cluster characteristics: Cluster name - Displays the cluster name, cluster configuration file revision level, locking type (either DLM or GULM), and basic fence timing properties used when a node joins a cluster or is fenced from the cluster. Cluster - Displays each node of the cluster, specifying node name, node ID, number of quorum votes, and fencing method for that node. Fence Device - Displays fence devices in the cluster. Parameters vary according to the type of fence device. For example for a power controller used as a fence device, the cluster configuration defines the name of the power controller, its IP address, login, and password. Managed Resources - Displays resources required to create cluster services. Managed resources includes the definition of failover domains, resources (for example an IP address), and services. Together the managed resources define cluster services and failover behavior of the cluster services.

Commands:
Chapter 2. Non-interactively selecting a system-wide Red Hat build of OpenJDK version on RHEL If you have multiple versions of Red Hat build of OpenJDK installed on RHEL, you can select the default Red Hat build of OpenJDK version to use system-wide in a non-interactive way. This is useful for administrators who have root privileges on a Red Hat Enterprise Linux system and need to switch the default Red Hat build of OpenJDK on many systems in an automated way. Note If you do not have root privileges, you can select a Red Hat build of OpenJDK version by configuring the JAVA_HOME environment variable . Prerequisites You must have root privileges on the system. Multiple versions of Red Hat build of OpenJDK were installed using the yum package manager. Procedure Select the major Red Hat build of OpenJDK version to switch to. For example, for Red Hat build of OpenJDK 21, use java-17-openjdk . Verify that the active Red Hat build of OpenJDK version is the one you specified.

Commands:
PKG_NAME=java-17-openjdk JAVA_TO_SELECT=USD(alternatives --display java | grep "family USDPKG_NAME" | cut -d' ' -f1) alternatives --set java USDJAVA_TO_SELECT
java -version openjdk version "17" 2021-09-14 OpenJDK Runtime Environment 21.9 (build 17+35) OpenJDK 64-Bit Server VM 21.9 (build 17+35, mixed mode, sharing)
10.7. Manually Reviewing the Certificate Status Using the Command Line To review certificate requests, ensure that you are authenticated as an agent with proper permissions to approve certificate requests. For details about configuring the pki command-line interface, see Section 2.5.1.1, "pki CLI Initialization" . To review the requests: Display the list of pending certificate requests: This command lists all pending certificate requests. Download a particular certificate request: Open the request.xml file in an editor or a separate terminal, and review the contents of the request to ensure it is legitimate. Then answer the prompt: if the request is valid, answer " approve and press Enter . If the request is invalid, answer reject and press Enter . Organizations can subscribe semantic differences to reject and cancel ; both result in no certificate being issued.

Commands:
pki agent_authentication_parameters ca-cert-request-find --status pending
pki agent_authentication_parameters ca-cert-request-review id --file request.xml
5.7. Multipath Command Output When you create, modify, or list a multipath device, you get a display of the current device setup. The format is as follows. For each multipath device: For each path group: For each path: For example, the output of a multipath command might appear as follows: If the path is up and ready for I/O, the status of the path is ready or ghost . If the path is down, the status is faulty or shaky . The path status is updated periodically by the multipathd daemon based on the polling interval defined in the /etc/multipath.conf file. The dm status is similar to the path status, but from the kernel's point of view. The dm status has two states: failed , which is analogous to faulty , and active which covers all other path states. Occasionally, the path state and the dm state of a device will temporarily not agree. The possible values for online_status are running and offline . A status of offline means that this SCSI device has been disabled. Note When a multipath device is being created or modified, the path group status, the dm device name, the write permissions, and the dm status are not known. Also, the features are not always correct.

Commands:
action_if_any: alias (wwid_if_different_from_alias) dm_device_name_if_known vendor,product size=size features='features' hwhandler='hardware_handler' wp=write_permission_if_known
-+- policy='scheduling_policy' prio=prio_if_known status=path_group_status_if_known
`- host:channel:id:lun devnode major:minor dm_status_if_known path_status online_status
3600d0230000000000e13955cc3757800 dm-1 WINSYS,SF2372 size=269G features='0' hwhandler='0' wp=rw |-+- policy='round-robin 0' prio=1 status=active | `- 6:0:0:0 sdb 8:16 active ready running `-+- policy='round-robin 0' prio=1 status=enabled `- 7:0:0:0 sdf 8:80 active ready running
Chapter 2. Support policy for Red Hat build of OpenJDK Red Hat will support select major versions of Red Hat build of OpenJDK in its products. For consistency, these are the same versions that Oracle designates as long-term support (LTS) for the Oracle JDK. A major version of Red Hat build of OpenJDK will be supported for a minimum of six years from the time that version is first introduced. For more information, see the OpenJDK Life Cycle and Support Policy . Note RHEL 6 reached the end of life in November 2020. Because of this, Red Hat build of OpenJDK is not supporting RHEL 6 as a supported configuration. Important From November 2024 onward, Red Hat provides extended life cycle support phase 1 (ELS-1) support for new releases of Red Hat build of OpenJDK 11. For more information, see Red Hat build of OpenJDK 11 - Extended Life Cycle Support Phase 1 .

Commands:
Chapter 82. ExternalConfigurationEnv schema reference Used in: ExternalConfiguration Property Description name Name of the environment variable which will be passed to the Kafka Connect pods. The name of the environment variable cannot start with KAFKA_ or STRIMZI_ . string valueFrom Value of the environment variable which will be passed to the Kafka Connect pods. It can be passed either as a reference to Secret or ConfigMap field. The field has to specify exactly one Secret or ConfigMap. ExternalConfigurationEnvVarSource

Commands:
13.4. Subquery Optimization EXISTS subqueries are typically rewrite to "SELECT 1 FROM ..." to prevent unnecessary evaluation of SELECT expressions. Quantified compare SOME subqueries are always turned into an equivalent IN predicate or comparison against an aggregate value. e.g. col > SOME (select col1 from table) would become col > (select min(col1) from table) Uncorrelated EXISTs and scalar subquery that are not pushed to the source can be evaluated prior to source command formation. Correlated subqueries used in DELETEs or UPDATEs that are not pushed as part of the corresponding DELETE/UPDATE will cause JBoss Data Virtualization to perform row-by-row compensating processing. This will only happen if the affected table has a primary key. If it does not, then an exception will be thrown. WHERE or HAVING clause IN, Quantified Comparison, Scalar Subquery Compare, and EXISTs predicates can take the MJ (merge join), DJ (dependent join), or NO_UNNEST (no unnest) hints appearing just before the subquery. The MJ hint directs the optimizer to use a traditional, semijoin, or antisemijoin merge join if possible. The DJ is the same as the MJ hint, but additionally directs the optimizer to use the subquery as the independent side of a dependent join if possible. The NO_UNNEST hint, which supercedes the other hints, will direct the optimizer to leave the subquery in place. Example 13.2. Merge Join Hint Usage SELECT col1 from tbl where col2 IN /*+ MJ */ (SELECT col1 FROM tbl2) Example 13.3. Dependent Join Hint Usage SELECT col1 from tbl where col2 IN /*+ DJ */ (SELECT col1 FROM tbl2) Example 13.4. No Unnest Hint Usage SELECT col1 from tbl where col2 IN /*+ NO_UNNEST */ (SELECT col1 FROM tbl2) The system property org.teiid.subqueryUnnestDefault controls whether the optimizer will by default unnest subqueries. If true, then most non-negated WHERE or HAVING clause non-negated EXISTS or IN subquery predicates can be converted to a traditional join. The planner will always convert to anitjoin or semijoin vartiants is costing is favorable. Use a hint to override this behavior if needed. EXISTs and scalar subqueries that are not pushed down, and not converted to merge joins, are implicitly limited to 1 and 2 result rows respectively. Conversion of subquery predicates to nested loop joins is not yet available.

Commands:
SELECT col1 from tbl where col2 IN /*+ MJ */ (SELECT col1 FROM tbl2)
SELECT col1 from tbl where col2 IN /*+ DJ */ (SELECT col1 FROM tbl2)
SELECT col1 from tbl where col2 IN /*+ NO_UNNEST */ (SELECT col1 FROM tbl2)
Part I. Deploying a Red Hat Decision Manager environment on Red Hat OpenShift Container Platform 4 using Operators As a system engineer, you can deploy a Red Hat Decision Manager environment on Red Hat OpenShift Container Platform 4 to provide an infrastructure to develop or execute services and other business assets. You can use OpenShift Operators to deploy the environment defined in a structured YAML file and to maintain and modify this environment as necessary. Prerequisites A Red Hat OpenShift Container Platform 4 environment is available. For the exact versions of Red Hat OpenShift Container Platform that the current release supports, see Red Hat Decision Manager 7 Supported Configurations . The OpenShift project for the deployment is created. You are logged into the project using the OpenShift web console. The following resources are available on the OpenShift cluster. Depending on the application load, higher resource allocation might be necessary for acceptable performance. For an authoring environment, 4 gigabytes of memory and 2 virtual CPU cores for the Business Central pod. In a high-availability deployment, these resources are required for each replica and two replicas are created by default. 2 gigabytes of memory and 1 virtual CPU core for each replica of each KIE Server pod. In a high-availability authoring deployment, additional resources according to the configured defaults are required for the Red Hat AMQ, and Red Hat Data Grid pods. Note The default values for MaxMetaspaceSize are: Business Central images: 1024m KIE Server images: 512m For other images: 256m Dynamic persistent volume (PV) provisioning is enabled. Alternatively, if dynamic PV provisioning is not enabled, enough persistent volumes must be available. By default, the deployed components require the following PV sizes: By default, Business Central requires one 1Gi PV. You can change the PV size for Business Central persistent storage. If you intend to deploy a high-availability authoring environment, your OpenShift environment supports persistent volumes with ReadWriteMany mode. If your environment does not support this mode, you can use NFS to provision the volumes. For information about access mode support in OpenShift public and dedicated clouds, see Access Modes in Red Hat OpenShift Container Platform documentation.

Commands:
14.15.2.6. snapshot-list-domain List all of the available snapshots for the given domain, defaulting to show columns for the snapshot name, creation time, and domain state. To use, run: The remaining optional options are as follows: --parent adds a column to the output table giving the name of the parent of each snapshot. This option may not be used with --roots or --tree . --roots filters the list to show only the snapshots that have no parents. This option may not be used with --parent or --tree . --tree displays output in a tree format, listing just snapshot names. These three options are mutually exclusive. This option may not be used with --roots or --parent . --from filters the list to snapshots which are children of the given snapshot; or if --current is provided, will cause the list to start at the current snapshot. When used in isolation or with --parent , the list is limited to direct children unless --descendants is also present. When used with --tree , the use of --descendants is implied. This option is not compatible with --roots . Note that the starting point of --from or --current is not included in the list unless the --tree option is also present. --leaves is specified, the list will be filtered to just snapshots that have no children. Likewise, if --no-leaves is specified, the list will be filtered to just snapshots with children. (Note that omitting both options does no filtering, while providing both options will either produce the same list or error out depending on whether the server recognizes the options) Filtering options are not compatible with --tree .. --metadata is specified, the list will be filtered to just snapshots that involve libvirt metadata, and thus would prevent the undefining of a persistent domain, or be lost on destroy of a transient domain. Likewise, if --no-metadata is specified, the list will be filtered to just snapshots that exist without the need for libvirt metadata. --inactive is specified, the list will be filtered to snapshots that were taken when the domain was shut off. If --active is specified, the list will be filtered to snapshots that were taken when the domain was running, and where the snapshot includes the memory state to revert to that running state. If --disk-only is specified, the list will be filtered to snapshots that were taken when the domain was running, but where the snapshot includes only disk state. --internal is specified, the list will be filtered to snapshots that use internal storage of existing disk images. If --external is specified, the list will be filtered to snapshots that use external files for disk images or memory state.

Commands:
virsh snapshot-list domain [{--parent | --roots | --tree}] [{[--from] snapshot | --current} [--descendants]] [--metadata] [--no-metadata] [--leaves] [--no-leaves] [--inactive] [--active] [--internal] [--external]