mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 145. KafkaRebalanceSpec schema reference Used in: KafkaRebalance Property Property type Description mode string (one of [remove-brokers, full, add-brokers]) Mode to run the rebalancing. The supported modes are full , add-brokers , remove-brokers . If not specified, the full mode is used by default. full mode runs the rebalancing across all the brokers in the cluster. add-brokers mode can be used after scaling up the cluster to move some replicas to the newly added brokers. remove-brokers mode can be used before scaling down the cluster to move replicas out of the brokers to be removed. brokers integer array The list of newly added brokers in case of scaling up or the ones to be removed in case of scaling down to use for rebalancing. This list can be used only with rebalancing mode add-brokers and removed-brokers . It is ignored with full mode. goals string array A list of goals, ordered by decreasing priority, to use for generating and executing the rebalance proposal. The supported goals are available at https://github.com/linkedin/cruise-control#goals . If an empty goals list is provided, the goals declared in the default.goals Cruise Control configuration parameter are used. skipHardGoalCheck boolean Whether to allow the hard goals specified in the Kafka CR to be skipped in optimization proposal generation. This can be useful when some of those hard goals are preventing a balance solution being found. Default is false. rebalanceDisk boolean Enables intra-broker disk balancing, which balances disk space utilization between disks on the same broker. Only applies to Kafka deployments that use JBOD storage with multiple disks. When enabled, inter-broker balancing is disabled. Default is false. excludedTopics string A regular expression where any matching topics will be excluded from the calculation of optimization proposals. This expression will be parsed by the java.util.regex.Pattern class; for more information on the supported format consult the documentation for that class. concurrentPartitionMovementsPerBroker integer The upper bound of ongoing partition replica movements going into/out of each broker. Default is 5. concurrentIntraBrokerPartitionMovements integer The upper bound of ongoing partition replica movements between disks within each broker. Default is 2. concurrentLeaderMovements integer The upper bound of ongoing partition leadership movements. Default is 1000. replicationThrottle integer The upper bound, in bytes per second, on the bandwidth used to move replicas. There is no limit by default. replicaMovementStrategies string array A list of strategy class names used to determine the execution order for the replica movements in the generated optimization proposal. By default BaseReplicaMovementStrategy is used, which will execute the replica movements in the order that they were generated.

Commands:
Preface Open Java Development Kit (OpenJDK) is a free and open source implementation of the Java Platform, Standard Edition (Java SE). The Red Hat build of OpenJDK is available in four versions: 8u, 11u, 17u, and 21u. Packages for the Red Hat build of OpenJDK are made available on Red Hat Enterprise Linux and Microsoft Windows and shipped as a JDK and JRE in the Red Hat Ecosystem Catalog.

Commands:
3.5. Configure the Gluster Storage Cluster Configure these instances to form a trusted storage pool (cluster). Note If you are using Red Hat Enterprise Linux 7 machines, log in to the Azure portal and reset the password for the VMs and also restart the VMs. On Red Hat Enterprise Linux 6 machines, password reset is not required. Log into each node using the keys or with password. For example, Register each node to Red Hat Network using the subscription-manager command, and attach the relevant Red Hat Storage subscriptions. For information on subscribing to the Red Hat Gluster Storage 3.5 channels, see the Installing Red Hat Gluster Storage chapter in the Red Hat Gluster Storage 3.5 Installation Guide . Update each node to ensure the latest enhancements and patches are in place. Follow the instructions in the Adding Servers to the Trusted Storage Pool chapter in the Red Hat Gluster Storage Administration Guide to create the trusted storage pool.

Commands:
ssh -i [path-to-key-pem] [admin-name@public-ip-address] or ssh [admin-name@public-ip-address]
ssh -i /root/.azure/ssh/rhgs72-key.pem clouduser@rhgs72.east.cloudapp.azure.com or ssh clouduser@rhgs72.east.cloudapp.azure.com
yum update
Chapter 1. Uninstalling Red Hat OpenShift GitOps Uninstalling the Red Hat OpenShift GitOps Operator is a two-step process: Delete the Argo CD instances that were added under the default namespace of the Red Hat OpenShift GitOps Operator. Uninstall the Red Hat OpenShift GitOps Operator. Uninstalling only the Operator will not remove the Argo CD instances created. 1.1. Deleting the Argo CD instances Delete the Argo CD instances added to the namespace of the GitOps Operator. Procedure In the Terminal type the following command: USD oc delete gitopsservice cluster -n openshift-gitops Note You cannot delete an Argo CD cluster from the web console UI. After the command runs successfully all the Argo CD instances will be deleted from the openshift-gitops namespace. Delete any other Argo CD instances from other namespaces using the same command: USD oc delete gitopsservice cluster -n <namespace> 1.2. Uninstalling the GitOps Operator You can uninstall Red Hat OpenShift GitOps Operator from the OperatorHub by using the web console. Procedure From the Operators OperatorHub page, use the Filter by keyword box to search for Red Hat OpenShift GitOps Operator tile. Click the Red Hat OpenShift GitOps Operator tile. The Operator tile indicates it is installed. In the Red Hat OpenShift GitOps Operator descriptor page, click Uninstall . Additional resources You can learn more about uninstalling Operators on OpenShift Container Platform in the Deleting Operators from a cluster section.

Commands:
oc delete gitopsservice cluster -n openshift-gitops
oc delete gitopsservice cluster -n <namespace>
5.3.13. Backing Up Volume Group Metadata Metadata backups and archives are automatically created on every volume group and logical volume configuration change unless disabled in the lvm.conf file. By default, the metadata backup is stored in the /etc/lvm/backup file and the metadata archives are stored in the /etc/lvm/archives file. You can manually back up the metadata to the /etc/lvm/backup file with the vgcfgbackup command. The vgcfrestore command restores the metadata of a volume group from the archive to all the physical volumes in the volume groups. For an example of using the vgcfgrestore command to recover physical volume metadata, see Section 7.4, "Recovering Physical Volume Metadata" .

Commands:
3.2.3.2.2. Is Symmetric Multiprocessing Right for You? Symmetric multiprocessing (also known as SMP) makes it possible for a computer system to have more than one CPU sharing all system resources. This means that, unlike a uniprocessor system, an SMP system may actually have more than one process running at the same time. At first glance, this seems like any system administrator's dream. First and foremost, SMP makes it possible to increase a system's CPU power even if CPUs with faster clock speeds are not available -- just by adding another CPU. However, this flexibility comes with some caveats. The first caveat is that not all systems are capable of SMP operation. Your system must have a motherboard designed to support multiple processors. If it does not, a motherboard upgrade (at the least) would be required. The second caveat is that SMP increases system overhead. This makes sense if you stop to think about it; with more CPUs to schedule work for, the operating system requires more CPU cycles for overhead. Another aspect to this is that with multiple CPUs, there can be more contention for system resources. Because of these factors, upgrading a dual-processor system to a quad-processor unit does not result in a 100% increase in available CPU power. In fact, depending on the actual hardware, the workload, and the processor architecture, it is possible to reach a point where the addition of another processor could actually reduce system performance. Another point to keep in mind is that SMP does not help workloads consisting of one monolithic application with a single stream of execution. In other words, if a large compute-bound simulation program runs as one process and without threads, it will not run any faster on an SMP system than on a single-processor machine. In fact, it may even run somewhat slower, due to the increased overhead SMP brings. For these reasons, many system administrators feel that when it comes to CPU power, single stream processing power is the way to go. It provides the most CPU power with the fewest restrictions on its use. While this discussion seems to indicate that SMP is never a good idea, there are circumstances in which it makes sense. For example, environments running multiple highly compute-bound applications are good candidates for SMP. The reason for this is that applications that do nothing but compute for long periods of time keep contention between active processes (and therefore, the operating system overhead) to a minimum, while the processes themselves keep every CPU busy. One other thing to keep in mind about SMP is that the performance of an SMP system tends to degrade more gracefully as the system load increases. This does make SMP systems popular in server and multi-user environments, as the ever-changing process mix can impact the system-wide load less on a multi-processor machine.

Commands:
Chapter 2. Using the Software Development Kit This chapter defines the modules and classes of the Ruby Software Development Kit and describes their usage. 2.1. Classes The OvirtSDK4 module contains the following software development kit classes: Connection The Connection class is the mechanism for connecting to the server and obtaining the reference to the root of the services tree. See Section 3.1, "Connecting to the Red Hat Virtualization Manager" for details. Types The Type classes implement the types supported by the API. For example, the Vm class is the implementation of the virtual machine type. The classes are data containers and do not contain any logic. You will be working with instances of types. Instances of these classes are used as parameters and return values of service methods. The conversion to or from the underlying representation is handled transparently by the software development kit. Services The Service classes implement the services supported by the API. For example, the VmsService class is the implementation of the service that manages the collection of virtual machines in the system. Instances of these classes are automatically created by the SDK when a service is referenced. For example, a new instance of the VmsService class is created automatically by the SDK when you call the vms_service method of the SystemService class: vms_service = connection.system_service.vms_service Warning Do not create instances of these classes manually. The constructor parameters and methods may change in the future. Error The Error class is the base exception class that the software development kit raises when it reports an error. Certain specific error classes extend the base error class: AuthError - Authentication or authorization failure ConnectionError - Server name cannot be resolved or server is unreachable NotFoundError - Requested object does not exist TimeoutError - Operation time-out Other Classes Other classes (for example, HTTP client classes, readers, and writers) are used for HTTP communication and for XML parsing and rendering. Using these classes is not recommended, because they comprise internal implementation details that may change in the future. Their backwards-compatibility cannot be relied upon.

Commands:
vms_service = connection.system_service.vms_service
Chapter 4. Updating Capsule Server Update Capsule Servers to the minor version. Procedure Synchronize the satellite-capsule-6.15-for-rhel-8-x86_64-rpms repository in the Satellite Server. Publish and promote a new version of the content view with which the Capsule is registered. Ensure that the Satellite Maintenance repository is enabled: Check the available versions to confirm the minor version is listed: Use the health check option to determine if the system is ready for upgrade: Review the results and address any highlighted error conditions before performing the upgrade. Because of the lengthy update time, use a utility such as tmux to suspend and reattach a communication session. You can then check the upgrade progress without staying connected to the command shell continuously. If you lose connection to the command shell where the upgrade command is running, you can see the logged messages in the /var/log/foreman-installer/capsule.log file to check if the process completed successfully. Perform the update: Determine if the system needs a reboot: If the command told you to reboot, then reboot the system:

Commands:
subscription-manager repos --enable satellite-maintenance-6.15-for-rhel-8-x86_64-rpms
satellite-maintain upgrade list-versions
satellite-maintain upgrade check --target-version 6.15.z
satellite-maintain upgrade run --target-version 6.15.z
dnf needs-restarting --reboothint
reboot
Chapter 8. steps The following sections might be useful after deploying a proof of concept version of Red Hat Quay. Many of these procedures can be used on a proof of concept deployment, offering insights to Red Hat Quay's features. Using Red Hat Quay . The content in this guide explains the following concepts: Adding users and repositories Using image tags Building Dockerfiles with build workers Setting up build triggers Adding notifications for repository events and more Managing Red Hat Quay . The content in this guide explains the following concepts: Using SSL/TLS Configuring action log storage Configuring Clair security scanner Repository mirroring IPv6 and dual-stack deployments Configuring OIDC for Red Hat Quay Geo-replication and more

Commands:
Chapter 1. About Red Hat OpenShift GitOps Red Hat OpenShift GitOps is an Operator that uses Argo CD as the declarative GitOps engine. It enables GitOps workflows across multicluster OpenShift and Kubernetes infrastructure. Using Red Hat OpenShift GitOps, administrators can consistently configure and deploy Kubernetes-based infrastructure and applications across clusters and development lifecycles. Red Hat OpenShift GitOps is based on the open source project Argo CD and provides a similar set of features to what the upstream offers, with additional automation, integration into Red Hat {OCP} and the benefits of Red Hat's enterprise support, quality assurance and focus on enterprise security. Note Because Red Hat OpenShift GitOps releases on a different cadence from OpenShift Container Platform, the Red Hat OpenShift GitOps documentation is now available as a separate documentation set at Red Hat OpenShift GitOps .

Commands:
Preface Red Hat OpenShift Data Foundation supports deployment on existing Red Hat OpenShift Service on AWS with hosted control planes. Note Only internal OpenShift Data Foundation clusters are supported on AWS. See Planning your deployment and Preparing to deploy OpenShift Data Foundation for more information about deployment requirements. To deploy OpenShift Data Foundation, start with the requirements in Preparing to deploy OpenShift Data Foundation chapter and then follow the deployment process in Deploying using dynamic storage devices .

Commands:
13.2. Adding and Removing User or Host Groups To add a group, you can use: The web UI (see the section called "Web UI: Adding a User or Host Group" ) The command line (see the section called "Command Line: Adding a User or Host Group" ) IdM enables specifying a custom GID when creating a user group. If you do this, be careful to avoid ID conflicts. See Section 14.6, "Ensuring That ID Values Are Unique" . If you do not specify a custom GID, IdM automatically assigns a GID from the available ID range. To remove a group, you can use: The web UI (see the section called "Web UI: Removing a User or Host Group" ) The command line (see the section called "Command Line: Removing a User or Host Group" ) Note that removing a group does not delete the group members from IdM. Web UI: Adding a User or Host Group Click Identity Groups , and select User Groups or Host Groups in the left sidebar. Click Add to start adding the group. Fill out the information about the group. For details on user group types, see Section 13.1.4, "User Group Types in IdM" . Click Add to confirm. Command Line: Adding a User or Host Group Log in as the administrator: To add a user group, use the ipa group-add command. To add a host group, use the ipa hostgroup-add command. By default, ipa group-add adds a POSIX user group. To specify a different group type, add options to ipa group-add : --nonposix to create a non-POSIX group --external to create an external group For details on group types, see Section 13.1.4, "User Group Types in IdM" . Web UI: Removing a User or Host Group Click Identity Groups and select User Groups or Host Groups in the left sidebar. Select the group to remove, and click Delete . Command Line: Removing a User or Host Group Log in as the administrator: To delete a user group, use the ipa group-del group_name command. To delete a host group, use the ipa hostgroup-del group_name command.

Commands:
kinit admin
ipa group-add group_name ----------------------- Added group "group_name" ------------------------
kinit admin
ipa group-del group_name -------------------------- Deleted group "group_name" --------------------------
10.5.32. TypesConfig TypesConfig names the file which sets the default list of MIME type mappings (file name extensions to content types). The default TypesConfig file is /etc/mime.types . Instead of editing /etc/mime.types , the recommended way to add MIME type mappings is to use the AddType directive. For more information about AddType , refer to Section 10.5.55, " AddType " .

Commands:
Chapter 1. Preparing to deploy OpenShift Data Foundation Deploying OpenShift Data Foundation on OpenShift Container Platform using dynamic storage devices provides you with the option to create internal cluster resources. This will result in the internal provisioning of the base services, which helps to make additional storage classes available to applications. Before you begin the deployment of Red Hat OpenShift Data Foundation, follow these steps: Optional: If you want to enable cluster-wide encryption using an external Key Management System (KMS): Ensure that a policy with a token exists and the key value backend path in Vault is enabled. See enabled the key value backend path and policy in Vault . Ensure that you are using signed certificates on your Vault servers. Minimum starting node requirements [Technology Preview] An OpenShift Data Foundation cluster will be deployed with minimum configuration when the standard deployment resource requirement is not met. See Resource requirements section in Planning guide. Regional-DR requirements [Developer Preview] Disaster Recovery features supported by Red Hat OpenShift Data Foundation require all of the following prerequisites in order to successfully implement a Disaster Recovery solution: A valid Red Hat OpenShift Data Foundation Advanced entitlement A valid Red Hat Advanced Cluster Management for Kubernetes subscription To know how subscriptions for OpenShift Data Foundation work, see knowledgebase article on OpenShift Data Foundation subscriptions . For detailed requirements, see Regional-DR requirements and RHACM requirements . 1.1. Enabling key value backend path and policy in Vault Prerequisites Administrator access to Vault. Carefully, choose a unique path name as the backend path that follows the naming convention since it cannot be changed later. Procedure Enable the Key/Value (KV) backend path in Vault. For Vault KV secret engine API, version 1: For Vault KV secret engine API, version 2: Create a policy to restrict users to perform a write or delete operation on the secret using the following commands. Create a token matching the above policy.

Commands:
vault secrets enable -path=odf kv
vault secrets enable -path=odf kv-v2
echo ' path "odf/*" { capabilities = ["create", "read", "update", "delete", "list"] } path "sys/mounts" { capabilities = ["read"] }'| vault policy write odf -
vault token create -policy=odf -format json
12.5. Samba Configuration The Samba configuration file smb.conf is located at /etc/samba/smb.conf in this example. It contains the following parameters: This example exports a share with name csmb located at /mnt/gfs2/share . This is different from the GFS2 shared filesystem at /mnt/ctdb/.ctdb.lock that we specified as the CTDB_RECOVERY_LOCK parameter in the CTDB configuration file at /etc/sysconfig/ctdb . In this example, we will create the share directory in /mnt/gfs2 when we mount it for the first time. The clustering = yes entry instructs Samba to use CTDB. The netbios name = csmb-server entry explicitly sets all the nodes to have a common NetBIOS name. The ea support parameter is required if you plan to use extended attributes. The smb.conf configuration file must be identical on all of the cluster nodes. Samba also offers registry-based configuration using the net conf command to automatically keep configuration in sync between cluster members without having to manually copy configuration files among the cluster nodes. For information on the net conf command, see the net (8) man page.

Commands:
[global] guest ok = yes clustering = yes netbios name = csmb-server [csmb] comment = Clustered Samba public = yes path = /mnt/gfs2/share writeable = yes ea support = yes
13.2.19. Domain Options: Using IP Addresses in Certificate Subject Names (LDAP Only) Using an IP address in the ldap_uri option instead of the server name may cause the TLS/SSL connection to fail. TLS/SSL certificates contain the server name, not the IP address. However, the subject alternative name field in the certificate can be used to include the IP address of the server, which allows a successful secure connection using an IP address. Procedure 13.8. Using IP Addresses in Certificate Subject Names Convert an existing certificate into a certificate request. The signing key ( -signkey ) is the key of the issuer of whatever CA originally issued the certificate. If this is done by an external CA, it requires a separate PEM file; if the certificate is self-signed, then this is the certificate itself. For example: With a self-signed certificate: Edit the /etc/pki/tls/openssl.cnf configuration file to include the server's IP address under the [ v3_ca ] section: Use the generated certificate request to generate a new self-signed certificate with the specified IP address: The -extensions option sets which extensions to use with the certificate. For this, it should be v3_ca to load the appropriate section. Copy the private key block from the old_cert.pem file into the new_cert.pem file to keep all relevant information in one file. When creating a certificate through the certutil utility provided by the nss-tools package, note that certutil supports DNS subject alternative names for certificate creation only.

Commands:
openssl x509 -x509toreq -in old_cert.pem -out req.pem -signkey key.pem
openssl x509 -x509toreq -in old_cert.pem -out req.pem -signkey old_cert.pem
subjectAltName = IP:10.0.0.10
openssl x509 -req -in req.pem -out new_cert.pem -extfile ./openssl.cnf -extensions v3_ca -signkey old_cert.pem