mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 20. service 20.1. service:list 20.1.1. Description Lists OSGi services. 20.1.2. Syntax service:list [options] [objectClass] 20.1.3. Arguments Name Description objectClass Name of service objectClass to filter for 20.1.4. Options Name Description -a Shows all services. (By default Karaf commands are hidden) --help Display this help message -n Shows only service class names 20.2. service:wait 20.2.1. Description Wait for a given OSGi service. 20.2.2. Syntax service:wait [options] service 20.2.3. Arguments Name Description service The service class or filter 20.2.4. Options Name Description -t, --timeout timeout to wait for the service (in milliseconds, negative to not wait at all, zero to wait forever) --help Display this help message -e, --exception throw an exception if the service is not found after the timeout

Commands:
probe::signal.sys_tgkill Name probe::signal.sys_tgkill - Sending kill signal to a thread group Synopsis signal.sys_tgkill Values sig_pid The PID of the thread receiving the kill signal sig The specific kill signal sent to the process name Name of the probe point pid_name The name of the signal recipient sig_name A string representation of the signal tgid The thread group ID of the thread receiving the kill signal task A task handle to the signal recipient Description The tgkill call is similar to tkill, except that it also allows the caller to specify the thread group ID of the thread to be signalled. This protects against TID reuse.

Commands:
Chapter 2. Block Storage backup service deployment The Block Storage backup service is optional. It is not installed by default so you must add it to your overcloud deployment Prerequisites An existing Red Hat OpenStack Platform (RHOSP) installation. An available storage source with a compatible backup driver: Object Storage (swift; default), Ceph, NFS, or Google Cloud storage. Note Google Cloud Storage requires additional configuration. For more information, see Appendix A, Google Cloud Storage configuration . 2.1. Configuring back end storage options for the backup service To enable the backup service, complete the following steps. Procedure Create a copy of the cinder-backup.yaml file, which is located in the /usr/share/openstack-tripleo-heat-templates/environments/ directory, and store it in the same location as your other custom templates. Your copy of the cinder-backup.yaml file contains default settings that configure an OpenStack Object Storage (swift) back end for the Block Storage backup service with Pacemaker. If this is the back end you are using for your backup then you do not need to make changes to this file. If you are using an alternative back end, configure parameter_defaults depending on the backup back end: If you are using Red Hat Ceph Storage, configure parameter_defaults in the following way: CinderBackupBackend : (Required) ceph CinderBackupRbdPoolName : (Optional) Set to a custom RBD pool name. Default: backups If you are using NFS, configure parameter_defaults in the following way: CinderBackupBackend : (Required) nfs CinderBackupNfsShare : (Required) Set to the NFS share that you want to mount. The default value is empty. CinderBackupNfsOptions : (Optional) Set to your required mount option. Save the changes to the file. To enable the backup service and apply this configuration, add your backup settings environment file to the stack with your other environment files and deploy the overcloud: For more information and additional configuration options, see Appendix A, Google Cloud Storage configuration . 2.2. Deploying the overcloud with your Google Cloud configuration After you create the environment file in `/home/stack/templates/ , deploy the overcloud then restart the cinder-backup service. Procedure Log in as the stack user. Deploy the configuration: Important If you passed any extra environment files when you created the overcloud, pass them again here using the -e option to avoid making undesired changes to the overcloud. Restart the cinder-backup service after the deployment finishes. For more information, see the Including environment files in an overcloud deployment in the Director Installation and Usage guide and Environment Files in the Advanced Overcloud Customization guide.

Commands:
cp /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup.yaml /home/stack/templates/cinder-backup-settings.yaml
(undercloud) [stack@undercloud ~]USD openstack overcloud deploy --templates -e [your environment files] -e /home/stack/templates/cinder-backup-settings.yaml
openstack overcloud deploy --templates -e /home/stack/templates/cinder-backup-settings.yaml
Chapter 1. Red Hat Ansible Automation Platform 2.5 upgrades 1.1. Ansible Automation Platform upgrades Currently, it is possible to perform Ansible Automation Platform upgrades using one of the following supported upgrade paths. Important Upgrading from Event-Driven Ansible 2.4 is not supported. If you're using Event-Driven Ansible 2.4 in production, contact Red Hat before you upgrade. Before beginning your upgrade be sure to review the prerequisites and upgrade planning sections of this guide. Supported upgrade path Steps to upgrade Ansible Automation Platform 2.4 to 2.5 Download the installation package . Set up your inventory file to match your installation environment. See Tested deployment models for a list of example inventory files. Back up your Ansible Automation Platform instance . Run the 2.5 installation program over your current Ansible Automation Platform instance. Link your existing service level accounts to a single unified platform account. Ansible Automation Platform 2.5 to 2.5.x Download the installation package . Set up your inventory file to match your installation environment. See Tested deployment models for a list of example inventory files. Back up your Ansible Automation Platform instance . Run the 2.5 installation program over your current Ansible Automation Platform instance. Automation controller and automation hub 2.4 and Event-Driven Ansible 2.5 with unified UI upgrades Upgrade the 2.4 services (using inventory file to only specify automation controller and automation hub VMs) to get them to the initial version of AAP 2.5. After all the services are at the same version, run a 2.5 upgrade on all the services

Commands:
Chapter 1. Preparing to install on IBM Power 1.1. Prerequisites You reviewed details about the OpenShift Container Platform installation and update processes. You read the documentation on selecting a cluster installation method and preparing it for users . 1.2. Choosing a method to install OpenShift Container Platform on IBM Power You can install a cluster on IBM Power(R) infrastructure that you provision, by using one of the following methods: Installing a cluster on IBM Power(R) : You can install OpenShift Container Platform on IBM Power(R) infrastructure that you provision. Installing a cluster on IBM Power(R) in a restricted network : You can install OpenShift Container Platform on IBM Power(R) infrastructure that you provision in a restricted or disconnected network, by using an internal mirror of the installation release content. You can use this method to install a cluster that does not require an active internet connection to obtain the software components. You can also use this installation method to ensure that your clusters only use container images that satisfy your organizational controls on external content.

Commands:
5.3. Managing Cluster Nodes This section documents how to perform the following node-management functions through the luci server component of Conga : Section 5.3.1, "Rebooting a Cluster Node" Section 5.3.2, "Causing a Node to Leave or Join a Cluster" Section 5.3.3, "Adding a Member to a Running Cluster" Section 5.3.4, "Deleting a Member from a Cluster" 5.3.1. Rebooting a Cluster Node To reboot a node in a cluster, perform the following steps: From the cluster-specific page, click on Nodes along the top of the cluster display. This displays the nodes that constitute the cluster. This is also the default page that appears when you click on the cluster name beneath Manage Clusters from the menu on the left side of the luci Homebase page. Select the node to reboot by clicking the check box for that node. Select the Reboot function from the menu at the top of the page. This causes the selected node to reboot and a message appears at the top of the page indicating that the node is being rebooted. Refresh the page to see the updated status of the node. It is also possible to reboot more than one node at a time by selecting all of the nodes that you wish to reboot before clicking on Reboot .

Commands:
Appendix B. Customizing the Manager virtual machine using automation during deployment You can use automation to adjust or otherwise customize the Manager virtual machine during deployment by using one or more Ansible playbooks. You can run playbooks at the following points during deployment: before the self-hosted engine setup after the self-hosted engine setup, but before storage is configured after adding the deployment host to the Manager after the deployment completes entirely Procedure Write one or more Ansible playbooks to run on the Manager virtual machine at specific points in the deployment process. Add the playbooks to the appropriate directory under /usr/share/ansible/collections/ansible_collections/redhat/rhv/roles/hosted_engine_setup/hooks/ : enginevm_before_engine_setup Run the playbook before the self-hosted engine setup. enginevm_after_engine_setup Run the playbook after the self-hosted engine setup, but before storage is configured. after_add_host Run the playbook after adding the deployment host to the Manager. after_setup Run the playbook after deployment is completed. When you run the self-hosted-engine installer, the deployment script runs the ovirt-engine-setup role, which automatically runs any playbooks in either of these directories. Additional resources Deploying the self-hosted engine using the command line Automating Configuration Tasks using Ansible Intro to playbooks in the Ansible documentation

Commands:
3.7. Data Journaling Ordinarily, GFS2 writes only metadata to its journal. File contents are subsequently written to disk by the kernel's periodic sync that flushes file system buffers. An fsync() call on a file causes the file's data to be written to disk immediately. The call returns when the disk reports that all data is safely written. Data journaling can result in a reduced fsync() time for very small files because the file data is written to the journal in addition to the metadata. This advantage rapidly reduces as the file size increases. Writing to medium and larger files will be much slower with data journaling turned on. Applications that rely on fsync() to sync file data may see improved performance by using data journaling. Data journaling can be enabled automatically for any GFS2 files created in a flagged directory (and all its subdirectories). Existing files with zero length can also have data journaling turned on or off. Enabling data journaling on a directory sets the directory to "inherit jdata", which indicates that all files and directories subsequently created in that directory are journaled. You can enable and disable data journaling on a file with the chattr command. The following commands enable data journaling on the /mnt/gfs2/gfs2_dir/newfile file and then check whether the flag has been set properly. The following commands disable data journaling on the /mnt/gfs2/gfs2_dir/newfile file and then check whether the flag has been set properly. You can also use the chattr command to set the j flag on a directory. When you set this flag for a directory, all files and directories subsequently created in that directory are journaled. The following set of commands sets the j flag on the gfs2_dir directory, then checks whether the flag has been set properly. After this, the commands create a new file called newfile in the /mnt/gfs2/gfs2_dir directory and then check whether the j flag has been set for the file. Since the j flag is set for the directory, then newfile should also have journaling enabled.

Commands:
chattr +j /mnt/gfs2/gfs2_dir/newfile lsattr /mnt/gfs2/gfs2_dir ---------j--- /mnt/gfs2/gfs2_dir/newfile
chattr -j /mnt/gfs2/gfs2_dir/newfile lsattr /mnt/gfs2/gfs2_dir ------------- /mnt/gfs2/gfs2_dir/newfile
chattr -j /mnt/gfs2/gfs2_dir lsattr /mnt/gfs2 ---------j--- /mnt/gfs2/gfs2_dir touch /mnt/gfs2/gfs2_dir/newfile lsattr /mnt/gfs2/gfs2_dir ---------j--- /mnt/gfs2/gfs2_dir/newfile
Chapter 13. Integrating with the Red Hat build of Debezium for change data capture The Red Hat build of Debezium is a distributed change data capture platform. It captures row-level changes in databases, creates change event records, and streams the records to Kafka topics. Debezium is built on Apache Kafka. You can deploy and integrate the Red Hat build of Debezium with Streams for Apache Kafka. Following a deployment of Streams for Apache Kafka, you deploy Debezium as a connector configuration through Kafka Connect. Debezium passes change event records to Streams for Apache Kafka on OpenShift. Applications can read these change event streams and access the change events in the order in which they occurred. Debezium has multiple uses, including: Data replication Updating caches and search indexes Simplifying monolithic applications Data integration Enabling streaming queries To capture database changes, deploy Kafka Connect with a Debezium database connector. You configure a KafkaConnector resource to define the connector instance. For more information on deploying the Red Hat build of Debezium with Streams for Apache Kafka, refer to the product documentation . The documentation includes a Getting Started with Debezium guide that guides you through the process of setting up the services and connector required to view change event records for database updates.

Commands:
Chapter 3. How the trust between IdM and AD works The trust between Identity Management (IdM) and Active Directory (AD) is established on the cross-realm Kerberos trust. This solution uses the Kerberos capability to establish trusts between different identity sources. Therefore, all AD users can: Log in to access Linux systems and resources. Use single sign-on (SSO). In the trust relationship, all IdM objects are managed in IdM, while all AD objects are managed in AD. In complex environments, a single IdM forest can be connected to multiple AD forests. This setup enables better separation of duties for different functions in the organization. AD administrators can focus on users and policies related to users while Linux administrators have full control over the Linux infrastructure. In such a case, the Linux realm controlled by IdM is analogous to an AD resource domain or realm but with Linux systems in it. From the perspective of AD, Identity Management represents a separate AD forest with a single AD domain. When cross-forest trust is established between an AD forest root domain and an IdM domain, users from the AD forest domains can interact with Linux machines and services from the IdM domain. Note In trust environments, IdM enables you to use ID views to configure POSIX attributes for AD users on the IdM server.

Commands:
Chapter 18. Guided decision tables Guided decision tables are a wizard-led alternative to spreadsheet decision tables for defining business rules in a tabular format. With guided decision tables, you are led by a UI-based wizard in Business Central that helps you define rule attributes, metadata, conditions, and actions based on specified data objects in your project. After you create your guided decision tables, the rules you defined are compiled into Drools Rule Language (DRL) rules as with all other rule assets. All data objects related to a guided decision table must be in the same project package as the guided decision table. Assets in the same package are imported by default. After you create the necessary data objects and the guided decision table, you can use the Data Objects tab of the guided decision tables designer to verify that all required data objects are listed or to import other existing data objects by adding a New item . 18.1. Viewing the mortgage decision table The goal of this chapter is to introduce you to the MortgageDecisionTable decision table. For this tutorial, you do not create and set the decision table conditions. Instead, review the values and the conditions that are already defined in the Mortgage_Process sample project's MortgageDecisionTable Guided Decision Tables asset. For information about creating decision tables, see Designing a decision service using guided decision tables . Prerequisites The business rules have been defined. For more information, see Section 17.1, "Viewing the Mortgage_Process business rules" . Procedure In Business Central, go to Menu Design Projects Mortgage_Process . Scroll down and click the MortgageDecisionTable Guided Decision Tables asset.

Commands:
4.296. sigar 4.296.1. RHBA-2011:1570 - sigar and mingw32-sigar bug fix and enhancement update Updated sigar and mingw32-sigar packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The System Information Gatherer and Reporter (SIGAR) is a library and command line tool for accessing operating system and hardware level information across multiple platforms and programming languages. The mingw32-sigar package provides the MinGW (Minimalist GNU for Windows) sigar library. The sigar package has been upgraded to upstream version 1.6.5, which updates sigar to use Windows device names instead of ethX names. This update also adds a number of bug fixes and enhancements over the version. (BZ# 688184 ) Bug Fix BZ# 746288 Previously, sigar could print incorrect system information on the IBM System z architecture due to a specific format for the /proc/cpuinfo file. This update ensures that the /proc/cpuinfo file is correctly parsed on all non-x86 architectures. As a result, the correct system information is now displayed. Enhancement BZ# 663465 This update adds PowerPC and IBM System z as a dependency for the Matahari framework on the AMD64 and Intel 64 architectures. All users of sigar and mingw32-sigar are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 5. Enabling notifications and integrations You can enable the notifications service on Red Hat Hybrid Cloud Console to send notifications whenever a vulnerability event is triggered. For example, you can configure the notifications service to automatically send an email message whenever a security issue affects systems in your installation, or to send an email digest of all the vulnerability events that take place each day. Using the notifications service frees you from having to continually check the Red Hat Insights for RHEL dashboard for event-triggered notifications. In addition to sending email messages, you can configure the notifications service to send event data in other ways: Using an authenticated client to query Red Hat Insights APIs for event data Using webhooks to send events to third-party applications that accept inbound requests Integrating notifications with applications such as Splunk to route event notifications to the application dashboard A Notifications Administrator sets up behavior groups for events in the notifications service. Behavior groups specify the delivery method for each notification and whether the notifications are sent to all users, or just to Organization Administrators. An Organization Administrator creates a User access group with the Notifications Administrator role, and then adds account members to the group. Users who receive email notifications from events may set their user preferences so that they receive individual emails for each event, or a daily digest of events. Additional resources For more information about how to set up notifications and integrations for Vulnerability events, see Configuring notifications on the Red Hat Hybrid Cloud Console with FedRAMP and Integrating the Red Hat Hybrid Cloud Console with third-party applications .

Commands:
E.2.29. /proc/version This file specifies the version of the Linux kernel, the version of gcc used to compile the kernel, and the time of kernel compilation. It also contains the kernel compiler's user name (in parentheses). This information is used for a variety of purposes, including the version data presented when a user logs in.

Commands:
Linux version 2.6.8-1.523 (user@foo.redhat.com) (gcc version 3.4.1 20040714 \ (Red Hat Enterprise Linux 3.4.1-7)) #1 Mon Aug 16 13:27:03 EDT 2004
Chapter 15. Network Booting with libvirt Guest virtual machines can be booted with PXE enabled. PXE allows guest virtual machines to boot and load their configuration off the network itself. This section demonstrates some basic configuration steps to configure PXE guests with libvirt. This section does not cover the creation of boot images or PXE servers. It is used to explain how to configure libvirt, in a private or bridged network, to boot a guest virtual machine with PXE booting enabled. Warning These procedures are provided only as an example. Ensure that you have sufficient backups before proceeding. 15.1. Preparing the Boot Server To perform the steps in this chapter you will need: A PXE Server (DHCP and TFTP) - This can be a libvirt internal server, manually-configured dhcpd and tftpd, dnsmasq, a server configured by Cobbler, or some other server. Boot images - for example, PXELINUX configured manually or by Cobbler. 15.1.1. Setting up a PXE Boot Server on a Private libvirt Network This example uses the default network. Perform the following steps: Procedure 15.1. Configuring the PXE boot server Place the PXE boot images and configuration in /var/lib/tftp . Run the following commands: Edit the <ip> element in the configuration file for the default network to include the appropriate address, network mask, DHCP address range, and boot file, where BOOT_FILENAME represents the file name you are using to boot the guest virtual machine. Boot the guest using PXE (refer to Section 15.2, "Booting a Guest Using PXE" ).

Commands:
virsh net-destroy default virsh net-edit default
<ip address='192.168.122.1' netmask='255.255.255.0'> <tftp root='/var/lib/tftp' /> <dhcp> <range start='192.168.122.2' end='192.168.122.254' /> <bootp file=' BOOT_FILENAME ' /> </dhcp> </ip>
5.3. Multipath Command Options Table 5.1, "Useful multipath Command Options" describes some options of the multipath command that you may find useful. Table 5.1. Useful multipath Command Options Option Description -l Display the current multipath configuration gathered from sysfs and the device mapper. -ll Display the current multipath configuration gathered from sysfs , the device mapper, and all other available components on the system. -f device Remove the named multipath device. -F Remove all multipath devices.

Commands:
Chapter 1. Image Builder description 1.1. Introduction to Image Builder You can use Image Builder to create customized system images of Red Hat Enterprise Linux, including system images prepared for deployment on cloud platforms. Image Builder automatically handles details of setup for each output type and is thus easier to use and faster to work with than manual methods of image creation. You can access Image Builder functionality through a command-line interface in the composer-cli tool, or a graphical user interface in the RHEL 7 web console. See managing the web console for more information. Image Builder runs as a system service lorax-composer . You can interact with this service through two interfaces: CLI tool composer-cli for running commands in the terminal. This method is recommended. GUI plugin for the RHEL 7 web console.

Commands: