mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 142. KafkaRebalanceSpec schema reference Used in: KafkaRebalance Property Description mode 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. string (one of [remove-brokers, full, add-brokers]) brokers 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. integer array goals 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. string array skipHardGoalCheck 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. boolean rebalanceDisk 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. boolean excludedTopics 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. string concurrentPartitionMovementsPerBroker The upper bound of ongoing partition replica movements going into/out of each broker. Default is 5. integer concurrentIntraBrokerPartitionMovements The upper bound of ongoing partition replica movements between disks within each broker. Default is 2. integer concurrentLeaderMovements The upper bound of ongoing partition leadership movements. Default is 1000. integer replicationThrottle The upper bound, in bytes per second, on the bandwidth used to move replicas. There is no limit by default. integer replicaMovementStrategies 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. string array

Commands:
Chapter 4. Updating Red Hat build of OpenJDK 17 on Red Hat Enterprise Linux The following sections provide instructions for updating Red Hat build of OpenJDK 17 on Red Hat Enterprise Linux. 4.1. Updating Red Hat build of OpenJDK 17 on RHEL by using yum You can update the installed Red Hat build of OpenJDK packages by using the yum system package manager. Prerequisites You must have root privileges on the system. Procedure Check the current Red Hat build of OpenJDK version: A list of installed Red Hat build of OpenJDK packages displays. Update a specific package. For example: Verify that the update worked by checking the current Red Hat build of OpenJDK versions: Note You can install multiple major versions of Red Hat build of OpenJDK on your local system. If you need to switch from one major version to another major version, issue the following command in your command-line interface (CLI) and then follow the onscreen prompts: 4.2. Updating Red Hat build of OpenJDK 17 on RHEL by using an archive You can update Red Hat build of OpenJDK by using an archive file. This is useful if the Red Hat build of OpenJDK administrator does not have root privileges. Prerequisites Know the generic path pointing to your JDK or JRE installation. For example, ~/jdks/java-17 Procedure Remove the existing symbolic link of the generic path to your JDK or JRE. For example: Install the latest version of the JDK or JRE in your installation location. Additional resources For instructions on installing a JRE, see Installing a JRE on RHEL by using an archive . For instructions on installing a JDK, see Installing Red Hat build of OpenJDK on RHEL by using an archive . Revised on 2024-10-29 18:38:39 UTC

Commands:
sudo yum list installed "java*"
Installed Packages java-1.8.0-openjdk.x86_64 1:1.8.0.322.b06-2.el8_5 @rhel-8-for-x86_64-appstream-rpms java-11-openjdk.x86_64 1:11.0.14.0.9-2.el8_5 @rhel-8-for-x86_64-appstream-rpms java-17-openjdk.x86_64 1:17.0.2.0.8-4.el8_5 @rhel-8-for-x86_64-appstream-rpms
sudo yum update java-17-openjdk
java -version openjdk version "17.0.2" 2022-01-18 LTS OpenJDK Runtime Environment 21.9 (build 17.0.2+8-LTS) OpenJDK 64-Bit Server VM 21.9 (build 17.0.2+8-LTS, mixed mode, sharing)
sudo update-alternatives --config 'java'
unlink ~/jdks/java-17
Appendix A. Revision History Revision History Revision 4.6-1 Tue Jul 17 2018 Marek Suchanek Asynchronous update Revision 4.6-0 Thu Aug 10 2017 Marek Suchanek Asynchronous update Revision 4.2-0 Tue May 10 2016 Milan Navratil Preparing document for 6.8 GA publication. Revision 4.1-0 Tue May 06 2014 Laura Bailey Added section on Performance Co-Pilot. Revision 4.0-43 Wed Nov 13 2013 Laura Bailey Building for Red Hat Enterprise Linux 6.5 GA. Revision 4.0-6 Thu Oct 4 2012 Laura Bailey Added new section on numastat utility ( BZ#853274 ). Revision 1.0-0 Friday December 02 2011 Laura Bailey Release for GA of Red Hat Enterprise Linux 6.2.

Commands:
3.15. Starting a Virtual Machine This Ruby example starts a virtual machine. # Get the reference to the "vms" service: vms_service = connection.system_service.vms_service # Find the virtual machine: vm = vms_service.list(search: 'name=myvm')[0] # Locate the service that manages the virtual machine, as that is where # the action methods are defined: vm_service = vms_service.vm_service(vm.id) # Call the "start" method of the service to start it: vm_service.start # Wait until the virtual machine status is UP: loop do sleep(5) vm = vm_service.get break if vm.status == OvirtSDK4::VmStatus::UP end For more information, see http://www.rubydoc.info/gems/ovirt-engine-sdk/OvirtSDK4/VmService:start .

Commands:
Get the reference to the "vms" service: vms_service = connection.system_service.vms_service Find the virtual machine: vm = vms_service.list(search: 'name=myvm')[0] Locate the service that manages the virtual machine, as that is where the action methods are defined: vm_service = vms_service.vm_service(vm.id) Call the "start" method of the service to start it: vm_service.start Wait until the virtual machine status is UP: loop do sleep(5) vm = vm_service.get break if vm.status == OvirtSDK4::VmStatus::UP end
4.148. libtiff 4.148.1. RHSA-2012:0468 - Important: libtiff security update Updated libtiff packages that fix two security issues are now available for Red Hat Enterprise Linux 5 and 6. The Red Hat Security Response Team has rated this update as having important security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available from the CVE link(s) associated with each description below. The libtiff packages contain a library of functions for manipulating Tagged Image File Format (TIFF) files. Security Fix CVE-2012-1173 Two integer overflow flaws, leading to heap-based buffer overflows, were found in the way libtiff attempted to allocate space for a tile in a TIFF image file. An attacker could use these flaws to create a specially-crafted TIFF file that, when opened, would cause an application linked against libtiff to crash or, possibly, execute arbitrary code. All libtiff users should upgrade to these updated packages, which contain a backported patch to resolve these issues. All running applications linked against libtiff must be restarted for this update to take effect.

Commands:
2.46. RHEA-2011:1442 - new packages: tdb-tools New tdb-tools packages are now available for Red Hat Enterprise Linux 6. The tdb-tools packages contain tools that can be used to backup and manage tdb files created by Samba. This enhancement update adds the tdb-tools packages to Red Hat Enterprise Linux 6. (BZ# 717690 ) All tdb users who wish to backup and manage tdb files are advised to install these new packages.

Commands:
8.237. systemtap 8.237.1. RHBA-2014:1449 - systemtap bug fix and enhancement update Updated systemtap packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. SystemTap is a tracing and probing tool to analyze and monitor activities of the operating system, including the kernel. It provides a wide range of filtering and analysis options. This update also fixes the following bugs: Note The systemtap packages have been upgraded to upstream version 2.5-5, which provides a number of bug fixes and enhancements over the version. (BZ# 1038692 , BZ# 1074541 ) This update also fixes the following bugs: Bug Fixes BZ# 1020437 Previously, the kernel added some trace points in a way which failed to expose them to systemtap's search mechanisms. This update extends systemtap's search mechanism to include these extra trace points, thus allowing them to be probed from a systemtap script. BZ# 1027459 The SystemTap runtime could attempt to open a file named "trace1" in the current directory rather than the one that was created in the /sys/kernel/debug/systemtap/ directory. As a consequence, SystemTap terminated unexpectedly if such a file existed in the current directory. This update applies a patch to fix this bug and SystemTap now works as expected in the described scenario. BZ# 1109084 Previously, it was not entirely clear that names of scripts configured with the SystemTap init script service could contain only alphanumeric characters and the underscore character ("_"). Also, the first character in a name cannot be a number. This update adds this information to the systemtap(8) manual page to prevent any confusion. The systemtap packages have been upgraded to upstream version 2.5-5, which provides a number of bug fixes and enhancements over the version. (BZ#1038692, BZ#1074541) Users of systemtap are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
8.2. Live Snapshots in Red Hat Virtualization Snapshots of virtual machine hard disks marked shareable and those that are based on Direct LUN connections are not supported, live or otherwise. Any other virtual machine that is not being cloned or migrated can have a snapshot taken when running, paused, or stopped. When a live snapshot of a virtual machine is initiated, the Manager requests that the SPM host create a new volume for the virtual machine to use. When the new volume is ready, the Manager uses VDSM to communicate with libvirt and qemu on the host running the virtual machine that it should begin using the new volume for virtual machine write operations. If the virtual machine is able to write to the new volume, the snapshot operation is considered a success and the virtual machine stops writing to the volume. If the virtual machine is unable to write to the new volume, the snapshot operation is considered a failure, and the new volume is deleted. The virtual machine requires access to both its current volume and the new one from the time when a live snapshot is initiated until after the new volume is ready, so both volumes are opened with read-write access. Virtual machines with an installed guest agent that supports quiescing can ensure filesystem consistency across snapshots. Registered Red Hat Enterprise Linux guests can install the qemu-guest-agent to enable quiescing before snapshots. If a quiescing compatible guest agent is present on a virtual machine when it a snapshot is taken, VDSM uses libvirt to communicate with the agent to prepare for a snapshot. Outstanding write actions are completed, and then filesystems are frozen before a snapshot is taken. When the snapshot is complete, and libvirt has switched the virtual machine to the new volume for disk write actions, the filesystem is thawed, and writes to disk resume. All live snapshots attempted with quiescing enabled. If the snapshot command fails because there is no compatible guest agent present, the live snapshot is re-initiated without the use-quiescing flag. When a virtual machine is reverted to its pre-snapshot state with quiesced filesystems, it boots cleanly with no filesystem check required. Reverting the snapshot using an un-quiesced filesystem requires a filesystem check on boot.

Commands:
5.160. libunistring 5.160.1. RHBA-2012:0887 - libunistring bug fix update An updated libunistring package that fixes one bug is now available for Red Hat Enterprise Linux 6. The libunistring package contains a portable C library that implements the UTF-8, UTF-16 and UTF-32 Unicode string types, together with functions for character processing (names, classifications, and properties) and functions for string processing (iteration, formatted output, width, word breaks, line breaks, normalization, case folding, and regular expressions). Bug Fix BZ# 732017 Previously, when calling the malloc() function, no check for the returned pointer was performed to find out whether memory was successfully allocated. Therefore, if a null pointer was returned, this could cause the libunistring library to misbehave in low-memory situations. This update adds the missing check to properly handle such situations. All users of libunistring are advised to upgrade to this updated package, which fixes this bug.

Commands:
Chapter 21. PostgreSQL PostgreSQL is an Object-Relational database management system (DBMS). [19] In Red Hat Enterprise Linux, the postgresql-server package provides PostgreSQL. Enter the following command to see if the postgresql-server package is installed: If it is not installed, use the yum utility as root to install it: 21.1. PostgreSQL and SELinux When PostgreSQL is enabled, it runs confined by default. Confined processes run in their own domains, and are separated from other confined processes. If a confined process is compromised by an attacker, depending on SELinux policy configuration, an attacker's access to resources and the possible damage they can do is limited. The following example demonstrates the PostgreSQL processes running in their own domain. This example assumes the postgresql-server package is installed: Run the getenforce command to confirm SELinux is running in enforcing mode: The command returns Enforcing when SELinux is running in enforcing mode. Enter the following command as the root user to start postgresql : Confirm that the service is running. The output should include the information below (only the time stamp will differ): Enter the following command to view the postgresql processes: The SELinux context associated with the postgresql processes is system_u:system_r:postgresql_t:s0 . The second last part of the context, postgresql_t , is the type. A type defines a domain for processes and a type for files. In this case, the postgresql processes are running in the postgresql_t domain. [19] See the PostgreSQL project page for more information.

Commands:
~]# rpm -q postgresql-server
~]# yum install postgresql-server
~]USD getenforce Enforcing
~]# systemctl start postgresql.service
~]# systemctl start postgresql.service postgresql.service - PostgreSQL database server Loaded: loaded (/usr/lib/systemd/system/postgresql.service; disabled) Active: active (running) since Mon 2013-08-05 14:57:49 CEST; 12s
~]USD ps -eZ | grep postgres system_u:system_r:postgresql_t:s0 395 ? 00:00:00 postmaster system_u:system_r:postgresql_t:s0 397 ? 00:00:00 postmaster system_u:system_r:postgresql_t:s0 399 ? 00:00:00 postmaster system_u:system_r:postgresql_t:s0 400 ? 00:00:00 postmaster system_u:system_r:postgresql_t:s0 401 ? 00:00:00 postmaster system_u:system_r:postgresql_t:s0 402 ? 00:00:00 postmaster
14.16.2. Learning about the Host Physical Machine CPU Model The virsh capabilities command displays an XML document describing the capabilities of the hypervisor connection and host physical machine. The XML schema displayed has been extended to provide information about the host physical machine CPU model. One of the big challenges in describing a CPU model is that every architecture has a different approach to exposing their capabilities. On x86, the capabilities of a modern CPU are exposed via the CPUID instruction. Essentially this comes down to a set of 32-bit integers with each bit given a specific meaning. Fortunately AMD and Intel agree on common semantics for these bits. Other hypervisors expose the notion of CPUID masks directly in their guest virtual machine configuration format. However, QEMU/KVM supports far more than just the x86 architecture, so CPUID is clearly not suitable as the canonical configuration format. QEMU ended up using a scheme which combines a CPU model name string, with a set of named options. On x86, the CPU model maps to a baseline CPUID mask, and the options can be used to then toggle bits in the mask on or off. libvirt decided to follow this lead and uses a combination of a model name and options. It is not practical to have a database listing all known CPU models, so libvirt has a small list of baseline CPU model names. It chooses the one that shares the greatest number of CPUID bits with the actual host physical machine CPU and then lists the remaining bits as named features. Notice that libvirt does not display which features the baseline CPU contains. This might seem like a flaw at first, but as will be explained in this section, it is not actually necessary to know this information.

Commands:
5.199. module-init-tools 5.199.1. RHBA-2012:0871 - module-init-tools bug fix and enhancement update Updated module-init-tools packages that fix two bugs and add one enhancement are now available for Red Hat Enterprise Linux 6. The module-init-tools packages include various programs needed for automatic loading and unloading of modules under 2.6 kernels, as well as other module management programs. Device drivers and file systems are two examples of loaded and unloaded modules. Bug Fixes BZ# 670613 Previously, on low-memory systems (such as low-memory high-performance infrastructure, or HPC, nodes or virtual machines), depmod could use excessive amount of memory. As a consequence, the depmod process was killed by the OOM (out of memory) mechanism, and the system was unable to boot. With this update, the free() function is correctly used on several places in the code so that depmod's memory consumption is reduced. BZ# 673100 Previously, if the "override" keyword was present in the depmod.conf file without any parameters specified, the depmod utility terminated unexpectedly with a segmentation fault. A patch has been applied to ensure that the depmod utility no longer crashes and a syntax warning is displayed instead. Enhancement BZ# 761511 This update adds the "backports" directory to the search path in the depmod.conf file, which is necessary to support integration of the compat-wireless package into kernel packages. All users of module-init-tools are advised to upgrade to these updated packages, which fix these bugs and add this enhancements.

Commands:
Chapter 5. Minimum hardware recommendations Ceph can run on non-proprietary commodity hardware. Small production clusters and development clusters can run without performance optimization with modest hardware. Note Disk space requirements are based on the Ceph daemons' default path under /var/lib/ceph/ directory. Process Criteria Minimum Recommended ceph-osd Processor 1x AMD64 or Intel 64 RAM For BlueStore OSDs, Red Hat typically recommends a baseline of 16 GB of RAM per OSD host, with an additional 5 GB of RAM per daemon. OS Disk 1x OS disk per host Volume Storage 1x storage drive per daemon block.db Optional, but Red Hat recommended, 1x SSD or NVMe or Optane partition or logical volume per daemon. Sizing is 4% of block.data for BlueStore for object, file and mixed workloads and 1% of block.data for the BlueStore for Block Device, Openstack cinder, and Openstack cinder workloads. block.wal Optional, 1x SSD or NVMe or Optane partition or logical volume per daemon. Use a small size, for example 10 GB, and only if it's faster than the block.db device. Network 2x 1GB Ethernet NICs ceph-mon Processor 1x AMD64 or Intel 64 RAM 1 GB per daemon Disk Space 15 GB per daemon (50 GB recommended) Monitor Disk Optionally,1x SSD disk for leveldb monitor data. Network 2x 1 GB Ethernet NICs ceph-mgr Processor 1x AMD64 or Intel 64 RAM 1 GB per daemon Network 2x 1 GB Ethernet NICs ceph-radosgw Processor 1x AMD64 or Intel 64 RAM 1 GB per daemon Disk Space 5 GB per daemon Network 1x 1 GB Ethernet NICs ceph-mds Processor 1x AMD64 or Intel 64 RAM 2 GB per daemon This number is highly dependent on the configurable MDS cache size. The RAM requirement is typically twice as much as the amount set in the mds_cache_memory_limit configuration setting. Note also that this is the memory for your daemon, not the overall system memory. Disk Space 2 MB per daemon, plus any space required for logging, which might vary depending on the configured log levels. Network 2x 1 GB Ethernet NICs Note that this is the same network as the OSDs. If you have a 10 GB network on your OSDs you should use the same on your MDS so that the MDS is not disadvantaged when it comes to latency.

Commands:
Chapter 62. Apache CXF Message Processing Phases Inbound phases Table 62.1, "Inbound message processing phases" lists the phases available in inbound interceptor chains. Table 62.1. Inbound message processing phases Phase Description RECEIVE Performs transport specific processing, such as determining MIME boundaries for binary attachments. PRE_STREAM Processes the raw data stream received by the transport. USER_STREAM POST_STREAM READ Determines if a request is a SOAP or XML message and builds adds the proper interceptors. SOAP message headers are also processed in this phase. PRE_PROTOCOL Performs protocol level processing. This includes processing of WS-* headers and processing of the SOAP message properties. USER_PROTOCOL POST_PROTOCOL UNMARSHAL Unmarshals the message data into the objects used by the application level code. PRE_LOGICAL Processes the unmarshalled message data. USER_LOGICAL POST_LOGICAL PRE_INVOKE INVOKE Passes the message to the application code. On the server side, the service implementation is invoked in this phase. On the client side, the response is handed back to the application. POST_INVOKE Invokes the outbound interceptor chain. Outbound phases Table 62.2, "Inbound message processing phases" lists the phases available in inbound interceptor chains. Table 62.2. Inbound message processing phases Phase Description SETUP Performs any set up that is required by later phases in the chain. PRE_LOGICAL Performs processing on the unmarshalled data passed from the application level. USER_LOGICAL POST_LOGICAL PREPARE_SEND Opens the connection for writing the message on the wire. PRE_STREAM Performs processing required to prepare the message for entry into a data stream. PRE_PROTOCOL Begins processing protocol specific information. WRITE Writes the protocol message. PRE_MARSHAL Marshals the message. MARSHAL POST_MARSHAL USER_PROTOCOL Process the protocol message. POST_PROTOCOL USER_STREAM Process the byte-level message. POST_STREAM SEND Sends the message and closes the transport stream. Important Outbound interceptor chains have a mirror set of ending phases whose names are appended with _ENDING . The ending phases are used interceptors that require some terminal action to occur before data is written on the wire.

Commands: