mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 17. Identity: Managing DNS If the IdM server was installed with DNS configured, then all of the DNS entries for the domain - host entries, locations, records - can be managed using the IdM tools. 17.1. About DNS in IdM DNS is one of the services that can be configured and maintained by the IdM domain. DNS is critical to the performance of the IdM domain; DNS is used for the Kerberos services and SSL connections for all servers and clients and for connections to domain services like LDAP. While IdM can use an external DNS service, there is a lot more flexibility and control over IdM - DNS interactions when the DNS service is configured within the domain. For example, DNS records and zones can be managed within the domain using IdM tools, and clients can update their own DNS records dynamically. When a host is added to IdM, a DNS record is automatically created in IdM's DNS service for that host machine. IdM stores all DNS information as LDAP entries. Every resource record for each machine is stored for the domain. For example, the client1 resource has three IPv4 (A) records and one IPv6 (AAAA) record: The schema used to define the DNS entries is in the /usr/share/ipa/60basev2.ldif schema file [6] . The BIND service communicates with the Directory Server using the system bind-dyndb-ldap plug-in. When Identity Management is configured to manage DNS, IdM creates a dynamic-db configuration section in the /etc/named.conf file for the BIND service. This configures the bind-dyndb-ldap plug-in for the BIND ( named ) service. When this plug-in is properly configured, it delivers the DNS records from the Directory Server to the named service. The configuration can be changed to adapt the behavior of the plug-in and, therefore, the LDAP-BIND interactions. [6] Any updated schema files, included updated DNS schema elements, are located in the /usr/share/ipa/updates directory.

Commands:
dn: idnsname=client1,idnsname=example.com,cn=dns,dc=example,dc=com idnsname: client1 arecord: 10.0.0.1 arecord: 10.0.0.2 arecord: 10.0.0.3 aaaarecord: fc00::1 objectclass: top objectclass: idnsrecord
3.3. Virtual Disk Performance Options Several virtual disk related options are available to your guest virtual machines during installation that can impact performance. The following image shows the virtual disk options available to your guests. The cache mode, IO mode, and IO tuning can be selected in the Virtual Disk section in virt-manager . Set these parameters in the fields under Performance options , as shown in the following image: Figure 3.7. Virtual Disk Performance Options Important When setting the virtual disk performance options in virt-manager , the virtual machine must be restarted for the settings to take effect. See Section 7.2, "Caching" and Section 7.3, "I/O Mode" for descriptions of these settings and instructions for editing these settings in the guest XML configuration.

Commands:
Chapter 3. Installing Red Hat build of OpenJDK 8 for Microsoft Windows with the archive This procedure describe how to manually install Red Hat build of OpenJDK 8 for Microsoft Windows using the archive. Procedure Download the archive of Red Hat build of OpenJDK 8 for Microsoft Windows. Extract the contents of the archive to a directory of your choice. Note Extracting the contents of the archive to a directory path that does not contain spaces is recommended. Update the PATH as below: Add the bin directory contained in your Red Hat build of OpenJDK 8 for Microsoft Windows installation path to the %PATH% environment variable: If the path contains spaces, use the shortened path name. Restart Command Prompt to reload the environment variables. Verify the Red Hat build of OpenJDK 8 for Microsoft Windows is successfully installed, run java -version command in a command prompt and you must get the following output: The %JAVA_HOME% environment variable must also be set to use some developer tools. Set the %JAVA_HOME% environment variable as follows: Open Command Prompt as an administrator. Set the value of the environment variable to your Red Hat build of OpenJDK 8 for Microsoft Windows installation path: If the path contains spaces, use the shortened path name. Restart Command Prompt to reload the environment variables

Commands:
C:\> setx /m PATH "%PATH%;C:\Progra~1\RedHat\java-1.8.0-openjdk-1.8.0.181-1\bin"
java version "1.8.0_181" Java(TM) SE Runtime Environment (build 1.8.0_181-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
C:\> setx /m JAVA_HOME "C:\Progra~1\RedHat\java-1.8.0-openjdk-1.8.0.181-1"
Chapter 2. Eclipse Temurin overview Eclipse Temurin is a free and open source implementation of the Java Platform, Standard Edition (Java SE) from the Eclipse Temurin Working Group. Eclipse Temurin is based on the upstream Red Hat build of OpenJDK 8u, Red Hat build of OpenJDK 11u, and Red Hat build of OpenJDK 17u projects and includes the Shenandoah Garbage Collector from version 11 and later versions. Eclipse Temurin does not vary structurally from the upstream distribution of Red Hat build of OpenJDK. Eclipse Temurin shares the following similar capabilities as Red Hat build of OpenJDK: Multi-platform - Red Hat offers support of Eclipse Temurin on Microsoft Windows, RHEL and macOS, so that you can standardize on a single Java platform on numerous environments, such as desktop, data center, and hybrid cloud. Frequent releases - Eclipse Temurin delivers quarterly updates of JRE and JDK for the Red Hat build of OpenJDK 8, Red Hat build of OpenJDK 11, and Red Hat build of OpenJDK 17 distributions. These updates are available as RPM, MSI, archive files, and containers. Long-term support (LTS) - Red Hat supports the recently released Eclipse Temurin 8, Eclipse Temurin 11, and Eclipse Temurin 17. For more information about the support lifecycle, see Red Hat build of OpenJDK Life Cycle and Support Policy .

Commands:
Appendix A. Component Versions This appendix is a list of components and their versions in the Red Hat Enterprise Linux 6.2 release. Table A.1. Component Versions Component Version Kernel 2.6.32-202 QLogic qla2xxx driver 8.03.07.05.06.2-k QLogic qla2xxx firmware ql23xx-firmware-3.03.27-3.1 ql2100-firmware-1.19.38-3.1 ql2200-firmware-2.02.08-3.1 ql2400-firmware-5.06.01-1 ql2500-firmware-5.06.01-1 Emulex lpfc driver 8.3.5.45.2p iSCSI initiator utils 6.2.0.872-27 DM-Multipath 0.4.9-43 LVM 2.02.87-3 X Server 1.10.4-3

Commands:
5.365. xorg-x11-drv-qxl 5.365.1. RHSA-2013:0218 - Moderate: xorg-x11-drv-qxl security update An updated xorg-x11-drv-qxl 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 xorg-x11-drv-qxl package provides an X11 video driver for the QEMU QXL video accelerator. This driver makes it possible to use Red Hat Enterprise Linux 6 as a guest operating system under the KVM kernel module and the QEMU multi-platform emulator, using the SPICE protocol. Security Fix CVE-2013-0241 A flaw was found in the way the host's qemu-kvm qxl driver and the guest's X.Org qxl driver interacted when a SPICE connection terminated. A user able to initiate a SPICE connection to a guest could use this flaw to make the guest temporarily unavailable or, potentially (if the sysctl kernel.softlockup_panic variable was set to "1" in the guest), crash the guest. All users of xorg-x11-drv-qxl are advised to upgrade to this updated package, which contains a backported patch to correct this issue. All running X.Org server instances using the qxl driver must be restarted for this update to take effect.

Commands:
Chapter 10. Configuring the node port service range As a cluster administrator, you can expand the available node port range. If your cluster uses of a large number of node ports, you might need to increase the number of available ports. The default port range is 30000-32767 . You can never reduce the port range, even if you first expand it beyond the default range. 10.1. Prerequisites Your cluster infrastructure must allow access to the ports that you specify within the expanded range. For example, if you expand the node port range to 30000-32900 , the inclusive port range of 32768-32900 must be allowed by your firewall or packet filtering configuration. 10.2. Expanding the node port range You can expand the node port range for the cluster. Important You can expand the node port range into the protected port range, which is between 0 and 32767. However, after expansion, you cannot change the range. Attempting to change the range returns the following error: The Network "cluster" is invalid: spec.serviceNodePortRange: Invalid value: "30000-32767": new service node port range 30000-32767 does not completely cover the range 0-32767 . Before making changes, ensure that the new range you set is appropriate for your cluster. Prerequisites Install the OpenShift CLI ( oc ). Log in to the cluster with a user with cluster-admin privileges. Procedure To expand the node port range, enter the following command. Replace <port> with the largest port number in the new range. USD oc patch network.config.openshift.io cluster --type=merge -p \ '{ "spec": { "serviceNodePortRange": "30000-<port>" } }' Tip You can alternatively apply the following YAML to update the node port range: apiVersion: config.openshift.io/v1 kind: Network metadata: name: cluster spec: serviceNodePortRange: "30000-<port>" Example output network.config.openshift.io/cluster patched To confirm that the configuration is active, enter the following command. It can take several minutes for the update to apply. USD oc get configmaps -n openshift-kube-apiserver config \ -o jsonpath="{.data['config\.yaml']}" | \ grep -Eo '"service-node-port-range":["[[:digit:]]+-[[:digit:]]+"]' Example output "service-node-port-range":["30000-33000"] 10.3. Additional resources Configuring ingress cluster traffic using a NodePort Network [config.openshift.io/v1 ] Service [core/v1 ]

Commands:
oc patch network.config.openshift.io cluster --type=merge -p '{ "spec": { "serviceNodePortRange": "30000-<port>" } }'
apiVersion: config.openshift.io/v1 kind: Network metadata: name: cluster spec: serviceNodePortRange: "30000-<port>"
network.config.openshift.io/cluster patched
oc get configmaps -n openshift-kube-apiserver config -o jsonpath="{.data['config\.yaml']}" | grep -Eo '"service-node-port-range":["[[:digit:]]+-[[:digit:]]+"]'
"service-node-port-range":["30000-33000"]
3.2. Querying Example The following provides an example of how to set up and run a query in Red Hat JBoss Data Grid. In this example, the Person object has been annotated using the following: Example 3.4. Annotating the Person Object Assuming several of these Person objects have been stored in JBoss DataGrid, they can be searched using querying. The following code creates a SearchManager and QueryBuilder instance: Example 3.5. Creating the SearchManager and QueryBuilder The SearchManager and QueryBuilder are used to construct a Lucene query. The Lucene query is then passed to the SearchManager to obtain a CacheQuery instance: Example 3.6. Running the Query This CacheQuery instance contains the results of the query, and can be used to produce a list or it can be used for repeat queries. Report a bug

Commands:
@Indexed public class Person implements Serializable { @Field(store = Store.YES) private String name; @Field private String description; @Field(store = Store.YES) private int age; }
SearchManager manager = Search.getSearchManager(cache); QueryBuilder builder = manager.buildQueryBuilderForClass(Person.class) .get(); Query luceneQuery = builder.keyword() .onField("name") .matching("FirstName") .createQuery();
CacheQuery query = manager.getQuery(luceneQuery); List<Object> results = query.list(); for (Object result : results) { System.out.println("Found " + result); }
Chapter 4. The Go race detector Go Toolset includes the Go race detector, which is a tool of the Go standard library for finding race conditions. Note that the race detector has a significant runtime resource overhead. 4.1. Prerequisites Go Toolset is installed. For more information, see Installing Go Toolset . 4.2. Using the Go race detector Use the Go race detector to check your code for race conditions. Procedure To use the race detector, run: On Red Hat Enterprise Linux 8: Replace < output_file > with the name of your executable file and < go_main_package > with the name of the package you want to test. On Red Hat Enterprise Linux 9: Replace < output_file > with the name of your executable file and < go_main_package > with the name of the package you want to test. 4.3. Additional resources The official Go race detector documentation .

Commands:
go build -race -o < output_file > < go_main_package >
go build -race -o < output_file > < go_main_package >
1.5.2. Performance, Scalability, Moderate Price Multiple Linux client applications on a LAN can share the same SAN-based data as shown in Figure 1.13, "GFS and GNBD with a SAN" . SAN block storage is presented to network clients as block storage devices by GNBD servers. From the perspective of a client application, storage is accessed as if it were directly attached to the server in which the application is running. Stored data is actually on the SAN. Storage devices and data can be equally shared by network client applications. File locking and sharing functions are handled by GFS for each network client. Figure 1.13. GFS and GNBD with a SAN

Commands:
8.10. DSN-less Connection You can also connect to a Red Hat JBoss Data Virtualization VDB using ODBC without explicitly creating a DSN. However, in these scenarios your application needs a DSN-less connection string. You may want to do this if you are working with multiple computers and do not want to keep distributing the ODBC data source name. Here is the string for Linux, UNIX, and similar operating systems: Here is the string for Windows:

Commands:
ODBC;DRIVER={PostgreSQL};DATABASE=<vdb-name>;SERVER=<host-name>;PORT=<port>;Uid=<username>;Pwd=<password>;c4=0;c8=1;
ODBC;DRIVER={PostgreSQL Unicode};DATABASE=<vdb-name>;SERVER=<host-name>;PORT=<port>;Uid=<username>;Pwd=<password>;c4=0;c8=1;
Chapter 1. JFR creation options for Cryostat With Cryostat, you can create a JDK Flight Recorder (JFR) recording that monitors the performance of your JVM in your containerized application. Additionally, you can take a snapshot of an active JFR recording to capture any collected data, up to a specific point in time, for your target JVM application. Cryostat supports all of the following different ways to create JFR recordings: You can use the Cryostat web console to create JFR recordings manually for target JVMs that are using a JMX or agent HTTP connection. The Cryostat server can send on-demand requests over JMX or an agent HTTP connection to start JFR recordings dynamically based on automated rules. The Cryostat agent can start JFR recordings automatically at agent startup based on a given event template as part of the agent harvester feature. From Red Hat build of Cryostat 3.0 onward, the Cryostat agent can start JFR recordings dynamically based on MBean custom triggers and a given event template. The rest of this document describes how to create a JFR recording manually in the Cryostat web console. Additional resources Using automated rules on Cryostat Enabling dynamic JFR recordings based on MBean custom triggers

Commands:
Chapter 2. Architectures Red Hat Enterprise Linux 7 is available on the following architectures: [1] 64-bit AMD 64-bit Intel IBM POWER7+ (big endian) IBM POWER8 (big endian) [2] IBM POWER8 (little endian) [3] IBM POWER9 (little endian) [4] [5] IBM Z [4] [6] 64-bit ARM [4] The Red Hat Enterprise Linux 7.7 is distributed with the kernel version 3.10.0-1062, which provides support for the following architectures: 64-bit AMD 64-bit Intel IBM POWER7+ (big endian) IBM POWER8 (big endian) IBM POWER8 (little endian) IBM Z (kernel version 3.10) The following architectures remain fully supported and continue to receive z-stream security and bug fix updates in accordance with the Red Hat Enterprise Linux Life Cycle : IBM POWER9 (little endian) IBM Z - Structure A (kernel version 4.14) 64-bit ARM [1] Note that the Red Hat Enterprise Linux 7 installation is supported only on 64-bit hardware. Red Hat Enterprise Linux 7 is able to run 32-bit operating systems, including versions of Red Hat Enterprise Linux, as virtual machines. [2] Red Hat Enterprise Linux 7 POWER8 (big endian) are currently supported as KVM guests on Red Hat Enterprise Linux 7 POWER8 systems that run the KVM hypervisor, and on PowerVM. [3] Red Hat Enterprise Linux 7 POWER8 (little endian) is currently supported as a KVM guest on Red Hat Enterprise Linux 7 POWER8 systems that run the KVM hypervisor, and on PowerVM. In addition, Red Hat Enterprise Linux 7 POWER8 (little endian) guests are supported on Red Hat Enterprise Linux 7 POWER9 systems that run the KVM hypervisor in POWER8-compatibility mode on version 4.14 kernel using the kernel-alt package. [4] This architecture is supported with the kernel version 4.14, provided by the kernel-alt packages. For details, see the Red Hat Enterprise Linux 7.5 Release Notes . [5] Red Hat Enterprise Linux 7 POWER9 (little endian) is currently supported as a KVM guest on Red Hat Enterprise Linux 7 POWER9 systems that run the KVM hypervisor on version 4.14 kernel using the kernel-alt package, and on PowerVM. [6] Red Hat Enterprise Linux 7 for IBM Z (both the 3.10 kernel version and the 4.14 kernel version) is currently supported as a KVM guest on Red Hat Enterprise Linux 7 for IBM Z hosts that run the KVM hypervisor on version 4.14 kernel using the kernel-alt package.

Commands:
6.3.2.4. /etc/gshadow The /etc/gshadow file is readable only by the root user and contains an encrypted password for each group, as well as group membership and administrator information. Just as in the /etc/group file, each group's information is on a separate line. Each of these lines is a colon delimited list including the following information: Group name - The name of the group. Used by various utility programs as a human-readable identifier for the group. Encrypted password - The encrypted password for the group. If set, non-members of the group can join the group by typing the password for that group using the newgrp command. If the value of this field is ! , then no user is allowed to access the group using the newgrp command. A value of !! is treated the same as a value of ! - however, it also indicates that a password has never been set before. If the value is null, only group members can log into the group. Group administrators - Group members listed here (in a comma delimited list) can add or remove group members using the gpasswd command. Group members - Group members listed here (in a comma delimited list) are regular, non-administrative members of the group. Here is an example line from /etc/gshadow : This line shows that the general group has no password and does not allow non-members to join using the newgrp command. In addition, shelley is a group administrator, and juan and bob are regular, non-administrative members. Since editing these files manually raises the potential for syntax errors, it is recommended that the applications provided with Red Hat Enterprise Linux for this purpose be used instead. The section reviews the primary tools for performing these tasks.

Commands:
general:!!:shelley:juan,bob
A.9. Evaluating Virtual Machine Custom Properties in a VDSM Hook Each key set in the Custom Properties field for a virtual machine is appended as an environment variable when calling hook scripts. Although the regular expressions used to validate the Custom Properties field provide some protection you should ensure that your scripts also validate that the inputs provided match their expectations. Example A.3. Evaluating Custom Properties This short Python example checks for the existence of the custom property key1 . If the custom property is set then the value is printed to standard error. If the custom property is not set then no action is taken.

Commands:
#!/usr/bin/python import os import sys if os.environ.has_key('key1'): sys.stderr.write('key1 value was : %s\n' % os.environ['key1']) else: sys.exit(0)
7.4.2. Core X Font System For compatibility, Red Hat Enterprise Linux provides the core X font subsystem, which uses the X Font Server ( xfs ) to provide fonts to X client applications. The X server looks for a font server specified in the FontPath directive within the Files section of the /etc/X11/xorg.conf configuration file. Refer to Section 7.3.1.4, " Files " for more information about the FontPath entry. The X server connects to the xfs server on a specified port to acquire font information. For this reason, the xfs service must be running for X to start. For more about configuring services for a particular runlevel, refer to the chapter titled Controlling Access to Services in the System Administrators Guide . 7.4.2.1. xfs Configuration The /etc/rc.d/init.d/xfs script starts the xfs server. Several options can be configured within its configuration file, /etc/X11/fs/config . The following lists common options: alternate-servers - Specifies a list of alternate font servers to be used if this font server is not available. A comma must seperate each font server in a list. catalogue - Specifies an ordered list of font paths to use. A comma must seperate each font path in a list. Use the string :unscaled immediately after the font path to make the unscaled fonts in that path load first. Then specify the entire path again, so that other scaled fonts are also loaded. client-limit - Specifies the maximum number of clients the font server services. The default is 10 . clone-self - Allows the font server to clone a new version of itself when the client-limit is hit. By default, this option is on . default-point-size - Specifies the default point size for any font that does not specify this value. The value for this option is set in decipoints. The default of 120 corresponds to a 12 point font. default-resolutions - Specifies a list of resolutions supported by the X server. Each resolution in the list must be separated by a comma. deferglyphs - Specifies whether to defer loading glyphs (the graphic used to visually represent a font). To disable this feature use none , to enable this feature for all fonts use all , or to turn this this feature on only for 16-bit fonts use 16 . error-file - Specifies the path and file name of a location where xfs errors are logged. no-listen - Prevents xfs from listening to particular protocols. By default, this option is set to tcp to prevent xfs from listening on TCP ports for security reasons. Note If using xfs to serve fonts over the network, remove this line. port - Specifies the TCP port that xfs listens on if no-listen does not exist or is commented out. use-syslog - Specifies whether to use the system error log.

Commands: