mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Introduction to Red Hat OpenStack Platform monitoring tools Monitoring tools are an optional suite of tools designed to help operators maintain an OpenStack environment. The tools perform the following functions: Centralized logging: Allows you gather logs from all components in the OpenStack environment in one central location. You can identify problems across all nodes and services, and optionally, export the log data to Red Hat for assistance in diagnosing problems. Availability monitoring: Allows you to monitor all components in the OpenStack environment and determine if any components are currently experiencing outages or are otherwise not functional. You can also configure the system to alert you when problems are identified. 1.1. Support status of monitoring components Use this table to view the support status of monitoring components in Red Hat OpenStack Platform (RHOSP). Table 1.1. Support status Component Fully supported since Deprecated in Removed since Note Aodh RHOSP 9 RHOSP 15 Supported for the autoscaling use case. Ceilometer RHOSP 4 Supported for collection of metrics and events for RHOSP in the autoscaling and Service Telemetry Framework (STF) use cases. Collectd RHOSP 11 RHOSP 17.1 Supported for collection of infrastructure metrics for STF. Gnocchi RHOSP 9 RHOSP 15 Supported for storage of metrics for the autoscaling use case. Panko RHOSP 11 RHOSP 12, not installed by default since RHOSP 14 RHOSP 17.0 QDR RHOSP 13 RHOSP 17.1 Supported for transmission of metrics and events data from RHOSP to STF.

Commands:
7.37. dash 7.37.1. RHBA-2012:1381 - dash bug fix update Updated dash packages that fix one bug are now available for Red Hat Enterprise Linux 6. The dash packages provide the POSIX-compliant Debian Almquist shell intended for small media like floppy disks. Bug Fix BZ# 706147 Prior to this update, the dash shell was not an allowed login shell. As a consequence, users could not log in using the dash shell. This update adds the dash to the /etc/shells list of allowed login shells when installing or upgrading dash package and removes it from the list when uninstalling the package. Now, users can login using the dash shell. All users of dash are advised to upgrade to these updated packages, which fix this bug.

Commands:
14.2. Required Parameters for Red Hat Enterprise Linux Guests For certain Red Hat Enterprise Linux guest virtual machines, additional kernel parameters are required. These parameters can be set by appending them to the end of the /kernel line in the /boot/grub/grub.conf file of the guest virtual machine. The table below lists versions of Red Hat Enterprise Linux and the parameters required on the specified systems. Table 14.1. Kernel parameter requirements Red Hat Enterprise Linux version Additional guest kernel parameters 7.0 and later on AMD64 and Intel 64 systems with kvm-clock Additional parameters are not required 6.1 and later on AMD64 and Intel 64 systems with kvm-clock Additional parameters are not required 6.0 on AMD64 and Intel 64 systems with kvm-clock Additional parameters are not required 6.0 on AMD64 and Intel 64 systems without kvm-clock notsc lpj= n 5.5 AMD64/Intel 64 with kvm-clock Additional parameters are not required 5.5 AMD64 and Intel 64 systems without kvm-clock notsc lpj= n 5.5 on 32-bit AMD and Intel systems with kvm-clock Additional parameters are not required 5.5 on 32-bit AMD and Intel systems without kvm-clock clocksource=acpi_pm lpj= n 5.4 on AMD64 and Intel 64 systems notsc 5.4 on 32-bit AMD and Intel systems clocksource=acpi_pm 5.3 on AMD64 and Intel 64 systems notsc 5.3 on 32-bit AMD and Intel systems clocksource=acpi_pm Note The lpj parameter requires a numeric value equal to the loops per jiffy value of the specific CPU on which the guest virtual machine runs. If you do not know this value, do not set the lpj parameter. Warning The divider kernel parameter was previously recommended for Red Hat Enterprise Linux 4 and 5 guest virtual machines that did not have high responsiveness requirements, or exist on systems with high guest density. It is no longer recommended for use with guests running Red Hat Enterprise Linux 4, or Red Hat Enterprise Linux 5 versions prior to version 5.8. divider can improve throughput on Red Hat Enterprise Linux 5 versions equal to or later than 5.8 by lowering the frequency of timer interrupts. For example, if HZ=1000 , and divider is set to 10 (that is, divider=10 ), the number of timer interrupts per period changes from the default value (1000) to 100 (the default value, 1000, divided by the divider value, 10). BZ#698842 details a bug in the way that the divider parameter interacts with interrupt and tick recording. This bug is fixed as of Red Hat Enterprise Linux 5.8. However, the divider parameter can still cause kernel panic in guests using Red Hat Enterprise Linux 4, or Red Hat Enterprise Linux 5 versions prior to version 5.8. This parameter was not implemented in Red Hat Enterprise Linux 3, so this bug does not affect Red Hat Enterprise Linux 3 guests. Red Hat Enterprise Linux 6 does not have a fixed-frequency clock interrupt; it operates in tickless mode and uses the timer dynamically as required. The divider parameter is therefore not useful for Red Hat Enterprise Linux 6, and Red Hat Enterprise Linux 6 guests are not affected by this bug.

Commands:
B.50. luci B.50.1. RHBA-2011:0906 - luci bug fix update An updated luci package that fixes one bug is now available for Red Hat Enterprise Linux 6. The luci package provides a web-based high-availability cluster configuration application. Bug Fix BZ# 681764 When configuring a cluster, the graphical user interface of the luci application allows users to configure fence agents. Previously, this interface did not include the fence_brocade agent in the list of available options. Since the RHBA-2011:0363 bug fix update re-included fence_brocade in the fence-agents package that is distributed with Red Hat Enterprise Linux 6, this update re-adds this agent (the "Brocade Fabric Switch" option) to the list of fence agents that are available for configuration. All users of luci are advised to upgrade to this updated package, which fixes this bug.

Commands:
Preface Red Hat Enterprise Linux (RHEL) minor releases are an aggregation of individual enhancement, security, and bug fix errata. The Red Hat Enterprise Linux 6.10 Technical Notes document provides a list of notable bug fixes, all currently available Technology Previews, deprecated functionality, and other information. The Release Notes document describes the major changes made to the Red Hat Enterprise Linux 6 operating system and its accompanying applications for this minor release, as well as known problems. Capabilities and limits of Red Hat Enterprise Linux 6 as compared to other versions of the system are available in the Red Hat Knowledgebase article available at https://access.redhat.com/articles/rhel-limits . Packages distributed with this release are listed in Red Hat Enterprise Linux 6 Package Manifest . Migration to Red Hat Enterprise Linux 7 is documented in the Migration Planning Guide. For information regarding the Red Hat Enterprise Linux life cycle, refer to https://access.redhat.com/support/policy/updates/errata/ .

Commands:
Chapter 1. Introduction to RPM The RPM Package Manager (RPM) is a package management system that runs on Red Hat Enterprise Linux (RHEL), CentOS, and Fedora. You can use RPM to distribute, manage, and update software that you create for any of these operating systems. The RPM package management system has the following advantages over distributing software in conventional archive files: RPM manages software in the form of packages that you can install, update, or remove independently of each other, which makes the maintenance of an operating system easier. RPM simplifies the distribution of software because RPM packages are standalone binary files, similar to compressed archives. These packages are built for a specific operating system and hardware architecture. RPMs contain files such as compiled executables and libraries that are placed into the appropriate paths on the filesystem when the package is installed. With RPM, you can perform the following tasks: Install, upgrade, and remove packaged software. Query detailed information about packaged software. Verify the integrity of packaged software. Build your own packages from software sources and complete build instructions. Digitally sign your packages by using the GNU Privacy Guard (GPG) utility. Publish your packages in a YUM repository. In Red Hat Enterprise Linux, RPM is fully integrated into the higher-level package management software, such as YUM or PackageKit. Although RPM provides its own command-line interface, most users need to interact with RPM only through this software. However, when building RPM packages, you must use the RPM utilities such as rpmbuild(8) . 1.1. RPM packages An RPM package consists of an archive of files and metadata used to install and erase these files. Specifically, the RPM package contains the following parts: GPG signature The GPG signature is used to verify the integrity of the package. Header (package metadata) The RPM package manager uses this metadata to determine package dependencies, where to install files, and other information. Payload The payload is a cpio archive that contains files to install to the system. There are two types of RPM packages. Both types share the file format and tooling, but have different contents and serve different purposes: Source RPM (SRPM) An SRPM contains source code and a spec file, which describes how to build the source code into a binary RPM. Optionally, the SRPM can contain patches to source code. Binary RPM A binary RPM contains the binaries built from the sources and patches. 1.2. Listing RPM packaging utilities In addition to the rpmbuild(8) program for building packages, RPM provides other utilities to make the process of creating packages easier. You can find these programs in the rpmdevtools package. Prerequisites The rpmdevtools package has been installed: Procedure Use one of the following methods to list RPM packaging utilities: To list certain utilities provided by the rpmdevtools package and their short descriptions, enter: To list all utilities, enter: Additional resources RPM utilities man pages

Commands:
yum install rpmdevtools
rpm -qi rpmdevtools
rpm -ql rpmdevtools | grep ^/usr/bin
5.285. rpmdevtools 5.285.1. RHBA-2012:1313 - rpmdevtools bug fix update Updated rpmdevtools packages that fix one bug are now available for Red Hat Enterprise Linux 6. The rpmdevtools packages contain scripts and (X)Emacs support files to aid in development of RPM packages. Bug Fix BZ# 730770 Prior to this update, the sample spec files referred to a deprecated BuildRoot tag. The tag was ignored if it was defined. This update removes the BuildRoot tags from all sample spec files. All users of rpmdevtools are advised to upgrade to these updated packages, which fix this bug.

Commands:
Power Monitoring OpenShift Container Platform 4.14 Configuring and using power monitoring for OpenShift Container Platform Red Hat OpenShift Documentation Team

Commands:
apiVersion: kepler.system.sustainable.computing.io/v1alpha1 kind: Kepler metadata: name: kepler spec: exporter: deployment: port: 9103 1 nodeSelector: kubernetes.io/os: linux 2 Tolerations: 3 - key: "" operator: "Exists" value: "" effect: ""
apiVersion: kepler.system.sustainable.computing.io/v1alpha1 kind: Kepler metadata: name: kepler status: exporter: conditions: 1 - lastTransitionTime: '2024-01-11T11:07:39Z' message: Reconcile succeeded observedGeneration: 1 reason: ReconcileSuccess status: 'True' type: Reconciled - lastTransitionTime: '2024-01-11T11:07:39Z' message: >- Kepler daemonset "kepler-operator/kepler" is deployed to all nodes and available; ready 2/2 observedGeneration: 1 reason: DaemonSetReady status: 'True' type: Available currentNumberScheduled: 2 2 desiredNumberScheduled: 2 3
apiVersion: kepler.system.sustainable.computing.io/v1alpha1 kind: Kepler metadata: name: kepler spec: exporter: deployment: redfish: secretRef: <secret_name> required 1 probeInterval: 60s 2 skipSSLVerify: false 3
<your_kubelet_node_name>,<redfish_username>,<redfish_password>,https://<redfish_ip_or_hostname>/
control-plane,exampleuser,examplepass,https://redfish.nodes.example.com worker-1,exampleuser,examplepass,https://redfish.nodes.example.com worker-2,exampleuser,examplepass,https://another.redfish.nodes.example.com
oc -n openshift-power-monitoring create secret generic redfish-secret --from-file=redfish.csv
apiVersion: v1 kind: Secret metadata: name: redfish-secret data: redfish.csv: YmFyCg== #
Chapter 5. Migrating Satellite to a New Red Hat Enterprise Linux System When you migrate your Satellite, you create a backup of your Satellite Server and your Capsule, install a fresh instance, and restore your backup on the new instance. After your migration is complete, you can then decommission the earlier instance of Satellite Server and Capsule. Terminology Ensure that you understand the following terms: Source server The origin of migration on which you create a backup. Target server The new server on which you restore the backup. High-Level Procedure To migrate your Satellite to new hardware, follow these high-level steps: Create a backup of the Satellite Server or Capsule Server on the source server. Perform a fresh installation of the Satellite Server or Capsule Server on a target server. Install a minimal Red Hat Enterprise Linux 8 instance with the capacity to store backup files. Do not install any operating system software groups or third-party applications. For more information, see Performing a standard Red Hat Enterprise Linux installation . Restore the backup on the target server. 5.1. Creating a Backup of a Server on Red Hat Enterprise Linux 7 Before you perform a fresh installation of the Satellite Server or Capsule Server on the Red Hat Enterprise Linux 8 system, back up your Satellite Server or Capsule Server data on the Red Hat Enterprise Linux 7 system by creating an offline backup. If you recently created an offline backup, you can perform an incremental backup to update the existing backup. Procedure Perform a backup on the source server: To perform a full backup, see Backing Up Satellite Server and Capsule Server in Administering Red Hat Satellite . To perform an incremental backup, see Performing an Incremental Backup in Administering Red Hat Satellite . 5.2. Performing a Fresh Installation of a Server on Red Hat Enterprise Linux 8 After you have created a backup of the Satellite Server or Capsule Server on the source server, you can install Satellite Server or Capsule Server on the target server. To install connected Satellite Server, see Installing Satellite Server in a Connected Network Environment . To install disconnected Satellite Server, see Installing Satellite Server in a Disconnected Network Environment . To install Capsule Server, see Installing Capsule Server . 5.3. Restoring a Backup of a Server on Red Hat Enterprise Linux 8 After you perform a fresh installation of Satellite Server or Capsule Server on the target server, you can restore the backup you previously created. Procedure Restore a backup on the target server: To restore a full backup, see Restoring From a Full Backup in Administering Red Hat Satellite . To restore an incremental backup, see Restoring From Incremental Backups in Administering Red Hat Satellite . Reindex the databases:

Commands:
runuser -u postgres -- reindexdb -a
7.188. sapconf 7.188.1. RHBA-2015:1329 - sapconf bug fix and enhancement update An updated sapconf package that fixes several bugs and adds two enhancements is now available for Red Hat Enterprise Linux 6. The sapconf package contains a script that checks the basic installation of Red Hat Enterprise Linux and modifies it according to SAP requirements. The script ensures that all necessary packages are installed and that configuration parameters are set correctly to run SAP software. Bug Fixes BZ# 1158407 Prior to this update, the sapconf package was not updated to reflect the changes made to the profiles of the tuned daemon for SAP NetWeaver. As a consequence, As a consequence, the activation of a tuned profile searched for the deprecated "sap" profile, and therefore failed. With this update, using the sapconf script installs the tuned-profiles-sap package if it is not already installed. In addition, the TUNED_SAP_PROFILE variable has been changed to "sap-netweaver". As a result, sapconf now properly uses the "sap-netweaver" profile, and activating a tuned profile proceeds as expected. BZ# 1168422 Previously, the sapconf script set an incorrect value for the MAX_MAP_COUNT_MIN variable. The value has been changed, and sapconf now matches the recommended value from SAP Red Hat Enterprise Linux 6.x Installation Guide. BZ# 1173861 In the SELinux permissive mode, the parameter with the path to the configuration file was missing. As a consequence, the sapconf script was waiting for the user input, which led to sapconf becoming unresponsive. The underlying source code has been fixed, and sapconf no longer hangs in the aforementioned situation. Enhancements BZ# 1123917 The sapconf manual page has been edited to contain more accurate information. BZ# 1174321 With this update, the output of the sapconf script contains also the information about the version of sapconf, which is practical to know for SAP installation or updates. Users of sapconf are advised to upgrade to this updated package, which fixes these bugs and adds these enhancements.

Commands:
20.3. Changing Passwords Stored Externally While most passwords can be changed through ldapmodify operations, there are some passwords that cannot be changed through regular LDAP operations. These passwords may be stored outside the Directory Server, such as passwords stored in a SASL application. These passwords can be modified through the password change extended operation . Directory Server supports the password change extended operation as defined in RFC 3062, so users can change their passwords, using a suitable client, in a standards-compliant way. The dsidm utility passes the changes for the password for the specified user: Important Password operations must be performed over a secure connection, meaning SASL, TLS, or STARTTLS. For information on using secure connections with LDAP client tools, see Section 9.9.4, "Authenticating Using a Certificate" . For further details about the parameters, see the output of the dsidm instance_name account change_password --help command. To use STARTTLS, which runs the command on a non-secure port, run dsidm with the -Z option and the standard LDAP port number. The password extended change operation has the following format: Note For STARTTLS connections to work, the TLS environment variables must be configured as described in Section 9.9.4, "Authenticating Using a Certificate" . Use the -Z option to force the connection to be successful. To modify an entry's password, run dsidm like any other operation. It is necessary to specify a bind DN, even if the account is the same as that given in the bind DN. For example: Access control is enforced for the password change operation. If the bind DN does not have rights to change the specified password, the operation will fail with an Insufficient rights error.

Commands:
dsidm ldap://server.example.com -D bind_dn -W -b dc=example,dc=com account change_password user newPassword oldPassword
dsidm ldap://server.example.com -Z bind_dn -W -b dc=example,dc=com account change_password user newPassword oldPassword
dsidm ldap://server.example.com -Z bind_dn -W -b dc=example,dc=com account change_password user newPassword oldPassword
2.14. RHEA-2011:0660 - new package: kdewebdev New kdewebdev packages are now available for Red Hat Enterprise Linux 6. KDEWebdev provides a set of KDE-based programmers' utilities for web development. KDEWebdev provides a web-based integrated development environment (Web IDE), a stylesheet debugger, and a utility to search and replace strings. (BZ# 591964 ) All users who wish to use the KDE-based set of web applications are advised to install this new package.

Commands:
probe::ioscheduler.elv_add_request.kp Name probe::ioscheduler.elv_add_request.kp - kprobe based probe to indicate that a request was added to the request queue Synopsis Values disk_major Disk major number of the request rq Address of the request q pointer to request queue name Name of the probe point elevator_name The type of I/O elevator currently enabled disk_minor Disk minor number of the request rq_flags Request flags

Commands:
ioscheduler.elv_add_request.kp
1.4. Setting the Development Environment For JBoss Developer Studio, create an empty java project and add "teiid-common-core", "teiid-api" and JEE "connector-api" JARs as dependencies. For using Maven, use the following dependencies: <dependencies> <dependency> <groupId>org.jboss.teiid</groupId> <artifactId>teiid-api</artifactId> <version>USD{teiid-version}</version> <scope>provided</scope> </dependency> <dependency> <groupId>org.jboss.teiid</groupId> <artifactId>teiid-common-core</artifactId> <version>USD{teiid-version}</version> <scope>provided</scope> </dependency> <dependency> <groupId>javax.resource</groupId> <artifactId>connector-api</artifactId> <version>USD{connector-api-version}</version> <scope>provided</scope> </dependency> </dependencies> The teiid-version property must be set to the expected version. You must also add the new declared property connector-api-version . You can find relevant artifacts in the Maven repository.

Commands:
<dependencies> <dependency> <groupId>org.jboss.teiid</groupId> <artifactId>teiid-api</artifactId> <version>USD{teiid-version}</version> <scope>provided</scope> </dependency> <dependency> <groupId>org.jboss.teiid</groupId> <artifactId>teiid-common-core</artifactId> <version>USD{teiid-version}</version> <scope>provided</scope> </dependency> <dependency> <groupId>javax.resource</groupId> <artifactId>connector-api</artifactId> <version>USD{connector-api-version}</version> <scope>provided</scope> </dependency> </dependencies>
Appendix A. Appendix Configuration from sample environment file The environment file that you created in Chapter 2, Creating the environment file configures the Block Storage service to use two NetApp back ends. The following snippet displays the relevant settings:

Commands:
enabled_backends = netapp1,netapp2 [netapp1] volume_backend_name=netapp_1 volume_driver=cinder.volume.drivers.netapp.common.NetAppDriver netapp_login=root netapp_storage_protocol=iscsi netapp_password=p@USDUSDw0rd netapp_storage_family=ontap_7mode netapp_server_port=80 netapp_server_hostname=10.35.64.11 [netapp2] volume_backend_name=netapp_2 volume_driver=cinder.volume.drivers.netapp.common.NetAppDriver netapp_login=root netapp_storage_protocol=iscsi netapp_password=p@USDUSDw0rd netapp_storage_family=ontap_7mode netapp_server_port=80 netapp_server_hostname=10.35.64.11