mtpti5iD/redhat-docs_dataset huggingface dataset:
5.2.3. /proc/cmdline This file shows the parameters passed to the kernel at the time it is started. A sample /proc/cmdline file looks like the following: This tells us that the kernel is mounted read-only (signified by (ro) ), located on the first logical volume ( LogVol00 ) of the first volume group ( /dev/VolGroup00 ). LogVol00 is the equivalent of a disk partition in a non-LVM system (Logical Volume Management), just as /dev/VolGroup00 is similar in concept to /dev/hda1 , but much more extensible. For more information on LVM used in Red Hat Enterprise Linux, refer to http://www.tldp.org/HOWTO/LVM-HOWTO/index.html . , rhgb signals that the rhgb package has been installed, and graphical booting is supported, assuming /etc/inittab shows a default runlevel set to id:5:initdefault: . Finally, quiet indicates all verbose kernel messages are suppressed at boot time.

Commands:
ro root=/dev/VolGroup00/LogVol00 rhgb quiet 3
5.340. unixODBC 5.340.1. RHBA-2012:1509 - unixODBC bug fix update Updated unixODBC packages that fix one bug are now available for Red Hat Enterprise Linux 6. The unixODBC packages contain a framework that supports accessing databases through the ODBC protocol. Bug Fix BZ# 876488 When the isql utility was running in batch mode, which was activated by the "-b" command-line option, isql terminated unexpectedly with a segmentation fault upon receiving any SQL query. This bug has been fixed and isql no longer crashes in the described scenario. All users of unixODBC are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 2. Resource Monitoring As stated earlier, a great deal of system administration revolves around resources and their efficient use. By balancing various resources against the people and programs that use those resources, you waste less money and make your users as happy as possible. However, this leaves two questions: What are resources? And: How is it possible to know what resources are being used (and to what extent)? The purpose of this chapter is to enable you to answer these questions by helping you to learn more about resources and how they can be monitored. 2.1. Basic Concepts Before you can monitor resources, you first have to know what resources there are to monitor. All systems have the following resources available: CPU power Bandwidth Memory Storage These resources are covered in more depth in the following chapters. However, for the time being all you need to keep in mind is that these resources have a direct impact on system performance, and therefore, on your users' productivity and happiness. At its simplest, resource monitoring is nothing more than obtaining information concerning the utilization of one or more system resources. However, it is rarely this simple. First, one must take into account the resources to be monitored. Then it is necessary to examine each system to be monitored, paying particular attention to each system's situation. The systems you monitor fall into one of two categories: The system is currently experiencing performance problems at least part of the time and you would like to improve its performance. The system is currently running well and you would like it to stay that way. The first category means you should monitor resources from a system performance perspective, while the second category means you should monitor system resources from a capacity planning perspective. Because each perspective has its own unique requirements, the following sections explore each category in more depth.

Commands:
Chapter 2. Console monitoring and alerting Red Hat Quay provides support for monitoring instances that were deployed by using the Red Hat Quay Operator, from inside the OpenShift Container Platform console. The new monitoring features include a Grafana dashboard, access to individual metrics, and alerting to notify for frequently restarting Quay pods. Note To enable the monitoring features, the Red Hat Quay Operator must be installed in All Namespaces mode. 2.1. Dashboard On the OpenShift Container Platform console, click Monitoring Dashboards and search for the dashboard of your desired Red Hat Quay registry instance: The dashboard shows various statistics including the following: The number of Organizations , Repositories , Users , and Robot accounts CPU Usage Max memory usage Rates of pulls and pushes, and authentication requests API request rate Latencies 2.2. Metrics You can see the underlying metrics behind the Red Hat Quay dashboard by accessing Monitoring Metrics in the UI. In the Expression field, enter the text quay_ to see the list of metrics available: Select a sample metric, for example, quay_org_rows : This metric shows the number of organizations in the registry. It is also directly surfaced in the dashboard. 2.3. Alerting An alert is raised if the Quay pods restart too often. The alert can be configured by accessing the Alerting rules tab from Monitoring Alerting in the console UI and searching for the Quay-specific alert: Select the QuayPodFrequentlyRestarting rule detail to configure the alert:

Commands:
Migrating Fuse 7 Applications to Red Hat build of Apache Camel for Quarkus Red Hat build of Apache Camel 4.4 Migrating Fuse 7 Applications to Red Hat build of Apache Camel for Quarkus Red Hat build of Apache Camel Documentation Team fuse-docs-support@redhat.com Red Hat build of Apache Camel Support Team http://access.redhat.com/support

Commands:
27.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: gluster_export_all_ro Having this Boolean enabled allows glusterfsd to share files and directory as read-only. This Boolean is disabled by default. gluster_export_all_rw Having this Boolean enabled allows glusterfsd to share files and directories with read and write access. This Boolean is enabled by default. gluster_anon_write Having this Boolean enabled allows glusterfsd to modify public files labeled with the public_content_rw_t SELinux type. 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, enter the following command: Enter the following command to view description of a particular Boolean: Note that the additional policycoreutils-devel package providing the sepolicy utility is required for this command to work.

Commands:
~]USD getsebool -a | grep service_name
~]USD sepolicy booleans -b boolean_name
Chapter 1. Overview The Storage Administration Guide contains extensive information on supported file systems and data storage features in Red Hat Enterprise Linux 7. This book is intended as a quick reference for administrators managing single-node (that is, non-clustered) storage solutions. The Storage Administration Guide is split into the following parts: File Systems, Storage Administration, and Data Deduplication and Compression with VDO. The File Systems part details the various file systems Red Hat Enterprise Linux 7 supports. It describes them and explains how best to utilize them. The Storage Administration part details the various tools and storage administration tasks Red Hat Enterprise Linux 7 supports. It describes them and explains how best to utilize them. The Data Deduplication and Compression with VDO part describes the Virtual Data Optimizer (VDO). It explains how to use VDO to reduce your storage requirements. 1.1. New Features and Enhancements in Red Hat Enterprise Linux 7 Red Hat Enterprise Linux 7 features the following file system enhancements: eCryptfs not included As of Red Hat Enterprise Linux 7, eCryptfs is not included. For more information on encrypting file systems, see Red Hat's Security Guide. System Storage Manager Red Hat Enterprise Linux 7 includes a new application called System Storage Manager which provides a command-line interface to manage various storage technologies. For more information, see Chapter 16, System Storage Manager (SSM) . XFS Is the Default File System As of Red Hat Enterprise Linux 7, XFS is the default file system. For more information about the XFS file system, see Chapter 3, The XFS File System . File System Restructure Red Hat Enterprise Linux 7 introduces a new file system structure. The directories /bin , /sbin , /lib , and /lib64 are now nested under /usr . Snapper Red Hat Enterprise Linux 7 introduces a new tool called Snapper that allows for the easy creation and management of snapshots for LVM and Btrfs. For more information, see Chapter 14, Creating and Maintaining Snapshots with Snapper . Btrfs (Technology Preview) Note Btrfs is available as a Technology Preview feature in Red Hat Enterprise Linux 7 but has been deprecated since the Red Hat Enterprise Linux 7.4 release. It will be removed in a future major release of Red Hat Enterprise Linux. For more information, see Deprecated Functionality in the Red Hat Enterprise Linux 7.4 Release Notes. Btrfs is a local file system that aims to provide better performance and scalability, including integrated LVM operations. This file system is not fully supported by Red Hat and as such is a technology preview. For more information on Btrfs, see Chapter 6, Btrfs (Technology Preview) . NFSv2 No Longer Supported As of Red Hat Enterprise Linux 7, NFSv2 is no longer supported.

Commands:
6.2. Managing High-Availability Services You can manage cluster services with the Cluster Status Tool ( Figure 6.1, " Cluster Status Tool " ) through the Cluster Management tab in Cluster Administration GUI. Figure 6.1. Cluster Status Tool You can use the Cluster Status Tool to enable, disable, restart, or relocate a high-availability service. The Cluster Status Tool displays the current cluster status in the Services area and automatically updates the status every 10 seconds. To enable a service, you can select the service in the Services area and click Enable . To disable a service, you can select the service in the Services area and click Disable . To restart a service, you can select the service in the Services area and click Restart . To relocate a service from one node to another, you can drag the service to another node and drop the service onto that node. Relocating a service restarts the service on that node. (Relocating a service to its current node - that is, dragging a service to its current node and dropping the service onto that node - restarts the service.) The following tables describe the members and services status information displayed by the Cluster Status Tool . Table 6.1. Members Status Members Status Description Member The node is part of the cluster. Note: A node can be a member of a cluster; however, the node may be inactive and incapable of running services. For example, if rgmanager is not running on the node, but all other cluster software components are running in the node, the node appears as a Member in the Cluster Status Tool . Dead The node is unable to participate as a cluster member. The most basic cluster software is not running on the node. Table 6.2. Services Status Services Status Description Started The service resources are configured and available on the cluster system that owns the service. Pending The service has failed on a member and is pending start on another member. Disabled The service has been disabled, and does not have an assigned owner. A disabled service is never restarted automatically by the cluster. Stopped The service is not running; it is waiting for a member capable of starting the service. A service remains in the stopped state if autostart is disabled. Failed The service has failed to start on the cluster and cannot successfully stop the service. A failed service is never restarted automatically by the cluster.

Commands:
29.4. Scenario 2: Migrating an LDAP Server Directly to Identity Management Important This is a general migration procedure, but it may not work in every environment. It is strongly recommended that you set up a test LDAP environment and test the migration process before attempting to migrate the real LDAP environment. Install the IdM server, including any custom LDAP directory schema [12] , on a different machine from the existing LDAP directory. Disable the compat plug-in. Restart the IdM Directory Server instance. Enable the IdM server to allow migration: Run the IdM migration script, ipa migrate-ds . At its most basic, this requires only the LDAP URL of the LDAP directory instance to migrate: Simply passing the LDAP URL migrates all of the directory data using common default settings. The user and group data can be selectively migrated by specifying other options, as covered in Section 29.2, "Examples for Using migrate-ds" . Once the information is exported, the script adds all required IdM object classes and attributes and converts DNs in attributes to match the IdM directory tree. Re-enable the compat plug-in. Restart the IdM Directory Server instance. Update the client configuration to use PAM_LDAP and NSS_LDAP to connect to IdM instead of connecting to an LDAP directory, NIS, or local files. Optional. Set up SSSD. Using SSSD migrates user passwords without additional user interaction, as described in Section 29.1.2, "Planning Password Migration" . Install SSSD on every client machine: Run the ipa-client-install to configure SSSD and related services to use the IdM server for identity and Kerberos authentication. Instruct users to log into IdM using either SSSD client or the migration web page if SSSD is not available on the client. Both methods automatically migrate the user password into Identity Management. Optional. Reconfigure non-SSSD clients to use Kerberos authentication ( pam_krb5 ) instead of LDAP authentication ( pam_ldap ). Note Use PAM_LDAP modules until all of the users have been migrated; then it is possible to use PAM_KRB5. When the migration of all clients and users is complete, decommission the LDAP directory. [12] There is limited support for custom user and group schema in Identity Management.

Commands:
ipa-compat-manage disable
service dirsrv restart
ipa config-mod --enable-migration=TRUE
ipa migrate-ds ldap://ldap.example.com:389
ipa-compat-manage enable
service dirsrv restart
yum install sssd
https://ipaserver.example.com/ipa/migration
Chapter 1. Overview of the sidecar container Cryostat supports sidecar containers, so you can use a sidecar container to generate automated analysis reports. Before Cryostat 2.3, you had to rely on the main Cryostat container to generate automated analysis reports. This approach is resource intensive and could impact the performance of running your Cryostat application because you might need to provision additional resources for the main Cryostat container. By generating automated analysis reports in the sidecar report container, you can efficiently use the Red Hat build of Cryostat Operator to provision resources for your Cryostat application. This provides your Cryostat container with a lower resource footprint, because the Cryostat instance that interacts with the target applications can focus on running low-overhead operations over HTTP and JMX connections. Additionally, you can duplicate a sidecar report container and then configure this duplicated container to meet your needs.

Commands:
Providing feedback on Red Hat JBoss Core Services documentation To report an error or to improve our documentation, log in to your Red Hat Jira account and submit an issue. If you do not have a Red Hat Jira account, then you will be prompted to create an account. Procedure Click the following link to create a ticket . Enter a brief description of the issue in the Summary . Provide a detailed description of the issue or enhancement in the Description . Include a URL to where the issue occurs in the documentation. Clicking Create creates and routes the issue to the appropriate documentation team.

Commands:
2.2. Batching and the Java Transaction API (JTA) In Red Hat JBoss Data Grid, the batching functionality initiates a JTA transaction in the back end, causing all invocations within the scope to be associated with it. For this purpose, the batching functionality uses a simple Transaction Manager implementation at the back end. As a result, the following behavior is observed: Locks acquired during an invocation are retained until the transaction commits or rolls back. All changes are replicated in a batch on all nodes in the cluster as part of the transaction commit process. Ensuring that multiple changes occur within the single transaction, the replication traffic remains lower and improves performance. When using synchronous replication or invalidation, a replication or invalidation failure causes the transaction to roll back. When a cache is transactional and a cache loader is present, the cache loader is not enlisted in the cache's transaction. This results in potential inconsistencies at the cache loader level when the transaction applies the in-memory state but (partially) fails to apply the changes to the store. All configurations related to a transaction apply for batching as well. Example 2.1. Configuring a Transaction that Applies for Batching The configuration attributes can be used for both transactions and batching, using different values. Note Batching functionality and JTA transactions are only supported in JBoss Data Grid's Library Mode. Report a bug

Commands:
<transaction syncRollbackPhase="false" syncCommitPhase="false" useEagerLocking="true" eagerLockSingleNode="true" />
4.26. chkconfig 4.26.1. RHBA-2012:0415 - chkconfig bug fix update Updated chkconfig packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The basic system utility chkconfig updates and queries runlevel information for system services. Bug Fixes BZ# 797847 When installing multiple Linux Standard Base (LSB) services which only had LSB headers, the stop priority of the related LSB init scripts could have been miscalculated and set to "-1". With this update, the LSB init script ordering mechanism has been fixed, and the stop priority of the LSB init scripts is now set correctly. BZ# 797846 When an LSB init script requiring the "USDlocal_fs" facility was installed with the "install_initd" command, the installation of the script could fail under certain circumstances. With this update, the underlying code has been modified to ignore this requirement because the "USDlocal_fs" facility is always implicitly provided. LSB init scripts with requirements on "USDlocal_fs" are now installed correctly. All users of chkconfig are advised to upgrade to these updated packages, which fix these bugs.

Commands:
27.2.4. Configuring a Batch Job The Batch application executes the defined one-time tasks when the system load average decreases below 0.8. To define a Batch job, do the following: On the command line, type the command batch . In the displayed at> prompt, define the job commands: Type the command the job should execute and press Enter . Optionally, repeat the step to provide multiple commands. Enter a shell script at the prompt and press Enter after each line in the script. If a script is entered, the job uses the shell set in the user's SHELL environment, the user's login shell, or /bin/sh (whichever is found first). Once finished, press Ctrl + D on an empty line to exit the prompt. If the set of commands or the script tries to display information to standard output, the output is emailed to the user. To view the list of pending jobs, use the atq command. See Section 27.2.5, "Viewing Pending Jobs" for more information. You can also restrict the usage of the batch command. For more information, see Section 27.2.7, "Controlling Access to At and Batch" for details.

Commands:
Appendix A. Updating the Local Repository for an Offline Red Hat Virtualization Manager Installation If your Red Hat Virtualization Manager is hosted on a machine that receives packages via FTP from a local repository, you must regularly synchronize the repository to download package updates from the Content Delivery Network, then update or upgrade that machine. Updated packages address security issues, fix bugs, and add enhancements. On the system hosting the repository, synchronize the repository to download the most recent version of each available package: # reposync --newest-only /var/ftp/pub/rhevrepo This command might download a large number of packages, and take a long time to complete. Ensure that the repository is available on the Manager machine, and then update or upgrade the machine.

Commands:
reposync --newest-only /var/ftp/pub/rhevrepo
8.242. xorg-x11-drv-synaptics 8.242.1. RHBA-2013:1644 - xorg-x11-drv-synaptics bug fix update Updated xorg-x11-drv-synaptics packages that fix one bug are now available for Red Hat Enterprise Linux 6. The xorg-x11-drv-synaptics packages contain the X.Org X11 input drivers for Synaptics touchpads. Bug Fix BZ# 988174 Previously, the synaptics driver scaled input coordinates based on the device resolution. Consequently, the X server could not apply the uniform resolution-based scaling for other devices in relative mode. The synaptics driver has been fixed to apply the scaling feature only if the X server does not support the per-device resolution scaling. Users of xorg-x11-drv-synaptics are advised to upgrade to these updated packages, which fix this bug.

Commands:
B.51.3. RHBA-2010:0849 - lvm2 bug fix update Updated lvm2 packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The lvm2 packages contain support for Logical Volume Management (LVM). Bug Fixes BZ# 641461 This update avoids data corruption caused by a failure to detect that a filesystem being resized with 'fsadm' (or lvresize/lvreduce --resizefs) is mounted. The update also fixes various other problems in 'fsadm' including incorrect handling of user's break action, inconsistent processing of the '--dry-run' option, missing support for correctly passing the '--yes' option, and incorrect handling of the 'LVM_BINARY' environment variable. BZ# 641812 Under some circumstances, creating cluster mirrors with the '--nosync' option could cause I/O to become extremely slow. Note that this issue only effected I/O immediately after the creation of the mirror, and only when '--nosync' was used. With this update, I/O no longer runs slow in the aforementioned case. BZ# 641896 Previously, the limit for tags section in metadata was 4096 characters. When this limit was exceeded, the VG metadata were corrupted. With this update, the limitation has been removed and the limit is given by metadata size only. BZ# 648554 Previously, a limit for maximum output length in reporting functions (vgs, lvs) caused problems while using a large set of tags. With this update, the output lines in these reports are now limited by available memory only. All users of lvm2 are advised to upgrade to these updated packages, which fix these bugs.

Commands: