mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Key features AMQ Streams simplifies the process of running Apache Kafka in an OpenShift cluster. This guide is intended as a starting point for building an understanding of AMQ Streams. The guide introduces some of the key concepts behind Kafka, which is central to AMQ Streams, explaining briefly the purpose of Kafka components. Configuration points are outlined, including options to secure and monitor Kafka. A distribution of AMQ Streams provides the files to deploy and manage a Kafka cluster, as well as example files for configuration and monitoring of your deployment. A typical Kafka deployment is described, as well as the tools used to deploy and manage Kafka. 1.1. Kafka capabilities The underlying data stream-processing capabilities and component architecture of Kafka can deliver: Microservices and other applications to share data with extremely high throughput and low latency Message ordering guarantees Message rewind/replay from data storage to reconstruct an application state Message compaction to remove old records when using a key-value log Horizontal scalability in a cluster configuration Replication of data to control fault tolerance Retention of high volumes of data for immediate access 1.2. Kafka use cases Kafka's capabilities make it suitable for: Event-driven architectures Event sourcing to capture changes to the state of an application as a log of events Message brokering Website activity tracking Operational monitoring through metrics Log collection and aggregation Commit logs for distributed systems Stream processing so that applications can respond to data in real time 1.3. How AMQ Streams supports Kafka AMQ Streams provides container images and Operators for running Kafka on OpenShift. AMQ Streams Operators are fundamental to the running of AMQ Streams. The Operators provided with AMQ Streams are purpose-built with specialist operational knowledge to effectively manage Kafka. Operators simplify the process of: Deploying and running Kafka clusters Deploying and running Kafka components Configuring access to Kafka Securing access to Kafka Upgrading Kafka Managing brokers Creating and managing topics Creating and managing users

Commands:
7.3.2.2.4. Optimising for applications that use extended attributes XFS can store small attributes directly in the inode if space is available in the inode. If the attribute fits into the inode, then it can be retrieved and modified without requiring extra I/O to retrieve separate attribute blocks. The performance differential between in-line and out-of-line attributes can easily be an order of magnitude slower for out-of-line attributes. For the default inode size of 256 bytes, roughly 100 bytes of attribute space is available depending on the number of data extent pointers also stored in the inode. The default inode size is really only useful for storing a small number of small attributes. Increasing the inode size at mkfs time can increase the amount of space available for storing attributes in-line. A 512 byte inode size increases the space available for attributes to roughly 350 bytes; a 2 KB inode has roughly 1900 bytes of space available. There is, however, a limit on the size of the individual attributes that can be stored in-line - there is a maximum size limit of 254 bytes for both the attribute name and the value (that is, an attribute with a name length of 254 bytes and a value length of 254 bytes will stay in-line). Exceeding these size limits forces the attributes out of line, even if there would have been enough space to store all the attributes in the inode.

Commands:
Chapter 17. Delegating Access to Hosts and Services To manage in the context of this chapter means being able to retrieve a keytab and certificates for another host or service. Every host and service has a managedby entry which lists what hosts or services can manage it. By default, a host can manage itself and all of its services. It is also possible to allow a host to manage other hosts, or services on other hosts, by updating the appropriate delegations or providing a suitable managedby entry. An IdM service can be managed from any IdM host, as long as that host has been granted, or delegated , permission to access the service. Likewise, hosts can be delegated permissions to other hosts within the domain. Figure 17.1. Host and Service Delegation Note If a host is delegated authority to another host through a managedBy entry, it does not mean that the host has also been delegated management for all services on that host. Each delegation has to be performed independently. 17.1. Delegating Service Management A host is delegated control over a service using the service-add-host utility: There are two parts to delegating the service: Specifying the principal using the principal argument. Identifying the hosts with the control using the --hosts option. For example: Once the host is delegated authority, the host principal can be used to manage the service: To create a ticket for this service, create a certificate request on the host with the delegated authority: Use the cert-request utility to create a service entry and load the certification information: For more information on creating certificate requests and using ipa cert-request , see Section 24.1.1, "Requesting New Certificates for a User, Host, or Service" .

Commands:
ipa service-add-host principal --hosts= hostname
ipa service-add HTTP/web.example.com ipa service-add-host HTTP/web.example.com --hosts=client1.example.com
kinit -kt /etc/krb5.keytab host/client1.example.com ipa-getkeytab -s server.example.com -k /tmp/test.keytab -p HTTP/web.example.com Keytab successfully retrieved and stored in: /tmp/test.keytab
kinit -kt /etc/krb5.keytab host/client1.example.com openssl req -newkey rsa:2048 -subj '/CN=web.example.com/O=EXAMPLE.COM' -keyout /etc/pki/tls/web.key -out /tmp/web.csr -nodes Generating a 2048 bit RSA private key .............................................................+++ ............................................................................................+++ Writing new private key to '/etc/pki/tls/private/web.key'
ipa cert-request --principal=HTTP/web.example.com web.csr Certificate: MIICETCCAXqgA...[snip] Subject: CN=web.example.com,O=EXAMPLE.COM Issuer: CN=EXAMPLE.COM Certificate Authority Not Before: Tue Feb 08 18:51:51 2011 UTC Not After: Mon Feb 08 18:51:51 2016 UTC Serial number: 1005
4.104. iwl6000g2a-firmware 4.104.1. RHEA-2011:1681 - iwl6000g2a-firmware enhancement update An updated iwl6000g2a-firmware package that adds an enhancement is now available for Red Hat Enterprise Linux 6. The iwl6000g2a-firmware package provides the firmware required by the iwlagn driver for Linux to support Intel Wireless WiFi Link 6005 series adapters. The iwl6000g2a-firmware package has been upgraded to upstream version 17.168.5.3, which provides an enhancement over the version. (BZ# 729438 ) All users of the iwlagn driver are advised to upgrade to this updated iwl6000g2a-firmware package, which adds this enhancement.

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 AMQ Streams for Apache Kafka 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. 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-04-29 12:48:52 UTC

Commands:
dnf install <package_name>
dnf install <path_to_download_package>
19.5. Adding a Remote Connection This procedure covers how to set up a connection to a remote system using virt-manager . To create a new connection open the File menu and select the Add Connection menu item. The Add Connection wizard appears. Select the hypervisor. For Red Hat Enterprise Linux 7, systems select QEMU/KVM . Select Local for the local system or one of the remote connection options and click Connect . This example uses Remote tunnel over SSH, which works on default installations. For more information on configuring remote connections, see Chapter 18, Remote Management of Guests Figure 19.10. Add Connection Enter the root password for the selected host when prompted. A remote host is now connected and appears in the main virt-manager window. Figure 19.11. Remote host in the main virt-manager window

Commands:
Chapter 5. About the multicluster engine for Kubernetes Operator One of the challenges of scaling Kubernetes environments is managing the lifecycle of a growing fleet. To meet that challenge, you can use the multicluster engine Operator. The operator delivers full lifecycle capabilities for managed OpenShift Container Platform clusters and partial lifecycle management for other Kubernetes distributions. It is available in two ways: As a standalone operator that you install as part of your OpenShift Container Platform or OpenShift Kubernetes Engine subscription As part of Red Hat Advanced Cluster Management for Kubernetes 5.1. Cluster management with multicluster engine on OpenShift Container Platform When you enable multicluster engine on OpenShift Container Platform, you gain the following capabilities: Hosted control planes , which is a feature that is based on the HyperShift project. With a centralized hosted control plane, you can operate OpenShift Container Platform clusters in a hyperscale manner. Hive, which provisions self-managed OpenShift Container Platform clusters to the hub and completes the initial configurations for those clusters. klusterlet agent, which registers managed clusters to the hub. Infrastructure Operator, which manages the deployment of the Assisted Service to orchestrate on-premise bare metal and vSphere installations of OpenShift Container Platform, such as SNO on bare metal. The Infrastructure Operator includes zero touch provisioning (ZTP) , which fully automates cluster creation on bare metal and vSphere provisioning with GitOps workflows to manage deployments and configuration changes. Open cluster management, which provides resources to manage Kubernetes clusters. The multicluster engine is included with your OpenShift Container Platform support subscription and is delivered separately from the core payload. To start to use multicluster engine, you deploy the OpenShift Container Platform cluster and then install the operator. For more information, see the installation documentation . 5.2. Cluster management with Red Hat Advanced Cluster Management If you need cluster management capabilities beyond what OpenShift Container Platform with multicluster engine can provide, consider Red Hat Advanced Cluster Management. The multicluster engine is an integral part of Red Hat Advanced Cluster Management and is enabled by default. 5.3. Additional resources For the complete documentation for multicluster engine, see multicluster engine documentation , which is part of the product documentation for Red Hat Advanced Cluster Management.

Commands:
Chapter 16. Annotating encrypted RBD storage classes Starting with OpenShift Data Foundation 4.14, when the OpenShift console creates a RADOS block device (RBD) storage class with encryption enabled, the annotation is set automatically. However, you need to add the annotation, cdi.kubevirt.io/clone-strategy=copy for any of the encrypted RBD storage classes that were previously created before updating to the OpenShift Data Foundation version 4.14. This enables customer data integration (CDI) to use host-assisted cloning instead of the default smart cloning. The keys used to access an encrypted volume are tied to the namespace where the volume was created. When cloning an encrypted volume to a new namespace, such as, provisioning a new OpenShift Virtualization virtual machine, a new volume must be created and the content of the source volume must then be copied into the new volume. This behavior is triggered automatically if the storage class is properly annotated.

Commands:
Appendix B. Using Red Hat Enterprise Linux packages This section describes how to use software delivered as RPM packages for Red Hat Enterprise Linux. To ensure the RPM packages for this product are available, you must first register your system . B.1. Overview A component such as a library or server often has multiple packages associated with it. You do not have to install them all. You can install only the ones you need. The primary package typically has the simplest name, without additional qualifiers. This package provides all the required interfaces for using the component at program run time. Packages with names ending in -devel contain headers for C and C++ libraries. These are required at compile time to build programs that depend on this package. Packages with names ending in -docs contain documentation and example programs for the component. For more information about using RPM packages, see one of the following resources: Red Hat Enterprise Linux 6 - Installing and managing software Red Hat Enterprise Linux 7 - Installing and managing software Red Hat Enterprise Linux 8 - Managing software packages B.2. Searching for packages To search for packages, use the yum search command. The search results include package names, which you can use as the value for <package> in the other commands listed in this section. USD yum search <keyword>... B.3. Installing packages To install packages, use the yum install command. USD sudo yum install <package>... B.4. Querying package information To list the packages installed in your system, use the rpm -qa command. USD rpm -qa To get information about a particular package, use the rpm -qi command. USD rpm -qi <package> To list all the files associated with a package, use the rpm -ql command. USD rpm -ql <package>

Commands:
yum search <keyword>
sudo yum install <package>
rpm -qa
rpm -qi <package>
rpm -ql <package>
Chapter 4. Verifying permissions of IdM configuration files using Healthcheck Learn more about how to test Identity Management (IdM) configuration files using the Healthcheck tool. For details, see Healthcheck in IdM . 4.1. File permissions Healthcheck tests The Healthcheck tool tests ownership and permissions of some important files installed or configured by Identity Management (IdM). If you change the ownership or permissions of any tested file, the test returns a warning in the result section. While it does not necessarily mean that the configuration will not work, it means that the file differs from the default configuration. To see all tests, run the ipa-healthcheck with the --list-sources option: You can find the file permissions test under the ipahealthcheck.ipa.files source: IPAFileNSSDBCheck This test checks the 389-ds NSS database and the Certificate Authority (CA) database. The 389-ds database is located in /etc/dirsrv/slapd-<dashed-REALM> and the CA database is located in /etc/pki/pki-tomcat/alias/ . IPAFileCheck This test checks the following files: /var/lib/ipa/ra-agent.{key|pem} /var/lib/ipa/certs/httpd.pem /var/lib/ipa/private/httpd.key /etc/httpd/alias/ipasession.key /etc/dirsrv/ds.keytab /etc/ipa/ca.crt /etc/ipa/custodia/server.keys If PKINIT is enabled: /var/lib/ipa/certs/kdc.pem /var/lib/ipa/private/kdc.key If DNS is configured: /etc/named.keytab /etc/ipa/dnssec/ipa-dnskeysyncd.keytab TomcatFileCheck This test checks some tomcat-specific files if a CA is configured: /etc/pki/pki-tomcat/password.conf /var/lib/pki/pki-tomcat/conf/ca/CS.cfg /etc/pki/pki-tomcat/server.xml Note Run these tests on all IdM servers when trying to find issues. 4.2. Screening configuration files using Healthcheck Follow this procedure to run a standalone manual test of an Identity Management (IdM) server's configuration files using the Healthcheck tool. The Healthcheck tool includes many tests. Results can be narrowed down by: Excluding all successful test: --failures-only Including only ownership and permissions tests: --source=ipahealthcheck.ipa.files Procedure To run Healthcheck tests on IdM configuration file ownership and permissions, while displaying only warnings, errors and critical issues, enter: A successful test displays empty brackets: Failed tests display results similar to the following WARNING : Additional resources See man ipa-healthcheck .

Commands:
ipa-healthcheck --list-sources
ipa-healthcheck --source=ipahealthcheck.ipa.files --failures-only
ipa-healthcheck --source=ipahealthcheck.ipa.files --failures-only []
{ "source": "ipahealthcheck.ipa.files", "check": "IPAFileNSSDBCheck", "result": "WARNING", "kw": { "key": "_etc_dirsrv_slapd-EXAMPLE-TEST_pkcs11.txt_mode", "path": "/etc/dirsrv/slapd-EXAMPLE-TEST/pkcs11.txt", "type": "mode", "expected": "0640", "got": "0666", "msg": "Permissions of /etc/dirsrv/slapd-EXAMPLE-TEST/pkcs11.txt are 0666 and should be 0640" } }
Appendix A. Revision History Revision History Revision 1.0-27 Mon Oct 30 2017 Lenka Spackova Added information on changes in the ld linker behavior to Deprecated Functionality. Revision 1.0-26 Mon Aug 01 2016 Lenka Spackova Added a note about limited support for Windows guest virtual machines to Deprecated Functionality. Revision 1.0-25 Fri Jun 03 2016 Lenka Spackova Added an OpenSSL known issue, which is valid for all Red Hat Enterprise Linux 7 minor releases. Revision 1.0-24 Thu May 26 2016 Lenka Spackova Fixed the "Intel Broadwell Processor and Graphics Support" note in the Hardware Enablement chapter. Revision 1.0-22 Wed Apr 20 2016 Jiri Herrmann Added a deprecated Virtualization feature. Revision 1.0-21 Wed Oct 14 2015 Lenka Spackova Fix in the Architectures chapter. Revision 1.0-20 Mon May 04 2015 Radek Biba Update of the Red Hat Enterprise Linux 7.1 Release Notes. Revision 1.0-13 Tue Mar 03 2015 Milan Navratil Release of the Red Hat Enterprise Linux 7.1 Release Notes.

Commands:
10.2. Cloning a CA Configure the master CA, and back up the keys. In the CS.cfg file for the master CA, enable the master CA to monitor replication database changes by adding the ca.listenToCloneModifications parameter: Create the clone subsystem instance. For examples of the configuration file required by pkispawn when cloning CA subsystems, see the Installing a CA clone and Installing a CA clone on the same host sections of the pkispawn (8) man page. Restart the Directory Server instance used by the clone. Note Restarting the Directory Server reloads the updated schema, which is required for proper performance. Restart the clone instance. After configuring the clone, test to make sure that the master-clone relationship is functioning: Request a certificate from the cloned CA. Approve the request. Download the certificate to the browser. Revoke the certificate. Check master CA's CRL for the revoked certificate. In the master Certificate Manager's agent services page, click Update Certificate Revocation List . Find the CRL in the list. The CRL should show the certificate revoked by the cloned Certificate Manager. If that certificate is not listed, check logs to resolve the problem.

Commands:
ca.listenToCloneModifications=true
systemctl restart pki-tomcatd@kra-clone-ds-instance.service
pki-server restart instance_name
3.3.3. Option: CPU Topology Use this option to apply a particular CPU topology (Sockets, Cores, Threads) to the virtual CPUs for your guest virtual machine. Refer to the following diagram which shows an example of this option: Figure 3.6. CPU Topology Options Note Although your environment may dictate other requirements, selecting any desired number of sockets, but with only a single core and a single thread usually gives the best performance results.

Commands:
8.5. Snapshot Previews To select which snapshot a virtual disk will be reverted to, the administrator can preview all previously created snapshots. From the available snapshots per guest, the administrator can select a snapshot volume to preview its contents. As depicted in Preview Snapshot , each snapshot is saved as a COW volume, and when it is previewed, a new preview layer is copied from the snapshot being previewed. The guest interacts with the preview instead of the actual snapshot volume. After the administrator previews the selected snapshot, the preview can be committed to restore the guest data to the state captured in the snapshot. If the administrator commits the preview, the guest is attached to the preview layer. After a snapshot is previewed, the administrator can select Undo to discard the preview layer of the viewed snapshot. The layer that contains the snapshot itself is preserved despite the preview layer being discarded. Figure 8.3. Preview Snapshot

Commands:
5.227. PackageKit 5.227.1. RHBA-2012:0913 - PackageKit bug fix update Updated PackageKit packages that fix four bugs are now available for Red Hat Enterprise Linux 6. PackageKit is a D-Bus abstraction layer that allows the session user to manage packages in a secure way using a cross-distribution, cross-architecture API. Bug Fixes BZ# 744359 If a user attempted to install or update packages that were either unsigned, or signed with a GPG key that was not installed and not available for installation, PackageKit kept reporting that the packages are from an untrusted source and repeatedly prompted the user for confirmation. This update corrects this behavior and ensures that up-to-date interfaces are used to specify that untrusted packages are to be installed. BZ# 783537 If the pkcon console client is executed with the "--noninteractive" command line option, it is not supposed to prompt the user for any confirmation. Previously, running pkcon with this option did not prevent it from requiring confirmation in certain situations, such as if a package signing key had to be imported or additional dependent packages needed to be removed during package removal. With this update, the pkcon utility no longer requires confirmation in these situations and proceeds as if the user answered "yes" on the command line. BZ# 684861 , BZ# 700448 Prior to this update, the PackageKit-yum and PackageKit-yum-plugin subpackages did not specify pygobject2 and dbus-python as their dependencies. Consequently, if these packages were not present on the system, certain tools such as the pkcon console client or the refresh-packagekit plug-in for YUM did not work properly. This update adapts the PackageKit-yum and PackageKit-yum-plugin subpackages to require pygobject2 and dbus-python respectively. As a result, the tools that are installed with either of these subpackages no longer fail to work properly due to missing dependencies. All users of PackageKit are advised to upgrade to these updated packages, which fix these bugs.

Commands: