mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 126. KafkaBridgeConsumerSpec schema reference Used in: KafkaBridgeSpec Full list of KafkaBridgeConsumerSpec schema properties Configures consumer options for the Kafka Bridge as keys. The values can be one of the following JSON types: String Number Boolean Exceptions You can specify and configure the options listed in the Apache Kafka configuration documentation for consumers . However, AMQ Streams takes care of configuring and managing options related to the following, which cannot be changed: Kafka cluster bootstrap address Security (encryption, authentication, and authorization) Consumer group identifier Properties with the following prefixes cannot be set: bootstrap.servers group.id sasl. security. ssl. If the config property contains an option that cannot be changed, it is disregarded, and a warning message is logged to the Cluster Operator log file. All other supported options are forwarded to Kafka Bridge, including the following exceptions to the options configured by AMQ Streams: Any ssl configuration for supported TLS versions and cipher suites Example Kafka Bridge consumer configuration apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaBridge metadata: name: my-bridge spec: # ... consumer: config: auto.offset.reset: earliest enable.auto.commit: true # ... Important The Cluster Operator does not validate keys or values in the config object. If an invalid configuration is provided, the Kafka Bridge deployment might not start or might become unstable. In this case, fix the configuration so that the Cluster Operator can roll out the new configuration to all Kafka Bridge nodes. 126.1. KafkaBridgeConsumerSpec schema properties Property Description config The Kafka consumer configuration used for consumer instances created by the bridge. Properties with the following prefixes cannot be set: ssl., bootstrap.servers, group.id, sasl., security. (with the exception of: ssl.endpoint.identification.algorithm, ssl.cipher.suites, ssl.protocol, ssl.enabled.protocols). map

Commands:
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaBridge metadata: name: my-bridge spec: # consumer: config: auto.offset.reset: earliest enable.auto.commit: true #
8.165. pam_pkcs11 8.165.1. RHBA-2014:1474 - pam_pkcs11 bug fix update Updated pam_pkcs11 packages that fix two bugs are now available for red Hat Enterprise Linux 6. The pam_pkcs11 package allows X.509 certificate-based user authentication. It provides access to the certificate and its dedicated private key with an appropriate Public Key Cryptographic Standards #11 (PKCS#11) module. Bug Fixes BZ# 887143 The pam_pkcs11 utility generated an incorrect Lightweight Directory Access Protocol (LDAP) URL when attempting to connect to port 636. As a consequence, the connection to that port failed. This update applies a patch to address this bug, and pam_pkcs11 now generates correct LDAP URL in the described scenario. BZ# 1012082 After adding the coolkey module manually using the full path by running the "modutil -add "CoolKey PKCS #11 Module" -dbdir /etc/pki/nssdb -libfile /usr/lib64/pkcs11/libcookeypk11.so" command, an attempt to log in using a smart card failed. The underlying source code has been modified to fix this bug and the user is now able to log in using the smart cards as expected. Users of pam_pkcs11 are advised to upgrade to these updated packages, which fix these bugs.

Commands:
7.292. ypserv 7.292.1. RHBA-2013:0330 - ypserv bug fix update Updated ypserv packages that fix four bugs are now available for Red Hat Enterprise Linux 6. The ypserv packages provide the Network Information Service (NIS) server. NIS is a system that provides network information such as login names, passwords, home directories, and group information to all the machines on a network. Bug Fixes BZ#790812 Prior to this update, the NIS server was returning "0" (YP_FALSE) instead of "-1" (YP_NOMAP) after a request for a database not present in the server's domain. This behavior caused the autofs mount attempts to fail on Solaris clients. With this update, the return value has been fixed and the autofs mounts no longer fail on Solaris clients. BZ# 816981 Previously, when the crypt() function returned NULL, the yppasswd utility did not properly recognize the return value. This bug has been fixed, and the NULL return values of crypt() are now recognized and reported correctly by yppaswd. BZ#845283 Previously, the ypserv utility allocated large amounts of virtual memory when parsing XDR requests, but failed to free that memory in case the request was not parsed successfully. Consequently, memory leaks occurred. With this update, a patch has been provided to free the already allocated memory when parsing of a request fails. As a result, the memory leaks no longer occur. BZ# 863952 Previously, the yppush(8) man page did not describe how to change settings of the yppush utility. The manual page has been amended to specify that the settings can be changed in the /var/yp/Makefile file. All users of ypserv are advised to upgrade to these updated packages, which fix these bugs.

Commands:
4.3. CONTROL/MONITORING The CONTROL/MONITORING Panel presents the a limited runtime status of LVS. It displays the status of the pulse daemon, the LVS routing table, and the LVS-spawned nanny processes. Note The fields for CURRENT LVS ROUTING TABLE and CURRENT LVS PROCESSES remain blank until you actually start LVS, as shown in Section 4.8, "Starting LVS" . Figure 4.2. The CONTROL/MONITORING Panel Auto update The status display on this page can be updated automatically at a user configurable interval. To enable this feature, click on the Auto update checkbox and set the desired update frequency in the Update frequency in seconds text box (the default value is 10 seconds). It is not recommended that you set the automatic update to an interval less than 10 seconds. Doing so may make it difficult to reconfigure the Auto update interval because the page will update too frequently. If you encounter this issue, simply click on another panel and then back on CONTROL/MONITORING . The Auto update feature does not work with all browsers, such as Mozilla . Update information now You can manually update the status information manually by clicking this button. CHANGE PASSWORD Clicking this button takes you to a help screen with information on how to change the administrative password for the Piranha Configuration Tool .

Commands:
4.3.2.2. Password Aging Password aging is another technique used by system administrators to defend against bad passwords within an organization. Password aging means that after a set amount of time (usually 90 days) the user is prompted to create a new password. The theory behind this is that if a user is forced to change his password periodically, a cracked password is only useful to an intruder for a limited amount of time. The downside to password aging, however, is that users are more likely to write their passwords down. There are two primary programs used to specify password aging under Red Hat Enterprise Linux: the chage command or the graphical User Manager ( system-config-users ) application. The -M option of the chage command specifies the maximum number of days the password is valid. So, for instance, to set a user's password to expire in 90 days, type the following command: In the above command, replace <username> with the name of the user. To disable password expiration, it is traditional to use a value of 99999 after the -M option (this equates to a little over 273 years). The graphical User Manager application may also be used to create password aging policies. To access this application, go to the Main Menu button (on the Panel) => System Settings => Users &Groups or type the command system-config-users at a shell prompt (for example, in an XTerm or a GNOME terminal). Click on the Users tab, select the user from the user list, and click Properties from the button menu (or choose File => Properties from the pull-down menu). Then click the Password Info tab and enter the number of days before the password expires, as shown in Figure 4.1, " Password Info Pane" . Figure 4.1. Password Info Pane For more information about user and group configuration (including instructions on forcing first time passwords), refer to the chapter titled User and Group Configuration in the System Administrators Guide . For an overview of user and resource management, refer to the chapter titled Managing User Accounts and Resource Access in the Red Hat Enterprise Linux Introduction to System Adminitration .

Commands:
chage -M 90 <username>
5.11. Multi-Level Security (MLS) The Multi-Level Security technology refers to a security scheme that enforces the Bell-La Padula Mandatory Access Model. Under MLS, users and processes are called subjects , and files, devices, and other passive components of the system are called objects . Both subjects and objects are labeled with a security level, which entails a subject's clearance or an object's classification. Each security level is composed of a sensitivity and a category , for example, an internal release schedule is filed under the internal documents category with a confidential sensitivity. Figure 5.1, "Levels of clearance" shows levels of clearance as originally designed by the US defense community. Relating to our internal schedule example above, only users that have gained the confidential clearance are allowed to view documents in the confidential category. However, users who only have the confidential clearance are not allowed to view documents that require higher levels or clearance; they are allowed read access only to documents with lower levels of clearance, and write access to documents with higher levels of clearance. Figure 5.1. Levels of clearance Figure 5.2, "Allowed data flows using MLS" shows all allowed data flows between a subject running under the "Secret" security level and various objects with different security levels. In simple terms, the Bell-LaPadula model enforces two properties: no read up and no write down . Figure 5.2. Allowed data flows using MLS 5.11.1. MLS and System Privileges MLS access rules are always combined with conventional access permissions (file permissions). For example, if a user with a security level of "Secret" uses Discretionary Access Control (DAC) to block access to a file by other users, this also blocks access by users with a security level of "Top Secret". It is important to remember that SELinux MLS policy rules are checked after DAC rules. A higher security clearance does not automatically give permission to arbitrarily browse a file system. Users with top-level clearances do not automatically acquire administrative rights on multi-level systems. While they may have access to all information on the computer, this is different from having administrative rights.

Commands:
function::return_str Name function::return_str - Formats the return value as a string Synopsis Arguments format Variable to determine return type base value ret Return value (typically USDreturn ) Description This function is used by the syscall tapset, and returns a string. Set format equal to 1 for a decimal, 2 for hex, 3 for octal. Note that this function is preferred over returnstr .

Commands:
return_str:string(format:long,ret:long)
20.23. Adding Multifunction PCI Devices to KVM Guest Virtual Machines To add a multi-function PCI device to a KVM guest virtual machine: Run the virsh edit guestname command to edit the XML configuration file for the guest virtual machine. In the <address> element, add a multifunction='on' attribute. This enables the use of other functions for the particular multifunction PCI device. For a PCI device with two functions, amend the XML configuration file to include a second device with the same slot number as the first device and a different function number, such as function='0x1' . For Example: Run the lspci command. The output from the KVM guest virtual machine shows the virtio block device: Note The SeaBIOS application runs in real mode for compatibility with BIOS interfaces. This limits the amount of memory available. As a consequence, SeaBIOS is only able to handle a limited number of disks. Currently, the supported number of disks is: virtio-scsi - 64 virtio-blk - 4 ahci/sata - 24 (4 controllers with all 6 ports connected) usb-storage - 4 As a workaround for this problem, when attaching a large number of disks to your virtual machine, make sure that your system disk has a small pci slot number, so SeaBIOS sees it first when scanning the pci bus. It is also recommended to use the virtio-scsi device instead of virtio-blk as the per-disk memory overhead is smaller.

Commands:
<disk type='file' device='disk'> <driver name='qemu' type='raw' cache='none'/> <source file='/var/lib/libvirt/images/rhel62-1.img'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/> </disk>
<disk type='file' device='disk'> <driver name='qemu' type='raw' cache='none'/> <source file='/var/lib/libvirt/images/rhel62-1.img'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/> </disk> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='none'/> <source file='/var/lib/libvirt/images/rhel62-2.img'/> <target dev='vdb' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/> </disk>
lspci 00:05.0 SCSI storage controller: Red Hat, Inc Virtio block device 00:05.1 SCSI storage controller: Red Hat, Inc Virtio block device
Chapter 4. Project deployment options with Red Hat Decision Manager After you develop, test, and build your Red Hat Decision Manager project, you can deploy the project to begin using the business assets you have created. You can deploy a Red Hat Decision Manager project to a configured KIE Server, to an embedded Java application, or into a Red Hat OpenShift Container Platform environment for an enhanced containerized implementation. The following options are the main methods for Red Hat Decision Manager project deployment: Table 4.1. Project deployment options Deployment option Description Documentation Deployment to an OpenShift environment Red Hat OpenShift Container Platform combines Docker and Kubernetes and enables you to create and manage containers. You can install both Business Central and KIE Server on OpenShift. Red Hat Decision Manager provides templates that you can use to deploy a Red Hat Decision Manager authoring environment, managed server environment, immutable server environment, or trial environment on OpenShift. With OpenShift, components of Red Hat Decision Manager are deployed as separate OpenShift pods. You can scale each of the pods up and down individually, providing as few or as many containers as necessary for a particular component. You can use standard OpenShift methods to manage the pods and balance the load. Deploying an Red Hat Decision Manager environment on Red Hat OpenShift Container Platform 4 using Operators Deploying an Red Hat Decision Manager environment on Red Hat OpenShift Container Platform 3 using templates Deployment to KIE Server KIE Server is the server provided with Red Hat Decision Manager that runs the decision services, process applications, and other deployable assets from a packaged and deployed Red Hat Decision Manager project (KJAR file). These services are consumed at run time through an instantiated KIE container, or deployment unit . You can deploy and maintain deployment units in KIE Server using Business Central or using a headless Process Automation Manager controller with its associated REST API (considered a managed KIE Server instance). You can also deploy and maintain deployment units using the KIE Server REST API or Java client API from a standalone Maven project, an embedded Java application, or other custom environment (considered an unmanaged KIE Server instance). Packaging and deploying an Red Hat Decision Manager project Interacting with Red Hat Decision Manager using KIE APIs Managing and monitoring KIE Server Deployment to an embedded Java application If you want to deploy Red Hat Decision Manager projects to your own Java virtual machine (JVM) environment, microservice, or application server, you can bundle the application resources in the project WAR files to create a deployment unit similar to a KIE container. You can also use the core KIE APIs (not KIE Server APIs) to configure a KIE scanner to periodically update KIE containers. KIE Public API

Commands:
4.12. augeas 4.12.1. RHEA-2011:1659 - augeas bug fix and enhancement update Updated augeas packages that fix multiple bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. Augeas is a configuration editing tool. Augeas parses configuration files in their native formats and transforms them into a tree. Configuration changes are made by manipulating this tree and saving it back into native config files. The augeas packages have been upgraded to upstream version 0.9.0, which provides a number of bug fixes and enhancements over the version. (BZ# 691483 ) Bug Fix BZ# 693539 Previously, due to a bug in the source code, parsing invalid files failed silently without any error message. With this update, error messages are provided to inform users about the problem. All users of Augeas are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Appendix A. Reference material A.1. About rule story points A.1.1. What are story points? Story points are an abstract metric commonly used in Agile software development to estimate the level of effort needed to implement a feature or change. The Migration Toolkit for Applications uses story points to express the level of effort needed to migrate particular application constructs, and the application as a whole. It does not necessarily translate to man-hours, but the value should be consistent across tasks. A.1.2. How story points are estimated in rules Estimating the level of effort for the story points for a rule can be tricky. The following are the general guidelines MTA uses when estimating the level of effort required for a rule. Level of Effort Story Points Description Information 0 An informational warning with very low or no priority for migration. Trivial 1 The migration is a trivial change or a simple library swap with no or minimal API changes. Complex 3 The changes required for the migration task are complex, but have a documented solution. Redesign 5 The migration task requires a redesign or a complete library change, with significant API changes. Rearchitecture 7 The migration requires a complete rearchitecture of the component or subsystem. Unknown 13 The migration solution is not known and may need a complete rewrite. A.1.3. Task category In addition to the level of effort, you can categorize migration tasks to indicate the severity of the task. The following categories are used to group issues to help prioritize the migration effort. Mandatory The task must be completed for a successful migration. If the changes are not made, the resulting application will not build or run successfully. Examples include replacement of proprietary APIs that are not supported in the target platform. Optional If the migration task is not completed, the application should work, but the results may not be optimal. If the change is not made at the time of migration, it is recommended to put it on the schedule soon after your migration is completed. Potential The task should be examined during the migration process, but there is not enough detailed information to determine if the task is mandatory for the migration to succeed. An example of this would be migrating a third-party proprietary type where there is no directly compatible type. Information The task is included to inform you of the existence of certain files. These may need to be examined or modified as part of the modernization effort, but changes are typically not required. A.2. Additional resources A.2.1. Additional resources MTA Jira issue tracker: https://issues.redhat.com/projects/MTA/issues MTA mailing list: windup-eng@redhat.com Revised on 2025-02-26 19:49:46 UTC

Commands:
Chapter 1. JBoss EAP 8.0 installation methods You can install JBoss EAP 8.0 using the following methods: Archive installation JBoss EAP Installation Manager GUI installer RPM installation From JBoss EAP 8.0 onward, the JBoss EAP Installation Manager and Graphical (GUI) installer methods support both online and offline installation modes. Online installation: You can install JBoss EAP 8.x directly from an online repository. You must have access to the Red Hat repositories or their mirrors to use the online option. When using this mode, the resulting server will always be the latest available JBoss EAP 8.0 update. Offline installation: You can install JBoss EAP 8.x from a local file-system. Use the offline installation mode if you do not have access to the Red Hat repositories or their mirrors or want to install a specific JBoss EAP update. After the installation, you may need to perform an update step to use the latest version of JBoss EAP 8.x. Depending on your requirements, choose the installation method. The following table provides a brief overview of each type of installation method. Table 1.1. Installation Methods Method Description Online/offline options JBoss EAP Installation Manager You can run the installer in a terminal. You must configure JBoss EAP after the installation. Online Offline Graphical (GUI) installer You can run the installer as a graphical wizard. It provides step-by-step instructions for installing JBoss EAP. You can configure some basic options for the server instance during the installation. The installer has additional setup options, that includes installing Quickstarts and configuring the Maven repository. Online Offline Archive Installation You can download the archive file and extract the instance manually. You must configure JBoss EAP after the installation. Offline RPM Installation You can install JBoss EAP using RPM packages on supported installations of Red Hat Enterprise Linux 8 or later. Online Offline (using Red Hat Satellite) You can run JBoss EAP on the following cloud platforms. This documentation does not cover provisioning on other cloud platforms. See the related documentation. JBoss EAP on OpenShift. Additional resources JBoss EAP on OpenShift . 1.1. Understanding channels in JBoss EAP The jboss-eap-installation-manager provides a streamlined and controlled pathway to access the most recent supported versions of JBoss EAP components. These streamlined and controlled pathways are called channels. A channel consists of a curated list of component versions (called channel manifest) and a collection of repositories used to resolve and retrieve those components. Each repository has a unique name (id) and a default Maven repository URL. The jboss-eap-installation-manager allows you to manage these channels effectively in both stand-alone and managed domain configurations.

Commands:
Chapter 6. (Preview) Deploying the Streams for Apache Kafka Console After you have deployed a Kafka cluster that's managed by Streams for Apache Kafka, you can deploy the Streams for Apache Kafka Console and connect your cluster. The Streams for Apache Kafka Console facilitates the administration of Kafka clusters, providing real-time insights for monitoring, managing, and optimizing each cluster from its user interface. For more information on connecting to and using the Streams for Apache Kafka Console, see the console guide in the Streams for Apache Kafka documentation . Note The Streams for Apache Kafka Console is currently available as a technology preview.

Commands: