mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 2. Exporting and downloading a manifest Export a manifest from the Hybrid Cloud Console to manage the subscriptions that it contains from within your Satellite instance. Exporting and downloading a new copy of the manifest is required whenever you add or remove subscriptions from the manifest. Prerequisites You are logged in to the Red Hat Hybrid Cloud Console. You are connected to a Red Hat Satellite Server. You have Red Hat Satellite 6 or later. You have the Subscriptions administrator role in the role-based access control (RBAC) system for the Red Hat Hybrid Cloud Console. Procedure To export and download a manifest, complete the following steps: From the Hybrid Cloud Console home page, click Services > Subscriptions and Spend > Manifests . From the Manifests page, click the name of the manifest that you want to export. Click Export manifest . Important Do not refresh the page while the manifest is exporting. Refreshing the page will disrupt the process. When the manifest is exported successfully, a notification window opens. From the notification window, click Download manifest . Note The application encodes the selected subscription certificates and creates a compressed file in .zip format. This file is the subscription manifest that you can upload into Satellite Server. The file saves to your default downloads folder. After you download the manifest, you can import it into your Satellite Server. You can then use the Satellite web UI to update the manifest and refresh it to reflect the changes. Alternatively, you can import an updated manifest that contains the changes. Additional resources For more information about importing your manifest into Satellite, see Importing a Subscription Manifest into Satellite Server in the Red Hat Satellite Content Management Guide . For more information about using Satellite to manage your Red Hat subscriptions, see Managing Subscriptions .

Commands:
10.6. Cluster Service Will Not Start If a cluster-controlled service will not start, check for the following conditions. There may be a syntax error in the service configuration in the cluster.conf file. You can use the rg_test command to validate the syntax in your configuration. If there are any configuration or syntax faults, the rg_test will inform you what the problem is. For more information on the rg_test command, see Section C.5, "Debugging and Testing Services and Resource Ordering" . If the configuration is valid, then increase the resource group manager's logging and then read the messages logs to determine what is causing the service start to fail. You can increase the log level by adding the loglevel="7" parameter to the rm tag in the cluster.conf file. You will then get increased verbosity in your messages logs with regards to starting, stopping, and migrating clustered services.

Commands:
rg_test test /etc/cluster/cluster.conf start service servicename
30.2. sudo Rules in Identity Management Using sudo rules, you can define who can do what , where , and as whom . Who are the users allowed to use sudo . What are the commands that can be used with sudo . Where are the target hosts on which the users are allowed to use sudo . As whom is the system or other user identity which the users assume to perform tasks. 30.2.1. External Users and Hosts in sudo Rules IdM accepts external entities in sudo rules. External entities are entities that are stored outside of the IdM domain, such as users or hosts that are not part of the IdM domain. For example, you can use sudo rules to grant root access to a member of the IT group in IdM, where the root user is not a user defined in the IdM domain. Or, for another example, administrators can block access to certain hosts that are on a network but are not part of the IdM domain. 30.2.2. User Group Support for sudo Rules You can use sudo to give access to whole user groups in IdM. IdM supports both Unix and non-POSIX groups. Note that creating non-POSIX groups can cause access problems because any users in a non-POSIX group inherit non-POSIX permissions from the group. 30.2.3. Support for sudoers Options IdM supports sudoers options. For a complete list of the available sudoers options, see the sudoers (5) man page. Note that IdM does not allow white spaces or line breaks in sudoers options. Therefore, instead of supplying multiple options in a comma-separated list, add them separately. For example, to add two sudoers options from the command line: Similarly, make sure to supply long options on one line. For example, from the command line:

Commands:
ipa sudorule-add-option sudo_rule_name Sudo Option: first_option ipa sudorule-add-option sudo_rule_name Sudo Option: second_option
ipa sudorule-add-option sudo_rule_name Sudo Option: env_keep="COLORS DISPLAY EDITOR HOSTNAME HISTSIZE INPUTRC KDEDIR LESSSECURE LS_COLORS MAIL PATH PS1 PS2 XAUTHORITY"
Chapter 4. sVirt 4.1. Introduction Since virtual machines under KVM are implemented as Linux processes, KVM leverages the standard Linux security model to provide isolation and resource controls. The Linux kernel includes SELinux (Security-Enhanced Linux), a project developed by the US National Security Agency to add mandatory access control (MAC), multi-level security (MLS) and multi-category security (MCS) through a flexible and customizable security policy. SELinux provides strict resource isolation and confinement for processes running on top of the Linux kernel, including virtual machine processes. The sVirt project builds upon SELinux to further facilitate virtual machine isolation and controlled sharing. For example, fine-grained permissions could be applied to group virtual machines together to share resources. From a security point of view, the hypervisor is a tempting target for attackers, as a compromised hypervisor could lead to the compromise of all virtual machines running on the host system. Integrating SELinux into virtualization technologies helps improve hypervisor security against malicious virtual machines trying to gain access to the host system or other virtual machines. Refer to the following image which represents isolated guests, limiting the ability for a compromised hypervisor (or guest) to launch further attacks, or to extend to another instance: Figure 4.1. Attack path isolated by SELinux Note For more information on SELinux, refer to Red Hat Enterprise Linux Security-Enhanced Linux .

Commands:
7.2. What is LVM2? LVM version 2, or LVM2, is the default for Red Hat Enterprise Linux, which uses the device mapper driver contained in the 2.6 kernel. LVM2, which is almost completely compatible with the earlier LVM1 version, can be upgraded from versions of Red Hat Enterprise Linux running the 2.4 kernel. Although upgrading from LVM1 to LVM2 is usually seamless, refer to Section 7.3, "Additional Resources" for further details on more complex requirements and upgrading scenarios.

Commands:
Chapter 5. Removing a system from a group If you no longer want a system in a group in the Insights Inventory application, you can remove it. For example, if a system no longer needs to be managed with other systems of a group, you can remove it. Prerequisites You have a Red Hat Hybrid Cloud Console account. You have already grouped systems registered with the Insights Inventory application. Procedure Access Red Hat Hybrid Cloud Console platform and log in. From the console dashboard, navigate to Red Hat Insights > RHEL > Inventory > Groups . On the Groups page, use the Filter by name search box to find the group you want to modify, and then click the name of the group. Select the systems you want to remove. In the Group toolbar, click the Actions for group details menu, which is three vertical dots. Click Remove from group . Then, confirm and click Remove .

Commands:
2.24. RHEA-2011:0709 - new package: perl-IO-Tty A new perl-IO-Tty package is now available for Red Hat Enterprise Linux 6. The perl-IO-Tty package provides the IO::Tty and IO::Pty Perl modules that allow for the creation of a pseudo-tty (Berkeley Unix networking device). This package allows to determine the correct terminal width even for terminals with less than 50 columns. This new package adds the IO::Tty and IO::Pty Perl modules to Red Hat Enterprise Linux 6. (BZ# 669405 ) All users of pseudo-tty devises are advised to install this new package.

Commands:
32.5. Using sadump on Fujitsu PRIMEQUEST systems On Fujitsu PRIMEQUEST systems, you can also enable the stand-alone dump ( sadump ) functionality provided by the hardware. This utility operates by combining kdump , which is a standard part of Red Hat Enterprise Linux, and the additional sadump BIOS-based function provided by Fujitsu. Note For the purpose of ensuring a dump is captured in the event of an unexpected reboot, Fujitsu recommend that sadump is always enabled on PRIMEQUEST hardware. The sadump utility is usually invoked when a kdump cannot be processed because Red Hat Enterprise Linux has became unresponsive. These conditions can include: Red Hat Enterprise Linux panic or hang before kdump starts An error while kdump is working How to use sadump To use sadump , complete the following steps: Install the following packages according to the kernel version in use: Configure UEFI for sadump For more details, see the FUJITSU Server PRIMEQUEST 2000 Series Installation Manual. Configure Red Hat Enterprise Linux for sadump For more details, see Section 32.5.1, "Configure Red Hat Enterprise Linux for sadump" . Start sadump For more details, see the FUJITSU Server PRIMEQUEST 2000 Series Installation Manual. Check the memory dump For more details, see Section 32.5.2, "Check the memory dump" . 32.5.1. Configure Red Hat Enterprise Linux for sadump Install and configure kdump as described in Section 32.1, "Installing the kdump Service" and Section 32.2, "Configuring the kdump Service" . Ensure that kdump starts as expected for sadump : Configure Red Hat Enterprise Linux to not reboot after a kernel panic: By default, Red Hat Enterprise Linux reboots automatically after a kernel panic, which prevents sadump to start. To avoid this behavior, configure the /etc/sysctl.conf file as follows: Configure Red Hat Enterprise Linux to start kdump by Nonmaskable Interrupt (NMI): In the procedure of starting sadump , starting kdump by NMI is needed at first. Configure /etc/sysctl.conf as follows: Ensure that kdump behaves correctly for sadump : Configure Red Hat Enterprise Linux to stop after kdump : By default, Red Hat Enterprise Linux reboots automatically when kdump fails, which prevents sadump to start. To avoid this behavior, configure the /etc/kdump.conf file as follows: or Configure Red Hat Enterprise Linux to start sadump : Configure /etc/kdump.conf to not block the System Management Interrupt (SMI) and thus to enable sadump to start:

Commands:
yum install kernel-debuginfo kernel-debuginfo-common
kernel.panic=0
kernel.unknown_nmi_panic=1
default halt
default shell
blacklist kvm-intel
3.3.3. Converting a local Xen virtual machine Ensure that the guest virtual machine's XML is available locally, and that the storage referred to in the XML is available locally at the same paths. To convert the virtual machine from an XML file, run: Where pool is the local storage pool to hold the image, bridge_name is the name of a local network bridge to connect the converted virtual machine's network to, and guest_name.xml is the path to the virtual machine's exported XML. You may also use the --network parameter to connect to a locally managed network if your virtual machine only has a single network interface. If your virtual machine has multiple network interfaces, edit /etc/virt-v2v.conf to specify the network mapping for all interfaces. If your virtual machine uses a Xen paravirtualized kernel (it would be called something like kernel-xen or kernel-xenU ), virt-v2v will attempt to install a new kernel during the conversion process. You can avoid this requirement by installing a regular kernel, which will not reference a hypervisor in its name, alongside the Xen kernel prior to conversion. You should not make this newly installed kernel your default kernel, because Xen will not boot it. virt-v2v will make it the default during conversion. Note When converting from Xen, virt-v2v requires that the image of the source virtual machine exists in a storage pool. If the image is not currently in a storage pool, you must create one. Contact Red Hat Support for assistance creating an appropriate storage pool. Note Presently, there is a known issue with importing Citrix Xen virtual machines to run on KVM or Red Hat Enterprise Virtualization. For more information, see https://access.redhat.com/solutions/54076 .

Commands:
virt-v2v -i libvirtxml -op pool --bridge bridge_name guest_name.xml
Chapter 5. Monitoring and managing upgrade of the storage cluster After running the ceph orch upgrade start command to upgrade the Red Hat Ceph Storage cluster, you can check the status, pause, resume, or stop the upgrade process. The health of the cluster changes to HEALTH_WARNING during an upgrade. If the host of the cluster is offline, the upgrade is paused. Note You have to upgrade one daemon type after the other. If a daemon cannot be upgraded, the upgrade is paused. Prerequisites A running Red Hat Ceph Storage cluster. Root-level access to all the nodes. At least two Ceph Manager nodes in the storage cluster: one active and one standby. Upgrade for the storage cluster initiated. Procedure Determine whether an upgrade is in process and the version to which the cluster is upgrading: Example Note You do not get a message once the upgrade is successful. Run ceph versions and ceph orch ps commands to verify the new image ID and the version of the storage cluster. Optional: Pause the upgrade process: Example Optional: Resume a paused upgrade process: Example Optional: Stop the upgrade process: Example

Commands:
ceph orch upgrade status
ceph orch upgrade pause
ceph orch upgrade resume
ceph orch upgrade stop
4.3. Profiling The following sections showcase scripts that profile kernel activity by monitoring function calls. 4.3.1. Counting Function Calls Made This section describes how to identify how many times the system called a specific kernel function in a 30-second sample. Depending on your use of wildcards, you can also use this script to target multiple kernel functions. functioncallcount.stp functioncallcount.stp takes the targeted kernel function as an argument. The argument supports wildcards, which enables you to target multiple kernel functions up to a certain extent. The output of functioncallcount.stp contains the name of the function called and how many times it was called during the sample time (in alphabetical order). Example 4.11, "functioncallcount.stp Sample Output" contains an excerpt from the output of stap functioncallcount.stp "*@mm/*.c" : Example 4.11. functioncallcount.stp Sample Output

Commands:
#! /usr/bin/env stap The following line command will probe all the functions in kernel's memory management code: # stap functioncallcount.stp "*@mm/*.c" probe kernel.function(@1).call { # probe functions listed on commandline called[probefunc()] <<< 1 # add a count efficiently } global called probe end { foreach (fn in called-) # Sort by call count (in decreasing order) # (fn+ in called) # Sort by function name printf("%s %d\n", fn, @count(called[fn])) exit() }
[...] __vma_link 97 __vma_link_file 66 __vma_link_list 97 __vma_link_rb 97 __xchg 103 add_page_to_active_list 102 add_page_to_inactive_list 19 add_to_page_cache 19 add_to_page_cache_lru 7 all_vm_events 6 alloc_pages_node 4630 alloc_slabmgmt 67 anon_vma_alloc 62 anon_vma_free 62 anon_vma_lock 66 anon_vma_prepare 98 anon_vma_unlink 97 anon_vma_unlock 66 arch_get_unmapped_area_topdown 94 arch_get_unmapped_exec_area 3 arch_unmap_area_topdown 97 atomic_add 2 atomic_add_negative 97 atomic_dec_and_test 5153 atomic_inc 470 atomic_inc_and_test 1 [...]
7.2. Role Mapping Each JBoss Data Virtualization data role can be mapped to any number of container roles or any authenticated user. Control role membership through whatever system the JBoss Data Virtualization security domain login modules are associated with. It is possible for a user to have any number of container roles, which in turn imply a subset of JBoss Data Virtualization data roles. Each applicable JBoss Data Virtualization data role contributes cumulatively to the permissions of the user. No one role supersedes or negates the permissions of the other data roles. Note If you have an alternative security domain that your VDB should use, set the VDB security-domain property to the relevant domain.

Commands:
Chapter 1. Key features Streams for Apache Kafka simplifies the process of running Apache Kafka within an OpenShift cluster. This guide serves as an introduction to Streams for Apache Kafka, outlining key Kafka concepts that are central to operating Streams for Apache Kafka. It briefly explains Kafka's components, their purposes, and configuration points, including security and monitoring options. Streams for Apache Kafka provides the necessary files to deploy and manage a Kafka cluster, along with example configuration files for monitoring your deployment. 1.1. Kafka capabilities Kafka's data stream-processing capabilities and component architecture offer: High-throughput, low-latency data sharing for microservices and other applications Guaranteed message ordering Message rewind/replay from data storage to reconstruct application state Message compaction to remove outdated records in a key-value log Horizontal scalability within a cluster Data replication to enhance fault tolerance High-volume data retention for immediate access 1.2. Kafka use cases Kafka's capabilities make it ideal for: Event-driven architectures Event sourcing to log application state changes Message brokering Website activity tracking Operational monitoring through metrics Log collection and aggregation Commit logs for distributed systems Stream processing for real-time data responses 1.3. How Streams for Apache Kafka supports Kafka Streams for Apache Kafka provides container images and operators for running Kafka on OpenShift. These operators are designed with specialized operational knowledge to efficiently manage Kafka on OpenShift. Streams for Apache Kafka operators simplify: Deploying and running Kafka clusters Deploying and managing Kafka components Configuring Kafka access Securing Kafka access Upgrading Kafka Managing brokers Creating and managing topics Creating and managing users For detailed information and instructions on using operators to perform these operations, see the guide for Deploying and Managing Streams for Apache Kafka .

Commands:
11.2. Using JSON with Ruby Example Prerequisites To use JavaScript Object Notation ( JSON ) with ruby to interact with Red Hat JBoss Data Grid's REST Interface, install the JSON Ruby library (see your platform's package manager or the Ruby documentation) and declare the requirement using the following code: Using JSON with Ruby The following code is an example of how to use JavaScript Object Notation ( JSON ) in conjunction with Ruby to send specific data, in this case the name and age of an individual, using the PUT function. Report a bug

Commands:
require 'json'
data = {:name => "michael", :age => 42 } http.put('/rest/Users/data/0', data.to_json, {"Content-Type" => "application/json"})
8.8. Activating and Deactivating a Snapshot Only activated snapshots are accessible. Check the Accessing Snapshot section for more details. Since each snapshot is a Red Hat Gluster Storage volume it consumes some resources hence if the snapshots are not needed it would be good to deactivate them and activate them when required. To activate a snapshot run the following command: where: snapname : Name of the snap to be activated. force : If some of the bricks of the snapshot volume are down then use the force command to start them. For Example: To deactivate a snapshot, run the following command: where: snapname : Name of the snap to be deactivated. For example:

Commands:
gluster snapshot activate < snapname > [force]
gluster snapshot activate snap1
gluster snapshot deactivate < snapname >
gluster snapshot deactivate snap1
1.3. Creating the Kickstart File The kickstart file is a simple text file, containing a list of items, each identified by a keyword. You can create it by editing a copy of the sample.ks file found in the RH-DOCS directory of the Red Hat Enterprise Linux Documentation CD, using the Kickstart Configurator application, or writing it from scratch. The Red Hat Enterprise Linux installation program also creates a sample kickstart file based on the options that you selected during installation. It is written to the file /root/anaconda-ks.cfg . You should be able to edit it with any text editor or word processor that can save files as ASCII text. First, be aware of the following issues when you are creating your kickstart file: Sections must be specified in order . Items within the sections do not have to be in a specific order unless otherwise specified. The section order is: Command section - Refer to Section 1.4, "Kickstart Options" for a list of kickstart options. You must include the required options. The %packages section - Refer to Section 1.5, "Package Selection" for details. The %pre and %post sections - These two sections can be in any order and are not required. Refer to Section 1.6, "Pre-installation Script" and Section 1.7, "Post-installation Script" for details. Items that are not required can be omitted. Omitting any required item results in the installation program prompting the user for an answer to the related item, just as the user would be prompted during a typical installation. Once the answer is given, the installation continues unattended (unless it finds another missing item). Lines starting with a pound (or hash) sign (#) are treated as comments and are ignored. For kickstart upgrades , the following items are required: Language Language support Installation method Device specification (if device is needed to perform the installation) Keyboard setup The upgrade keyword Boot loader configuration If any other items are specified for an upgrade, those items are ignored (note that this includes package selection).

Commands:
Preface Red Hat OpenStack Platform (Red Hat OpenStack Platform) provides the foundation to build a private or public Infrastructure-as-a-Service (IaaS) cloud on top of Red Hat Enterprise Linux. It offers a massively scalable, fault-tolerant platform for the development of cloud-enabled workloads. This guide discusses procedures for creating and managing persistent storage. Within OpenStack, this storage is provided by three main services: Block Storage ( openstack-cinder ) Object Storage ( openstack-swift ) Shared File System Storage ( openstack-manila ) These services provide different types of persistent storage, each with its own set of advantages in different use cases. This guide discusses the suitability of each for general enterprise storage requirements. You can manage cloud storage using either the OpenStack dashboard or the command-line clients. Most procedures can be carried out using either method; some of the more advanced procedures can only be executed on the command line. This guide provides procedures for the dashboard where possible. Note For the complete suite of documentation for Red Hat OpenStack Platform, see Red Hat OpenStack Platform Documentation . Important This guide documents the use of crudini to apply some custom service settings. As such, you need to install the crudini package first:

Commands:
dnf install crudini -y