mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 6. Changing the power button behavior When you press the power button on your computer, it suspends or shuts down the system by default. You can customize this behavior according to your preferences. 6.1. Changing the behavior of the power button when pressing the button and GNOME is not running When you press the power button in a non-graphical systemd target, it shuts down the system by default. You can customize this behavior according to your preferences. Prerequisites Administrative access. Procedure Edit the /etc/systemd/logind.conf configuration file and set the HandlePowerKey=poweroff variable to one of the following options: poweroff Shut down the computer. reboot Reboot the system. halt Initiate a system halt. kexec Initiate a kexec reboot. suspend Suspend the system. hibernate Initiate system hibernation. ignore Do nothing. For example, to reboot the system upon pressing the power button, use this setting: 6.2. Changing the behavior of the power button when pressing the button and GNOME is running On the graphical login screen or in the graphical user session, pressing the power button suspends the machine by default. This happens both in cases when the user presses the power button physically or when pressing a virtual power button from a remote console. You can select a different power button behavior. Procedure Create a local database for system-wide settings in the /etc/dconf/db/local.d/01-power file with the following content: Replace <value> with one of the following power button actions: nothing Does nothing . suspend Suspends the system. hibernate Hibernates the system. interactive Shows a pop-up query asking the user what to do. With interactive mode, the system powers off automatically after 60 seconds when pressing the power button. However, you can choose a different behavior from the pop-up query. Optional: Override the user's setting, and prevent the user from changing it. Enter the following configuration in the /etc/dconf/db/local.d/locks/01-power file: Update the system databases: Log out and back in again for the system-wide settings to take effect.

Commands:
HandlePowerKey=reboot
[org/gnome/settings-daemon/plugins/power] power-button-action=<value>
/org/gnome/settings-daemon/plugins/power/power-button-action
dconf update
Chapter 5. Managing Red Hat Gluster Storage Servers and Volumes using Red Hat Virtualization Manager You can create and configure Red Hat Gluster Storage volumes using Red Hat Virtualization Manager 3.3 or later by creating a separate cluster with the Enable Gluster Service option enabled. Note Red Hat Gluster Storage nodes must be managed in a separate cluster to Red Hat Virtualization hosts. If you want to configure combined management of virtualization hosts and storage servers, see the Red Hat Hyperconverged Infrastructure documentation: https://access.redhat.com/documentation/en-us/red_hat_hyperconverged_infrastructure/1.0/html/deploying_red_hat_hyperconverged_infrastructure/ A volume is a logical collection of bricks where each brick is an export directory on a server in the trusted storage pool. Most of the management operations for Red Hat Gluster Storage happen on these volumes. You can use Red Hat Virtualization Manager to create and start new volumes featuring a single global namespace. Note With the exception of the volume operations described in this section, all other Red Hat Gluster Storage functionalities must be executed from the command line. 5.1. Creating a Data Center Select the Data Centers resource tab to list all data centers in the results list. Click the New button to open the New Data Center window. Figure 5.1. New Data Center Window Enter the Name and Description of the data center. Set Type to Shared from the drop-down menu. Set Quota Mode as Disabled . Click OK . The new data center is added to the virtualization environment. It will remain Uninitialized until a cluster, host, and storage are configured.

Commands:
Chapter 7. Managing domains Identity Service (keystone) domains are additional namespaces that you can create in keystone. Use keystone domains to partition users, groups, and projects. You can also configure these separate domains to authenticate users in different LDAP or Active Directory environments. For more information, see the Integrate with Identity Service guide. Note Identity Service includes a built-in domain called Default . It is suggested you reserve this domain only for service accounts, and create a separate domain for user accounts. 7.1. Viewing a list of domains You can view a list of domains with the openstack domain list command: 7.2. Creating a new domain You can create a new domain with the openstack domain create command: 7.3. Viewing the details of a domain You can view the details of a domain with the openstack domain show command: 7.4. Disabling a domain You can disable and enable domains according to your requirements. Procedure Disable a domain using the --disable option: Confirm that the domain has been disabled: Use the --enable option to re-enable the domain, if required:

Commands:
openstack domain list +----------------------------------+------------------+---------+--------------------+ | ID | Name | Enabled | Description | +----------------------------------+------------------+---------+--------------------+ | 3abefa6f32c14db9a9703bf5ce6863e1 | TestDomain | True | | | 69436408fdcb44ab9e111691f8e9216d | corp | True | | | a4f61a8feb8d4253b260054c6aa41adb | federated_domain | True | | | default | Default | True | The default domain | +----------------------------------+------------------+---------+--------------------+
openstack domain create TestDomain +-------------+----------------------------------+ | Field | Value | +-------------+----------------------------------+ | description | | | enabled | True | | id | 3abefa6f32c14db9a9703bf5ce6863e1 | | name | TestDomain | +-------------+----------------------------------+
openstack domain show TestDomain +-------------+----------------------------------+ | Field | Value | +-------------+----------------------------------+ | description | | | enabled | True | | id | 3abefa6f32c14db9a9703bf5ce6863e1 | | name | TestDomain | +-------------+----------------------------------+
openstack domain set TestDomain --disable
openstack domain show TestDomain +-------------+----------------------------------+ | Field | Value | +-------------+----------------------------------+ | description | | | enabled | False | | id | 3abefa6f32c14db9a9703bf5ce6863e1 | | name | TestDomain | +-------------+----------------------------------+
openstack domain set TestDomain --enable
Chapter 14. Exporting and importing the Developer Portal As a 3scale API provider, you can export and import the Developer Portal for the following purposes: Creating backups. Keeping the Developer Portal in an external repository, for example, GitHub. Integrating the Developer Portal with other applications. Use the Developer Portal API as a Content Management System (CMS) to import and export the Development Portal content. For this, perform the following steps to generate a key with enough permissions to use the Developer Portal API. Procedure Navigate to Account settings > Personal > Tokens and click Add Access Token . Name the access token and check Developer Portal API . Choose permissions: Read only allows retrieving Developer Content portal contents. Read and Write allows retrieving and restoring Developer Portal contents. Click Create Access token . Copy and store the token information displayed. Check the endpoints list navigating from the left panel to Integrate > 3scale API Docs . Then, scroll down to Developer Portal API . Use the token generated to call each endpoint and fill in the fields according to your needs. Developer Portal API endpoints considerations The Developer Portal API available from 3scale 2.14 is not compatible with versions. Also, from 3scale 2.14, JSON is the only data format compatible for all requests and responses. For each endpoint, you can perform the following actions: GET to read and list resources. POST to create and add resources. PUT to modify resources. DELETE to delete resources. Note Built-in objects cannot be deleted. Call the GET /admin/api/cms/templates endpoint with the type=builtin_page parameter to get a list of builtin pages and the type=builtin_partial parameter to get a list of builtin partials. To do a complete backup, you must call each content. There is no API endpoint that downloads a complete archive containing all files. If content is not sent, it does not return the published or draft content. Instead, it returns a summary with information like template name and section because the content is too long. Use the details listed under each endpoint to refine its output after executing it. Consider the following for the listed parameters: All endpoints reject unsupported parameters; if unsupported parameters are sent, the request is canceled. GET /admin/api/cms/templates endpoint accepts a content parameter. By default, it returns a list of Developer Portal templates. To also get published and draft content, use content=true parameter. GET /admin/api/cms/templates endpoint accepts type and section_id parameters to filter results. GET /admin/api/cms/sections endpoint accepts parent_id parameter to filter results. GET /admin/api/cms/files endpoint accepts section_id parameter to filter results.

Commands:
Chapter 2. Onboarding certification partners Use the Red Hat Customer Portal to create a new account if you are a new partner, or use your existing Red Hat account if you are a current partner to onboard with Red Hat for certifying your products. 2.1. Onboarding existing certification partners As an existing partner you could be: A member of the one-to-many EPM program who has some degree of representation on the EPM team, but does not have any assistance with OpenStack certification. OR A member fully managed by the EPM team in the traditional manner with a dedicated EPM team member who is assigned to manage the partner, including questions about OpenStack certification requests. Prerequisites You have an existing Red Hat account. Procedure Access Red Hat Customer Portal and click Log in . Enter your Red Hat login or email address and click . Then, use either of the following options: Log in with company single sign-on Log in with Red Hat account From the menu bar on the header, click your avatar to view the account details. If an account number is associated with your account, then contact the certification team to proceed with the certification process. If an account number is not associated with your account, then first contact the Red Hat global customer service team to raise a request for creating a new account number. After you get an account number, contact the certification team to proceed with the certification process. 2.2. Onboarding new certification partners Creating a new Red Hat account is the first step in onboarding new certification partners. Access Red Hat Customer Portal and click Register . Enter the following details to create a new Red Hat account: Select Corporate in the Account Type field. If you have created a Corporate type account and require an account number, contact the Red Hat global customer service team . Note Ensure that you create a company account and not a personal account. The account created during this step is also used to sign in to the Red Hat Ecosystem Catalog when working with certification requests. Choose a Red Hat login and password. Important If your login ID is associated with multiple accounts, then do not use your contact email as the login ID as this can cause issues during login. Also, you cannot change your login ID once created. Enter your Personal information and Company information . Click Create My Account . A new Red Hat account is created. Contact your Ecosystem Partner Management (EPM) representative, if available. Else contact the certification team to proceed with the certification process.

Commands:
Chapter 5. Understanding Bindings in WSDL Abstract Bindings map the logical messages used to define a service into a concrete payload format that can be transmitted and received by an endpoint. Overview Bindings provide a bridge between the logical messages used by a service to a concrete data format that an endpoint uses in the physical world. They describe how the logical messages are mapped into a payload format that is used on the wire by an endpoint. It is within the bindings that details such as parameter order, concrete data types, and return values are specified. For example, the parts of a message can be reordered in a binding to reflect the order required by an RPC call. Depending on the binding type, you can also identify which of the message parts, if any, represent the return type of a method. Port types and bindings Port types and bindings are directly related. A port type is an abstract definition of a set of interactions between two logical services. A binding is a concrete definition of how the messages used to implement the logical services will be instantiated in the physical world. Each binding is then associated with a set of network details that finish the definition of one endpoint that exposes the logical service defined by the port type. To ensure that an endpoint defines only a single service, WSDL requires that a binding can only represent a single port type. For example, if you had a contract with two port types, you could not write a single binding that mapped both of them into a concrete data format. You would need two bindings. However, WSDL allows for a port type to be mapped to several bindings. For example, if your contract had a single port type, you could map it into two or more bindings. Each binding could alter how the parts of the message are mapped or they could specify entirely different payload formats for the message. The WSDL elements Bindings are defined in a contract using the WSDL binding element. The binding element consists of attributes like, name , that specifies a unique name for the binding and type that provides reference to PortType. The value of this attribute is used to associate the binding with an endpoint as discussed in Chapter 4, Defining Your Logical Interfaces . The actual mappings are defined in the children of the binding element. These elements vary depending on the type of payload format you decide to use. The different payload formats and the elements used to specify their mappings are discussed in the following chapters. Adding to a contract Apache CXF provides command line tools that can generate bindings for predefined service interfaces. The tools will add the proper elements to your contract for you. However, we recommended that you have some knowledge of how the different types of bindings work. You can also add a binding to a contract using any text editor. When hand editing a contract, you are responsible for ensuring that the contract is valid. Supported bindings Apache CXF supports the following bindings: SOAP 1.1 SOAP 1.2 CORBA Pure XML

Commands:
4.325. tmpwatch 4.325.1. RHBA-2011:1199 - tmpwatch bug fix update An updated tmpwatch package that fixes one bug is now available for Red Hat Enterprise Linux 6. The tmpwatch utility recursively searches through specified directories and removes files which have not been accessed in a specified period of time. Tmpwatch is normally used to clean up directories which are used for temporarily holding files (for example, /tmp). Bug Fix BZ# 722856 When searching for files or directories to remove, tmpwatch was reporting all failures to access these files or directories. This included expected access failures due to the restrictive default configuration of FUSE mount points. With this update, tmpwatch now silently ignores all EACCES errors, and the expected access failures regarding FUSE mount points are no longer reported. All users are advised to upgrade to this updated tmpwatch package, which fixes this bug.

Commands:
Chapter 4. Dynamically provisioned OpenShift Data Foundation deployed on Microsoft Azure 4.1. Replacing operational or failed storage devices on Azure installer-provisioned infrastructure When you need to replace a device in a dynamically created storage cluster on an Azure installer-provisioned infrastructure, you must replace the storage node. For information about how to replace nodes, see: Replacing operational nodes on Azure installer-provisioned infrastructure . Replacing failed nodes on Azure installer-provisioned infrastructures .

Commands:
28.6. Using the Maintenance Boot Modes 28.6.1. Verifying Boot Media You can test the integrity of an ISO-based installation source before using it to install Red Hat Enterprise Linux. These sources include DVD, and ISO images stored on a hard drive or NFS server. Verifying that the ISO images are intact before you attempt an installation helps to avoid problems that are often encountered during installation. Red Hat Enterprise Linux offers you two ways to test installation ISOs: select OK at the prompt to test the media before installation when booting from the Red Hat Enterprise Linux DVD boot Red Hat Enterprise Linux with the option mediacheck option.

Commands:
8.133. man-pages-fr 8.133.1. RHBA-2014:0637 - man-pages-fr bug fix update An updated man-pages-fr package that fixes one bug is now available for Red Hat Enterprise Linux 6. The man-pages-fr package contains a collection of manual pages translated into French. Bug Fix BZ# 891278 This update of the man-pages-fr package adds a warning that the French man page for the xinetd service includes options that are out of date. Users of man-pages-fr are advised to upgrade to this updated package, which fixes this bug.

Commands:
Chapter 13. Real-Time Kernel About Red Hat Enterprise Linux for Real Time Kernel The Red Hat Enterprise Linux for Real Time Kernel is designed to enable fine-tuning for systems with extremely high determinism requirements. The major increase in the consistency of results can, and should, be achieved by tuning the standard kernel. The real-time kernel enables gaining a small increase on top of increase achieved by tuning the standard kernel. The real-time kernel is available in the rhel-7-server-rt-rpms repository. The Installation Guide contains the installation instructions and the rest of the documentation is available at Product Documentation for Red Hat Enterprise Linux for Real Time . The can-dev module has been enabled for the real-time kernel The can-dev module has been enabled for the real-time kernel, providing the device interface for Controller Area Network (CAN) device drivers. CAN is a vehicle bus specification originally intended to connect the various micro-controllers in automobiles and has since extended to other areas. CAN is also used in industrial and machine controls where a high performance interface is required and other interfaces such as RS-485 are not sufficient. The functions exported from the can-dev module are used by CAN device drivers to make the kernel aware of the devices and to allow applications to connect and transfer data. Enabling CAN in the real-time kernel allows the use of third party CAN drivers and applications to implement CAN-based systems. (BZ# 1328607 )

Commands:
21.2.3. Using TCP The default transport protocol for NFSv4 is TCP; however, the Red Hat Enterprise Linux 4 kernel includes support for NFS over UDP. To use NFS over UDP, include the -o udp option to mount when mounting the NFS-exported file system on the client system. There are three ways to configure an NFS file system export. On demand via the command line (client side), automatically via the /etc/fstab file (client side), and automatically via autofs configuration files, such as /etc/auto.master and /etc/auto.misc (server side with NIS). For example, on demand via the command line (client side): When the NFS mount is specified in /etc/fstab (client side): When the NFS mount is specified in an autofs configuration file for a NIS server, available for NIS enabled workstations: Since the default is TCP, if the -o udp option is not specified, the NFS-exported file system is accessed via TCP. The advantages of using TCP include the following: Improved connection durability, thus less NFS stale file handles messages. Performance gain on heavily loaded networks because TCP acknowledges every packet, unlike UDP which only acknowledges completion. TCP has better congestion control than UDP (which has none). On a very congested network, UDP packets are the first packets that are dropped. This means that if NFS is writing data (in 8K chunks) all of that 8K must be retransmitted over UDP. Because of TCP's reliability, only parts of that 8K data are transmitted at a time. Error detection. When a TCP connection breaks (due to the server being unavailable) the client stops sending data and restarts the connection process once the server becomes available. With UDP, since it's connection-less, the client continues to pound the network with data until the server reestablishes a connection. The main disadvantage is that there is a very small performance hit due to the overhead associated with the TCP protocol.

Commands:
mount -o udp shadowman.example.com:/misc/export /misc/local
server:/usr/local/pub /pub nfs rsize=8192,wsize=8192,timeo=14,intr,udp
myproject -rw,soft,intr,rsize=8192,wsize=8192,udp penguin.example.net:/proj52
8.80. gvfs 8.80.1. RHBA-2014:1499 - gvfs bug fix update Updated gvfs packages that fix several bugs are now available for Red Hat Enterprise Linux 6. GVFS is the GNOME desktop's virtual file system layer, which allows users to easily access local and remote data, including through the FTP, SFTP, WebDAV, CIFS, and SMB protocols, among others. GVFS integrates with the GIO (GNOME I/O) abstraction layer. Bug Fixes BZ# 902448 Previously, when several clients using the same home directory located on remote NFS (Network File System) modified the gvfs-metadata database files, a conflict could occur. In addition, GVFS produced heavy traffic on the remote NFS server. With this update, countermeasures for possible conflicts have been put in place and metadata journal files have been relocated to a temporary directory, and GVFS no longer produces heavy traffic on the NFS mount. BZ# 1011835 Prior to this update, GVFS did not pass a mount prefix into the rename operation. Consequently, it was not possible to rename files on the WebDAV shares if mount prefix was specified, and the following message was displayed when attempting to do so: The item could not be renamed. Sorry, could not rename "dir1" to "dir2": Thespecified location is not mounted This bug has been fixed and the mount prefix is now passed into the rename operation as expected. As a result, the rename operation works correctly on the WebDAV shares. BZ# 1049232 When the GDesktopAppInfoLookup extension processed a URL scheme that contained invalid characters, for example from Thunderbird messages, a request for URL handlers was unsuccessful. Consequently, an error dialog notifying about the invalid character was shown. With this update, GDesktopAppInfoLookup has been modified to check the URL scheme for invalid characters before it is used. As a result, the aforementioned error no longer occurs. BZ# 883021 A GLib2 rebase BZ# 1118325 Previously, GVFS used the select() function to communicate with the OpenSSH utility. Due to changes introduced with the OpenSSH update, select() could return incomplete results. Consequently, mounting of SFTP locations failed with the following message: Error mounting location: Error reading from unix: Input/output error GVFS has been updated to use the poll() function instead of select(), thus fixing this bug. BZ# 1101389 A GLib2 rebase caused a namespace conflict between GVFS and GIO. As a consequence, GVFS failed to build. To fix this bug, affected modules have been renamed, and the building process of GVFS now succeeds. (BZ#1071374) marked the GDesktopAppInfo class as deprecated. Consequently, GVFS failed to compile. With this update, GdesktopAppInfo is not regarded as deprecated in this specific scenario. As a result, GVFS compiles as expected. (BZ#1118704) Users of gvfs are advised to upgrade to these updated packages, which fix these bugs.

Commands: