mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 5. Managing rules The MTR plugin comes with a core set of System rules for analyzing projects and identifying migration and modernization issues. You can create and import custom rulesets. 5.1. Viewing rules You can view system and custom rules, if any, for the MTR plugin. Prerequisites To view system rules, the MTR server must be running. Procedure Click the Rulesets tab. Expand System to view system rulesets or Custom to view custom rulesets. Expand a ruleset. Double-click a rule to open it in a viewer. Click the Source tab to view the XML source of the rule. 5.2. Creating a custom ruleset You can create a custom ruleset in the MTR perspective. See the Rule Development Guide to learn more about creating custom XML rules. Procedure Click the Rulesets tab. Click the Create Ruleset icon ( ). Select a project and a directory for the ruleset. Enter the file name. Note The file must have the extension .windup.xml . Enter a ruleset ID, for example, my-ruleset-id . Optional: Select Generate quickstart template to add basic rule templates to the file. Click Finish . The ruleset file opens in an editor and you can add and edit rules in the file. Click the Source tab to edit the XML source of the ruleset file. You can select the new ruleset when you create a run configuration. 5.3. Importing a custom ruleset You can import a custom ruleset into the MTR plugin to analyze your projects. Prerequisites Custom ruleset file with a .windup.xml extension. See the Rule Development Guide for information about creating rulesets. Procedure Click the Rulesets tab. Click the Import Ruleset icon ( ). Browse to and select the XML rule file to import. The custom ruleset is displayed when you expand Custom on the Rulesets tab. 5.4. Submitting a custom ruleset You can submit your custom ruleset for inclusion in the official MTR rule repository. This allows your custom rules to be reviewed and included in subsequent releases of MTR. Procedure Click the Rulesets tab. Click the Arrow icon ( ) and select Submit Ruleset . Complete the following fields: Summary : Describe the purpose of the rule. This becomes the title of the submission. Code Sample : Enter an example of the source code that the rule should run against. Description : Enter a brief description of the rule. Click Choose Files and select the ruleset file. Click Submit .

Commands:
4.7.3. Synchronizing Network Packet Filtering Rules If you are using iptables , you will need to synchronize the appropriate configuration file on the backup LVS router. If you alter the any network packet filter rules, enter the following command as root from the primary LVS router: scp /etc/sysconfig/iptables n.n.n.n :/etc/sysconfig/ In the command, replace n.n.n.n with the real IP address of the backup LVS router. either open an ssh session to the backup router or log into the machine as root and type the following command: /sbin/service iptables restart Once you have copied these files over to the backup router and started the appropriate services (see Section 2.1, "Configuring Services on the LVS Router" for more on this topic) you are ready to start the Load Balancer Add-On.

Commands:
Integrating Google Cloud data into cost management Cost Management Service 1-latest Learn how to add and configure your Google Cloud integration Red Hat Customer Content Services

Commands:
billing-export@red-hat-cost-management.iam.gserviceaccount.com
billing-export@red-hat-cost-management.iam.gserviceaccount.com
requests google-cloud-bigquery google-cloud-storage
name: Scheduler
month_end = now.replace(day=1) - timedelta(days=1) # delta = now.replace(day=1) - timedelta(days=query_range) # year = month_end.strftime("%Y") # month = month_end.strftime("%m") # day = month_end.strftime("%d")
Chapter 16. Overview of migration to Red Hat build of Kogito microservices You can migrate the decision service artifacts that you developed in Business Central to Red Hat build of Kogito microservices. Red Hat build of Kogito currently supports migration for the following types of decision services: Decision Model and Notation (DMN) models : You migrate DMN-based decision services by moving the DMN resources from KJAR artifacts to the respective Red Hat build of Kogito archetype. Predictive Model Markup Language (PMML) models : You migrate PMML-based prediction and prediction services by moving the PMML resources from KJAR artifacts to the respective Red Hat build of Kogito archetype. Drools Rule Language (DRL) rules : You migrate the DRL-based decision services by enclosing them in a Red Hat build of Quarkus REST endpoint. This approach of migration enables you to use major Quarkus features, such as hot reload and native compilation. The Quarkus features and the programming model of Red Hat build of Kogito enable the automatic generation of the Quarkus REST endpoints for implementation in your applications and services.

Commands:
A.5. Metric Configuration (using pmstore) Some metrics in PCP allow the modification of their values, especially in the case where the metric acts as a control variable. This is the case with the gsf2.control.* metrics with the GFS2 PMDA. This is achieved through the use of the pmstore command line tool. As with most of the other PCP tools, the pmstore tool normally changes the current value for the specified metric on the local system, but you can use the -h switch to allow the change of metric values on specified remote systems. For further information, see the pmstore (3) man page. As an example, the following command enables all of the GSF2 tracepoints on the local machine on a system with the GFS2 PMDA installed and loaded. When this command is run, the PMDA will switch on all of the GFS2 tracepoints in the debugfs file system. Table A.3, "Control Tracepoints" describes each of the control tracepoints and its usage. An explanation on the effect of each control tracepoint and its available options is available through the help switch in the pminfo tool. Table A.3. Control Tracepoints Control Metric Use and Available Options gfs2.contol.tracepoints.all The GFS2 tracepoint statistics can be manually controlled using 0 [off] or 1 [on]. Setting the value of the metric controls the behavior of the PMDA to whether it tries to collect from tracepoint metrics or not. gfs2.control.tracepoints.* The GFS2 tracepoint statistics can be manually controlled using 0 [off] or 1 [on]. Setting the value of the metric controls the behavior of the PMDA to whether it tries to collect from each specified tracepoint metric or not. gfs2.control.global_tracing The global tracing can be controlled using 0 [off] or 1 [on]. This is required to be on for most of the GFS2 metrics to function. gfs2.control.worst_glock Can be individually controlled whether on or off using the control metrics.0 [off] or 1 [on]. Setting the value of the metric controls the behavior of the PMDA to whether it tries to collect the lock_time metrics or not. The machine must have the GFS2 tracepoints available for the glock_lock_time based metrics to function. gfs2.control.latency The gfs2.latency statistics can be manually controlled using pmstore gfs2.control.latency 0 [off] or 1 [on]. Setting the value of the metric controls the behavior of the PMDA to whether it tries to collect the latency metrics or not. The machine must have the gfs2 tracepoints available for the latency metrics to function. gfs2.control.glock_threshold The number of glocks that will be processed and accepted over all ftrace statistics. This number can be manually altered using the pmstore tool in order to tailor the number of glocks processed. This value must be positive.

Commands:
pmstore gfs2.control.tracepoints.all 1 gfs2.control.tracepoints.all old value=0 new value=1
Chapter 3. Planning for Installation on the x86 Architecture 3.1. Upgrade or Install? There are two procedures available for upgrading your current system to the major version of Red Hat Enterprise Linux. To decide which procedure is the right one for your system, read the following descriptions: Clean Install A clean install is performed by backing up all data from the system, formatting disk partitions, performing an installation of Red Hat Enterprise Linux 7 from installation media, and then restoring any user data. Note This is the recommended method for upgrading between major versions of Red Hat Enterprise Linux. In-Place Upgrade An in-place upgrade is a way of upgrading your system without removing the older version first. The procedure requires installing the migration utilities available for your system and running them as any other software. In Red Hat Enterprise Linux, the Preupgrade Assistant assesses your current system and identifies potential problems you might encounter during and/or after the upgrade. It also performs minor fixes and modifications to the system. The Red Hat Upgrade Tool utility downloads the packages and performs the actual upgrade. An in-place upgrade requires a lot of troubleshooting and planning and should only be done if there is no other choice. For more information on the Preupgrade Assistant , see Chapter 37, Upgrading Your Current System . Warning Never perform an in-place upgrade on a production system without first testing it on a cloned backup copy of the system.

Commands:
Chapter 2. Setting up an unbound DNS server The unbound DNS server is a validating, recursive, and caching DNS resolver. Additionally, unbound focuses on security and has, for example, Domain Name System Security Extensions (DNSSEC) enabled by default. 2.1. Configuring Unbound as a caching DNS server By default, the unbound DNS service resolves and caches successful and failed lookups. The service then answers requests to the same records from its cache. Procedure Install the unbound package: Edit the /etc/unbound/unbound.conf file, and make the following changes in the server clause: Add interface parameters to configure on which IP addresses the unbound service listens for queries, for example: With these settings, unbound only listens on the specified IPv4 and IPv6 addresses. Limiting the interfaces to the required ones prevents clients from unauthorized networks, such as the internet, from sending queries to this DNS server. Add access-control parameters to configure from which subnets clients can query the DNS service, for example: Create private keys and certificates for remotely managing the unbound service: If you skip this step, verifying the configuration in the step will report the missing files. However, the unbound service automatically creates the files if they are missing. Verify the configuration file: Update the firewalld rules to allow incoming DNS traffic: Enable and start the unbound service: Verification Query the unbound DNS server listening on the localhost interface to resolve a domain: After querying a record for the first time, unbound adds the entry to its cache. Repeat the query: Because of the cached entry, further requests for the same record are significantly faster until the entry expires. steps Configure clients in your network to use this DNS server. For example, use the nmcli utility to set the IP of the DNS server in a NetworkManager connection profile: Additional resources unbound.conf(5) man page on your system

Commands:
yum install unbound
interface: 127.0.0.1 interface: 192.0.2.1 interface: 2001:db8:1::1
access-control: 127.0.0.0/8 allow access-control: 192.0.2.0/24 allow access-control: 2001:db8:1::/64 allow
systemctl restart unbound-keygen
unbound-checkconf unbound-checkconf: no errors in /etc/unbound/unbound.conf
firewall-cmd --permanent --add-service=dns firewall-cmd --reload
systemctl enable --now unbound
dig @ localhost www.example.com www.example.com. 86400 IN A 198.51.100.34 ;; Query time: 330 msec
dig @ localhost www.example.com www.example.com. 85332 IN A 198.51.100.34 ;; Query time: 1 msec
nmcli connection modify Example_Connection ipv4.dns 192.0.2.1 nmcli connection modify Example_Connection ipv6.dns 2001:db8:1::1
14.11.2.3. Creating and starting a storage pool from raw parameters This command creates and starts a pool object name from the raw parameters given. If --print-xml is specified, then it prints the XML of the storage pool object without creating the pool. Otherwise, the pool requires a type in order to be built. For all storage pool commands which require a type , the pool types must be separated by comma. The valid pool types include: dir , fs , netfs , logical , disk , iscsi , scsi , mpath , rbd , and sheepdog . In contrast, the following command creates, but does not start, a pool object name from the raw parameters given: If --print-xml is specified, then it prints the XML of the pool object without defining the pool. Otherwise, the pool has to have a specified type. For all storage pool commands which require a type , the pool types must be separated by comma. The valid pool types include: dir , fs , netfs , logical , disk , iscsi , scsi , mpath , rbd , and sheepdog . The pool-start pool-or-uuid starts the specified storage pool, which was previously defined but inactive.

Commands:
pool-create-as name --print-xml type source-host source-path source-dev source-name <target> --source-format format
pool-define-as name --print-xml type source-host source-path source-dev source-name <target> --source-format format
Chapter 1. Rust Toolset Rust Toolset is a Red Hat offering for developers on Red Hat Enterprise Linux (RHEL). It provides the rustc compiler for the Rust programming language, the Rust package manager Cargo, the rustfmt formatting tool, and required libraries. For Red Hat Enterprise Linux 8, Rust Toolset is available as a module. Rust Toolset is available as packages for Red Hat Enterprise Linux 9. 1.1. Rust Toolset components The following components are available as part of Rust Toolset: Name Version Description rust 1.79.0 The Rust compiler front-end for LLVM. cargo 1.79.0 A build system and dependency manager for Rust. rustfmt 1.79.0 A tool for automatic formatting of Rust code. 1.2. Rust Toolset compatibility Rust Toolset is available for Red Hat Enterprise Linux 8 and Red Hat Enterprise Linux 9 on the following architectures: AMD and Intel 64-bit 64-bit ARM IBM Power Systems, Little Endian 64-bit IBM Z 1.3. Installing Rust Toolset Complete the following steps to install Rust Toolset including all development and debugging tools as well as dependent packages. Note that Rust Toolset has a dependency on LLVM Toolset. Prerequisites All available Red Hat Enterprise Linux updates are installed. Procedure On Red Hat Enterprise Linux 8, install the rust-toolset module by running: On Red Hat Enterprise Linux 9, install the rust-toolset package by running: 1.4. Installing Rust documentation The The Rust Programming Language book is available as installable documentation. Prerequisites Rust Toolset is installed. For more information, see Installing Rust Toolset . Procedure To install the rust-doc package, run the following command: On Red Hat Enterprise Linux 8: You can find the The Rust Programming Language book under the following path: /usr/share/doc/rust/html/index.html . You can find the API documentation for all Rust code packages under the following path: /usr/share/doc/rust/html/std/index.html . On Red Hat Enterprise Linux 9: You can find the The Rust Programming Language book under the following path: /usr/share/doc/rust/html/index.html . You can find the API documentation for all Rust code packages under the following path: /usr/share/doc/rust/html/std/index.html . 1.5. Installing Cargo documentation The Cargo, Rust's Package Manager book is available as installable documentation for Cargo. Note From Rust Toolset 1.66.1, the cargo-doc package is included in the rust-doc package. Prerequisites Rust Toolset is installed. For more information, see Installing Rust Toolset . Procedure To install the cargo-doc package, run: On Red Hat Enterprise Linux 8: You can find the Cargo, Rust's Package Manager book under the following path: /usr/share/doc/cargo/html/index.html . On Red Hat Enterprise Linux 9: You can find the Cargo, Rust's Package Manager book under the following path: /usr/share/doc/cargo/html/index.html . 1.6. Additional resources For more information on the Rust programming language, see the official Rust documentation .

Commands:
yum module install rust-toolset
dnf install rust-toolset
yum install rust-doc
dnf install rust-doc
yum install cargo-doc
dnf install cargo-doc
Chapter 6. Input/Output 6.1. Features Red Hat Enterprise Linux 6 introduces a number of performance enhancements in the I/O stack: Solid state disks (SSDs) are now recognized automatically, and the performance of the I/O scheduler is tuned to take advantage of the high I/Os per second (IOPS) that these devices can perform. For information on tuning SSDs, see the Solid State Disk Deployment Guidelines chapter in the Red Hat Enterprise Linux 6 Storage Administration Guide . Discard support has been added to the kernel to report unused block ranges to the underlying storage. This helps SSDs with their wear-leveling algorithms. It also helps storage that supports logical block provisioning (a sort of virtual address space for storage) by keeping closer tabs on the actual amount of storage in-use. The file system barrier implementation was overhauled in Red Hat Enterprise Linux 6.1 to make it more performant. pdflush has been replaced by per-backing-device flusher threads, which greatly improves system scalability on configurations with large LUN counts.

Commands:
11.3. Preparing and Adding Local Storage 11.3.1. Preparing Local Storage A local storage domain can be set up on a host. When you set up a host to use local storage, the host is automatically added to a new data center and cluster that no other hosts can be added to. Multiple-host clusters require that all hosts have access to all storage domains, which is not possible with local storage. Virtual machines created in a single-host cluster cannot be migrated, fenced, or scheduled. Important On Red Hat Virtualization Host (RHVH), local storage should always be defined on a file system that is separate from / (root). Red Hat recommends using a separate logical volume or disk, to prevent possible loss of data during upgrades. Preparing Local Storage for Red Hat Enterprise Linux hosts On the host, create the directory to be used for the local storage: Ensure that the directory has permissions allowing read/write access to the vdsm user (UID 36) and kvm group (GID 36): Preparing Local Storage for Red Hat Virtualization Hosts Red Hat recommends creating the local storage on a logical volume as follows: Create a local storage directory: Mount the new local storage, and then modify the permissions and ownership: 11.3.2. Adding Local Storage Adding local storage to a host places the host in a new data center and cluster. The local storage configuration window combines the creation of a data center, a cluster, and storage into a single process. Procedure Click Compute Hosts and select the host. Click Management Maintenance and click OK . Click Management Configure Local Storage . Click the Edit buttons to the Data Center , Cluster , and Storage fields to configure and name the local storage domain. Set the path to your local storage in the text entry field. If applicable, click the Optimization tab to configure the memory optimization policy for the new local storage cluster. Click OK . Your host comes online in a data center of its own.

Commands:
mkdir -p /data/images
chown 36:36 /data /data/images chmod 0755 /data /data/images
mkdir /data lvcreate -L USDSIZE rhvh -n data mkfs.ext4 /dev/mapper/rhvh-data echo "/dev/mapper/rhvh-data /data ext4 defaults,discard 1 2" >> /etc/fstab mount /data
mount -a chown 36:36 /data /rhvh-data chmod 0755 /data /rhvh-data
Chapter 3. Features 3.1. New and Changed features 3.1.1. Spring Boot BOM From Red Hat support for Spring Boot 2.7 onward, the Spring Boot BOM (Bill of Materials) to manage dependencies for Red Hat supported components is not available. You can, however, manage these components individually in an application's pom.xml file as dependencies by specifying their groupId , artifactId , and version (GAV). For more information, see Migrating applications to Spring Boot 2.7 . 3.2. New features introduced in earlier 2.x releases 3.2.1. Deploy Spring Boot applications to OpenShift using the Dekorate Maven dependency Use the Dekorate Maven dependency to deploy your Spring Boot applications to OpenShift. The Fabric8 Maven plugin is no longer supported. For information about deploying your application to OpenShift, see Dekorate Guide for Spring Boot Developers . 3.2.2. OpenJDK11 OpenShift images support multiple architectures OpenJ9 images for IBM Z and IBM Power Systems have been deprecated. The following OpenJDK11 image has been updated to support multiple architectures: ubi8/openjdk-11 You can use the OpenJDK11 image with the following architectures: x86 (x86_64) s390x (IBM Z) ppc64le (IBM Power Systems) If you want to use the OpenJ9 Java Virtual Machine (JVM) with the OpenJDK11 images, see Java Change in Power and Z OpenShift Images . 3.2.3. Support for OpenJDK 8 OpenJDK 11 and OpenJDK 17 RHEL 8 Universal Base Images (UBI8) Spring Boot 2.7 introduces support for building and deploying Spring Boot applications to OpenShift with OCI-compliant Universal Base Images for Red Hat OpenJDK 8 , Red Hat OpenJDK 11 , and Red Hat OpenJDK 17 on RHEL 8 . The RHEL 8 OpenJDK Universal Base Images replace the RHEL 8 OpenJDK builder images supported by Red Hat for use with earlier releases of Red Hat Build of Spring Boot. The previously supported RHEL 8 OpenJDK base images are no longer supported for use with Red Hat Build of Spring Boot. 3.2.4. Spring Boot metering labels for OpenShift You can add metering labels to your Spring Boot pods and check Red Hat subscription details with the OpenShift Metering Operator. Note Do not add metering labels to any pods that an operator deploys and manages. Spring Boot should use the following metering labels: com.company: Red_Hat rht.prod_name: Red_Hat_Runtimes rht.prod_ver: 2023-Q4 rht.comp: Spring_Boot rht.comp_ver: 2.7.18 rht.subcomp: <leave_blank> rht.subcomp_t: application See Metering documentation for more information. For more information on labels, see Understanding how to update labels on nodes . 3.3. Deprecated features No features or functionalities are marked as deprecated in this release. 3.4. Technology Preview 3.4.1. Dekorate build hooks for deploying Spring Boot applications to OpenShift Container Platform You can use Dekorate to configure a Source-to-image build of your application that starts automatically after you compile your application with Maven. This functionality is provided as Technology Preview in Dekorate version 1.0.0 and later. Red Hat does not provide support for using this functionality in a production environment.

Commands:
macro::json_output_string_value Name macro::json_output_string_value - Output a string value. Synopsis Arguments name The name of the string metric. value The string value to output. Description The json_output_string_value macro is designed to be called from the 'json_data' probe in the user's script to output a metric's string value. This metric should have been added with json_add_string_metric .

Commands:
@json_output_string_value(name,value)
19.4. Memory Red Hat Gluster Storage does not consume significant compute resources from the storage nodes themselves. However, read intensive workloads can benefit greatly from additional RAM. 19.4.1. Virtual Memory Parameters The data written by the applications is aggregated in the operating system page cache before being flushed to the disk. The aggregation and writeback of dirty data is governed by the Virtual Memory parameters. The following parameters may have a significant performance impact: vm.dirty_ratio vm.dirty_background_ratio The appropriate values of these parameters vary with the type of workload: Large-file sequential I/O workloads benefit from higher values for these parameters. For small-file and random I/O workloads it is recommended to keep these parameter values low. The Red Hat Gluster Storage tuned profiles set the values for these parameters appropriately. Hence, it is important to select and activate the appropriate Red Hat Gluster Storage profile based on the workload.

Commands: