mtpti5iD/redhat-docs_dataset huggingface dataset:
15.2.2. Installing RPM packages typically have file names like foo-1.0-1.i386.rpm . The file name includes the package name ( foo ), version ( 1.0 ), release ( 1 ), and architecture ( i386 ). To install a package, log in as root and type the following command at a shell prompt: If installation is successful, the following output is displayed: As you can see, RPM prints out the name of the package and then prints a succession of hash marks as the package is installed as a progress meter. The signature of a package is checked automatically when installing or upgrading a package. The signature confirms that the package was signed by an authorized party. For example, if the verification of the signature fails, an error message such as the following is displayed: If it is a new, header-only, signature, an error message such as the following is displayed: If you do not have the appropriate key installed to verify the signature, the message contains the word NOKEY such as: Refer to Section 15.3, "Checking a Package's Signature" for more information on checking a package's signature. Warning If you are installing a kernel package, you should use rpm -ivh instead. Refer to Chapter 36, Manually Upgrading the Kernel for details. Installing packages is designed to be simple, but you may sometimes see errors. 15.2.2.1. Package Already Installed If the package of the same version is already installed, the following is displayed: If the same version you are trying to install is already installed, and you want to install the package anyway, you can use the --replacepkgs option, which tells RPM to ignore the error: This option is helpful if files installed from the RPM were deleted or if you want the original configuration files from the RPM to be installed.

Commands:
-Uvh foo-1.0-1.i386.rpm
Preparing... ########################################### [100%] 1:foo ########################################### [100%]
error: V3 DSA signature: BAD, key ID 0352860f
error: Header V3 DSA signature: BAD, key ID 0352860f
warning: V3 DSA signature: NOKEY, key ID 0352860f
Preparing... ########################################### [100%] package foo-1.0-1 is already installed
-ivh --replacepkgs foo-1.0-1.i386.rpm
15.7. Removing a Host from a Self-Hosted Engine Environment To remove a self-hosted engine node from your environment, place the node into maintenance mode, undeploy the node, and optionally remove it. The node can be managed as a regular host after the HA services have been stopped, and the self-hosted engine configuration files have been removed. Removing a Host from a Self-Hosted Engine Environment In the Administration Portal, click Compute Hosts and select the self-hosted engine node. Click Management Maintenance and click OK . Click Installation Reinstall . Click the Hosted Engine tab and select UNDEPLOY from the drop-down list. This action stops the ovirt-ha-agent and ovirt-ha-broker services and removes the self-hosted engine configuration file. Click OK . Optionally, click Remove to open the Remove Host(s) confirmation window and click OK .

Commands:
Appendix A. Troubleshooting: Remote jobs timing out after yggdrasil update On hosts that have weak dependencies disabled and are configured to use the yggdrasil pull client, remote jobs can start failing due to timeouts after the yggdrasil package has been updated to version 0.4.z or later. The pull-based transport configuration relies on the Yggdrasil service and differs based on the version of the yggdrasil package that is installed on the host. For pull-based remote execution mode to work correctly after yggdrasil version 0.4.z is installed on the host, the Yggdrasil client configuration must be updated. Installing the foreman_ygg_migration package on the host ensures that Satellite applies the required changes to Yggdrasil configuration. On hosts with weak dependencies enabled, Satellite automatically installs the foreman_ygg_migration package. No further steps are required. On hosts with weak dependencies disabled, you must install the foreman_ygg_migration package manually. Procedure Determine which version of the yggdrasil package is installed on the host: If your host has yggdrasil version 0.4.z or later installed, the yggdrasil and com.redhat.Yggdrasil1.Worker1.foreman services are expected to be running. Check the status of these services: If the above services are not running, it means that Yggdrasil might not be configured correctly. Install the foreman_ygg_migration package manually: Installing foreman_ygg_migration ensures that Satellite applies the required Yggdrasil configuration changes and enables remote execution in pull mode to work as expected. Verification Check the status of the Yggdrasil services again: These services should now be running.

Commands:
rpm --query yggdrasil
systemctl status yggdrasil com.redhat.Yggdrasil1.Worker1.foreman
dnf install foreman_ygg_migration
systemctl status yggdrasil com.redhat.Yggdrasil1.Worker1.foreman
9.10. Using SELinux Policies SELinux is a collection of mandatory access control rules which are enforced across a system to restrict unauthorized access and tampering. SELinux categorizes files, directories, ports, processes, users, and other objects on the server. Each object is placed in an appropriate security context to define how the object is allowed to behave on the server through its role, user, and security level. These roles for objects are grouped in domains, and SELinux rules define how the objects in one domain are allowed to interact with objects in another domain. Directory Server has the following domains: dirsrv_t for the Directory Server dirsrv_snmp_t for the SNMP Directory Server also uses one additional, default domains for LDAP ports: ldap_port_t Figure 9.4. Editing Directory Server File Labeling These domains provide security contexts for all of the processes, files, directories, ports, sockets, and users for the Directory Server. Files and directories for each instance are labeled with a specific SELinux context. (Most of the main directories used by Directory Server have subdirectories for all local instances, no matter how many, so a single policy is easily applied to new instances.) The ports for each instance are labeled with a specific SELinux context. All Directory Server processes are constrained within the appropriate domain. Each domain has specific rules that define what actions are authorized for the domain. Any access not specified in the SELinux policy is denied to the instance. SELinux has three different levels of enforcement: disabled (no SELinux), permissive (where the rules are processed but not enforced), and enforcing (where all rules are strictly enforced). Red Hat Directory Server has defined SELinux policies that allow it to run as normal under strict SELinux enforcing mode, with a caveat. The Directory Server can run in different modes, one for normal operations and one for database operations like importing (ldif2db mode). The SELinux policies for the Directory Server only apply to normal mode. By default, the Directory Server runs confined by SELinux policies.

Commands:
4.2.2. Blacklisting By Device Name You can blacklist device types by device name so that they will not be grouped into a multipath device by specifying a devnode entry in the devnode_blacklist section of the configuration file. The following example shows the lines in the configuration file that would blacklist all SCSI devices, since it blacklists all sd* devices. You can use a devnode entry in the blacklist section of the configuration file to specify individual devices to blacklist rather than all devices of specific type; this is not recommended, however. Unless it is statically mapped by udev rules, there is no guarantee that a specific device will have the same name on reboot. For example, a device name could change from /dev/sda to /dev/sdb on reboot. By default, the following devnode entries are compiled in the default blacklist; the devices that these entries blacklist do not generally support DM-Multipath.

Commands:
devnode_blacklist { devnode "^sd[a-z]" }
blacklist { devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*" devnode "^hd[a-z]" devnode "^cciss!c[0-9]d[0-9]*" }
7.217. tree 7.217.1. RHBA-2015:0049 - tree bug fix update Updated tree packages that fix one bug are now available for Red Hat Enterprise Linux 6. The tree package contains the tree utility that recursively displays the contents of directories in a tree-like format. Tree is basically a UNIX port of the DOS tree utility. Bug Fix BZ# 1110559 Previously, buffer overflows could occur in the uidtoname() and gidtoname() functions of the tree utility. As a consequence, using the "tree" command in some cases failed and the following error message was displayed to the user: An upstream patch has been backported to fix the problem, and the tree utility now lists files as expected. Users of tree are advised to upgrade to these updated packages, which fix this bug.

Commands:
*** buffer overflow detected ***: tree terminated
2.5. Post-installation Procedures The following steps are the security-related procedures that should be performed immediately after installation of Red Hat Enterprise Linux. Update your system. enter the following command as root: Even though the firewall service, firewalld , is automatically enabled with the installation of Red Hat Enterprise Linux, there are scenarios where it might be explicitly disabled, for example in the kickstart configuration. In such a case, it is recommended to consider re-enabling the firewall. To start firewalld enter the following commands as root: To enhance security, disable services you do not need. For example, if there are no printers installed on your computer, disable the cups service using the following command: To review active services, enter the following command:

Commands:
~]# yum update
~]# systemctl start firewalld ~]# systemctl enable firewalld
~]# systemctl disable cups
~]USD systemctl list-units | grep service
8.175. perl-TimeDate 8.175.1. RHBA-2014:1425 - perl-TimeDate bug fix update An updated perl-TimeDate package that fixes one bug is now available for Red Hat Enterprise Linux 6. perl-TimeDate is a perl library that parses time and date information. Bug Fix BZ# 993222 Previously, some time zones were missing in the perl-TimeDate package, so the user could not set, for example, the Alaska Standard time zone. Support for the missing time zones has been added to the Time/Zone.pm module, namely the following: AEDT Eastern Australian Daylight AEST Eastern Australian Standard AKDT Alaska Daylight AKST Alaska Standard METDST Middle European DST MSD Moscow Daylight MSK Moscow As a result, the list of time zones in Time/Zone.pm is now complete. Users of perl-TimeDate are advised to upgrade to this updated package, which fixes this bug.

Commands:
Chapter 7. References 7.1. Red Hat Installing RHEL 9 for SAP Solutions Configuring and managing high availability clusters Support Policies for RHEL High Availability Clusters Support Policies for RHEL High Availability Clusters - Fencing/STONITH Support Policies for RHEL High Availability Clusters - Management of SAP HANA in a Cluster Red Hat HA Solutions for SAP HANA, S/4HANA and NetWeaver based SAP Applications Configuring quorum devices The Systemd-Based SAP Startup Framework Why does the stop operation of a SAPHana resource agent fail when the systemd based SAP startup framework is enabled? 7.2. SAP SAP HANA Server Installation and Update Guide SAP HANA System Replication Implementing a HA/DR Provider SAP Note 2057595 - FAQ: SAP HANA High Availability SAP Note 2063657 - SAP HANA System Replication Takeover Decision Guideline SAP Note 2235581 - SAP HANA: Supported Operating Systems SAP Note 2369981 - Required configuration steps for authentication with HANA System Replication SAP Note 2972496 - SAP HANA Filesystem Types SAP Note 3007062 - FAQ: SAP HANA & Third Party Cluster Solutions SAP Note 3115048 - sapstartsrv with native Linux systemd support SAP Note 3139184 - Linux: systemd integration for sapstartsrv and SAP Host Agent SAP Note 3189534 - Linux: systemd integration for sapstartsrv and SAP HANA 7.3. Other Be Prepared for Using Pacemaker Cluster for SAP HANA - Part 1: Basics Be Prepared for Using Pacemaker Cluster for SAP HANA - Part 2: Failure of Both Nodes

Commands:
Chapter 10. Error handling Errors in AMQ C++ can be handled in two different ways: Catching exceptions Overriding event-handling functions to intercept AMQP protocol or connection errors Catching exceptions is the most basic, but least granular, way to handle errors. If an error is not handled using an override in a handler function, an exception is thrown. 10.1. Catching exceptions If an error is not handled using an override in an event-handling function, an exception is thrown by the container's run method. All of the exceptions that AMQ C++ throws inherit from the proton::error class, which in turn inherits from the std::runtime_error and std::exception classes. The following example illustrates how to catch any exception thrown from AMQ C++: Example: API-specific exception handling try { // Something that might throw an exception } catch (proton::error& e) { // Handle Proton-specific problems here } catch (std::exception& e) { // Handle more general problems here } If you do not require API-specific exception handling, you only need to catch std::exception , since proton::error inherits from it. 10.2. Handling connection and protocol errors You can handle protocol-level errors by overriding the following messaging_handler methods: on_transport_error(proton::transport&) on_connection_error(proton::connection&) on_session_error(proton::session&) on_receiver_error(proton::receiver&) on_sender_error(proton::sender&) These event handling routines are called whenever there is an error condition with the specific object that is in the event. After calling the error handler, the appropriate close handler is also called. If one of the more specific error handlers is not overridden, the default error handler is called: on_error(proton::error_condition&) Note Because the close handlers are called in the event of any error, only the error itself needs to be handled within the error handler. Resource cleanup can be managed by close handlers. If there is no error handling that is specific to a particular object, it is typical to use the general on_error handler and not have a more specific handler. Note When reconnect is enabled and the remote server closes a connection with the amqp:connection:forced condition, the client does not treat it as an error and thus does not fire the on_connection_error handler. The client instead begins the reconnection process.

Commands:
try { // Something that might throw an exception } catch (proton::error& e) { // Handle Proton-specific problems here } catch (std::exception& e) { // Handle more general problems here }
Chapter 12. Volume cloning A clone is a duplicate of an existing storage volume that is used as any standard volume. You create a clone of a volume to make a point in time copy of the data. A persistent volume claim (PVC) cannot be cloned with a different size. You can create up to 512 clones per PVC for both CephFS and RADOS Block Device (RBD). 12.1. Creating a clone Prerequisites Source PVC must be in Bound state and must not be in use. Note Do not create a clone of a PVC if a Pod is using it. Doing so might cause data corruption because the PVC is not quiesced (paused). Procedure Click Storage Persistent Volume Claims from the OpenShift Web Console. To create a clone, do one of the following: Beside the desired PVC, click Action menu (...) Clone PVC . Click on the PVC that you want to clone and click Actions Clone PVC . Enter a Name for the clone. Select the access mode of your choice. Important The ReadOnlyMany (ROX) access mode is a Developer Preview feature and is subject to Developer Preview support limitations. Developer Preview releases are not intended to be run in production environments and are not supported through the Red Hat Customer Portal case management system. If you need assistance with ReadOnlyMany feature, reach out to the ocs-devpreview@redhat.com mailing list and a member of the Red Hat Development Team will assist you as quickly as possible based on availability and work schedules. See Creating a clone or restoring a snapshot with the new readonly access mode to use the ROX access mode. Click Clone . You are redirected to the new PVC details page. Wait for the cloned PVC status to become Bound . The cloned PVC is now available to be consumed by the pods. This cloned PVC is independent of its dataSource PVC.

Commands:
36.4. Performing the Upgrade After retrieving all of the necessary packages, it is time to upgrade the existing kernel. At a shell prompt, as root, change to the directory that contains the kernel RPM packages and follow these steps. Important It is strongly recommended that the old kernel is kept in case there are problems with the new kernel. Use the -i argument with the rpm command to keep the old kernel. Do not use the -U option, since it overwrites the currently installed kernel, which creates boot loader problems. Issue the following command (the kernel version may vary): If the system is a multi-processor system, install the kernel-smp packages as well (the kernel version may vary): If the system is i686 -based and contains more than 4 GB of RAM, install the kernel-hugemem package built for the i686 architecture as well (the kernel version might vary): The step is to verify that the initial RAM disk image has been created. Refer to Section 36.5, "Verifying the Initial RAM Disk Image" for details.

Commands:
-ivh kernel-2.6.9-5.EL. <arch> .rpm
-ivh kernel-smp-2.6.9-5.EL. <arch> .rpm
-ivh kernel-hugemem-2.6.9-5.EL.i686.rpm
Chapter 8. Setting up a Custom Git Trigger A Custom Git Trigger is a generic way for any git server to act as a build trigger. It relies solely on SSH keys and webhook endpoints; everything else is left to the user to implement. 8.1. Creating a Trigger Creating a Custom Git Trigger is similar to the creation of any other trigger with a few subtle differences: It is not possible for Red Hat Quay to automatically detect the proper robot account to use with the trigger. This must be done manually in the creation process. There are extra steps after the creation of the trigger that must be done in order to use the trigger. These steps are detailed below. 8.2. Post trigger-creation setup Once a trigger has been created, there are 2 additional steps required before the trigger can be used: Provide read access to the SSH public key generated when creating the trigger. Setup a webhook that POSTs to the Red Hat Quay endpoint to trigger a build. The key and the URL are both available at all times by selecting View Credentials from the gear located in the trigger listing. 8.2.1. SSH public key access Depending on the Git server setup, there are various ways to install the SSH public key that Red Hat Quay generates for a custom git trigger. For example, Git documentation describes a small server setup in which simply adding the key to USDHOME/.ssh/authorize_keys would provide access for builders to clone the repository. For any git repository management software that isn't officially supported, there is usually a location to input the key often labeled as Deploy Keys . 8.2.2. Webhook In order to automatically trigger a build, one must POST a JSON payload to the webhook URL with the following format: Note This request requires a Content-Type header containing application/json in order to be valid. Once again, this can be accomplished in various ways depending on the server setup, but for most cases can be done via a post-receive git hook .

Commands:
{ "commit": "1c002dd", // required "ref": "refs/heads/master", // required "default_branch": "master", // required "commit_info": { // optional "url": "gitsoftware.com/repository/commits/1234567", // required "message": "initial commit", // required "date": "timestamp", // required "author": { // optional "username": "user", // required "avatar_url": "gravatar.com/user.png", // required "url": "gitsoftware.com/users/user" // required }, "committer": { // optional "username": "user", // required "avatar_url": "gravatar.com/user.png", // required "url": "gitsoftware.com/users/user" // required } } }
function::stack Name function::stack - Return address at given depth of kernel stack backtrace Synopsis Arguments n number of levels to descend in the stack. Description Performs a simple (kernel) backtrace, and returns the element at the specified position. The results of the backtrace itself are cached, so that the backtrace computation is performed at most once no matter how many times stack is called, or in what order.

Commands:
stack:long(n:long)
Chapter 60. Storage LVM does not support event-based autoactivation of incomplete volume groups If a volume group is not complete and physical volumes are missing, LVM does not support automatic LVM event-based activation of that volume group. This implies a setting of --activationmode complete whenever autoactivation takes place. For information on the --activationmode complete option and automatic activation, see the vgchange(8) and pvscan(8) man pages. Note that the event-driven autoactivation hooks are enabled when lvmetad is enabled with the global/use_lvmetad=1 setting in the /etc/lvm/lvm.conf configuration file. Also note that without autoactivation, there is a direct activation hook at the exact time during boot at which the volume groups are activated with only the physical volumes that are available at that time. Any physical volumes that appear later are not taken into account. This issue does not affect early boot in initramfs ( dracut ) nor does this affect direct activation from the command line using vgchange and lvchange calls, which default to degraded activation mode. (BZ# 1337220 ) The vdo service is disabled after upgrading to Red Hat Enterprise Linux 7.6 Upgrading from Red Hat Enterprise Linux 7.5 to 7.6 disables the vdo service if it was previously enabled. This is because of missing systemd macros in the vdo RPM package. The problem has been fixed in the 7.6 release, and upgrading from Red Hat Enterprise Linux 7.6 to a later release will no longer disable vdo . (BZ#1617896) Data corruption occurs on RAID 10 reshape on top of VDO. RAID 10 reshape (with both LVM and mdadm ) on top of VDO corrupts data. Stacking RAID 10 (or other RAID types) on top of VDO does not take advantage of the deduplication and compression capabilities of VDO and is not recommended. (BZ# 1528466 , BZ#1530776) System boot is sometimes delayed by ndctl A udev rule installed by the ndctl package sometimes delays the system boot process for several minutes on systems with Non-Volatile Dual In-line Memory Module (NVDIMM) devices. In such cases, systemd displays a message similar to the following: To work around the issue, disable the udev rule using the following command: After disabling the udev rule, the described problem no longer occurs. (BZ#1635441) LVM might cause data corruption in the first 128kB of allocatable space of a physical volume A bug in the I/O layer of LVM causes LVM to read and write back the first 128kB of data that immediately follows the LVM metadata on the disk. If another program or the file system is modifying these blocks when you use an LVM command, changes might be lost. As a consequence, this might lead to data corruption in rare cases. To work around this problem, avoid using LVM commands that change volume group (VG) metadata, such as lvcreate or lvextend , while logical volumes (LVs) in the VG are in use. (BZ# 1643651 )

Commands:
INFO: task systemd-udevd:1554 blocked for more than 120 seconds. nvdimm_bus_check_dimm_count+0x31/0xa0 [libnvdimm]
rm /usr/lib/udev/rules.d/80-ndctl.rules