mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Using schema properties to configure custom resources Custom resources offer a flexible way to manage and fine-tune the operation of AMQ Streams components using configuration properties. This reference guide describes common configuration properties that apply to multiple custom resources, as well as the configuration properties available for each custom resource schema available with AMQ Streams. Where appropriate, expanded descriptions of properties and examples of how they are configured are provided. The properties defined for each schema provide a structured and organized way to specify configuration for the custom resources. Whether it's adjusting resource allocation or specifying access controls, the properties in the schemas allow for a granular level of configuration. For example, you can use the properties of the KafkaClusterSpec schema to specify the type of storage for a Kafka cluster or add listeners that provide secure access to Kafka brokers. Some property options within a schema may be constrained, as indicated in the property descriptions. These constraints define specific options or limitations on the values that can be assigned to those properties. Constraints ensure that the custom resources are configured with valid and appropriate values.

Commands:
Chapter 4. Performance impact of alt-java The alt-java binary contains the SSB mitigation, so the SSB mitigation performance impact no longer exists on java . Note Using alt-java might significantly reduce the performance of Java programs. You can find detailed information of some Java performance issues that might exist with using alt-java by selecting any of the Red Hat Bugzilla links listed in the Additional resources section. Additional resources (java-11-openjdk) Seccomp related performance regression in RHEL8 . (java-1.8.0-openjdk) Seccomp related performance regression in RHEL8 . CVE-2018-3639 Detail . CVE-2018-3639 hw: cpu: speculative store bypass . CVE-2018-3639 java-1.8.0-openjdk: hw: cpu: speculative store bypass (rhel-7.6) Revised on 2024-05-03 15:35:17 UTC

Commands:
14.10. Configuring Certificate Transparency Certificate System provides a basic version of Certificate Transparency (CT) V1 support (rfc 6962). It has the capability of issuing certificates with embedded Signed Certificate Time stamps (SCTs) from any trusted log where each deployment site choses to have its root CA cert included. You can also configure the system to support multiple CT logs. A minimum of one trusted CT log is required for this feature to work. Important It is the responsibility of the deployment site to establish its trust relationship with a trusted CT log server. To configure Certificate Transparency, edit the CA's CS.cfg file located in the /var/lib/pki/ instance name /ca/conf/CS.cfg directory. For more information on how to test your Certificate Transparency setup, see the Testing Certificate Transparency section in the Red Hat Certificate System Planning, Installation, and Deployment Guide . 14.10.1. ca.certTransparency.mode The ca.certTransparency.mode specifies one of three Certificate Transparency modes: disabled : issued certs will not carry the SCT extension enabled : issued certs will carry the SCT extension perProfile : certs enrolled through those profiles that contain the following policyset will carry the SCT extension: SignedCertificateTimestampListExtDefaultImpl The default value is disabled . 14.10.2. ca.certTransparency.log.num ca.certTransparency.log.num specifies the total number of CT logs defined in the configuration. Note Not all CT log entries that are defined are considered active; see ca.certTransparency.log.<id>.enable in Section 14.10.3, "ca.certTransparency.log.<id>.*" . 14.10.3. ca.certTransparency.log.<id>.* ca.certTransparency.log.<id>.* specifies information pertaining to the log <id>, where <id> is a unique id you assign to the CT log server to differentiate it from other CT logs. The parameter names follow each ca.certTransparency.log.<id>. and belong to the <id>: ca.certTransparency.log.<id>.enable specifies whether the <id> CT log is enabled (true) or disabled (false). ca.certTransparency.log.<id>.pubKey contains the base64 encoding of the CT log's public key. ca.certTransparency.log.<id>.url contains the base64 encoding of the CT log url. ca.certTransparency.log.<id>.version specifies the CT version number that the CT supports (as well as the CT log server); it currently only supports version 1.

Commands:
15.3.5. Installing via FTP, HTTP, or HTTPS Important When you provide a URL to an installation source, you must explicitly specify http:// or https:// or ftp:// as the protocol. The URL dialog applies only if you are installing from a FTP, HTTP, or HTTPS server (if you selected URL in the Installation Method dialog). This dialog prompts you for information about the FTP, HTTP, or HTTPS server from which you are installing Red Hat Enterprise Linux. If you used the repo=ftp or repo=http boot options, you already specified a server and path. Enter the name or IP address of the FTP, HTTP, or HTTPS site from which you are installing, and the name of the directory that contains the /images directory for your architecture. For example: /mirrors/redhat/rhel-6.9/Server/ppc64/ To install via a secure HTTPS connection, specify https:// as the protocol. Specify the address of a proxy server, and if necessary, provide a port number, username, and password. If everything was specified properly, a message box appears indicating that files are being retrieved from the server. If your FTP, HTTP, or HTTPS server requires user authentication, specify user and password as part of the URL as follows: {ftp|http|https}://<user>:<password>@<hostname>[:<port>]/<directory>/ For example: http://install:rhel6.9pw@name.example.com/mirrors/redhat/rhel-6.9/Server/ppc64/ Figure 15.11. URL Setup Dialog Proceed with Chapter 16, Installing Using Anaconda .

Commands:
20.32. Deleting a Storage Volume's Contents The virsh vol-wipe vol pool command wipes a volume, to ensure data previously on the volume is not accessible to future reads. The command requires a --pool pool which is the name or UUID of the storage pool the volume is in as well as pool which is the name the name or key or path of the volume to wipe. Note that it is possible to choose different wiping algorithms instead of re-writing volume with zeroes, using the argument --algorithm and using one of the following supported algorithm types: zero - 1-pass all zeroes nnsa - 4-pass NNSA Policy Letter NAP-14.1-C (XVI-8) for sanitizing removable and non-removable hard disks: random x2, 0x00, verify. dod - 4-pass DoD 5220.22-M section 8-306 procedure for sanitizing removable and non-removable rigid disks: random, 0x00, 0xff, verify. bsi - 9-pass method recommended by the German Center of Security in Information Technologies (http://www.bsi.bund.de): 0xff, 0xfe, 0xfd, 0xfb, 0xf7, 0xef, 0xdf, 0xbf, 0x7f. gutmann - The canonical 35-pass sequence described in Gutmann's paper. schneier - 7-pass method described by Bruce Schneier in "Applied Cryptography" (1996): 0x00, 0xff, random x5. pfitzner7 - Roy Pfitzner's 7-random-pass method: random x7 pfitzner33 - Roy Pfitzner's 33-random-pass method: random x33. random - 1-pass pattern: random.s Note The availability of algorithms may be limited by the version of the "scrub" binary installed on the host. Example 20.92. How to delete a storage volume's contents (How to wipe the storage volume) The following example wipes the contents of the storage volume new-vol , which has the storage pool vdisk associated with it:

Commands:
virsh vol-wipe new-vol vdisk vol new-vol wiped
Preface The Red Hat Ansible Certified Content Collection for Red Hat JBoss Web Server is a prepackaged Ansible content collection that Red Hat provides. You can use the Red Hat Ansible Certified Content Collection to automate the installation and configuration of the Red Hat JBoss Web Server product. You can also add customized tasks to your playbook to automate the deployment of JBoss Web Server applications either at the same time as the automated product installation or later. For general information about the Red Hat Ansible Certified Content Collection, see the Ansible Collection - redhat.jws page in Ansible automation hub . The Ansible Collection - redhat.jws page includes information about the roles that the collection contains. You can click the name of a role to view details about the purpose of this role, any requirements or dependencies, and the list of variables and default settings that the role uses to complete automation tasks. For more information about Ansible concepts or the benefits of using Ansible, see Ansible concepts and benefits . The Red Hat Ansible Certified Content Collection for Red Hat JBoss Web Server is released with Production Support . If you have any issues or questions related to this collection, please contact support at Red Hat Customer Experience & Engagement . Note The rest of this document refers to the Red Hat Ansible Certified Content Collection for Red Hat JBoss Web Server as the JBoss Web Server collection .

Commands:
Chapter 4. Directory Structure 4.1. Installation Locations If you are installing from a zip file then by default there will be an install root directory of rhbk-26.0.10 , which can be created anywhere you choose on your filesystem. /opt/keycloak is the root install location for the server in all containerized usage shown for Red Hat build of Keycloak. Note In the rest of the documentation, relative paths are understood to be relative to the install root - for example, conf/file.xml means <install root>/conf/file.xml 4.2. Directory Structure Under the Red Hat build of Keycloak install root there exists a number of folders: bin/ - contains all the shell scripts for the server, including kc.sh|bat , kcadm.sh|bat , and kcreg.sh|bat client/ - used internally conf/ - directory used for configuration files, including keycloak.conf - see Configuring Red Hat build of Keycloak . Many options for specifying a configuration file expect paths relative to this directory. truststores/ - default path used by the truststore-paths option - see Configuring trusted certificates data/ - directory for the server to store runtime information, such as transaction logs logs/ - default directory for file logging - see Configuring logging lib/ - used internally providers/ - directory for user provided dependencies - see Configuring providers for extending the server and Configuring the database for an example of add a JDBC driver. themes/ - directory for customizations to the Admin Console - see Developing Themes

Commands:
3.2. Introduction: Basic Networking Terms Red Hat Virtualization provides networking functionality between virtual machines, virtualization hosts, and wider networks using: A Network Interface Controller (NIC) A Bridge A Bond A Virtual NIC A Virtual LAN (VLAN) NICs, bridges, and VNICs allow for network communication between hosts, virtual machines, local area networks, and the Internet. Bonds and VLANs are optionally implemented to enhance security, fault tolerance, and network capacity.

Commands:
Chapter 16. Using the Red Hat Marketplace The Red Hat Marketplace is an open cloud marketplace that makes it easy to discover and access certified software for container-based environments that run on public clouds and on-premises. 16.1. Red Hat Marketplace features Cluster administrators can use the Red Hat Marketplace to manage software on Red Hat OpenShift Service on AWS, give developers self-service access to deploy application instances, and correlate application usage against a quota. 16.1.1. Connect Red Hat OpenShift Service on AWS clusters to the Marketplace Cluster administrators can install a common set of applications on Red Hat OpenShift Service on AWS clusters that connect to the Marketplace. They can also use the Marketplace to track cluster usage against subscriptions or quotas. Users that they add by using the Marketplace have their product usage tracked and billed to their organization. During the cluster connection process , a Marketplace Operator is installed that updates the image registry secret, manages the catalog, and reports application usage. 16.1.2. Install applications Cluster administrators can install Marketplace applications from within OperatorHub in Red Hat OpenShift Service on AWS, or from the Marketplace web application . You can access installed applications from the web console by clicking Operators > Installed Operators . 16.1.3. Deploy applications from different perspectives You can deploy Marketplace applications from the web console's Administrator and Developer perspectives. The Developer perspective Developers can access newly installed capabilities by using the Developer perspective. For example, after a database Operator is installed, a developer can create an instance from the catalog within their project. Database usage is aggregated and reported to the cluster administrator. This perspective does not include Operator installation and application usage tracking. The Administrator perspective Cluster administrators can access Operator installation and application usage information from the Administrator perspective. They can also launch application instances by browsing custom resource definitions (CRDs) in the Installed Operators list.

Commands:
14.3. Booting from the Network Using a yaboot Installation Server To boot with a yaboot installation server, you need a properly configured server, and a network interface in your computer that can support an installation server. For information on how to configure an installation server, refer to Chapter 30, Setting Up an Installation Server . Configure the computer to boot from the network interface by selecting Select Boot Options in the SMS menu, then Select Boot/Install Device . Finally, select your network device from the list of available devices. Once you properly configure booting from an installation server, the computer can boot the Red Hat Enterprise Linux installation system without any other media. To boot a computer from a yaboot installation server: Ensure that the network cable is attached. The link indicator light on the network socket should be lit, even if the computer is not switched on. Switch on the computer. A menu screen appears. Press the number key that corresponds to the desired option. If your PC does not boot from the network installation server, ensure that the SMS is configured to boot first from the correct network interface. Refer to your hardware documentation for more information.

Commands:
7.13. b43-openfwwf 7.13.1. RHBA-2015:1422 - b43-openfwwf bug fix update An updated b43-openfwwf package that fixes one bug is now available for Red Hat Enterprise Linux 6. The b43-openfwwf package contains the open firmware for certain Broadcom 43xx series wireless LAN (WLAN) chips. The currently supported models are 4306, 4311 (rev1), 4318, and 4320. Bug Fix BZ# 1015671 Previously, the b43-openfwwf firmware was incorrectly recognized as the closed-source b43 firmware from Broadcom, which caused the b43 driver to expect the behavior of the Broadcom b43 firmware. This update corrects the location where the firmware images are installed, and as a result, the b43-openfwwf firmware is recognized correctly. Users of b43-openfwwf are advised to upgrade to this updated package, which fixes this bug.

Commands:
2.4. perf The perf tool uses hardware performance counters and kernel tracepoints to track the impact of other commands and applications on your system. Various perf subcommands display and record statistics for common performance events, and analyze and report on the data recorded. For detailed information about perf and its subcommands, see Section A.6, "perf" . Alternatively, more information is available in the Red Hat Enterprise Linux 7 Developer Guide .

Commands:
E.3.4. /proc/driver/ This directory contains information for specific drivers in use by the kernel. A common file found here is rtc which provides output from the driver for the system's Real Time Clock (RTC) , the device that keeps the time while the system is switched off. Sample output from /proc/driver/rtc looks like the following: For more information about the RTC, see the following installed documentation: /usr/share/doc/kernel-doc- <kernel_version> /Documentation/rtc.txt .

Commands:
rtc_time : 16:21:00 rtc_date : 2004-08-31 rtc_epoch : 1900 alarm : 21:16:27 DST_enable : no BCD : yes 24hr : yes square_wave : no alarm_IRQ : no update_IRQ : no periodic_IRQ : no periodic_freq : 1024 batt_status : okay
Preface Red Hat Enterprise Linux minor releases are an aggregation of individual enhancement, security, and bug fix errata. The Red Hat Enterprise Linux 6.8 Release Notes document describes the major changes made to the Red Hat Enterprise Linux 6 operating system and its accompanying applications for this minor release, as well as known problems. The Technical Notes document provides a list of notable bug fixes, all currently available Technology Previews, deprecated functionality, and other information. Capabilities and limits of Red Hat Enterprise Linux 6 as compared to other versions of the system are available in the Red Hat Knowledgebase article available at https://access.redhat.com/articles/rhel-limits . For information regarding the Red Hat Enterprise Linux life cycle, refer to https://access.redhat.com/support/policy/updates/errata/ .

Commands:
A.6. Setting Virtual Machine Custom Properties Once custom properties are defined in the Red Hat Virtualization Manager, you can begin setting them on virtual machines. Custom properties are set on the Custom Properties tab of the New Virtual Machine and Edit Virtual Machine windows in the Administration Portal. You can also set custom properties from the Run Virtual Machine(s) dialog box. Custom properties set from the Run Virtual Machine(s) dialog box will only apply to the virtual machine until it is shutdown. The Custom Properties tab provides a facility for you to select from the list of defined custom properties. Once you select a custom property key an additional field will display allowing you to enter a value for that key. Add additional key/value pairs by clicking the + button and remove them by clicking the - button.

Commands:
8.9. Changes to RSA and DSA Key Generation Normal Red Hat Enterprise Linux 6 operation allows the generation of RSA and DSA keys of any size. Additional restrictions are applied if Red Hat Enterprise Linux 6 is run in FIPS mode. As of Red Hat Enterprise Linux 6.6, the OPENSSL_ENFORCE_MODULUS_BITS environment variable determines key generation behavior in FIPS mode. When FIPS mode is in use and the OPENSSL_ENFORCE_MODULUS_BITS environment variable is set, only 2048 bit or 3072 bit RSA and DSA keys can be generated. If the OPENSSL_ENFORCE_MODULUS_BITS environment variable is not set, key generation behavior does not change from releases of Red Hat Enterprise Linux 6: the system can generate RSA keys greater than or equal to 1024 bits, and DSA keys of 1024 bits, 2048 bits, or 3072 bits.

Commands:
8.5. Starting and Stopping the NFS Server Prerequisites For servers that support NFSv2 or NFSv3 connections, the rpcbind [1] service must be running. To verify that rpcbind is active, use the following command: To configure an NFSv4-only server, which does not require rpcbind , see Section 8.6.7, "Configuring an NFSv4-only Server" . On Red Hat Enterprise Linux 7.0, if your NFS server exports NFSv3 and is enabled to start at boot, you need to manually start and enable the nfs-lock service: On Red Hat Enterprise Linux 7.1 and later, nfs-lock starts automatically if needed, and an attempt to enable it manually fails. Procedures To start an NFS server, use the following command: To enable NFS to start at boot, use the following command: To stop the server, use: The restart option is a shorthand way of stopping and then starting NFS. This is the most efficient way to make configuration changes take effect after editing the configuration file for NFS. To restart the server type: After you edit the /etc/sysconfig/nfs file, restart the nfs-config service by running the following command for the new values to take effect: The try-restart command only starts nfs if it is currently running. This command is the equivalent of condrestart ( conditional restart ) in Red Hat init scripts and is useful because it does not start the daemon if NFS is not running. To conditionally restart the server, type: To reload the NFS server configuration file without restarting the service type:

Commands:
systemctl status rpcbind
systemctl start nfs-lock # systemctl enable nfs-lock
systemctl start nfs
systemctl enable nfs
systemctl stop nfs
systemctl restart nfs
systemctl restart nfs-config
systemctl try-restart nfs
systemctl reload nfs
5.94. gnome-terminal 5.94.1. RHBA-2012:1311 - gnome-terminal bug fix update Updated gnome-terminal packages that fix one bug are now available for Red Hat Enterprise Linux 6. Gnome-terminal is a terminal emulator for GNOME. It supports translucent backgrounds, opening multiple terminals in a single window (tabs) and clickable URLs. Bug Fix BZ# 819796 Prior to this update, gnome-terminal was not completely localized into Asamese. With this update, the Assamese locale has been updated. All gnome-terminal users are advised to upgrade to these updated packages, which fix this bug.

Commands:
14.4.2. Share-Level Security With share-level security, the server accepts only a password without an explicit username from the client. The server expects a password for each share, independent of the username. There have been recent reports that Microsoft Windows clients have compatibility issues with share-level security servers. Samba developers strongly discourage use of share-level security. In smb.conf , the security = share directive that sets share-level security is:

Commands:
[GLOBAL] security = share
Chapter 3. The User Interface The Automation Execution User Interface (UI) provides a graphical framework for your IT orchestration requirements. Access your user profile, the About page, view related documentation, or log out using the icons in the page header. The navigation panel provides quick access to automation controller resources, such as Jobs , Templates , Schedules , Projects , Infrastructure , and Administration . Jobs Job templates Workflow job templates Schedules Projects 3.1. Infrastructure menu The Infrastucture menu provides quick access to the following automation controller resources: Topology View Inventories Hosts Instance Groups Instances Execution Environments Credentials Credential Types 3.2. Administration The Administration menu provides access to the administrative options of automation controller. From here, you can create, view, and edit: Activity Stream Workflow Approvals Notifiers Management Jobs 3.3. The Settings menu You can configure some automation controller options by using the Settings menu of the User Interface. The Settings page enables an administrator to configure the following: Configuring subscriptions Platform gateway User preferences Configuring jobs Setting up logging Troubleshooting options

Commands:
8.34. cpupowerutils 8.34.1. RHBA-2014:1422 - cpupowerutils bug fix and enhancement update Updated cpupowerutils packages that fix several bugs and add one enhancement are now available for Red Hat Enterprise Linux 6. The cpupowerutils packages provide a suite of tools to manage power states on appropriately enabled central processing units (CPU). Bug Fix BZ# 1056310 , BZ# 1109187 Prior to this update, the turbostat utility did not correctly access the energy status register on certain Intel Core processors. As a consequence, turbostat displayed the following error message: /dev/cpu/0/msr offset 0x641 read failed With this update, turbostat has been fixed to correctly access the proper energy status registers. As a result, turbostat now returns the expected data in the described scenario. In addition, this update adds the following Enhancement BZ# 1093513 This update adds support for the Intel Broadwell Microarchitecture to the turbostat utility. Users of cpupowerutils are advised to upgrade to these updated packages, which fix these bugs and add this enhancement.

Commands: