mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 4. User Authentication User authentication enables you to verify the identity of users by adding usernames and assigning them to security roles. In AMQ Broker 7, this process is similar to AMQ 6. However, there are some differences in terminology, configuration file locations, and configuration syntax. Once you understand the differences, there are several methods you can use to configure user access to your broker instance. 4.1. User Authentication Changes In both AMQ Broker 7 and AMQ 6, authentication is provided by pluggable login modules based on the Java Authentication and Authorization Service (JAAS). However, groups in AMQ 6 are now called roles in AMQ Broker 7. In addition, the names and locations of the login modules have changed in AMQ Broker 7. Login Module Location in AMQ 6 Location in AMQ Broker 7 Users etc/users.properties BROKER_INSTANCE_DIR /etc/artemis-users.properties Roles (groups) etc/groups.properties BROKER_INSTANCE_DIR /etc/artemis-roles.properties The syntax for adding users and roles is also different. In AMQ 6 Non-privileged users could be added and assigned a password and security role in the users.properties file: In AMQ Broker 7 Users and roles are assigned in separate login modules. You add users in the artemis-users.properties file: You assign users to a security role in the artemis-roles.properties file: 4.2. How User Authentication is Configured You can access the AMQ 7 broker instance using the default username and password that you created when you created the broker instance. To enable additional users to access the broker instance, you can configure user authentication for the broker using any of the following methods: Authentication Method Description Guest Authentication Enables anonymous access. In this configuration, any user who connects without credentials or with the wrong credentials will be authenticated automatically and assigned a specific user and role. For more information, see Configuring guest access in Configuring AMQ Broker . Basic User and Password Authentication For each user, you must define a username and password and assign a security role. Users can only access the broker instance using these credentials. For more information, see Configuring user and password authentication based on properties files in Configuring AMQ Broker . Certificate-Based Authentication Users are authenticated using SSL certificates. For more information, see Configuring certificate-based authentication in Configuring AMQ Broker . LDAP Authentication Users are authenticated and authorized by checking the credentials against user data stored in a central X.500 directory server. For more information, see Using LDAP for authentication and authorization in Configuring AMQ Broker .

Commands:
USER = PASSWORD , ROLE
USER = PASSWORD
ROLE = USER
Chapter 3. Red Hat build of OpenJDK features The latest Red Hat build of OpenJDK 11 release might include new features. Additionally, the latest release might enhance, deprecate, or remove features that originated from Red Hat build of OpenJDK 11 releases. Note For all the other changes and security fixes, see OpenJDK 11.0.18 Released . Red Hat build of OpenJDK new features and enhancements Review the following release notes to understand new features and feature enhancements that are included with the Red Hat build of OpenJDK 11.0.18 release: Enhanced BMP bounds By default, Red Hat build of OpenJDK 11.0.18 disables loading a linked International Color Consortium (ICC) profile in a BMP image. You can enable this functionality by setting the new sun.imageio.bmp.enabledLinkedProfiles property to true . This property replaces the old sun.imageio.plugins.bmp.disableLinkedProfiles property See JDK-8295687 (JDK Bug System) . Improved banking of sounds Previously, the SoundbankReader implementation, com.sun.media.sound.JARSoundbankReader , downloaded a JAR soundbank from a URL. For Red Hat build of OpenJDK 11.0.18, this behavior is now disabled by default. To re-enable the behavior, set the new system property jdk.sound.jarsoundbank to true . See JDK-8293742 (JDK Bug System) . Enhanced Datagram Transport Layer Security (DTLS) performance Red Hat build of OpenJDK now exchanges DTLS cookies for all new and resumed handshake communications. To re-enable the release behavior, set the new system property jdk.tls.enableDtlsResumeCookie to false . See JDK-8287411 (JDK Bug System) . SunMSCAPI provider supports new Microsoft Windows keystore types The SunMSCAPI provider supports the following Microsoft Windows keystore types where you must append your local namespace to Windows- : Windows-MY-LOCALMACHINE Windows-ROOT-LOCALMACHINE Windows-MY-CURRENTUSER Windows-ROOT-CURRENTUSER By specifying any of these types, you can provide access to your local computer's location for the Microsoft Windows keystore. Thereby providing the keystore access to certificates that are stored on your local system. See JDK-6782021 (JDK Bug System). Added note for LoginModule implementation The Red Hat build of OpenJDK 9 release changed the Set implementation, which holds principals and credentials, so that the implementation can reject null values. Any attempts to call add(null) , contains(null) , or remove(null) would throw a NullPointerException message. The Red Hat build of OpenJDK 9 release did not update the logout() method in the LoginModule implementation to check for null values. These values could occur because of a failed login attempt, which can cause a logout() call to throw a NullPointerException message. The Red Hat build of OpenJDK 11.0.18 release updates the LoginModule implementations to check for null values. Additionally, the release adds an implementation note to the specification that states the change also applies to third-party modules. The note advises developers of third-party modules to verify that a logout() method does not throw a NullPointerException message. See JDK-8015081 (JDK Bug System). See JDK-8282730 (JDK Bug System).

Commands:
Chapter 1. Go Toolset Go Toolset is a Red Hat offering for developers on Red Hat Enterprise Linux (RHEL). It provides the Go programming language tools and libraries. Note that Go is alternatively known as golang. Go Toolset is available as a module for Red Hat Enterprise Linux 8. Go Toolset is available as packages for Red Hat Enterprise Linux 9. 1.1. Go Toolset components The following components are available as a part of Go Toolset: Name Version Description golang RHEL 8 - 1.21.0, RHEL 9 - 1.21.0 A Go compiler. delve RHEL 8 - 1.21.0, RHEL 9 - 1.21.0 A Go debugger. 1.2. Go Toolset compatibility Go Toolset is available for Red Hat Enterprise Linux 8 and Red Hat Enterprise Linux 9 on the following architectures: AMD and Intel 64-bit 64-bit ARM IBM Power Systems, Little Endian 64-bit IBM Z 1.3. Installing Go Toolset Complete the following steps to install Go Toolset, including all dependent packages. Prerequisites All available Red Hat Enterprise Linux updates are installed. Procedure On Red Hat Enterprise Linux 8, install the go-toolset module by running: On Red Hat Enterprise Linux 9, install the go-toolset package by running: 1.4. Installing Go documentation You can install documentation for the Go programming language on your local system. Prerequisites Go Toolset is installed. For more information, see Installing Go Toolset . Procedure To install the golang-docs package, run the following command: On Red Hat Enterprise Linux 8: You can find the documentation under the following path: /usr/lib/golang/doc/go_spec.html . On Red Hat Enterprise Linux 9: You can find the documentation under the following path: /usr/lib/golang/doc/go_spec.html . 1.5. Additional resources For more information on the Go programming language, tools, and libraries, see the official Go documentation .

Commands:
yum module install go-toolset
dnf install go-toolset
yum install golang-docs
dnf install golang-docs
1.3. LVM Architecture Overview Note LVM2 is backwards compatible with LVM1, with the exception of snapshot and cluster support. You can convert a volume group from LVM1 format to LVM2 format with the vgconvert command. For information on converting LVM metadata format, see the vgconvert (8) man page. The underlying physical storage unit of an LVM logical volume is a block device such as a partition or whole disk. This device is initialized as an LVM physical volume (PV). To create an LVM logical volume, the physical volumes are combined into a volume group (VG). This creates a pool of disk space out of which LVM logical volumes (LVs) can be allocated. This process is analogous to the way in which disks are divided into partitions. A logical volume is used by file systems and applications (such as databases). Figure 1.1, "LVM Logical Volume Components" shows the components of a simple LVM logical volume: Figure 1.1. LVM Logical Volume Components For detailed information on the components of an LVM logical volume, see Chapter 2, LVM Components .

Commands:
Part II. Manually installing Red Hat Enterprise Linux Setting up a machine for installing Red Hat Enterprise Linux (RHEL) involves several key steps, from booting the installation media to configuring system options. Once the installation ISO is booted, there are opportunities to modify boot settings and monitor installation processes through various consoles and logs. Customizing the system during installation ensures that it is tailored to specific needs, and the initial setup process finalizes the configuration for first-time use.

Commands:
B.4. Guest starting fails with error: monitor socket did not show up Symptom The guest virtual machine (or domain) starting fails with this error (or similar): Investigation This error message shows: libvirt is working; The QEMU process failed to start up; and libvirt quits when trying to connect QEMU or the QEMU agent monitor socket. To understand the error details, examine the guest log: Solution The guest log contains the details needed to fix the error. If a host is shut down while the guest is still running a libvirt version prior to 0.9.5, the libvirt-guest's init script attempts to perform a managed save of the guest. If the managed save was incomplete (for example, due to loss of power before the managed save image was flushed to disk), the save image is corrupted and will not be loaded by QEMU . The older version of libvirt does not recognize the corruption, making the problem perpetual. In this case, the guest log will show an attempt to use -incoming as one of its arguments, meaning that libvirt is trying to start QEMU by migrating in the saved state file. This problem can be fixed by running virsh managedsave-remove name_of_guest to remove the corrupted managed save image. Newer versions of libvirt take steps to avoid the corruption in the first place, as well as adding virsh start --force-boot name_of_guest to bypass any managed save image.

Commands:
virsh -c qemu:///system create name_of_guest .xml error: Failed to create domain from name_of_guest .xml error: monitor socket did not show up.: Connection refused
cat /var/log/libvirt/qemu/ name_of_guest .log LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-kvm -S -M pc -enable-kvm -m 768 -smp 1,sockets=1,cores=1,threads=1 -name name_of_guest -uuid ebfaadbe-e908-ba92-fdb8-3fa2db557a42 -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/ name_of_guest .monitor,server,nowait -mon chardev=monitor,mode=readline -no-reboot -boot c -kernel /var/lib/libvirt/boot/vmlinuz -initrd /var/lib/libvirt/boot/initrd.img -append method=http://www.example.com/pub/product/release/version/x86_64/os/ -drive file=/var/lib/libvirt/images/ name_of_guest .img,if=none,id=drive-ide0-0-0,boot=on -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -device virtio-net-pci,vlan=0,id=net0,mac=52:40:00:f4:f1:0a,bus=pci.0,addr=0x4 -net tap,fd=42,vlan=0,name=hostnet0 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -vnc 127.0.0.1:0 -k en-gb -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0, addr=0x3 char device redirected to /dev/pts/1 qemu: could not load kernel '/var/lib/libvirt/boot/vmlinuz': Permission denied
Chapter 34. Firstboot Important Firstboot is only available on systems after a graphical installation or after a kickstart installation where a desktop and the X window system were installed and graphical login was enabled. If you performed a text-mode installation or a kickstart installation that did not include a desktop and the X window system, the firstboot configuration tool does not appear. Firstboot launches the first time that you start a new Red Hat Enterprise Linux system. Use firstboot to configure the system for use before you log in. Figure 34.1. Firstboot welcome screen Click Forward to start firstboot . 34.1. License Information This screen displays the overall licensing terms for Red Hat Enterprise Linux. Figure 34.2. Firstboot license screen If you agree to the terms of the license, select Yes, I agree to the License Agreement and click Forward .

Commands:
9.6. Ad-Hoc REST Services Apart from the explicitly defined procedure based rest services, the generated jax-rs war file will also implicitly include a special rest based service under URI "/query" that can take any XML or JSON producing SQL as parameter and expose the results of that query as result of the service. This service is defined with "POST", accepting a Form Parameter named "sql". For example, after you deploy the VDB defined in above example, you can issue a HTTP POST call as A sample HTTP Request from Java can be made like below:

Commands:
http://localhost:8080/sample_1/view/query sql=SELECT XMLELEMENT(NAME "rows",XMLAGG(XMLELEMENT(NAME "row", XMLFOREST(e1, e2)))) AS xml_out FROM PM1.G1
public static String httpCall(String url, String method, String params) throws Exception { StringBuffer buff = new StringBuffer(); HttpURLConnection connection = (HttpURLConnection) new URL(url).openConnection(); connection.setRequestMethod(method); connection.setDoOutput(true); if (method.equalsIgnoreCase("post")) { OutputStreamWriter wr = new OutputStreamWriter(connection.getOutputStream()); wr.write(params); wr.flush(); } BufferedReader serverResponse = new BufferedReader(new InputStreamReader(connection.getInputStream())); String line; while ((line = serverResponse.readLine()) != null) { buff.append(line); } return buff.toString(); } public static void main(String[] args) throws Exception { String params = URLEncoder.encode("sql", "UTF-8") + "=" + URLEncoder.encode("SELECT XMLELEMENT(NAME "rows",XMLAGG(XMLELEMENT(NAME "row", XMLFOREST(e1, e2)))) AS xml_out FROM PM1.G1", "UTF-8"); httpCall("http://localhost:8080/sample_1/view/query", "POST", params); }
Chapter 133. KafkaConnectorStatus schema reference Used in: KafkaConnector Property Description conditions List of status conditions. Condition array observedGeneration The generation of the CRD that was last reconciled by the operator. integer autoRestart The auto restart status. AutoRestartStatus connectorStatus The connector status, as reported by the Kafka Connect REST API. map tasksMax The maximum number of tasks for the Kafka Connector. integer topics The list of topics used by the Kafka Connector. string array

Commands:
6.4. Backing Up and Restoring the Cluster Database The Cluster Configuration Tool automatically retains backup copies of the three most recently used configuration files (besides the currently used configuration file). Retaining the backup copies is useful if the cluster does not function correctly because of misconfiguration and you need to return to a working configuration. Each time you save a configuration file, the Cluster Configuration Tool saves backup copies of the three most recently used configuration files as /etc/cluster/cluster.conf.bak.1 , /etc/cluster/cluster.conf.bak.2 , and /etc/cluster/cluster.conf.bak.3 . The backup file /etc/cluster/cluster.conf.bak.1 is the newest backup, /etc/cluster/cluster.conf.bak.2 is the second newest backup, and /etc/cluster/cluster.conf.bak.3 is the third newest backup. If a cluster member becomes inoperable because of misconfiguration, restore the configuration file according to the following steps: At the Cluster Configuration Tool tab of the Red Hat Cluster Suite management GUI, click File => Open . Clicking File => Open causes the system-config-cluster dialog box to be displayed. At the the system-config-cluster dialog box, select a backup file (for example, /etc/cluster/cluster.conf.bak.1 ). Verify the file selection in the Selection box and click OK . Click File => Save As . Clicking File => Save As causes the system-config-cluster dialog box to be displayed. At the the system-config-cluster dialog box, select /etc/cluster/cluster.conf and click OK . (Verify the file selection in the Selection box.) Clicking OK causes an Information dialog box to be displayed. At that dialog box, click OK . Propagate the updated configuration file throughout the cluster by clicking Send to Cluster . Note The Cluster Configuration Tool does not display the Send to Cluster button if the cluster is new and has not been started yet, or if the node from which you are running the Cluster Configuration Tool is not a member of the cluster. If the Send to Cluster button is not displayed, you can still use the Cluster Configuration Tool ; however, you cannot propagate the configuration. You can still save the configuration file. For information about using the Cluster Configuration Tool for a new cluster configuration, refer to Chapter 5, Configuring Red Hat Cluster With system-config-cluster . Clicking Send to Cluster causes a Warning dialog box to be displayed. Click Yes to propagate the configuration. Click the Cluster Management tab and verify that the changes have been propagated to the cluster members.

Commands:
19.5. chkconfig The chkconfig command can also be used to activate and deactivate services. The chkconfig --list command displays a list of system services and whether they are started ( on ) or stopped ( off ) in runlevels 0-6. At the end of the list is a section for the services managed by xinetd . If the chkconfig --list command is used to query a service managed by xinetd , it displays whether the xinetd service is enabled ( on ) or disabled ( off ). For example, the command chkconfig --list finger returns the following output: As shown, finger is enabled as an xinetd service. If xinetd is running, finger is enabled. If you use chkconfig --list to query a service in /etc/rc.d , service's settings for each runlevel are displayed. For example, the command chkconfig --list httpd returns the following output: chkconfig can also be used to configure a service to be started (or not) in a specific runlevel. For example, to turn nscd off in runlevels 3, 4, and 5, use the following command: Warning Services managed by xinetd are immediately affected by chkconfig . For example, if xinetd is running, finger is disabled, and the command chkconfig finger on is executed, finger is immediately enabled without having to restart xinetd manually. Changes for other services do not take effect immediately after using chkconfig . You must stop or start the individual service with the command service daemon stop . In the example, replace daemon with the name of the service you want to stop; for example, httpd . Replace stop with start or restart to start or restart the service.

Commands:
finger on
httpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
chkconfig --level 345 nscd off
A.3. Red Hat JBoss Data Virtualization Functions and Order of Precedence There are three classes of functions in Red Hat JBoss Data Virtualization: System functions (effectively scoped to SYS) and are known at design time. Pushdown functions (also effectively scoped to SYS) and are supplied by translators. UDFs which are schema scoped (except for legacy function models) and are defined via metadata. When resolved, system functions take preference - no schema qualification is necessary. But you can introduce for example a concat UDF and call it as schema.concat(...). Pushdown functions then take preference. Note It possible that two translators will declare the same function with the same root name, but Red Hat JBoss Data Virtualization currently does not treat this as an ambiguity. The primary reason is that in Teiid Designer, pushdown functions must be redeclared in metadata to be used (either with the legacy function model or with source functions). So it is assumed that the first matching definition is correct. Schema scoped functions are last in preference and require qualification if there are conflicting names.

Commands:
27.6. The floppy Group If, for whatever reason, console access is not appropriate for you and your non-root users are required access to your system's diskette drive, this can be done using the floppy group. Add the user(s) to the floppy group using the tool of your choice. For example, the gpasswd command can be used to add user fred to the floppy group: Now, user fred is able to access the system's diskette drive from the console.

Commands:
gpasswd -a fred floppy
4.2. SELinux and Mandatory Access Control (MAC) Security-Enhanced Linux (SELinux) is an implementation of MAC in the Linux kernel, checking for allowed operations after standard discretionary access controls (DAC) are checked. SELinux can enforce a user-customizable security policy on running processes and their actions, including attempts to access file system objects. Enabled by default in Red Hat Enterprise Linux, SELinux limits the scope of potential damage that can result from the exploitation of vulnerabilities in applications and system services, such as the hypervisor. sVirt integrates with libvirt, a virtualization management abstraction layer, to provide a MAC framework for virtual machines. This architecture allows all virtualization platforms supported by libvirt and all MAC implementations supported by sVirt to interoperate.

Commands:
Chapter 139. KafkaMirrorMaker2Spec schema reference Used in: KafkaMirrorMaker2 Property Property type Description version string The Kafka Connect version. Defaults to the latest version. Consult the user documentation to understand the process required to upgrade or downgrade the version. replicas integer The number of pods in the Kafka Connect group. Defaults to 3 . image string The container image used for Kafka Connect pods. If no image name is explicitly specified, it is determined based on the spec.version configuration. The image names are specifically mapped to corresponding versions in the Cluster Operator configuration. connectCluster string The cluster alias used for Kafka Connect. The value must match the alias of the target Kafka cluster as specified in the spec.clusters configuration. The target Kafka cluster is used by the underlying Kafka Connect framework for its internal topics. clusters KafkaMirrorMaker2ClusterSpec array Kafka clusters for mirroring. mirrors KafkaMirrorMaker2MirrorSpec array Configuration of the MirrorMaker 2 connectors. resources ResourceRequirements The maximum limits for CPU and memory resources and the requested initial resources. livenessProbe Probe Pod liveness checking. readinessProbe Probe Pod readiness checking. jvmOptions JvmOptions JVM Options for pods. jmxOptions KafkaJmxOptions JMX Options. logging InlineLogging , ExternalLogging Logging configuration for Kafka Connect. clientRackInitImage string The image of the init container used for initializing the client.rack . rack Rack Configuration of the node label which will be used as the client.rack consumer configuration. tracing JaegerTracing , OpenTelemetryTracing The configuration of tracing in Kafka Connect. template KafkaConnectTemplate Template for Kafka Connect and Kafka Mirror Maker 2 resources. The template allows users to specify how the Pods , Service , and other services are generated. externalConfiguration ExternalConfiguration Pass data from Secrets or ConfigMaps to the Kafka Connect pods and use them to configure connectors. metricsConfig JmxPrometheusExporterMetrics Metrics configuration.

Commands: