mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 13. File-based configuration AMQ C++ can read the configuration options used to establish connections from a local file named connect.json . This enables you to configure connections in your application at the time of deployment. The library attempts to read the file when the application calls the container connect method without supplying any connection options. 13.1. File locations If set, AMQ C++ uses the value of the MESSAGING_CONNECT_FILE environment variable to locate the configuration file. If MESSAGING_CONNECT_FILE is not set, AMQ C++ searches for a file named connect.json at the following locations and in the order shown. It stops at the first match it encounters. On Linux: USDPWD/connect.json , where USDPWD is the current working directory of the client process USDHOME/.config/messaging/connect.json , where USDHOME is the current user home directory /etc/messaging/connect.json On Windows: %cd%/connect.json , where %cd% is the current working directory of the client process If no connect.json file is found, the library uses default values for all options. 13.2. The file format The connect.json file contains JSON data, with additional support for JavaScript comments. All of the configuration attributes are optional or have default values, so a simple example need only provide a few details: Example: A simple connect.json file { "host": "example.com", "user": "alice", "password": "secret" } SASL and SSL/TLS options are nested under "sasl" and "tls" namespaces: Example: A connect.json file with SASL and SSL/TLS options { "host": "example.com", "user": "ortega", "password": "secret", "sasl": { "mechanisms": ["SCRAM-SHA-1", "SCRAM-SHA-256"] }, "tls": { "cert": "/home/ortega/cert.pem", "key": "/home/ortega/key.pem" } } 13.3. Configuration options The option keys containing a dot (.) represent attributes nested inside a namespace. Table 13.1. Configuration options in connect.json Key Value type Default value Description scheme string "amqps" "amqp" for cleartext or "amqps" for SSL/TLS host string "localhost" The hostname or IP address of the remote host port string or number "amqps" A port number or port literal user string None The user name for authentication password string None The password for authentication sasl.mechanisms list or string None (system defaults) A JSON list of enabled SASL mechanisms. A bare string represents one mechanism. If none are specified, the client uses the default mechanisms provided by the system. sasl.allow_insecure boolean false Enable mechanisms that send cleartext passwords tls.cert string None The filename or database ID of the client certificate tls.key string None The filename or database ID of the private key for the client certificate tls.ca string None The filename, directory, or database ID of the CA certificate tls.verify boolean true Require a valid server certificate with a matching hostname

Commands:
host: example.com
user: alice
password: secret
{ "host": "example.com", "user": "ortega", "password": "secret", "sasl": { "mechanisms": ["SCRAM-SHA-1", "SCRAM-SHA-256"] }, "tls": { "cert": "/home/ortega/cert.pem", "key": "/home/ortega/key.pem" } }
Chapter 30. Manually Upgrading the Kernel The Red Hat Enterprise Linux kernel is custom-built by the Red Hat Enterprise Linux kernel team to ensure its integrity and compatibility with supported hardware. Before Red Hat releases a kernel, it must first pass a rigorous set of quality assurance tests. Red Hat Enterprise Linux kernels are packaged in the RPM format so that they are easy to upgrade and verify using the Yum or PackageKit package managers. PackageKit automatically queries the Red Hat Network servers and informs you of packages with available updates, including kernel packages. This chapter is therefore only useful for users who need to manually update a kernel package using the rpm command instead of yum . Warning Whenever possible, use either the Yum or PackageKit package manager to install a new kernel because they always install a new kernel instead of replacing the current one, which could potentially leave your system unable to boot. Warning Building a custom kernel is not supported by the Red Hat Global Services Support team, and therefore is not explored in this manual. For more information on installing kernel packages with Yum , see Section 8.1.2, "Updating Packages" . For information on Red Hat Network, see Chapter 6, Registering the System and Managing Subscriptions . 30.1. Overview of Kernel Packages Red Hat Enterprise Linux contains the following kernel packages: kernel - Contains the kernel for single, multicore and multiprocessor systems. kernel-debug - Contains a kernel with numerous debugging options enabled for kernel diagnosis, at the expense of reduced performance. kernel-devel - Contains the kernel headers and makefiles sufficient to build modules against the kernel package. kernel-debug-devel - Contains the development version of the kernel with numerous debugging options enabled for kernel diagnosis, at the expense of reduced performance. kernel-doc - Documentation files from the kernel source. Various portions of the Linux kernel and the device drivers shipped with it are documented in these files. Installation of this package provides a reference to the options that can be passed to Linux kernel modules at load time. By default, these files are placed in the /usr/share/doc/kernel-doc- <kernel_version> / directory. kernel-headers - Includes the C header files that specify the interface between the Linux kernel and user-space libraries and programs. The header files define structures and constants that are needed for building most standard programs. kernel-firmware - Contains all of the firmware files that are required by various devices to operate. perf - This package contains supporting scripts and documentation for the perf tool shipped in each kernel image subpackage.

Commands:
Chapter 40. Hardware Enablement LSI Syncro CS HA-DAS adapters Red Hat Enterprise Linux 7.1 included code in the megaraid_sas driver to enable LSI Syncro CS high-availability direct-attached storage (HA-DAS) adapters. While the megaraid_sas driver is fully supported for previously enabled adapters, the use of this driver for Syncro CS is available as a Technology Preview. Support for this adapter is provided directly by LSI, your system integrator, or system vendor. Users deploying Syncro CS on Red Hat Enterprise Linux 7.2 and later are encouraged to provide feedback to Red Hat and LSI. (BZ#1062759) Intel DIMM management tools As a Technology Preview, the following components have been added to enable the management of Intel Dual Inline Memory Modules (DIMMs). An API has been added for configuring DIMMs The libinvm-cli library, which supports storage command-line (CLI) applications The libinvm-cim library, which allows the use of storage common information model (CIM) providers The libinvm-i18n library, which provides internationalization functionality for DIMMs These enable the user to perform basic DIMM inventory, capacity provisioning, health monitoring, and troubleshooting. (BZ# 1270993 , BZ#1270998, BZ#1326924, BZ#1326931)

Commands:
Chapter 36. Subcases Subcases provide the flexibility to compose complex cases that consist of other cases. This means that you can split large and complex cases into multiple layers of abstraction and even multiple case projects. This is similar to splitting a process into multiple sub-processes. A subcase is another case definition that is invoked from within another case instance or a regular process instance. It has all of the capabilities of a regular case instance: It has a dedicated case file. It is isolated from any other case instance. It has its own set of case roles. It has its own case prefix. You can use the process designer to add subcases to your case definition. A subcase is a case within your case project, similar to having a sub-process within your process. Subcases can also be added to a regular business process. Doing this enables you to start a case from within a process instance. For more information about adding a subcase to your case definition, see Getting started with case management . The Sub Case Data I/O window supports the following set of input parameters that enable you to configure and start the subcase: Independent Optional indicator that tells the process engine whether or not the case instance is independent. If it is independent, the main case instance does not wait for its completion. The value of this property is false by default. GroupRole_XXX Optional group to case role mapping. The role names belonging to this case instance can be referenced here, meaning that participants of the main case can be mapped to participants of the subcase. This means that the group assigned to the main case is automatically assigned to the subcase, where XXX is the role name and the value of the property is the value of the group role assignment. DataAccess_XXX Optional data access restrictions where XXX is the name of the data item and the value of the property is the access restrictions. DestroyOnAbort Optional indicator that tells the process engine whether to cancel or destroy the subcase when the subcase activity is aborted. The default value is true . UserRole_XXX Optional user to case role mapping. You can reference the case instance role names here, meaning that an owner of the main case can be mapped to an owner of the subcase. The person assigned to the main case is automatically assigned to the subcase, where XXX is the role name and the value of the property is the value of the user role assignment. Data_XXX Optional data mapping from this case instance or business process to a subcase, where XXX is the name of the data in the subcase being targeted. This parameter can be provided as many times as needed. DeploymentId Optional deployment ID (or container ID in the context of KIE Server) that indicates where the targeted case definition is located. CaseDefinitionId The mandatory case definition ID to be started. CaseId The case instance ID of the subcase after it is started.

Commands:
Chapter 8. KafkaListenerAuthenticationScramSha512 schema reference Used in: GenericKafkaListener The type property is a discriminator that distinguishes use of the KafkaListenerAuthenticationScramSha512 type from KafkaListenerAuthenticationTls , KafkaListenerAuthenticationOAuth , KafkaListenerAuthenticationCustom . It must have the value scram-sha-512 for the type KafkaListenerAuthenticationScramSha512 . Property Property type Description type string Must be scram-sha-512 .

Commands:
3.4. Removing Control Groups Remove cgroups with the cgdelete command that has syntax similar to that of cgcreate . Enter the following command as root : where: controllers is a comma-separated list of controllers. path is the path to the cgroup relative to the root of the hierarchy. For example: cgdelete can also recursively remove all subgroups when the -r option is specified. Note that when you delete a cgroup, all its processes move to its parent group.

Commands:
~]# cgdelete controllers : path
~]# cgdelete net_prio:/test-subgroup
Chapter 6. Backing OpenShift Container Platform applications with OpenShift Data Foundation You cannot directly install OpenShift Data Foundation during the OpenShift Container Platform installation. However, you can install OpenShift Data Foundation on an existing OpenShift Container Platform by using the Operator Hub and then configure the OpenShift Container Platform applications to be backed by OpenShift Data Foundation. Prerequisites OpenShift Container Platform is installed and you have administrative access to OpenShift Web Console. OpenShift Data Foundation is installed and running in the openshift-storage namespace. Procedure In the OpenShift Web Console, perform one of the following: Click Workloads Deployments . In the Deployments page, you can do one of the following: Select any existing deployment and click Add Storage option from the Action menu (...). Create a new deployment and then add storage. Click Create Deployment to create a new deployment. Edit the YAML based on your requirement to create a deployment. Click Create . Select Add Storage from the Actions drop-down menu on the top right of the page. Click Workloads Deployment Configs . In the Deployment Configs page, you can do one of the following: Select any existing deployment and click Add Storage option from the Action menu (...). Create a new deployment and then add storage. Click Create Deployment Config to create a new deployment. Edit the YAML based on your requirement to create a deployment. Click Create . Select Add Storage from the Actions drop-down menu on the top right of the page. In the Add Storage page, you can choose one of the following options: Click the Use existing claim option and select a suitable PVC from the drop-down list. Click the Create new claim option. Select the appropriate CephFS or RBD storage class from the Storage Class drop-down list. Provide a name for the Persistent Volume Claim. Select ReadWriteOnce (RWO) or ReadWriteMany (RWX) access mode. Note ReadOnlyMany (ROX) is deactivated as it is not supported. Select the size of the desired storage capacity. Note You can expand the block PVs but cannot reduce the storage capacity after the creation of Persistent Volume Claim. Specify the mount path and subpath (if required) for the mount path volume inside the container. Click Save . Verification steps Depending on your configuration, perform one of the following: Click Workloads Deployments . Click Workloads Deployment Configs . Set the Project as required. Click the deployment for which you added storage to display the deployment details. Scroll down to Volumes and verify that your deployment has a Type that matches the Persistent Volume Claim that you assigned. Click the Persistent Volume Claim name and verify the storage class name in the Persistent Volume Claim Overview page.

Commands:
5.235. perl-IPC-Run3 5.235.1. RHBA-2012:1440 - perl-IPC-Run3 bug fix update Updated perl-IPC-Run3 packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The perl-IPC-Run3 packages provide a module to run subprocesses and redirect the stdin, stdout, and stderr functionalities to files and perl data structures. The perl-IPC-Run3 package allows to use system, qx, and open3 modules with a simple API. Bug Fixes BZ# 657487 Prior to this update, binary perl-IPC-Run3 packages failed to build if the perl-Time-HiRes module was not installed. This update adds the perl-Time-HiRes package to the build-time dependencies for perl-IPC-Run3. BZ# 870089 Prior to this update, tests that called the IP-Run3 profiler failed when the internal perl-IPC-Run3 test suite was used. This update, adds run-time dependencies on perl(Getopt::Long) and perl(Time::HiRes) to the perl-IPC-Run3 package because certain IP-Run3 functions require the perl modules. Now, the IPC-Run3 profiler runs as expected. All users of perl-IPC-Run3 are advised to upgrade to these updated packages, which fix these bugs.

Commands:
3.2. Operating System Details and Devices 3.2.1. Specifying Guest Virtual Machine Details The virt-manager tool provides different profiles depending on what operating system type and version are selected for a new guest virtual machine. When creating a guest, you should provide as many details as possible; this can improve performance by enabling features available for your specific type of guest. Refer to the following example screen capture of the virt-manager tool. When creating a new guest virtual machine, always specify your intended OS type and Version: Figure 3.1. Provide the OS type and Version

Commands:
15.3. Booleans SELinux is based on the least level of access required for a service to run. Services can be run in a variety of ways; therefore, you need to specify how you run your services. Use the following Booleans to set up SELinux: gluster_export_all_ro Having this Boolean enabled allows glusterfsd to share files and directory as read-only. This Boolean is disabled by default. gluster_export_all_rw Having this Boolean enabled allows glusterfsd to share files and directories with read and write access. This Boolean is enabled by default. gluster_anon_write Having this Boolean enabled allows glusterfsd to modify public files labeled with the public_content_rw_t SELinux type. Note Due to the continuous development of the SELinux policy, the list above might not contain all Booleans related to the service at all times. To list them, run the following command as root:

Commands:
~]# semanage boolean -l | grep service_name
10.7. Managing Core Configuration Using JBoss Management Console Log in to the JBoss Management Console. Select the Profile tab. From the navigation tree, select Subsystems Teiid . Select one of the following options: Query Engine - From here you can view and configure core query engine properties. Translators - From here you can view, add and remove translators. Transports - From here you can view, add and remove transports. View and modify configuration as necessary. Note If you need help at any stage, select the Need Help? link. Warning Some properties require you to restart the server before they will take effect.

Commands:
16.3. A Note About Linux Virtual Consoles This information only applies to users of non-partitioned System p systems using a video card as their console. Users of partitioned System p systems should skip to Section 16.4, "Using the HMC vterm" . The Red Hat Enterprise Linux installation program offers more than the dialog boxes of the installation process. Several kinds of diagnostic messages are available to you, as well as a way to enter commands from a shell prompt. The installation program displays these messages on five virtual consoles , among which you can switch using a single keystroke combination. A virtual console is a shell prompt in a non-graphical environment, accessed from the physical machine, not remotely. Multiple virtual consoles can be accessed simultaneously. These virtual consoles can be helpful if you encounter a problem while installing Red Hat Enterprise Linux. Messages displayed on the installation or system consoles can help pinpoint a problem. Refer to Table 16.1, "Console, Keystrokes, and Contents" for a listing of the virtual consoles, keystrokes used to switch to them, and their contents. Generally, there is no reason to leave the default console (virtual console #6) for graphical installations unless you are attempting to diagnose installation problems. Table 16.1. Console, Keystrokes, and Contents console keystrokes contents 1 ctrl + alt + f1 installation dialog 2 ctrl + alt + f2 shell prompt 3 ctrl + alt + f3 install log (messages from installation program) 4 ctrl + alt + f4 system-related messages 5 ctrl + alt + f5 other messages 6 ctrl + alt + f6 x graphical display

Commands:
Chapter 62. Virtualization Migration of certain guests from Red Hat Enterprise Linux 7.2 to 7.3 hosts is not possible Prior to this update, the PCI address of any USB controller that did not have an explicitly specified model value was ignored on IBM Power guest virtual machines. This bug has been fixed, but as a consequence of the fix, it is not possible to perform a live migration of guests that use the described USB controllers from a Red Hat Enterprise Linux 7.2 host to a Red Hat Enterprise Linux 7.3 host, due to the different PCI addresses of the USB controller. To work around this problem, edit the guest XML file and add a model attribute with the pci-ohci value to the USB <controller> element, for example as follows: Afterwards, shut down the guest and start it again for the changes to take effect. As a result, the guest can be migrated from Red Hat Enterprise Linux 7.2 to 7.3. (BZ# 1357468 ) numad changes QEMU memory bindings Currently, the numad daemon cannot distinguish between memory bindings that numad sets and memory bindings set explicitly by the memory mappings of a process. As a consequence, numad changes QEMU memory bindings, even when the NUMA memory policy is specified in the QEMU command line. To work around this problem, if manual NUMA bindings are specified in the guest, disable numad . This ensures that manual bindings configured in virtual machines are not changed by numad . (BZ# 1360584 ) Memory usage for QEMU processes is shown without mapped hugetlbfs pages Mapped hugetlbfs pages are not accounted for by the kernel when calculating process memory usage. As a consequence, commands such as top and ps show memory usage for QEMU processes without the mapped hugetlbfs pages when a virtual machine is configured to use huge pages. (BZ#1221443) qemu-kvm below version 2.6.0 cannot load 2.88 MB floppy disks When using the qemu-kvm package below version 2.6.0, KVM guests are not able to load a 2.88 MB floppy disk if it is inserted after the guest has already booted up. To work around this problem, insert the floppy disk before booting the guest, or use qemu-kvm version 2.6.0 or later. (BZ# 1209707 )

Commands:
<controller type='usb' model='pci-ohci' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </controller>
Chapter 4. Important Changes to External Kernel Parameters This chapter provides system administrators with a summary of significant changes in the kernel distributed with Red Hat Enterprise Linux 7.9. These changes include added or updated proc entries, sysctl , and sysfs default values, boot parameters, kernel configuration options, or any noticeable behavior changes. 4.1. New kernel parameters bert_disable [ACPI] This parameter disables Boot Error Record Table (BERT) on defective BIOSes. BERT is one of four ACPI Platform Error Interface tables and is used for obtaining hardware error logs that occurred in the boot and firmware did not notify the kernel about the error at runtime, for example through a non-maskable interrupt (NMI) or a machine-check exception (MCE). bert_enable [ACPI] RHEL7 only. This parameter enables Boot Error Record Table (BERT). The default state is disabled. page_owner = [KNL] Storage of the information about who allocated each page is disabled in default. This parameter enables to store such information by using the following option: on - enable the feature srbds = [X86,INTEL] This parameter controls the Special Register Buffer Data Sampling (SRBDS) mitigation. Certain CPUs are vulnerable to MDS-like (Microarchitectural Data Sampling) exploits which can leak bits from the random number generator. By default, this issue is mitigated by microcode. However, the microcode fix can cause the RDRAND (read random) and RDSEED instructions to become much slower. Among other effects, this will result in reduced throughput from the /dev/urandom file. The microcode mitigation can be disabled with the following option: off - Disable mitigation and remove performance impact to RDRAND and RDSEED . 4.2. New /proc/sys/kernel/ parameters hyperv_record_panic_msg This parameter controls whether the panic kernel (kmsg) data is reported to Hyper-V or not. The values are: 0 - Do not report the panic kmsg data. 1 - Report the panic kmsg data. This is the default behavior.

Commands:
Preface Providing feedback on Red Hat documentation Red Hat appreciates your feedback on product documentation. To propose improvements, open a Jira issue and describe your suggested changes. Provide as much detail as possible to help the documentation team to address your request quickly. Prerequisite You have a Red Hat Customer Portal account. This account enables you to log in to the Red Hat Jira Software instance. If you do not have an account, you will be prompted to create one. Procedure Click the following link: Create issue . In the Summary text box, enter a brief description of the issue. In the Description text box, provide the following information: The URL of the page where you found the issue. A detailed description of the issue. You can leave the information other fields at their default values. In the Reporter field, enter your Jira user name. Click Create to submit the Jira issue to the documentation team. Thank you for taking the time to provide feedback.

Commands: