mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 4. Configuring Hammer The default location for global hammer configuration is: /etc/hammer/cli_config.yml for general hammer settings /etc/hammer/cli.modules.d/ for CLI module configuration files You can set user specific directives for hammer (in ~/.hammer/cli_config.yml ) as well as for CLI modules (in respective .yml files under ~/.hammer/cli.modules.d/ ). To see the order in which configuration files are loaded, as well as versions of loaded modules, use: Note Loading configuration for many CLI modules can slow down the execution of hammer commands. In such a case, consider disabling CLI modules that are not regularly used. Apart from saving credentials as described in Chapter 3, Hammer authentication , you can set several other options in the ~/.hammer/ configuration directory. For example, you can change the default log level and set log rotation with the following directives in ~/.hammer/cli_config.yml . These directives affect only the current user and are not applied globally. Similarly, you can configure user interface settings. For example, set the number of entries displayed per request in the Hammer output by changing the following line: This setting is an equivalent of the --per-page Hammer option. 4.1. Setting a default organization and location context Many hammer commands are organization specific. You can set a default organization and location for hammer commands so that you do not have to specify them every time with the --organization and --location options. Specifying a default organization is useful when you mostly manage a single organization, as it makes your commands shorter. However, when you switch to a different organization, you must use hammer with the --organization option to specify it. Procedure Set a default organization: You can find the name of your organization with the hammer organization list command. Optional: Set a default location: You can find the name of your location with the hammer location list command. Verification Review the currently specified default settings: 4.2. Increasing the logging level for Hammer You can find the log in ~/.hammer/log/hammer.log . Procedure In /etc/hammer/cli_config.yml , set the :log_level: option to debug :

Commands:
hammer -d --version
:log_level: 'warning' :log_size: 5 #in MB
:per_page: 30
hammer defaults add --param-name organization --param-value "Your_Organization"
hammer defaults add --param-name location --param-value "Your_Location"
hammer defaults list
:log_level: 'debug'
10.2.2.5. Error Documents To use a hard-coded message with the ErrorDocument directive, the message should be enclosed in a pair of double quotation marks " , rather than just preceded by a double quotation mark as required in Apache HTTP Server 1.3. For example, the following is a sample Apache HTTP Server 1.3 directive: To migrate an ErrorDocument setting to Apache HTTP Server 2.0, use the following structure: Note the trailing double quote in the ErrorDocument directive example. For more on this topic, refer to the following documentation on the Apache Software Foundation's website: http://httpd.apache.org/docs-2.0/mod/core.html#errordocument

Commands:
ErrorDocument 404 "The document was not found
ErrorDocument 404 "The document was not found "
4.2. Logging Into the Piranha Configuration Tool When configuring LVS, you should always begin by configuring the primary router with the Piranha Configuration Tool . To do this,verify that the piranha-gui service is running and an administrative password has been set, as described in Section 2.2, "Setting a Password for the Piranha Configuration Tool " . If you are accessing the machine locally, you can open http://localhost:3636 in a Web browser to access the Piranha Configuration Tool . Otherwise, type in the hostname or real IP address for the server followed by :3636 . Once the browser connects, you will see the screen shown in Figure 4.1, "The Welcome Panel" . Figure 4.1. The Welcome Panel Click on the Login button and enter piranha for the Username and the administrative password you created in the Password field. The Piranha Configuration Tool is made of four main screens or panels . In addition, the Virtual Servers panel contains four subsections . The CONTROL/MONITORING panel is the first panel after the login screen.

Commands:
Appendix B. Converting a File System from GFS to GFS2 Since the Red Hat Enterprise Linux 6 release does not support GFS file systems, you must upgrade any existing GFS file systems to GFS2 file systems with the gfs2_convert command. Note that you must perform this conversion procedure on a Red Hat Enterprise Linux 5 system before upgrading to Red Hat Enterprise Linux 6. Note For information on upgrading Red Hat Enterprise Linux 5 with a GFS file system to Red Hat Enterprise Linuz 7, see How to upgrade from RHEL 5 with a gfs or gfs2 filesystem to RHEL6 or RHEL 7? . Warning Before converting the GFS file system, you must back up the file system, since the conversion process is irreversible and any errors encountered during the conversion can result in the abrupt termination of the program and consequently an unusable file system. Before converting the GFS file system, you must use the gfs_fsck command to check the file system and fix any errors. If the conversion from GFS to GFS2 is interrupted by a power failure or any other issue, restart the conversion tool. Do not attempt to execute the fsck.gfs2 command on the file system until the conversion is complete. When converting full or nearly full file systems, it is possible that there will not be enough space available to fit all the GFS2 file system data structures. In such cases, the size of all the journals is reduced uniformly such that everything fits in the available space. B.1. Conversion of Context-Dependent Path Names GFS2 file systems do not provide support for Context-Dependent Path Names (CDPNs), which allow you to create symbolic links that point to variable destination files or directories. To achieve the same functionality as CDPNs in GFS2 file systems, you can use the bind option of the mount command. The gfs2_convert command identifies CDPNs and replaces them with empty directories with the same name. In order to configure bind mounts to replace the CDPNs, however, you need to know the full paths of the link targets of the CDPNs you are replacing. Before converting your file system, you can use the find command to identify the links. The following command lists the symlinks that point to a hostname CDPN: Similarly, you can execute the find command for other CDPNs ( mach , os , sys , uid , gid , jid ). Note that since CDPN names can be of the form @hostname or {hostname} , you will need to run the find command for each variant. For more information on bind mounts and context-dependent pathnames in GFS2, see Section 4.12, "Bind Mounts and Context-Dependent Path Names" .

Commands:
find /mnt/gfs -lname @hostname /mnt/gfs/log
Preface You can configure a new installation of Event-Driven Ansible controller 1.1 with automation controller 4.4 or 4.5, which is considered a general availability release fully supported by Red Hat. Automation controller 4.4 and 4.5 were released as part of Ansible Automation Platform 2.4. Upgrading to Event-Driven Ansible controller 1.1 from an earlier release is unsupported at this time. This means that you can install a new Event-Driven Ansible controller 2.5 server and configure rulebook activations to execute job templates on an Ansible Automation Platform 2.4 automation controller. With this interoperability support you can retain your existing Ansible Automation Platform 2.4 clusters and add Event-Driven Ansible controller 2.5 to them. This gives you the option to upgrade your Ansible Automation Platform 2.4 cluster to Ansible Automation Platform 2.5 at a date that suits you, whilst giving you all the benefits of Event-Driven Ansible 2.5. The installs are still two separate installs, in that you manage the Ansible Automation Platform 2.4 cluster with the Ansible Automation Platform 2.4 installer. The Event-Driven Ansible 2.5 server is managed with the Ansible Automation Platform 2.5 installer. This guide shows you how to install and configure Event-Driven Ansible 1.1 to work with automation controller 4.4 or 4.5 for a Red Hat Package Manager (RPM)-based installation.

Commands:
8.6. Function Metadata SYS.Functions This table supplies information about the functions in the virtual database. Column Name Type Description VDBName string VDB name SchemaName string Schema Name Name string Function name NameInSource string Function name in source system UID string Function UID Description string Description IsVarArgs boolean Does the function accept variable arguments? SYS.FunctionParams This supplies information on functionparameters. Column Name Type Description VDBName string VDB name SchemaName string Schema Name FunctionName string Function name FunctionUID string Function UID Name string Parameter name DataType string Data Virtualization runtime data type name Position integer Position in function args Type string Parameter direction: "In", "Out", "InOut", "ResultSet", "ReturnValue" Precision integer Precision of parameter TypeLength integer Length of parameter value Scale integer Scale of parameter Radix integer Radix of parameter NullType string Nullability: "Nullable", "No Nulls", "Unknown" UID string Function Parameter UID Description string Description OID integer Unique ID Warning The OID column is no longer used on system tables. Use UID instead.

Commands:
Chapter 1. Overview AMQ Spring Boot Starter is an adapter for creating Spring-based applications that use AMQ messaging. It provides a Spring Boot starter module that enables you to build standalone Spring applications. The starter uses the AMQ JMS client to communicate using the AMQP 1.0 protocol. AMQ Spring Boot Starter is part of AMQ Clients, a suite of messaging libraries supporting multiple languages and platforms. For an overview of the clients, see AMQ Clients Overview . For information about this release, see AMQ Clients 2.8 Release Notes . AMQ Spring Boot Starter is based on the AMQP 1.0 JMS Spring Boot project. 1.1. Key features Quickly build standalone Spring applications with built-in messaging Automatic configuration of JMS resources Configurable pooling of JMS connections and sessions 1.2. Supported standards and protocols Version 2.2 of the Spring Boot API Version 2.0 of the Java Message Service API Version 1.0 of the Advanced Message Queueing Protocol (AMQP) 1.3. Supported configurations AMQ Spring Boot Starter supports the OS and language versions listed below. For more information, see Red Hat AMQ 7 Supported Configurations . Red Hat Enterprise Linux 7 and 8 with the following JDKs: OpenJDK 8 and 11 Oracle JDK 8 IBM JDK 8 Red Hat Enterprise Linux 6 with the following JDKs: OpenJDK 8 Oracle JDK 8 IBM AIX 7.1 with IBM JDK 8 Microsoft Windows 10 Pro with Oracle JDK 8 Microsoft Windows Server 2012 R2 and 2016 with Oracle JDK 8 Oracle Solaris 10 and 11 with Oracle JDK 8 AMQ Spring Boot Starter is supported in combination with the following AMQ components and versions: All versions of AMQ Broker All versions of AMQ Interconnect A-MQ 6 versions 6.2.1 and newer 1.4. Document conventions The sudo command In this document, sudo is used for any command that requires root privileges. Exercise caution when using sudo because any changes can affect the entire system. For more information about sudo , see Using the sudo command . File paths In this document, all file paths are valid for Linux, UNIX, and similar operating systems (for example, /home/andrea ). On Microsoft Windows, you must use the equivalent Windows paths (for example, C:\Users\andrea ). Variable text This document contains code blocks with variables that you must replace with values specific to your environment. Variable text is enclosed in arrow braces and styled as italic monospace. For example, in the following command, replace <project-dir> with the value for your environment: USD cd <project-dir>

Commands:
cd <project-dir>
Chapter 3. Overview of Bare Metal certification The bare-metal certification overview provides details about product publication in the catalog, product release, certification duration, and recertification. 3.1. Publication in the catalog When you certify your server for bare-metal hardware on Red Hat OpenStack Platform, it is published in the Red Hat Ecosystem Catalog as Bare Metal . The Bare Metal Management feature also appears as a certified component of your server. 3.2. Red Hat product releases You have access to and are encouraged to test with pre-released Red Hat software. You can begin your engagement with the Red Hat Certification team before Red Hat software is generally available (GA) to customers to expedite the certification process for your product. However, conduct official certification testing only on the GA releases of Red Hat OpenShift Container Platform bare-metal hardware. 3.3. Certification duration Certifications are valid starting with the specific major and minor releases of Red Hat OpenStack Platform software as tested and listed on the Red Hat Ecosystem Catalog. They continue to be valid through the last minor release of the major release. This allows customers to count on certifications from the moment they are listed until the end of the product's lifecycle. 3.4. Recertification workflow You do not need to recertify after a new major or minor release of RHOSP if you have not made changes to your product. However, it is your responsibility to certify your product again any time you make significant changes to it. Red Hat recommends that you run the certification tests on your product periodically to ensure its quality, functionality, and performance with the supported versions of RHOSP. To recertify your product, open a supplemental certification.

Commands:
18.3.4.2. UDP Protocol These match options are available for the UDP protocol ( -p udp ): --dport - Specifies the destination port of the UDP packet, using the service name, port number, or range of port numbers. The --destination-port match option is synonymous with --dport . --sport - Specifies the source port of the UDP packet, using the service name, port number, or range of port numbers. The --source-port match option is synonymous with --sport .

Commands:
Chapter 4. Advisories related to this release The following advisories are issued to document bug fixes and CVE fixes included in this release: RHSA-2023:5734 RHSA-2023:5735 RHSA-2023:5736 RHSA-2023:5737 RHSA-2023:5739 RHSA-2023:5740 RHSA-2023:5741 RHSA-2023:5742 RHSA-2023:5743 RHSA-2023:5744 Revised on 2024-05-09 17:32:44 UTC

Commands:
Chapter 7. Creating an instance with a VDPA interface You can create an instance with a VDPA interface by requesting a port for your instance that has a vNIC type of VDPA. Limitations You cannot suspend or live migrate an instance that has a VDPA interface. You cannot detach the VDPA interface from an instance and then reattach it to the instance. Procedure Create a network that is mapped to the physical network: Create a subnet for the network: Create a port from a VDPA-enabled NIC: Create an instance, specifying the NIC port to use: An "ACTIVE" status in the output indicates that you have successfully created the instance on a host that can provide the requested VDPA interface.

Commands:
openstack network create vdpa_network --provider-physical-network tenant --provider-network-type vlan --provider-segment 1337
openstack subnet create vdpa_subnet --network vdpa_net1 --subnet-range 192.0.2.0/24 --dhcp
openstack port create vdpa_direct_port --network vdpa_network --vnic-type vdpa \
openstack server create vdpa_instance --flavor cirros256 --image cirros-0.3.5-x86_64-disk --nic port-id=vdpa_direct_port --wait
Chapter 9. Installing Using Anaconda This chapter describes an installation using the graphical user interface of anaconda . 9.1. The Text Mode Installation Program User Interface Important Installing in text mode does not prevent you from using a graphical interface on your system once it is installed. Apart from the graphical installer, anaconda also includes a text-based installer. If one of the following situations occurs, the installation program uses text mode: The installation system fails to identify the display hardware on your computer You choose the text mode installation from the boot menu While text mode installations are not explicitly documented, those using the text mode installation program can easily follow the GUI installation instructions. However, because text mode presents you with a simpler, more streamlined installation process, certain options that are available in graphical mode are not also available in text mode. These differences are noted in the description of the installation process in this guide, and include: configuring advanced storage methods such as LVM, RAID, FCoE, zFCP, and iSCSI. customizing the partition layout customizing the bootloader layout selecting packages during installation configuring the installed system with firstboot If you choose to install Red Hat Enterprise Linux in text mode, you can still configure your system to use a graphical interface after installation. Refer to Section 35.3, "Switching to a Graphical Login" for instructions. To configure options not available in text mode, consider using a boot option. For example, the linux ip option can be used to configure network settings. Refer to Section 28.1, "Configuring the Installation System at the Boot Menu" for instructions.

Commands:
16.2.4. DHCP Relay Agent The DHCP Relay Agent ( dhcrelay ) allows for the relay of DHCP and BOOTP requests from a subnet with no DHCP server on it to one or more DHCP servers on other subnets. When a DHCP client requests information, the DHCP Relay Agent forwards the request to the list of DHCP servers specified when the DHCP Relay Agent is started. When a DHCP server returns a reply, the reply is broadcast or unicast on the network that sent the original request. The DHCP Relay Agent listens for DHCP requests on all interfaces unless the interfaces are specified in /etc/sysconfig/dhcrelay with the INTERFACES directive. To start the DHCP Relay Agent, use the command service dhcrelay start .

Commands:
5.2.2. Displaying Physical Volumes There are three commands you can use to display properties of LVM physical volumes: pvs , pvdisplay , and pvscan . The pvs command provides physical volume information in a configurable form, displaying one line per physical volume. The pvs command provides a great deal of format control, and is useful for scripting. For information on using the pvs command to customize your output, see Section 5.8, "Customized Reporting for LVM" . The pvdisplay command provides a verbose multi-line output for each physical volume. It displays physical properties (size, extents, volume group, and so on) in a fixed format. The following example shows the output of the pvdisplay command for a single physical volume. The pvscan command scans all supported LVM block devices in the system for physical volumes. The following command shows all physical devices found: You can define a filter in the /etc/lvm/lvm.conf file so that this command will avoid scanning specific physical volumes. For information on using filters to control which devices are scanned, see Section 5.5, "Controlling LVM Device Scans with Filters" .

Commands:
pvdisplay --- Physical volume --- PV Name /dev/sdc1 VG Name new_vg PV Size 17.14 GB / not usable 3.40 MB Allocatable yes PE Size (KByte) 4096 Total PE 4388 Free PE 4375 Allocated PE 13 PV UUID Joqlch-yWSj-kuEn-IdwM-01S9-XO8M-mcpsVe
pvscan PV /dev/sdb2 VG vg0 lvm2 [964.00 MB / 0 free] PV /dev/sdc1 VG vg0 lvm2 [964.00 MB / 428.00 MB free] PV /dev/sdc2 lvm2 [964.84 MB] Total: 3 [2.83 GB] / in use: 2 [1.88 GB] / in no VG: 1 [964.84 MB]
13.4. Access the Running Application The Hello World quickstart application runs on the following URLs: First Server Instance: http://localhost:8080/jboss-helloworld-jdg Second Server Instance: http://localhost:8180/jboss-helloworld-jdg 23154%2C+Getting+Started+Guide-6.608-09-2016+09%3A22%3A31JBoss+Data+Grid+6Documentation6.6.1 Report a bug

Commands:
Administration Guide Red Hat CodeReady Workspaces 2.1 Administering Red Hat CodeReady Workspaces 2.1 Supriya Takkhi Robert Kratky rkratky@redhat.com Michal Maler mmaler@redhat.com Fabrice Flore-Thebault ffloreth@redhat.com Yana Hontyk yhontyk@redhat.com Red Hat Developer Group Documentation Team devtools-docs@redhat.com

Commands:
Chapter 3. Customizing the Fuse Console branding You can customize the Fuse Console branding information, such as title, logo, and login page information, by using the Fuse Console branding plugin. By default, the Fuse Console branding is defined in the hawtconfig.json that is located in the Fuse Console WAR file ( eap-install-dir/standalone/deployments/hawtio-wildfly-<version>.war ). When you implement the Fuse Console branding plugin, you can override the default branding with your own custom branding. Procedure Download the branding plugin example from https://github.com/hawtio/hawtio/tree/master/examples/branding-plugin to a local directory of your choice. In an editor of your choice, open the Fuse Console branding plugin's src/main/webapp/plugin/brandingPlugin.js file to customize the Fuse Console branding. You can change the values of the configuration properties listed in Table A.1, "Fuse Console Configuration Properties" . Save your changes. In an editor of your choice, open the Fuse Console branding plugin's pom.xml file to its <parent> section: Edit the <parent> section as follows: Change the value of the <version> property to match the version of your Fuse on EAP installation. For example, if your Fuse on EAP installation directory name is 2.0.0.fuse-760015 , set the version to 2.0.0.fuse-760015 . Remove the <relativePath>../..</relativePath> line. For example: In a Terminal window, build the branding-plugin project by running the following command: This command creates a branding-plugin.war file in the project's /target folder. Copy the branding-plugin.war file to your EAP installation's standalone/deployments directory. If Fuse is not already running, start it by running the following command: On Linux/Mac OS: ./bin/standalone.sh On Windows: ./bin/standalone.bat In a web browser, open the Fuse Console by using the URL that the start command returned in the step (the default URL is http://localhost:8080/hawtio ). Note If you have already run the Fuse Console in a web browser, the branding is stored in the browser's local storage. To use new branding settings, you must clear the browser's local storage.

Commands:
<parent> <groupId>io.hawt</groupId> <artifactId>project</artifactId> <version>2.9-SNAPSHOT</version> <relativePath>../..</relativePath> </parent>
<parent> <groupId>io.hawt</groupId> <artifactId>project</artifactId> <version> 2.0.0.fuse-760015</version> </parent>
mvn clean install