mtpti5iD/redhat-docs_dataset huggingface dataset:
7.195. python-paste 7.195.1. RHBA-2013:0472 - python-paste bug fix update An updated python-paste package that fixes one bug is now available for Red Hat Enterprise Linux 6. Python Paste provides middleware for building and running Python web applications. Bug Fix BZ#783158 Previously, the auth_tkt plugin used MD5 checksums, which are not FIPS (Federal Information Processing Standard) compliant. Consequently, when FIPS compliance mode was active on the system, auth_tkt failed. The auth_tkt plugin has been set to use Secure Hash Algorithm (SHA) 256, which is FIPS-compliant, instead of MD5 checksums. As a result, auth-tkt no longer fails in this situation. All users of python-paste are advised to upgrade to this updated package, which fixes this bug.

Commands:
Chapter 7. Configuration of an evaluation period for custom MBean triggers The Cryostat agent supports smart triggers that continually listen to the current values of the specified MBean counters that you can define in custom trigger definitions. The trigger conditions are evaluated on a polling basis at regular configurable intervals. By default, trigger conditions are evaluated at regular 1-second intervals. An evaluation period (polling frequency) of once per second means that there is a potential time delay of up to one second between a condition being met and the agent's ability to evaluate that this condition was met. When you configure your target application to load the Cryostat agent, you can choose to configure a different evaluation period for MBean custom triggers. You can specify the value of the evaluation period in milliseconds. You can configure an evaluation period in either of the following ways: Using a JVM system property flag The following example shows how to configure an evaluation period by using a JVM system property flag: Using an environment variable The following example shows how to configure a harvester period by using an environment variable: The preceding examples show an evaluation period value of 500. Based on this example, the trigger conditions are evaluated every 500 milliseconds (that is, at regular half-second intervals).

Commands:
-Dcryostat.agent.smart-trigger.evaluation.period-ms=500
- name: CRYOSTAT_AGENT_SMART-TRIGGER_EVALUATION_PERIOD_MS value: 500
1.2.3.4. Anticipating Your Future Needs Depending upon your target and resources, there are many tools available. There are tools for wireless networks, Novell networks, Windows systems, Linux systems, and more. Another essential part of performing assessments may include reviewing physical security, personnel screening, or voice/PBX network assessment. Concepts such as war walking and wardriving , which involves scanning the perimeter of your enterprise's physical structures for wireless network vulnerabilities, are some concepts that you should investigate and, if needed, incorporate into your assessments. Imagination and exposure are the only limits of planning and conducting vulnerability assessments.

Commands:
Chapter 4. Red Hat Enterprise Linux 6 This section outlines the packages released for Red Hat Enterprise Linux 6. 4.1. Red Hat Satellite Client 6 (for RHEL 6 Server - ELS) (RPMs) The following table outlines the packages included in the rhel-6-server-els-satellite-client-6-rpms repository. Table 4.1. Red Hat Satellite Client 6 (for RHEL 6 Server - ELS) (RPMs) Name Version Advisory gofer 2.11.9-1.el6sat RHBA-2022:5497 katello-agent 3.5.7-3.el6sat RHBA-2022:5497 katello-host-tools 3.5.7-3.el6sat RHBA-2022:5497 katello-host-tools-fact-plugin 3.5.7-3.el6sat RHBA-2022:5497 pulp-rpm-handlers 2.21.5-2.el6sat RHBA-2022:5497 puppet-agent 7.16.0-2.el6sat RHBA-2022:5497 python-gofer 2.11.9-1.el6sat RHBA-2022:5497 python-gofer-proton 2.11.9-1.el6sat RHBA-2022:5497 python-isodate 0.5.0-4.el6sat RHBA-2022:5497 python-pulp-agent-lib 2.21.5-2.el6sat RHBA-2022:5497 python-pulp-common 2.21.5-2.el6sat RHBA-2022:5497 python-pulp-rpm-common 2.21.5-2.el6sat RHBA-2022:5497 python-qpid-proton 0.28.0-3.el6_10 RHBA-2022:5497 qpid-proton-c 0.28.0-3.el6_10 RHBA-2022:5497 rubygem-foreman_scap_client 0.5.0-1.el6sat RHBA-2022:5497 rubygem-json 1.4.6-2.el6 RHBA-2022:5497 4.2. Red Hat Satellite Client 6 (for RHEL 6 for System Z - ELS) (RPMs) The following table outlines the packages included in the rhel-6-for-system-z-els-satellite-client-6-rpms repository. Table 4.2. Red Hat Satellite Client 6 (for RHEL 6 for System Z - ELS) (RPMs) Name Version Advisory gofer 2.11.9-1.el6sat RHBA-2022:5497 katello-agent 3.5.7-3.el6sat RHBA-2022:5497 katello-host-tools 3.5.7-3.el6sat RHBA-2022:5497 katello-host-tools-fact-plugin 3.5.7-3.el6sat RHBA-2022:5497 pulp-rpm-handlers 2.21.5-2.el6sat RHBA-2022:5497 python-gofer 2.11.9-1.el6sat RHBA-2022:5497 python-gofer-proton 2.11.9-1.el6sat RHBA-2022:5497 python-isodate 0.5.0-4.el6sat RHBA-2022:5497 python-pulp-agent-lib 2.21.5-2.el6sat RHBA-2022:5497 python-pulp-common 2.21.5-2.el6sat RHBA-2022:5497 python-pulp-rpm-common 2.21.5-2.el6sat RHBA-2022:5497 python-qpid-proton 0.28.0-3.el6_10 RHBA-2022:5497 qpid-proton-c 0.28.0-3.el6_10 RHBA-2022:5497 rubygem-foreman_scap_client 0.5.0-1.el6sat RHBA-2022:5497 rubygem-json 1.4.6-2.el6 RHBA-2022:5497

Commands:
4.3. CONTROL/MONITORING The CONTROL/MONITORING Panel presents the a limited runtime status of the Load Balancer Add-On. It displays the status of the pulse daemon, the LVS routing table, and the LVS-spawned nanny processes. Note The fields for CURRENT LVS ROUTING TABLE and CURRENT LVS PROCESSES remain blank until you actually start the Load Balancer Add-On, as shown in Section 4.8, "Starting the Load Balancer Add-On" . Figure 4.2. The CONTROL/MONITORING Panel Auto update The status display on this page can be updated automatically at a user configurable interval. To enable this feature, click on the Auto update check box and set the desired update frequency in the Update frequency in seconds text box (the default value is 10 seconds). It is not recommended that you set the automatic update to an interval less than 10 seconds. Doing so may make it difficult to reconfigure the Auto update interval because the page will update too frequently. If you encounter this issue, simply click on another panel and then back on CONTROL/MONITORING . The Auto update feature does not work with all browsers, such as Mozilla . Update information now You can manually update the status information manually by clicking this button. CHANGE PASSWORD Clicking this button takes you to a help screen with information on how to change the administrative password for the Piranha Configuration Tool .

Commands:
Chapter 18. Managing technology preview features You can enable or disable features that are Technology Preview by using feature flags. Important Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope . 18.1. Managing feature flags 18.1.1. Prerequisites You have access to the environment where the RHACS component is deployed. You have permission to modify environment variables. You understand that the Technology Preview features might be incomplete and are provided with limited support. You know if the flag for the Technology Preview feature needs to be configured before the deployment. Check the installation manifests to see if they use the required flag. Procedure Identify the environment variable name associated with the feature flag. Consult the release notes or the /v1/featureflags API endpoint to identify the flag for the feature you want to enable or disable. Modify the feature flag by completing one of the following actions: To enable a feature, configure the environment variable associated with the flag by setting its value to true . Configure this directly on the Kubernetes deployment or during installation by using the Helm chart or the Operator custom resource (CR). To disable a feature, set the environment variable associated with the flag to false . After the application is restarted or redeployed, verify that the feature has been enabled or disabled by completing the following steps: Check the output of the /v1/featureflags API endpoint. Check the application functionality related to the feature. Review logs or monitoring tools for any errors or confirmation messages. 18.1.2. Best practices Follow these best practices for using the feature flag: Always test feature changes in a staging environment before applying them to production. Keep a record of all feature flags and their current status. Be prepared to revert the changes if the feature causes issues. 18.1.3. Troubleshooting Follow these troubleshooting guidelines: If the feature does not appear, ensure that the environment variable is correctly named and set. Check application logs for any errors related to feature flag parsing. If enabling a feature causes application errors, disable the feature and contact Red Hat Support.

Commands:
33.3. DNS Configuration Priorities Many DNS configuration options can be configured on three different levels. Zone-specific configuration The level of configuration specific for a particular zone defined in IdM has the highest priority. Zone-specific configuration is managed using the ipa dnszone-* and ipa dnsforwardzone-* commands. Global DNS configuration If no zone-specific configuration is defined, IdM uses global DNS configuration stored in LDAP. Global DNS configuration is managed using the ipa dnsconfig-* commands. Settings defined in global DNS configuration are applied to all IdM DNS servers. Configuration in /etc/named.conf Configuration defined in the /etc/named.conf file on each IdM DNS server has the lowest priority. It is specific for each server and must be edited manually. The /etc/named.conf file is usually only used to specify DNS forwarding to a local DNS cache; other options are managed using the commands for zone-specific and global DNS configuration mentioned above. DNS options can be configured on multiple levels at once. In such cases, configuration with the highest priority takes precedence over configuration defined at lower levels.

Commands:
E.2. Top-level Files within the proc File System Below is a list of some of the more useful virtual files in the top-level of the /proc/ directory. Note In most cases, the content of the files listed in this section are not the same as those installed on your machine. This is because much of the information is specific to the hardware on which Red Hat Enterprise Linux is running for this documentation effort. E.2.1. /proc/buddyinfo The /proc/buddyinfo file is used primarily for diagnosing memory fragmentation issues. The output depends on the memory layout used, which is architecture specific. The following is an example from a 32-bit system: Using the buddy algorithm, each column represents the number of memory pages of a certain order, a certain size, that are available at any given time. In the example above, for zone DMA, there are 90 of 2 0 *PAGE_SIZE bytes large chunks of memory. Similarly, there are 6 of 2 1 *PAGE_SIZE chunks and 2 of 2 2 *PAGE_SIZE chunks of memory available. The DMA row references the first 16 MB of memory on the system, the HighMem row references all memory greater than 896 MB on the system, and the Normal row references the memory in between. On a 64-bit system, the output might look as follows: The DMA row references the first 16 MB of memory on the system, the DMA32 row references all memory allocated for devices that cannot address memory greater than 4 GB, and the Normal row references all memory above the DMA32 allocation, which includes all memory above 4 GB on the system.

Commands:
Node 0, zone DMA 90 6 2 1 1 Node 0, zone Normal 1650 310 5 0 0 Node 0, zone HighMem 2 0 0 1 1
Node 0, zone DMA 0 3 1 2 4 3 1 2 3 3 1 Node 0, zone DMA32 295 25850 7065 1645 835 220 78 6 0 1 0 Node 0, zone Normal 3824 3359 736 159 31 3 1 1 1 1 0
Chapter 13. Publishing the certified or validated application 13.1. Publishing certified applications After submitting your test results for certification through the Red Hat certification portal , your application is scanned for vulnerabilities. When the scanning is completed, the publish button will be enabled for your application on the Product Listings page. After providing all the necessary information, click the publish button. Your application will be available on the Red Hat Ecosystem Catalog . 13.2. Publishing validated applications After submitting your application for validation, the Red Hat certification team will review and verify the entered details of the validation questionnaire. If at a later date you want to certify your partner validated application, complete the Certification details. The Red Hat certification team will review the submitted test results. After successful verification, to publish your product on the Red Hat Ecosystem Catalog , go to the Product Listings page to attach the Partner Validated or Certified application. Important Red Hat software certification or validation does not conduct testing of the Partner's product in how it functions or performs on the chosen platform. Any and all aspects of the certification candidate product's quality assurance remains the partner's sole responsibility.

Commands:
Chapter 64. Virtualization Guests reporting cmt , mbmt , or mbml perf events fail to boot If a guest virtual machine is set to report cmt , mbmt , or mbml perf events, it is unable to boot after the host is upgraded to Red Hat Enterprise Linux 7.5. To work around this problem, disable this setting by removing lines that contain event name='cmt' , event name='mbmt' , or event name='mbml' from the <perf> section of the domain XML configuration file. (BZ# 1532553 )

Commands:
5.4. Starting, Stopping, Restarting, and Deleting Clusters You can start, stop, and restart a cluster by performing these actions on the individual nodes in the cluster. From the cluster-specific page, click on Nodes along the top of the cluster display. This displays the nodes that constitute the cluster. The start and restart operations for cluster nodes or a whole cluster allow you to create short cluster service outages if a cluster service needs to be moved to another cluster member because it running on a node that is being stopped or restarted. To stop a cluster, perform the following steps. This shuts down the cluster software in the nodes, but does not remove the cluster configuration information from the nodes and the nodes still appear in the cluster node display with a status of Not a cluster member . Select all of the nodes in the cluster by clicking on the check box to each node. Select the Leave Cluster function from the menu at the top of the page. This causes a message to appear at the top of the page indicating that each node is being stopped. Refresh the page to see the updated status of the nodes. To start a cluster, perform the following steps: Select all of the nodes in the cluster by clicking on the check box to each node. Select the Join Cluster function from the menu at the top of the page. Refresh the page to see the updated status of the nodes. To restart a running cluster, first stop all of the nodes in cluster, then start all of the nodes in the cluster, as described above. To delete a cluster entirely, perform the following steps. This causes all cluster services to stop and removes the cluster configuration information from the nodes themselves as well as removing them from the cluster display. If you later try to add an existing cluster using any of the nodes you have deleted, luci will indicate that the node is not a member of any cluster. Important Deleting a cluster is a destructive operation that cannot be undone. To restore a cluster after you have deleted it requires that you recreate and redefine the cluster from scratch. Select all of the nodes in the cluster by clicking on the check box to each node. Select the Delete function from the menu at the top of the page. If you wish to remove a cluster from the luci interface without stopping any of the cluster services or changing the cluster membership, you can use the Remove option on the Manage Clusters page, as described in Section 5.2, "Removing a Cluster from the luci Interface" .

Commands:
Chapter 5. Deploying the configured Fujitsu ETERNUS back ends After you create the eternusbackend-env.yaml file in /home/stack/templates/ , complete the following steps: Procedure Log in as the stack user. Deploy the back end configuration with the following command: Important If you passed any extra environment files when you created the overcloud, pass them again here using the -e option to avoid making undesired changes to the overcloud. For more information, see Modifying the Overcloud Environment in the Director Installation and Usage guide. Test the back end after director orchestration is complete. See Chapter 6, Testing your Fujitsu ETERNUS configuration .

Commands:
openstack overcloud deploy --templates -e [your environment files] -e /home/stack/templates/eternusbackend-env.yaml
Chapter 4. Hosting Virtual Machine Images on Red Hat Gluster Storage volumes Red Hat Gluster Storage provides a POSIX-compatible file system to store virtual machine images in Red Hat Gluster Storage volumes. This chapter describes how to configure volumes using the command line interface, and how to prepare Red Hat Gluster Storage servers for virtualization using Red Hat Virtualization Manager. 4.1. Configuring Volumes Using the Command Line Interface Red Hat recommends configuring volumes before starting them. For information on creating volumes, see Red Hat Gluster Storage Volumes in the Red Hat Gluster Storage Administration Guide : https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.5/html/administration_guide/chap-red_hat_storage_volumes. . Procedure 4.1. Configuring Volumes Using the Command Line Interface Configure the rhgs-random-io tuned profile Install the tuned tuning daemon and configure Red Hat Gluster Storage servers to use the rhgs-random-io profile: For more information on available tuning profiles, refer to the tuned-adm man page, or see the Red Hat Gluster Storage 3.5 Administration Guide : https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.5/html/administration_guide/ . Note When you upgrade, a new virt file may be created in /var/lib/glusterd/groups/virt.rpmnew . Apply the new virt file to the existing volumes by renaming the virt.rpmnew file to virt . Assign volumes to virt group Assign volumes that store virtual machine images to the virt volume group to apply the settings in the virt profile. This has the same effect as the Optimize for Virt Store option in the management console. See Appendix A, The virt group profile for more information about this configuration. Important Volumes in the virt group must only be used for storing machine images, and must only be accessed using the native FUSE client. (Recommended) Configure improved self-heal performance Run the following command to improve the performance of volume self-heal operations. Allow KVM and VDSM brick access Set the brick permissions for vdsm and kvm . If you do not set the required brick permissions, creation of virtual machines fails. Set the user and group permissions using the following commands: If you are using QEMU/KVM as a hypervisor, set the user and group permissions using the following commands: See Also: Section 5.4, "Optimizing Red Hat Gluster Storage Volumes for Virtual Machine Images"

Commands:
yum install tuned tuned-adm profile rhgs-random-io
gluster volume set VOLNAME group virt
gluster volume heal volname cluster.granular-entry-heal enable
gluster volume set VOLNAME storage.owner-uid 36 gluster volume set VOLNAME storage.owner-gid 36
gluster volume set VOLNAME storage.owner-uid 107 gluster volume set VOLNAME storage.owner-gid 107
4.2. Configuration File Blacklist The blacklist section of the multipath configuration file specifies the devices that will not be used when the system configures multipath devices. Devices that are blacklisted will not be grouped into a multipath device. In older releases of Red Hat Enterprise Linux, multipath always tried to create a multipath device for every path that was not explicitly blacklisted. In Red Hat Enterprise Linux 6, however, if the find_multipaths configuration parameter is set to yes , then multipath will create a device only if one of three conditions are met: There are at least two non-blacklisted paths with the same WWID. The user manually forces the creation of the device by specifying a device with the multipath command. A path has the same WWID as a multipath device that was previously created (even if that multipath device does not currently exist). Whenever a multipath device is created, multipath remembers the WWID of the device so that it will automatically create the device again as soon as it sees a path with that WWID. This allows you to have multipath automatically choose the correct paths to make into multipath devices, without have to edit the multipath blacklist. If you have previously created a multipath device without using the find_multipaths parameter and then you later set the parameter to yes , you may need to remove the WWIDs of any device you do not want created as a multipath device from the /etc/multipath/wwids file. The following shows a sample /etc/multipath/wwids file. The WWIDs are enclosed by slashes (/): With the find_multipaths parameter set to yes , you need to blacklist only the devices with multiple paths that you do not want to be multipathed. Because of this, it will generally not be necessary to blacklist devices. If you do need to blacklist devices, you can do so according to the following criteria: By WWID, as described in Section 4.2.1, "Blacklisting by WWID" By device name, as described in Section 4.2.2, "Blacklisting By Device Name" By device type, as described in Section 4.2.3, "Blacklisting By Device Type" By default, a variety of device types are blacklisted, even after you comment out the initial blacklist section of the configuration file. For information, see Section 4.2.2, "Blacklisting By Device Name" . 4.2.1. Blacklisting by WWID You can specify individual devices to blacklist by their World-Wide IDentification with a wwid entry in the blacklist section of the configuration file. The following example shows the lines in the configuration file that would blacklist a device with a WWID of 26353900f02796769.

Commands:
Multipath wwids, Version : 1.0 NOTE: This file is automatically maintained by multipath and multipathd. You should not need to edit this file in normal circumstances. # Valid WWIDs: /3600d0230000000000e13955cc3757802/ /3600d0230000000000e13955cc3757801/ /3600d0230000000000e13955cc3757800/ /3600d02300069c9ce09d41c31f29d4c00/ /SWINSYS SF2372 0E13955CC3757802/ /3600d0230000000000e13955cc3757803/
blacklist { wwid 26353900f02796769 }