mtpti5iD/redhat-docs_dataset huggingface dataset:
C.5.2. Runlevel 5 When the system boots into runlevel 5, a special X client application called a display manager is launched. A user must authenticate using the display manager before any desktop environment or window managers are launched. Depending on the desktop environments installed on the system, three different display managers are available to handle user authentication. GDM (GNOME Display Manager) - The default display manager for Red Hat Enterprise Linux. GNOME allows the user to configure language settings, shutdown, restart or log in to the system. KDM - KDE's display manager which allows the user to shutdown, restart or log in to the system. xdm (X Window Display Manager) - A very basic display manager which only lets the user log in to the system. When booting into runlevel 5, the /etc/X11/prefdm script determines the preferred display manager by referencing the /etc/sysconfig/desktop file. A list of options for this file is available in this file: where <version-number> is the version number of the initscripts package. Each of the display managers reference the /etc/X11/xdm/Xsetup_0 file to set up the login screen. Once the user logs into the system, the /etc/X11/xdm/GiveConsole script runs to assign ownership of the console to the user. Then, the /etc/X11/xdm/Xsession script runs to accomplish many of the tasks normally performed by the xinitrc script when starting X from runlevel 3, including setting system and user resources, as well as running the scripts in the /etc/X11/xinit/xinitrc.d/ directory. Users can specify which desktop environment they want to use when they authenticate using the GNOME or KDE display managers by selecting it from the Sessions menu item accessed by selecting System Preferences More Preferences Sessions . If the desktop environment is not specified in the display manager, the /etc/X11/xdm/Xsession script checks the .xsession and .Xclients files in the user's home directory to decide which desktop environment to load. As a last resort, the /etc/X11/xinit/Xclients file is used to select a desktop environment or window manager to use in the same way as runlevel 3. When the user finishes an X session on the default display ( :0 ) and logs out, the /etc/X11/xdm/TakeConsole script runs and reassigns ownership of the console to the root user. The original display manager, which continues running after the user logged in, takes control by spawning a new display manager. This restarts the X server, displays a new login window, and starts the entire process over again. The user is returned to the display manager after logging out of X from runlevel 5. For more information on how display managers control user authentication, see the /usr/share/doc/gdm- <version-number> /README , where <version-number> is the version number for the gdm package installed, or the xdm man page.

Commands:
/usr/share/doc/initscripts- <version-number> /sysconfig.txt
4.7. Kernel Thin-provisioning and scalable snapshot capabilities The dm-thinp targets, thin and thin-pool , provide a device mapper device with thin-provisioning and scalable snapshot capabilities. This feature is available as a Technology Preview. Package: kernel-2.6.32-358 Kernel Media support The following features are presented as Technology Previews: The latest upstream video4linux Digital video broadcasting Primarily infrared remote control device support Various webcam support fixes and improvements Package: kernel-2.6.32-358 Remote audit logging The audit package contains the user space utilities for storing and searching the audit records generated by the audit subsystem in the Linux 2.6 kernel. Within the audispd-plugins sub-package is a utility that allows for the transmission of audit events to a remote aggregating machine. This remote audit logging application, audisp-remote , is considered a Technology Preview in Red Hat Enterprise Linux 6. Package: audispd-plugins-2.2-2 Linux (NameSpace) Container [LXC] Linux containers provide a flexible approach to application runtime containment on bare-metal systems without the need to fully virtualize the workload. Red Hat Enterprise Linux 6 provides application level containers to separate and control the application resource usage policies via cgroups and namespaces. This release includes basic management of container life-cycle by allowing creation, editing and deletion of containers via the libvirt API and the virt-manager GUI. Linux Containers are a Technology Preview. Packages: libvirt-0.9.10-21 , virt-manager-0.9.0-14 Diagnostic pulse for the fence_ipmilan agent, BZ# 655764 A diagnostic pulse can now be issued on the IPMI interface using the fence_ipmilan agent. This new Technology Preview is used to force a kernel dump of a host if the host is configured to do so. Note that this feature is not a substitute for the off operation in a production cluster. Package: fence-agents-3.1.5-25

Commands:
6.13. RHEA-2013:0289 - new package: mtdev A new mtdev package is now available for Red Hat Enterprise Linux 6. The new mtdev package contains a library that converts kernel input events from multitouch protocol A into multitouch protocol B events. Protocol B events provide per-touchpoint tracking which is required by the xorg-x11-drv-evdev and xorg-x11-drv-synaptics packages. This enhancement update adds the mtdev package to Red Hat Enterprise Linux 6. (BZ# 860177 ) All users who require mtdev should install this new package.

Commands:
Chapter 1. Overview of the OpenShift Data Foundation update process This chapter helps you to upgrade between the minor releases and z-streams for all Red Hat OpenShift Data Foundation deployments (Internal, Internal-Attached and External). The upgrade process remains the same for all deployments. You can upgrade OpenShift Data Foundation and its components, either between minor releases like 4.12 and 4.13, or between z-stream updates like 4.13.0 and 4.13.1 by enabling automatic updates (if not done so during operator installation) or performing manual updates. When a new z-stream release becomes available, the upgrade process triggers automatically if the update strategy was set to Automatic. You also need to upgrade the different parts of Red Hat OpenShift Data Foundation in the following order for both internal and external mode deployments: Update OpenShift Container Platform according to the Updating clusters documentation for OpenShift Container Platform. Update Red Hat OpenShift Data Foundation. To prepare a disconnected environment for updates , see Operators guide to using Operator Lifecycle Manager on restricted networks to be able to update OpenShift Data Foundation as well as Local Storage Operator when in use. For updating between minor releases , see Updating Red Hat OpenShift Data Foundation 4.12 to 4.13 . For updating between z-stream releases , see Updating Red Hat OpenShift Data Foundation 4.13.x to 4.13.y . For updating external mode deployments , you must also perform the steps from section Updating the Red Hat OpenShift Data Foundation external secret . If you use local storage, then update the Local Storage operator . See Checking for Local Storage Operator deployments if you are unsure. Important If you have an existing setup of OpenShift Data Foundation 4.12 with disaster recovery (DR) enabled, ensure to update all your clusters in the environment at the same time and avoid updating a single cluster. This is to avoid any potential issues and maintain best compatibility. It is also important to maintain consistency across all OpenShift Data Foundation DR instances. After the upgrade, you must run step 1 of the workaround for BZ#2215462 as documented in the DR upgrade Known issues section of Release notes . Update considerations Review the following important considerations before you begin. The Red Hat OpenShift Container Platform version is the same as Red Hat OpenShift Data Foundation. See the Interoperability Matrix for more information about supported combinations of OpenShift Container Platform and Red Hat OpenShift Data Foundation. To know whether your cluster was deployed in internal or external mode, refer to the knowledgebase article on How to determine if ODF cluster has storage in internal or external mode . The Local Storage Operator is fully supported only when the Local Storage Operator version matches the Red Hat OpenShift Container Platform version. The flexible scaling feature is available only in new deployments of OpenShift Data Foundation. For more information, see Scaling storage guide .

Commands:
23.18. Installing Packages At this point there is nothing left for you to do until all the packages have been installed. How quickly this happens depends on the number of packages you have selected and your computer's speed. Depending on the available resources, you might see the following progress bar while the installer resolves dependencies of the packages you selected for installation: Figure 23.52. Starting installation During installation of the selected packages and their dependencies, you see the following progress bar: Figure 23.53. Packages completed

Commands:
4.10. Configuring Fencing Levels Pacemaker supports fencing nodes with multiple devices through a feature called fencing topologies. To implement topologies, create the individual devices as you normally would and then define one or more fencing levels in the fencing-topology section in the configuration. Each level is attempted in ascending numeric order, starting at 1. If a device fails, processing terminates for the current level. No further devices in that level are exercised and the level is attempted instead. If all devices are successfully fenced, then that level has succeeded and no other levels are tried. The operation is finished when a level has passed (success), or all levels have been attempted (failed). Use the following command to add a fencing level to a node. The devices are given as a comma-separated list of stonith ids, which are attempted for the node at that level. The following command lists all of the fencing levels that are currently configured. In the following example, there are two fence devices configured for node rh7-2 : an ilo fence device called my_ilo and an apc fence device called my_apc . These commands sets up fence levels so that if the device my_ilo fails and is unable to fence the node, then Pacemaker will attempt to use the device my_apc . This example also shows the output of the pcs stonith level command after the levels are configured. The following command removes the fence level for the specified node and devices. If no nodes or devices are specified then the fence level you specify is removed from all nodes. The following command clears the fence levels on the specified node or stonith id. If you do not specify a node or stonith id, all fence levels are cleared. If you specify more than one stonith id, they must be separated by a comma and no spaces, as in the following example. The following command verifies that all fence devices and nodes specified in fence levels exist.

Commands:
pcs stonith level add level node devices
pcs stonith level
pcs stonith level add 1 rh7-2 my_ilo pcs stonith level add 2 rh7-2 my_apc pcs stonith level Node: rh7-2 Level 1 - my_ilo Level 2 - my_apc
pcs stonith level remove level [ node_id ] [ stonith_id ] ... [ stonith_id ]
pcs stonith level clear [ node | stonith_id (s)]
pcs stonith level clear dev_a,dev_b
pcs stonith level verify
Chapter 17. Installing a three-node cluster on AWS In OpenShift Container Platform version 4.15, you can install a three-node cluster on Amazon Web Services (AWS). A three-node cluster consists of three control plane machines, which also act as compute machines. This type of cluster provides a smaller, more resource efficient cluster, for cluster administrators and developers to use for testing, development, and production. You can install a three-node cluster using either installer-provisioned or user-provisioned infrastructure. Note Deploying a three-node cluster using an AWS Marketplace image is not supported. 17.1. Configuring a three-node cluster You configure a three-node cluster by setting the number of worker nodes to 0 in the install-config.yaml file before deploying the cluster. Setting the number of worker nodes to 0 ensures that the control plane machines are schedulable. This allows application workloads to be scheduled to run from the control plane nodes. Note Because application workloads run from control plane nodes, additional subscriptions are required, as the control plane nodes are considered to be compute nodes. Prerequisites You have an existing install-config.yaml file. Procedure Set the number of compute replicas to 0 in your install-config.yaml file, as shown in the following compute stanza: Example install-config.yaml file for a three-node cluster apiVersion: v1 baseDomain: example.com compute: - name: worker platform: {} replicas: 0 # ... If you are deploying a cluster with user-provisioned infrastructure: After you create the Kubernetes manifest files, make sure that the spec.mastersSchedulable parameter is set to true in cluster-scheduler-02-config.yml file. You can locate this file in <installation_directory>/manifests . For more information, see "Creating the Kubernetes manifest and Ignition config files" in "Installing a cluster on user-provisioned infrastructure in AWS by using CloudFormation templates". Do not create additional worker nodes. Example cluster-scheduler-02-config.yml file for a three-node cluster apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {} 17.2. steps Installing a cluster on AWS with customizations Installing a cluster on user-provisioned infrastructure in AWS by using CloudFormation templates

Commands:
apiVersion: v1 baseDomain: example.com compute: - name: worker platform: {} replicas: 0
apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {}
8.38. evolution 8.38.1. RHSA-2013:1540 - Low: evolution security, bug fix, and enhancement update Updated evolution packages that fix one security issue, several bugs, and add various enhancements are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having low security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, are available for each vulnerability from the CVE links associated with each description below. Evolution is the integrated collection of email, calendaring, contact management, communications, and personal information management (PIM) tools for the GNOME desktop environment. Security Fix CVE-2013-4166 A flaw was found in the way Evolution selected GnuPG public keys when encrypting emails. This could result in emails being encrypted with public keys other than the one belonging to the intended recipient. Note The Evolution packages have been upgraded to upstream version 2.32.3, which provides a number of bug fixes and enhancements over the version. These changes include implementation of Gnome XDG Config Folders, and support for Exchange Web Services (EWS) protocol to connect to Microsoft Exchange servers. EWS support has been added as a part of the evolution-exchange packages. (BZ# 883010 , BZ# 883014 , BZ# 883015 , BZ# 883017 , BZ# 524917 , BZ# 524921 , BZ# 883044 ) The gtkhtml3 packages have been upgraded to upstream version 2.32.2, which provides a number of bug fixes and enhancements over the version. (BZ# 883019 ) The libgdata packages have been upgraded to upstream version 0.6.4, which provides a number of bug fixes and enhancements over the version. (BZ# 883032 ) Bug Fix BZ# 665967 The Exchange Calendar could not fetch the "Free" and "Busy" information for meeting attendees when using Microsoft Exchange 2010 servers, and this information thus could not be displayed. This happened because Microsoft Exchange 2010 servers use more strict rules for "Free" and "Busy" information fetching. With this update, the respective code in the openchange packages has been modified so the "Free" and "Busy" information fetching now complies with the fetching rules on Microsoft Exchange 2010 servers. The "Free" and "Busy" information can now be displayed as expected in the Exchange Calendar. All Evolution users are advised to upgrade to these updated packages, which contain backported patches to correct these issues and add these enhancements. All running instances of Evolution must be restarted for this update to take effect.

Commands:
Chapter 4. Technology previews This section describes technology preview features introduced in Red Hat OpenShift Data Foundation 4.9 under Technology Preview support limitations. Important Technology Preview features are provided with a limited support scope, as detailed on the Customer Portal: Technology Preview Features Support Scope . PV encryption - service account per namespace As of Openshift Data Foundation 4.9, you can use service accounts to authenticate a tenant with Vault as a technology preview. For more information, see Persistent volume encryption . Alerts to control overprovision With this release, you can get alerts for the overprovision. This enables you to define a quota on the amount of persistent volume claims (PVCs) consumed from a storage cluster based on the specific application namespace. For more information, see Overprovision level policy control .

Commands:
Chapter 5. Installing a three-node cluster on Nutanix In OpenShift Container Platform version 4.16, you can install a three-node cluster on Nutanix. A three-node cluster consists of three control plane machines, which also act as compute machines. This type of cluster provides a smaller, more resource efficient cluster, for cluster administrators and developers to use for testing, development, and production. 5.1. Configuring a three-node cluster You configure a three-node cluster by setting the number of worker nodes to 0 in the install-config.yaml file before deploying the cluster. Setting the number of worker nodes to 0 ensures that the control plane machines are schedulable. This allows application workloads to be scheduled to run from the control plane nodes. Note Because application workloads run from control plane nodes, additional subscriptions are required, as the control plane nodes are considered to be compute nodes. Prerequisites You have an existing install-config.yaml file. Procedure Set the number of compute replicas to 0 in your install-config.yaml file, as shown in the following compute stanza: Example install-config.yaml file for a three-node cluster apiVersion: v1 baseDomain: example.com compute: - name: worker platform: {} replicas: 0 # ... 5.2. steps Installing a cluster on Nutanix

Commands:
apiVersion: v1 baseDomain: example.com compute: - name: worker platform: {} replicas: 0
Preface Open Java Development Kit (OpenJDK) is a free and open source implementation of the Java Platform, Standard Edition (Java SE). The Red Hat build of OpenJDK is available in three versions: 8u, 11u, and 17u. Packages for the Red Hat build of OpenJDK are made available on Red Hat Enterprise Linux and Microsoft Windows and shipped as a JDK and JRE in the Red Hat Ecosystem Catalog.

Commands:
Chapter 1. Installing and Configuring Data Warehouse 1.1. Overview of Configuring Data Warehouse You can install and configure Data Warehouse on the same machine as the Manager, or on a separate machine with access to the Manager: Install and configure Data Warehouse on the Manager machine This configuration requires only a single registered machine, and is the simplest to configure, but it increases the demand on the Manager machine. Users who require access to the Data Warehouse service require access to the Manager machine itself. See Configuring the Red Hat Virtualization Manager in Installing Red Hat Virtualization as a standalone Manager with local databases . Install and configure Data Warehouse on a separate machine This configuration requires two registered machines. It reduces the load on the Manager machine and avoids potential CPU and memory-sharing conflicts on that machine. Administrators can also allow user access to the Data Warehouse machine, without the need to grant access to the Manager machine. See Installing and Configuring Data Warehouse on a Separate Machine for more information on this configuration. Important It is recommended that you set the system time zone for all machines in your Data Warehouse deployment to UTC. This ensures that data collection is not interrupted by variations in your local time zone: for example, a change from summer time to winter time. To calculate an estimate of the space and resources the ovirt_engine_history database will use, use the RHV Manager History Database Size Calculator tool. The estimate is based on the number of entities and the length of time you have chosen to retain the history records. Important The following behavior is expected in engine-setup : Install the Data Warehouse package, run engine-setup , and answer No to configuring Data Warehouse: Configure Data Warehouse on this host (Yes, No) [Yes]: No Run engine-setup again; setup no longer presents the option to configure Data Warehouse. To force engine-setup to present the option again, run engine-setup --reconfigure-optional-components . To configure only the currently installed Data Warehouse packages, and prevent setup from applying package updates found in enabled repositories, add the --offline option .

Commands:
Configure Data Warehouse on this host (Yes, No) [Yes]: No
Chapter 2. Learn more about OpenShift Container Platform Use the following sections to find content to help you learn about and use OpenShift Container Platform. 2.1. Architect Learn about OpenShift Container Platform Plan an OpenShift Container Platform deployment Additional resources Enterprise Kubernetes with OpenShift Tested platforms OpenShift blog Architecture Security and compliance What's new in OpenShift Container Platform Networking OpenShift Container Platform life cycle Backup and restore 2.2. Cluster Administrator Learn about OpenShift Container Platform Deploy OpenShift Container Platform Manage OpenShift Container Platform Additional resources Enterprise Kubernetes with OpenShift Installing OpenShift Container Platform Using Insights to identify issues with your cluster Getting Support Architecture Post installation configuration Logging OpenShift Knowledgebase articles OpenShift Interactive Learning Portal Networking Monitoring overview OpenShift Container Platform Life Cycle Storage Backup and restore Updating a cluster 2.3. Application Site Reliability Engineer (App SRE) Learn about OpenShift Container Platform Deploy and manage applications Additional resources OpenShift Interactive Learning Portal Projects Getting Support Architecture Operators OpenShift Knowledgebase articles Logging OpenShift Container Platform Life Cycle Blogs about logging Monitoring 2.4. Developer Learn about application development in OpenShift Container Platform Deploy applications Getting started with OpenShift for developers (interactive tutorial) Creating applications Red Hat Developers site Builds Red Hat CodeReady Workspaces Operators Images Developer-focused CLI

Commands:
22.16.8. Adding a Manycast Server Address To add a manycast server address, that is to say, to configure an address to allow the clients to discover the server by multicasting NTP packets, make use of the manycastserver command in the ntp.conf file. The manycastserver command takes the following form: manycastserver address Enables the sending of multicast messages. Where address is the address to multicast to. This should be used together with authentication to prevent service disruption. This command configures a system to act as an NTP server. Systems can be both client and server at the same time.

Commands: