mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 18. Storage dm-era Device Mapper The device-mapper-persistent-data package now provides tools to help use the new dm-era device mapper functionality released as a Technology Preview. The dm-era functionality keeps track of which blocks on a device were written within user-defined periods of time called an era . This functionality allows backup software to track changed blocks or restore the coherency of a cache after reverting changes. DIF/DIX support DIF/DIX, is a new addition to the SCSI Standard and a Technology Preview in Red Hat Enterprise Linux 6. DIF/DIX increases the size of the commonly used 512-byte disk block from 512 to 520 bytes, adding the Data Integrity Field (DIF). The DIF stores a checksum value for the data block that is calculated by the Host Bus Adapter (HBA) when a write occurs. The storage device then confirms the checksum on receive, and stores both the data and the checksum. Conversely, when a read occurs, the checksum can be checked by the storage device, and by the receiving HBA. The DIF/DIX hardware checksum feature must only be used with applications that exclusively issue O_DIRECT I/O. These applications may use the raw block device, or the XFS file system in O_DIRECT mode. (XFS is the only file system that does not fall back to buffered I/O when doing certain allocation operations.) Only applications designed for use with O_DIRECT I/O and DIF/DIX hardware should enable this feature. For more information, refer to section Block Devices with DIF/DIX Enabled in the Storage Administration Guide . Package: kernel LVM Application Programming Interface (API) Red Hat Enterprise Linux 6 features the new LVM application programming interface (API) as a Technology Preview. This API is used to query and control certain aspects of LVM. Package: lvm2

Commands:
Chapter 16. Log file locations During the deployment process, progress information is displayed in the web browser. This information is also stored on the local file system so that the information logged can be archived or reviewed at a later date, for example, if the web browser stops responding or is closed before the information has been reviewed. The log file for the Web Console based deployment process (documented in Chapter 10, Configure Red Hat Gluster Storage for Hosted Engine using the Web Console ) is stored in the /var/log/cockpit/ovirt-dashboard/gluster-deployment.log file by default. The log files for the Hosted Engine setup portion of the deployment process (documented in Chapter 11, Deploy the Hosted Engine using the Web Console ) are stored in the /var/log/ovirt-hosted-engine-setup directory, with file names of the form ovirt-hosted-engine-setup-<date>.log .

Commands:
Appendix F. Swift response headers The response from the server should include an X-Auth-Token value. The response might also contain a X-Storage-Url that provides the API_VERSION / ACCOUNT prefix that is specified in other requests throughout the API documentation. Table F.1. Response Headers Name Description Type X-Storage-Token The authorization token for the X-Auth-User specified in the request. String X-Storage-Url The URL and API_VERSION / ACCOUNT path for the user. String

Commands:
Part VII. Patching and upgrading Red Hat Process Automation Manager As a Red Hat Process Automation Manager user, you can apply updates to Red Hat Process Automation Manager as they become available in the Red Hat Customer Portal to keep your Red Hat Process Automation Manager distribution current with the latest enhancements and fixes. Red Hat provides update tools and product notifications for new product releases so you can more readily apply helpful updates to Red Hat Process Automation Manager and KIE Server. Prerequisites You have a Red Hat Customer Portal account. Red Hat Process Automation Manager is installed. For installation options, see Planning a Red Hat Process Automation Manager installation . Note If you are using Red Hat Process Automation Manager 7.10 and you want to upgrade to Red Hat Process Automation Manager 7.13, see Patching and upgrading Red Hat Process Automation Manager 7.10 .

Commands:
Chapter 17. Accessing odf-console with the ovs-multitenant plugin by manually enabling global pod networking In OpenShift Container Platform, when ovs-multitenant plugin is used for software-defined networking (SDN), pods from different projects cannot send packets to or receive packets from pods and services of a different project. By default, pods can not communicate between namespaces or projects because a project's pod networking is not global. To access odf-console, the OpenShift console pod in the openshift-console namespace needs to connect with the OpenShift Data Foundation odf-console in the openshift-storage namespace. This is possible only when you manually enable global pod networking. Issue When`ovs-multitenant` plugin is used in the OpenShift Container Platform, the odf-console plugin fails with the following message: Resolution Make the pod networking for the OpenShift Data Foundation project global:

Commands:
GET request for "odf-console" plugin failed: Get "https://odf-console-service.openshift-storage.svc.cluster.local:9001/locales/en/plugin__odf-console.json": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
oc adm pod-network make-projects-global openshift-storage
Chapter 1. Bare Metal Provisioning service (ironic) functionality You use the Bare Metal Provisioning service (ironic) components to provision and manage physical machines as bare metal instances for your cloud users. To provision and manage bare metal instances, the Bare Metal Provisioning service interacts with the following Red Hat OpenStack Platform (RHOSP) services in the overcloud: The Compute service (nova) provides scheduling, tenant quotas, and a user-facing API for virtual machine instance management. The Bare Metal Provisioning service provides the administrative API for hardware management. The Identity service (keystone) provides request authentication and assists the Bare Metal Provisioning service to locate other RHOSP services. The Image service (glance) manages disk and instance images and image metadata. The Networking service (neutron) provides DHCP and network configuration, and provisions the virtual or physical networks that instances connect to on boot. The Object Storage service (swift) exposes temporary image URLs for some drivers. Bare Metal Provisioning service components The Bare Metal Provisioning service consists of services, named ironic-* . The following services are the core Bare Metal Provisioning services: Bare Metal Provisioning API ( ironic-api ) This service provides the external REST API to users. The API sends application requests to the Bare Metal Provisioning conductor over remote procedure call (RPC). Bare Metal Provisioning conductor ( ironic-conductor ) This service uses drivers to perform the following bare metal node management tasks: Adds, edits, and deletes bare metal nodes. Powers bare metal nodes on and off with IPMI, Redfish, or other vendor-specific protocol. Provisions, deploys, and cleans bare metal nodes. Bare Metal Provisioning inspector ( ironic-inspector ) This service discovers the hardware properties of a bare metal node that are required for scheduling bare metal instances, and creates the Bare Metal Provisioning service ports for the discovered ethernet MACs. Bare Metal Provisioning database This database tracks hardware information and state. Message queue All services use this messaging service to communicate with each other, including implementing the RPC between ironic-api and ironic-conductor . Bare Metal Provisioning agent ( ironic-python-agent ) This service runs in a temporary ramdisk to provide ironic-conductor and ironic-inspector services with remote access, in-band hardware control, and hardware introspection. Provisioning a bare metal instance The Bare Metal Provisioning service uses iPXE to provision physical machines as bare metal instances. The following diagram outlines how the RHOSP services interact during the provisioning process when a cloud user launches a new bare metal instance with the default drivers.

Commands:
1.4. Generated Keys JBoss Data Virtualization supports returning generated keys for JDBC sources and from JBoss Data Virtualization temp tables with SERIAL primary key columns. However the current implementation returns only the last set of keys generated and returns the key results directly from the source - no view projection of other intermediate handling is performed. For most scenarios (single source inserts) this handling is sufficient. A custom solution may need to be developed if you are using a FOR EACH ROW instead of trigger to process your inserts and target multiple tables that each return generated keys. It is possible to develop a UDF that also manipulates the returned generated keys - see the org.teiid.CommandContext methods dealing with generated keys for more.

Commands:
Chapter 2. Understanding custom back ends A custom back end is a storage server, appliance, or configuration that is not yet fully integrated into the Red Hat OpenStack Platform director. Supported Block Storage back ends are already integrated and pre-configured with built-in director files. For example, Red Hat Ceph and single-back end configurations of Dell EMC PS Series, Dell Storage Center, and NetApp appliances. Some integrated storage appliances support only a single-instance back end. For example, with the pre-configured director files for Dell Storage Center, you can only deploy a single back end. If you want to deploy multiple back end instances of this appliance, you need a custom configuration. Although you can manually configure the Block Storage service by directly editing the /etc/cinder/cinder.conf file on the node where the Block Storage service is located, the director overwrites your configuration when you run the openstack overcloud deploy command. For more information, see Deploying the configured back ends . Deploy the Block Storage back end with the director to ensure that your settings persist through overcloud deployments and updates. If your back end configuration is fully integrated you can edit and invoke the packaged environment files. However, for custom back ends, you must write your own environment file. This document includes the annotated /home/stack/templates/custom-env.yaml file that you can edit for your deployment, see Configuration from sample environment file . This sample file is suitable for configuring the Block Storage service to use two NetApp back ends. For more information about environment files, see Including environment files in an overcloud deployment in the Director Installation and Usage guide. 2.1. Requirements The following additional prerequisite conditions must apply to your environment to configure custom Block Storage back ends: If you are using third-party back end appliances, you have configured them as storage repositories. You have deployed the overcloud with director with the instructions in Director Installation and Usage . You have the username and password of an account with elevated privileges. You can use the same stack user account that you created to deploy the overcloud. You have already planned the resulting configuration that you want for the Block Storage back end in /etc/cinder/cinder.conf . 2.2. Understanding the configuration process Configuring the Block Storage service to use custom back ends involves the following steps: Creating the environment file. For more information, see Creating the custom back end environment file . Deploying the configured back ends. For more information, Deploying the configured back ends . Testing the configured back end. For more information, Testing the configured back ends .

Commands:
Chapter 1. Overview of client-side notifications When actions and state changes occur in the Cryostat backend, Cryostat uses a WebSocket connection to show notifications in your Cryostat web client. In Cryostat, notifications display for all conceptual actions and state changes. These notifications are prevalent when you configure automated rules. Cryostat includes notification settings that you can configure to reduce the high volume of notifications that might display on your Cryostat web console. Cryostat improves web-client performance by using notifications to update the state of resources. For example, when you delete an active recording, a notification is sent to the Cryostat web console. The web console deletes the recording from the active recordings list. Additional resources Using automated rules on Cryostat

Commands:
Chapter 5. User roles in automation controller Users associated with an organization are shown in the Access tab of the organization. A default administrator user with the role of System Administrator is automatically created and is available to all users of automation controller. You can use it as it is or edit it later. Other users can be added to an organization, including a Normal User , System Auditor , or System Administrator , but they must be created first. For more information, see the Users section in the Automation Controller User Guide. For the purpose of the getting started guide, leave the default user as it is.

Commands:
Appendix A. Using your subscription AMQ Streams is provided through a software subscription. To manage your subscriptions, access your account at the Red Hat Customer Portal. Accessing Your Account Go to access.redhat.com . If you do not already have an account, create one. Log in to your account. Activating a Subscription Go to access.redhat.com . Navigate to My Subscriptions . Navigate to Activate a subscription and enter your 16-digit activation number. Downloading Zip and Tar Files To access zip or tar files, use the customer portal to find the relevant files for download. If you are using RPM packages, this step is not required. Open a browser and log in to the Red Hat Customer Portal Product Downloads page at access.redhat.com/downloads . Locate the Red Hat AMQ Streams entries in the INTEGRATION AND AUTOMATION category. Select the desired AMQ Streams product. The Software Downloads page opens. Click the Download link for your component. Revised on 2021-04-19 16:15:28 UTC

Commands:
2.6. RHEA-2011:0635 - new package: foghorn A new foghorn package is now available for Red Hat Enterprise Linux 6. The foghorn daemon listens for specific signals on the D-Bus message bus system and translates these signals into SNMP traps. This enhancement update adds the foghorn package to Red Hat Enterprise Linux 6. (BZ# 660324 ) All users who require foghorn should install this new package.

Commands:
Chapter 5. Starting a new build After you have enabled the Red Hat Quay builds feature by configuring your deployment, you can start a new build by invoking a build trigger or by uploading a Dockerfile. Use the following procedure to start a new build by uploading a Dockerfile. For information about creating a build trigger , see "Build triggers". Prerequisites You have navigated to the Builds page of your repository. You have configured your environment to use the build feature. Procedure On the Builds page, click Start New Build . When prompted, click Upload Dockerfile to upload a Dockerfile or an archive that contains a Dockerfile at the root directory. Click Start Build . Note Currently, users cannot specify the Docker build context when manually starting a build. Currently, BitBucket is unsupported on the Red Hat Quay v2 UI. You are redirected to the build , which can be viewed in real-time. Wait for the Dockerfile build to be completed and pushed. Optional. you can click Download Logs to download the logs, or Copy Logs to copy the logs. Click the back button to return to the Repository Builds page, where you can view the build history . You can check the status of your build by clicking the commit in the Build History page, or by running the following command: Example output After the build has completed, the oc get pods -n virtual-builders command returns no resources: USD oc get pods -n virtual-builders Example output

Commands:
oc get pods -n virtual-builders
NAME READY STATUS RESTARTS AGE f192fe4a-c802-4275-bcce-d2031e635126-9l2b5-25lg2 1/1 Running 0 7s
oc get pods -n virtual-builders
No resources found in virtual-builders namespace.
probe::kprocess.release Name probe::kprocess.release - Process released Synopsis kprocess.release Values released_tid TID of the task being released task A task handle to the process being released released_pid PID of the process being released pid Same as released_pid for compatibility (deprecated) Context The context of the parent, if it wanted notification of this process' termination, else the context of the process itself. Description Fires when a process is released from the kernel. This always follows a kprocess.exit, though it may be delayed somewhat if the process waits in a zombie state.

Commands:
D.8. Properties View The Properties View provides editing capabilities for the currently selected object in Teiid Designer . The selection provided by whichever view or editor is currently in focus will determine the its contents. To edit a property, click a cell in the Value column. As in the Table Editor , each cell provides a UI editor specific to the property type. Figure D.15. Properties View If the model for the object being edited is not open in an editor, a dialog may appear confirming the attempt to modify the model and asking the user to confirm or cancel. This dialog can be prevented by selecting the preference Always open editor without prompting . You can also select/clear this property via the Teiid Designer's main preference page. Figure D.16. Open Model Editor Dialog Properties can also be edited via a right-click menu presented below. Figure D.17. Open Model Editor Dialog The Properties toolbar contains the following actions: Show Categories - toggles between categorized properties and flat alphabetical properties list. Show Advanced Properties - shows/hide advanced properties (if available). Restore Default Value - for a selected property, this action will reset the current to a default value (if available).

Commands:
2.2.4. Product Subscriptions and Content Updates Red Hat Enterprise Linux 6 introduces an updated and more flexible service for content delivery and subscription management. This section describes the changes to the content service. The Red Hat Network hosted environment is updated from using channel-based subscriptions to product-and-quantity based subscriptions. The new Certificate-Based RHN has redesigned client tools for managing subscriptions and systems and works with the new Subscription and Content Delivery Network (CDN). The traditional channel-based RHN is still available as RHN Classic . These two subscription services are available on the same platform, just with parallel technologies, so all subscriptions can be registered and managed either way. Environments using a Satellite or proxy server will continue to use the traditional channel-based subscription system and will register systems with RHN Classic. A new content server option, Red Hat Network Classic, has been added to the firstboot wizard. This uses the traditional channel-based RHN rather than the updated RHN and CDN. The default Red Hat Network option uses the new Certificate-based Red Hat Network management platform. Certificate-Based RHN and RHN Classic are interoperable; if a system is registered using one service, the other service recognizes it and will not issue any warnings. However, these services do not work simultaneously. A system must be registered with one, and only one, subscription service; it cannot be registered with both. There is currently no direct migration path from a system using RHN Classic to the new Certificate-based Red Hat Network. To move a system from one service to the other, there are two options: Update the system to Red Hat Enterprise Linux 6.1 or later using a boot ISO rather than yum . Manually remove the system from RHN Classic and delete the host record, then register the system to Certificate-based Red Hat Network using the Red Hat Subscription Manager tools. A new set of client tools, the Red Hat Subscription Manager GUI and CLI, are provided with Red Hat Enterprise Linux 6.1 and newer to manage subscriptions through Certificate-Based RHN. The existing rhn_* tools are still available to handle systems managed through RHN Classic.

Commands:
8.10. boost 8.10.1. RHBA-2013:1187 - boost bug fix update Updated boost packages that fix one bug are now available. The boost packages provide free peer-reviewed portable C++ source libraries with emphasis on libraries which work well with the C++ Standard Library. Bug Fix BZ# 820670 The Boost package did not contain the Boost.Math shared libraries, which include an inverse of trigonometric functions over complex numbers and gamma, beta and erf special functions, as specified in the Technical Report on C++ Library Extensions. This update adds the boost-math sub-package, which includes the symbols corresponding to the mentioned functions. Users of boost are advised to upgrade to these updated packages, which fix this bug.

Commands:
28.4.6. Automatic Downloads and Installation of Debuginfo Packages ABRT can be configured to automatically download and install packages needed for debugging of particular problems. This feature can be useful if you want to debug problems locally in your company environment. To enable automatic debuginfo downloads and installation, ensure that your system fulfills the following conditions: The /etc/libreport/events.d/ccpp_event.conf file contains the following analyzer event, which is present uncommented in default configuration: EVENT=analyze_LocalGDB analyzer=CCpp abrt-action-analyze-core --core=coredump -o build_ids && # In RHEL we don't want to install anything by default # and also this would fail, as the debuginfo repositories. # are not available without root password rhbz#759443 # /usr/libexec/abrt-action-install-debuginfo-to-abrt-cache --size_mb=4096 && abrt-action-generate-backtrace && abrt-action-analyze-backtrace The /etc/libreport/events.d/ccpp_event.conf file contains the following line, which allows ABRT to run binary to install debuginfo packages for the problems being analyzed. This line is, in order to avoid installations of unnecessary content, commented out by default so you have to remove the leading # character to enable it: /usr/libexec/abrt-action-install-debuginfo-to-abrt-cache --size_mb=4096 && The gdb package, which allows you to generate a backtrace during a problem analysis, is installed on your system. If needed, see Section 8.2.4, "Installing Packages" for more information on how to install packages with the Yum package manager. Important Note that debuginfo packages are installed using the rhnplugin which requires root privileges. Therefore, you have to run ABRT as root to be able to install debuginfo packages.

Commands:
EVENT=analyze_LocalGDB analyzer=CCpp abrt-action-analyze-core --core=coredump -o build_ids && # In RHEL we don't want to install anything by default # and also this would fail, as the debuginfo repositories. # are not available without root password rhbz#759443 # /usr/libexec/abrt-action-install-debuginfo-to-abrt-cache --size_mb=4096 && abrt-action-generate-backtrace && abrt-action-analyze-backtrace
/usr/libexec/abrt-action-install-debuginfo-to-abrt-cache --size_mb=4096 &&