mtpti5iD/redhat-docs_dataset huggingface dataset:
4.28. SCSI Persistent Reservations Table 4.29, "SCSI Reservation Fencing" lists the fence device parameters used by fence_scsi , the fence agent for SCSI persistent reservations. Note Use of SCSI persistent reservations as a fence method is supported with the following limitations: When using SCSI fencing, all nodes in the cluster must register with the same devices so that each node can remove another node's registration key from all the devices it is registered with. Devices used for the cluster volumes should be a complete LUN, not partitions. SCSI persistent reservations work on an entire LUN, meaning that access is controlled to each LUN, not individual partitions. It is recommended that devices used for the cluster volumes be specified in the format /dev/disk/by-id/ xxx where possible. Devices specified in this format are consistent among all nodes and will point to the same disk, unlike devices specified in a format such as /dev/sda which can point to different disks from machine to machine and across reboots. Table 4.29. SCSI Reservation Fencing luci Field cluster.conf Attribute Description Name name A name for the SCSI fence device. Unfencing unfence section of the cluster configuration file When enabled, this ensures that a fenced node is not re-enabled until the node has been rebooted. This is necessary for non-power fence methods (that is, SAN/storage fencing). When you configure a device that requires unfencing, the cluster must first be stopped and the full configuration including devices and unfencing must be added before the cluster is started. For more information about unfencing a node, see the fence_node (8) man page. Node name nodename The node name is used to generate the key value used for the current operation. Key for current action key (overrides node name) Key to use for the current operation. This key should be unique to a node. For the "on" action, the key specifies the key use to register the local node. For the "off" action,this key specifies the key to be removed from the device(s). Delay (optional) delay The number of seconds to wait before fencing is started. The default value is 0. Figure 4.21, "SCSI Fencing" shows the configuration screen for adding an SCSI fence device Figure 4.21. SCSI Fencing The following command creates a fence device instance for a SCSI Fence device: The following is the cluster.conf entry for the fence_scsi device:

Commands:
ccs -f cluster.conf --addfencedev scsifencetest1 agent=fence_scsi
<fencedevices> <<fencedevice agent="fence_scsi" name="scsifencetest1"/> </fencedevices>
11.6. Configuring IPv6 Tokenized Interface Identifiers In a network, servers are generally given static addresses and these are usually configured manually to avoid relying on a DHCP server which may fail or run out of addresses. The IPv6 protocol introduced Stateless Address Autoconfiguration ( SLAAC ) which enables clients to assign themselves an address without relying on a DHCPv6 server. SLAAC derives the IPv6 address based on the interface hardware, therefore it should not be used for servers in case the hardware is changed and the associated SLAAC generated address changes with it. In an IPv6 environment, if the network prefix is changed, or the system is moved to a new location, any manually configured static addresses would have to be edited due to the changed prefix. To address these problems, the IETF draft Tokenised IPv6 Identifiers has been implemented in the kernel together with corresponding additions to the ip utility. This enables the lower 64 bit interface identifier part of the IPv6 address to be based on a token, supplied by the administrator, leaving the network prefix, the higher 64 bits, to be obtained from router advertisements ( RA ). This means that if the network interface hardware is changed, the lower 64 bits of the address will not change, and if the system is moved to another network, the network prefix will be obtained from router advertisements automatically, thus no manual editing is required. To configure an interface to use a tokenized IPv6 identifier, issue a command in the following format as root user: Where ::1a:2b:3c:4d/64 is the token to be used. This setting is not persistent. To make it persistent, add the command to an init script. See Section 11.3, "Interface Control Scripts" . Using a memorable token is possible, but is limited to the range of valid hexadecimal digits. For example, for a DNS server, which traditionally uses port 53 , a token of ::53/64 could be used. To view all the configured IPv6 tokens, issue the following command: To view the configured IPv6 token for a specific interface, issue the following command: Note that adding a token to an interface will replace a previously allocated token, and in turn invalidate the address derived from it. Supplying a new token causes a new address to be generated and applied, but this process will leave any other addresses unchanged. In other words, a new tokenized identifier only replaces a previously existing tokenized identifier, not any other IP address. Note Take care not to add the same token to more than one system or interface as the duplicate address detection ( DAD ) mechanism will not be able to resolve the problem. Once a token is set, it cannot be cleared or reset, except by rebooting the machine.

Commands:
~]# ip token set ::1a:2b:3c:4d/64 dev eth4
~]USD ip token token :: dev eth0 token :: dev eth1 token :: dev eth2 token :: dev eth3 token ::1a:2b:3c:4d dev eth4
~]USD ip token get dev eth4 token ::1a:2b:3c:4d dev eth4
Chapter 3. Nagios remote plug-in executor installation As a storage administrator, you can monitor the Ceph storage cluster hosts, install Nagios plug-ins, the Ceph plug-ins, and the Nagios remote plug-in executor (NRPE) add-on to each of the Ceph hosts. For demonstration purposes, this section adds NRPE to a Ceph Monitor host with the hostname host01 . Repeat the remaining procedures on all Ceph hosts that Nagios should monitor. 3.1. Installing and configuring Nagios Remote Plug-In Executor Install the Nagios Remote Plug-in Executor (NPRE) and configure it to communicate with the Nagios Core server. Prerequisites Root-level access to Ceph Monitor host. Procedure Install these packages on the host: Example NRPE installation requires a Nagios user. Create the user first: Example Download the latest version of the Nagios plug-ins. Then, make and install them: Example Download the latest version of the Ceph plug-ins: Example Download, make, and install Nagios NRPE: Example If you are using a firewall, open port 5666 to allow communication with NRPE: Example Additional Resources For more information about Nagios plug-ins for Ceph, see Nagios plugins for Ceph . 3.2. Starting the Nagios Remote Plug-in Executor service Start the Nagios Remote Plug-in Executor (NRPE) service to collect data and report it back to the Nagios Core server. Prerequisites Root-level access to the Ceph Monitor host Procedure Enable and start the NRPE service: Example 3.3. Configuring Nagios Core server access to remote nodes For the Nagios Core server to access Nagios Remote Plugin Executor (NPRE) on a remote machine, the remote machine's NRPE configurations must be updated with the IP address of the Nagios Core server. Prerequisites Root-level access to the Nagios Core server. Internet access. Access to the Nagios Remote Plugin Executor. Procedure Edit the NRPE configuration with the Nagios server's IP address: Example Add the IP address of the Nagios Core server to the allowed_hosts setting. Syntax Replace IP_ADDRESS_OF_NAGIOS_CORE_SERVER with the IP address of your Nagios Core server. Restart nrpe : Example Verification Test the installation: Example The check should echo NRPE v4.0.3 if it is working correctly.

Commands:
dnf install openssl openssl-devel gcc make git
useradd nagios passwd nagios
wget http://nagios-plugins.org/download/nagios-plugins-2.3.3.tar.gz tar zxf nagios-plugins-2.3.3.tar.gz cd nagios-plugins-2.3.3 ./configure make make install
cd ~ git clone --recursive https://github.com/ceph/ceph-nagios-plugins.git cd ceph-nagios-plugins make dist make install
cd ~ wget https://github.com/NagiosEnterprises/nrpe/releases/download/nrpe-4.0.3/nrpe-4.0.3.tar.gz tar xvfz nrpe-4.0.3.tar.gz cd nrpe-4.0.3 ./configure make all make install-groups-users make install make install-config make install-init
firewall-cmd --zone=public --add-port=5666/tcp firewall-cmd --zone=public --add-port=5666/tcp --permanent
systemctl enable nrpe systemctl start nrpe
vi /usr/local/nagios/etc/nrpe.cfg
allowed_hosts=127.0.0.1, IP_ADDRESS_OF_NAGIOS_CORE_SERVER
systemctl restart nrpe
/usr/local/nagios/libexec/check_nrpe -H localhost
4.2. BIOS and Boot Loader Security Password protection for the BIOS (or BIOS equivalent) and the boot loader can prevent unauthorized users who have physical access to systems from booting using removable media or attaining root privileges through single user mode. But the security measures one should take to protect against such attacks depends both on the sensitivity of the information the workstation holds and the location of the machine. For instance, if a machine is used in a trade show and contains no sensitive information, than it may not be critical to prevent such attacks. However, if an employee's laptop with private, unencrypted SSH keys for the corporate network is left unattended at that same trade show, it could lead to a major security breach with ramifications for the entire company. On the other hand, if the workstation is located in a place where only authorized or trusted people have access, then securing the BIOS or the boot loader may not be necessary at all. 4.2.1. BIOS Passwords The following are the two primary reasons for password protecting the BIOS of a computer [5] : Preventing Changes to BIOS Settings - If an intruder has access to the BIOS, they can set it to boot from a diskette or CD-ROM. This makes it possible for them to enter rescue mode or single user mode, which in turn allows them to start arbitrary processes on the system or copy sensitive data. Preventing System Booting - Some BIOSes allow password protection of the boot process. When activated, an attacker is forced to enter a password before the BIOS launches the boot loader. Because the methods for setting a BIOS password vary between computer manufacturers, consult the computer's manual for specific instructions. If you forget the BIOS password, it can either be reset with jumpers on the motherboard or by disconnecting the CMOS battery. For this reason, it is good practice to lock the computer case if possible. However, consult the manual for the computer or motherboard before attempting to disconnect the CMOS battery. 4.2.1.1. Securing Non-x86 Platforms Other architectures use different programs to perform low-level tasks roughly equivalent to those of the BIOS on x86 systems. For instance, Intel (R) Itanium TM computers use the Extensible Firmware Interface ( EFI ) shell. For instructions on password protecting BIOS-like programs on other architectures, refer to the manufacturer's instructions. [5] Since system BIOSes differ between manufacturers, some may not support password protection of either type, while others may support one type but not the other.

Commands:
15.4. Adding Self-Hosted Engine Nodes to the Red Hat Virtualization Manager Self-hosted engine nodes are added in the same way as a standard host, with an additional step to deploy the host as a self-hosted engine node. The shared storage domain is automatically detected and the node can be used as a failover host to host the Manager virtual machine when required. You can also attach standard hosts to a self-hosted engine environment, but they cannot host the Manager virtual machine. Red Hat recommends having at least two self-hosted engine nodes to ensure the Manager virtual machine is highly available. Additional hosts can also be added using the REST API. See Hosts in the REST API Guide . Prerequisites If you are reusing a self-hosted engine node, remove its existing self-hosted engine configuration. See Removing a Host from a Self-Hosted Engine Environment . Important When creating a management bridge that uses a static IPv6 address, disable network manager control in its interface configuration (ifcfg) file before adding a host. See https://access.redhat.com/solutions/3981311 for more information. Procedure In the Administration Portal, click Compute Hosts . Click New . For information on additional host settings, see Explanation of Settings and Controls in the New Host and Edit Host Windows in the Administration Guide . Use the drop-down list to select the Data Center and Host Cluster for the new host. Enter the Name and the Address of the new host. The standard SSH port, port 22, is auto-filled in the SSH Port field. Select an authentication method to use for the Manager to access the host. Enter the root user's password to use password authentication. Alternatively, copy the key displayed in the SSH PublicKey field to /root/.ssh/authorized_keys on the host to use public key authentication. Optionally, configure power management, where the host has a supported power management card. For information on power management configuration, see Host Power Management Settings Explained in the Administration Guide . Click the Hosted Engine tab. Select Deploy . Click OK .

Commands:
8.2. NetworkManager 8.2.1. RHBA-2014:1413 - NetworkManager bug fix update Updated NetworkManager packages that fix two bugs are now available for Red Hat Enterprise Linux 6. NetworkManager is a system network service that manages network devices and connections, attempting to keep active network connectivity when available. Its capabilities include managing Ethernet, wireless, mobile broadband (WWAN), and PPPoE devices, as well as providing VPN integration with a variety of different VPN services. Bug Fixes BZ# 1025009 When the machine suspended, the NetworkManager daemon deactivated all network devices on that machine. Consequently, the Wake-on-LAN clients did not work because this network device was powered down, and thus could not receive the Magic Packet. With this update, NetworkManager leaves devices running at suspend time if they have the Wake-on-LAN or Wake-on-Wireless-LAN variable enabled, and Wake-on-LAN works as intended if the administrator enables it. BZ# 1034860 Previously, NetworkManager used the kernel's Point-to-point protocol over Ethernet (PPPoE) driver, which did not inform userland when it received a PPPoE Active Discovery Terminate (PADT) frame. As a consequence, when connecting to certain digital subscriber line (DSL) providers, the NetworkManager daemon failed to notice whether the connection was dropped. With this update, NetworkManager uses a userland PPPoE driver rather than the kernel driver, and dropped DSL connections are now noticed for all providers. BZ# 1113996 NetworkManager automatically provides an autoconnect for interfaces. Previously, when this connection was altered and saved, NetworkManager terminated unexpectedly. The write_ip4_setting() function has been updated to fix this bug, and NetworkManager no longer crashes after saving altered configuration. Users of NetworkManager are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 1. Overview of Cryostat Cryostat is a container-native Java application based on JDK Flight Recorder (JFR) that you can use to monitor Java Virtual Machine (JVM) performance for containerized workloads that run on a Red Hat OpenShift cluster. You can deploy Cryostat in a container in a Red Hat OpenShift project that hosts your containerized Java applications. You can create JVM targets that correspond to the JVM instances that you use to run your containerized workload. You can connect Cryostat to the JVM targets to record and analyze data about heap and non-heap memory usage, thread count, garbage collection, and other performance metrics for each JVM target. You can use the tools that are included with Cryostat to monitor the performance of your JVMs in real time, capture JDK Flight Recorder (JFR) recordings and snapshots, generate Automated Analysis reports, and visualize your recorded performance data by using a Grafana dashboard. The Cryostat web console and HTTP API provides a way to analyze your JVM performance data inside the container without having to rely on an external monitoring application. However, you can also export your recordings from Cryostat into an external instance of JDK Mission Control (JMC) when you need to perform a deeper analysis of your data outside of a cluster environment. Cryostat supports role-based access control (RBAC) as a standard feature of OpenShift Container Platform. You can configure different levels of authorization for each user role to ensure the privacy and integrity of your Flight Recording data. You can install Cryostat inside a Red Hat OpenShift project by using Operator Lifecycle Manager (OLM). You can also download the latest Cryostat component images from the Red Hat Ecosystem Catalog. The following container images exist for Cryostat 2.4 on the Red Hat Ecosystem Catalog: Cryostat Red Hat build of Cryostat Operator Red Hat build of Cryostat Operator bundle Cryostat reports Cryostat Grafana dashboard JFR data source Additional resources Operator Lifecycle Manager (OLM) (OpenShift Container Platform) Container images (Red Hat Ecosystem Catalog)

Commands:
B.57.2. RHSA-2011:0472 - Important: nss security update Updated nss packages that fix one security issue are now available for Red Hat Enterprise Linux 4, 5, and 6. The Red Hat Security Response Team has rated this update as having important security impact. Network Security Services (NSS) is a set of libraries designed to support the development of security-enabled client and server applications. BZ# 689430 This erratum blacklists a small number of HTTPS certificates by adding them, flagged as untrusted, to the NSS Builtin Object Token (the libnssckbi.so library) certificate store. Note Note that this fix only applies to applications using the NSS Builtin Object Token. It does not blacklist the certificates for applications that use the NSS library, but do not use the NSS Builtin Object Token (such as curl). All NSS users should upgrade to these updated packages, which correct this issue. After installing the update, applications using NSS must be restarted for the changes to take effect.

Commands:
4.2. Using SMB shares with SSSD and Winbind This section describes how you can use SSSD clients to access and fully use shares based on the Server Message Block (SMB) protocol, also known as the Common Internet File System (CIFS) protocol. Important Using SSSD as a client in IdM or Active Directory domains has certain limitations, and Red Hat does not recommend using SSSD as ID mapping plug-in for Winbind. For further details, see the " What is the support status for Samba file server running on IdM clients or directly enrolled AD clients where SSSD is used as the client daemon " article. SSSD does not support all the services that Winbind provides. For example, SSSD does not support authentication using the NT LAN Manager (NTLM) or NetBIOS name lookup. If you need these services, use Winbind. Note that in Identity Management domains, Kerberos authentication and DNS name lookup are available for the same purposes. 4.2.1. How SSSD Works with SMB The SMB file-sharing protocol is widely used on Windows machines. In Red Hat Enterprise Linux environments with a trust between Identity Management and Active Directory, SSSD enables seamless use of SMB as if it was a standard Linux file system. To access a SMB share, the system must be able to translate Windows SIDs to Linux POSIX UIDs and GIDs. SSSD clients use the SID-to-ID or SID-to-name algorithm, which enables this ID mapping. 4.2.2. Switching Between SSSD and Winbind for SMB Share Access This procedure describes how you can switch between SSSD and Winbind plug-ins that are used for accessing SMB shares from SSSD clients. For Winbind to be able to access SMB shares, you need to have the cifs-utils package installed on your client. To make sure that cifs-utils is installed on your machine: Optional . Find out whether you are currently using SSSD or Winbind to access SMB shares from the SSSD client: If the SSSD plug-in ( cifs_idmap_sss.so ) is installed, it has a higher priority than the Winbind plug-in ( idmapwb.so ) by default. Before switching to the Winbind plug-in, make sure Winbind is running on the system: Before switching to the SSSD plug-in, make sure SSSD is running on the system: To switch to a different plug-in, use the alternatives --set cifs-idmap-plugin command, and specify the path to the required plug-in. For example, to switch to Winbind: Note The 32-bit version platform, such as i686 in RHEL 7, uses the /usr/lib/cifs-utils/ directory instead of /usr/lib64/cifs-utils/ .

Commands:
rpm -q cifs-utils
alternatives --display cifs-idmap-plugin cifs-idmap-plugin - status is auto. link currently points to /usr/lib64/cifs-utils/cifs_idmap_sss.so /usr/lib64/cifs-utils/cifs_idmap_sss.so - priority 20 /usr/lib64/cifs-utils/idmapwb.so - priority 10 Current `best' version is /usr/lib64/cifs-utils/cifs_idmap_sss.so.
systemctl is-active winbind.service active
systemctl is-active sssd.service active
alternatives --set cifs-idmap-plugin /usr/lib64/cifs-utils/idmapwb.so
Chapter 4. Advisories related to this release The following advisories have been issued to document bugfixes and CVE fixes included in this release: RHSA-2023:0203 RHSA-2023:0204 RHSA-2023:0205 RHSA-2023:0206 RHSA-2023:0207 RHSA-2023:0208 RHSA-2023:0209 RHSA-2023:0210 Revised on 2024-05-10 09:05:52 UTC

Commands:
5.153. libproxy 5.153.1. RHSA-2012:1461 - Moderate: libproxy security update Updated libproxy packages that fix one security issue are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having moderate security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. libproxy is a library that handles all the details of proxy configuration. Security Fix CVE-2012-4505 A buffer overflow flaw was found in the way libproxy handled the downloading of proxy auto-configuration (PAC) files. A malicious server hosting a PAC file or a man-in-the-middle attacker could use this flaw to cause an application using libproxy to crash or, possibly, execute arbitrary code, if the proxy settings obtained by libproxy (from the environment or the desktop environment settings) instructed the use of a PAC proxy configuration. This issue was discovered by the Red Hat Security Response Team. Users of libproxy should upgrade to these updated packages, which contain a backported patch to correct this issue. All applications using libproxy must be restarted for this update to take effect.

Commands: