mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 140. KafkaMirrorMaker2ClusterSpec schema reference Used in: KafkaMirrorMaker2Spec Full list of KafkaMirrorMaker2ClusterSpec schema properties Configures Kafka clusters for mirroring. 140.1. config Use the config properties to configure Kafka options. Standard Apache Kafka configuration may be provided, restricted to those properties not managed directly by Streams for Apache Kafka. For client connection using a specific cipher suite for a TLS version, you can configure allowed ssl properties . You can also configure the ssl.endpoint.identification.algorithm property to enable or disable hostname verification. 140.2. KafkaMirrorMaker2ClusterSpec schema properties Property Property type Description alias string Alias used to reference the Kafka cluster. bootstrapServers string A comma-separated list of host:port pairs for establishing the connection to the Kafka cluster. tls ClientTls TLS configuration for connecting MirrorMaker 2 connectors to a cluster. authentication KafkaClientAuthenticationTls , KafkaClientAuthenticationScramSha256 , KafkaClientAuthenticationScramSha512 , KafkaClientAuthenticationPlain , KafkaClientAuthenticationOAuth Authentication configuration for connecting to the cluster. config map The MirrorMaker 2 cluster config. Properties with the following prefixes cannot be set: ssl., sasl., security., listeners, plugin.path, rest., bootstrap.servers, consumer.interceptor.classes, producer.interceptor.classes (with the exception of: ssl.endpoint.identification.algorithm, ssl.cipher.suites, ssl.protocol, ssl.enabled.protocols).

Commands:
Appendix F. Purging storage clusters deployed by Ansible If you no longer want to use a Ceph storage cluster, then use the purge-docker-cluster.yml playbook to remove the cluster. Purging a storage cluster is also useful when the installation process failed and you want to start over. Warning After purging a Ceph storage cluster, all data on the OSDs is permanently lost. Prerequisites Root-level access to the Ansible administration node. Access to the ansible user account. For bare-metal deployments: If the osd_auto_discovery option in the /usr/share/ceph-ansible/group-vars/osds.yml file is set to true , then Ansible will fail to purge the storage cluster. Therefore, comment out osd_auto_discovery and declare the OSD devices in the osds.yml file. Ensure that the /var/log/ansible/ansible.log file is writable by the ansible user account. Procedure Navigate to the /usr/share/ceph-ansible/ directory: As the ansible user, run the purge playbook. For bare-metal deployments, use the purge-cluster.yml playbook to purge the Ceph storage cluster: For container deployments: Use the purge-docker-cluster.yml playbook to purge the Ceph storage cluster: Note This playbook removes all packages, containers, configuration files, and all the data created by the Ceph Ansible playbook. To specify a different inventory file other than the default ( /etc/ansible/hosts ), use -i parameter: Syntax Replace INVENTORY_FILE with the path to the inventory file. Example To skip the removal of the Ceph container image, use the --skip-tags="remove_img" option: To skip the removal of the packages that were installed during the installation, use the --skip-tags="with_pkg" option: Additional Resources See the OSD Ansible settings for more details.

Commands:
cd /usr/share/ceph-ansible
[ansible@admin ceph-ansible]USD ansible-playbook infrastructure-playbooks/purge-cluster.yml
[ansible@admin ceph-ansible]USD ansible-playbook infrastructure-playbooks/purge-docker-cluster.yml
[ansible@admin ceph-ansible]USD ansible-playbook infrastructure-playbooks/purge-docker-cluster.yml -i INVENTORY_FILE
[ansible@admin ceph-ansible]USD ansible-playbook infrastructure-playbooks/purge-docker-cluster.yml -i ~/ansible/hosts
[ansible@admin ceph-ansible]USD ansible-playbook --skip-tags="remove_img" infrastructure-playbooks/purge-docker-cluster.yml
[ansible@admin ceph-ansible]USD ansible-playbook --skip-tags="with_pkg" infrastructure-playbooks/purge-docker-cluster.yml
Chapter 3. Removed functionality This section lists functionality that has been removed in Red Hat Satellite 6.16. 3.1. Security and authentication OVAL-only contents and policies Management of the Open Vulnerability and Assessment Language (OVAL) contents and policies, which were provided as Technology Previews, are no longer available. If you used an OVAL policy on your clients, you must reconfigure them. Jira:SAT-23806 3.2. Content management Entitlement-based subscription management Entitlement-based subscription management has been removed. You must use Simple Content Access, which simplifies the entitlement experience for administrators. For more information, see the Subscription Management Administration Guide for Red Hat Enterprise Linux on the Red Hat Customer Portal. Jira:SAT-27936 [1] 3.3. Host provisioning and management Telemetry disablement in Convert2RHEL job templates You cannot disable telemetry when you use the Convert2RHEL utility. Jira:SAT-24654 [1] foreman_hooks plugin The foreman_hooks plugin has been removed. You must use the foreman_webhooks plugin instead. Jira:SAT-16036 [1] 3.4. Backup and restore Snapshot backup satellite-maintain no longer supports snapshot backups. You must use online backups instead. Jira:SAT-20955 [1] 3.5. Hammer CLI tool Removed Hammer commands and options The following Hammer command has been removed: hammer simple-content-access The following Hammer options have been removed: --simple-content-access removed from the hammer organization create command --simple-content-access removed from the hammer organization update command --source-url removed from the hammer repository synchronize command Jira:SAT-28141 [1] 3.6. REST API Removed API endpoints and routes The following API endpoints have been removed: /katello/api/organizations/:organization_id/simple_content_access/eligible /katello/api/organizations/:organization_id/simple_content_access/enable /katello/api/organizations/:organization_id/simple_content_access/disable /katello/api/organizations/:organization_id/simple_content_access/status /api/compliance/oval_contents /api/compliance/oval_contents/:id /api/compliance/oval_contents/sync /api/compliance/oval_policies /api/compliance/oval_policies/:id /api/compliance/oval_policies/:id/assign_hostgroups /api/compliance/oval_policies/:id/assign_hosts /api/compliance/oval_policies/:id/oval_content /api/compliance/oval_reports/:cname/:oval_policy_id/:date Jira:SAT-28135 [1]

Commands:
9.5. Security for Generated REST Services By default all the generated Rest based services are secured using "HTTPBasic" with security domain "teiid-security" and with security role "rest". However, these properties can be customized by defining the then in vdb.xml file. Example 9.1. Example vdb.xml file security specification security-type - defines the security type. allowed values are "HttpBasic" or "none". If omitted will default to "HttpBasic" security-domain - defines JAAS security domain to be used with HttpBasic. If omitted will default to "teiid-security" security-role - security role that HttpBasic will use to authorize the users. If omitted the value will default to "rest" passthough-auth - when defined the pass-through-authentication is used to login in to JBoss Data Virtualization. When this is set to "true", make sure that the "embedded" transport configuration in standalone.xml has defined a security-domain that can be authenticated against. Failure to add the configuration change will result in authentication error. Defaults to false. Important it is our intention to provide other types of security based on ws-security in future releases.

Commands:
<vdb name="sample" version="1"> <property name="UseConnectorMetadata" value="true" /> <property name="{http://teiid.org/rest}auto-generate" value="true"/> <property name="{http://teiid.org/rest}security-type" value="HttpBasic"/> <property name="{http://teiid.org/rest}security-domain" value="teiid-security"/> <property name="{http://teiid.org/rest}security-role" value="example-role"/> <property name="{http://teiid.org/rest}passthrough-auth" value="true"/> </vdb>
Chapter 5. Changed features Changed features are not deprecated and will continue to be supported until further notice. The following table provides information about features that are changed in Ansible Automation Platform 2.5: Component Feature Automation hub Error codes are now changed from 403 to 401. Any API client usage relying on specific status code 403 versus 401 will have to update their logic. Standard UI usage will work as expected. Event-Driven Ansible The endpoints /extra_vars are now moved to a property within /activations . Event-Driven Ansible The endpoint /credentials was replaced with /eda-credentials . This is part of an expanded credentials capability for Event-Driven Ansible. For more information, see the chapter Setting up credentials for Event-Driven Ansible controller in the Event-Driven Ansible controller user guide . Event-Driven Ansible Event-Driven Ansible can no longer add, edit, or delete the platform gateway-managed resources. Creating, editing, or deleting organizations, teams, or users is available through platform gateway endpoints only. The platform gateway endpoints also enable you to edit organization or team memberships and configure external authentication. API Auditing of users has now changed. Users are now audited through the platform API, not through the controller API. This change applies to the Ansible Automation Platform in both cloud service and on-premise deployments. Automation controller, automation hub, platform gateway, and Event-Driven Ansible User permission audits the sources of truth for the platform gateway. When an IdP (SSO) is used, then the IdP should be the source of truth for user permission audits. When the Ansible Automation Platform platform gateway is used without SSO, then the platform gateway should be the source of truth for user permissions, not the app-specific UIs or APIs.

Commands:
Chapter 3. Installing web console add-ons and creating custom pages Depending on how you want to use your Red Hat Enterprise Linux system, you can add additional available applications to the web console or create custom pages based on your use case. 3.1. Add-ons for the RHEL web console While the cockpit package is a part of Red Hat Enterprise Linux by default, you can install add-on applications on demand by using the following command: In the command, replace <add-on> by a package name from the list of available add-on applications for the RHEL web console. Feature name Package name Usage Composer cockpit-composer Building custom OS images File manager cockpit-files Managing files and directories in the standard web-console interface Machines cockpit-machines Managing libvirt virtual machines PackageKit cockpit-packagekit Software updates and application installation (usually installed by default) PCP cockpit-pcp Persistent and more fine-grained performance data (installed on demand from the UI) Podman cockpit-podman Managing containers and managing container images Session Recording cockpit-session-recording Recording and managing user sessions Storage cockpit-storaged Managing storage through udisks 3.2. Creating new pages in the web console If you want to add customized functions to your Red Hat Enterprise Linux web console, you must add the package directory that contains the HTML and JavaScript files for the page that runs the required function. For detailed information about adding custom pages, see Creating Plugins for the Cockpit User Interface on the Cockpit Project website. Additional resources Cockpit Packages section in the Cockpit Project Developer Guide 3.3. Overriding the manifest settings in the web console You can modify the menu of the web console for a particular user and all users of the system. In the cockpit project, a package name is a directory name. A package contains the manifest.json file along with other files. Default settings are present in the manifest.json file. You can override the default cockpit menu settings by creating a <package-name> .override.json file at a specific location for the specified user. Prerequisites You have installed the RHEL 9 web console. For instructions, see Installing and enabling the web console . Procedure Override manifest settings in the <systemd> .override.json file in a text editor of your choice, for example: To edit for all users, enter: To edit for a single user, enter: Edit the required file with the following details: { "menu": { "services": null, "logs": { "order": -1 } } } The null value hides the services tab The -1 value moves the logs tab to the first place. Restart the cockpit service: Additional resources cockpit(1) man page on your system Manifest overrides

Commands:
dnf install <add-on>
vi /etc/cockpit/ <systemd> .override.json
vi ~/.config/cockpit/ <systemd> .override.json
{ "menu": { "services": null, "logs": { "order": -1 } } }
systemctl restart cockpit.service
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:44 UTC

Commands:
dnf install <package_name>
dnf install <path_to_download_package>
Preface The Red Hat Virtualization Manager includes a data warehouse that collects monitoring data about hosts, virtual machines, and storage. Data Warehouse, which includes a database and a service, must be installed and configured along with the Manager setup, either on the same machine or on a separate server. The Red Hat Virtualization installation creates two databases: The Manager database ( engine ) is the primary data store used by the Red Hat Virtualization Manager. Information about the virtualization environment like its state, configuration, and performance are stored in this database. The Data Warehouse database ( ovirt_engine_history ) contains configuration information and statistical data which is collated over time from the Manager database. The configuration data in the Manager database is examined every minute, and changes are replicated to the Data Warehouse database. Tracking the changes to the database provides information on the objects in the database. This enables you to analyze and enhance the performance of your Red Hat Virtualization environment and resolve difficulties. To calculate an estimate of the space and resources the ovirt_engine_history database will use, use the RHV Manager History Database Size Calculator tool. The estimate is based on the number of entities and the length of time you have chosen to retain the history records.

Commands:
Chapter 16. Using TLS certificates for applications accessing RGW Most of the S3 applications require TLS certificate in the forms such as an option included in the Deployment configuration file, passed as a file in the request, or stored in /etc/pki paths. TLS certificates for RADOS Object Gateway (RGW) are stored as Kubernetes secret and you need to fetch the details from the secret. Prerequisites A running OpenShift Data Foundation cluster. Procedure For internal RGW server Get the TLS certificate and key from the kubernetes secret: <secret_name> The default kubernetes secret name is <objectstore_name>-cos-ceph-rgw-tls-cert . Specify the name of the object store. For external RGW server Get the the TLS certificate from the kubernetes secret: <secret_name> The default kubernetes secret name is ceph-rgw-tls-cert and it is an opaque type of secret. The key value for storing the TLS certificates is cert . 16.1. Accessing External RGW server in OpenShift Data Foundation Accessing External RGW server using Object Bucket Claims The S3 credentials such as AccessKey or Secret Key is stored in the secret generated by the Object Bucket Claim (OBC) creation and you can fetch the same by using the following commands: Similarly, you can fetch the endpoint details from the configmap of OBC: Accessing External RGW server using the Ceph Object Store User CR You can fetch the S3 Credentials and endpoint details from the secret generated as part of the Ceph Object Store User CR: Important For both the access mechanisms, you can either request for new certificates from the administrator or reuse the certificates from the Kubernetes secret, ceph-rgw-tls-cert .

Commands:
oc get secrets/<secret_name> -o jsonpath='{.data..tls\.crt}' | base64 -d oc get secrets/<secret_name> -o jsonpath='{.data..tls\.key}' | base64 -d
oc get secrets/<secret_name> -o jsonpath='{.data.cert}' | base64 -d
oc get secret <object bucket claim name> -o jsonpath='{.data.AWS_SECRET_ACCESS_KEY}' | base64 --decode oc get secret <object bucket claim name> -o jsonpath='{.data.AWS_ACCESS_KEY_ID}' | base64 --decode
oc get cm <object bucket claim name> -o jsonpath='{.data.BUCKET_HOST}' oc get cm <object bucket claim name> -o jsonpath='{.data.BUCKET_PORT}' oc get cm <object bucket claim name> -o jsonpath='{.data.BUCKET_NAME}'
oc get secret rook-ceph-object-user-<object-store-cr-name>-<object-user-cr-name> -o jsonpath='{.data.AccessKey}' | base64 --decode oc get secret rook-ceph-object-user-<object-store-cr-name>-<object-user-cr-name> -o jsonpath='{.data.SecretKey}' | base64 --decode oc get secret rook-ceph-object-user-<object-store-cr-name>-<object-user-cr-name> -o jsonpath='{.data.Endpoint}' | base64 --decode
API overview OpenShift Container Platform 4.15 Overview content for the OpenShift Container Platform API Red Hat OpenShift Documentation Team

Commands:
oc debug node/<node>
chroot /host
systemctl cat kubelet
/etc/systemd/system/kubelet.service.d/20-logging.conf [Service] Environment="KUBELET_LOG_LEVEL=2"
echo -e "[Service]\nEnvironment=\"KUBELET_LOG_LEVEL=8\"" > /etc/systemd/system/kubelet.service.d/30-logging.conf
systemctl daemon-reload
systemctl restart kubelet
rm -f /etc/systemd/system/kubelet.service.d/30-logging.conf
systemctl daemon-reload
systemctl restart kubelet
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: master name: 99-master-kubelet-loglevel spec: config: ignition: version: 3.2.0 systemd: units: - name: kubelet.service enabled: true dropins: - name: 30-logging.conf contents: | [Service] Environment="KUBELET_LOG_LEVEL=2"
oc adm node-logs --role master -u kubelet
oc adm node-logs --role worker -u kubelet
journalctl -b -f -u kubelet.service
sudo tail -f /var/log/containers/*
- for n in USD(oc get node --no-headers | awk '{print USD1}'); do oc adm node-logs USDn | gzip > USDn.log.gz; done
4.7. Activating Logical Volumes on Individual Nodes in a Cluster If you have LVM installed in a cluster environment, you may at times need to activate logical volumes exclusively on one node. To activate logical volumes exclusively on one node, use the lvchange -aey command. Alternatively, you can use lvchange -aly command to activate logical volumes only on the local node but not exclusively. You can later activate them on additional nodes concurrently. You can also activate logical volumes on individual nodes by using LVM tags, which are described in Appendix D, LVM Object Tags . You can also specify activation of nodes in the configuration file, which is described in Appendix B, The LVM Configuration Files .

Commands:
5.323. system-config-language 5.323.1. RHBA-2012:1213 - system-config-language bug fix update An updated system-config-language package that fixes one bug is now available for Red Hat Enterprise Linux 6. The system-config-language is a graphical user interface that allows the user to change the default language of the system. Bug Fix BZ# 819811 When using system-config-language in a non-English locale, some of the messages in the GUI were not translated. Consequently, non-English users were presented with untranslated messages. With this update, all message strings have been translated. All users of system-config-language are advised to upgrade to this updated package, which fixes this bug.

Commands:
Chapter 8. Asynchronous errata updates 8.1. RHBA-2024:6399 OpenShift Data Foundation 4.13.11 bug fixes and security updates OpenShift Data Foundation release 4.13.11 is now available. The bug fixes that are included in the update are listed in the RHBA-2024:6399 advisory. 8.2. RHBA-2024:4358 OpenShift Data Foundation 4.13.10 bug fixes and security updates OpenShift Data Foundation release 4.13.10 is now available. The bug fixes that are included in the update are listed in the RHBA-2024:4358 advisory. 8.3. RHBA-2024:3865 OpenShift Data Foundation 4.13.9 bug fixes and security updates OpenShift Data Foundation release 4.13.9 is now available. The bug fixes that are included in the update are listed in the RHBA-2024:3865 advisory. 8.4. RHBA-2024:1657 OpenShift Data Foundation 4.13.8 bug fixes and security updates OpenShift Data Foundation release 4.13.8 is now available. The bug fixes that are included in the update are listed in the RHBA-2024:1657 advisory. 8.5. RHBA-2024:0540 OpenShift Data Foundation 4.13.7 bug fixes and security updates OpenShift Data Foundation release 4.13.7 is now available. The bug fixes that are included in the update are listed in the RHBA-2024:0540 advisory. 8.6. RHBA-2023:7870 OpenShift Data Foundation 4.13.6 bug fixes and security updates OpenShift Data Foundation release 4.13.6 is now available. The bug fixes that are included in the update are listed in the RHBA-2023:7870 advisory. 8.7. RHBA-2023:7775 OpenShift Data Foundation 4.13.5 bug fixes and security updates OpenShift Data Foundation release 4.13.5 is now available. The bug fixes that are included in the update are listed in the RHBA-2023:7775 advisory. 8.8. RHBA-2023:6146 OpenShift Data Foundation 4.13.4 bug fixes and security updates OpenShift Data Foundation release 4.13.4 is now available. The bug fixes that are included in the update are listed in the RHBA-2023:6146 advisory. 8.9. RHSA-2023:5376 OpenShift Data Foundation 4.13.3 bug fixes and security updates OpenShift Data Foundation release 4.13.3 is now available. The bug fixes that are included in the update are listed in the RHSA-2023:5376 advisory. 8.10. RHBA-2023:4716 OpenShift Data Foundation 4.13.2 bug fixes and security updates OpenShift Data Foundation release 4.13.2 is now available. The bug fixes that are included in the update are listed in the RHBA-2023:4716 advisory. 8.11. RHSA-2023:4437 OpenShift Data Foundation 4.13.1 bug fixes and security updates OpenShift Data Foundation release 4.13.1 is now available. The bug fixes that are included in the update are listed in the RHSA-2023:4437 advisory.

Commands:
Chapter 23. Optimizing the JBoss EAP server configuration Once you have installed the JBoss EAP server , and you have created a management user , Red Hat recommends that you optimize your server configuration. Make sure you review information in the Performance tuning for JBoss EAP guide for information about how to optimize the server configuration to avoid common problems when deploying applications in a production environment. Common optimizations include setting ulimits , enabling garbage collection , creating Java heap dumps , and adjusting the thread pool size . It is also a good idea to keep your instance of JBoss EAP up to date with the latest bug fixes. For more information, see Updating Red Hat JBoss Enterprise Application Platform .

Commands: