mtpti5iD/redhat-docs_dataset huggingface dataset:
Preface Providing feedback on Red Hat documentation You can give feedback or report an error in the documentation by creating a Jira issue. You must have a Red Hat Jira account. Log in to Jira . Click Create Issue to launch the form in a browser. Complete the Summary , Description , and Reporter fields. Click Create to submit the form. The form creates an issue in the Red Hat Hybrid Cloud Infrastructure (HCIDOCS) Jira project.

Commands:
Appendix C. Using AMQ Broker with the examples The AMQ C++ examples require a running message broker with a queue named examples . Use the procedures below to install and start the broker and define the queue. C.1. Installing the broker Follow the instructions in Getting Started with AMQ Broker to install the broker and create a broker instance . Enable anonymous access. The following procedures refer to the location of the broker instance as <broker-instance-dir> . C.2. Starting the broker Procedure Use the artemis run command to start the broker. USD <broker-instance-dir> /bin/artemis run Check the console output for any critical errors logged during startup. The broker logs Server is now live when it is ready. USD example-broker/bin/artemis run __ __ ____ ____ _ /\ | \/ |/ __ \ | _ \ | | / \ | \ / | | | | | |_) |_ __ ___ | | _____ _ __ / /\ \ | |\/| | | | | | _ <| '__/ _ \| |/ / _ \ '__| / ____ \| | | | |__| | | |_) | | | (_) | < __/ | /_/ \_\_| |_|\___\_\ |____/|_| \___/|_|\_\___|_| Red Hat AMQ <version> 2020-06-03 12:12:11,807 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server ... 2020-06-03 12:12:12,336 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live ... C.3. Creating a queue In a new terminal, use the artemis queue command to create a queue named examples . USD <broker-instance-dir> /bin/artemis queue create --name examples --address examples --auto-create-address --anycast You are prompted to answer a series of yes or no questions. Answer N for no to all of them. Once the queue is created, the broker is ready for use with the example programs. C.4. Stopping the broker When you are done running the examples, use the artemis stop command to stop the broker. USD <broker-instance-dir> /bin/artemis stop Revised on 2021-08-24 14:23:53 UTC

Commands:
<broker-instance-dir> /bin/artemis run
example-broker/bin/artemis run __ __ ____ ____ _ /\ | \/ |/ __ \ | _ \ | | / \ | \ / | | | | | |_) |_ __ ___ | | _____ _ __ / /\ \ | |\/| | | | | | _ <| '__/ _ \| |/ / _ \ '__| / ____ \| | | | |__| | | |_) | | | (_) | < __/ | /_/ \_\_| |_|\___\_\ |____/|_| \___/|_|\_\___|_| Red Hat AMQ <version> 2020-06-03 12:12:11,807 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server 2020-06-03 12:12:12,336 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live
<broker-instance-dir> /bin/artemis queue create --name examples --address examples --auto-create-address --anycast
<broker-instance-dir> /bin/artemis stop
11.7. Notes for Administrators Many system customization files can include network interface names, and thus will require updates if moving a system from the old convention to the new convention. If you use the new naming convention, you will also need to update network interface names in areas such as custom iptables rules, scripts altering irqbalance , and other similar configuration files. Also, enabling this change for installation will require modification to existing kickstart files that use device names through the ksdevice parameter; these kickstart files will need to be updated to use the network device's MAC address or the network device's new name. Note The maximum interface name length is defined by the kernel headers and is a global limit, affecting all applications.

Commands:
19.4. Known Issues SELinux MLS policy is not supported with kernel version 4.14 SELinux Multi-Level Security (MLS) Policy denies unknown classes and permissions, and kernel version 4.14 in the kernel-alt packages recognizes the map permission, which is not defined in any policy. Consequently, every command on a system with active MLS policy and SELinux in enforcing mode terminates with the Segmentation fault error. A lot of SELinux denial warnings occurs on systems with active MLS policy and SELinux in permissive mode. The combination of SELinux MLS policy with kernel version 4.14 is not supported. ipmitool communicates with BMC only when IPMI_SI=no on Cavium ThunderX When starting ipmi.service with the systemctl command, the default configuration attempts to load the ipmi_si driver. On Cavium ThunderX systems, which do not have an IPMI SI device, ipmi.service incorrectly removes the ipmi_devintf driver. Consequently, the ipmitool utility in the kernel is not able to communicate with the Baseboard Management Controller (BMC). To work around this problem, edit the /etc/sysconfig/ipmi file and set the IPMI_SI variable as follows: Then reboot the operating system if necessary. As a result, the correct drivers are loaded and ipmitoo can communicate with BMC through the /dev/ipmi0/ directory. (BZ#1448181) Putting SATA ALPM devices into low power mode does not work correctly When using the following commands to enable and disable low power mode for Serial Advanced Technology Attachment (SATA) devices using the Aggressive Link Power Management (ALPM) power management protocol on the 64-bit ARM systems, SATA does not work correctly: Consequently, SATA failures stop all disk I/O, and users have to reboot the operating system to fix it. To work around this problem, use one of the following options: Do not put the system into the powersave profile Check with your hardware vendor for firmware updates that might fix the bug with ALPM (BZ#1430391) Setting tuned to network-latency causes system hang on ARM If the tuned profile is set to network-latency on the 64-bit ARM systems, the operating system becomes unresponsive, and the kernel prints a backtrace to the serial console. To work around this problem, do not set the tuned profile to network-latency . (BZ#1503121) modprobe succeeds to load kernel modules with incorrect parameters When attempting to load a kernel module with an incorrect parameter using the modprobe command, the incorrect parameter is ignored, and the module loads as expected on Red Hat Enterprise Linux 7 for ARM and for IBM Power LE (POWER9). Note that this is a different behavior compared to Red Hat Enterprise Linux for traditional architectures, such as AMD64 and Intel 64, IBM Z and IBM Power Systems. On these systems, modprobe exits with an error, and the module with an incorrect parameter does not load in the described situation. On all architectures, an error message is recorded in the dmesg output. (BZ#1449439)

Commands:
IPMI_SI=no
tuned-adm profile powersave
tuned-adm profile performance
Chapter 1. About the Red Hat Insights for OpenShift advisor service You can use the Insights for OpenShift advisor service to assess and monitor the health of your OpenShift clusters. Whether you are concerned about individual clusters, or with your whole infrastructure, it is important to be aware of your exposure to issues that can affect service availability, fault tolerance, performance, or security. Insights repeatedly analyzes data collected by Insights Operator against a database of recommendations , which are sets of conditions that can leave your clusters at risk. You can then perform the following actions in the Red Hat Hybrid Cloud Console: See clusters impacted by a specific recommendation. Use robust filtering capabilities to refine your results. Learn more about individual recommendations, details about the risks they present, and get resolutions tailored to your individual clusters. Share results with other stakeholders. To use the advisor service, your cluster must be registered to Red Hat OpenShift Cluster Manager. To register a disconnected cluster, see Registering OpenShift Container Platform clusters to OpenShift Cluster Manager . Additional resources Red Hat Insights for OpenShift does not collect identifying information, such as user names, passwords, or certificates. See Red Hat Insights Data & Application Security for information about Red Hat Insights data collection and controls. For more information on how Red Hat Insights for OpenShift gathers data from OpenShift, see the OpenShift Container Platform documentation: About remote health monitoring Showing data collected by remote health monitoring Opting out of remote health reporting 1.1. Understanding advisor service recommendations The Insights for OpenShift advisor service bundles information about various cluster states and component configurations that can negatively affect the service availability, fault tolerance, performance, or security of your clusters. This information set is called a recommendation in advisor service and includes the following information: Name: A concise description of the recommendation Added: When the recommendation was published to the Insights archive Category: Whether the issue has the potential to negatively affect service availability, fault tolerance, performance, or security Total risk: A value derived from the likelihood that the condition will negatively affect your infrastructure, and the impact on operations if that were to happen Clusters: A list of clusters on which a recommendation is detected Link to associated topics: More information from Red Hat about the issue

Commands:
Preface As a business analyst, system administrator, or business rules developer, the types of Red Hat Decision Manager business assets that you create and the way in which you develop, store, execute, and deploy those assets varies based on the needs of your business automation environment. You can design a decision management architecture that uses Business Central or an external integrated development environment (IDE) for asset development, a built-in or external Git repository for storage and version control, a KIE Server or embedded application for deployment, or other implementation combinations. You can also deploy Red Hat Decision Manager into a Red Hat OpenShift Container Platform environment for an enhanced containerized implementation. This document describes basic concepts and options for a Red Hat Decision Manager implementation to consider when designing your decision management architecture. To verify the most suitable implementation for your environment, contact your Red Hat Technical Account Manager or Solutions Architect.

Commands:
Appendix E. LVM Volume Group Metadata The configuration details of a volume group are referred to as the metadata. By default, an identical copy of the metadata is maintained in every metadata area in every physical volume within the volume group. LVM volume group metadata is stored as ASCII. If a volume group contains many physical volumes, having many redundant copies of the metadata is inefficient. It is possible to create a physical volume without any metadata copies by using the --metadatacopies 0 option of the pvcreate command. Once you have selected the number of metadata copies the physical volume will contain, you cannot change that at a later point. Selecting 0 copies can result in faster updates on configuration changes. Note, however, that at all times every volume group must contain at least one physical volume with a metadata area (unless you are using the advanced configuration settings that allow you to store volume group metadata in a file system). If you intend to split the volume group in the future, every volume group needs at least one metadata copy. The core metadata is stored in ASCII. A metadata area is a circular buffer. New metadata is appended to the old metadata and then the pointer to the start of it is updated. You can specify the size of metadata area with the --metadatasize . option of the pvcreate command. The default size may be too small for volume groups that contain physical volumes and logical volumes that number in the hundreds. E.1. The Physical Volume Label By default, the pvcreate command places the physical volume label in the 2nd 512-byte sector. This label can optionally be placed in any of the first four sectors, since the LVM tools that scan for a physical volume label check the first 4 sectors. The physical volume label begins with the string LABELONE . The physical volume label Contains: Physical volume UUID Size of block device in bytes NULL-terminated list of data area locations NULL-terminated lists of metadata area locations Metadata locations are stored as offset and size (in bytes). There is room in the label for about 15 locations, but the LVM tools currently use 3: a single data area plus up to two metadata areas.

Commands:
18.4. Configuring a VNC Server To set up graphical desktop sharing between the host and the guest machine using Virtual Network Computing (VNC), a VNC server has to be configured on the guest you wish to connect to. To do this, VNC has to be specified as a graphics type in the devices element of the guest's XML file. For further information, see Section 23.17.11, "Graphical Framebuffers" . To connect to a VNC server, use the virt-viewer utility or the virt-manager interface.

Commands:
7.7. abrt 7.7.1. RHBA-2015:1453 - abrt, libreport, and satyr bug fix and enhancement update Updated abrt, libreport, and satyr packages that fix several bugs and add one enhancement are now available for Red Hat Enterprise Linux 6. The Automatic Bug Reporting Tool (ABRT) recognizes defects in applications and creates bug reports that help maintainers to fix the defects. ABRT uses a plug-in system to extend its functionality. Bug Fixes BZ# 1199261 The abrt-addon-ccpp process logs messages using the rsyslog daemon. When rsyslog terminated unexpectedly, abrt-addon-ccpp could enter a deadlock state, because the /dev/log socket was not freed. The underlying source code has been modified to fix this bug, and the deadlock no longer occurs in the described situation. BZ# 1208154 The "bootloader" plug-in was renamed to "boot". However, ABRT still used the old name when generating SOS reports. As a consequence, ABRT did not include SOS report data in its crash reports. With this update, ABRT now uses the correct name and generates SOS reports as expected. BZ# 1212095 The libreport library could previously change mode of any file or mode of the dump directory because it followed symbolic links. Also, libreport could change ownership of a new dump directory. This behavior could lead to security issues. With this update, this bug has been fixed, and libreport no longer changes modes or ownership. Enhancement BZ# 1150197 , BZ# 1152222 , BZ# 1153311 This update introduces ABRT micro-reporting. When a crash occurs, users can now send authenticated reports about the problem called micro-reports. These reports contain non-sensitive data describing the problem and optionally host name, machine ID, and RHN account number. Micro-reports help Red Hat to track bug occurrences and to provide instant solutions to crashes. See https://access.redhat.com/node/642323 for more information about micro-reporting. Users of abrt, libreport, and satyr are advised to upgrade to these updated packages, which fix these bugs and add this enhancement.

Commands:
7.9.2. Useful Websites http://www.webopedia.com/TERM/p/printer.html -- General definitions of printers and descriptions of printer types. http://www.linuxprinting.org/ -- A database of documents about printing, along with a database of nearly 1000 printers compatible with Linux printing facilities. http://www.cups.org/ -- Documentation, FAQs, and newsgroups about CUPS.

Commands:
B.53. mod_auth_mysql B.53.1. RHSA-2010:1002 - Moderate: mod_auth_mysql security update An updated mod_auth_mysql package that fixes one security issue is now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having moderate security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. The mod_auth_mysql package includes an extension module for the Apache HTTP Server, which can be used to implement web user authentication against a MySQL database. CVE-2008-2384 A flaw was found in the way mod_auth_mysql escaped certain multibyte-encoded strings. If mod_auth_mysql was configured to use a multibyte character set that allowed a backslash ("\") as part of the character encodings, a remote attacker could inject arbitrary SQL commands into a login request. Note Note that this flaw only affected non-default installations where AuthMySQLCharacterSet is configured to use one of the affected multibyte character sets. Installations that did not use the AuthMySQLCharacterSet configuration option were not vulnerable to this flaw. All mod_auth_mysql users are advised to upgrade to this updated package, which contains a backported patch to correct this issue. After installing the updated package, the httpd daemon must be restarted for the update to take effect.

Commands:
22.2. Enabling/Disabling Write Barriers To mitigate the risk of data corruption during power loss, some storage devices use battery-backed write caches. Generally, high-end arrays and some hardware controllers use battery-backed write caches. However, because the cache's volatility is not visible to the kernel, Red Hat Enterprise Linux 6 enables write barriers by default on all supported journaling file systems. For devices with non-volatile, battery-backed write caches and those with write-caching disabled, you can safely disable write barriers at mount time using the -o nobarrier option for mount . However, some devices do not support write barriers; such devices will log an error message to /var/log/messages (refer to Table 22.1, "Write barrier error messages per file system" ). Table 22.1. Write barrier error messages per file system File System Error Message ext3/ext4 JBD: barrier-based sync failed on device - disabling barriers XFS Filesystem device - Disabling barriers, trial barrier write failed btrfs btrfs: disabling barriers on dev device Note The use of nobarrier is no longer recommended in Red Hat Enterprise Linux 6 as the negative performance impact of write barriers is negligible (approximately 3%). The benefits of write barriers typically outweigh the performance benefits of disabling them. Additionally, the nobarrier option should never be used on storage configured on virtual machines.

Commands:
2.4. Limiting Access To the Piranha Configuration Tool The Piranha Configuration Tool prompts for a valid user name and password combination. However, because all of the data passed to the Piranha Configuration Tool is in plain text, it is recommended that you restrict access only to trusted networks or to the local machine. The easiest way to restrict access is to use the Apache HTTP Server's built in access control mechanisms by editing /etc/sysconfig/ha/web/secure/.htaccess . After altering the file you do not have to restart the piranha-gui service because the server checks the .htaccess file each time it accesses the directory. By default, the access controls for this directory allow anyone to view the contents of the directory. Here is what the default access looks like: To limit access of the Piranha Configuration Tool to only the localhost change the .htaccess file to allow access from only the loopback device (127.0.0.1). For more information on the loopback device, see the chapter titled Network Scripts in the Red Hat Enterprise Linux Reference Guide . You can also allow specific hosts or subnets as seen in this example: In this example, only Web browsers from the machine with the IP address of 192.168.1.100 and machines on the 172.16.57/24 network can access the Piranha Configuration Tool . Warning Editing the Piranha Configuration Tool .htaccess file limits access to the configuration pages in the /etc/sysconfig/ha/web/secure/ directory but not to the login and the help pages in /etc/sysconfig/ha/web/ . To limit access to this directory, create a .htaccess file in the /etc/sysconfig/ha/web/ directory with order , allow , and deny lines identical to /etc/sysconfig/ha/web/secure/.htaccess .

Commands:
Order deny,allow Allow from all
Order deny,allow Deny from all Allow from 127.0.0.1
Order deny,allow Deny from all Allow from 192.168.1.100 Allow from 172.16.57
13.6. Changing the Width for Indexed Substring Searches By default, for a search to be indexed, the search string must be at least three characters long, without counting any wildcard characters. For example, the string abc would be an indexed search while ab* would not be. Indexed searches are significantly faster than unindexed searches, so changing the minimum length of the search key is helpful to increase the number of indexed searches. To improve search performance, particularly for sites with many wildcard searches, the search string length for indexed searches can be changed. Directory Server has three attributes which allow you to change the minimum number of characters required for an indexed search: The nsSubStrBegin attribute sets the required number of characters for an indexed search for the beginning of a search string, before the wildcard. The nsSubStrMiddle attribute sets the required number of characters for an indexed search where a wildcard is used in the middle of a search string. For example: The nsSubStrEnd attribute sets the required number of characters for an indexed search for the end of a search string, after the wildcard. For example: The default substring search length for the string triplet (before, middle, and end) is 3, 3, and 3, meaning every search requires a minimum of three characters, in every wildcard position. For any attribute index to have alternate string lengths, add the extensibleObject object class to the entry and then set the substring search lengths. Set the new key length for the specific attribute index. This requires adding the extensibleObject object class and then adding the nsSubStrBegin , nsSubStrEnd , or nsSubStrMiddle attributes as appropriate. For example:

Commands:
abc*
*abc*
*xyz
ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: attribute_name ,cn=index,cn= database_name ,cn=ldbm database,cn=plugins,cn=config changetype: modify add: objectclass objectclass: extensibleObject - add: nsSubStrBegin nsSubStrBegin: 2 - add: nsSubStrMiddle nsSubStrMiddle: 2 - add: nsSubStrEnd nsSubStrEnd: 2
3.7. Active-State Power Management Active-State Power Management (ASPM) saves power in the Peripheral Component Interconnect Express (PCI Express or PCIe) subsystem by setting a lower power state for PCIe links when the devices to which they connect are not in use. ASPM controls the power state at both ends of the link, and saves power in the link even when the device at the end of the link is in a fully powered-on state. When ASPM is enabled, device latency increases because of the time required to transition the link between different power states. ASPM has three policies to determine power states: default sets PCIe link power states according to the defaults specified by the firmware on the system (for example, BIOS). This is the default state for ASPM. powersave sets ASPM to save power wherever possible, regardless of the cost to performance. performance disables ASPM to allow PCIe links to operate with maximum performance. ASPM support can be enabled or disabled by the pcie_aspm kernel parameter, where pcie_aspm=off disables ASPM and pcie_aspm=force enables ASPM, even on devices that do not support ASPM. ASPM policies are set in /sys/module/pcie_aspm/parameters/policy , but can be also specified at boot time with the pcie_aspm.policy kernel parameter, where, for example, pcie_aspm.policy=performance will set the ASPM performance policy. Warning If pcie_aspm=force is set, hardware that does not support ASPM can cause the system to stop responding. Before setting pcie_aspm=force , ensure that all PCIe hardware on the system supports ASPM.

Commands: