mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 3. Integrating Serverless with the cost management service Cost management is an OpenShift Container Platform service that enables you to better understand and track costs for clouds and containers. It is based on the open source Koku project. 3.1. Prerequisites You have cluster administrator permissions. You have set up cost management and added an OpenShift Container Platform source . 3.2. Labels for cost management queries Labels, also known as tags in cost management, can be applied for nodes, namespaces or pods. Each label is a key and value pair. You can use a combination of multiple labels to generate reports. You can access reports about costs by using the Red Hat hybrid console . Labels are inherited from nodes to namespaces, and from namespaces to pods. However, labels are not overridden if they already exist on a resource. For example, Knative services have a default app=<revision_name> label: Example Knative service default label apiVersion: serving.knative.dev/v1 kind: Service metadata: name: showcase spec: ... labels: app: <revision_name> ... If you define a label for a namespace, such as app=my-domain , the cost management service does not take into account costs coming from a Knative service with the tag app=<revision_name> when querying the application using the app=my-domain tag. Costs for Knative services that have this tag must be queried under the app=<revision_name> tag. 3.3. Additional resources Managing cost data using tagging Visualizing your costs using cost explorer

Commands:
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: showcase spec: labels: app: <revision_name>
9.4. Import From Teiid Data Source Connection The Teiid Connection Source Model import option provides a means to create relational source models from JDBC and other deployed data sources that are not supported by other Teiid Designer importers. Note A running Teiid 8.3 or later instance is required. Ensure that the Default Server is started before you begin the import procedure. Procedure 9.1. Import From Teiid Data Source Connection Choose the File > Import... action in the toolbar or go to the Model Explorer and wherever right click and select Import... . Select Teiid Designer > Teiid Connection >> Source Model and then click . Select the datasource to use for the import. You can create a new source if the one you want does not already exist. You can also undertake other source management functions here. Click . Select the appropriate translator for your data source type and then click . Set the location where you plan to import the model, define a name for the model, specify any other options and then click . When you move to page of the wizard, a temporary dynamic vdb is actually deployed to your server and the schema for your data source is retrieved in DDL form. This DDL is displayed (and you can also be exported if you so desire). Click . On the final page of the wizard, a difference report is presented for viewing or de-selecting individual relational entities. Press Click to complete.

Commands:
Chapter 1. Introduction Migration Toolkit for Runtimes product will be End of Life on September 30th, 2024 All customers using this product should start their transition to Migration Toolkit for Applications . Migration Toolkit for Applications is fully backwards compatible with all features and rulesets available in Migration Toolkit for Runtimes and will be maintained in the long term. 1.1. About the Maven Plugin Guide This guide is for engineers, consultants, and others who want to use the Migration Toolkit for Runtimes (MTR) to migrate Java applications or other components. It describes how to install and run the Maven plugin, review the generated reports, and take advantage of additional features. 1.2. About the Migration Toolkit for Runtimes What is the Migration Toolkit for Runtimes? The Migration Toolkit for Runtimes (MTR) is an extensible and customizable rule-based tool that simplifies the migration and modernization of Java applications. MTR examines application artifacts, including project source directories and application archives, and then produces an HTML report highlighting areas needing changes. MTR supports many migration paths, including the following examples: Upgrading to the latest release of Red Hat JBoss Enterprise Application Platform Migrating from Oracle WebLogic or IBM WebSphere Application Server to Red Hat JBoss Enterprise Application Platform Containerizing applications and making them cloud-ready Migrating from Java Spring Boot to Quarkus Updating from Oracle JDK to OpenJDK Upgrading from OpenJDK 8 to OpenJDK 11 Upgrading from OpenJDK 11 to OpenJDK 17 Upgrading from OpenJDK 17 to OpenJDK 21 Migrating EAP Java applications to Azure Migrating Spring Boot Java applications to Azure For more information about use cases and migration paths, see the MTR for developers web page. How does the Migration Toolkit for Runtimes simplify migration? The Migration Toolkit for Runtimes looks for common resources and known trouble spots when migrating applications. It provides a high-level view of the technologies used by the application. MTR generates a detailed report evaluating a migration or modernization path. This report can help you to estimate the effort required for large-scale projects and to reduce the work involved. How do I learn more? See the Introduction to the Migration Toolkit for Runtimes to learn more about the features, supported configurations, system requirements, and available tools in the Migration Toolkit for Runtimes. 1.3. About the Maven Plugin The Maven plugin for the Migration Toolkit for Runtimes integrates into the Maven build process, allowing developers to continuously evaluate migration and modernization efforts with each iteration of source code. It provides numerous reports that highlight the analysis results, and is designed for developers who want updates with each build.

Commands:
7.290. yaboot 7.290.1. RHBA-2013:0476 - yaboot bug fix and enhancement update Updated yaboot packages that fix one bug and add one enhancement are now available for Red Hat Enterprise Linux 6. The yaboot packages provide a boot loader for Open Firmware based PowerPC systems. Yaboot can be used to boot IBM eServer System p machines. Bug Fix BZ#871579 Prior to this update, the yaboot loader used by default a maximum block size of 512 bytes in the fdisk partition table. As a consequence, yaboot could not load a kernel in a disk that was formatted using 4 kilobytes partitions. This update extends the MAX_BLOCK_SIZE value to 4 kilobytes to allow for disks that use the advanced format. Enhancement BZ#822657 This update adds VLAN Tag support for network boot and installation to allow multiple VLANs in a bridged network to share the same physical network link but maintain isolation. All users of yaboot are advised to upgrade to these updated packages, which fix this bug and add this enhancement.

Commands:
9.3. Role Mapping In order to convert the Principals in a Subject into a set of roles used for authorization, a PrincipalRoleMapper must be specified in the global configuration. Red Hat JBoss Data Grid ships with three mappers, and also allows you to provide a custom mapper. Table 9.3. Mappers Mapper Name Java XML Description IdentityRoleMapper org.infinispan.security.impl.IdentityRoleMapper <identity-role-mapper /> Uses the Principal name as the role name. CommonNameRoleMapper org.infinispan.security.impl.CommonRoleMapper <common-name-role-mapper /> If the Principal name is a Distinguished Name (DN), this mapper extracts the Common Name (CN) and uses it as a role name. For example the DN cn=managers,ou=people,dc=example,dc=com will be mapped to the role managers . ClusterRoleMapper org.infinispan.security.impl.ClusterRoleMapper <cluster-role-mapper /> Uses the ClusterRegistry to store principal to role mappings. This allows the use of the CLI's GRANT and DENY commands to add/remove roles to a Principal. Custom Role Mapper <custom-role-mapper class="a.b.c" /> Supply the fully-qualified class name of an implementation of org.infinispan.security.impl.PrincipalRoleMapper Report a bug

Commands:
B.8.3. RHBA-2010:0844 - cluster and gfs2-utils bug fix update Updated cluster and gfs2-utils packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The cluster packages contain the core clustering libraries for Red Hat High Availability as well as utilities to maintain GFS2 file systems for users of Red Hat Resilient Storage. Bug Fixes BZ# 634201 The /proc/mounts file system is no longer updated with the wrong device. BZ# 638954 A 'service cman stop remove' command no longer erroneously and permanently sets the 'remove' flag for a node for every subsequent stop/leave operation. BZ# 639958 When two cluster nodes attempt to form a cluster with different configuration files, the one with the more recent version no longer gets killed. BZ# 637699 The fsck.gfs2 utility no longer crashes if journals are missing. All users of Red Hat High Availability and Red Hat Resilient Storage are advised to upgrade to these updated packages, which address these issues.

Commands:
5.353. virt-who 5.353.1. RHBA-2012:0900 - virt-who bug fix and enhancement update Updated virt-who packages that fix several bugs and add various enhancement are now available. The virt-who package provides an agent that collects information about virtual guests present in the system and reports them to the subscription manager. The virt-who package has been upgraded to upstream version 0.6, which provides a number of bug fixes and enhancements over the version. (BZ# 790000 ) Bug Fixes BZ# 746163 When the libvirtd daemon was stopped, the virt-who utility no longer received information about the state of the guest, and showed an inaccurate list of guest UUIDs. With this update, polling is used to check the connection to the libvirtd daemon, and the time for which the list of UUIDs is inaccurate was minimized. BZ# 813299 Prior to this update, the virt-who utility could not connect to the libvirt daemon due to a regression in the code that handles forking of the virt-who daemon. With this update, a connection is open to the libvirtd daemon after the fork of the virt-who daemon; thus, fixing this issue. BZ# 801657 This update includes a missing python-suds dependency into the virt-who specfile. The missing dependency was causing the virt-who daemon to fail to start. BZ# 806225 The virt-who daemon did not use double forking when it was started. Consequently, the daemon did not detach from the terminal correctly. With this update, virt-who uses double forking, and is able to correctly detach itself from the terminal. BZ# 815279 Previously, the virt-who utility could not handle all events that were being sent by the libvirtd daemon. If an unrecognized event was received, virt-who logged an IndexError in the logs, and returned a traceback error. With this update, virt-who handles all error events (even unknown), and no longer returns a traceback error. Users are advised to upgrade to these updated virt-who packages, which resolve these issues and add these enhancement.

Commands:
Chapter 78. token This chapter describes the commands under the token command. 78.1. token issue Issue new token Usage: Table 78.1. Command arguments Value Summary -h, --help Show this help message and exit Table 78.2. Output formatter options Value Summary -f {json,shell,table,value,yaml}, --format {json,shell,table,value,yaml} The output format, defaults to table -c COLUMN, --column COLUMN Specify the column(s) to include, can be repeated Table 78.3. JSON formatter options Value Summary --noindent Whether to disable indenting the json Table 78.4. Shell formatter options Value Summary --prefix PREFIX Add a prefix to all variable names Table 78.5. Table formatter options Value Summary --max-width <integer> Maximum display width, <1 to disable. you can also use the CLIFF_MAX_TERM_WIDTH environment variable, but the parameter takes precedence. --fit-width Fit the table to the display width. implied if --max- width greater than 0. Set the environment variable CLIFF_FIT_WIDTH=1 to always enable --print-empty Print empty table if there is no data to show. 78.2. token revoke Revoke existing token Usage: Table 78.6. Positional arguments Value Summary <token> Token to be deleted Table 78.7. Command arguments Value Summary -h, --help Show this help message and exit

Commands:
openstack token issue [-h] [-f {json,shell,table,value,yaml}] [-c COLUMN] [--noindent] [--prefix PREFIX] [--max-width <integer>] [--fit-width] [--print-empty]
openstack token revoke [-h] <token>
Chapter 1. Introduction to overcloud configuration Red Hat OpenStack Platform (RHOSP) director provides a set of tools that you can use to provision and create a fully featured OpenStack environment, also known as the overcloud. The Director Installation and Usage Guide covers the preparation and configuration of a basic overcloud. However, a production-level overcloud might require additional configuration: Basic network configuration to integrate the overcloud into your existing network infrastructure. Network traffic isolation on separate VLANs for certain OpenStack network traffic types. SSL configuration to secure communication on public endpoints Storage options such as NFS, iSCSI, Red Hat Ceph Storage, and multiple third-party storage devices. Red Hat Content Delivery Network node registration, or registration with your internal Red Hat Satellite 5 or 6 server. Various system-level options. Various OpenStack service options. Note The examples in this guide are optional steps to configure the overcloud. These steps are necessary only if you want to provide the overcloud with additional functionality. Use the steps that apply to the requirements of your environment.

Commands:
4.2. Link Elements Access to the Entry Point provides link elements and URIs for all of the resource collections the API exposes. Each collection uses a relation type to identify the URI a client needs. Table 4.1. Available Relationship Types Relationship Description capabilities Supported capabilities of the Red Hat Virtualization Manager. datacenters Data centers. clusters Host clusters. networks Virtual networks. storagedomains Storage domains. hosts Hosts. vms Virtual machines. disks Virtual disks. templates Templates. vmpools Virtual machine pools. domains Identity service domains. groups Imported identity service groups. roles Roles. users Users. tags Tags. events Events. Figure 4.1. The relationship between the API entry point and the resource collections exposed by the API Note All URIs shown in example responses are illustrative. The format of all URIs returned by the server is opaque. Clients navigate to specific resources through the entry point URI and use the relationship types to access the URIs. The server chooses to include absolute URIs or absolute paths [3] in the link element's href attribute, so clients are required to handle either form. The link elements also contain a set of search URIs for certain collections. These URIs use URI templates [4] to integrate search queries. The purpose of the URI template is to accept a search expression using the natural HTTP pattern of a query parameter. The client does not require prior knowledge of the URI structure. Thus clients should treat these templates as being opaque and access them with a URI template library. Each search query URI template is identified with a relation type using the convention "collection/search" . Table 4.2. Relationships associated with search query URIs Relationship Description datacenters/search Query data centers. clusters/search Query host clusters. storagedomains/search Query storage domains. hosts/search Query hosts. vms/search Query virtual machines. disks/search Query disks. templates/search Query templates. vmpools/search Query virtual machine pools. events/search Query events. users/search Query users. [3] The RFC describing Uniform Resource Locator Generic Syntax provides a Collected ABNF for URI that explains the difference between these forms. [4] The Internet-Draft describing the format of a URI Template is available at http://tools.ietf.org/html/draft-gregorio-uritemplate-03 .

Commands:
Chapter 5. mod_auth_openidc Apache HTTPD Module Warning Red Hat build of Keycloak does not provide any official support to mod_auth_openidc. The instructions below are best-effort and may not be up-to-date. We recommend that you stick to official mod_auth_openidc documentation for more details. The mod_auth_openidc is an Apache HTTP plugin for OpenID Connect. If your language/environment supports using Apache HTTPD as a proxy, then you can use mod_auth_openidc to secure your web application with OpenID Connect. Configuration of this module is beyond the scope of this document. Please see the mod_auth_openidc GitHub repo for more details on configuration. To configure mod_auth_openidc you'll need The client_id. The client_secret. The redirect_uri to your application. The Red Hat build of Keycloak openid-configuration url mod_auth_openidc specific Apache HTTPD module config. An example configuration would look like the following. Further information on how to configure mod_auth_openidc can be found on the mod_auth_openidc project page.

Commands:
LoadModule auth_openidc_module modules/mod_auth_openidc.so ServerName USD{HOSTIP} <VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html #this is required by mod_auth_openidc OIDCCryptoPassphrase a-random-secret-used-by-apache-oidc-and-balancer OIDCProviderMetadataURL USD{KC_ADDR}/realms/USD{KC_REALM}/.well-known/openid-configuration OIDCClientID USD{CLIENT_ID} OIDCClientSecret USD{CLIENT_SECRET} OIDCRedirectURI http://USD{HOSTIP}/USD{CLIENT_APP_NAME}/redirect_uri # maps the preferred_username claim to the REMOTE_USER environment variable OIDCRemoteUserClaim preferred_username <Location /USD{CLIENT_APP_NAME}/> AuthType openid-connect Require valid-user </Location> </VirtualHost>
Introduction Welcome to the Red Hat Enterprise Linux Introduction to System Adminitration . The Red Hat Enterprise Linux Introduction to System Adminitration contains introductory information for new Red Hat Enterprise Linux system administrators. It does not teach you how to perform a particular task under Red Hat Enterprise Linux; rather, it provides you with the background knowledge that more experienced system administrators have learned over time. This guide assumes you have a limited amount of experience as a Linux user, but no Linux system administration experience. If you are completely new to Linux in general (and Red Hat Enterprise Linux in particular), you should start by purchasing an introductory book on Linux. Each chapter in the Red Hat Enterprise Linux Introduction to System Adminitration has the following structure: Generic overview material -- This section discusses the topic of the chapter without going into details about a specific operating system, technology, or methodology. Red Hat Enterprise Linux-specific material -- This section addresses aspects of the topic related to Linux in general and Red Hat Enterprise Linux in particular. Additional resources for further study -- This section includes pointers to other Red Hat Enterprise Linux manuals, helpful websites, and books containing information applicable to the topic. By adopting a consistent structure, readers can more easily read the Red Hat Enterprise Linux Introduction to System Adminitration in whatever way they choose. For example, an experienced system administrator with little Red Hat Enterprise Linux experience could skim only the sections that specifically focus on Red Hat Enterprise Linux, while a new system adminstrator could start by reading only the generic overview sections, and using the Red Hat Enterprise Linux-specific sections as an introduction to more in-depth resources. While on the subject of more in-depth resources, the System Administrators Guide is an excellent resource for performing specific tasks in a Red Hat Enterprise Linux environment. Administrators requiring more in-depth, factual information should refer to the Reference Guide . HTML, PDF, and RPM versions of the manuals are available on the Red Hat Enterprise Linux Documentation CD and online at http://www.redhat.com/docs/manuals/enterprise/ . 1. Architecture-specific Information Unless otherwise noted, all information contained in this manual apply only to the x86 processor and processors featuring the Intel (R) Extended Memory 64 Technology ( Intel (R) EM64T) and AMD64 technologies. For architecture-specific information, refer to the Red Hat Enterprise Linux Installation Guide for your respective architecture.

Commands:
25.2. DM-Multipath Device Mapper Multipathing (DM-Multipath) is a feature that allows you to configure multiple I/O paths between server nodes and storage arrays into a single device. These I/O paths are physical SAN connections that can include separate cables, switches, and controllers. Multipathing aggregates the I/O paths, creating a new device that consists of the aggregated paths. DM-Multipath are used primarily for the following reasons: Redundancy DM-Multipath can provide failover in an active/passive configuration. In an active/passive configuration, only half the paths are used at any time for I/O. If any element of an I/O path (the cable, switch, or controller) fails, DM-Multipath switches to an alternate path. Improved Performance DM-Multipath can be configured in active/active mode, where I/O is spread over the paths in a round-robin fashion. In some configurations, DM-Multipath can detect loading on the I/O paths and dynamically re-balance the load. Important For comprehensive information on the deployment and configuration of DM-Multipath in your environment, refer to the Using DM-Multipath guide provided by Red Hat.

Commands:
Appendix C. Sample iscsigws.yml file Example

Commands:
service_type: iscsi service_id: iscsi placement: hosts: - host11 - magna12 spec: pool: iscsi_pool trusted_ip_list: "10.80.100.100,10.8.100.113,2620:52:0:880:225:90ff:fefc:1bf2,2620:52:0:880:225:90ff:fefc:1a8c" api_user: user1 api_password: password1
D.2. Directories in the /etc/sysconfig/ Directory The following directories are normally found in /etc/sysconfig/ . /etc/sysconfig/cbq/ This directory contains the configuration files needed to do Class Based Queuing for bandwidth management on network interfaces. CBQ divides user traffic into a hierarchy of classes based on any combination of IP addresses, protocols, and application types. /etc/sysconfig/networking/ This directory is used by the now deprecated Network Administration Tool ( system-config-network ), and its contents should not be edited manually. For more information about configuring network interfaces using graphical configuration tools, see Chapter 10, NetworkManager . /etc/sysconfig/network-scripts/ This directory contains the following network-related configuration files: Network configuration files for each configured network interface, such as ifcfg-eth0 for the eth0 Ethernet interface. Scripts used to bring network interfaces up and down, such as ifup and ifdown . Scripts used to bring ISDN interfaces up and down, such as ifup-isdn and ifdown-isdn . Various shared network function scripts which should not be edited directly. For more information on the /etc/sysconfig/network-scripts/ directory, see Chapter 11, Network Interfaces . /etc/sysconfig/rhn/ This directory contains the configuration files and GPG keys for Red Hat Network. No files in this directory should be edited by hand. For more information on Red Hat Network, see the Red Hat Network website online at https://rhn.redhat.com/ .

Commands: