mtpti5iD/redhat-docs_dataset huggingface dataset:
34.4. Detecting and Recovering from Successive Crashed Nodes Red Hat JBoss Data Grid is unable to distinguish whether a node left the cluster because of a process or machine crash, or because of a network failure. If a single node exits the cluster, and if the value of numOwners is greater than 1, the cluster remains available and JBoss Data Grid attempts to create new replicas of the lost data. However, if additional nodes crash during this rebalancing process, it is possible that for some entries, all copies of its data have left the node and therefore cannot be recovered. The recommended way to protect the data grid against successive crashed nodes is to enable partition handling (see Section 34.6, "Configure Partition Handling" for instructions) and to set an appropriately high value for numOwners to ensure that even if a large number of nodes leave the cluster in rapid succession, JBoss Data Grid is able to rebalance the nodes to recover the lost data. Report a bug

Commands:
Chapter 43. Decision table use case An online shopping site lists the shipping charges for ordered items. The site provides free shipping under the following conditions: The number of items ordered is 4 or more and the checkout total is USD300 or more. Standard shipping is selected (4 or 5 business days from the date of purchase). The following are the shipping rates under these conditions: Table 43.1. For orders less than USD300 Number of items Delivery day Shipping charge in USD, N = Number of items 3 or fewer day 2nd day Standard 35 15 10 4 or more day 2nd day Standard N*7.50 N*3.50 N*2.50 Table 43.2. For orders more than USD300 Number of items Delivery day Shipping charge in USD, N = Number of items 3 or fewer day 2nd day Standard 25 10 N*1.50 4 or more day 2nd day Standard N*5 N*2 FREE These conditions and rates are shown in the following example spreadsheet decision table: Figure 43.1. Decision table for shipping charges In order for a decision table to be uploaded in Business Central, the table must comply with certain structure and syntax requirements, within an XLS or XLSX spreadsheet, as shown in this example. For more information, see Chapter 44, Defining spreadsheet decision tables .

Commands:
5.5. Resource Groups One of the most common elements of a cluster is a set of resources that need to be located together, start sequentially, and stop in the reverse order. To simplify this configuration, Pacemaker supports the concept of groups. You create a resource group with the following command, specifying the resources to include in the group. If the group does not exist, this command creates the group. If the group exists, this command adds additional resources to the group. The resources will start in the order you specify them with this command, and will stop in the reverse order of their starting order. You can also add a new resource to an existing group when you create the resource, using the following command. The resource you create is added to the group named group_name . You remove a resource from a group with the following command. If there are no resources in the group, this command removes the group itself. The following command lists all currently configured resource groups. The following example creates a resource group named shortcut that contains the existing resources IPaddr and Email . There is no limit to the number of resources a group can contain. The fundamental properties of a group are as follows. Resources are started in the order in which you specify them (in this example, IPaddr first, then Email ). Resources are stopped in the reverse order in which you specify them. ( Email first, then IPaddr ). If a resource in the group cannot run anywhere, then no resource specified after that resource is allowed to run. If IPaddr cannot run anywhere, neither can Email . If Email cannot run anywhere, however, this does not affect IPaddr in any way. Obviously as the group grows bigger, the reduced configuration effort of creating resource groups can become significant. 5.5.1. Group Options A resource group inherits the following options from the resources that it contains: priority , target-role , is-managed For information on resource options, see Table 5.3, "Resource Meta Options" .

Commands:
pcs resource group add group_name resource_id
pcs resource create resource_id standard:provider:type|type [resource_options] [op operation_action operation_options ] --group group_name
pcs resource group remove group_name resource_id
pcs resource group list
pcs resource group add shortcut IPaddr Email
Chapter 10. Error handling Errors in AMQ Python can be handled in two different ways: Catching exceptions Overriding event-handling functions to intercept AMQP protocol or connection errors 10.1. Catching exceptions All of the exceptions that AMQ Python throws inherit from the ProtonException class, which in turn inherits from the Python Exception class. The following example illustrates how to catch any exception thrown from AMQ Python: Example: API-specific exception handling try: # Something that might throw an exception except ProtonException as e: # Handle Proton-specific problems here except Exception as e: # Handle more general problems here } If you do not require API-specific exception handling, you only need to catch Exception , since ProtonException inherits from it. 10.2. Handling connection and protocol errors You can handle protocol-level errors by overriding the following messaging_handler methods: on_transport_error(event) on_connection_error(event) on_session_error(event) on_link_error(event) These event-handling functions are called whenever there is an error condition with the specific object that is in the event. After calling the error handler, the appropriate close handler is also called. Note Because the close handlers are called in the event of any error, only the error itself needs to be handled within the error handler. Resource cleanup can be managed by close handlers. If there is no error handling that is specific to a particular object, it is typical to use the general on_error handler and not have a more specific handler. Note When reconnect is enabled and the remote server closes a connection with the amqp:connection:forced condition, the client does not treat it as an error and thus does not fire the on_connection_error handler. The client instead begins the reconnection process.

Commands:
try: # Something that might throw an exception except ProtonException as e: # Handle Proton-specific problems here except Exception as e: # Handle more general problems here }
Chapter 8. Ceph debugging and logging configuration As a storage administrator, you can increase the amount of debugging and logging information in cephadm to help diagnose problems with Red Hat Ceph Storage. Prerequisites Red Hat Ceph Storage software is installed. Additional resources See all the Red Hat Ceph Storage Ceph debugging and logging configuration options in Ceph debugging and loggin configuration options for specific option descriptions and usage. For more information about troubleshooting cephadm , see Cephadm troubleshooting in the Red Hat Ceph Storage Administration Guide . For more information about cephadm logging, see Cephadm operations in the Red Hat Ceph Storage Administration Guide .

Commands:
12.19. JPA Translator The JPA translator, known by the type name jpa2, can reverse a JPA object model into a relational model, which can then be integrated with other relational or non-relational sources. The JPA Translator currently has no import or execution properties. JPA source procedures may be created using the teiid_rel:native-query extension. The procedure invokes the native-query similar to an native procedure call with the benefits that the query is predetermined and that result column types are known, rather than requiring the use of ARRAYTABLE or similar functionality. Warning This feature is turned off by default because of the security risk this exposes to execute any command against the source. To enable this feature, set the execution property called SupportsDirectQueryProcedure to true. Note By default the name of the procedure that executes the queries directly is native. Override the execution property DirectQueryProcedureName to change it to another name. The JPA translator provides a procedure to execute any ad-hoc JPA-QL query directly against the source without Teiid parsing or resolving. Since the metadata of this procedure's results are not known to Teiid, they are returned as object array. User can use ARRAYTABLE can be used construct tabular output for consumption by client applications. Teiid exposes this procedure with a query structure. In this select query, the "search" keyword is followed by a query statement: In this delete query, the the "delete" keyword is followed by JPA-QL for a delete operation. In this sample, the "update" keyword must be followed by JPA-QL for the update statement. In this create query, the create operation sends "create" word as a marker and send the entity as the first parameter:

Commands:
SELECT x.* FROM (call jpa_source.native('search;FROM Account')) w, ARRAYTABLE(w.tuple COLUMNS "id" string , "type" string, "name" String) AS x
SELECT x.* FROM (call jpa_source.native('delete;<jpa-ql>')) w, ARRAYTABLE(w.tuple COLUMNS "updatecount" integer) AS x
SELECT x.* FROM (call jpa_source.native('update;<jpa-ql>')) w, ARRAYTABLE(w.tuple COLUMNS "update_count" integer) AS x
SELECT x.* FROM (call jpa_source.native('create;', <entity>)) w, ARRAYTABLE(w.tuple COLUMNS "update_count" integer) AS x
4.4. Supported Hardware Security Modules The following table lists Hardware Security Modules (HSM) supported by Red Hat Certificate System: HSM Firmware Appliance Software Client Software nCipher nShield Connect XC (High) nShield_HSM_Firmware-12.72.1 12.71.0 SecWorld_Lin64-12.71.0 Thales TCT Luna Network HSM Luna-T7 lunafw_update-7.11.1-4 7.11.0-25 610-500244-001_LunaClient-7.11.1-5

Commands:
3.12. Creating a Virtual Disk To ensure that a newly created virtual machine has access to persistent storage you must create and attach a disk. This Ruby example creates and attaches a virtual storage disk to a virtual machine. # Locate the virtual machines service and use it to find the virtual # machine: vms_service = connection.system_service.vms_service vm = vms_service.list(search: 'name=myvm')[0] # Locate the service that manages the disk attachments of the virtual # machine: disk_attachments_service = vms_service.vm_service(vm.id).disk_attachments_service # Use the "add" method of the disk attachments service to add the disk. # Note that the size of the disk, the `provisioned_size` attribute, is # specified in bytes, so to create a disk of 10 GiB the value should # be 10 * 2^30. disk_attachment = disk_attachments_service.add( OvirtSDK4::DiskAttachment.new( disk: { name: 'mydisk', description: 'My disk', format: OvirtSDK4::DiskFormat::COW, provisioned_size: 10 * 2**30, storage_domains: [{ name: 'mydata' }] }, interface: OvirtSDK4::DiskInterface::VIRTIO, bootable: false, active: true ) ) # Wait until the disk status is OK: disks_service = connection.system_service.disks_service disk_service = disks_service.disk_service(disk_attachment.disk.id) loop do sleep(5) disk = disk_service.get break if disk.status == OvirtSDK4::DiskStatus::OK end For more information, see DiskAttachmentsService:add .

Commands:
Locate the virtual machines service and use it to find the virtual machine: vms_service = connection.system_service.vms_service vm = vms_service.list(search: 'name=myvm')[0] Locate the service that manages the disk attachments of the virtual machine: disk_attachments_service = vms_service.vm_service(vm.id).disk_attachments_service Use the "add" method of the disk attachments service to add the disk. Note that the size of the disk, the `provisioned_size` attribute, is specified in bytes, so to create a disk of 10 GiB the value should be 10 * 2^30. disk_attachment = disk_attachments_service.add( OvirtSDK4::DiskAttachment.new( disk: { name: 'mydisk', description: 'My disk', format: OvirtSDK4::DiskFormat::COW, provisioned_size: 10 * 2**30, storage_domains: [{ name: 'mydata' }] }, interface: OvirtSDK4::DiskInterface::VIRTIO, bootable: false, active: true ) ) Wait until the disk status is OK: disks_service = connection.system_service.disks_service disk_service = disks_service.disk_service(disk_attachment.disk.id) loop do sleep(5) disk = disk_service.get break if disk.status == OvirtSDK4::DiskStatus::OK end
Chapter 7. Login Troubleshoot login issues. 7.1. Issue - Logging in to the automation controller UI results in "Invalid username or password. Please try again." When you try to log in to the automation controller UI, the login fails and you see the error message: "Invalid username or password. Please try again.". One reason this could be happening is if the value for Maximum number of simultaneous logged in sessions is 0 . The Maximum number of simultaneous logged in sessions value determines the maximum number of sessions allowed per user per device. If this value is 0 , no users can log in to automation controller. The default value is -1 , which disables the maximum sessions allowed. This means that you can have as many sessions without an imposed limit. Procedure As root user, run the following command from the command line to set the SESSIONS_PER_USER variable to -1 which disables the maximum sessions allowed: # echo "settings.SESSIONS_PER_USER = -1" | awx-manage shell_plus --quiet Verification Verify that you can log in successfully to automation controller. Additional resources For more information about installing and using the controller node CLI, see AWX Command Line Interface and AWX manage utility . For more information about session limits, see Session Limits in the Automation Controller Administration Guide.

Commands:
echo "settings.SESSIONS_PER_USER = -1" | awx-manage shell_plus --quiet
Chapter 1. Upgrading Red Hat build of Keycloak Red Hat build of Keycloak is based on the Keycloak project, which enables you to secure your web applications by providing Web SSO capabilities based on popular standards such as OpenID Connect, OAuth 2.0, and SAML 2.0. The Red Hat build of Keycloak server acts as an OpenID Connect or SAML-based identity provider (IdP), allowing your enterprise user directory or third-party IdP to secure your applications by using standards-based security tokens. This guide applies to version 22.0.13, which is a minor version of Red Hat build of Keycloak. To upgrade Red Hat build of Keycloak to version 22.0.13, use the following procedures in this order: Upgrade the Red Hat build of Keycloak server Upgrade Red Hat build of Keycloak adapters

Commands:
10.5.34. HostnameLookups HostnameLookups can be set to on , off , or double . If HostnameLookups is set to on , the server automatically resolves the IP address for each connection. Resolving the IP address means that the server makes one or more connections to a DNS server, adding processing overhead. If HostnameLookups is set to double , the server performs a double-reverse DNS look up adding even more processing overhead. To conserve resources on the server, HostnameLookups is set to off by default. If hostnames are required in server log files, consider running one of the many log analyzer tools that perform the DNS lookups more efficiently and in bulk when rotating the Web server log files.

Commands:
Chapter 12. Log file locations During the deployment process, progress information is displayed in the web browser. This information is also stored on the local file system so that the information logged can be archived or reviewed at a later date, for example, if the web browser stops responding or is closed before the information has been reviewed. The log file for the Web Console based deployment process (documented in Section 8.1, "Configuring Red Hat Gluster Storage on a single node" ) is stored in the /var/log/cockpit/ovirt-dashboard/gluster-deployment.log file by default. The log files for the Hosted Engine setup portion of the deployment process (documented in Section 8.2, "Deploy the Hosted Engine on a single node using the Web Console" ) are stored in the /var/log/ovirt-hosted-engine-setup directory, with file names of the form ovirt-hosted-engine-setup-<date>.log .

Commands:
5.2. Transport Security Properties The following properties can be set when defining the transport security setting for a transport. Table 5.1. SSL Properties Setting Description Default Value mode Options are: disabled , login , or enabled . If set to disabled , no transport or message level encryption will be used. If set to login , only the login traffic will be encrypted at a message level using 128 bit AES with an ephemeral DH key exchange. This only applies to the teiid transport. (No other configuration values are required in this mode.) If set to enabled , traffic will be encrpyted using SSL according to the configuration properties below. teiid transport clients must connect using SSL with the mms protocol. ODBC pg transport clients may optionally use SSL. login keystore/name The filename of the keystore that contains the private key of the server. The file name can be specified relative to the JBoss Data Virtualization deployer classloader or by absolute file system path. A typical installation would place the keystore file in the EAP_HOME/MODE /configuration directory. cert.keystore keystore/password The password used to access the keystore. keystore/type The keystore type created by the keytool. JKS keystore/key-alias The keystore key-alias created by the keytool. ssl-protocol Type of SSL protocol to be used. TLSv1 keymanagement-algorithm Type of key algorithm to be used. truststore/name If authentication-mode is set to 2-way , this property must be provided. This is the truststore that contains the public key for the client. Depending on how you created the keystore and truststores, this may be the same as the file specified for keystore/name . cert.truststore truststore/password The password used to access the truststore. authentication-mode Options are 1-way , 2-way and anonymous . 1-way enabled-cipher-suites A comma separated list of cipher suites allowed for encryption between the client and server. The values must be supported by the JVM, otherwise the SSL connections will fail. Note Both anonymous SSL and login only encryption are configured to use 128 bit AES encryption by default. By default, 1-way and 2-way SSL allow for cipher suite negotiation based upon the default cipher suites supported by the respective Java platforms of the client and server. Administrators can restrict the cipher suites used for encryption by setting the enabled-cipher-suites property. This defaults to all supported cipher suites for the virtual machine. Note You will typically use the CLI to modify the transport configuration. Warning Red Hat recommends to encrypt passwords in production systems. Refer to the JBoss Enterprise Application Platform Security Guide for information about the Password Vault .

Commands:
3.4. Virtual Disk Performance Options Several virtual disk related options are available to your guest virtual machines during installation that can impact performance. The following image shows the virtual disk options available to your guests. The cache mode, IO mode, and IO tuning can be selected in the Virtual Disk section in virt-manager . Set these parameters in the fields under Performance options , as shown in the following image: Figure 3.8. Virtual Disk Performance Options Important When setting the virtual disk performance options in virt-manager , the virtual machine must be restarted for the settings to take effect. See Section 7.3, "Caching" and Section 7.4, "I/O Mode" for descriptions of these settings and instructions for editing these settings in the guest XML configuration.

Commands:
Index B boot menu customization for BIOS systems, Systems with BIOS Firmware customization for UEFI systems, Systems with UEFI Firmware G grub2 custom configuration, Systems with UEFI Firmware I ISO image creation, Creating Custom Boot Images ISO images extracting, Extracting Red Hat Enterprise Linux Boot Images isolinux custom configuration, Systems with BIOS Firmware M MD5sum implanting into ISO images, Creating Custom Boot Images P product.img creating, Creating a product.img File

Commands:
4.255. ql2500-firmware 4.255.1. RHBA-2011:1660 - ql2500-firmware bug fix update An updated ql2500-firmware package that fixes multiple bugs and adds various enhancements is now available for Red Hat Enterprise Linux 6. The ql2500-firmware package provides the firmware required to run the QLogic 2500 Series of mass storage adapters. This update upgrades the ql2500 firmware to upstream version 5.06.02, which provides a number of bug fixes and enhancements over the version. (BZ# 730818 ) All users of QLogic 2500 Series Fibre Channel adapters are advised to upgrade to this updated package, which fixes these bugs and adds these enhancements.

Commands:
Chapter 22. Making a High-availability and Disaster Recovery Plan Part of running a Directory Server deployment efficiently is planning for that worst case scenario. This chapter covers general principles for drafting a disaster recovery plan and highlights features in Directory Server that can be used to aide in disaster recovery. Disaster recovery is a way of planning and implementing a smooth transition from one operating environment to another environment whenever there is some sort of catastrophic failure. A disaster recovery plan for Directory Server may be part of a larger business continuity plan or it could be a standalone plan specifically for an interruption in directory services. Note This chapter covers very general concepts for disaster recovery. Disaster recovery can be a very complex and detail-specific thing. Consider using a professional service to design, maintain, and test any disaster recovery plan for sensitive or mission-critical services, like Red Hat Directory Server. 22.1. Identifying Potential Scenarios The first step is identifying what potential issues you may encounter, what services will be affected, and what responses you should take. In the Red Hat Directory Server Deployment Guide , administrators made a site survey of their existing and proposed infrastructure to determine what kind of directory to design. Do something similar for disaster planning; as in Table 22.1, "Disaster Scenarios and Responses" , identify where your data infrastructure is, determine what the affect of losing that component is, and look at potential ideal responses. Table 22.1. Disaster Scenarios and Responses Scenario Effects on Infrastructure Ideal Response Data corruption Through software or hardware failure (or through a malicious attack), the data at one site or on one server could be corrupted. If that corrupted server is a supplier in multi-supplier replication, then the corruption can quickly be propagated throughout the deployment. An isolated server should be available with access to the most recent backup of uncorrupted data. When a problem is detected, replication can be suspended on the regular infrastructure, and this server can be brought online to reinitialize the suppliers with good data. Natural disasters and other mass events Natural disasters can take an entire office or data center offline, even through something as simple as a long-term power outage. Directory operations can be transferred to a mirrored site at another physical location, with the same data. Server or machine loss A single machine could fail. Another machine, with the same data, can assume the lost machine's place.

Commands: