mtpti5iD/redhat-docs_dataset huggingface dataset:
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.20.10, RHEL 9 - 1.20.10 A Go compiler. delve RHEL 8 - 1.20.2, RHEL 9 - 1.20.2 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
Chapter 3. Red Hat build of OpenJDK features The latest Red Hat build of OpenJDK 17 release might include new features. Additionally, the latest release might enhance, deprecate, or remove features that originated from Red Hat build of OpenJDK 17 releases. Note For all the other changes and security fixes, see OpenJDK 17.0.9 Released . 3.1. Red Hat build of OpenJDK enhancements Red Hat build of OpenJDK 17 provides enhancements to features originally created in releases of Red Hat build of OpenJDK. Increased default group size of TLS Diffie-Hellman In Red Hat build of OpenJDK 17.0.9, the JDK implementation of Transport Layer Security (TLS) 1.2 uses a default Diffie-Hellman key size of 2048 bits. This supersedes the behavior in releases where the default Diffie-Hellman key size was 1024 bits. This enhancement is relevant when a TLS_DHE cipher suite is negotiated and either the client or the server does not support Finite Field Diffie-Hellman Ephemeral (FFDHE) parameters. The JDK TLS implementation supports FFDHE, which is enabled by default and can negotiate a stronger key size. As a workaround, you can revert to the key size by setting the jdk.tls.ephemeralDHKeySize system property to 1024 . However, to mitigate risk, consider using the default key size of 2048 bits. Note This change does not affect TLS 1.3, which already uses a minimum Diffie-Hellman key size of 2048 bits. See JDK-8301700 (JDK Bug System) . -XshowSettings:locale output includes tzdata version In Red Hat build of OpenJDK 17.0.9, the -XshowSettings launcher option also prints the tzdata version that the JDK uses. The tzdata version is displayed as part of the output for the -XshowSettings:locale option. For example: See JDK-8305950 (JDK Bug System) . Certigna root CA certificate added In Red Hat build of OpenJDK 17.0.9, the cacerts truststore includes the Certigna root certificate: Name: Certigna (Dhimyotis) Alias name: certignarootca Distinguished name: CN=Certigna Root CA, OU=0002 48146308100036, O=Dhimyotis, C=FR See JDK-8314960 (JDK Bug System) . 3.2. Red Hat build of OpenJDK deprecated features Review the following release notes to understand pre-existing features that have been either deprecated or removed in Red Hat build of OpenJDK 17.0.9: SECOM Trust Systems root CA1 certificate removed Red Hat build of OpenJDK 17.0.9 removes the following root certificate from the cacerts truststore: Alias name: secomscrootca1 [jdk] Distinguished name: OU=Security Communication RootCA1, O=SECOM Trust.net, C=JP See JDK-8295894 (JDK Bug System) .

Commands:
Locale settings: default locale = English default display locale = English default format locale = English tzdata version = 2023c
Chapter 13. Updating and upgrading the Load-balancing service Perform regular updates and upgrades so that you can use the latest Red Hat OpenStack Platform Load-balancing service (octavia) features, and avoid possible lengthy and problematic issues caused by infrequent updates and upgrades. Section 13.1, "Updating and upgrading the Load-balancing service" Section 13.2, "Updating running Load-balancing service instances" 13.1. Updating and upgrading the Load-balancing service The Load-balancing service (octavia) is a part of a Red Hat OpenStack Platform (RHOSP) update or upgrade. Prerequisites Schedule a maintenance window to perform the upgrade, because during the upgrade the Load-balancing service control plane is not fully functional. Procedure Perform the RHOSP update as described in the Keeping Red Hat OpenStack Platform Updated guide. After the maintenance release is applied, if you need to use new features, then rotate running amphorae to update them to the latest amphora image. Additional resources Keeping Red Hat OpenStack Platform Updated guide Section 13.2, "Updating running Load-balancing service instances" Section 2.2, "Load-balancing service (octavia) feature support matrix" 13.2. Updating running Load-balancing service instances Periodically, you can update a running Load-balancing service instance (amphora) with a newer image. For example, you might want to update an amphora instance during the following events: An update or upgrade of Red Hat OpenStack Platform (RHOSP). A security update to your system. A change to a different flavor for the underlying virtual machine. During an RHOSP update or upgrade, director automatically downloads the default amphora image, uploads it to the overcloud Image service (glance), and then configures the Load-balancing service (octavia) to use the new image. When you fail over a load balancer, you force the Load-balancing service to start an instance (amphora) that uses the new amphora image. Prerequisites New images for amphora. These are available during an RHOSP update or upgrade. Procedure Source your credentials file. Example List the IDs for all of the load balancers that you want to update: Fail over each load balancer: Note When you start failing over the load balancers, monitor system utilization, and as needed, adjust the rate at which you perform failovers. A load balancer failover creates new virtual machines and ports, which might temporarily increase the load on OpenStack Networking. Monitor the state of the failed over load balancer: The update is complete when the load balancer status is ACTIVE . Additional resources loadbalancer in the Command Line Interface Reference

Commands:
source ~/overcloudrc
openstack loadbalancer list -c id -f value
openstack loadbalancer failover <loadbalancer_id>
openstack loadbalancer show <loadbalancer_id>
Appendix C. Journaler configuration reference Reference of the list commands that can be used for journaler configuration. journaler_write_head_interval Description How frequently to update the journal head object. Type Integer Required No Default 15 journaler_prefetch_periods Description How many stripe periods to read ahead on journal replay. Type Integer Required No Default 10 journaler_prezero_periods Description How many stripe periods to zero ahead of write position. Type Integer Required No Default 10 journaler_batch_interval Description Maximum additional latency in seconds to incur artificially. Type Double Required No Default .001 journaler_batch_max Description Maximum bytes that will be delayed flushing. Type 64-bit Unsigned Integer Required No Default 0

Commands:
5.363. xorg-x11-drv-intel 5.363.1. RHBA-2012:0995 - xorg-x11-drv-intel bug fix and enhancement update Updated xorg-x11-drv-intel packages that fix two bugs and add one enhancement are now available for Red Hat Enterprise Linux 6. The xorg-x11-drv-intel packages contain an Intel integrated graphics video driver for the X.Org implementation of the X Window System. Bug Fixes BZ# 692776 On Lenovo ThinkPad T500 laptops, the display could have stayed blank after opening the lid when it was used with an external display in mirror mode. Consequently, the following message appeared: With this update, the underlying source code has been modified so that the display turns on as expected when the lid is open. BZ# 711452 On Lenovo ThinkPad series laptops, the system did not always resume from the suspend state. This was dependent on monitor configuration and could occur under various circumstances, for example if the laptop was suspended docked with only external display enabled, and later resumed undocked with no external display. With this update, the system now resumes correctly regardless of the monitor configuration. Enhancement BZ# 821521 In addition, this update adds accelerated rendering support for the Intel Core i5 and i7 processors. All users of xorg-x11-drv-intel are advised to upgrade to these updated packages, which fix these bugs and add this enhancement.

Commands:
Could not switch the monitor configuration Could not set the configuration for CRT63
7.278. X.Org Legacy Input Drivers 7.278.1. RHEA-2013:0295 - X.Org X11 legacy input drivers enhancement update Updated xorg-x11-drv-acecad , xorg-x11-drv-aiptek , xorg-x11-drv-hyperpen , xorg-x11-drv-elographics , xorg-x11-drv-fpit , xorg-x11-drv-mutouch , xorg-x11-drv-penmount , and xorg-x11-drv-void packages that add various enhancements are now available for Red Hat Enterprise Linux 6. The xorg-x11-drv-keyboard and xorg-x11-drv-mouse packages contain the legacy X.Org X11 input drivers for keyboards and mice. The xorg-x11-drv-acecad , xorg-x11-drv-aiptek , xorg-x11-drv-hyperpen , xorg-x11-drv-elographics , xorg-x11-drv-fpit , xorg-x11-drv-mutouch , xorg-x11-drv-penmount , and xorg-x11-drv-void packages contain the X.Org X11 input drivers for legacy devices. The following packages have been upgraded to their respective upstream versions, which provide a number of enhancements over the versions: Table 7.3. Upgraded packages PACKAGE NAME UPSTREAM VERSION BZ NUMBER xorg-x11-drv-acecad 1.5.0 835212 xorg-x11-drv-aiptek 1.4.1 835215 xorg-x11-drv-elographics 1.4.1 835222 xorg-x11-drv-fpit 1.4.0 835229 xorg-x11-drv-hyperpen 1.4.1 835233 xorg-x11-drv-keyboard 1.6.2 835237 xorg-x11-drv-mouse 1.8.1 835242 xorg-x11-drv-mutouch 1.3.0 835243 xorg-x11-drv-penmount 1.5.0 835248 xorg-x11-drv-void 1.4.0 835264 Users of X.Org X11 legacy input drivers are advised to upgrade to these updated packages, which add these enhancements.

Commands:
Chapter 10. Troubleshooting scrub and deep-scrub issues Learn to troubleshoot the scrub and deep-scrub issues. 10.1. Addressing the scrub slowness issue while upgrading from 6 to 7 Learn to troubleshoot the scrub slowness issue which seen after upgrading from 6 to 7. Scrub slowness is caused by the automated OSD benchmark setting a very low value for osd_mclock_max_capacity_iops_hdd . Due to this, scrub operations are impacted since the IOPS capacity of an OSD plays a significant role in determining the bandwidth the scrub operation receives. To further increase the problem, scrubs receive only a fraction of the total IOPS capacity based on the QoS allocation defined by the mClock profile. Due to this, the Ceph cluster reports the expected scrub completion time in multiples of days or weeks. Prequisites A running Red Hat Ceph Storage cluster in a healthy state. Root-level access to the node. Procedure Detect low measured IOPS reported by OSD bench during OSD boot-up and fallback to default IOPS setting defined for osd_mclock_max_capacity_iops_[hdd|ssd] . The fallback is triggered if the reported IOPS falls below a threshold determined by osd_mclock_iops_capacity_low_threshold_[hdd|ssd] . A cluster warning is also logged. Example: [Optional]: Perform the following steps if you have not yet upgraded to 7 from 6 (before the upgrade): For clusters already affected by the issue, remove the IOPS capacity setting on the OSD(s) before upgrading to the release with the fix by running the following command: Example: Set the osd_mclock_force_run_benchmark_on_init option for the affected OSD to true before the upgrade: Example: After upgrading to the release with this fix, the IOPS capacity reflects the default setting or the new one reported by the OSD bench. [Optional]: Perform the following steps if you have already upgraded from 6 to 7 (after upgrade): If you were unable to perform the above steps before upgrade, you re-run the OSD bench again after upgrading by removing the osd_mclock_max_capacity_iops_[hdd|ssd] setting: Example: Set osd_mclock_force_run_benchmark_on_init to true . Example: Restart the OSD. After the OSD restarts, the IOPS capacity reflects the default setting or the new setting reported by the OSD bench.

Commands:
ceph config rm osd.X osd_mclock_max_capacity_iops_[hdd|ssd]
ceph config rm osd.X osd_mclock_max_capacity_iops_[hdd|ssd]
ceph config set osd.X osd_mclock_force_run_benchmark_on_init true
ceph config rm osd.X osd_mclock_max_capacity_iops_[hdd|ssd]
ceph config set osd.X osd_mclock_force_run_benchmark_on_init true
Appendix A. Troubleshooting A.1. Ansible stops installation because it detects less devices than expected The Ansible automation application stops the installation process and returns the following error: What this means: When the osd_auto_discovery parameter is set to true in the /usr/share/ceph-ansible/group_vars/osds.yml file, Ansible automatically detects and configures all the available devices. During this process, Ansible expects that all OSDs use the same devices. The devices get their names in the same order in which Ansible detects them. If one of the devices fails on one of the OSDs, Ansible fails to detect the failed device and stops the whole installation process. Example situation: Three OSD nodes ( host1 , host2 , host3 ) use the /dev/sdb , /dev/sdc , and dev/sdd disks. On host2 , the /dev/sdc disk fails and is removed. Upon the reboot, Ansible fails to detect the removed /dev/sdc disk and expects that only two disks will be used for host2 , /dev/sdb and /dev/sdc (formerly /dev/sdd ). Ansible stops the installation process and returns the above error message. To fix the problem: In the /etc/ansible/hosts file, specify the devices used by the OSD node with the failed disk ( host2 in the Example situation above): See Chapter 5, Installing Red Hat Ceph Storage using Ansible for details.

Commands:
- name: fix partitions gpt header or labels of the osd disks (autodiscover disks) shell: "sgdisk --zap-all --clear --mbrtogpt -- '/dev/{{ item.0.item.key }}' || sgdisk --zap-all --clear --mbrtogpt -- '/dev/{{ item.0.item.key }}'" with_together: - "{{ osd_partition_status_results.results }}" - "{{ ansible_devices }}" changed_when: false when: - ansible_devices is defined - item.0.item.value.removable == "0" - item.0.item.value.partitions|count == 0 - item.0.rc != 0
[osds] host1 host2 devices="[ '/dev/sdb', '/dev/sdc' ]" host3
Chapter 4. Demoting or promoting hidden replicas After a replica has been installed, you can configure whether the replica is hidden or visible. For details about hidden replicas, see The hidden replica mode . Prerequisites Ensure that the replica is not the DNSSEC key master. If it is, move the service to another replica before making this replica hidden. Ensure that the replica is not a CA renewal server. If it is, move the service to another replica before making this replica hidden. For details, see Procedure To hide a replica: To make a replica visible again: To view a list of all the hidden replicas in your topology: If all of your replicas are enabled, the command output does not mention hidden replicas.

Commands:
ipa server-state replica.idm.example.com --state=hidden
ipa server-state replica.idm.example.com --state=enabled
ipa config-show
5.6. Securing FTP The File Transport Protocol , or FTP , is an older TCP protocol designed to transfer files over a network. Because all transactions with the server, including user authentication, are unencrypted, it is considered an insecure protocol and should be carefully configured. Red Hat Enterprise Linux provides three FTP servers. gssftpd - A kerberized xinetd -based FTP daemon which does not pass authentication information over the network. Red Hat Content Accelerator ( tux ) - A kernel-space Web server with FTP capabilities. vsftpd - A standalone, security oriented implementation of the FTP service. The following security guidelines are for setting up the vsftpd FTP service. 5.6.1. FTP Greeting Banner Before submitting a username and password, all users are presented with a greeting banner. By default, this banner includes version information useful to crackers trying to identify weaknesses in a system. To change the greeting banner for vsftpd , add the following directive to the /etc/vsftpd/vsftpd.conf file: Replace <insert_greeting_here> in the above directive with the text of the greeting message. For mutli-line banners, it is best to use a banner file. To simplify management of multiple banners, place all banners in a new directory called /etc/banners/ . The banner file for FTP connections in this example is /etc/banners/ftp.msg . Below is an example of what such a file may look like: Note It is not necessary to begin each line of the file with 220 as specified in Section 5.1.1.1, "TCP Wrappers and Connection Banners" . To reference this greeting banner file for vsftpd , add the following directive to the /etc/vsftpd/vsftpd.conf file: It also is possible to send additional banners to incoming connections using TCP wrappers as described in Section 5.1.1.1, "TCP Wrappers and Connection Banners" .

Commands:
ftpd_banner= <insert_greeting_here>
#################################################### # Hello, all activity on ftp.example.com is logged.# ####################################################
banner_file=/etc/banners/ftp.msg
Appendix B. Restoring manual changes overwritten by a Puppet run If your manual configuration has been overwritten by a Puppet run, you can restore the files to the state. The following example shows you how to restore a DHCP configuration file overwritten by a Puppet run. Procedure Copy the file you intend to restore. This allows you to compare the files to check for any mandatory changes required by the upgrade. This is not common for DNS or DHCP services. Check the log files to note down the md5sum of the overwritten file. For example: Restore the overwritten file: Compare the backup file and the restored file, and edit the restored file to include any mandatory changes required by the upgrade.

Commands:
cp /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.backup
journalctl -xe /Stage[main]/Dhcp/File[/etc/dhcp/dhcpd.conf]: Filebucketed /etc/dhcp/dhcpd.conf to puppet with sum 622d9820b8e764ab124367c68f5fa3a1
puppet filebucket restore --local --bucket /var/lib/puppet/clientbucket /etc/dhcp/dhcpd.conf \ 622d9820b8e764ab124367c68f5fa3a1
Chapter 13. PodMetrics [metrics.k8s.io/v1beta1] Description PodMetrics sets resource usage metrics of a pod. Type object Required timestamp window containers 13.1. Specification Property Type Description apiVersion string APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources containers array Metrics for all containers are collected within the same time window. containers[] object ContainerMetrics sets resource usage metrics of a container. kind string Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds metadata ObjectMeta_v2 Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata timestamp Time The following fields define time interval from which metrics were collected from the interval [Timestamp-Window, Timestamp]. window Duration 13.1.1. .containers Description Metrics for all containers are collected within the same time window. Type array 13.1.2. .containers[] Description ContainerMetrics sets resource usage metrics of a container. Type object Required name usage Property Type Description name string Container name corresponding to the one from pod.spec.containers. usage object (Quantity) The memory usage is the memory working set. 13.2. API endpoints The following API endpoints are available: /apis/metrics.k8s.io/v1beta1/pods GET : list objects of kind PodMetrics /apis/metrics.k8s.io/v1beta1/namespaces/{namespace}/pods GET : list objects of kind PodMetrics /apis/metrics.k8s.io/v1beta1/namespaces/{namespace}/pods/{name} GET : read the specified PodMetrics 13.2.1. /apis/metrics.k8s.io/v1beta1/pods HTTP method GET Description list objects of kind PodMetrics Table 13.1. HTTP responses HTTP code Reponse body 200 - OK PodMetricsList schema 13.2.2. /apis/metrics.k8s.io/v1beta1/namespaces/{namespace}/pods HTTP method GET Description list objects of kind PodMetrics Table 13.2. HTTP responses HTTP code Reponse body 200 - OK PodMetricsList schema 13.2.3. /apis/metrics.k8s.io/v1beta1/namespaces/{namespace}/pods/{name} Table 13.3. Global path parameters Parameter Type Description name string name of the PodMetrics HTTP method GET Description read the specified PodMetrics Table 13.4. HTTP responses HTTP code Reponse body 200 - OK PodMetrics schema

Commands:
Chapter 17. Applying security context to Streams for Apache Kafka pods and containers Security context defines constraints on pods and containers. By specifying a security context, pods and containers only have the permissions they need. For example, permissions can control runtime operations or access to resources. 17.1. Handling of security context by OpenShift platform Handling of security context depends on the tooling of the OpenShift platform you are using. For example, OpenShift uses built-in security context constraints (SCCs) to control permissions. SCCs are the settings and strategies that control the security features a pod has access to. By default, OpenShift injects security context configuration automatically. In most cases, this means you don't need to configure security context for the pods and containers created by the Cluster Operator. Although you can still create and manage your own SCCs. For more information, see the OpenShift documentation .

Commands: