mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 9. Organizations, locations, and lifecycle environments Red Hat Satellite takes a consolidated approach to Organization and Location management. System administrators define multiple Organizations and multiple Locations in a single Satellite Server. For example, a company might have three Organizations (Finance, Marketing, and Sales) across three countries (United States, United Kingdom, and Japan). In this example, Satellite Server manages all Organizations across all geographical Locations, creating nine distinct contexts for managing systems. In addition, users can define specific locations and nest them to create a hierarchy. For example, Satellite administrators might divide the United States into specific cities, such as Boston, Phoenix, or San Francisco. Figure 9.1. Example topology for Red Hat Satellite Satellite Server defines all locations and organizations. Each respective Satellite Capsule Server synchronizes content and handles configuration of systems in a different location. The main Satellite Server retains the management function, while the content and configuration is synchronized between the main Satellite Server and a Satellite Capsule Server assigned to certain locations. 9.1. Organizations Organizations divide Red Hat Satellite resources into logical groups based on ownership, purpose, content, security level, or other divisions. You can create and manage multiple organizations through Red Hat Satellite, then divide and assign your subscriptions to each individual organization. This provides a method of managing the content of several individual organizations under one management system. 9.2. Locations Locations divide organizations into logical groups based on geographical location. Each location is created and used by a single account, although each account can manage multiple locations and organizations. 9.3. Lifecycle environments Application lifecycles are divided into lifecycle environments which represent each stage of the application lifecycle. Lifecycle environments are linked to form an environment path . You can promote content along the environment path to the lifecycle environment when required. For example, if development ends on a particular version of an application, you can promote this version to the testing environment and start development on the version. Figure 9.2. An environment path containing four environments

Commands:
10.4. Driver Changes This section describes the driver changes in Red Hat Enterprise Linux 6. Note that all drivers are now loaded to initramfs by default. 10.4.1. Discontinued Drivers aic7xxx_old atp870u cpqarray DAC960 dc395x gdth hfs hfsplus megaraid net/tokenring/ paride qla1280 sound/core/oss sound/drivers/opl3/* sound/pci/nm256

Commands:
10.4. The Multi-Source Column in System Metadata The pseudo column is by default not present in your actual metadata; it is not added on source tables/procedures when you import the metadata. If you would like to use the multi-source column in your transformations to control which sources are accessed or updated or you would like the column reported via metadata facilities, there are several options: With either VDB type to make the multi-source column present in the system metadata, you can set the model property multisource.addColumn to true on a multi-source model. Care must be taken though when using this property in Teiid Designer as any transformation logic (views/procedures) that you have defined will not have been aware of the multi-source column and may fail validation upon server deployment. If using Teiid Designer, you can manually add the multi-source column. If using Dynamic VDBs, the pseudo-column will already be available to transformations, but will not be present in your System metadata by default. If you are using DDL and you would like to be selective (rather than using the multisource.addColumn property), you can manually add the column via DDL.

Commands:
probe::signal.procmask Name probe::signal.procmask - Examining or changing blocked signals Synopsis signal.procmask Values name Name of the probe point sigset The actual value to be set for sigset_t (correct?) how Indicates how to change the blocked signals; possible values are SIG_BLOCK=0 (for blocking signals), SIG_UNBLOCK=1 (for unblocking signals), and SIG_SETMASK=2 for setting the signal mask. sigset_addr The address of the signal set (sigset_t) to be implemented oldsigset_addr The old address of the signal set (sigset_t)

Commands:
Chapter 1. Introduction to scaling storage Red Hat OpenShift Data Foundation is a highly scalable storage system. OpenShift Data Foundation allows you to scale by adding the disks in the multiple of three, or three or any number depending upon the deployment type. For internal (dynamic provisioning) deployment mode, you can increase the capacity by adding 3 disks at a time. For internal-attached (Local Storage Operator based) mode, you can deploy with less than 3 failure domains. With flexible scale deployment enabled, you can scale up by adding any number of disks. For deployment with 3 failure domains, you will be able to scale up by adding disks in the multiple of 3. For scaling your storage in external mode, see Red Hat Ceph Storage documentation . Note You can use a maximum of nine storage devices per node. The high number of storage devices will lead to a higher recovery time during the loss of a node. This recommendation ensures that nodes stay below the cloud provider dynamic storage device attachment limits, and limits the recovery time after node failure with local storage devices. While scaling, you must ensure that there are enough CPU and Memory resources as per scaling requirement. Supported storage classes by default gp2-csi on AWS thin on VMware managed_premium on Microsoft Azure 1.1. Supported Deployments for Red Hat OpenShift Data Foundation User-provisioned infrastructure: Amazon Web Services (AWS) VMware Bare metal IBM Power IBM Z or IBM(R) LinuxONE Installer-provisioned infrastructure: Amazon Web Services (AWS) Microsoft Azure VMware Bare metal

Commands:
Release Notes for AMQ Streams 2.5 on RHEL Red Hat Streams for Apache Kafka 2.5 Highlights of what's new and what's changed with this release of AMQ Streams on Red Hat Enterprise Linux

Commands:
strimzi.authorization.grants.max.idle.time.seconds="300" strimzi.authorization.grants.gc.period.seconds="300" strimzi.authorization.reuse.grants="false"
listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required ; # oauth.username.claim="['user.info'].['user.id']" \ 1 oauth.fallback.username.claim="['client.info'].['client.id']" \ 2 #
client.quota.callback.class= io.strimzi.kafka.quotas.StaticQuotaCallback client.quota.callback.static.produce= 1000000 client.quota.callback.static.fetch= 1000000 client.quota.callback.static.storage.soft= 400000000000 client.quota.callback.static.storage.hard= 500000000000 client.quota.callback.static.storage.check-interval= 5
Chapter 52. CertificateAuthority schema reference Used in: KafkaSpec Configuration of how TLS certificates are used within the cluster. This applies to certificates used for both internal communication within the cluster and to certificates used for client access via Kafka.spec.kafka.listeners.tls . Property Description generateCertificateAuthority If true then Certificate Authority certificates will be generated automatically. Otherwise the user will need to provide a Secret with the CA certificate. Default is true. boolean generateSecretOwnerReference If true , the Cluster and Client CA Secrets are configured with the ownerReference set to the Kafka resource. If the Kafka resource is deleted when true , the CA Secrets are also deleted. If false , the ownerReference is disabled. If the Kafka resource is deleted when false , the CA Secrets are retained and available for reuse. Default is true . boolean validityDays The number of days generated certificates should be valid for. The default is 365. integer renewalDays The number of days in the certificate renewal period. This is the number of days before the a certificate expires during which renewal actions may be performed. When generateCertificateAuthority is true, this will cause the generation of a new certificate. When generateCertificateAuthority is true, this will cause extra logging at WARN level about the pending certificate expiry. Default is 30. integer certificateExpirationPolicy How should CA certificate expiration be handled when generateCertificateAuthority=true . The default is for a new CA certificate to be generated reusing the existing private key. string (one of [replace-key, renew-certificate])

Commands:
Chapter 4. OCI referrers OAuth access token In some cases, depending on the features that your Red Hat Quay deployment is configured to use, you might need to leverage an OCI referrers OAuth access token . OCI referrers OAuth access tokens are used to list OCI referrers of a manifest under a repository, and uses a curl command to make a GET request to the Red Hat Quay v2/auth endpoint. These tokens are obtained via basic HTTP authentication, wherein the user provides a username and password encoded in Base64 to authenticate directly with the v2/auth API endpoint. As such, they are based directly on the user's credentials aod do not follow the same detailed authorization flow as OAuth 2, but still allow a user to authorize API requests. OCI referrers OAuth access tokens do not offer scope-based permissions and do not expire. They are solely used to list OCI referrers of a manifest under a repository. Additional resource Attaching referrers to an image tag 4.1. Creating an OCI referrers OAuth access token This OCI referrers OAuth access token is used to list OCI referrers of a manifest under a repository. Procedure Update your config.yaml file to include the FEATURE_REFERRERS_API: true field. For example: # ... FEATURE_REFERRERS_API: true # ... Enter the following command to Base64 encode your credentials: USD echo -n '<username>:<password>' | base64 Example output abcdeWFkbWluOjE5ODlraWROZXQxIQ== Enter the following command to use the base64 encoded string and modify the URL endpoint to your Red Hat Quay server: USD curl --location '<quay-server.example.com>/v2/auth?service=<quay-server.example.com>&scope=repository:quay/listocireferrs:pull,push' --header 'Authorization: Basic <base64_username:password_encode_token>' -k | jq Example output { "token": "<example_secret> }

Commands:
FEATURE_REFERRERS_API: true
echo -n '<username>:<password>' | base64
abcdeWFkbWluOjE5ODlraWROZXQxIQ==
curl --location '<quay-server.example.com>/v2/auth?service=<quay-server.example.com>&scope=repository:quay/listocireferrs:pull,push' --header 'Authorization: Basic <base64_username:password_encode_token>' -k | jq
{ "token": "<example_secret> }
Chapter 2. Installing the MTR plugin for IntelliJ IDEA You can install the MTR plugin in the Ultimate and the Community Edition releases of IntelliJ IDEA. Prerequisites The following are the prerequisites for the Migration Toolkit for Runtimes (MTR) installation: Java Development Kit (JDK) is installed. MTR supports the following JDKs: OpenJDK 11 OpenJDK 17 Oracle JDK 11 Oracle JDK 17 Eclipse TemurinTM JDK 11 Eclipse TemurinTM JDK 17 8 GB RAM macOS installation: the value of maxproc must be 2048 or greater. The latest version of mtr-cli from the MTR download page Procedure In IntelliJ IDEA, click the Plugins tab on the Welcome screen. Enter Migration Toolkit for Runtimes in the Search field on the Marketplace tab. Select the Migration Toolkit for Runtimes (MTR) by Red Hat plugin and click Install . The plugin is listed on the Installed tab.

Commands:
Chapter 1. Introduction Red Hat Satellite provides a Representational State Transfer (REST) API. The API provides software developers and system administrators with control over their Red Hat Satellite environment outside of the standard web interface. The REST API is useful for developers and administrators who aim to integrate the functionality of Red Hat Satellite with custom scripts or external applications that access the API over HTTP. 1.1. Overview of the Red Hat Satellite API The benefits of using the REST API are: Broad client support - any programming language, framework, or system with support for HTTP protocol can use the API. Self-descriptive - client applications require minimal knowledge of the Red Hat Satellite infrastructure because a user discovers many details at runtime. Resource-based model - the resource-based REST model provides a natural way to manage a virtualization platform. You can use the REST API to perform the following tasks: Integrate with enterprise IT systems. Integrate with third-party applications. Perform automated maintenance or error checking tasks. Automate repetitive tasks with scripts. As you prepare to upgrade Satellite Server, ensure that any scripts you use that contain Satellite API commands are up to date. API commands differ between versions of Satellite. 1.2. Satellite API Compared to Hammer CLI Tool For many tasks, you can use both Hammer and Satellite API. You can use Hammer as a human-friendly interface to Satellite API. For example, to test responses to API calls before applying them in a script, use the --debug option to inspect API calls that Hammer issues: hammer --debug organization list . In the background, each Hammer command first establishes a binding to the API and then sends a request. This can have performance implications when executing a large number of Hammer commands in sequence. In contrast, scripts that use API commands communicate directly with the Satellite API. Note that you must manually update scripts that use API commands, while Hammer automatically reflects changes in the API. For more information, see the Hammer CLI Guide .

Commands:
4.11. Fence Virt (Serial/VMChannel Mode) Table 4.12, "Fence virt (Serial/VMChannel Mode)" lists the fence device parameters used by fence_virt , the fence agent for virtual machines using VM channel or serial mode . Table 4.12. Fence virt (Serial/VMChannel Mode) luci Field cluster.conf Attribute Description Name name A name for the Fence virt fence device. Serial Device serial_device On the host, the serial device must be mapped in each domain's configuration file. For more information, see the fence_virt man page. If this field is specified, it causes the fence_virt fencing agent to operate in serial mode. Not specifying a value causes the fence_virt fencing agent to operate in VM channel mode. Serial Parameters serial_params The serial parameters. The default is 115200, 8N1. VM Channel IP Address channel_address The channel IP. The default value is 10.0.2.179. Timeout (optional) timeout Fencing timeout, in seconds. The default value is 30. Domain port (formerly domain ) Virtual machine (domain UUID or name) to fence. ipport The channel port. The default value is 1229, which is the value used when configuring this fence device with luci . Delay (optional) delay Fencing delay, in seconds. The fence agent will wait the specified number of seconds before attempting a fencing operation. The default value is 0. The following command creates a fence device instance for virtual machines using serial mode. The following is the cluster.conf entry for the fence_virt device:

Commands:
ccs -f cluster.conf --addfencedev fencevirt1 agent=fence_virt serial_device=/dev/ttyS1 serial_params=19200, 8N1
<fencedevices> <fencedevice agent="fence_virt" name="fencevirt1" serial_device="/dev/ttyS1" serial_params="19200, 8N1"/> </fencedevices>
Providing feedback on Red Hat documentation We appreciate your feedback on our documentation. Provide as much detail as possible so that your request can be addressed. Prerequisites You have a Red Hat account. If you do not have a Red Hat account, you can create one by clicking Register on the Red Hat Customer Portal home page. You are logged in to your Red Hat account. Procedure To provide your feedback, click the following link: Create Issue Describe the issue or enhancement in the Summary text box. Provide more details about the issue or enhancement in the Description text box. If your Red Hat user name does not automatically appear in the Reporter text box, enter it. Scroll to the bottom of the page and then click the Create button. A documentation issue is created and routed to the appropriate documentation team. Thank you for taking the time to provide feedback.

Commands:
17.3. Delegating Host or Service Management in the Web UI Each host and service entry in the IdM web UI has a configuration tab that indicates what hosts have been delegated management control over that host or service. Open the Identity tab, and select the Hosts or Services subtab. Click the name of the host or service that you are going to grant delegated management to . Click the Hosts subtab on the far right of the host or service entry. This is the tab which lists hosts that can manage the selected host or service. Figure 17.2. Host Subtab Click the Add link at the top of the list. Click the check box by the names of the hosts to which to delegate management for the host or service. Click the right arrow button, > , to move the hosts to the selection box. Figure 17.3. Host/Service Delegation Management Click the Add button to close the selection box and to save the delegation settings.

Commands:
32.3.2. Displaying the Message Buffer To display the kernel message buffer, type the log command at the interactive prompt. Example 32.3. Displaying the kernel message buffer Type help log for more information on the command usage. Note The kernel message buffer includes the most essential information about the system crash and, as such, it is always dumped first in to the vmcore-dmesg.txt file. This is useful when an attempt to get the full vmcore file failed, for example because of lack of space on the target location. By default, vmcore-dmesg.txt is located in the /var/crash/ directory.

Commands:
crash> log ... several lines omitted EIP: 0060:[<c068124f>] EFLAGS: 00010096 CPU: 2 EIP is at sysrq_handle_crash+0xf/0x20 EAX: 00000063 EBX: 00000063 ECX: c09e1c8c EDX: 00000000 ESI: c0a09ca0 EDI: 00000286 EBP: 00000000 ESP: ef4dbf24 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Process bash (pid: 5591, ti=ef4da000 task=f196d560 task.ti=ef4da000) Stack: c068146b c0960891 c0968653 00000003 00000000 00000002 efade5c0 c06814d0 <0> fffffffb c068150f b7776000 f2600c40 c0569ec4 ef4dbf9c 00000002 b7776000 <0> efade5c0 00000002 b7776000 c0569e60 c051de50 ef4dbf9c f196d560 ef4dbfb4 Call Trace: [<c068146b>] ? __handle_sysrq+0xfb/0x160 [<c06814d0>] ? write_sysrq_trigger+0x0/0x50 [<c068150f>] ? write_sysrq_trigger+0x3f/0x50 [<c0569ec4>] ? proc_reg_write+0x64/0xa0 [<c0569e60>] ? proc_reg_write+0x0/0xa0 [<c051de50>] ? vfs_write+0xa0/0x190 [<c051e8d1>] ? sys_write+0x41/0x70 [<c0409adc>] ? syscall_call+0x7/0xb Code: a0 c0 01 0f b6 41 03 19 d2 f7 d2 83 e2 03 83 e0 cf c1 e2 04 09 d0 88 41 03 f3 c3 90 c7 05 c8 1b 9e c0 01 00 00 00 0f ae f8 89 f6 <c6> 05 00 00 00 00 01 c3 89 f6 8d bc 27 00 00 00 00 8d 50 d0 83 EIP: [<c068124f>] sysrq_handle_crash+0xf/0x20 SS:ESP 0068:ef4dbf24 CR2: 0000000000000000
12.2. Setting and Removing Cluster Properties To set the value of a cluster property, use the following pcs command. For example, to set the value of symmetric-cluster to false , use the following command. You can remove a cluster property from the configuration with the following command. Alternately, you can remove a cluster property from a configuration by leaving the value field of the pcs property set command blank. This restores that property to its default value. For example, if you have previously set the symmetric-cluster property to false , the following command removes the value you have set from the configuration and restores the value of symmetric-cluster to true , which is its default value.

Commands:
pcs property set property = value
pcs property set symmetric-cluster=false
pcs property unset property
pcs property set symmetic-cluster=
Preface Red Hat Quay is an enterprise-quality container registry. Use Red Hat Quay to build and store container images, then make them available to deploy across your enterprise. The Red Hat Quay Operator provides a simple method to deploy and manage Red Hat Quay on an OpenShift cluster. With the release of Red Hat Quay 3.4.0, the Red Hat Quay Operator was re-written to offer an enhanced experience and to add more support for Day 2 operations. As a result, the Red Hat Quay Operator is now simpler to use and is more opinionated. The key difference from versions prior to Red Hat Quay 3.4.0 include the following: The QuayEcosystem custom resource has been replaced with the QuayRegistry custom resource. The default installation options produces a fully supported Red Hat Quay environment, with all managed dependencies, such as database, caches, object storage, and so on, supported for production use. Note Some components might not be highly available. A new validation library for Red Hat Quay's configuration. Object storage can now be managed by the Red Hat Quay Operator using the ObjectBucketClaim Kubernetes API Note Red Hat OpenShift Data Foundation can be used to provide a supported implementation of this API on OpenShift Container Platform. Customization of the container images used by deployed pods for testing and development scenarios.

Commands:
7.2. Starting and Stopping a Cluster You can use the ccs command to stop a cluster by using the following command to stop cluster services on all nodes in the cluster: You can use the ccs command to start a cluster that is not running by using the following command to start cluster services on all nodes in the cluster: When you use the --startall option of the ccs command to start a cluster, the command automatically enables the cluster resources. For some configurations, such as when services have been intentionally disabled on one node to disable fence loops, you may not want to enable the services on that node. As of Red Hat Enterprise Linux 6.6 release, you can use the --noenable option of the ccs --startall command to prevent the services from being enabled:

Commands:
ccs -h host --stopall
ccs -h host --startall
ccs -h host --startall --noenable