mtpti5iD/redhat-docs_dataset huggingface dataset:
7.260. usbredir 7.260.1. RHBA-2013:0346 - usbredir bug fix and enhancement update Updated usbredir packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The usbredir packages provide a protocol for redirection of USB traffic from a single USB device to a different virtual machine then the one to which the USB device is attached. The usbredir packages contain a number of libraries to help implement support for usbredir. Note The usbredir packages have been upgraded to upstream version 0.5.1, which provides a number of bug fixes and enhancements over the version. (BZ# 842356 ) Bug Fixes BZ# 834560 Due to a bug in the libusbredirhost library, handling of timeouts for bulk transfers did not work correctly. Consequently, traffic of USB ACM serial port devices, such as PSTN modems and SmartCard readers, could not be properly redirected. With this update, no timeout is set on the usb-host side for these devices and the traffic redirection works as expected. BZ# 855737 The usbredir code was allocating an unlimited amount of write buffers. Consequently, when a USB webcam produced data faster then it could be written out, the write queue grew boundlessly and the remote-viewer utility used an enormous amount of RAM. The underlying source code has been modified so that usbredir now checks how large the write queue is and drops isochronous data packets when the queue is too long. Enhancement BZ# 842316 Support for live migration of SPICE USB redirection requires support for state serialization. This update adds this missing support to the libusbredirparser library. All users of usbredir are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 2. Managing Puppet Modules 2.1. Installing a Puppet Module on Satellite Server You can install a pre-built Puppet module from the Puppet Forge. The Puppet Forge is a repository that provides Puppet modules contributed by the community. Puppet modules flagged as supported are officially supported and tested by Puppet Inc. This example shows how to add the ntp module to managed hosts. Procedure Navigate to forge.puppet.com and search for ntp . One of the first modules is puppetlabs/ntp . Connect to your Satellite Server using SSH and install the Puppet module: Use the -i parameter to specify the path and Puppet environment, for example production . Once the installation is completed, the output looks as follows: An alternative way to install a Puppet module is to copy a folder containing the Puppet module to the module path as mentioned above. Ensure to resolve its dependencies manually. 2.2. Updating a Puppet Module You can update an existing Puppet module using the puppet command. Procedure Connect to your Puppet server using SSH and find out where the Puppet modules are located: This returns output as follows: If the module is located in the path as displayed above, the following command updates a module:

Commands:
puppet module install puppetlabs-ntp -i /etc/puppetlabs/code/environments/production/modules
Notice: Preparing to install into /etc/puppetlabs/code/environments/production/modules Notice: Created target directory /etc/puppetlabs/code/environments/production/modules Notice: Downloading from https://forgeapi.puppet.com Notice: Installing -- do not interrupt /etc/puppetlabs/code/environments/production/modules |-| puppetlabs-ntp (v8.3.0) |-- puppetlabs-stdlib (v4.25.1) [/etc/puppetlabs/code/environments/production/modules]
puppet config print modulepath
/etc/puppetlabs/code/environments/production/modules:/etc/puppetlabs/code/environments/common:/etc/puppetlabs/code/modules:/opt/puppetlabs/puppet/modules:/usr/share/puppet/modules
puppet module upgrade module name
6.4.2. Deadline I/O Scheduler The deadline I/O scheduler attempts to provide a guaranteed latency for requests. It is important to note that the latency measurement only starts when the requests gets down to the I/O scheduler (this is an important distinction, as an application may be put to sleep waiting for request descriptors to be freed). By default, reads are given priority over writes, since applications are more likely to block on read I/O. Deadline dispatches I/Os in batches. A batch is a sequence of either read or write I/Os which are in increasing LBA order (the one-way elevator). After processing each batch, the I/O scheduler checks to see whether write requests have been starved for too long, and then decides whether to start a new batch of reads or writes. The FIFO list of requests is only checked for expired requests at the start of each batch, and then only for the data direction of that batch. So, if a write batch is selected, and there is an expired read request, that read request will not get serviced until the write batch completes. Tunables fifo_batch This determines the number of reads or writes to issue in a single batch. The default is 16 . Setting this to a higher value may result in better throughput, but will also increase latency. front_merges You can set this tunable to 0 if you know your workload will never generate front merges. Unless you have measured the overhead of this check, it is advisable to leave it at its default setting ( 1 ). read_expire This tunable allows you to set the number of milliseconds in which a read request should be serviced. By default, this is set to 500 ms (half a second). write_expire This tunable allows you to set the number of milliseconds in which a write request should be serviced. By default, this is set to 5000 ms (five seconds). writes_starved This tunable controls how many read batches can be processed before processing a single write batch. The higher this is set, the more preference is given to reads.

Commands:
Chapter 6. Tools for application migration Before you migrate your applications from Red Hat build of OpenJDK version 8, 11, or 17 to Red Hat build of OpenJDK 21, you can use tools to test the suitability of your applications to run on Red Hat build of OpenJDK 21. You can use the following steps to enhance your testing process: Update third-party libraries. Compile your application code. Run jdeps on your application's code. Use the migration toolkit for applications (MTA) tool to migrate Java applications from Red Hat build of OpenJDK version 8, 11, or 17 to Red Hat build of OpenJDK 21. Additional resources For more information about the MTA tool, see the Introduction to the Migration Toolkit for Applications guide.

Commands:
1.2. Examples The following examples demonstrate how SELinux increases security: The default action is deny. If an SELinux policy rule does not exist to allow access, such as for a process opening a file, access is denied. SELinux can confine Linux users. A number of confined SELinux users exist in the SELinux policy. Linux users can be mapped to confined SELinux users to take advantage of the security rules and mechanisms applied to them. For example, mapping a Linux user to the SELinux user_u user, results in a Linux user that is not able to run (unless configured otherwise) set user ID (setuid) applications, such as sudo and su . See Section 3.3, "Confined and Unconfined Users" for more information. Increased process and data separation. Processes run in their own domains, preventing processes from accessing files used by other processes, as well as preventing processes from accessing other processes. For example, when running SELinux, unless otherwise configured, an attacker cannot compromise a Samba server, and then use that Samba server as an attack vector to read and write to files used by other processes, such as MariaDB databases. SELinux helps mitigate the damage made by configuration mistakes. Domain Name System (DNS) servers often replicate information between each other in what is known as a zone transfer. Attackers can use zone transfers to update DNS servers with false information. When running the Berkeley Internet Name Domain (BIND) as a DNS server in Red Hat Enterprise Linux, even if an administrator forgets to limit which servers can perform a zone transfer, the default SELinux policy prevents zone files [1] from being updated using zone transfers, by the BIND named daemon itself, and by other processes. See the NetworkWorld.com article, A seatbelt for server software: SELinux blocks real-world exploits [2] , for background information about SELinux, and information about various exploits that SELinux has prevented. [1] Text files that include information, such as host name to IP address mappings, that are used by DNS servers. [2] Marti, Don. "A seatbelt for server software: SELinux blocks real-world exploits". Published 24 February 2008. Accessed 27 August 2009: http://www.networkworld.com/article/2283723/lan-wan/a-seatbelt-for-server-software--selinux-blocks-real-world-exploits.html .

Commands:
4.54. emacs 4.54.1. RHBA-2012:0042 - emacs bug fix update Updated emacs packages that fix one bug are now available for Red Hat Enterprise Linux 6. GNU Emacs is a powerful, customizable, self-documenting text editor. It provides special code editing features, a scripting language (elisp), and the capability to read email and news. Bug Fix BZ# 769673 Emacs did not properly terminate if it was started remotely and the remote client session was closed while Emacs was suspended. Under these conditions, Emacs entered an infinite loop in the code and gradually consumed all available computer resources, which caused the system to become unstable. With this update, Emacs has been modified, and it now terminates correctly when the remote session is closed. All users of emacs are advised to upgrade to these updated packages, which fix this bug. 4.54.2. RHBA-2012:0348 - emacs bug fix update Updated emacs packages that fix one bug are now available for Red Hat Enterprise Linux 6. GNU Emacs is a powerful, customizable, self-documenting text editor. It provides special code editing features, a scripting language (elisp), and the capability to read e-mail and news. Bug Fix BZ# 796053 In ispell mode, Emacs used the spell checkers in the following order: Ispell, Aspell, and Hunspell. However, Ispell is no longer available and Aspell does not have any dictionaries installed by default. Consequently, because Emacs found Aspell before the default Hunspell, the spell check failed and Emacs reported the following error message: With this update, Emacs has been modified to look for the spell checkers in the following order: Hunspell, Aspell, and Ispell. This ensures that Hunspell is used by default when it is available. All users of emacs are advised to upgrade to these updated packages, which fix this bug.

Commands:
ispell-init-process: Error: No word lists can be found for the language "en_US".
Chapter 8. Networking Troubleshoot networking issues. 8.1. Issue - The default subnet used in Ansible Automation Platform containers conflicts with the internal network The default subnet used in Ansible Automation Platform containers conflicts with the internal network resulting in "No route to host" errors. To resolve this issue, update the default classless inter-domain routing (CIDR) value so it does not conflict with the CIDR used by the default Podman networking plugin. Procedure In all controller and hybrid nodes, run the following commands to create a file called custom.py : # touch /etc/tower/conf.d/custom.py # chmod 640 /etc/tower/conf.d/custom.py # chown root:awx /etc/tower/conf.d/custom.py Add the following to the /etc/tower/conf.d/custom.py file: DEFAULT_CONTAINER_RUN_OPTIONS = ['--network', 'slirp4netns:enable_ipv6=true,cidr=192.0.2.0/24'] 192.0.2.0/24 is the value for the new CIDR in this example. Stop and start the automation controller service in all controller and hybrid nodes: # automation-controller-service stop # automation-controller-service start All containers will start on the new CIDR.

Commands:
touch /etc/tower/conf.d/custom.py
chmod 640 /etc/tower/conf.d/custom.py
chown root:awx /etc/tower/conf.d/custom.py
DEFAULT_CONTAINER_RUN_OPTIONS = ['--network', 'slirp4netns:enable_ipv6=true,cidr=192.0.2.0/24']
automation-controller-service stop
automation-controller-service start
E.2.24. /proc/slabinfo This file gives full information about memory usage on the slab level. Linux kernels greater than version 2.2 use slab pools to manage memory above the page level. Commonly used objects have their own slab pools. Instead of parsing the highly verbose /proc/slabinfo file manually, the /usr/bin/slabtop program displays kernel slab cache information in real time. This program allows for custom configurations, including column sorting and screen refreshing. A sample screen shot of /usr/bin/slabtop usually looks like the following example: Some of the more commonly used statistics in /proc/slabinfo that are included into /usr/bin/slabtop include: OBJS - The total number of objects (memory blocks), including those in use (allocated), and some spares not in use. ACTIVE - The number of objects (memory blocks) that are in use (allocated). USE - Percentage of total objects that are active. ((ACTIVE/OBJS)(100)) OBJ SIZE - The size of the objects. SLABS - The total number of slabs. OBJ/SLAB - The number of objects that fit into a slab. CACHE SIZE - The cache size of the slab. NAME - The name of the slab. For more information on the /usr/bin/slabtop program, refer to the slabtop man page.

Commands:
Active / Total Objects (% used) : 133629 / 147300 (90.7%) Active / Total Slabs (% used) : 11492 / 11493 (100.0%) Active / Total Caches (% used) : 77 / 121 (63.6%) Active / Total Size (% used) : 41739.83K / 44081.89K (94.7%) Minimum / Average / Maximum Object : 0.01K / 0.30K / 128.00K OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME 44814 43159 96% 0.62K 7469 6 29876K ext3_inode_cache 36900 34614 93% 0.05K 492 75 1968K buffer_head 35213 33124 94% 0.16K 1531 23 6124K dentry_cache 7364 6463 87% 0.27K 526 14 2104K radix_tree_node 2585 1781 68% 0.08K 55 47 220K vm_area_struct 2263 2116 93% 0.12K 73 31 292K size-128 1904 1125 59% 0.03K 16 119 64K size-32 1666 768 46% 0.03K 14 119 56K anon_vma 1512 1482 98% 0.44K 168 9 672K inode_cache 1464 1040 71% 0.06K 24 61 96K size-64 1320 820 62% 0.19K 66 20 264K filp 678 587 86% 0.02K 3 226 12K dm_io 678 587 86% 0.02K 3 226 12K dm_tio 576 574 99% 0.47K 72 8 288K proc_inode_cache 528 514 97% 0.50K 66 8 264K size-512 492 372 75% 0.09K 12 41 48K bio 465 314 67% 0.25K 31 15 124K size-256 452 331 73% 0.02K 2 226 8K biovec-1 420 420 100% 0.19K 21 20 84K skbuff_head_cache 305 256 83% 0.06K 5 61 20K biovec-4 290 4 1% 0.01K 1 290 4K revoke_table 264 264 100% 4.00K 264 1 1056K size-4096 260 256 98% 0.19K 13 20 52K biovec-16 260 256 98% 0.75K 52 5 208K biovec-64
Chapter 1. Introduction 1.1. Why Performance Optimization Matters in Virtualization In KVM Virtualization, guests are represented by processes on the host machine. This means that processing power, memory, and other resources of the host are used to emulate the functions and capabilities of the guest's virtual hardware. However, guest hardware can be less effective at using the resources than the host. Therefore, adjusting the amount of allocated host resources may be needed for the guest to perform its tasks at the expected speed. In addition, various types of virtual hardware may have different levels of overhead, so an appropriate virtual hardware configuration can have significant impact on guest performance. Finally, depending on the circumstances, specific configurations enable virtual machines to use host resources more efficiently.

Commands:
14.2.3. Migrating Extents To migrate extents from a physical volume, select the volume from the list in the left pane, highlight the desired extents in the central window, and click on the Migrate Selected Extent(s) From Volume button. You need to have a sufficient number of free extents to migrate extents within a volume group. An error message will be displayed if you do not have a sufficient number of free extents. To resolve this problem, extend your volume group (see Section 14.2.6, "Extending a Volume Group" ). If a sufficient number of free extents is detected in the volume group, a pop-up window will be displayed from which you can select the destination for the extents or automatically let LVM choose the physical volumes (PVs) to migrate them to. This is illustrated below. Figure 14.10. Migrate Extents The figure below illustrates a migration of extents in progress. In this example, the extents were migrated to 'Partition 3'. Figure 14.11. Migrating extents in progress Once the extents have been migrated, unused space is left on the physical volume. The figure below illustrates the physical and logical view for the volume group. The extents of LogVol00 which were initially in hda2 are now in hda3. Migrating extents allows you to move logical volumes in case of hard disk upgrades or to manage your disk space better. Figure 14.12. Logical and physical view of volume group

Commands:
klusterlet add-ons Red Hat Advanced Cluster Management for Kubernetes 2.11 klusterlet add-ons

Commands:
apiVersion: agent.open-cluster-management.io/v1 kind: KlusterletAddonConfig metadata: name: <cluster_name> namespace: <cluster_name> spec: applicationManager: enabled: true certPolicyController: enabled: true policyController: 1 enabled: true searchCollector: enabled: true
apply -f klusterlet-addon-config.yaml
get managedclusteraddons -n <cluster namespace>
apiVersion: addon.open-cluster-management.io/v1alpha1 kind: AddOnDeploymentConfig metadata: name: config-name 1 namespace: config-name-space 2 spec: nodePlacement: nodeSelector: node-selector 3 tolerations: tolerations 4
apiVersion: addon.open-cluster-management.io/v1alpha1 kind: AddOnDeploymentConfig metadata: name: deploy-config namespace: open-cluster-management-hub spec: nodePlacement: nodeSelector: "node-dedicated": "acm-addon" tolerations: - effect: NoSchedule key: node-dedicated value: acm-addon operator: Equal
apply -f addondeploymentconfig
patch clustermanagementaddons <addon-name> --type='json' -p='[{"op":"add", "path":"/spec/supportedConfigs", "value":[{"group":"addon.open-cluster-management.io","resource":"addondeploymentconfigs", "defaultConfig":{"name":"deploy-config","namespace":"open-cluster-management-hub"}}]}]'
-n <managed-cluster> patch managedclusteraddons <addon-name> --type='json' -p='[{"op":"add", "path":"/spec/configs", "value":[ {"group":"addon.open-cluster-management.io","resource":"addondeploymentconfigs","namespace":"<config-namespace>","name":"<config-name>"} ]}]'
-n <my-cluster-name> edit klusterletaddonconfig <my-cluster-name>
-n <my-cluster-name> edit klusterletaddonconfig
spec proxyConfig: httpProxy: "<proxy_not_secure>" 1 httpsProxy: "<proxy_secure>" 2 noProxy: "<no_proxy>" 3
apiVersion: agent.open-cluster-management.io/v1 kind: KlusterletAddonConfig metadata: name: clusterName namespace: clusterName spec: proxyConfig: httpProxy: http://pxuser:12345@10.0.81.15:3128 httpsProxy: http://pxuser:12345@10.0.81.15:3128 noProxy: .cluster.local,.svc,10.128.0.0/14, example.com applicationManager: enabled: true proxyPolicy: CustomProxy policyController: enabled: true proxyPolicy: OCPGlobalProxy searchCollector: enabled: true proxyPolicy: Disabled certPolicyController: enabled: true proxyPolicy: Disabled
B.43. libtiff B.43.1. RHSA-2011:0318 - Important: libtiff security update Updated libtiff packages that fix one security issue are now available for Red Hat Enterprise Linux 4, 5, and 6. The Red Hat Security Response Team has rated this update as having important security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available from the CVE link(s) associated with each description below. The libtiff packages contain a library of functions for manipulating Tagged Image File Format (TIFF) files. CVE-2011-0192 A heap-based buffer overflow flaw was found in the way libtiff processed certain TIFF Internet Fax image files, compressed with the CCITT Group 4 compression algorithm. An attacker could use this flaw to create a specially-crafted TIFF file that, when opened, would cause an application linked against libtiff to crash or, possibly, execute arbitrary code. Red Hat would like to thank Apple Product Security for reporting this issue. All libtiff users should upgrade to these updated packages, which contain a backported patch to resolve this issue. All running applications linked against libtiff must be restarted for this update to take effect.

Commands:
A.2. Download API Documentation Javadocs for Red Hat JBoss Data Virtualization can be found on the Red Hat Customer Portal . Procedure A.1. Download API Documentation Open a web browser and navigate to https://access.redhat.com/jbossnetwork . From the Software Downloads page, when prompted for a Product , select Data Virtualization . This will present a table of files to download for the latest version of the product. Change the Version to the current release if required. Look for Red Hat JBoss Data Virtualization VERSION Javadocs in the table and select Download .

Commands:
21.4. Exposing Automount Maps to NIS Clients If any automount maps are already defined, you must manually add them to the NIS configuration in IdM. This ensures the maps are exposed to NIS clients. The NIS server is managed by a special plug-in entry in the IdM LDAP directory. Each NIS domain and map used by the NIS server is added as a sub-entry in this container. The NIS domain entry contains: the name of the NIS domain the name of the NIS map information on how to find the directory entries to use as the NIS map's contents information on which attributes to use as the NIS map's key and value Most of these settings are the same for every map. 21.4.1. Adding an Automount Map IdM stores the automount maps, grouped by the automount location, in the cn=automount branch of the IdM directory tree. You can add the NIS domain and maps using the LDAP protocol. For example, to add an automount map named auto.example in the default location for the example.com domain: Note Set the nis-domain attribute to the name of your NIS domain. The value set in the nis-base attribute must correspond: To an existing automount map set using the ipa automountmap-* commands. To an existing automount location set using the ipa automountlocation-* commands. After you set the entry, you can verify the automount map:

Commands:
ldapadd -h server.example.com -x -D "cn=Directory Manager" -W dn: nis-domain=example.com+nis-map=auto.example,cn=NIS Server,cn=plugins,cn=config objectClass: extensibleObject nis-domain: example.com nis-map: auto.example nis-filter: (objectclass=automount) nis-key-format: %{automountKey} nis-value-format: %{automountInformation} nis-base: automountmapname=auto.example,cn=default,cn=automount,dc=example,dc=com
ypcat -k -d example.com -h server.example.com auto.example