mtpti5iD/redhat-docs_dataset huggingface dataset:
Appendix A. Using your subscription Streams for Apache Kafka 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 Streams for Apache Kafka for Apache Kafka entries in the INTEGRATION AND AUTOMATION category. Select the desired Streams for Apache Kafka product. The Software Downloads page opens. Click the Download link for your component. Installing packages with DNF To install a package and all the package dependencies, use: dnf install <package_name> To install a previously-downloaded package from a local directory, use: dnf install <path_to_download_package> Revised on 2024-09-25 08:45:33 UTC

Commands:
dnf install <package_name>
dnf install <path_to_download_package>
18.4. Configuring Locations A location is a set of maps, which are all stored in auto.master , and a location can store multiple maps. The location entry only works as a container for map entries; it is not an automount configuration in and of itself. Important Identity Management does not set up or configure autofs. That must be done separately. Identity Management works with an existing autofs deployment. 18.4.1. Configuring Locations through the Web UI Click the Policy tab. Click the Automount subtab. Click the Add link at the top of the list of automount locations. Enter the name for the new location. Click the Add and Edit button to go to the map configuration for the new location. Create maps, as described in Section 18.5.1.1, "Configuring Direct Maps from the Web UI" and Section 18.5.2.1, "Configuring Indirect Maps from the Web UI" . 18.4.2. Configuring Locations through the Command Line To create a map, using the automountlocation-add and give the location name. For example: When a new location is created, two maps are automatically created for it, auto.master and auto.direct . auto.master is the root map for all automount maps for the location. auto.direct is the default map for direct mounts and is mounted on /- . To view all of the maps configured for a location as if they were deployed on a filesystem, use the automountlocation-tofiles command:

Commands:
ipa automountlocation-add location
ipa automountlocation-add raleigh ---------------------------------- Added automount location "raleigh" ---------------------------------- Location: raleigh
ipa automountlocation-tofiles raleigh /etc/auto.master: /- /etc/auto.direct --------------------------- /etc/auto.direct:
Chapter 11. Uploading the results file of the executed test plan to Red Hat Certification portal Prerequisites You have downloaded the test results file from either the SUT or Cockpit. Procedure Log in to Red Hat Certification portal . On the homepage, enter the product case number in the search bar. Select the case number from the list that is displayed. On the Summary tab, under the Files section, click Upload . Red Hat will review the submitted test results file and suggest the steps. Additional resources For more information, visit Red Hat Certification portal .

Commands:
5. Power Management Note The Power Management Guide provides information on effectively managing power consumption on Red Hat Enterprise Linux 6. 5.1. powertop The introduction of the tickless kernel in Red Hat Enterprise Linux 6 (refer to Section 12.4.2, "Tickless Kernel" ) allows the CPU to enter the idle state more frequently, reducing power consumption and improving power management. The new powertop tool provides the ability to identify specific components of kernel and userspace applications that frequently wake up the CPU. powertop was used in development to identify and tune many applications in this release, reducing unnecessary CPU wake up by a factor of 10. 5.2. tuned tuned is a system tuning daemon that monitors system components and dynamically tunes system settings. Utilizing ktune (the static mechanism for system tuning), tuned can monitor and tune devices (e.g. hard disk drives and ethernet devices). Red Hat Enterprise Linux 6 also introduces diskdevstat for monitoring disk operations and netdevstat for monitoring network operations.

Commands:
Chapter 3. Automatic starting of a dynamic JFR recording When the Cryostat agent is enabled to start JFR recordings and the custom trigger condition for a dynamic recording is met, the Cryostat agent automatically starts the recording from within the target application. The Cryostat agent automatically assigns a name to the JFR recording, which is always in a cryostat-smart-trigger- X format, where X represents the recording ID. The JVM automatically generates the recording ID, which is an incremental numeric value that is unique for each JFR recording that is started within the JVM. When the Cryostat agent starts a dynamic JFR recording, you can subsequently view this recording in the Active Recordings tab in the Cryostat web console. For more information about using the Active Recordings tab, see Creating a JFR recording with Cryostat .

Commands:
25.2. Types The main permission control method used in SELinux targeted policy to provide advanced process isolation is Type Enforcement. All files and processes are labeled with a type: types define a SELinux domain for processes and a SELinux type for files. SELinux policy rules define how types access each other, whether it be a domain accessing a type, or a domain accessing another domain. Access is only allowed if a specific SELinux policy rule exists that allows it. The following types are used with OpenShift. Different types allow you to configure flexible access: Process types openshift_t The OpenShift process is associated with the openshift_t SELinux type. Types on executables openshift_cgroup_read_exec_t SELinux allows files with this type to transition an executable to the openshift_cgroup_read_t domain. openshift_cron_exec_t SELinux allows files with this type to transition an executable to the openshift_cron_t domain. openshift_initrc_exec_t SELinux allows files with this type to transition an executable to the openshift_initrc_t domain. Writable types openshift_cgroup_read_tmp_t This type allows OpenShift control groups (cgroup) read and access temporary files in the /tmp directory. openshift_cron_tmp_t This type allows storing temporary files of the OpenShift cron jobs in /tmp . openshift_initrc_tmp_t This type allows storing the OpenShift initrc temporary files in /tmp . openshift_log_t Files with this type are treated as OpenShift log data, usually stored under the /var/log/ directory. openshift_rw_file_t OpenShift have permission to read and to write to files labeled with this type. openshift_tmp_t This type is used for storing the OpenShift temporary files in /tmp . openshift_tmpfs_t This type allows storing the OpenShift data on a tmpfs file system. openshift_var_lib_t This type allows storing the OpenShift files in the /var/lib/ directory. openshift_var_run_t This type allows storing the OpenShift files in the /run/ or /var/run/ directory.

Commands:
6.3. I/O Scheduling with Red Hat Enterprise Linux as a Virtualization Guest You can use I/O scheduling on a Red Hat Enterprise Linux guest virtual machine, regardless of the hypervisor on which the guest is running. The following is a list of benefits and issues that should be considered: Red Hat Enterprise Linux guests often benefit greatly from the noop scheduler. This noop scheduler allows the host machine or hypervisor to optimize the input/output requests. The noop scheduler can combine small requests from the guest operating system into larger requests, before handing the I/O to the hypervisor. However, noop tries to use the fewest number of CPU cycles in the guest for I/O scheduling. The host/hypervisor has an overview of the requests of all guests and uses a separate strategy for handling I/O. Note For Red Hat Enterprise Linux 7.2 and newer, virtio-blk always uses noop implicitly. This is because it uses blk-mq . Depending on the workload I/O and how storage devices are attached, schedulers like deadline can be more advantageous. Performance testing is required to verify which scheduler is the best one to use in each situation. All scheduler tuning should be tested under normal operating conditions, as synthetic benchmarks typically do not accurately compare performance of systems using shared resources in virtual environments. Guests using storage accessed by iSCSI, SR-IOV, or physical device passthrough should not use the noop scheduler. These methods do not allow the host to optimize I/O requests to the underlying physical device. In virtualized environments, sometimes it is not beneficial to schedule I/O on both the host and guest layers. If multiple guests use storage on a filesystem or block device managed by the host operating system, the host may be able to schedule I/O more efficiently because it is aware of requests from all guests and knows the physical layout of storage, which may not map linearly to the guests' virtual storage. On the other hand, depending on the workload, it may be beneficial to use a scheduler like deadline in the guest virtual machine.

Commands:
Chapter 9. Clair security scans Clair security scanner is not enabled for Red Hat Quay by default. To enable Clair, see Clair on Red Hat Quay . Clair security scans can be viewed on the UI, or by the API. Procedure Navigate to a repository and click Tags in the navigation pane. This page shows the results of the security scan. To reveal more information about multi-architecture images, click See Child Manifests to see the list of manifests in extended view. Click a relevant link under See Child Manifests , for example, 1 Unknown to be redirected to the Security Scanner page. The Security Scanner page provides information for the tag, such as which CVEs the image is susceptible to, and what remediation options you might have available. Note Image scanning only lists vulnerabilities found by Clair security scanner. What users do about the vulnerabilities are uncovered is up to said user. Red Hat Quay superusers do not act on found vulnerabilities. 9.1. Viewing Clair security scans by using the UI You can view Clair security scans on the UI. Procedure Navigate to a repository and click Tags in the navigation pane. This page shows the results of the security scan. To reveal more information about multi-architecture images, click See Child Manifests to see the list of manifests in extended view. Click a relevant link under See Child Manifests , for example, 1 Unknown to be redirected to the Security Scanner page. The Security Scanner page provides information for the tag, such as which CVEs the image is susceptible to, and what remediation options you might have available. Note Image scanning only lists vulnerabilities found by Clair security scanner. What users do about the vulnerabilities are uncovered is up to said user. Red Hat Quay superusers do not act on found vulnerabilities. 9.2. View Clair security scans by using the API You can view Clair security scans by using the API. Procedure Use the GET /api/v1/repository/{repository}/manifest/{manifestref}/security endpoint to retrieve security information about a specific manifest in a repository. For example: USD curl -X GET \ -H "Authorization: Bearer <bearer_token>" \ -H "Accept: application/json" \ "https://quay-server.example.com/api/v1/repository/<namespace>/<repository>/manifest/<manifest_digest>/security?vulnerabilities=<true_or_false>" Example output {"status": "queued", "data": null}

Commands:
curl -X GET -H "Authorization: Bearer <bearer_token>" -H "Accept: application/json" "https://quay-server.example.com/api/v1/repository/<namespace>/<repository>/manifest/<manifest_digest>/security?vulnerabilities=<true_or_false>"
status: queued
Chapter 5. Configuring Cluster Resources This chapter provides information on configuring resources in a cluster. 5.1. Resource Creation Use the following command to create a cluster resource. For example, the following command creates a resource with the name VirtualIP of standard ocf , provider heartbeat , and type IPaddr2 . The floating address of this resource is 192.168.0.120, the system will check whether the resource is running every 30 seconds. Alternately, you can omit the standard and provider fields and use the following command. This will default to a standard of ocf and a provider of heartbeat . As of the Red Hat Enterprise Linux 6.8 release, resources start as soon as their state has been confirmed on all nodes and all dependencies have been satisfied, rather than waiting for the state of all resources to be confirmed. This allows for faster startup of some services, and more even startup load. Use the following command to delete a configured resource. For example, the following command deletes an existing resource with a resource ID of VirtualIP For information on the resource_id , standard , provider , and type fields of the pcs resource create command, see Section 5.2, "Resource Properties" . For information on defining resource parameters for individual resources, see Section 5.3, "Resource-Specific Parameters" . For information on defining resource meta options, which are used by the cluster to decide how a resource should behave, see Section 5.4, "Resource Meta Options" . For information on defining the operations to perform on a resource, see Section 5.6, "Resource Operations" .

Commands:
pcs resource create resource_id standard:provider:type | type [ resource options ]
pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.120 cidr_netmask=24 op monitor interval=30s
pcs resource create VirtualIP IPaddr2 ip=192.168.0.120 cidr_netmask=24 op monitor interval=30s
pcs resource delete resource_id
pcs resource delete VirtualIP
3.8. Attaching a Storage Domain to a Data Center This Ruby example attaches an existing NFS storage domain, mydata , to an existing data center, mydc . This example is used to attach both data and ISO storage domains. # Get the reference to the root of the services tree: system_service = connection.system_service # Locate the service that manages the storage domains and use it to # search for the storage domain: sds_service = system_service.storage_domains_service sd = sds_service.list(search: 'name=mydata')[0] # Locate the service that manages the data centers and use it to # search for the data center: dcs_service = system_service.data_centers_service dc = dcs_service.list(search: 'name=mydc')[0] # Locate the service that manages the data center where you want to # attach the storage domain: dc_service = dcs_service.data_center_service(dc.id) # Locate the service that manages the storage domains that are attached # to the data centers: attached_sds_service = dc_service.storage_domains_service # Use the "add" method of service that manages the attached storage # domains to attach it: attached_sds_service.add( OvirtSDK4::StorageDomain.new( id: sd.id ) ) # Wait until the storage domain is active: attached_sd_service = attached_sds_service.storage_domain_service(sd.id) loop do sleep(5) sd = attached_sd_service.get break if sd.status == OvirtSDK4::StorageDomainStatus::ACTIVE end For more information, see http://www.rubydoc.info/gems/ovirt-engine-sdk/OvirtSDK4/StorageDomainsService:add .

Commands:
Get the reference to the root of the services tree: system_service = connection.system_service Locate the service that manages the storage domains and use it to search for the storage domain: sds_service = system_service.storage_domains_service sd = sds_service.list(search: 'name=mydata')[0] Locate the service that manages the data centers and use it to search for the data center: dcs_service = system_service.data_centers_service dc = dcs_service.list(search: 'name=mydc')[0] Locate the service that manages the data center where you want to attach the storage domain: dc_service = dcs_service.data_center_service(dc.id) Locate the service that manages the storage domains that are attached to the data centers: attached_sds_service = dc_service.storage_domains_service Use the "add" method of service that manages the attached storage domains to attach it: attached_sds_service.add( OvirtSDK4::StorageDomain.new( id: sd.id ) ) Wait until the storage domain is active: attached_sd_service = attached_sds_service.storage_domain_service(sd.id) loop do sleep(5) sd = attached_sd_service.get break if sd.status == OvirtSDK4::StorageDomainStatus::ACTIVE end
Chapter 5. Using the search query string parameter Procedure Use the search query string parameter to perform a non-case-sensitive search within all designated text fields of a model: https://<server name>/api/v2/model_verbose_name?search=findme To search across related fields, use the following: https://<server name>/api/v2/model_verbose_name?related__search=findme

Commands:
https://<server name>/api/v2/model_verbose_name?search=findme
https://<server name>/api/v2/model_verbose_name?related__search=findme
Chapter 8. Configuring the systems and running tests using RHCert CLI Tool Cockpit is the preferred method to configure systems and run tests. However, RHCert CLI will be continued as an alternative for performing the same tasks. 8.1. Using the test plan to provision the Controller and Compute nodes for testing Provisioning the Controller and Compute nodes through the test host performs several operations, such as installing the required packages on the two nodes based on the certification type and creating a final test plan to run. The final test plan is generated based on the test roles defined for each node and has a list of common tests taken from both the test plan provided by Red Hat and tests generated on discovering the system requirements. For instance, required OpenStack packages will be installed if the test plan is designed for certifying an OpenStack plugin. Prerequisites You have the IP address of both the Controller and Compute nodes. You have downloaded the test plan to the test host. Procedure Log into the test host using CLI. Provision the Controller and Compute nodes from the test host. Replace <path_to_test_plan_document> with the test plan file saved on the test host. Example: In addition to starting the Controller and Compute nodes and sending the test plan to both the nodes where the tests actually run, the command also establishes communication between the test host and each node. Select the RHOSP administrator account when prompted. Note Enter "tripleo-admin" if you use RHOSP 17.1 or later. Enter "heat-admin" if you use RHOSP 17 or earlier. Enter "root" if you have configured root as the ssh user for Controller and Compute nodes. Select None for "What is this host's role" when prompted. Tests applicable for each node will be displayed. 8.2. Running the certification tests using CLI Note The tests run in the foreground on the Controller node, they are interactive and will prompt you for inputs, whereas the tests run in the background on the Compute node and are non-interactive. Procedure Run tests Example: Select the RHOSP administrator account when prompted. Note Enter "tripleo-admin" if you use RHOSP 17.1 or later. Enter "heat-admin" if you use RHOSP 17 or earlier. Enter "root" if you have configured root as the ssh user for Controller and Compute nodes. When prompted, choose whether to run each test by typing yes or no . You can also run particular tests from the list by typing select . Separate test results from each node are transferred to the test host, where they are merged into a single result file. By default, the result file is saved as /var/rhcert/save/rhcert-multi-openstack-<certification ID>-<timestamp>.xml .

Commands:
rhcert-provision <path_to_test_plan_document> --host controller:<IP address of the controller> --host compute:<IP address of the compute>
rhcert-provision rhosp_test_plan.xml --host controller:192.168.24.23 --host compute:192.168.24.32
rhcert-run --host controller:<_IP address of the controller_> --host compute:<_IP address of the compute_>
rhcert-run --host controller:192.168.24.23 --host compute:192.168.24.32
Chapter 1. Installing a sample instance of Red Hat Single Sign-On This section describes how to install and start a Red Hat Single Sign-On server in standalone mode, set up the initial admin user, and log in to the Red Hat Single Sign-On Admin Console. Additional Resources This installation is intended for practice use of Red Hat Single Sign-On. For instructions on installation in a production environment and full details on all product features, see the other guides in the Red Hat Single Sign-On documentation. 1.1. Installing the Red Hat Single Sign-On server For this sample instance of Red Hat Single Sign-On, this procedure involves installation in standalone mode. The server download ZIP file contains the scripts and binaries to run the Red Hat Single Sign-On server. You can install the server on Linux or Windows. Procedure Go to the Red Hat customer portal . Download the Red Hat Single Sign-On Server: rh-sso-7.4.0.zip Place the file in a directory you choose. Unpack the ZIP file using the appropriate unzip utility, such as unzip, or Expand-Archive. Linux/Unix USD unzip rhsso-7.4.0.zip Windows > Expand-Archive -Path 'C:Downloads\rhsso-7.4.0.zip' -DestinationPath 'C:\Downloads' 1.2. Starting the Red Hat Single Sign-On server You start the server on the system where you installed it. Prerequisites You saw no errors during the Red Hat Single Sign-On server installation. Procedure Go to the bin directory of the server distribution. Run the standalone boot script. Linux/Unix USD cd bin USD ./standalone.sh Windows > ...\bin\standalone.bat 1.3. Creating the admin account Before you can use Red Hat Single Sign-On, you need to create an admin account which you use to log in to the Red Hat Single Sign-On admin console. Prerequisites You saw no errors when you started the Red Hat Single Sign-On server. Procedure Open http://localhost:8080/auth in your web browser. The welcome page opens, confirming that the server is running. Welcome page Enter a username and password to create an initial admin user. 1.4. Logging into the admin console After you create the initial admin account, you can log in to the admin console. In this console, you add users and register applications to be secured by Red Hat Single Sign-On. Prerequisites You have an admin account for the admin console. Procedure Click the Administration Console link on the Welcome page or go directly to http://localhost:8080/auth/admin/ (the console URL). Note The Administration Console is generally referred to as the admin console for short in Red Hat Single Sign-On documentation. Enter the username and password you created on the Welcome page to open the admin console . Admin console login screen The initial screen for the admin console appears. Admin console steps Now that you can log into the admin console, you can begin creating realms where administrators can create users and give them access to applications. For more details, see Creating a realm and a user .

Commands:
unzip rhsso-7.4.0.zip
> Expand-Archive -Path 'C:Downloads\rhsso-7.4.0.zip' -DestinationPath 'C:\Downloads'
cd bin ./standalone.sh
> ...\bin\standalone.bat