mtpti5iD/redhat-docs_dataset huggingface dataset:
5.9.9. Day to Day Management of RAID Arrays There is little that needs to be done to keep a RAID array operating. As long as no hardware problems crop up, the array should function just as if it were a single physical disk drive. However, just as a system administrator should periodically check the status of all disk drives on the system, the RAID arrays' status should be checked as well. 5.9.9.1. Checking Array Status With /proc/mdstat The file /proc/mdstat is the easiest way to check on the status of all RAID arrays on a particular system. Here is a sample mdstat (view with the command cat /proc/mdstat ): On this system, there are three RAID arrays (all RAID 1). Each RAID array has its own section in /proc/mdstat and contains the following information: The RAID array device name (not including the /dev/ part) The status of the RAID array The RAID array's RAID level The physical partitions that currently make up the array (followed by the partition's array unit number) The size of the array The number of configured devices versus the number of operative devices in the array The status of each configured device in the array ( U meaning the device is OK, and _ indicating that the device has failed)

Commands:
Personalities : [raid1] read_ahead 1024 sectors md1 : active raid1 hda3[0] hdc3[1] 522048 blocks [2/2] [UU] md0 : active raid1 hda2[0] hdc2[1] 4192896 blocks [2/2] [UU] md2 : active raid1 hda1[0] hdc1[1] 128384 blocks [2/2] [UU] unused devices: <none>
Chapter 58. CertificateAuthority schema reference Used in: KafkaSpec Configuration of how TLS certificates are used within the cluster. This applies to certificates used for both internal communication within the cluster and to certificates used for client access via Kafka.spec.kafka.listeners.tls . Property Property type Description generateCertificateAuthority boolean If true then Certificate Authority certificates will be generated automatically. Otherwise the user will need to provide a Secret with the CA certificate. Default is true. generateSecretOwnerReference boolean If true , the Cluster and Client CA Secrets are configured with the ownerReference set to the Kafka resource. If the Kafka resource is deleted when true , the CA Secrets are also deleted. If false , the ownerReference is disabled. If the Kafka resource is deleted when false , the CA Secrets are retained and available for reuse. Default is true . validityDays integer The number of days generated certificates should be valid for. The default is 365. renewalDays integer The number of days in the certificate renewal period. This is the number of days before the a certificate expires during which renewal actions may be performed. When generateCertificateAuthority is true, this will cause the generation of a new certificate. When generateCertificateAuthority is true, this will cause extra logging at WARN level about the pending certificate expiry. Default is 30. certificateExpirationPolicy string (one of [replace-key, renew-certificate]) How should CA certificate expiration be handled when generateCertificateAuthority=true . The default is for a new CA certificate to be generated reusing the existing private key.

Commands:
16.8. Additional Resources The following resources further explain methods to use and configure PAM. In addition to these resources, read the PAM configuration files on the system to better understand how they are structured. 16.8.1. Installed Documentation PAM related man pages - There are a number of man pages for the various applications and configuration files involved with PAM. The following is a list of some of the more important man pages. Configuration Files man pam - Good introductory information on PAM, including the structure and purpose of the PAM configuration files. Note that although this man page talks about the /etc/pam.conf file, the actual configuration files for PAM under Red Hat Enterprise Linux are in the /etc/pam.d/ directory. man pam_console - Describes the purpose of the pam_console.so module. It also describes the appropriate syntax for an entry within a PAM configuration file. man console.apps - Describes the format and options available within /etc/security/console.apps the configuration file which defines which applications are accessible by the console user assigned by PAM. man console.perms - Describes the format and options available within /etc/security/console.perms , the configuration file for the console user permissions assigned by PAM. man pam_timestamp - Describes the pam_timestamp.so module. /usr/share/doc/pam- <version-number> - Contains a System Administrators' Guide , a Module Writers' Manual , and the Application Developers' Manual , as well as a copy of the PAM standard, DCE-RFC 86.0 (replace <version-number> with the version number of PAM). /usr/share/doc/pam- <version-number> /txts/README.pam_timestamp - Contains information about the pam_timestamp.so PAM module (replace <version-number> with the version number of PAM).

Commands:
Chapter 22. Desktop Using Radeon or Nouveau can cause incorrectly rendered graphics A bug in the Xorg server can, under rare circumstances, cause graphics to be rendered incorrectly if using the Radeon or Nouveau graphics device driver. For example, the Thunderbird message pane can be displayed incorrectly. For Nouveau, as a workaround, add the WrappedFB option to the xorg.conf file as follows: This workaround avoids the faulty logic in the X server, and the Thunderbird message pane will be displayed correctly. (BZ#1076595)

Commands:
Section "Device" Identifier "nouveau-device" Driver "nouveau" Option "WrappedFB" "true" EndSection
function::user_long_warn Name function::user_long_warn - Retrieves a long value stored in user space. Synopsis Arguments addr The user space address to retrieve the long from. General Syntax user_long_warn:long(addr:long) Description Returns the long value from a given user space address. Returns zero when user space and warns (but does not abort) about the failure. Note that the size of the long depends on the architecture of the current user space task (for those architectures that support both 64/32 bit compat tasks).

Commands:
function user_long_warn:long(addr:long)
33.7.2. The Policies Tab To change settings in print output, click the Policies tab. For example, to create a banner page (a page that describes aspects of the print job such as the originating printer, the username from the which the job originated, and the security status of the document being printed) click the Starting Banner or Ending Banner drop-menu and choose the option that best describes the nature of the print jobs (such as topsecret , classified , or confidential ). Figure 33.9. Policies Tab You can also configure the Error Policy of the printer, by choosing an option from the drop-down menu. You can choose to abort the print job, retry, or stop it.

Commands:
Chapter 23. Storage dm-era Device Mapper The device-mapper-persistent-data package now provides tools to help use the new dm-era device mapper functionality released as a Technology Preview. The dm-era functionality keeps track of which blocks on a device were written within user-defined periods of time called an era . This functionality allows backup software to track changed blocks or restore the coherency of a cache after reverting changes. DIF/DIX support DIF/DIX, is a new addition to the SCSI Standard and a Technology Preview in Red Hat Enterprise Linux 6. DIF/DIX increases the size of the commonly used 512-byte disk block from 512 to 520 bytes, adding the Data Integrity Field (DIF). The DIF stores a checksum value for the data block that is calculated by the Host Bus Adapter (HBA) when a write occurs. The storage device then confirms the checksum on receive, and stores both the data and the checksum. Conversely, when a read occurs, the checksum can be checked by the storage device, and by the receiving HBA. The DIF/DIX hardware checksum feature must only be used with applications that exclusively issue O_DIRECT I/O. These applications may use the raw block device, or the XFS file system in O_DIRECT mode. (XFS is the only file system that does not fall back to buffered I/O when doing certain allocation operations.) Only applications designed for use with O_DIRECT I/O and DIF/DIX hardware should enable this feature. For more information, refer to section Block Devices with DIF/DIX Enabled in the Storage Administration Guide . Package: kernel-2.6.32-696 LVM Application Programming Interface (API) Red Hat Enterprise Linux 6 features the new LVM application programming interface (API) as a Technology Preview. This API is used to query and control certain aspects of LVM. Package: lvm2-2.02.143-11

Commands:
F.2. A Detailed Look at the Boot Process The beginning of the boot process varies depending on the hardware platform being used. However, once the kernel is found and loaded by the boot loader, the default boot process is identical across all architectures. This chapter focuses primarily on the x86 architecture. F.2.1. The Firmware Interface F.2.1.1. BIOS-based x86 Systems The Basic Input/Output System (BIOS) is a firmware interface that controls not only the first step of the boot process, but also provides the lowest level interface to peripheral devices. On x86 systems equipped with BIOS, the program is written into read-only, permanent memory and is always available for use. When the system boots, the processor looks at the end of system memory for the BIOS program, and runs it. Once loaded, the BIOS tests the system, looks for and checks peripherals, and then locates a valid device with which to boot the system. Usually, it checks any optical drives or USB storage devices present for bootable media, then, failing that, looks to the system's hard drives. In most cases, the order of the drives searched while booting is controlled with a setting in the BIOS, and it looks on the master IDE on the primary IDE bus or for a SATA device with a boot flag set. The BIOS then loads into memory whatever program is residing in the first sector of this device, called the Master Boot Record (MBR). The MBR is only 512 bytes in size and contains machine code instructions for booting the machine, called a boot loader, along with the partition table. Once the BIOS finds and loads the boot loader program into memory, it yields control of the boot process to it. This first-stage boot loader is a small machine code binary on the MBR. Its sole job is to locate the second stage boot loader ( GRUB ) and load the first part of it into memory. F.2.1.2. UEFI-based x86 Systems The Unified Extensible Firmware Interface (UEFI) is designed, like BIOS, to control the boot process (through boot services ) and to provide an interface between system firmware and an operating system (through runtime services ). Unlike BIOS, it features its own architecture, independent of the CPU, and its own device drivers. UEFI can mount partitions and read certain file systems. When an x86 computer equipped with UEFI boots, the interface searches the system storage for a partition labeled with a specific globally unique identifier (GUID) that marks it as the EFI System Partition (ESP). This partition contains applications compiled for the EFI architecture, which might include bootloaders for operating systems and utility software. UEFI systems include an EFI boot manager that can boot the system from a default configuration, or prompt a user to choose an operating system to boot. When a bootloader is selected, manually or automatically, UEFI reads it into memory and yields control of the boot process to it.

Commands:
Chapter 22. Importing projects from Git repositories Git is a distributed version control system. It implements revisions as commit objects. When you save your changes to a repository, a new commit object in the Git repository is created. Business Central uses Git to store project data, including assets such as rules and processes. When you create a project in Business Central, it is added to a Git repository that is embedded in Business Central. If you have projects in other Git repositories, you can import those projects into the Business Central Git repository through Business Central spaces. Prerequisites Red Hat Decision Manager projects exist in an external Git repository. You have the credentials required for read access to that external Git repository. Procedure In Business Central, click Menu Design Projects . Select or create the space into which you want to import the projects. The default space is MySpace . To import a project, do one of the following: Click Import Project . Select Import Project from the drop-down list. In the Import Project window, enter the URL and credentials for the Git repository that contains the projects that you want to import and click Import . The projects are added to the Business Central Git repository and are available from the current space.

Commands:
Chapter 11. Managing FIPS Mode Support Red Hat Directory Server fully supports the Federal Information Processing Standard (FIPS) 140-2. When Directory Server runs in FIPS mode, security-related settings change. For example, SSL is automatically disabled and only TLS 1.2 and 1.3 encryption is used. For general details about FIPS, see Federal Information Processing Standard (FIPS) in the Red Hat Enterprise Linux 8 Security hardening documentation. Enabling FIPS Mode Support To enable FIPS mode support for Directory Server: Optionally, enable FIPS mode in Red Hat Enterprise Linux. For details, see the corresponding section in the Red Hat Enterprise Linux 8 Security hardening documentation. Enable FIPS mode for the network security services (NSS) database: Restart the Directory Server instance: Disabling FIPS Mode Support To disable FIPS mode support for Directory Server: Disable FIPS mode for the network security services (NSS) database: Restart the Directory Server instance:

Commands:
modutil -dbdir /etc/dirsrv/slapd- instance_name / -fips true
dsctl instance_name restart
modutil -dbdir /etc/dirsrv/slapd- instance_name / -fips false
dsctl instance_name restart
5.4. Performance Counters for Linux (PCL) Tools and perf Performance Counters for Linux (PCL) is a new kernel-based subsystem that provides a framework for collecting and analyzing performance data. These events will vary based on the performance monitoring hardware and the software configuration of the system. Red Hat Enterprise Linux 6 includes this kernel subsystem to collect data and the user-space tool perf to analyze the collected performance data. The PCL subsystem can be used to measure hardware events, including retired instructions and processor clock cycles. It can also measure software events, including major page faults and context switches. For example, PCL counters can compute the Instructions Per Clock (IPC) from a process's counts of instructions retired and processor clock cycles. A low IPC ratio indicates the code makes poor use of the CPU. Other hardware events can also be used to diagnose poor CPU performance. Performance counters can also be configured to record samples. The relative frequency of samples can be used to identify which regions of code have the greatest impact on performance. 5.4.1. Perf Tool Commands Useful perf commands include the following: perf stat This perf command provides overall statistics for common performance events, including instructions executed and clock cycles consumed. Options allow selection of events other than the default measurement events. perf record This perf command records performance data into a file which can be later analyzed using perf report . perf report This perf command reads the performance data from a file and analyzes the recorded data. perf list This perf command lists the events available on a particular machine. These events will vary based on the performance monitoring hardware and the software configuration of the system. Use perf help to obtain a complete list of perf commands. To retrieve man page information on each perf command, use perf help command .

Commands:
Chapter 7. Data Grid ports and protocols As Data Grid distributes data across your network and can establish connections for external client requests, you should be aware of the ports and protocols that Data Grid uses to handle network traffic. If run Data Grid as a remote server then you might need to allow remote clients through your firewall. Likewise, you should adjust ports that Data Grid nodes use for cluster communication to prevent conflicts or network issues. 7.1. Data Grid Server ports and protocols Data Grid Server provides network endpoints that allow client access with different protocols. Port Protocol Description 11222 TCP Hot Rod and REST 11221 TCP Memcached (disabled by default) Single port Data Grid Server exposes multiple protocols through a single TCP port, 11222 . Handling multiple protocols with a single port simplifies configuration and reduces management complexity when deploying Data Grid clusters. Using a single port also enhances security by minimizing the attack surface on the network. Data Grid Server handles HTTP/1.1, HTTP/2, and Hot Rod protocol requests from clients via the single port in different ways. HTTP/1.1 upgrade headers Client requests can include the HTTP/1.1 upgrade header field to initiate HTTP/1.1 connections with Data Grid Server. Client applications can then send the Upgrade: protocol header field, where protocol is a server endpoint. Application-Layer Protocol Negotiation (ALPN)/Transport Layer Security (TLS) Client requests include Server Name Indication (SNI) mappings for Data Grid Server endpoints to negotiate protocols over a TLS connection. Note Applications must use a TLS library that supports the ALPN extension. Data Grid uses WildFly OpenSSL bindings for Java. Automatic Hot Rod detection Client requests that include Hot Rod headers automatically route to Hot Rod endpoints. 7.1.1. Configuring network firewalls for Data Grid traffic Adjust firewall rules to allow traffic between Data Grid Server and client applications. Procedure On Red Hat Enterprise Linux (RHEL) workstations, for example, you can allow traffic to port 11222 with firewalld as follows: To configure firewall rules that apply across a network, you can use the nftables utility. Reference Using and configuring firewalld Getting started with nftables 7.2. TCP and UDP ports for cluster traffic Data Grid uses the following ports for cluster transport messages: Default Port Protocol Description 7800 TCP/UDP JGroups cluster bind port 46655 UDP JGroups multicast Cross-site replication Data Grid uses the following ports for the JGroups RELAY2 protocol: 7900 For Data Grid clusters running on OpenShift. 7800 If using UDP for traffic between nodes and TCP for traffic between clusters. 7801 If using TCP for traffic between nodes and TCP for traffic between clusters.

Commands:
firewall-cmd --add-port=11222/tcp --permanent success firewall-cmd --list-ports | grep 11222 11222/tcp
1.2. Security Controls Computer security is often divided into three distinct master categories, commonly referred to as controls : Physical Technical Administrative These three broad categories define the main objectives of proper security implementation. Within these controls are sub-categories that further detail the controls and how to implement them. 1.2.1. Physical Controls Physical control is the implementation of security measures in a defined structure used to deter or prevent unauthorized access to sensitive material. Examples of physical controls are: Closed-circuit surveillance cameras Motion or thermal alarm systems Security guards Picture IDs Locked and dead-bolted steel doors Biometrics (includes fingerprint, voice, face, iris, handwriting, and other automated methods used to recognize individuals)

Commands:
Chapter 1. Introduction to Red Hat JBoss Data Grid 6.6 Welcome to Red Hat JBoss Data Grid 6.6.2. As you become familiar with the newest version of JBoss Data Grid these Release Notes provide you with information about new features, as well as known and resolved issues. Use this document in conjunction with the entire JBoss Data Grid documentation suite, available at the Red Hat Customer Service Portal's JBoss Data Grid documentation page . Report a bug 1.1. About Red Hat JBoss Data Grid Red Hat's JBoss Data Grid is an open source, distributed, in-memory key/value data store built from the Infinispan open source software project. Whether deployed in client/server mode or embedded in a Java Virtual Machine, it is built to be elastic, high performance, highly available and to scale linearly. JBoss Data Grid is accessible for both Java and Non-Java clients. Using JBoss Data Grid, data is distributed and replicated across a manageable cluster of nodes, optionally written to disk and easily accessible using the REST, Memcached and Hot Rod protocols, or directly in process through a traditional Java Map API. Report a bug

Commands:
Chapter 5. Trim options on an LVM-VDO volume The following are different available trim options for an LVM-VDO volume: discard Performs online block discard operations to automatically discard unused blocks. For immediate discarding, use the mount -o discard command. fstrim Performs periodic discarding. The admin needs to schedule and monitor an additional process. Note It is currently recommended to use fstrim application to discard unused blocks rather than the discard mount option because the performance impact of this option can be quite severe. For this reason, nodiscard is the default. 5.1. Enabling discard mount option on an LVM-VDO volume You can enable the discard option on your LVM-VDO volume. Prerequisites An LVM-VDO volume exists on your system. Procedure Enable the discard option on your volume: Additional resources xfs(5) , mount(8) , and lvmvdo(7) man pages on your system 5.2. Setting up periodic TRIM operation You can enable a scheduled TRIM operation on your system. Prerequisites An LVM-VDO volume exists on your system. Procedure Enable and start the timer: Verification Verify that the timer is enabled: Note You will not see any reference to a VDO volume, because the fstrim.timer runs across all mounted file systems. Additional resources fstrim(8) man page on your system

Commands:
mount -o discard /dev/ vg-name/vdo-name mount-point
systemctl enable --now fstrim.timer
systemctl list-timers fstrim.timer NEXT LEFT LAST PASSED UNIT ACTIVATES Mon 2021-05-10 00:00:00 EDT 5 days left n/a n/a fstrim.timer fstrim.service