mtpti5iD/redhat-docs_dataset huggingface dataset:
9.4. Considerations for Generated REST Services If you defined a procedure that returns a XML content, then REST service call must be called with "accepts" HTTP header of "application/xml". Also, if you defined a procedure that returns a JSON content and PRODUCES property is defined "json" then HTTP client call must include the "accepts" header of "application/json". In the situations where "accepts" header is missing, and only one procedure is defined with unique path, that procedure will be invoked. If there are multiple procedures with same URI path, for example one generating XML and another generating JSON content, then "accepts" header directs the REST engine as to which procedure will be invoked to get the results. A wrong "accepts" header will result in error. Warning Ensure the number of parameters defined on the URI must match to the parameters defined on procedure definition. An error with parameter definition will result in procedure being skipped from generation of REST based service or error with 'GET' based methods. 'POST' methods do not need to be defined with URI paths, the procedure parameters are automatically added as @FormParam annotations on the generated procedure.

Commands:
18.20. Installation Complete Congratulations! Your Red Hat Enterprise Linux installation is now complete! The installation program prompts you to prepare your system for reboot. The installation program automatically reboots into the installed system. Should the installation program not reboot, the installation program shows information from which device to do an IPL (boot). Accept the shutdown option and after shutdown, IPL from the DASD or SCSI LUN where the /boot partition for Red Hat Enterprise Linux has been installed. 18.20.1. IPL under z/VM To IPL from a DASD, for example using the DASD device 200 on the 3270 console, issue the command: In DASD only environments where automatic partitioning (clearing data from all partitions) was used, the first activated DASD is where the /boot partition is typically located. Using /boot on an FCP LUN, you must provide the WWPN and LUN for the FCP-attached device from which to IPL. To IPL from an FCP-attached device: Provide FCP routing information to an FCP-attached device, for example, where 0x50050763050B073D is the WWPN, and 0x4020400100000000 is the FCP LUN: IPL the FCP adapter, for example FC00 : Note To disconnect from the 3270 terminal without stopping the Linux running in your virtual machine, use #cp disconnect instead of #cp logoff . When your virtual machine is re-connected using the usual logon procedure, it might be placed in CP console function mode ( CP READ ). If so, to resume execution on your virtual machine, enter the BEGIN command. 18.20.2. IPL on an LPAR For LPAR-based installations, on the HMC, issue a load command to the LPAR, specifying the particular DASD, or the FCP adapter, WWPN, and FCP LUN where the /boot partition is located. 18.20.3. Continuing after Reboot (re-IPL) Following the automatic reboot or the manual IPL of the installed Red Hat Enterprise Linux operating system, you can log on to the system through ssh . Note that the only place from which you can log in as root is from the 3270 terminal or from other terminal devices listed in /etc/securetty . The first time you start your Red Hat Enterprise Linux system in a graphical environment, you can use Initial Setup to guide you through Red Hat Enterprise Linux configuration. Initial Setup lets you configure your environment at the beginning, so that you can get started using your Red Hat Enterprise Linux system quickly. See Chapter 30, Initial Setup for information about the configuration process.

Commands:
#cp i 200
#cp set loaddev portname 50050763 050B073D lun 40204001 00000000
#cp ipl FC00
function::msecs_to_string Name function::msecs_to_string - Human readable string for given milliseconds Synopsis Arguments msecs Number of milliseconds to translate. Description Returns a string representing the number of milliseconds as a human readable string consisting of " XmY.ZZZs " , where X is the number of minutes, Y is the number of seconds and ZZZ is the number of milliseconds.

Commands:
function msecs_to_string:string(msecs:long)
3.2. Initial Setup Tasks Initial GFS2 setup consists of the following tasks: Setting up logical volumes. Making a GFS2 files system. Mounting file systems. Follow these steps to set up GFS2 initially. Using LVM, create a logical volume for each Red Hat GFS2 file system. Note You can use init.d scripts included with Red Hat Cluster Suite to automate activating and deactivating logical volumes. For more information about init.d scripts, see Configuring and Managing a Red Hat Cluster . Create GFS2 file systems on logical volumes created in Step 1. Choose a unique name for each file system. For more information about creating a GFS2 file system, see Section 4.1, "Making a File System" . You can use either of the following formats to create a clustered GFS2 file system: For more information on creating a GFS2 file system, see Section 4.1, "Making a File System" . At each node, mount the GFS2 file systems. For more information about mounting a GFS2 file system, see Section 4.2, "Mounting a File System" . Command usage: mount BlockDevice MountPoint mount -o acl BlockDevice MountPoint The -o acl mount option allows manipulating file ACLs. If a file system is mounted without the -o acl mount option, users are allowed to view ACLs (with getfacl ), but are not allowed to set them (with setfacl ). Note You can use init.d scripts included with the Red Hat High Availability Add-On to automate mounting and unmounting GFS2 file systems.

Commands:
mkfs.gfs2 -p lock_dlm -t ClusterName:FSName -j NumberJournals BlockDevice
mkfs -t gfs2 -p lock_dlm -t LockTableName -j NumberJournals BlockDevice
Appendix A. Red Hat Customer Portal Labs Relevant to Networking Red Hat Customer Portal Labs are tools designed to help you improve performance, troubleshoot issues, identify security problems, and optimize configuration. This appendix provides an overview of Red Hat Customer Portal Labs relevant to networking. All Red Hat Customer Portal Labs are available at https://access.redhat.com/labs/ . Bridge Configuration The Bridge Configuration is designed to configure a bridged network interface for applications such as KVM using Red Hat Enterprise Linux 5.4 or later. Network Bonding Helper The Network Bonding Helper allows administrators to bind multiple Network Interface Controllers together into a single channel using the bonding kernel module and the bonding network interface. Use the Network Bonding Helper to enable two or more network interfaces to act as one bonding interface. Packet capture syntax generator The Packet capture syntax generator helps you to capture network packets. Use the Packet capture syntax generator to generate the tcpdump command that selects an interface and then prints information to the console. You need root access to enter the command.

Commands:
3.3. Cache Configuration By default, result set caching is enabled with 1024 maximum entries with a maximum entry age of two hours. There are actually two caches configured with these settings. One cache holds results that are specific to sessions and is local to each Red Hat JBoss Data Virtualization instance. The other cache holds VDB scoped results and can be replicated. You can also override the default maximum entry age via the Cache Hint. Result set caching is not limited to memory. There is no explicit limit on the size of the results that can be cached. Cached results are primarily stored in the BufferManager and are subject to its configuration, including the restriction of maximum buffer space. Important While the result data is not held in memory, cache keys - including parameter values - may be held in memory. Thus the cache should not be given an unlimited maximum size. Result set cache entries can be invalidated by data change events. The max-staleness setting determines how long an entry will remain in the case after one of the tables that contributed to the results has been changed.

Commands:
8.2.3. Creating the LVM Volume Groups Once all the physical volumes are created, the volume groups can be created: Click the LVM button to collect the physical volumes into volume groups. A volume group is basically a collection of physical volumes. You can have multiple logical volume groups, but a physical volume can only be in one volume group. Note There is overhead disk space reserved in the logical volume group. The summation of the physical volumes may not equal the size of the volume group; however, the size of the logical volumes shown is correct. Figure 8.7. Creating an LVM Volume Group Change the Volume Group Name if desired. All logical volumes inside the volume group must be allocated in physical extent units. By default, the physical extent is set to 32 MB; thus, logical volume sizes must be divisible by 32 MBs. If you enter a size that is not a unit of 32 MBs, the installation program automatically selects the closest size in units of 32 MBs. It is not recommended that you change this setting. Select which physical volumes to use for the volume group.

Commands:
function::tokenize Name function::tokenize - Return the non-empty token in a string. Synopsis Arguments input String to tokenize. If NULL, returns the non-empty token in the string passed in the call to tokenize . delim Token delimiter. Set of characters that delimit the tokens. General Syntax tokenize:string (input:string, delim:string) Description This function returns the non-empty token in the given input string, where the tokens are delimited by characters in the delim string. If the input string is non-NULL, it returns the first token. If the input string is NULL, it returns the token in the string passed in the call to tokenize. If no delimiter is found, the entire remaining input string is returned. It returns NULL when no more tokens are available.

Commands:
function tokenize:string(input:string,delim:string)
5.97. grubby 5.97.1. RHBA-2012:0895 - grubby bug fix and enhancement update Updated grubby packages that fix one bug are now available for Red Hat Enterprise Linux 6. The grubby packages provide grubby, a command line tool for displaying and editing of GRUB (GRand Unified Bootloader) configuration files. Bug Fix BZ# 696960 Previously, when grubby was executed with the "--args=[arguments] --update-kernel=ALL" options to update command line arguments for all kernels whose boot configuration was stored in the edited configuration file, it updated only arguments for the first kernel in the file. As a result, arguments for the other kernels were not updated. This update ensures that arguments for all kernels in a configuration file are updated when grubby is launched with the aforementioned options. All users of grubby are advised to upgrade to these updated packages, which fix this bug.

Commands:
Preface Red Hat OpenShift Data Foundation supports deployment on existing Red Hat OpenShift Container Platform (RHOCP) vSphere clusters in connected or disconnected environments along with out-of-the-box support for proxy environments. To deploy OpenShift Data Foundation, start with the requirements in the Preparing to deploy OpenShift Data Foundation chapter and then follow any one of the below deployment process for your environment: Internal mode Deploy using dynamic storage devices Deploy using local storage devices Deploy standalone Multicloud Object Gateway External mode Deploying OpenShift Data Foundation in external mode

Commands:
Chapter 2. Deploying Quarkus applications You can deploy your Quarkus application on OpenShift by using any of the the following build strategies: Docker build S2I Binary Source S2I For more details about each of these build strategies, see Chapter 1. OpenShift build strategies and Quarkus of the Deploying your Quarkus applications to OpenShift guide. Note The OpenShift Docker build strategy is the preferred build strategy that supports Quarkus applications targeted for JVM as well as Quarkus applications compiled to native executables. You can configure the deployment strategy using the quarkus.openshift.build-strategy property.

Commands:
5.197. mod_authz_ldap 5.197.1. RHBA-2012:1389 - mod_authz_ldap bug fix update Updated mod_authz_ldap packages that fix three bugs are now available for Red Hat Enterprise Linux 6. The mod_authz_ldap packages provide a module for the Apache HTTP Server to authenticate users against an LDAP database. Bug Fixes BZ# 607797 Prior to this update, the License field of the mod_authz_ldap packages contained an incorrect tag. This update modifies the license text. Now, the license tag correctly reads "ASL1.0". BZ# 643691 Prior to this update, the mod_authz_ldap module could leak memory. As a consequence, the memory consumption of the httpd process could increase as more requests were processed. This update modifies the underlying code to handle LDAP correctly. Now, the memory consumption as at expected levels. BZ# 782442 Prior to this update, passwords were logged in plain text to the error log when an LDAP bind password was configured if a connection error occurred. This update modifies the underlying code to prevent passwords from being logged in error conditions. All users of mod_authz_ldap are advised to upgrade to this updated package, which fixes these bugs.

Commands:
1.3.3. Checking Out a Working Copy To check out a working copy of a project in a CVS repository, run the following command: cvs -d cvs_repository checkout module This creates a new directory called module with a working copy of a project in it. Note that cvs_repository is a URL of the CVS repository and module is the subdirectory in which the project is stored (such as project ). Alternatively, you can set the USDCVSROOT environment variable as follows: export CVSROOT= cvs_repository Then you can use the cvs checkout command without the -d option: cvs checkout module Example 1.17. Checking out a working copy Imagine that you have a CVS repository in ~/cvs/ and that this repository contains a module named project . To check out a working copy of this module, type:

Commands:
~]USD export CVSROOT=~/cvs ~]USD cvs checkout project cvs checkout: Updating project U project/AUTHORS U project/INSTALL U project/LICENSE U project/Makefile U project/TODO
Chapter 121. AclRuleGroupResource schema reference Used in: AclRule The type property is a discriminator that distinguishes use of the AclRuleGroupResource type from AclRuleTopicResource , AclRuleClusterResource , AclRuleTransactionalIdResource . It must have the value group for the type AclRuleGroupResource . Property Property type Description type string Must be group . 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 topic name. With prefix pattern type, the resource name will be used only as a prefix. Default value is literal .

Commands:
Chapter 5. Using custom Red Hat build of Keycloak images 5.1. Red Hat build of Keycloak custom image with the Operator With the Keycloak Custom Resource (CR), you can specify a custom container image for the Red Hat build of Keycloak server. Note To ensure full compatibility of Operator and Operand, make sure that the version of Red Hat build of Keycloak release used in the custom image is aligned with the version of the operator. 5.1.1. Best practice When using the default Red Hat build of Keycloak image, the server will perform a costly re-augmentation every time a Pod starts. To avoid this delay, you can provide a custom image with the augmentation built-in from the build time of the image. With a custom image, you can also specify the Keycloak build-time configurations and extensions during the build of the container. For instructions on how to build such an image, see Running Red Hat build of Keycloak in a container . 5.1.2. Providing a custom Red Hat build of Keycloak image To provide a custom image, you define the image field in the Keycloak CR as shown in this example: apiVersion: k8s.keycloak.org/v2alpha1 kind: Keycloak metadata: name: example-kc spec: instances: 1 image: quay.io/my-company/my-keycloak:latest http: tlsSecret: example-tls-secret hostname: hostname: test.keycloak.org Note With custom images, every build time option is passed either through a dedicated field or the additionalOptions is ignored.

Commands:
apiVersion: k8s.keycloak.org/v2alpha1 kind: Keycloak metadata: name: example-kc spec: instances: 1 image: quay.io/my-company/my-keycloak:latest http: tlsSecret: example-tls-secret hostname: hostname: test.keycloak.org
Chapter 27. IBM System z References 27.1. IBM System z Publications Current versions of the Linux on System z publications can be found at http://www.ibm.com/developerworks/linux/linux390/documentation_red_hat.html . They include: Linux on System z - Device Drivers, Features, and Commands as available with Red Hat Enterprise Linux 6 . IBM . 2010. SC34-2597. Linux on System z - Using the Dump Tools on Red Hat Enterprise Linux 6 . IBM . 2010. SC34-2607. Linux on System z - How to use FC-attached SCSI devices with Linux on System z9 and zSeries . IBM . 2008. SC33-8413. How to use Execute-in-Place Technology with Linux on z/VM . IBM . 2008. SC34-2594. Linux on System z - How to Set up a Terminal Server Environment on z/VM . IBM . 2009. SC34-2596. Linux on System z - libica 2.0 Programmer's Reference . IBM . 2009. SC34-2602. Linux on System z - How to Improve Performance with PAV . IBM . 2008. SC33-8414. z/VM - Getting Started with Linux on System z . IBM . 2009. SC24-6194.

Commands:
7.176. rdma 7.176.1. RHBA-2015:1415 - rdma bug fix and enhancement update Updated rdma packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. Red Hat Enterprise Linux includes a collection of Infiniband and iWARP utilities, libraries and development packages for writing applications that use Remote Direct Memory Access (RDMA) technology. Note The user space libcxgb4 driver has been upgraded to upstream version 1.3.1, which provides a number of bug fixes and enhancements over the version. (BZ# 1165842 ) The user space library infinipath-psm has been upgraded to upstream version 3.3, which provides a number of bug fixes and enhancements over the version. (BZ# 1138643 ) Bug Fixes BZ# 1159331 When shutting down a system with InfiniBand (IB) modules loaded, the system displayed a "Failed to unload ib_addr" error message during the shutdown process. This update corrects the order in which IB modules are unloaded, and the error message no longer appears. BZ# 1151159 Prior to this update, shutting down the nfs-rdma service failed and printed the following message in the console: Please stop the nfs-rdma service before stopping the rdma service. The order of nfs-rdma shutdown steps has been corrected, and nfs-rdma now stops correctly. BZ# 1006988 Previously, the mstvpd program failed with a segmentation fault when used. With this update, the underlying code has been fixed, and the problem no longer occurs. Enhancement BZ# 1186498 The ifup-ib script artificially limited the maximum transmission unit (MTU) amount of IP over InfiniBand (IPoIB) devices running in datagram mode to 2044. This has been fixed, and the new limit now depends on the underlying MTU of the InfiniBand fabric. As a result, IPoIB devices can now have MTU up to 4092 if the InfiniBand fabric MTU is also 4092. Users of rdma are advised to upgrade to these updated packages, which fix these bugs and add this enhancement.

Commands:
Chapter 7. Management CLI Command History The management CLI features a command history functionality that is enabled by default in the application server installation. The history is kept both as a record in the volatile memory of the active CLI session, and appended to a log file that saves automatically in the user's home directory as .jboss-cli-history . This history file is configured by default to record up to a maximum of 500 CLI commands. The history file location and maximum history entries can be customized in the EAP_HOME /bin/jboss-cli.xml file. The history command by itself will return the history of the current session, or with additional arguments will disable, enable, or clear the history from the session memory. The management CLI also features the ability to use your keyboard's arrow keys to go back and forth in the history of commands and operations. View the Management CLI Command History Display the CLI command history stored in memory since the management CLI startup or the history clear command. Clear the Management CLI Command History Clear the history of CLI commands from the session memory and from the .jboss-cli-history file saved to the user's home directory. Enable the Management CLI Command History Record CLI commands in the session memory and in the .jboss-cli-history file saved to the user's home directory. Disable the Management CLI Command History Do not record CLI commands in the session memory or in the .jboss-cli-history file saved to the user's home directory.

Commands:
history
history --clear
history --enable
history --disable
Chapter 2. User interface views The Migration Toolkit for Applications (MTA) user interface has two views: Administration view Migration view In Administration view, administrators can configure the instance environment, work with credentials and repositories, define HTTP and HTTPS proxies, create custom migration targets, manage issues, and add custom assessment questionnaires. In Migration view, all authorized users can review reports, add applications for assessment and analysis. perform application assessments and analyses, create migration waves, view issues that could potentially impact migration, view the status of analysis and discovery tasks through Task Manager. The permissions of the different user roles - administrators, architects, and migrators - vary in this view.

Commands:
A.13. Workaround for Creating External Snapshots with libvirt There are two classes of snapshots for KVM guests: Internal snapshots are contained completely within a qcow2 file, and fully supported by libvirt , allowing for creating, deleting, and reverting of snapshots. This is the default setting used by libvirt when creating a snapshot, especially when no option is specified. This file type take slightly longer than others for creating the snapshot, and has the drawback of requiring qcow2 disks. Important Internal snapshots are not being actively developed, and Red Hat discourages their use. External snapshots work with any type of original disk image, can be taken with no guest downtime, and are more stable and reliable. As such, external snapshots are recommended for use on KVM guest virtual machines. However, external snapshots are currently not fully implemented on Red Hat Enterprise Linux 7, and are not available when using virt-manager . To create an external snapshot, use the snapshot-create-as with the --diskspec vda,snapshot=external option, or use the following disk line in the snapshot XML file: At the moment, external snapshots are a one-way operation as libvirt can create them but cannot do anything further with them. A workaround is described on libvirt upstream pages .

Commands:
<disk name='vda' snapshot='external'> <source file='/path/to,new'/> </disk>