mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 6. Changes in Go Toolset Go Toolset has been updated from version 1.19 to 1.20.10 on RHEL 8 and RHEL 9. Notable changes include: New functions added in the unsafe package to handle slices and strings without depending on the internal representation. Comparable types can now satisfy comparable constraints. A new crypto/ecdh package. The go build and go test commands no longer accept the -i flag. The go generate and go test commands now accept the -skip pattern option. The go build , go install , and other build-related commands now support the -pgo and -cover flags. The go command now disables cgo by default on systems without a C toolchain. The go version -m command now supports reading more Go binaries types. The go command now disables cgo by default on systems without a C toolchain. Added support for collecting code coverage profiles from applications and integration tests instead of collecting them only from unit tests. For detailed information regarding the updates, see the upstream Go 1.20 Release Notes .

Commands:
Chapter 10. FS-Cache FS-Cache is a persistent local cache that can be used by file systems to take data retrieved from over the network and cache it on local disk. This helps minimize network traffic for users accessing data from a file system mounted over the network (for example, NFS). The following diagram is a high-level illustration of how FS-Cache works: Figure 10.1. FS-Cache Overview FS-Cache is designed to be as transparent as possible to the users and administrators of a system. Unlike cachefs on Solaris, FS-Cache allows a file system on a server to interact directly with a client's local cache without creating an overmounted file system. With NFS, a mount option instructs the client to mount the NFS share with FS-cache enabled. FS-Cache does not alter the basic operation of a file system that works over the network - it merely provides that file system with a persistent place in which it can cache data. For instance, a client can still mount an NFS share whether or not FS-Cache is enabled. In addition, cached NFS can handle files that won't fit into the cache (whether individually or collectively) as files can be partially cached and do not have to be read completely up front. FS-Cache also hides all I/O errors that occur in the cache from the client file system driver. To provide caching services, FS-Cache needs a cache back end . A cache back end is a storage driver configured to provide caching services (i.e. cachefiles ). In this case, FS-Cache requires a mounted block-based file system that supports bmap and extended attributes (e.g. ext3) as its cache back end. FS-Cache cannot arbitrarily cache any file system, whether through the network or otherwise: the shared file system's driver must be altered to allow interaction with FS-Cache, data storage/retrieval, and metadata setup and validation. FS-Cache needs indexing keys and coherency data from the cached file system to support persistence: indexing keys to match file system objects to cache objects, and coherency data to determine whether the cache objects are still valid. Note In Red Hat Enterprise Linux 7, the cachefilesd package is not installed by default and needs to be installed manually. 10.1. Performance Guarantee FS-Cache does not guarantee increased performance, however it ensures consistent performance by avoiding network congestion. Using a cache back end incurs a performance penalty: for example, cached NFS shares add disk accesses to cross-network lookups. While FS-Cache tries to be as asynchronous as possible, there are synchronous paths (e.g. reads) where this isn't possible. For example, using FS-Cache to cache an NFS share between two computers over an otherwise unladen GigE network will not demonstrate any performance improvements on file access. Rather, NFS requests would be satisfied faster from server memory rather than from local disk. The use of FS-Cache, therefore, is a compromise between various factors. If FS-Cache is being used to cache NFS traffic, for instance, it may slow the client down a little, but massively reduce the network and server loading by satisfying read requests locally without consuming network bandwidth.

Commands:
13.4. InfiniBand and RDMA related software packages Because RDMA applications are so different from Berkeley Sockets based applications, and from normal IP networking, most applications that are used on an IP network cannot be used directly on an RDMA network. Red Hat Enterprise Linux 7 comes with a number of different software packages for RDMA network administration, testing and debugging, high level software development APIs, and performance analysis. In order to utilize these networks, some or all of these packages need to be installed (this list is not exhaustive, but does cover the most important packages related to RDMA). Required packages: rdma - responsible for kernel initialization of the RDMA stack. libibverbs - provides the InfiniBand Verbs API. opensm - subnet manager (only required on one machine, and only if there is no subnet manager active on the fabric). user space driver for installed hardware - one or more of: infinipath-psm , libcxgb3 , libcxgb4 , libehca , libipathverbs , libmthca , libmlx4 , libmlx5 , libnes , and libocrdma . Note that libehca is only available for IBM Power Systems servers. Recommended packages: librdmacm , librdmacm-utils , and ibacm - Connection management library that is aware of the differences between InfiniBand, iWARP, and RoCE and is able to properly open connections across all of these hardware types, some simple test programs for verifying the operation of the network, and a caching daemon that integrates with the library to make remote host resolution faster in large clusters. libibverbs-utils - Simple Verbs based programs for querying the installed hardware and verifying communications over the fabric. infiniband-diags and ibutils - Provide a number of useful debugging tools for InfiniBand fabric management. These provide only very limited functionality on iWARP or RoCE as most of the tools work at the InfiniBand link layer, not the Verbs API layer. perftest and qperf - Performance testing applications for various types of RDMA communications. Optional packages: These packages are available in the Optional channel. Before installing packages from the Optional channel, see Scope of Coverage Details . Information on subscribing to the Optional channel can be found in the Red Hat Knowledgebase solution How to access Optional and Supplementary channels . dapl , dapl-devel , and dapl-utils - Provide a different API for RDMA than the Verbs API. There is both a runtime component and a development component to these packages. openmpi , mvapich2 , and mvapich2-psm - MPI stacks that have the ability to use RDMA communications. User-space applications writing to these stacks are not necessarily aware that RDMA communications are taking place.

Commands:
1.2. Adding the Keyboard Layout Indicator If you want to see what keyboard layout you are currently using, or you would like to switch between different layouts with a single mouse click, add the Keyboard Indicator applet to the panel. To do so, right-click the empty space on the main panel, and select the Add to Panel option from the pulldown menu. Figure 1.5. Adding a new applet You will be presented with a list of available applets. Scroll through the list (or start typing " keyboard " into the search field at the top of the window), select Keyboard Indicator , and click the Add button. Figure 1.6. Selecting the Keyboard Indicator The applet appears immediately, displaying the shortened name of the country the current layout is associated with. To display the actual variant, hover the pointer over the applet icon. Figure 1.7. The Keyboard Indicator applet

Commands:
1.8.2. Making the Kickstart File Available on the Network Network installations using kickstart are quite common, because system administrators can easily automate the installation on many networked computers quickly and painlessly. In general, the approach most commonly used is for the administrator to have both a BOOTP/DHCP server and an NFS server on the local network. The BOOTP/DHCP server is used to give the client system its networking information, while the actual files used during the installation are served by the NFS server. Often, these two servers run on the same physical machine, but they are not required to. To perform a network-based kickstart installation, you must have a BOOTP/DHCP server on your network, and it must include configuration information for the machine on which you are attempting to install Red Hat Enterprise Linux. The BOOTP/DHCP server provides the client with its networking information as well as the location of the kickstart file. If a kickstart file is specified by the BOOTP/DHCP server, the client system attempts an NFS mount of the file's path, and copies the specified file to the client, using it as the kickstart file. The exact settings required vary depending on the BOOTP/DHCP server you use. Here is an example of a line from the dhcpd.conf file for the DHCP server: Note that you should replace the value after filename with the name of the kickstart file (or the directory in which the kickstart file resides) and the value after -server with the NFS server name. If the file name returned by the BOOTP/DHCP server ends with a slash ("/"), then it is interpreted as a path only. In this case, the client system mounts that path using NFS, and searches for a particular file. The file name the client searches for is: The <ip-addr> section of the file name should be replaced with the client's IP address in dotted decimal notation. For example, the file name for a computer with an IP address of 10.10.0.1 would be 10.10.0.1-kickstart . Note that if you do not specify a server name, then the client system attempts to use the server that answered the BOOTP/DHCP request as its NFS server. If you do not specify a path or file name, the client system tries to mount /kickstart from the BOOTP/DHCP server and tries to find the kickstart file using the same <ip-addr> -kickstart file name as described above.

Commands:
filename "/usr/new-machine/kickstart/" ; next-server blarg.redhat.com;
<ip-addr> -kickstart
Chapter 11. Allowing JavaScript-based access to the API server from additional hosts 11.1. Allowing JavaScript-based access to the API server from additional hosts The default OpenShift Container Platform configuration only allows the web console to send requests to the API server. If you need to access the API server or OAuth server from a JavaScript application using a different hostname, you can configure additional hostnames to allow. Prerequisites Access to the cluster as a user with the cluster-admin role. Procedure Edit the APIServer resource: USD oc edit apiserver.config.openshift.io cluster Add the additionalCORSAllowedOrigins field under the spec section and specify one or more additional hostnames: apiVersion: config.openshift.io/v1 kind: APIServer metadata: annotations: release.openshift.io/create-only: "true" creationTimestamp: "2019-07-11T17:35:37Z" generation: 1 name: cluster resourceVersion: "907" selfLink: /apis/config.openshift.io/v1/apiservers/cluster uid: 4b45a8dd-a402-11e9-91ec-0219944e0696 spec: additionalCORSAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) 1 1 The hostname is specified as a Golang regular expression that matches against CORS headers from HTTP requests against the API server and OAuth server. Note This example uses the following syntax: The (?i) makes it case-insensitive. The // pins to the beginning of the domain and matches the double slash following http: or https: . The \. escapes dots in the domain name. The (:|\z) matches the end of the domain name (\z) or a port separator (:) . Save the file to apply the changes.

Commands:
oc edit apiserver.config.openshift.io cluster
apiVersion: config.openshift.io/v1 kind: APIServer metadata: annotations: release.openshift.io/create-only: "true" creationTimestamp: "2019-07-11T17:35:37Z" generation: 1 name: cluster resourceVersion: "907" selfLink: /apis/config.openshift.io/v1/apiservers/cluster uid: 4b45a8dd-a402-11e9-91ec-0219944e0696 spec: additionalCORSAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) 1
Appendix C. Using AMQ Broker with the examples The AMQ JMS examples require a running message broker with a queue named queue . 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 queue . USD <broker-instance-dir> /bin/artemis queue create --name queue --address queue --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-05-07 10:16:22 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 queue --address queue --auto-create-address --anycast
<broker-instance-dir> /bin/artemis stop
Chapter 8. Setting a default desktop session for all users You can configure a default desktop session that is preselected for all users that have not logged in yet. If a user logs in using a different session than the default, their selection persists to their login. Procedure Copy the configuration file template: Edit the new /etc/accountsservice/user-templates/standard file. On the Session= gnome line, replace gnome with the session that you want to set as the default. Optional: To configure an exception to the default session for a certain user, follow these steps: Copy the template file to /var/lib/AccountsService/users/ user-name : In the new file, replace variables such as USD{USER} and USD{ID} with the user values. Edit the Session value.

Commands:
cp /usr/share/accountsservice/user-templates/standard /etc/accountsservice/user-templates/standard
cp /usr/share/accountsservice/user-templates/standard /var/lib/AccountsService/users/ user-name
Chapter 8. sVirt sVirt is a technology included in Red Hat Enterprise Linux that integrates SELinux and virtualization. sVirt applies Mandatory Access Control (MAC) to improve security when using virtual machines. The main reasons for integrating these technologies are to improve security and harden the system against bugs in the hypervisor that might be used as an attack vector aimed toward the host or to another virtual machine. This chapter describes how sVirt integrates with virtualization technologies in Red Hat Enterprise Linux. Non-Virtualized Environment In a non-virtualized environment, hosts are separated from each other physically and each host has a self-contained environment, consisting of services such as a Web server, or a DNS server. These services communicate directly to their own user space, host kernel and physical host, offering their services directly to the network. The following image represents a non-virtualized environment: Virtualized Environment In a virtualized environment, several operating systems can be housed (as "guests") within a single host kernel and physical host. The following image represents a virtualized environment: 8.1. Security and Virtualization When services are not virtualized, machines are physically separated. Any exploit is usually contained to the affected machine, with the obvious exception of network attacks. When services are grouped together in a virtualized environment, extra vulnerabilities emerge in the system. If there is a security flaw in the hypervisor that can be exploited by a guest instance, this guest may be able to not only attack the host, but also other guests running on that host. This is not theoretical; attacks already exist on hypervisors. These attacks can extend beyond the guest instance and could expose other guests to attack. sVirt is an effort to isolate guests and limit their ability to launch further attacks if exploited. This is demonstrated in the following image, where an attack cannot break out of the virtual machine and extend to another host instance: SELinux introduces a pluggable security framework for virtualized instances in its implementation of Mandatory Access Control (MAC). The sVirt framework allows guests and their resources to be uniquely labeled. Once labeled, rules can be applied which can reject access between different guests.

Commands:
4.3. RHEA-2012:0831 - new package: device-mapper-persistent-data A new device-mapper-persistent-data package is now available for Red Hat Enterprise Linux 6. The device-mapper-persistent-data package provides device-mapper thin provisioning (thinp) tools. This enhancement update adds the device-mapper-persistent-data package to Red Hat Enterprise Linux 6 as a Technology Preview. (BZ# 760614 ) More information about Red Hat Technology Previews is available here: https://access.redhat.com/support/offerings/techpreview/ All users who require device-mapper-persistent-data should install this new package, which adds this enhancement.

Commands:
Chapter 55. Compiler and Tools Performance of regular expressions cannot be boosted with the JIT technique if executable stack is disabled When the SELinux policy disallows executable stack, the PCRE library cannot use JIT compilation to speed up regular expressions. As a result, attempting JIT compilation for regular expressions is ignored and their performance is not boosted. To work around this problem, amend the SELinux policy with a rule for enabling the execmem action on affected SELinux domains to enable JIT compilation. Some of the rules are already provided and can be enabled by specific SELinux booleans. To list these booleans, see the output of the following command: An alternative workaround is changing application code to not request JIT compilation with calls to the pcre_study() function. (BZ# 1290432 ) Memory leaks occur when certain applications fail to exit after unloading the Gluster libraries Gluster consists of many internal components and different translators that implement functions and features. The gfapi access method was added to integrate Gluster tightly with applications. However, not all components and translators are designed to be unloaded in running applications. As a consequence, programs that do not exit after unloading the Gluster libraries are unable to release some of the memory allocations that are performed internally by Gluster. To reduce the amount of memory leaks, prevent applications from calling the glfs_init() and glfs_fini() functions whenever possible. To release the leaked memory, you must restart long-running applications. (BZ# 1409773 ) URL to DISA SRGs is incorrect The SCAP Security Guide (SSG) rules refer to Defense Information Systems Agency Security Requirement Guides (DISA SRGs). Connecting to the URL fails with an 404 - not found error. As a consequence, users have no direct reference to SRGs. (BZ# 1464899 ) The ensure_gpgcheck_repo_metadata rule fails During remediation of the ensure_gpgcheck_repo_metadata rule, certain profiles update the yum.conf file to enable the repo_gpgcheck option. Red Hat does not currently provide signed repository metadata. As a consequence, the yum utility is no longer able to install any package from official repositories. To work around the problem, use a tailoring file to remove ensure_gpgcheck_repo_metadata from the profile. If remediation already breaks the system, update yum.conf and set repo_gpgcheck to 0 . (BZ# 1465677 ) The SSG pam_faillock module utilization check incorrectly accepts default=die The SCAP Security Guide (SSG) pam_faillock module utilization check incorrectly accepts the default=die option. Consequently, when a user authentication using the pam_unix module fails, the pam stack evaluation stops immediately without incrementing the counter of pam_faillock. To work around this problem, do not use default=die before the authfail option. This ensures that the pam_faillock counter is incremented properly. (BZ#1448952)

Commands:
getsebool -a | grep execmem
8.184. powerpc-utils 8.184.1. RHBA-2014:1454 - powerpc-utils bug fix and enhancement update Updated powerpc-utils packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The powerpc-utils packages provide various utilities for the PowerPC platform. * The update_flash utility now supports Firmware Entitlement Checking. (BZ# 1006777 ) * The ofpathname utility now supports virtio-blk disks. (BZ# 1039462 ) In addition, this update fixes the following bug: Note The powerpc-utils packages have been upgraded to upstream version 1.2.20, which provides a number of bug fixes and enhancements over the version. Among others, the powerpc-utils packages now provide the following new features: * Support for Dynamic CPU Affinity using the Platform Resource Reassignment Notifications (PRRN) interface from user space has been added. (BZ# 1021522 ) * The update_flash utility now supports Firmware Entitlement Checking. (BZ#1006777) * The ofpathname utility now supports virtio-blk disks. (BZ#1039462) In addition, this update fixes the following bug: Bug Fixes BZ# 1021522 Support for Dynamic CPU Affinity using the Platform Resource Reassignment Notifications (PRRN) interface from user space has been added. BZ# 1006777 The update_flash utility now supports Firmware Entitlement Checking. BZ# 1039462 The ofpathname utility now supports virtio-blk disks. BZ# 1064496 , BZ# 1087723 Previously, the kernel was not notified before and after an update of a device tree during a partition migration. As a consequence, the lpar utility terminated unexpectedly upon resuming after the migration. With this update, the kernel is notified as expected and lpar no longer crashes in the described scenario. The powerpc-utils packages have been upgraded to upstream version 1.2.20, which provides a number of bug fixes and enhancements over the version. Among others, the powerpc-utils packages now provide the following new features: Users of powerpc-utils are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands: