mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 8. Responsive restarts and security certificates MicroShift responds to system configuration changes and restarts after alterations are detected, including IP address changes, clock adjustments, and security certificate age. 8.1. IP address changes or clock adjustments MicroShift depends on device IP addresses and system-wide clock settings to remain consistent during its runtime. However, these settings may occasionally change on edge devices, such as DHCP or Network Time Protocol (NTP) updates. When such changes occur, some MicroShift components may stop functioning properly. To mitigate this situation, MicroShift monitors the IP address and system time and restarts if either setting change is detected. The threshold for clock changes is a time adjustment of greater than 10 seconds in either direction. Smaller drifts on regular time adjustments performed by the Network Time Protocol (NTP) service do not cause a restart. 8.2. Security certificate lifetime MicroShift certificates are separated into two basic groups: Short-lived certificates having certificate validity of one year. Long-lived certificates having certificate validity of 10 years. Most server or leaf certificates are short-term. An example of a long-lived certificate is the client certificate for system:admin user authentication, or the certificate of the signer of the kube-apiserver external serving certificate. 8.2.1. Certificate rotation Certificates that are expired or close to their expiration dates need to be rotated to ensure continued MicroShift operation. When MicroShift restarts for any reason, certificates that are close to expiring are rotated. A certificate that is set to expire imminently, or has expired, can cause an automatic MicroShift restart to perform a rotation. Note If the rotated certificate is a Certificate Authority, all of the certificates it signed rotate. 8.2.1.1. Short-term certificates The following situations describe MicroShift actions during short-term certificate lifetimes: No rotation: When a short-term certificate is up to 5 months old, no rotation occurs. Rotation at restart: When a short-term certificate is 5 to 8 months old, it is rotated when MicroShift starts or restarts. Automatic restart for rotation: When a short-term certificate is more than 8 months old, MicroShift can automatically restart to rotate and apply a new certificate. 8.2.1.2. Long-term certificates The following situations describe MicroShift actions during long-term certificate lifetimes: No rotation: When a long-term certificate is up to 8.5 years old, no rotation occurs. Rotation at restart: When a long-term certificate is 8.5 to 9 years old, it is rotated when MicroShift starts or restarts. Automatic restart for rotation: When a long-term certificate is more than 9 years old, MicroShift can automatically restart to rotate and apply a new certificate.

Commands:
4.5. Virtual Memory Performance Implications While virtual memory makes it possible for computers to more easily handle larger and more complex applications, as with any powerful tool, it comes at a price. The price in this case is one of performance -- a virtual memory operating system has a lot more to do than an operating system incapable of supporting virtual memory. This means that performance is never as good with virtual memory as it is when the same application is 100% memory-resident. However, this is no reason to throw up one's hands and give up. The benefits of virtual memory are too great to do that. And, with a bit of effort, good performance is possible. The thing that must be done is to examine those system resources impacted by heavy use of the virtual memory subsystem. 4.5.1. Worst Case Performance Scenario For a moment, take what you have read in this chapter and consider what system resources are used by extremely heavy page fault and swapping activity: RAM -- It stands to reason that available RAM is low (otherwise there would be no need to page fault or swap). Disk -- While disk space might not be impacted, I/O bandwidth (due to heavy paging and swapping) would be. CPU -- The CPU is expending cycles doing the processing required to support memory management and setting up the necessary I/O operations for paging and swapping. The interrelated nature of these loads makes it easy to understand how resource shortages can lead to severe performance problems. All it takes is a system with too little RAM, heavy page fault activity, and a system running near its limit in terms of CPU or disk I/O. At this point, the system is thrashing, with poor performance the inevitable result.

Commands:
Chapter 2. API Documentation 2.1. Download API Documentation Javadocs for JBoss Data Virtualization can be found on the Red Hat Customer Portal . Procedure: Download API Documentation Go to https://access.redhat.com/jbossnetwork . From the Software Downloads page, when prompted for a Product , select Data Virtualization . This will present a table of files to download for the latest version of the product. Change the Version to the current release if required. Look for JBoss Data Virtualization VERSION Javadocs in the table and select Download .

Commands:
Chapter 6. Converting to a RHEL system using Insights After running the Pre-conversion analysis for converting to RHEL task and resolving all reported issues, you can convert your CentOS Linux 7 systems to RHEL 7. Prerequisites You have completed the steps listed in Preparing for a RHEL conversion using Insights and Reviewing the pre-conversion analysis report using Insights . Note To avoid serious problems after the conversion, do not convert any systems that have unresolved inhibitors and warnings in the pre-conversion analysis. Procedure Log in to the Red Hat Hybrid Cloud Console and go to Red Hat Insights > RHEL > Automation toolkit > Tasks . Locate the Convert to RHEL from CentOS 7 Linux task and click Run task . Select the CentOS Linux 7 systems that you want to convert to RHEL and click Execute task . Note The conversion process can take up to an hour to complete. Go to the Activity tab and select the newly generated conversion report. Review each system and message: If a system has been successfully converted with no issues, reboot the system and proceed to the step. If the system was not converted, review the message for more information on the found problems and how to resolve them. Additionally, verify the following: You have completed all steps in Preparing for a RHEL conversion using Insights . The system contains all packages required for the conversion. The system is running. You have resolved all issues found in the Reviewing the pre-conversion analysis report using Insights . If the conversion timed out without completing, verify that the system is running and retry at another time. If issues persist, contact Support . After rebooting the system that has been successfully converted, remove third-party packages from the original OS that remained unchanged. These are typically packages that do not have a RHEL counterpart. To get a list of these packages, use: Replace RHEL_RepoID with your repository. Optional: Perform an in-place upgrade to RHEL 9 to ensure your system is updated with the latest enhancements, security features, and bug fixes. For more information, see the Upgrading from RHEL 7 to RHEL 8 and Upgrading from RHEL 8 to RHEL 9 guides.

Commands:
yum list extras --disablerepo=" " --enablerepo= <RHEL_RepoID> *
Chapter 1. Introduction 1.1. Red Hat Virtualization Manager The Red Hat Virtualization Manager provides centralized management for a virtualized environment. A number of different interfaces can be used to access the Red Hat Virtualization Manager. Each interface facilitates access to the virtualized environment in a different manner. Figure 1.1. Red Hat Virtualization Manager Architecture The Red Hat Virtualization Manager provides graphical interfaces and an Application Programming Interface (API). Each interface connects to the Manager, an application delivered by an embedded instance of the Red Hat JBoss Enterprise Application Platform. There are a number of other components which support the Red Hat Virtualization Manager in addition to Red Hat JBoss Enterprise Application Platform.

Commands:
Preface Red Hat OpenShift Data Foundation supports deployment on existing Red Hat OpenShift Container Platform (RHOCP) Red Hat Virtualization platform clusters. Deploying OpenShift Data Foundation on OpenShift Container Platform using shared storage devices provided by Red Hat Virtualization installer-provisioned infrastructure (IPI) enables you to create internal cluster resources. Also, it is possible to deploy only the Multicloud Object Gateway (MCG) component with OpenShift Data Foundation. Note Only internal OpenShift Data Foundation clusters are supported on Red Hat Virtualization platform. See Planning your deployment for more information about deployment requirements. Based on your requirement, perform one of the following methods of deployment: Deploy using dynamic storage devices for the full deployment of OpenShift Data Foundation using dynamic storage devices. Deploy using local storage devices for the full deployment of OpenShift Data Foundation using local storage devices. Deploy standalone Multicloud Object Gateway component for deploying only the Multicloud Object Gateway component with OpenShift Data Foundation.

Commands:
Index A about this document other Red Hat Enterprise Linux documents, Introduction C cluster displaying status, Cluster Status Tool cluster administration displaying cluster and service status, Cluster Status Tool cluster component compatible hardware, Compatible Hardware cluster components table, Cluster Components Cluster Configuration Tool accessing, Cluster Configuration Tool cluster service displaying status, Cluster Status Tool command line tools table, Command Line Administration Tools compatible hardware cluster components, Compatible Hardware Conga overview, Conga Conga overview, Conga F feedback, Feedback I introduction, Introduction L LVS direct routing requirements, hardware, Direct Routing requirements, network, Direct Routing requirements, software, Direct Routing routing methods NAT, Routing Methods three tiered high-availability cluster, Three-Tier LVS Topology N NAT routing methods, LVS, Routing Methods network address translation (see NAT) O overview economy, Red Hat GFS performance, Red Hat GFS scalability, Red Hat GFS P Piranha Configuration Tool CONTROL/MONITORING, CONTROL/MONITORING EDIT MONITORING SCRIPTS Subsection, EDIT MONITORING SCRIPTS Subsection GLOBAL SETTINGS, GLOBAL SETTINGS login panel, Linux Virtual Server Administration GUI necessary software, Linux Virtual Server Administration GUI REAL SERVER subsection, REAL SERVER Subsection REDUNDANCY, REDUNDANCY VIRTUAL SERVER subsection, VIRTUAL SERVERS Firewall Mark, The VIRTUAL SERVER Subsection Persistence, The VIRTUAL SERVER Subsection Scheduling, The VIRTUAL SERVER Subsection Virtual IP Address, The VIRTUAL SERVER Subsection VIRTUAL SERVERS, VIRTUAL SERVERS R Red Hat Cluster Manager components, Cluster Components T table command line tools, Command Line Administration Tools tables cluster components, Cluster Components

Commands:
Chapter 1. Introduction to Federal Information Processing Standards (FIPS) The Federal Information Processing Standards (FIPS) provides guidelines and requirements for improving security and interoperability across computer systems and networks. The FIPS 140-2 and 140-3 series apply to cryptographic modules at both the hardware and software levels. The National Institute of Standards and Technology in the United States implements a cryptographic module validation program with searchable lists of both in-process and approved cryptographic modules. Red Hat Enterprise Linux (RHEL) brings an integrated framework to enable FIPS 140 compliance system-wide. When operating under FIPS mode, software packages using cryptographic libraries are self-configured according to the global policy. Most of the packages provide a way to change the default alignment behavior for compatibility or other needs. Red Hat build of OpenJDK 17 is a FIPS policy-aware package. Additional resources For more information about the cryptographic module validation program, see Cryptographic Module Validation Program CMVP on the National Institute of Standards and Technology website. For more information on how to install RHEL with FIPS mode enabled, see Installing a RHEL 8 system with FIPS mode enabled . For more information on how to enable FIPS mode after installing RHEL, see Switching the system to FIPS mode . For more information on how to run Red Hat build of OpenJDK in FIPS mode on RHEL. See Running OpenJDK in FIPS mode on RHEL . For more information on Red Hat compliance with Government Standards, see Government Standards .

Commands:
4.333. unicap 4.333.1. RHBA-2011:1202 - unicap bug fix update An updated unicap package that fixes multiple bugs is now available for Red Hat Enterprise Linux 6. The unicap package provides a uniform interface to video capture devices. It allows applications to use any supported video capture device via a single application programming interface (API). The included ucil library provides functions to render text and graphic overlays onto video images. Bug Fixes BZ# 612693 Prior to this update, the unicap package did not provide the libucil, libunicap and libunicap-gtk virtual packages. As a result, it was not possible to install packages that depended on the libucil, libunicap and libunicap-gtk packages. This update fixes the declaration "--provides" so that the unicap package now provides the virtual packages. BZ# 635644 Prior to this update, the unicap utility did not check for the return value of the Advanced Linux Sound Architecture (ALSA) initialization. As a result, unicap terminated unexpectedly if the initialization of ALSA failed. This update adds the missing checks for the return value to handle the ALSA initialization failure gracefully. BZ# 635645 Prior to this update, the unicap utility did not check for the return value of the Theora encoder initialization. As a result, unicap terminated unexpectedly if the initialization of the Theora encoder failed. This update adds the missing checks for the return value to handle the Theora encoder initialization failure gracefully. BZ# 658059 Prior to this update, unicap-devel packages for both 32-bit and 64-bit architectures on a single system could not be installed because of conflicts between the packages. This update uses the documentation from the unicap source code archive instead of the documentation generated at build time. Now, unicap-devel packages can be installed as expected. BZ# 728473 Prior to this update, the unicap package was missing a dependency on libv4l2.so.0, although some libraries shipped with unicap were using libv4l2.so.0. This update adds the missing dependency. All users of unicap are advised to upgrade to this updated package, which fixes these bugs.

Commands:
Chapter 1. Overview of distributed workloads You can use the distributed workloads feature to queue, scale, and manage the resources required to run data science workloads across multiple nodes in an OpenShift cluster simultaneously. Typically, data science workloads include several types of artificial intelligence (AI) workloads, including machine learning (ML) and Python workloads. Distributed workloads provide the following benefits: You can iterate faster and experiment more frequently because of the reduced processing time. You can use larger datasets, which can lead to more accurate models. You can use complex models that could not be trained on a single node. You can submit distributed workloads at any time, and the system then schedules the distributed workload when the required resources are available. The distributed workloads infrastructure includes the following components: CodeFlare Operator Secures deployed Ray clusters and grants access to their URLs CodeFlare SDK Defines and controls the remote distributed compute jobs and infrastructure for any Python-based environment Note The CodeFlare SDK is not installed as part of OpenShift AI, but it is contained in some of the notebook images provided by OpenShift AI. KubeRay Manages remote Ray clusters on OpenShift for running distributed compute workloads Kueue Manages quotas and how distributed workloads consume them, and manages the queueing of distributed workloads with respect to quotas Note The minimum version of OpenShift that is compatible with Kueue 0.10.1 is 4.15. If you deploy Red Hat OpenShift AI 2.18 on OpenShift 4.14 or earlier, you must disable the API Priority and Fairness configuration for the Visibility API, as described in the Enabling/Disabling API Priority and Fairness section in the Kueue Cluster Administration guide. This modification is required because the PriorityLevelConfiguration API is incompatible with older OpenShift versions. You can run distributed workloads from data science pipelines, from Jupyter notebooks, or from Microsoft Visual Studio Code files. Note Data science pipelines workloads are not managed by the distributed workloads feature, and are not included in the distributed workloads metrics.

Commands:
Chapter 2. Disaster scenarios in IdM Prepare and respond to various disaster scenarios in Identity Management (IdM) systems that affect servers, data, or entire infrastructures. Table 2.1. Disaster scenarios in IdM Disaster type Example causes How to prepare How to respond Server loss : The IdM deployment loses one or several servers. Hardware malfunction Preparing for server loss with replication Recovering a single server with replication Data loss : IdM data is unexpectedly modified on a server, and the change is propagated to other servers. A user accidentally deletes data A software bug modifies data Preparing for data loss with VM snapshots Preparing for data loss with IdM backups Recovering from data loss with VM snapshots Recovering from data loss with IdM backups Managing data loss Total infrastructure loss : All IdM servers or Certificate Authority (CA) replicas are lost with no VM snapshots or data backups available. Lack of off-site backups or redundancy prevents recovery after a failure or disaster. Preparing for data loss with VM snapshots This situation is a total loss. Warning A total loss scenario occurs when all Certificate Authority (CA) replicas or all IdM servers are lost, and no virtual machine (VM) snapshots or backups are available for recovery. Without CA replicas, the IdM environment cannot deploy additional replicas or rebuild itself, making recovery impossible. To avoid such scenarios, ensure backups are stored off-site, maintain multiple geographically redundant CA replicas, and connect each replica to at least two others.

Commands:
Chapter 3. Creating an IBM Power Virtual Server workspace 3.1. Creating an IBM Power Virtual Server workspace Use the following procedure to create an IBM Power(R) Virtual Server workspace. Procedure To create an IBM Power(R) Virtual Server workspace, complete step 1 to step 5 from the IBM Cloud(R) documentation for Creating an IBM Power(R) Virtual Server . After it has finished provisioning, retrieve the 32-character alphanumeric Globally Unique Identifier (GUID) of your new workspace by entering the following command: USD ibmcloud resource service-instance <workspace name> 3.2. steps Installing a cluster on IBM Power(R) Virtual Server with customizations

Commands:
ibmcloud resource service-instance <workspace name>
Chapter 1. Overview of upgrading RHHI for Virtualization Upgrading involves moving from one version of a product to a newer release of the same product. This section shows you how to upgrade to Red Hat Hyperconverged Infrastructure for Virtualization 1.8 from versions 1.5, 1.6 and 1.7. From a component standpoint, this involves the following: Upgrading the Hosted Engine virtual machine to Red Hat Virtualization Manager version 4.4. Upgrading the physical hosts to Red Hat Virtualization 4.4.

Commands:
4.9. NTP NTP (Network Time Protocol) is used to synchronize the clocks of computer systems over the network. In Red Hat Enterprise Linux 6, the default configuration file, /etc/ntp.conf , now has the following lines commented: This configuration means that ntpd will only distribute time information to network clients if it is specifically synchronized to an NTP server or a reference clock. To get ntpd to offer this information even when not synchronized, the two lines must be uncommented. Also, when ntpd is started with the -x option (in OPTIONS in the /etc/sysconfig/ntpd file), or if there are servers specified in /etc/ntp/step-tickers , the service no longer runs the ntpdate command before starting. There is now a separate ntpdate service which can be enabled independently from the ntpd service. This ntpdate service is disabled by default, and is only recommended for use when other services require the correct time before starting, or do not function properly when time modifications occur later by ntpd . If you encounter problems running this service with the default NetworkManager configuration, a possible fix is to add NETWORKWAIT=1 to /etc/sysconfig/network , as described in the Red Hat Enterprise Linux Deployment Guide. As of Red Hat Enterprise Linux 6.5, the format used by ntpd for syslog messages has changed. This affects users attempting to parse these log messages. Additionally, users can now configure the types of message to be logged using the logconfig option in ntp.conf .

Commands:
#server 127.127.1.0 # local clock #fudge 127.127.1.0 stratum 10
Chapter 51. Using standalone custom pages(dashboards) Apart from standalone perspectives, you can also embed custom pages, also known as dashboards, in your application. For accessing the custom pages from your application, provide the name of the custom page as the value of the perspective parameter. Note that the perspective parameter is case-sensitive. Procedure Log in to Business Central. In a web browser, enter the custom page's web address in the address bar, for example, http://localhost:8080/business-central/kie-wb.jsp?standalone=true&perspective=CustomPageName The standalone custom page opens in the browser. Replace the value, CustomPageName , with the name of the custom page you want to use in the standalone mode.

Commands: