mtpti5iD/redhat-docs_dataset huggingface dataset:
18.3. ACI Structure The aci attribute uses the following syntax: target_rule specifies the entry, attributes, or set of entries and attributes for which to control access. For details, see Section 18.9, "Defining Targets" . version 3.0 is a required string which identifies the ACI version. aci " ACL_name " sets a name or string that describes the ACI. permission_rule sets what rights, such as read or write , are allowed or denied. For details, see Section 18.10, "Defining Permissions" . bind_rules specifies which rules must match during the bind to allow or deny access. For details, see Section 18.11, "Defining Bind Rules" . Note The permission and the bind rule pair are called an access control rule. To efficiently set multiple access controls for a given target, you can set multiple access control rules for each target:

Commands:
( target_rule ) (version 3.0; acl " ACL_name "; permission_rule bind_rules ;)
( target_rule )(version 3.0; acl " ACL_name "; permission_rule bind_rules ; permission_rule bind_rules ; ... ;)
1.3.3. Tell Your Users What You Have Done After you have finished making the changes, you must tell your users what you have done. Again, this should be a summary of the messages (invariably someone will not have read them.) [1] However, there is one important addition you must make. It is vital that you give your users the current status. Did the upgrade not go as smoothly as planned? Was the new storage server only able to serve the systems in Engineering, and not in Finance? These types of issues must be addressed here. Of course, if the current status differs from what you communicated previously, you should make this point clear and describe what will be done (if anything) to arrive at the final solution. In our hypothetical situation, the downtime had some problems. The new CPU module did not work; a call to the system's manufacturer revealed that a special version of the module is required for in-the-field upgrades. On the plus side, the migration of the database to the RAID volume went well (even though it took a bit longer than planned due to the problems with the CPU module. Here is one possible announcement: System Downtime Complete The system downtime scheduled for Friday night (refer to the System Administration page on the company intranet website) has been completed. Unfortunately, hardware issues prevented one of the tasks from being completed. Due to this, the remaining tasks took longer than the originally-scheduled four hours. Instead, all systems were back in production by midnight (6am Saturday for the Berlin office). Because of the remaining hardware issues, performance of the AP, AR, and the Balance Sheet report will be slightly improved, but not to the extent originally planned. A second downtime will be announced and scheduled as soon as the issues that prevented completion of the task have been resolved. Please note that the downtime did change some database indices; people that have written their own SQL queries should consult the Finance page on the company intranet website. Please contact System Administration at extension 4321 with any questions. With this kind of information, your users will have sufficient background knowledge to continue their work, and to understand how the changes impact them. [1] Be sure to send this message out as soon as the work is done, before you leave for home. Once you have left the office, it is much too easy to forget, leaving your users in the dark as to whether they can use the system or not.

Commands:
1.11.3. Related Books Most books on system administration do little to cover the philosophy behind the job. However, the following books do have sections that give a bit more depth to the issues that were discussed here: The Reference Guide ; Red Hat, Inc -- Provides an overview of locations of key system files, user and group settings, and PAM configuration. The Security Guide ; Red Hat, Inc -- Contains a comprehensive discussion of many security-related issues for Red Hat Enterprise Linux system administrators. The System Administrators Guide ; Red Hat, Inc -- Includes chapters on managing users and groups, automating tasks, and managing log files. Linux Administration Handbook by Evi Nemeth, Garth Snyder, and Trent R. Hein; Prentice Hall -- Provides a good section on the policies and politics side of system administration, including several "what-if" discussions concerning ethics. Linux System Administration: A User's Guide by Marcel Gagne; Addison Wesley Professional -- Contains a good chapter on automating various tasks. Solaris System Management by John Philcox; New Riders Publishing -- Although not specifically written for Red Hat Enterprise Linux (or even Linux in general), and using the term "system manager" instead of "system administrator," this book provides a 70-page overview of the many roles that system administrators play in a typical organization.

Commands:
probe::ioscheduler_trace.elv_completed_request Name probe::ioscheduler_trace.elv_completed_request - Fires when a request is Synopsis Values disk_major Disk major no of request. rq Address of request. name Name of the probe point elevator_name The type of I/O elevator currently enabled. disk_minor Disk minor number of request. rq_flags Request flags. Description completed.

Commands:
ioscheduler_trace.elv_completed_request
8.37. esc 8.37.1. RHBA-2013:1698 - esc bug fix update Updated esc packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The esc packages contain the Smart Card Manager GUI, which allows user to manage security smart cards. The primary function of the tool is to enroll smart cards, so that they can be used for common cryptographic operations, such as secure e-mail and website access. Bug Fixes BZ# 920826 The ESC utility did not start when the latest 17 series release of the XULRunner runtime environment was installed on the system. This update includes necessary changes to ensure that ESC works as expected with the latest version of XULRunner. BZ# 961582 The ESC utility can be started manually or automatically when a card is inserted. Previously, when ESC started automatically, the ~/.redhat/ directory was created and granted with the read, write and execute permissions. However, some files within this directory had the permissions to read and write only. This inconsistency has been fixed with this update and the permissions are now set properly in the described scenario. BZ# 981156 Due to a bug in the esc.desktop file, an error message has been logged in the /var/log/messages/ directory. This update applies a patch to fix this bug and the error message is no longer returned. Users of esc are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 69. JmxTransQueryTemplate schema reference Used in: JmxTransSpec Property Property type Description targetMBean string If using wildcards instead of a specific MBean then the data is gathered from multiple MBeans. Otherwise if specifying an MBean then data is gathered from that specified MBean. attributes string array Determine which attributes of the targeted MBean should be included. outputs string array List of the names of output definitions specified in the spec.kafka.jmxTrans.outputDefinitions that have defined where JMX metrics are pushed to, and in which data format.

Commands:
1.2.3. Evaluating the Tools An assessment can start by using some form of an information gathering tool. When assessing the entire network, map the layout first to find the hosts that are running. Once located, examine each host individually. Focusing on these hosts requires another set of tools. Knowing which tools to use may be the most crucial step in finding vulnerabilities. Just as in any aspect of everyday life, there are many different tools that perform the same job. This concept applies to performing vulnerability assessments as well. There are tools specific to operating systems, applications, and even networks (based on the protocols used). Some tools are free; others are not. Some tools are intuitive and easy to use, while others are cryptic and poorly documented but have features that other tools do not. Finding the right tools may be a daunting task and in the end, experience counts. If possible, set up a test lab and try out as many tools as you can, noting the strengths and weaknesses of each. Read documentation that comes with the tool (for example, in a README file or a manual page). For more information, search articles, step-by-step guides, or even mailing lists specific to a tool on the Internet. The tools discussed below are just a small sampling of the available tools. 1.2.3.1. Scanning Hosts with Nmap Nmap is a popular tool that can be used to determine the layout of a network. Nmap has been available for many years and is probably the most often used tool when gathering information. An excellent manual page is included that provides detailed descriptions of its options and usage. Administrators can use Nmap on a network to find host systems and open ports on those systems. Nmap is a competent first step in vulnerability assessment. You can map out all the hosts within your network and even pass an option that allows Nmap to attempt to identify the operating system running on a particular host. Nmap is a good foundation for establishing a policy of using secure services and restricting unused services. To install Nmap, run the yum install nmap command as the root user. 1.2.3.1.1. Using Nmap Nmap can be run from a shell prompt by typing the nmap command followed by the host name or IP address of the machine to scan: nmap <host name> For example, to scan a machine with host name foo.example.com , type the following at a shell prompt: The results of a basic scan (which could take up to a few minutes, depending on where the host is located and other network conditions) look similar to the following: Nmap tests the most common network communication ports for listening or waiting services. This knowledge can be helpful to an administrator who wants to close down unnecessary or unused services. For more information about using Nmap, see the official homepage at the following URL: http://www.insecure.org/

Commands:
~]USD nmap foo.example.com
Interesting ports on foo.example.com: Not shown: 1710 filtered ports PORT STATE SERVICE 22/tcp open ssh 53/tcp open domain 80/tcp open http 113/tcp closed auth
Chapter 5. Container Images Based on Red Hat Software Collections 3.6 Component Description Supported architectures Application Images rhscl/nodejs-14-rhel7 Node.js 14 platform for building and running applications x86_64, s390x, ppc64le rhscl/perl-530-rhel7 Perl 5.30 platform for building and running applications x86_64, s390x, ppc64le rhscl/php-73-rhel7 PHP 7.3 platform for building and running applications x86_64, s390x, ppc64le rhscl/ruby-25-rhel7 Ruby 2.5 platform for building and running applications (EOL) x86_64 Daemon Images rhscl/httpd-24-rhel7 Apache HTTP 2.4 Server x86_64, s390x, ppc64le rhscl/nginx-118-rhel7 nginx 1.18 server and a reverse proxy server (EOL) x86_64, s390x, ppc64le Legend: x86_64 - AMD64 and Intel 64 architectures s390x - 64-bit IBM Z ppc64le - IBM POWER, little endian All images are based on components from Red Hat Software Collections. The images are available for Red Hat Enterprise Linux 7 through the Red Hat Container Registry. For detailed information about components provided by Red Hat Software Collections 3.6, see the Red Hat Software Collections 3.6 Release Notes . For more information about the Red Hat Developer Toolset 10 components, see the Red Hat Developer Toolset 10 User Guide . For information regarding container images based on Red Hat Software Collections 2, see Using Red Hat Software Collections 2 Container Images . EOL images are no longer supported.

Commands:
7.200. spice-xpi 7.200.1. RHBA-2015:1393 - spice-xpi bug fix update Updated spice-xpi packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The spice-xpi packages provide the Simple Protocol for Independent Computing Environments (SPICE) extension for Mozilla that allows the SPICE client to be used from a web browser. Bug Fixes BZ# 1049475 Previously, after enabling a proxy for a SPICE connection opened through the spice-xpi plug-in, the only way the user could unset the proxy was to close or reopen the web page. This update modifies spice-xpi to unset the SPICE_PROXY environment variable when the proxy is unset. As a result, unsetting a proxy for a SPICE connection works as expected. BZ# 1049486 Prior to this update, certain spice-xpi properties were not recorded in the spice-xpi.log file. These properties were only displayed in the /var/log/messages file. With this update, spice-xpi has been modified to properly log reading or setting the "smartcard", "color-depth", "disable-effects", and "proxy" properties of the spice-xpi browser plug-in. As a result, these events are now visible in spice-xpi.log. Users of spice-xpi are advised to upgrade to these updated packages, which fix these bugs. After installing the update, Firefox must be restarted for the changes to take effect.

Commands:
16.2.2. Lease Database On the DHCP server, the file /var/lib/dhcpd/dhcpd.leases stores the DHCP client lease database. Do not change this file. DHCP lease information for each recently assigned IP address is automatically stored in the lease database. The information includes the length of the lease, to whom the IP address has been assigned, the start and end dates for the lease, and the MAC address of the network interface card that was used to retrieve the lease. All times in the lease database are in Coordinated Universal Time (UTC), not local time. The lease database is recreated from time to time so that it is not too large. First, all known leases are saved in a temporary lease database. The dhcpd.leases file is renamed dhcpd.leases~ and the temporary lease database is written to dhcpd.leases . The DHCP daemon could be killed or the system could crash after the lease database has been renamed to the backup file but before the new file has been written. If this happens, the dhcpd.leases file does not exist, but it is required to start the service. Do not create a new lease file. If you do, all old leases are lost which causes many problems. The correct solution is to rename the dhcpd.leases~ backup file to dhcpd.leases and then start the daemon.

Commands:
Chapter 4. Compatibility Matrix for Red Hat Ceph Storage 5.3 The following tables list products and their versions compatible with Red Hat Ceph Storage 5.3. Host Operating System Version Notes Red Hat Enterprise Linux 9.5, 9.4, 9.3, 9.2, 9.1, 9.0, 8.10, 8.9, 8.8, 8.7, 8.6, 8.5, and EUS 8.4 Standard lifecycle 9.4 is included in the product (recommended). Red Hat Enterprise Linux EUS is optional. Important All nodes in the cluster and their clients must use the supported OS version(s) to ensure that the version of the ceph package is the same on all nodes. Using different versions of the ceph package is not supported. Important Red Hat no longer supports using Ubuntu as a host operating system to deploy Red Hat Ceph Storage. Product Version Notes Ansible Supported in a limited capacity. Supported for upgrade and conversion to Cephadm and for other minimal playbooks. Red Hat OpenShift 3.x RBD,Cinder and CephFS drivers are supported. Red Hat OpenShift Data Foundation See the Red Hat OpenShift Data Foundation Supportability and Interoperability Checker for detailed external mode version compatibility. Red Hat OpenStack Platform 16.1, 16.2, 17.0, and 17.1 Red Hat OpenStack Platform 16.1z8 and 16.2z1 are supported only with external Red Hat Ceph Storage 5.3. Red Hat OpenStack Platform 17.0 and 17.1 supports Red Hat Ceph Storage 5.3 through both external and director deployed. Red Hat Satellite 6.x Only registering with the Content Delivery Network (CDN) is supported. Registering with Red Hat Network (RHN) is deprecated and not supported. Client Connector Version Notes S3A 2.8.x, 3.2.x, and trunk Red Hat Enterprise Linux iSCSI Initiator The latest versions of the iscsi-initiator-utils and device-mapper-multipath packages VMware vSphere versions 6.7 and 7 are supported Red Hat Ceph Storage as a backup target Version Notes CommVault Cloud Data Management v11 IBM Spectrum Protect Plus 10.1.5 IBM Spectrum Protect server 8.1.8 NetApp AltaVault 4.3.2 and 4.4 Rubrik Cloud Data Management (CDM) 3.2 onwards Trilio, TrilioVault 3.0 S3 target Veeam (object storage) Veeam Availability Suite 9.5 Update 4 Supported on Red Hat Ceph Storage object storage with the S3 protocol Veritas NetBackup for Symantec OpenStorage (OST) cloud backup 7.7 and 8.0 Independent Software vendors Version Notes IBM Spectrum Discover 2.0.3 WekaIO 3.12.2

Commands:
Chapter 2. Red Hat Enterprise Linux 6 Performance Features 2.1. 64-Bit Support Red Hat Enterprise Linux 6 supports 64-bit processors; these processors can theoretically use up to 16 exabytes of memory. As of general availability (GA), Red Hat Enterprise Linux 6.0 is tested and certified to support up to 8 TB of physical memory. The size of memory supported by Red Hat Enterprise Linux 6 is expected to grow over several minor updates, as Red Hat continues to introduce and improve more features that enable the use of larger memory blocks. For current details, see https://access.redhat.com/site/articles/rhel-limits . Example improvements (as of Red Hat Enterprise Linux 6.0 GA) are: Huge pages and transparent huge pages Non-Uniform Memory Access improvements These improvements are outlined in greater detail in the sections that follow. Huge pages and transparent huge pages The implementation of huge pages in Red Hat Enterprise Linux 6 allows the system to manage memory use efficiently across different memory workloads. Huge pages dynamically utilize 2 MB pages compared to the standard 4 KB page size, allowing applications to scale well while processing gigabytes and even terabytes of memory. Huge pages are difficult to manually create, manage, and use. To address this, Red Hat Enterprise 6 also features the use of transparent huge pages (THP). THP automatically manages many of the complexities involved in the use of huge pages. For more information on huge pages and THP, refer to Section 5.2, "Huge Pages and Transparent Huge Pages" . NUMA improvements Many new systems now support Non-Uniform Memory Access (NUMA). NUMA simplifies the design and creation of hardware for large systems; however, it also adds a layer of complexity to application development. For example, NUMA implements both local and remote memory, where remote memory can take several times longer to access than local memory. This feature has performance implications for operating systems and applications, and should be configured carefully. Red Hat Enterprise Linux 6 is better optimized for NUMA use, thanks to several additional features that help manage users and applications on NUMA systems. These features include CPU affinity, CPU pinning (cpusets), numactl and control groups, which allow a process (affinity) or application (pinning) to "bind" to a specific CPU or set of CPUs. For more information about NUMA support in Red Hat Enterprise Linux 6, refer to Section 4.1.1, "CPU and NUMA Topology" .

Commands:
7.181. rgmanager 7.181.1. RHBA-2015:1402 - rgmanager bug fix update Updated rgmanager packages that fix one bug are now available for Red Hat Enterprise Linux 6. The rgmanager packages contain the Red Hat Resource Group Manager, which is used for creating and managing high-availability server applications in the event of system downtime. Bug Fix BZ# 1151199 Previously, when relocating a service, the rgmanager utility attempted to use all nodes in a domain and if all failed, rgmanager restarted the service locally without checking whether the local node was eligible to run the service and regardless of whether the service had been started. Consequently, under certain circumstances, a service in a restricted domain could be started on a non-member node. With this update, if the service cannot be started on any domain members, the service goes back to a stopped state, and rgmanager no longer attempts to start the service on a local node outside the restricted domain. Users of rgmanager are advised to upgrade to these updated packages, which fix this bug.

Commands:
22.2. remote-viewer The remote-viewer is a simple remote desktop display client that supports SPICE and VNC. It shares most of the features and limitations with virt-viewer . However, unlike virt-viewer , remote-viewer does not require libvirt to connect to the remote guest display. As such, remote-viewer can be used for example to connect to a virtual machine on a remote host that does not provide permissions to interact with libvirt or to use SSH connections. To install the remote-viewer utility, run: Syntax The basic remote-viewer command-line syntax is as follows: To see the full list of options available for use with remote-viewer, see the remote-viewer man page. Connecting to a guest virtual machine If used without any options, remote-viewer lists guests that it can connect to on the default URI of the local system. To connect to a specific guest using remote-viewer, use the VNC/SPICE URI. For information about obtaining the URI, see Section 20.14, "Displaying a URI for Connection to a Graphical Display" . Example 22.3. Connecting to a guest display using SPICE Use the following to connect to a SPICE server on a machine called "testguest" that uses port 5900 for SPICE communication: Example 22.4. Connecting to a guest display using VNC Use the following to connect to a VNC server on a machine called testguest2 that uses port 5900 for VNC communication: Interface By default, the remote-viewer interface provides only the basic tools for interacting with the guest: Figure 22.2. Sample remote-viewer interface

Commands:
yum install virt-viewer
remote-viewer [OPTIONS] {guest-name|id|uuid}
remote-viewer spice:// testguest : 5900
remote-viewer vnc:// testguest2 : 5900
Chapter 18. Cache Store Implementations The cache store connects Red Hat JBoss Data Grid to the persistent data store. Cache stores are associated with individual caches. Different caches attached to the same cache manager can have different cache store configurations. Note If a clustered cache is configured with an unshared cache store (where shared is set to false ), on node join, stale entries which might have been removed from the cluster might still be present in the stores and can reappear. Report a bug 18.1. Cache Store Comparison Select a cache store based on your requirements. The following is a summary of high level differences between the cache stores available in Red Hat JBoss Data Grid: The Single File Cache Store is a local file cache store. It persists data locally for each node of the clustered cache. The Single File Cache Store provides superior read and write performance, but keeps keys in memory which limits its use when persisting large data sets at each node. See Section 18.4, "Single File Cache Store" for details. The LevelDB file cache store is a local file cache store which provides high read and write performance. It does not have the limitation of Single File Cache Store of keeping keys in memory. See Section 18.5, "LevelDB Cache Store" for details. The JDBC cache store is a cache store that may be shared, if required. When using it, all nodes of a clustered cache persist to a single database or a local JDBC database for every node in the cluster. The shared cache store lacks the scalability and performance of a local cache store such as the LevelDB cache store, but it provides a single location for persisted data. The JDBC cache store persists entries as binary blobs, which are not readable outside JBoss Data Grid. See Section 18.6, "JDBC Based Cache Stores" for details. The JPA Cache Store (supported in Library mode only) is a shared cache store like JDBC cache store, but preserves schema information when persisting to the database. Therefore, the persisted entries can be read outside JBoss Data Grid. See Section 18.8, "JPA Cache Store" for details. Report a bug

Commands: