mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 2. New Features This section describes new features introduced in Red Hat OpenShift Data Foundation 4.9. User interface, product component, and documentation rebranding OpenShift Container Storage, based on the open source Ceph technology, has expanded its scope and foundational role in a containerized, hybrid cloud environment since its introduction. To better reflect these foundational and infrastructure distinctives, OpenShift Container Storage is now OpenShift Data Foundation . OpenShift Data Foundation 4.9 now includes: Improved dashboards for viewing all storage system status and metrics Easy to use wizard for creating storage system Rebranded user interface and documentation To view documentation for OpenShift Container Storage version 4.8 and earlier, see Product Documentation for Red Hat OpenShift Container Storage . To update from OpenShift Container Storage 4.8 to OpenShift Data Foundation 4.9, you must freshly install the OpenShift Data Foundation operator from the OpenShift Container Platform Operator Hub. This fresh operator installation upgrades OpenShift Container Storage version 4.8 and all its components to OpenShift Data Foundation version 4.9. For more information, see Upgrading to OpenShift Data Foundation . Multicloud Object Gateway bucket replication Data replication from one Multicloud Object Gateway (MCG) bucket to another MCG bucket provides higher resiliency and better collaboration options. These buckets can be either data buckets or namespace buckets backed by any supported storage solutions. For more information, see Multicloud Object Gateway bucket replication . Ability to view pool compression metrics In this release, you can view the pool compression metrics, which provide information about the amount of storage space saved, the effectiveness of pool compression when it is enabled, and its impact on capacity consumption. The per-pool metrics available with this release provide information that enables you to reduce cost and consume data more efficiently. Also, you can disable compression if it is not effective. For more information, see Pool metrics . Automated scaling of Multicloud Object Gateway endpoint pods You can use the automated scaling of Multicloud Object Gateway endpoint pods feature to automate the resource adjustments based on increases or decreases to the load. This provides better performance and serviceability to manage your production resources for your S3 load. For more information, see Automatic scaling of Multicloud Object Gateway endpoints . Deployment and monitoring layer for pluggable external storage (IBM FlashSystem(R)) In this release, you can connect to and monitor IBM FlashSystem(R) storage using OpenShift Data Foundation. OpenShift Data Foundation extends IBM FlashSystem to file and object storage while providing a single view for both the underlying storage and OpenShift Data Foundation data layer. For more information, see Deploy OpenShift Data Foundation using IBM FlashSystem .

Commands:
14.4.5. Server Security Mode (User-Level Security) Server security mode was previously used when Samba was not capable of acting as a domain member server. Note It is highly recommended to not use this mode since there are numerous security drawbacks. In smb.conf , the following directives enable Samba to operate in server security mode:

Commands:
[GLOBAL] encrypt passwords = Yes security = server password server = "NetBIOS_of_Domain_Controller"
12.7. Updating an attribute This section describes how to update an attribute using the command line and the web console. 12.7.1. Updating an Attribute Using the Command Line Use the dsconf utility to update an attribute entry. For example: For further details about object class definitions, see Section 12.1.2, "Object Classes" . 12.7.2. Updating an Attribute Using the Web Console To update an attribute using the web console: Open the Directory Server user interface in the web console. See Section 1.4, "Logging Into Directory Server Using the Web Console" . Select the instance. Select Schema Attributes . Click the Choose Action button to the attribute you want to edit. Select Edit Attribute . Update the parameters. Click Save .

Commands:
dsconf -D "cn=Directory Manager" ldap://server.example.com schema attributetypes replace dateofbirth --desc="Employee birthday" --syntax="1.3.6.1.4.1.1466.115.121.1.15" --single-value --x-origin="Example defined"
2. Kernel The kernel shipped in Red Hat Enterprise Linux 6.1 includes several hundred bug fixes for and enhancements to the Linux kernel. For details concerning every bug fixed in and every enhancement added to the kernel for this release, refer to the kernel chapter in the Red Hat Enterprise Linux 6.1 Technical Notes. Control Groups Control groups are a feature of the Linux kernel introduced in Red Hat Enterprise Linux 6. Each control group is a set of tasks on a system that have been grouped together to better manage their interaction with system hardware. Control groups can be tracked to monitor the system resources that they use. Additionally, system administrators can use control group infrastructure to allow or to deny specific control groups access to system resources such as memory, CPUs (or groups of CPUs), networking, I/O, or the scheduler. Red Hat Enterprise Linux 6.1 introduces many improvements and updates to control groups, including the ability to throttle block device Input/Output (I/O) to a particular device, either by bytes per second or I/O Per Second (IOPS). Additionally, integration with libvirt and other userspace tools is provided by the new ability to create hierarchical block device control groups. The new block device control group tunable group_idle , provides better throughput with control groups while maintaining fairness. Red Hat Enterprise Linux 6.1 also introduces the new autogroup feature, reducing latencies and allowing for more interactive tasks during CPU intensive workloads. This cgsnapshot tool, providing the ability to take a snapshot of the current control group configuration. Note Control Groups and other resource management features are discussed in detail in the Red Hat Enterprise Linux 6 Resource Management Guide Networking updates Red Hat Enterprise Linux 6.1 introduces support for Receive Packet Steering (RPS) and Receive Flow Steering (RFS). Receive Packet Steering allows incoming network packets to be processed in parallel over multiple CPU cores. Receive Flow Steering chooses the optimal CPU to process network data intended for a specific application. kdump kdump is an advanced crash dumping mechanism. When enabled, the system is booted from the context of another kernel. This second kernel reserves a small amount of memory, and its only purpose is to capture the core dump image in case the system crashes. Red Hat Enterprise Linux 6.1 introduces the kernel message dumper, which is called when a kernel panic occurs. The kernel message dumper provides easier crash analysis and allows 3rd party kernel message logging to alternative targets. Performance updates and improvements The kernel in Red Hat Enterprise Linux 6.1 provides the following notable performance improvements: Updates and improvements to Transparent Huge Pages (THP) support Updates to perf_event , adding the new perf lock feature to better analyze lock events. kprobes jump optimization, reducing overhead and enhancing SystemTap performance. Updates to i7300_edac and i7core_edac , providing support for monitoring of memory errors on motherboards using Intel 7300 chipset

Commands:
Chapter 15. Integrating with Apache ActiveMQ Overview If you are using Apache ActiveMQ as your JMS provider, the JNDI name of your destinations can be specified in a special format that dynamically creates JNDI bindings for queues or topics. This means that it is not necessary to configure the JMS provider in advance with the JNDI bindings for your queues or topics. The initial context factory The key to integrating Apache ActiveMQ with JNDI is the ActiveMQInitialContextFactory class. This class is used to create a JNDI InitialContext instance, which you can then use to access JMS destinations in the JMS broker. Example 15.1, "SOAP/JMS WSDL to connect to Apache ActiveMQ" shows SOAP/JMS WSDL extensions to create a JNDI InitialContext that is integrated with Apache ActiveMQ. Example 15.1. SOAP/JMS WSDL to connect to Apache ActiveMQ In Example 15.1, "SOAP/JMS WSDL to connect to Apache ActiveMQ" , the Apache ActiveMQ client connects to the broker port located at tcp://localhost:61616 . Looking up the connection factory As well as creating a JNDI InitialContext instance, you must specify the JNDI name that is bound to a javax.jms.ConnectionFactory instance. In the case of Apache ActiveMQ, there is a predefined binding in the InitialContext instance, which maps the JNDI name ConnectionFactory to an ActiveMQConnectionFactory instance. Example 15.2, "SOAP/JMS WSDL for specifying the Apache ActiveMQ connection factory" shaows the SOAP/JMS extension element for specifying the Apache ActiveMQ connection factory. Example 15.2. SOAP/JMS WSDL for specifying the Apache ActiveMQ connection factory Syntax for dynamic destinations To access queues or topics dynamically, specify the destination's JNDI name as a JNDI composite name in either of the following formats: QueueName and TopicName are the names that the Apache ActiveMQ broker uses. They are not abstract JNDI names. Example 15.3, "WSDL port specification with a dynamically created queue" shows a WSDL port that uses a dynamically created queue. Example 15.3. WSDL port specification with a dynamically created queue When the application attempts to open the JMS connection, Apache ActiveMQ will check to see if a queue with the JNDI name greeter.request.queue exists. If it does not exist, it will create a new queue and bind it to the JNDI name greeter.request.queue .

Commands:
<soapjms:jndiInitialContextFactory> org.apache.activemq.jndi.ActiveMQInitialContextFactory </soapjms:jndiInitialContextFactory> <soapjms:jndiURL>tcp://localhost:61616</soapjms:jndiURL>
<soapjms:jndiConnectionFactoryName> ConnectionFactory </soapjms:jndiConnectionFactoryName>
dynamicQueues/ QueueName dynamicTopics/ TopicName
<service name="JMSService"> <port binding="tns:GreeterBinding" name="JMSPort"> <jms:address jndiConnectionFactoryName="ConnectionFactory" jndiDestinationName="dynamicQueues/greeter.request.queue" > <jms:JMSNamingProperty name="java.naming.factory.initial" value="org.activemq.jndi.ActiveMQInitialContextFactory" /> <jms:JMSNamingProperty name="java.naming.provider.url" value="tcp://localhost:61616" /> </jms:address> </port> </service>
10.4. Problems After Installation 10.4.1. Trouble With the Graphical GRUB Screen on an x86-based System? If you are experiencing problems with GRUB, you may need to disable the graphical boot screen. To do this, become the root user and edit the /boot/grub/grub.conf file. Within the grub.conf file, comment out the line which begins with splashimage by inserting the # character at the beginning of the line. Press Enter to exit the editing mode. Once the boot loader screen has returned, type b to boot the system. Once you reboot, the grub.conf file is reread and any changes you have made take effect. You may re-enable the graphical boot screen by uncommenting (or adding) the above line back into the grub.conf file.

Commands:
6.2. VDB Definition: The VDB Element Attributes name The name of the VDB. The VDB name referenced through the driver or datasource during the connection time. version The version of the VDB (should be an positive integer). This determines the deployed directory location (see Name), and provides an explicit versioning mechanism to the VDB name. Property Elements cache-metadata Can be "true" or "false". If "false", JBoss Data Virtualization will obtain metadata once for every launch of the VDB. "true" will save a file containing the metadata into the EAP_HOME / MODE /data directory. Defaults to "false" for -vdb.xml deployments otherwise "true". query-timeout Sets the default query timeout in milliseconds for queries executed against this VDB. 0 indicates that the server default query timeout should be used. Defaults to 0. Will have no effect if the server default query timeout is set to a lesser value. Note that clients can still set their own timeouts that will be managed on the client side. lib Set to a list of modules for the VDB classpath for user defined function loading. See also Support for Non-Pushdown User Defined Functions in Red Hat JBoss Data Virtualization Development Guide: Server Development . security-domain Set to the security domain to use if a specific security domain is applicable to the VDB. Otherwise the security domain list from the transport will be used. Important An administrator needs to configure a matching "custom-security" login module in the standalone.xml configuration file before the VDB is deployed. connection.XXX This is for use by the ODBC transport and OData. They use it to set the default connection/execution properties. Note that the properties are set on the connection after it has been established. authentication-type Authentication type of configured security domain. Allowed values currently are (GSS, USERPASSWORD). The default is set on the transport (typically USERPASSWORD). password-pattern Regular expression matched against the connecting user's name that determines if USERPASSWORD authentication is used. password-pattern Takes precedence of over authentication-type. The default is authentication-type. gss-pattern Regular expression matched against the connecting user's name that determines if GSS authentication is used. gss-pattern Takes precedence of over password-pattern. The default is password-pattern. model.visible Used to override the visibility of imported vdb models, where model is the name of the imported model.. include-pg-metadata By default, PG metadata is always added to VDB unless System Properties set property org.teiid.addPGMetadata to false. This property enables adding PG metadata per VDB. Please note that if you are using ODBC to access your VDB, the VDB must include PG metadata. lazy-invalidate By default TTL expiration will be invalidating. Setting lazy-invalidate to true makes ttl refreshes non-invalidating.

Commands:
<property name="security-domain" value="custom-security" />
<property name="connection.partialResultsMode" value="true" />
Chapter 2. Supported versions of Windows Server You can establish a trust relationship with Active Directory (AD) forests that use the following forest and domain functional levels: Forest functional level range: Windows Server 2012 - Windows Server 2016 Domain functional level range: Windows Server 2012 - Windows Server 2016 Identity Management (IdM) supports establishing a trust with Active Directory domain controllers running the following operating systems: Windows Server 2022 (RHEL 9.1 and later) Windows Server 2019 Windows Server 2016 Windows Server 2012 R2 Windows Server 2012 Important Identity Management (IdM) does not support establishing trust to Active Directory with Active Directory domain controllers running Windows Server 2008 R2 or earlier versions. RHEL IdM requires SMB encryption when establishing the trust relationship, which is only supported in Windows Server 2012 or later.

Commands:
Chapter 2. Compiling Protobuf Schema Data Grid uses the ProtoStream API to store data as Protobuf-encoded entries. Protobuf is a language-neutral format that allows clients to create and retrieve entries in remote caches using both Hot Rod and REST endpoints. 2.1. Compiling Protobuf schema on Red Hat Enterprise Linux (RHEL) Compile Protobuf schema, .proto files, into C++ header and source files to describe your data to Data Grid. Prerequisites Install the Protobuf library and protobuf-devel package. Procedure Set the LD_LIBRARY_PATH environment variable, if it is not already set. Compile Protobuf schema for the Hot Rod C++ client as required. HR_PROTO_EXPORT is a macro that the Hot Rod C++ client expands when it compiles the Protobuf schema. Register your Protobuf schema with Data Grid if you plan to use queries. Additional resources Registering Protobuf Schemas 2.2. Compiling Protobuf schema on Microsoft Windows Compile Protobuf schema, .proto files, into C++ header and source files to describe your data to Data Grid. Procedure Open a command prompt to the installation directory for the Hot Rod C++ client. Compile Protobuf schema for the Hot Rod C++ client as required. HR_PROTO_EXPORT is a macro that the Hot Rod C++ client expands when it compiles the Protobuf schema. Register your Protobuf schema with Data Grid if you plan to use queries. Additional resources Registering Protobuf Schemas

Commands:
yum install protobuf yum install protobuf-devel
export LD_LIBRARY_PATH=USDLD_LIBRARY_PATH:/opt/lib64
/bin/protoc --cpp_out dllexport_decl=HR_PROTO_EXPORT:/path/to/output/ USDFILE
bin\protoc --cpp_out dllexport_decl=HR_PROTO_EXPORT:path\to\output\ USDFILE
15.14. Removing the Changelog The changelog is a record of all modifications on a given replica that the supplier uses to replay these modifications to replicas on consumer servers (or suppliers in the case of multi-supplier replication). If a supplier server goes offline, it is important to be able to delete the changelog because it no longer holds a true record of all modifications and, as a result, should not be used as a basis for replication. A changelog can be effectively deleted by deleting the log file. 15.14.1. Removing the Changelog using the Command Line To remove the changelog from the supplier server: Verify whether replication is disabled for all suffixes: Remove the changelog: 15.14.2. Removing the Changelog using the Web Console To remove the changelog from the supplier server: Open the Directory Server user interface in the web console. See Section 1.4, "Logging Into Directory Server Using the Web Console" . Select the instance. Open the Replication menu, and select the Replication Changelog entry. Click Delete Changelog .

Commands:
dsconf -D "cn=Directory Manager" ldap://supplier.example.com replication list There are no replicated suffixes
dsconf -D "cn=Directory Manager" ldap://supplier.example.com replication delete-changelog
5.4. Configuring Fence Devices Configuring fence devices for the cluster consists of selecting one or more fence devices and specifying fence-device-dependent parameters (for example, name, IP address, login, and password). To configure fence devices, follow these steps: Click Fence Devices . At the bottom of the right frame (labeled Properties ), click the Add a Fence Device button. Clicking Add a Fence Device causes the Fence Device Configuration dialog box to be displayed (refer to Figure 5.4, "Fence Device Configuration" ). Figure 5.4. Fence Device Configuration At the Fence Device Configuration dialog box, click the drop-down box under Add a New Fence Device and select the type of fence device to configure. Specify the information in the Fence Device Configuration dialog box according to the type of fence device. Refer to Appendix B, Fence Device Parameters for more information about fence device parameters. Click OK . Choose File => Save to save the changes to the cluster configuration.

Commands:
function::target Name function::target - Return the process ID of the target process Synopsis Arguments None Description This function returns the process ID of the target process. This is useful in conjunction with the -x PID or -c CMD command-line options to stap. An example of its use is to create scripts that filter on a specific process. -x <pid> target returns the pid specified by -x target returns the pid for the executed command specified by -c

Commands:
target:long()
Chapter 123. AclRuleTransactionalIdResource schema reference Used in: AclRule The type property is a discriminator that distinguishes use of the AclRuleTransactionalIdResource type from AclRuleTopicResource , AclRuleGroupResource , AclRuleClusterResource . It must have the value transactionalId for the type AclRuleTransactionalIdResource . Property Property type Description type string Must be transactionalId . name string Name of resource for which given ACL rule applies. Can be combined with patternType field to use prefix pattern. patternType string (one of [prefix, literal]) Describes the pattern used in the resource field. The supported types are literal and prefix . With literal pattern type, the resource field will be used as a definition of a full name. With prefix pattern type, the resource name will be used only as a prefix. Default value is literal .

Commands:
8.92. libnl 8.92.1. RHBA-2013:1730 - libnl bug fix update Updated libnl packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The libnl packages contain a convenience library to simplify using the Linux kernel's Netlink sockets interface for network manipulation. Bug Fixes BZ# 682240 When a domain was started using the libvirt client libraries and utilities, a memory leak was triggered from the libnl library because libnl continued to use memory that was no longer in use. With this update, memory leaks in libnl are fixed, and libnl releases memory after it completes its usage. BZ# 689559 Prior to this update, libnl's error handling made generous use of the strerror() function. Nevertheless, the strerror() function was not threadsafe, and it was possible for multiple threads in an application to call libnl. With this update, all the occurrences of strerror() are replaced with a call to the strerror_r() function that puts the message into a thread-local static buffer. BZ# 953339 When the max_vfs parameter of the igb module, which allocates the maximum number of Virtual Functions, was set to any value greater than 50,50 on a KVM (Kernel-based Virtual Machine) host, the guest failed to start with the following error messages: error : virNetDevParseVfConfig:1484 : internal error missing IFLA_VF_INFO in netlink response error : virFileReadAll:457 : Failed to open file '/var/run/libvirt/qemu/eth0_vf0': No such file or directory error : virFileReadAll:457 : Failed to open file '/var/run/libvirt/qemu/eth1_vf0': No such file or directory This update increases the default receive buffer size to allow receiving of Netlink messages that exceed the size of a memory page. Thus, guests are able to start on the KVM host, and error messages no longer occur in the described scenario. Users of libnl are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 5. Deploying Ceph Once the pre-requisites and initial tuning are complete, consider deploying a Ceph cluster. When deploying a production cluster, Red Hat recommends setting up the initial monitor cluster and enough OSD nodes to reach an active + clean state. For details, see the Installing a Red Hat Ceph Storage Cluster section in the Red Hat Ceph Storage 4 Installation Guide. Then, install the Ceph CLI client on an administration node. For details, see the Installing the Ceph Command Line Interface section in the Red Hat Ceph Storage 4 Installation Guide. Once the initial cluster is running, consider adding the settings in the following sections to the Ceph configuration file.

Commands:
29.3. TCPGOSSIP Configuration Options The following TCPGOSSIP specific properties may be configured: initial_hosts - Comma delimited list of hosts to be contacted for initial membership. reconnect_interval - Interval (in milliseconds) by which a disconnected node attempts to reconnect to the Gossip Router. sock_conn_timeout - Max time (in milliseconds) allowed for socket creation. Defaults to 1000 . sock_read_timeout - Max time (in milliseconds) to block on a read. A value of 0 will block forever. Report a bug

Commands: