mtpti5iD/redhat-docs_dataset huggingface dataset:
C.5. Runlevels and X In most cases, the Red Hat Enterprise Linux installer configures a machine to boot into a graphical login environment, known as runlevel 5 . It is possible, however, to boot into a text-only multi-user mode called runlevel 3 and begin an X session from there. The following subsections review how X starts up in both runlevel 3 and runlevel 5. For more information about runlevels, see Section 12.1, "Configuring the Default Runlevel" . C.5.1. Runlevel 3 When in runlevel 3, the best way to start an X session is to log in and type startx . The startx command is a front-end to the xinit command, which launches the X server ( Xorg ) and connects X client applications to it. Because the user is already logged into the system at runlevel 3, startx does not launch a display manager or authenticate users. See Section C.5.2, "Runlevel 5" for more information about display managers. When the startx command is executed, it searches for the .xinitrc file in the user's home directory to define the desktop environment and possibly other X client applications to run. If no .xinitrc file is present, it uses the system default /etc/X11/xinit/xinitrc file instead. The default xinitrc script then searches for user-defined files and default system files, including .Xresources , .Xmodmap , and .Xkbmap in the user's home directory, and Xresources , Xmodmap , and Xkbmap in the /etc/X11/ directory. The Xmodmap and Xkbmap files, if they exist, are used by the xmodmap utility to configure the keyboard. The Xresources file is read to assign specific preference values to applications. After setting the above options, the xinitrc script executes all scripts located in the /etc/X11/xinit/xinitrc.d/ directory. One important script in this directory is xinput.sh , which configures settings such as the default language. The xinitrc script attempts to execute .Xclients in the user's home directory and turns to /etc/X11/xinit/Xclients if it cannot be found. The purpose of the Xclients file is to start the desktop environment or, possibly, just a basic window manager. The .Xclients script in the user's home directory starts the user-specified desktop environment in the .Xclients-default file. If .Xclients does not exist in the user's home directory, the standard /etc/X11/xinit/Xclients script attempts to start another desktop environment, trying GNOME first, then KDE, followed by twm . When in runlevel 3, the user is returned to a text mode user session after ending an X session.

Commands:
Chapter 1. Red Hat Virtualization Architecture Red Hat Virtualization can be deployed as a self-hosted engine, or as a standalone Manager. A self-hosted engine is the recommended deployment option. 1.1. Self-Hosted Engine Architecture The Red Hat Virtualization Manager runs as a virtual machine on self-hosted engine nodes (specialized hosts) in the same environment it manages. A self-hosted engine environment requires one less physical server, but requires more administrative overhead to deploy and manage. The Manager is highly available without external HA management. The minimum setup of a self-hosted engine environment includes: One Red Hat Virtualization Manager virtual machine that is hosted on the self-hosted engine nodes. The RHV-M Appliance is used to automate the installation of a Red Hat Enterprise Linux 7 virtual machine, and the Manager on that virtual machine. A minimum of two self-hosted engine nodes for virtual machine high availability. You can use Red Hat Enterprise Linux hosts or Red Hat Virtualization Hosts (RHVH). VDSM (the host agent) runs on all hosts to facilitate communication with the Red Hat Virtualization Manager. The HA services run on all self-hosted engine nodes to manage the high availability of the Manager virtual machine. One storage service, which can be hosted locally or on a remote server, depending on the storage type used. The storage service must be accessible to all hosts. Figure 1.1. Self-Hosted Engine Red Hat Virtualization Architecture 1.2. Standalone Manager Architecture The Red Hat Virtualization Manager runs on a physical server, or a virtual machine hosted in a separate virtualization environment. A standalone Manager is easier to deploy and manage, but requires an additional physical server. The Manager is only highly available when managed externally with a product such as Red Hat's High Availability Add-On. The minimum setup for a standalone Manager environment includes: One Red Hat Virtualization Manager machine. The Manager is typically deployed on a physical server. However, it can also be deployed on a virtual machine, as long as that virtual machine is hosted in a separate environment. The Manager must run on Red Hat Enterprise Linux 7. A minimum of two hosts for virtual machine high availability. You can use Red Hat Enterprise Linux hosts or Red Hat Virtualization Hosts (RHVH). VDSM (the host agent) runs on all hosts to facilitate communication with the Red Hat Virtualization Manager. One storage service, which can be hosted locally or on a remote server, depending on the storage type used. The storage service must be accessible to all hosts. Figure 1.2. Standalone Manager Red Hat Virtualization Architecture

Commands:
5.9.4. Archiving Files with tar The tar utility does not retain extended attributes by default. Since SELinux contexts are stored in extended attributes, contexts can be lost when archiving files. Use the tar --selinux command to create archives that retain contexts and to restore files from the archives. If a tar archive contains files without extended attributes, or if you want the extended attributes to match the system defaults, use the restorecon utility: Note that depending on the directory, you may need to be the root user to run the restorecon . The following example demonstrates creating a tar archive that retains SELinux contexts: Procedure 5.10. Creating a tar Archive Change to the /var/www/html/ directory and view its SELinux context: As root, create three files ( file1 , file2 , and file3 ) in /var/www/html/ . These files inherit the httpd_sys_content_t type from /var/www/html/ : As root, run the following command to create a tar archive named test.tar . Use the --selinux to retain the SELinux context: As root, create a new directory named /test/ , and then allow all users full access to it: Copy the test.tar file into /test/ : Change into /test/ directory. Once in this directory, run the following command to extract the tar archive. Specify the --selinux option again otherwise the SELinux context will be changed to default_t : View the SELinux contexts. The httpd_sys_content_t type has been retained, rather than being changed to default_t , which would have happened had the --selinux not been used: If the /test/ directory is no longer required, as root, run the following command to remove it, as well as all files in it: See the tar (1) manual page for further information about tar , such as the --xattrs option that retains all extended attributes.

Commands:
~]USD tar -xvf archive.tar | restorecon -f -
~]USD cd /var/www/html/
html]USD ls -dZ /var/www/html/ drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 .
html]# touch file{1,2,3}
html]USD ls -Z /var/www/html/ -rw-r--r-- root root unconfined_u:object_r:httpd_sys_content_t:s0 file1 -rw-r--r-- root root unconfined_u:object_r:httpd_sys_content_t:s0 file2 -rw-r--r-- root root unconfined_u:object_r:httpd_sys_content_t:s0 file3
html]# tar --selinux -cf test.tar file{1,2,3}
~]# mkdir /test
~]# chmod 777 /test/
~]USD cp /var/www/html/test.tar /test/
~]USD cd /test/
test]USD tar --selinux -xvf test.tar
test]USD ls -lZ /test/ -rw-r--r-- user1 group1 unconfined_u:object_r:httpd_sys_content_t:s0 file1 -rw-r--r-- user1 group1 unconfined_u:object_r:httpd_sys_content_t:s0 file2 -rw-r--r-- user1 group1 unconfined_u:object_r:httpd_sys_content_t:s0 file3 -rw-r--r-- user1 group1 unconfined_u:object_r:default_t:s0 test.tar
~]# rm -ri /test/
20.7. Additional Resources For more information about SSH, refer to the following resources. 20.7.1. Installed Documentation The /usr/share/doc/openssh- <version-number> / directory - Replace <version-number> with the installed version of the OpenSSH package. This directory contains a README with basic information about the OpenSSH project and a file called RFC.nroff with general information about the SSH protocol. SSH related man pages - There are a number of man pages for the various applications and configuration files involved with SSH. The following is a list of some of the more important man pages. Client Applications man ssh - Describes how to use this command to connect to an SSH server. man scp - Describes how to use this command to copy files to and from an SSH server. man sftp - Describes how to use this command to interactively copy files to and from and SSH server. Server Applications man sshd - Describes available command line options for the SSH server. Configuration Files man ssh_config - Describes the format and options available within the configuration file for SSH clients. man sshd_config - Describes the format and options available within the configuration file for the SSH server.

Commands:
Providing feedback on Red Hat documentation You can provide feedback or report an error by creating a Jira issue for the HCIDOCS project, where you can track the progress of your feedback. You must have a Red Hat Jira account and be logged in. Launch the Create Issue form. Complete the Summary , Description , and Reporter fields. In the Description field, include the documentation URL, chapter or section number, and a detailed description of the issue. Click Create .

Commands:
10.6. FS-Cache References For more information on cachefilesd and how to configure it, see man cachefilesd and man cachefilesd.conf . The following kernel documents also provide additional information: /usr/share/doc/cachefilesd- version-number /README /usr/share/man/man5/cachefilesd.conf.5.gz /usr/share/man/man8/cachefilesd.8.gz For general information about FS-Cache, including details on its design constraints, available statistics, and capabilities, see the following kernel document: /usr/share/doc/kernel-doc- version /Documentation/filesystems/caching/fscache.txt

Commands:
10.3. Booleans SELinux is based on the least level of access required for a service to run. Services can be run in a variety of ways; therefore, you need to specify how you run your services. Use the following Booleans to set up SELinux: allow_user_postgresql_connect Having this Boolean enabled allows any user domain (as defined by PostgreSQL) to make connections to the database server. postgresql_can_rsync When enabled, this Boolean allows PostgreSQL to use the SSH protocol and the rsync utility. Note Due to the continuous development of the SELinux policy, the list above might not contain all Booleans related to the service at all times. To list them, run the following command as root:

Commands:
~]# semanage boolean -l | grep service_name
8.139. mipv6-daemon 8.139.1. RHBA-2014:1571 - mipv6-daemon bug fix and enhancement update Updated mipv6-daemon packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The mipv6-daemon packages contain a mobile IPv6 service for clients, which allows them to relocate within an IPv6-enabled network yet remain reachable. This update also fixes the following bug: Note The mipv6-daemon packages have been upgraded to upstream version 1.0, which provides a number of bug fixes and enhancements over the version. (BZ# 804124 ) This update also fixes the following bug: Bug Fix BZ# 804124 Previously, the mip6d daemon wrote debugging log messages to the stderr output stream, especially during process termination. However, due to a bug in the code, mip6d wrote random data into the netlink socket instead of stderr. These netlink messages were rejected by the kernel and caused SELinux warnings about invalid netlink messages. This update fixes this bug and the described situation no longer occurs. The mipv6-daemon packages have been upgraded to upstream version 1.0, which provides a number of bug fixes and enhancements over the version. (BZ#804124) Users of mipv6-daemon are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
5.222. openssl 5.222.1. RHBA-2012:1195 - openssl bug fix update Updated openssl packages that fix a bug are now available for Red Hat Enterprise Linux 6. OpenSSL is a toolkit that implements the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols, as well as a full-strength general-purpose cryptography library. Bug Fix BZ# 848406 When a save operation of a private key file in the encrypted format was attempted in FIPS mode, the resulting file was corrupted because the PEM encryption uses hash algorithms that are not available in FIPS mode. With this update, the PKCS#8 encrypted format is used to write private keys to files in FIPS mode. This file format does not use algorithms unavailable in FIPS mode, thus preventing this bug. All users of OpenSSL should upgrade to these updated packages, which fix this bug.

Commands:
Appendix C. 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
17.7. Distributed Execution Example In this example, parallel distributed execution is used to approximate the value of Pi (p) As shown below, the area of a square is: Area of a Square (S) = 4r 2 The following is an equation for the area of a circle: Area of a Circle (C) = p x r 2 Isolate r 2 from the first equation: r 2 = S/4 Inject this value of r 2 into the second equation to find a value for Pi: C = Sp/4 Isolating p in the equation results in: C = Sp/4 4C = Sp 4C/S = p Figure 17.1. Distributed Execution Example If we now throw a large number of darts into the square, then draw a circle inside the square, and discard all dart throws that landed outside the circle, we can approximate the C/S value. The value of p is previously worked out to 4C/S. We can use this to derive the approximate value of p. By maximizing the amount of darts thrown, we can derive an improved approximation of p. In the following example, we throw 10 million darts by parallelizing the dart tossing across the cluster: Example 17.6. Distributed Execution Example Report a bug

Commands:
public class PiAppx { public static void main (String [] arg){ List<Cache> caches = ...; Cache cache = ...; int numPoints = 10000000; int numServers = caches.size(); int numberPerWorker = numPoints / numServers; DistributedExecutorService des = new DefaultExecutorService(cache); long start = System.currentTimeMillis(); CircleTest ct = new CircleTest(numberPerWorker); List<Future<Integer>> results = des.submitEverywhere(ct); int countCircle = 0; for (Future<Integer> f : results) { countCircle += f.get(); } double appxPi = 4.0 * countCircle / numPoints; System.out.println("Distributed PI appx is " + appxPi + " completed in " + (System.currentTimeMillis() - start) + " ms"); } private static class CircleTest implements Callable<Integer>, Serializable { /** The serialVersionUID */ private static final long serialVersionUID = 3496135215525904755L; private final int loopCount; public CircleTest(int loopCount) { this.loopCount = loopCount; } @Override public Integer call() throws Exception { int insideCircleCount = 0; for (int i = 0; i < loopCount; i++) { double x = Math.random(); double y = Math.random(); if (insideCircle(x, y)) insideCircleCount++; } return insideCircleCount; } private boolean insideCircle(double x, double y) { return (Math.pow(x - 0.5, 2) + Math.pow(y - 0.5, 2)) <= Math.pow(0.5, 2); } } }
Chapter 1. Supported upgrade paths The in-place upgrade replaces the RHEL 7 operating system (OS) on your system with a RHEL 8 version. Currently, it is possible to perform an in-place upgrade from RHEL 7 to the following target RHEL 8 minor versions: Table 1.1. Supported upgrade paths System configuration Source OS version Target OS version RHEL RHEL 7.9 RHEL 8.8 RHEL 8.10 (default) RHEL with SAP HANA RHEL 7.9 RHEL 8.8 (default) RHEL 8.10 For more information about supported upgrade paths, see Supported in-place upgrade paths for Red Hat Enterprise Linux and the In-place upgrade Support Policy .

Commands:
Chapter 2. New features and enhancements 2.1. Exposed URL parameters on the 'Git Repo Options' panel on the User Dashboard Git branch, remotes, and path to devfile URL parameters are now exposed on the 'Git Repo Options' panel of the User Dashboard. Additional resources CRW-6527 2.2. Support raw devfile URLs without yaml extension Starting from this release, you can create workspaces from any URL that serves a valid devfile , such as in the following cases: https://registry.devfile.io/devfiles/ollama/1.0.0 https://registry.devfile.io/devfiles/dotnet60/1.0.3 Additional resources CRW-6528 2.3. Add initContainer for initializing persistentHome when USDHOME persistence is enabled With this release, if you have USDHOME persistence enabled, there is an initContainer that runs the entrypoint script and initializes persistentHome. This prevents a race condition from occurring. Previously, the persistent user home setup occurred in the entrypoint of the tooling container. Notably, the entrypoint was used to run stow to make symbolic links for the home directory to be saved on the PVC. If a postStart event depends on files or edits files located in the home directory, there is a risk of a race condition caused by the post-start event running before the stow execution is finished. To prevent this, the entrypoint script must be completed before the postStart events run. You can find more details about this enhancement in the demo video . Additional resources CRW-6529

Commands:
5.3. Load Balancing Policy: VM_Evenly_Distributed A virtual machine evenly distributed load balancing policy distributes virtual machines evenly between hosts based on a count of the virtual machines. The high virtual machine count is the maximum number of virtual machines that can run on each host, beyond which qualifies as overloading the host. The VM_Evenly_Distributed policy allows an administrator to set a high virtual machine count for hosts. The maximum inclusive difference in virtual machine count between the most highly-utilized host and the least-utilized host is also set by an administrator. The cluster is balanced when every host in the cluster has a virtual machine count that falls inside this migration threshold. The administrator also sets the number of slots for virtual machines to be reserved on SPM hosts. The SPM host will have a lower load than other hosts, so this variable defines how many fewer virtual machines than other hosts it can run. If any host is running more virtual machines than the high virtual machine count and at least one host has a virtual machine count that falls outside of the migration threshold, virtual machines are migrated one by one to the host in the cluster that has the lowest CPU utilization. One virtual machine is migrated at a time until every host in the cluster has a virtual machine count that falls within the migration threshold.

Commands:
2.2. Installation Method Figure 2.2. Installation Method The Installation Method screen allows you to choose whether to perform a new installation or an upgrade. If you choose upgrade, the Partition Information and Package Selection options are disabled. They are not supported for kickstart upgrades. Choose the type of kickstart installation or upgrade screen from the following options: CD-ROM - Choose this option to install or upgrade from the Red Hat Enterprise Linux CD-ROMs. NFS - Choose this option to install or upgrade from an NFS shared directory. In the text field for the the NFS server, enter a fully-qualified domain name or IP address. For the NFS directory, enter the name of the NFS directory that contains the RedHat directory of the installation tree. For example, if the NFS server contains the directory /mirrors/redhat/i386/RedHat/ , enter /mirrors/redhat/i386/ for the NFS directory. FTP - Choose this option to install or upgrade from an FTP server. In the FTP server text field, enter a fully-qualified domain name or IP address. For the FTP directory, enter the name of the FTP directory that contains the RedHat directory. For example, if the FTP server contains the directory /mirrors/redhat/i386/RedHat/ , enter /mirrors/redhat/i386/ for the FTP directory. If the FTP server requires a username and password, specify them as well. HTTP - Choose this option to install or upgrade from an HTTP server. In the text field for the HTTP server, enter the fully-qualified domain name or IP address. For the HTTP directory, enter the name of the HTTP directory that contains the RedHat directory. For example, if the HTTP server contains the directory /mirrors/redhat/i386/RedHat/ , enter /mirrors/redhat/i386/ for the HTTP directory. Hard Drive - Choose this option to install or upgrade from a hard drive. Hard drive installations require the use of ISO (or CD-ROM) images. Be sure to verify that the ISO images are intact before you start the installation. To verify them, use an md5sum program as well as the linux mediacheck boot option as discussed in the Installation Guide . Enter the hard drive partition that contains the ISO images (for example, /dev/hda1 ) in the Hard Drive Partition text box. Enter the directory that contains the ISO images in the Hard Drive Directory text box.

Commands:
2.6. File System Backups It is important to make regular backups of your GFS2 file system in case of emergency, regardless of the size of your file system. Many system administrators feel safe because they are protected by RAID, multipath, mirroring, snapshots, and other forms of redundancy, but there is no such thing as safe enough. It can be a problem to create a backup since the process of backing up a node or set of nodes usually involves reading the entire file system in sequence. If this is done from a single node, that node will retain all the information in cache until other nodes in the cluster start requesting locks. Running this type of backup program while the cluster is in operation will negatively impact performance. Dropping the caches once the backup is complete reduces the time required by other nodes to regain ownership of their cluster locks/caches. This is still not ideal, however, because the other nodes will have stopped caching the data that they were caching before the backup process began. You can drop caches using the following command after the backup is complete: It is faster if each node in the cluster backs up its own files so that the task is split between the nodes. You might be able to accomplish this with a script that uses the rsync command on node-specific directories. Red Hat recommends making a GFS2 backup by creating a hardware snapshot on the SAN, presenting the snapshot to another system, and backing it up there. The backup system should mount the snapshot with -o lockproto=lock_nolock since it will not be in a cluster.

Commands:
echo -n 3 > /proc/sys/vm/drop_caches