mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 10. Hardware Enablement genwqe-tools rebased to version 4.0.20 on IBM POWER The genwqe-tools packages have been rebased to version 4.0.20 for IBM POWER architectures. This version provides a number of bug fixes and enhancements over the version, most notably: CompressBound has been fixed Debugging tools have been added The genwqe_cksum tool has been fixed Missing manual pages in the spec file have been fixed New compiler warnings have been fixed Z_STREAM_END detection circumvention has been improved (BZ#1521050) Memory Mode for Optane DC Persistent Memory technology is fully supported Intel(R) Optane DC Persistent Memory storage devices provide data center-class persistent memory technology, which can significantly increase transaction throughput. To use the Memory Mode technology, your system does not require any special drivers or specific certification. Memory Mode is transparent to the operating system.

Commands:
Chapter 26. Customizing artifact repository properties In some cases, projects need to resolve external dependencies to build domain model JAR files. A repository contains the needed artifacts and has the following features: The repository is a Maven repository. All snapshots are time stamped. Assets are stored mostly in the local hard drive. By default, the artifact repository is in USDWORKING_DIRECTORY/repositories/kie . Procedure In Business Central, select the Admin icon in the top-right corner of the screen and select Artifact Repository . The Artifact Repository page opens. Make selections and enter information in the Properties section. Click Save .

Commands:
Chapter 6. Additional resources Migration Planning Guide Upgrading from RHEL 7 to RHEL 8 Upgrading from RHEL 6 to RHEL 8 How do I upgrade from RHEL 6 to RHEL 7 with SAP HANA How to create custom Preupgrade Assistant modules for upgrading from RHEL 6 to RHEL 7 Red Hat Upgrade Tool - rollbacks and cleanup after upgrading RHEL 6 to RHEL 7

Commands:
18.3.2. Basic Firewall Policies Establishing basic firewall policies creates a foundation for building more detailed, user-defined rules. Each iptables chain is comprised of a default policy, and zero or more rules which work in concert with the default policy to define the overall ruleset for the firewall. The default policy for a chain can be either DROP or ACCEPT. Security-minded administrators typically implement a default policy of DROP, and only allow specific packets on a case-by-case basis. For example, the following policies block all incoming and outgoing packets on a network gateway: It is also recommended that any forwarded packets - network traffic that is to be routed from the firewall to its destination node - be denied as well, to restrict internal clients from inadvertent exposure to the Internet. To do this, use the following rule: When you have established the default policies for each chain, you can create and save further rules for your particular network and security requirements. The following sections describe how to save iptables rules and outline some of the rules you might implement in the course of building your iptables firewall.

Commands:
iptables -P INPUT DROP iptables -P OUTPUT DROP
iptables -P FORWARD DROP
Chapter 2. 4.1 Release Notes 2.1. New Features This part describes new features and major enhancements introduced in Red Hat Update Infrastructure 4.1. Pulp packages upgraded to version 3.17.3 The Pulp packages have been upgraded to upstream version 3.17.3. Apart from providing a number of bug fixes and enhancements, this upgrade makes RHUI fully FIPS compliant. RHUI now supports CephFS You can now use the Ceph File System to store the remote share. For information on installing RHUI with CephFS, see Installing Red Hat Update Infrastructure . Repositories are now automatically exported With this update, repositories are now automatically exported. As a result, symlinks from packages and repository metadata files to binary blobs are created even before the content is requested for the first time. Consequently, CDS nodes can provide content even if the RHUA node is inaccessible. Proxy servers are now supported With this update, you can synchronize packages from the Red Hat CDN using a proxy server. To use this feature, you must run RHUI Installer with arguments that correspond to your proxy server configuration. For detailed instructions, see Installing Red Hat Update Infrastructure . Legacy CA certificates are now supported With this update, you can store CA certificates from older RHUI installations on CDS nodes. The certificates are stored in the /etc/pki/rhui/legacy directory. As a result, clients with certificates signed by legacy certificate authorities can now use RHUI. 2.2. Bug Fixes This part describes bugs fixed in Red Hat Update Infrastructure 4.1 that have a significant impact on users. Gunicorn log file now successfully logs new enteries Previously, when the Gunicorn logs were rotated by the logrotate utility, the main log file did not receive new entries. With this update, the issue has been fixed and the log file works as expected. CDS node installations no longer fail Previously, if the /var/lib/rhui/remote_share/rpm/ directory contained more than one version of the same package, the CDS nodes failed to install. With this update, the installation process cleans the directory before proceeding with the installation. As a result, the CDS node installations no longer fail.

Commands:
11.3. Interface Control Scripts The interface control scripts activate and deactivate system interfaces. There are two primary interface control scripts that call on control scripts located in the /etc/sysconfig/network-scripts/ directory: /sbin/ifdown and /sbin/ifup . The ifup and ifdown interface scripts are symbolic links to scripts in the /sbin/ directory. When either of these scripts are called, they require the value of the interface to be specified, such as: Warning The ifup and ifdown interface scripts are the only scripts that the user should use to bring up and take down network interfaces. The following scripts are described for reference purposes only. Two files used to perform a variety of network initialization tasks during the process of bringing up a network interface are /etc/rc.d/init.d/functions and /etc/sysconfig/network-scripts/network-functions . See Section 11.7, "Network Function Files" for more information. After verifying that an interface has been specified and that the user executing the request is allowed to control the interface, the correct script brings the interface up or down. The following are common interface control scripts found within the /etc/sysconfig/network-scripts/ directory: ifup-aliases Configures IP aliases from interface configuration files when more than one IP address is associated with an interface. ifup-ippp and ifdown-ippp Brings ISDN interfaces up and down. ifup-ipv6 and ifdown-ipv6 Brings IPv6 interfaces up and down. ifup-plip Brings up a PLIP interface. ifup-plusb Brings up a USB interface for network connections. ifup-post and ifdown-post Contains commands to be executed after an interface is brought up or down. ifup-ppp and ifdown-ppp Brings a PPP interface up or down. ifup-routes Adds static routes for a device as its interface is brought up. ifdown-sit and ifup-sit Contains function calls related to bringing up and down an IPv6 tunnel within an IPv4 connection. ifup-wireless Brings up a wireless interface. Warning Removing or modifying any scripts in the /etc/sysconfig/network-scripts/ directory can cause interface connections to act irregularly or fail. Only advanced users should modify scripts related to a network interface. The easiest way to manipulate all network scripts simultaneously is to use the /sbin/service command on the network service ( /etc/rc.d/init.d/network ), as illustrated by the following command: /sbin/service network action Here, action can be either start , stop , or restart . To view a list of configured devices and currently active network interfaces, use the following command:

Commands:
ifup eth0
/sbin/service network status
Appendix D. Managing Replicas at Domain Level 0 This appendix describes managing replicas at domain level 0 (see Chapter 7, Displaying and Raising the Domain Level ). For documentation on managing replicas at domain level 1 , see: Section 4.5, "Creating the Replica: Introduction" Chapter 6, Managing Replication Topology D.1. Replica Information File During the replica creation process, the ipa-replica-prepare utility creates a replica information file named after the replica server in the /var/lib/ipa/ directory. The replica information file is a GPG-encrypted file containing realm and configuration information for the master server. The ipa-replica-install replica setup script configures a Directory Server instance based on the information contained in the replica information file and initiates the replica initialization process, during which the script copies over data from the master server to the replica. A replica information file can only be used to install a replica on the specific machine for which it was created. It cannot be used to create multiple replicas on multiple machines.

Commands:
probe::nfs.fop.read_iter Name probe::nfs.fop.read_iter - NFS client read_iter file operation Synopsis nfs.fop.read_iter Values ino inode number file_name file name cache_time when we started read-caching this inode pos current position of file dev device identifier attrtimeo how long the cached information is assumed to be valid. We need to revalidate the cached attrs for this inode if jiffies - read_cache_jiffies > attrtimeo. count read bytes parent_name parent dir name cache_valid cache related bit mask flag

Commands:
Chapter 48. Storage Multi-queue I/O scheduling for SCSI Red Hat Enterprise Linux 7 includes a new multiple-queue I/O scheduling mechanism for block devices known as blk-mq. The scsi-mq package allows the Small Computer System Interface (SCSI) subsystem to make use of this new queuing mechanism. This functionality is provided as a Technology Preview and is not enabled by default. To enable it, add scsi_mod.use_blk_mq=Y to the kernel command line. Although blk-mq is intended to offer improved performance, particularly for low-latency devices, it is not guaranteed to always provide better performance. In particular, in some cases, enabling scsi-mq can result in significantly worse performance, especially on systems with many CPUs. (BZ#1109348) Targetd plug-in from the libStorageMgmt API Since Red Hat Enterprise Linux 7.1, storage array management with libStorageMgmt, a storage array independent API, has been fully supported. The provided API is stable, consistent, and allows developers to programmatically manage different storage arrays and utilize the hardware-accelerated features provided. System administrators can also use libStorageMgmt to manually configure storage and to automate storage management tasks with the included command-line interface. The Targetd plug-in is not fully supported and remains a Technology Preview. (BZ#1119909) SCSI-MQ as a Technology Preview in the qla2xxx and lpfc drivers The qla2xxx driver updated in Red Hat Enterprise Linux 7.4 can enable the use of SCSI-MQ (multiqueue) with the ql2xmqsupport=1 module parameter. The default value is 0 (disabled). The SCSI-MQ functionality is provided as a Technology Preview when used with the qla2xxx or the lpfc drivers. Note that a recent performance testing at Red Hat with async IO over Fibre Channel adapters using SCSI-MQ has shown significant performance degradation under certain conditions. (BZ#1414957) NVMe/FC available as a Technology Preview in Qlogic adapters using the qla2xxx driver The NVMe over Fibre Channel (NVMe/FC) transport type is available as a Technology Preview in Qlogic adapters using the qla2xxx driver. NVMe/FC is an additional fabric transport type for the Nonvolatile Memory Express (NVMe) protocol, in addition to the Remote Direct Memory Access (RDMA) protocol that was previously introduced in Red Hat Enterprise Linux. NVMe/FC provides a higher-performance, lower-latency I/O protocol over existing Fibre Channel infrastructure. This is especially important with solid-state storage arrays, because it allows the performance benefits of NVMe storage to be passed through the fabric transport, rather than being encapsulated in a different protocol, SCSI. Note that since Red Hat Enterprise Linux 7.6, NVMe/FC is fully supported with Broadcom Emulex Fibre Channel 32Gbit adapters using the lpfc driver. See the restrictions listed in the New Features part. (BZ# 1387768 , BZ#1454386)

Commands:
Appendix A. Sample environment file: creating a Ceph Storage cluster The following custom environment file uses many of the options described throughout Chapter 2, Preparing Ceph Storage nodes for overcloud deployment . This sample does not include any commented-out options. For an overview on environment files, see Environment Files (from the Advanced Overcloud Customization guide). /home/stack/templates/storage-config.yaml 1 The parameter_defaults section modifies the default values for parameters in all templates. Most of the entries listed here are described in Chapter 4, Customizing the Storage service . 2 If you are deploying the Ceph Object Gateway, you can use Ceph Object Storage ( ceph-rgw ) as a backup target. To configure this, set CinderBackupBackend to swift . See Section 4.2, "Enabling the Ceph Object Gateway" for details. 3 The CephAnsibleDisksConfig section defines a custom disk layout for deployments using BlueStore. 4 For each role, the *Count parameters assign a number of nodes while the Overcloud*Flavor parameters assign a flavor. For example, ControllerCount: 3 assigns 3 nodes to the Controller role, and OvercloudControlFlavor: control sets each of those roles to use the control flavor. See Section 7.1, "Assigning nodes and flavors to roles" for details. Note The CephMonCount , CephMdsCount , OvercloudCephMonFlavor , and OvercloudCephMdsFlavor parameters (along with the ceph-mon and ceph-mds flavors) will only be valid if you created a custom CephMON and CephMds role, as described in Chapter 3, Deploying Ceph services on dedicated nodes . 5 NeutronNetworkType: sets the network type that the neutron service should use (in this case, vxlan ).

Commands:
parameter_defaults: 1 CinderBackupBackend: ceph 2 CephAnsibleDisksConfig: 3 osd_scenario: lvm osd_objectstore: bluestore dmcrypt: true devices: - /dev/disk/by-path/pci-0000:03:00.0-scsi-0:0:10:0 - /dev/disk/by-path/pci-0000:03:00.0-scsi-0:0:11:0 - /dev/nvme0n1 ControllerCount: 3 4 OvercloudControlFlavor: control ComputeCount: 3 OvercloudComputeFlavor: compute CephStorageCount: 3 OvercloudCephStorageFlavor: ceph-storage CephMonCount: 3 OvercloudCephMonFlavor: ceph-mon CephMdsCount: 3 OvercloudCephMdsFlavor: ceph-mds NeutronNetworkType: vxlan 5
2.11. RHEA-2011:0811 - new package: iwl100-firmware A new iwl100-firmware package is now available. This package contains the firmware required by the iwlagn driver for Linux to support the iwl100 hardware. The firmware for the Crane Peak 1(100) Wifi network adaptor was not included with its driver (iwlagn) in the earlier release. This is now included with the driver in RHEL6.1. (BZ# 694078 ) All users requiring iwlagn should install this new package, which adds this enhancement.

Commands:
B.2. Installed Documentation man virsh and /usr/share/doc/libvirt- <version-number> - Contains sub-commands and options for the virsh virtual machine management utility as well as comprehensive information about the libvirt virtualization library API. /usr/share/doc/gnome-applet-vm- <version-number> - Documentation for the GNOME graphical panel applet that monitors and manages locally-running virtual machines. /usr/share/doc/libvirt-python- <version-number> - Provides details on the Python bindings for the libvirt library. The libvirt-python package allows python developers to create programs that interface with the libvirt virtualization management library. /usr/share/doc/python-virtinst- <version-number> - Provides documentation on the virt-install command that helps in starting installations of Fedora and Red Hat Enterprise Linux related distributions inside of virtual machines. /usr/share/doc/virt-manager- <version-number> - Provides documentation on the Virtual Machine Manager, which provides a graphical tool for administering virtual machines.

Commands:
Appendix A. Tips for Developers Every good programming textbook covers problems with memory allocation and the performance of specific functions. As you develop your software, be aware of issues that might increase power consumption on the systems on which the software runs. Although these considerations do not affect every line of code, you can optimize your code in areas which are frequent bottlenecks for performance. Some techniques that are often problematic include: using threads. unnecessary CPU wake-ups and not using wake-ups efficiently. If you must wake up, do everything at once (race to idle) and as quickly as possible. using [f]sync() unnecessarily. unnecessary active polling or using short, regular timeouts. (React to events instead). inefficient disk access. Use large buffers to avoid frequent disk access. Write one large block at a time. inefficient use of timers. Group timers across applications (or even across systems) if possible. excessive I/O, power consumption, or memory usage (including memory leaks) performing unnecessary computation. The following sections examine some of these areas in greater detail. A.1. Using Threads It is widely believed that using threads makes applications perform better and faster, but this is not true in every case. Python Python uses the Global Lock Interpreter , so threading is profitable only for larger I/O operations. Unladen-swallow is a faster implementation of Python with which you might be able to optimize your code. Perl Perl threads were originally created for applications running on systems without forking (such as systems with 32-bit Windows operating systems). In Perl threads, the data is copied for every single thread (Copy On Write). Data is not shared by default, because users should be able to define the level of data sharing. For data sharing the threads::shared module has to be included. However, data is not only then copied (Copy On Write), but the module also creates tied variables for the data, which takes even more time and is even slower. For more information, see Things you need to know before programming Perl ithreads . C C threads share the same memory, each thread has its own stack, and the kernel does not have to create new file descriptors and allocate new memory space. C can really use the support of more CPUs for more threads. Therefore, to maximize the performance of your threads, use a low-level language like C or C++. If you use a scripting language, consider writing a C binding. Use profilers to identify poorly performing parts of your code. See also Of Programmers And Hardware: Transcending The Gap .

Commands:
Chapter 102. TgzArtifact schema reference Used in: Plugin Property Property type Description type string Must be tgz . url string URL of the artifact which will be downloaded. Streams for Apache Kafka does not do any security scanning of the downloaded artifacts. For security reasons, you should first verify the artifacts manually and configure the checksum verification to make sure the same artifact is used in the automated build. Required for jar , zip , tgz and other artifacts. Not applicable to the maven artifact type. sha512sum string SHA512 checksum of the artifact. Optional. If specified, the checksum will be verified while building the new container. If not specified, the downloaded artifact will not be verified. Not applicable to the maven artifact type. insecure boolean By default, connections using TLS are verified to check they are secure. The server certificate used must be valid, trusted, and contain the server name. By setting this option to true , all TLS verification is disabled and the artifact will be downloaded, even when the server is considered insecure.

Commands:
Chapter 6. Pulling images from a container repository Pull images from the automation hub container registry to make a copy to your local machine. Automation hub provides the podman pull command for each latest image in the container repository. You can copy and paste this command into your terminal, or use podman pull to copy an image based on an image tag. 6.1. Prerequisites You must have permission to view and pull from a private container repository. 6.2. Pulling an image You can pull images from the automation hub container registry to make a copy to your local machine. Automation hub provides the podman pull command for each latest image in the container repository. Note If you need to pull container images from a password or token-protected registry, you must create a credential in automation controller before pulling the image. Procedure Navigate to Execution Environments . Select your container repository. In the Pull this image entry, click Copy to clipboard . Paste and run the command in your terminal. Verification Run podman images to view images on your local machine. 6.3. Syncing images from a container repository You can pull images from the automation hub container registry to sync an image to your local machine. Prerequisites You must have permission to view and pull from a private container repository. Procedure To sync an image from a remote container registry, you need to configure a remote registry. Navigate to Execution Environments Remote Registries . Add https://registry.redhat.io to the registry. Add any required credentials to authenticate. Note Some container registries are aggressive with rate limiting. It is advisable to set a rate limit under Advanced Options. Navigate to Execution Environments Execution Environments . Click Add execution environment in the page header. Select the registry you wish to pull from. The "name" field displays the name of the image that will show up as on your local registry. Note The "Upstream name" field is the name of the image on the remote server. For example if the upstream name is set to "alpine" and the "name" field to "local/alpine", the alpine image will be downloaded from the remote and renamed to local/alpine. It is advisable to set a list of tags to include or exclude. Syncing images with a large number of tags is time consuming and will use a lot of disk space. Additional resources See Red Hat Container Registry Authentication for a list of registries. 6.4. Additional resources See the What is Podman? documentation for options to use when pulling images.

Commands:
5.2. Uploading an AMI image to AWS This section describes how to upload an AMI image to AWS. Prerequisites Your system must be set up for uploading AWS images. You must have an AWS image created by Image Builder. Use the ami output type in CLI or Amazon Machine Image Disk (.ami) in GUI when creating the image. Procedure 1. Push the image to S3: 2. After the upload to S3 ends, import the image as a snapshot into EC2: Replace my-image with the name of the image. To track progress of the import, run: 3. Create an image from the uploaded snapshot by selecting the snapshot in the EC2 console, right clicking on it and selecting Create Image: Figure 5.1. Create Image 4. Select the Virtualization type of Hardware-assisted virtualization in the image you create: Figure 5.2. Virtualization type 5. Now you can run an instance using whatever mechanism you like (CLI or AWS Console) from the snapshot. Use your private key via SSH to access the resulting EC2 instance. Log in as ec2-user.

Commands:
USD AMI=8db1b463-91ee-4fd9-8065-938924398428-disk.ami
aws s3 cp USDAMI s3://USDBUCKET Completed 24.2 MiB/4.4 GiB (2.5 MiB/s) with 1 file(s) remaining
A printf '{ "Description": "my-image", "Format": "raw", "UserBucket": { "S3Bucket": "%s", "S3Key": "%s" } }' USDBUCKET USDAMI > containers.json
aws ec2 import-snapshot disk-container file://containers.json
aws ec2 describe-import-snapshot-tasks --filters Name=task-state,Values=active