mtpti5iD/redhat-docs_dataset huggingface dataset:
7.136. mailman 7.136.1. RHBA-2012:1474 - mailman bug fix update Updated mailman packages that fix multiple bugs are now available for Red Hat Enterprise Linux 6. Mailman is a program used to help manage e-mail discussion lists. Bug Fixes BZ# 772998 The reset_pw.py script contained a typo, which could cause the mailman utility to fail with a traceback. The typo has been corrected, and mailman now works as expected. BZ# 799323 The "urlhost" argument was not handled in the newlist script. When running the "newlist" command with the "--urlhost" argument specified, the contents of the index archive page was not created using proper URLs; the hostname was used instead. With this update, "urlhost" is now handled in the newlist script. If the "--urlhost" argument is specified on the command line, the host URL is used when creating the index archive page instead of the hostname. BZ# 832920 Previously, long lines in e-mails were not wrapped in the web archive, sometimes requiring excessive horizontal scrolling. The "white-space: pre-wrap;" CSS style has been added to all templates, so that long lines are now wrapped in browsers that support that style. BZ# 834023 The "From" string in the e-mail body was not escaped properly. A message containing the "From" string at the beginning of a line was split and displayed in the web archive as two or more messages. The "From" string is now correctly escaped, and messages are no longer split in the described scenario. All users of mailman are advised to upgrade to these updated packages, which fix these bugs.

Commands:
4.41. cvs 4.41.1. RHSA-2012:0321 - Moderate: cvs security update Updated cvs packages that fix one security issue are now available for Red Hat Enterprise Linux 5 and 6. The Red Hat Security Response Team has rated this update as having moderate security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. Concurrent Version System (CVS) is a version control system that can record the history of your files. Security Fix CVE-2012-0804 A heap-based buffer overflow flaw was found in the way the CVS client handled responses from HTTP proxies. A malicious HTTP proxy could use this flaw to cause the CVS client to crash or, possibly, execute arbitrary code with the privileges of the user running the CVS client. All users of cvs are advised to upgrade to these updated packages, which contain a patch to correct this issue.

Commands:
probe::nfsd.create Name probe::nfsd.create - NFS server creating a file(regular,dir,device,fifo) for client Synopsis nfsd.create Values fh file handle (the first part is the length of the file handle) iap_valid Attribute flags filelen the length of file name type file type(regular,dir,device,fifo ...) filename file name iap_mode file access mode client_ip the ip address of client Description Sometimes nfsd will call nfsd_create_v3 instead of this this probe point.

Commands:
Chapter 2. Installation This chapter guides you through the steps to install AMQ Spring Boot Starter in your environment. 2.1. Prerequisites You must have a subscription to access AMQ release files and repositories. To build programs with AMQ Spring Boot Starter, you must install Apache Maven . To use AMQ Spring Boot Starter, you must install Java. 2.2. Using the Red Hat Maven repository Configure your Maven environment to download the client library from the Red Hat Maven repository. Procedure Add the Red Hat repository to your Maven settings or POM file. For example configuration files, see Section B.1, "Using the online repository" . <repository> <id>red-hat-ga</id> <url>https://maven.repository.redhat.com/ga</url> </repository> Add the library dependency to your POM file. <dependency> <groupId>org.amqphub.spring</groupId> <artifactId>amqp-10-jms-spring-boot-starter</artifactId> <version>2.3.6.redhat-00003</version> </dependency> The client is now available in your Maven project. 2.3. Installing a local Maven repository As an alternative to the online repository, AMQ Spring Boot Starter can be installed to your local filesystem as a file-based Maven repository. Procedure Use your subscription to download the AMQ Clients 2.9.0 Spring Boot Starter Maven repository .zip file. Extract the file contents into a directory of your choosing. On Linux or UNIX, use the unzip command to extract the file contents. USD unzip amq-clients-2.9.0-spring-boot-starter-maven-repository.zip On Windows, right-click the .zip file and select Extract All . Configure Maven to use the repository in the maven-repository directory inside the extracted install directory. For more information, see Section B.2, "Using a local repository" .

Commands:
<repository> <id>red-hat-ga</id> <url>https://maven.repository.redhat.com/ga</url> </repository>
<dependency> <groupId>org.amqphub.spring</groupId> <artifactId>amqp-10-jms-spring-boot-starter</artifactId> <version>2.3.6.redhat-00003</version> </dependency>
unzip amq-clients-2.9.0-spring-boot-starter-maven-repository.zip
20.16.9.3. Setting a port masquerading range In cases where you want to set the port masquerading range, the port can be set as follows: <forward mode='nat'> <address start='192.0.2.1' end='192.0.2.10'/> </forward> ... Figure 20.38. Port Masquerading Range These values should be set using the iptables commands as shown in Section 18.3, "Network Address Translation Mode"

Commands:
<forward mode='nat'> <address start='192.0.2.1' end='192.0.2.10'/> </forward>
6.6. Configuring the Role-Based Credential Map Identity Login Module Warning RoleBasedCredentialMap is now deprecated. Procedure 6.2. Configure Role-Based Credential Map Identity Login Module Create the Login Module Configure authentication modules using the Management Console according to the following specification: Complete the Configuration Configure the data source or connection factory in the same way as for the CallerIdentityLoginModule . Result In the above example, the primary login module UsersRolesLoginModule is configured to login the primary user and assign some roles. The RoleBasedCredentialMap login module is configured to hold role to password information in the file defined by the credentialMap property. When the user logs in, the role information from the primary login module is taken, and the role's password is extracted and attached as a private credential to the Subject. Note To use an encrypted password instead of a plaintext one, include the encrypted password in the file defined by the credentialMap property. For more information about encrypting passwords, refer to the JBoss Enterprise Application Platform Security Guide .

Commands:
<subsystem xmlns="urn:jboss:domain:security:1.1"> <security-domains> <security-domain name="my-security-domain" cache-type="default"> <authentication> <login-module code="UsersRoles" flag="required"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="usersProperties" value="file://USD{jboss.server.config.dir}/teiid-security-users.properties"/> <module-option name="rolesProperties" value="file://USD{jboss.server.config.dir}/teiid-security-roles.properties"/> </login-module> <login-module code="org.teiid.jboss.RoleBasedCredentialMapIdentityLoginModule" flag="required"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="credentialMap" value="file://USD{jboss.server.config.dir}/teiid-credentialmap.properties"/> </login-module> </authentication> </security-domain> </security-domains> </subsystem>
Chapter 11. Deploying a Plain JAR Abstract An alternative method of deploying applications into Apache Karaf is to use plain JAR files. These are usually libraries that contain no deployment metadata . A plain JAR is neither a WAR, nor an OSGi bundle. If the plain JAR occurs as a dependency of a bundle, you must add bundle headers to the JAR. If the JAR exposes a public API, typically the best solution is to convert the existing JAR into a bundle, enabling the JAR to be shared with other bundles. Use the instructions in this chapter to perform the conversion process automatically, using the open source Bnd tool. For more information on the Bnd tool, see Bnd tools website . 11.1. Converting a JAR Using the wrap Scheme Overview You have the option of converting a JAR into a bundle using the wrap: protocol, which can be used with any existing URL format. The wrap: protocol is based on the Bnd utility. Syntax The wrap: protocol has the following basic syntax: The wrap: protocol can prefix any URL that locates a JAR. The locating part of the URL, LocationURL , is used to obtain the plain JAR and the URL handler for the wrap: protocol then converts the JAR automatically into a bundle. Note The wrap: protocol also supports a more elaborate syntax, which enables you to customize the conversion by specifying a Bnd properties file or by specifying individual Bnd properties in the URL. Typically, however, the wrap: protocol is used just with the default settings. Default properties The wrap: protocol is based on the Bnd utility, so it uses exactly the same default properties to generate the bundle as Bnd does. Wrap and install The following example shows how you can use a single console command to download the plain commons-logging JAR from a remote Maven repository, dynamically convert it into an OSGi bundle, and then install it and start it in the OSGi container: Reference The wrap: protocol is provided by the Pax project , which is the umbrella project for a variety of open source OSGi utilities. For full documentation on the wrap: protocol, see the Wrap Protocol reference page.

Commands:
wrap: LocationURL
karaf@root> bundle:install -s wrap:mvn:commons-logging/commons-logging/1.1.1
8.39. ctdb 8.39.1. RHEA-2014:1488 - ctdb bug fix and enhancement update Updated ctdb packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The ctdb packages provide a clustered database based on Samba's Trivial Database (TDB) used to store temporary data. This update also fixes the following bugs: Note The ctdb package has been upgraded to upstream version 2.5.1, which provides a number of bug fixes and enhancements over the version. Note that due to these changes, the new version cannot run in parallel with the versions on the same cluster. In addition, note that to update CTDB in an existing cluster, CTDB has to be stopped on all nodes in the cluster before the upgrade can start. Furthermore, back up your cluster nodes in case the update fails. To ensure easy recovery in case of update failure, only a single node should be updated at a time. (BZ# 1061630 , BZ# 1085447 ) This update also fixes the following bugs: Bug Fixes BZ# 987099 Prior to this update, CTDB sometimes waited too long for file locks to establish. Consequently, clients accessing a CTDB file-server cluster could time out due to high latency. With this update, the underlying code has been fixed to address the problem, and clients can now access files on a CTDB file-server cluster without timeouts. BZ# 1075913 Previously, when CTDB was configured to use two bonded interfaces, CTDB failed to assign an IP address to the second bonded interface. As a consequence, the cluster status of the cluster node was shown as "PARTIALLYONLINE" even when the actual status was "OK". The script which handles the network interfaces has been fixed and the cluster status now shows the correct value. BZ# 1085413 Prior to this update, CTDB under some circumstances attempted to free allocated memory at an invalid address which caused CTDB to terminate unexpectedly with a segmentation fault. This update fixes the underlying code and CTDB uses the correct address for freeing allocated memory. As a result, the crash no longer occurs. The ctdb package has been upgraded to upstream version 2.5.1, which provides a number of bug fixes and enhancements over the version. Note that due to these changes, the new version cannot run in parallel with the versions on the same cluster. In addition, note that to update CTDB in an existing cluster, CTDB has to be stopped on all nodes in the cluster before the upgrade can start. Furthermore, back up your cluster nodes in case the update fails. To ensure easy recovery in case of update failure, only a single node should be updated at a time. (BZ#1061630, BZ#1085447) Users of CTDB are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 3. Getting started This chapter guides you through the steps to set up your environment and run a simple messaging program. 3.1. Prerequisites To build the example, Maven must be configured to use the Red Hat repository or a local repository . You must install the examples . You must have a message broker listening for connections on localhost . It must have anonymous access enabled. For more information, see Starting the broker . You must have a queue named exampleQueue . For more information, see Creating a queue . 3.2. Running your first example The example creates a consumer and producer for a queue named exampleQueue . It sends a text message and then receives it back, printing the received message to the console. Procedure Use Maven to build the examples by running the following command in the <install-dir> /examples/protocols/openwire/queue directory. USD mvn clean package dependency:copy-dependencies -DincludeScope=runtime -DskipTests The addition of dependency:copy-dependencies results in the dependencies being copied into the target/dependency directory. Use the java command to run the example. On Linux or UNIX: USD java -cp "target/classes:target/dependency/*" org.apache.activemq.artemis.jms.example.QueueExample On Windows: > java -cp "target\classes;target\dependency\*" org.apache.activemq.artemis.jms.example.QueueExample Running it on Linux results in the following output: USD java -cp "target/classes:target/dependency/*" org.apache.activemq.artemis.jms.example.QueueExample Sent message: This is a text message Received message: This is a text message The source code for the example is in the <install-dir> /examples/protocols/openwire/queue/src directory. Additional examples are available in the <install-dir> /examples/protocols/openwire directory.

Commands:
mvn clean package dependency:copy-dependencies -DincludeScope=runtime -DskipTests
java -cp "target/classes:target/dependency/*" org.apache.activemq.artemis.jms.example.QueueExample
> java -cp "target\classes;target\dependency\*" org.apache.activemq.artemis.jms.example.QueueExample
java -cp "target/classes:target/dependency/*" org.apache.activemq.artemis.jms.example.QueueExample Sent message: This is a text message Received message: This is a text message
Chapter 3. Shenandoah garbage collector modes You can run Shenandoah in three different modes. Select a specific mode with the -XX:ShenandoahGCMode=<name> . The following list describes each Shenandoah mode: normal/satb (product, default) This mode runs a concurrent garbage collector (GC) with Snapshot-At-The-Beginning (SATB) marking. This marking mode does the similar work as G1, the default garbage collector for Red Hat build of OpenJDK 21. iu (experimental) This mode runs a concurrent GC with Incremental Update (IU) marking. It can reclaim unreachably memory more aggressively. This marking mode mirrors the SATB mode. This may make marking less conservative, especially around accessing weak references. passive (diagnostic) This mode runs Stop the World Event GCs. This mode is used for functional testing, but sometimes it is useful for bisecting performance anomalies with GC barriers, or to ascertain the actual live data size in the application.

Commands:
8.2.3.3. Differential Backups Differential backups are similar to incremental backups in that both backup only modified files. However, differential backups are cumulative -- in other words, with a differential backup, once a file has been modified it continues to be included in all subsequent differential backups (until the , full backup, of course). This means that each differential backup contains all the files modified since the last full backup, making it possible to perform a complete restoration with only the last full backup and the last differential backup. Like the backup strategy used with incremental backups, differential backups normally follow the same approach: a single periodic full backup followed by more frequent differential backups. The effect of using differential backups in this way is that the differential backups tend to grow a bit over time (assuming different files are modified over the time between full backups). This places differential backups somewhere between incremental backups and full backups in terms of backup media utilization and backup speed, while often providing faster single-file and complete restorations (due to fewer backups to search/restore). Given these characteristics, differential backups are worth careful consideration.

Commands:
15.9. Using GVFS Metadata GVFS has its metadata storage implemented as a set of simple key/value pairs information bound to a particular file. Thus, there is a tool for a user or application to save small data designed for runtime information such as icon position, last-played location, position in a document, emblems, notes, and so on. Whenever a file or directory is moved, metadata is moved accordingly so that it stays connected to the respective file. GVFS stores all metadata privately so it is available only on the machine. However, GVFS mounts and removable media are tracked as well. Note Removable media are now mounted in the /run/media/ instead of the /media directory. To view and manipulate with metadata, you can use: the gvfs-info command; the gvfs-set-attribute command; or any other native GIO way of working with attributes. In the following example, a custom metadata attribute is set. Notice the differences between particular gvfs-info calls and data persistence after a move or rename (note the gvfs-info command output): Example 15.5. Setting Custom Metadata Attribute

Commands:
touch /tmp/myfile gvfs-info -a 'metadata::*' /tmp/myfile attributes: gvfs-set-attribute -t string /tmp/myfile 'metadata::mynote' 'Please remember to delete this file!' gvfs-info -a 'metadata::*' /tmp/myfile attributes: metadata::mynote: Please remember to delete this file! gvfs-move /tmp/myfile /tmp/newfile gvfs-info -a 'metadata::*' /tmp/newfile attributes: metadata::mynote: Please remember to delete this file!
12.2. XML Representation of a Storage Domain Example 12.1. An XML representation of a storage domain

Commands:
<storage_domain id="fabe0451-701f-4235-8f7e-e20e458819ed" href="/ovirt-engine/api/storagedomains/fabe0451-701f-4235-8f7e-e20e458819ed"> <name>data0</name> <link rel="permissions" href="/ovirt-engine/api/storagedomains/be24cd98-8e23-49c7-b425-1a12bd12abb0/permissions"/> <link rel="files" href="/ovirt-engine/api/storagedomains/be24cd98-8e23-49c7-b425-1a12bd12abb0/files"/> <type>data</type> <master>true</master> <storage> <type>nfs</type> <address>172.31.0.6</address> <path>/exports/RHEVX/images/0</path> </storage> <available>156766306304</available> <used>433791696896</used> <committed>617401548800</committed> <storage_format>v1</storage_format> <wipe_after_delete>true</wipe_after_delete> <warning_low_space_indicator>10</warning_low_space_indicator> <critical_space_action_blocker>5</critical_space_action_blocker> </storage_domain>
Chapter 1. Availability Red Hat provides a distribution of .NET that enables developers to create applications using the C#, Visual Basic, and F# languages and then deploy them on Red Hat Enterprise Linux (RHEL), Red Hat OpenShift Container Platform, or other platforms. A no-cost Red Hat Enterprise Linux Developer Subscription is available, including a full suite of tools for container development. For RHEL 8.9 and later and RHEL 9.3 and later, .NET 8.0 is available as the following RPMs in the AppStream repositories: Note The AppStream repositories are enabled by default in RHEL 8 and RHEL 9. dotnet-sdk-8.0 : Includes the .NET 8.0 Software Development Kit (SDK) and all the runtimes. aspnetcore-runtime-8.0 : Includes the .NET runtime and the ASP.NET Core runtime. Install this package to run ASP.NET Core-based applications. dotnet-runtime-8.0 : Includes only the .NET 8.0 runtime. Install this to use the runtime without the SDK. .NET 8.0 is available for aarch64 , ppc64le , s390x , and x86_64 architectures on RHEL 8, RHEL 9, and OpenShift Container Platform. Full instructions for installing .NET 8.0 on RHEL are available in the Getting started with .NET on RHEL 8 and Getting started with .NET on RHEL 9 guides.

Commands:
Chapter 10. Securing Kafka A secure deployment of Streams for Apache Kafka might encompass one or more of the following security measures: Encryption Streams for Apache Kafka supports Transport Layer Security (TLS), a protocol for encrypted communication. Communication is always encrypted between Streams for Apache Kafka components. To set up TLS-encrypted communication between Kafka and clients, you configure listeners in the Kafka custom resource. Authentication Kafka listeners use authentication to ensure a secure client connection to the Kafka cluster. Clients can also be configured for mutual authentication. Security credentials are created and managed by the Cluster and User Operator. Supported authentication mechanisms: mTLS authentication (on listeners with TLS-enabled encryption) SASL SCRAM-SHA-512 OAuth 2.0 token based authentication Custom authentication (supported by Kafka) Authorization Authorization controls the operations that are permitted on Kafka brokers by specific clients or users. Supported authorization mechanisms: Simple authorization using ACL rules OAuth 2.0 authorization (if you are using OAuth 2.0 token-based authentication) Open Policy Agent (OPA) authorization Custom authorization (supported by Kafka) Federal Information Processing Standards (FIPS) Streams for Apache Kafka is designed to run on FIPS-enabled OpenShift clusters to ensure data security and system interoperability. For more information about the NIST validation program and validated modules, see Cryptographic Module Validation Program on the NIST website.

Commands: