mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 12. Configuring manual node reboot to define KernelArgs Overcloud nodes are automatically rebooted when the overcloud deployment includes setting the KernelArgs for the first time. Rebooting nodes can be an issue for existing workloads if you are adding KernelArgs to a deployment that is already in production. You can disable the automatic rebooting of nodes when updating a deployment, and instead perform node reboots manually after each overcloud deployment. Note If you disable automatic reboot and then add new Compute nodes to your deployment, the new nodes will not be rebooted during their initial provisioning. This might cause deployment errors because the configuration of KernelArgs is applied only after a reboot. 12.1. Configuring manual node reboot to define KernelArgs You can disable the automatic rebooting of nodes when you configure KernelArgs for the first time, and instead reboot the nodes manually. Procedure Log in to the undercloud as the stack user. Source the stackrc file: Enable the KernelArgsDeferReboot role parameter in a custom environment file, for example, kernelargs_manual_reboot.yaml : Add your custom environment file to the stack with your other environment files and deploy the overcloud: Retrieve a list of your Compute nodes to identify the host name of the node that you want to reboot: Disable the Compute service on the Compute node you want to reboot, to prevent the Compute scheduler from assigning new instances to the node: Replace <node> with the host name of the node you want to disable the Compute service on. Retrieve a list of the instances hosted on the Compute node that you want to migrate: Migrate the instances to another Compute node. For information on migrating instances, see Migrating virtual machine instances between Compute nodes . Log in to the node that you want to reboot. Reboot the node: Wait until the node boots. Re-enable the Compute node: Check that the Compute node is enabled:

Commands:
[stack@director ~]USD source ~/stackrc
parameter_defaults: <Role>Parameters: KernelArgsDeferReboot: True
(undercloud)USD openstack overcloud deploy --templates -e [your environment files] -e /home/stack/templates/kernelargs_manual_reboot.yaml
(undercloud)USD source ~/overcloudrc (overcloud)USD openstack compute service list
(overcloud)USD openstack compute service set <node> nova-compute --disable
(overcloud)USD openstack server list --host <node_UUID> --all-projects
[tripleo-admin@overcloud-compute-0 ~]USD sudo reboot
(overcloud)USD openstack compute service set <node_UUID> nova-compute --enable
(overcloud)USD openstack compute service list
21.3. Methods 21.3.1. Creating a Role Creation of a role requires values for name , administrative and a list of initial permits . Example 21.2. Creating a role 21.3.2. Updating a Role The name , description and administrative elements are updatable post-creation. Example 21.3. Updating a role 21.3.3. Removing a Role Removal of a role requires a DELETE request. Example 21.4. Removing a role

Commands:
POST /ovirt-engine/api/roles HTTP/1.1 Accept: application/xml Content-type: application/xml <role> <name>Finance Role</name> <administrative>true</administrative> <permits> <permit id="1"/> </permits> </role>
PUT /ovirt-engine/api/roles/8de42ad7-f307-408b-80e8-9d28b85adfd7 HTTP/1.1 Accept: application/xml Content-type: application/xml <role> <name>Engineering Role</name> <description>Standard users in the Engineering Role</description> <administrative>false</administrative> </role>
DELETE /ovirt-engine/api/roles/8de42ad7-f307-408b-80e8-9d28b85adfd7 HTTP/1.1 HTTP/1.1 204 No Content
Chapter 6. Monitoring and tuning Data Grid queries Data Grid exposes statistics for queries and provides attributes that you can adjust to improve query performance. 6.1. Getting query statistics Collect statistics to gather information about performance of your indexes and queries, including information such as the types of indexes, average time for queries to complete and the number of possible failures on indexing operations. Procedure Do one of the following: Invoke the getSearchStatistics() or getClusteredSearchStatistics() methods for embedded caches. Use GET requests to obtain statistics for remote caches from the REST API. Embedded caches // Statistics for the local cluster member SearchStatistics statistics = Search.getSearchStatistics(cache); // Consolidated statistics for the whole cluster CompletionStage<SearchStatisticsSnapshot> statistics = Search.getClusteredSearchStatistics(cache) Remote caches 6.2. Tuning query performance Use the following guidelines to help you improve the performance of indexing operations and queries. Checking index usage statistics Queries against partially indexed caches return slower results. For instance, if some fields in a schema are not annotated then the resulting index does not include those fields. Start tuning query performance by checking the time it takes for each type of query to run. If your queries seem to be slow, you should make sure that queries are using the indexes for caches and that all entities and field mappings are indexed. Adjusting the commit interval for indexes Indexing can degrade write throughput for Data Grid clusters. The commit-interval attribute defines the interval, in milliseconds, between which index changes that are buffered in memory are flushed to the index storage and a commit is performed. This operation is costly so you should avoid configuring an interval that is too small. The default is 1000 ms (1 second). Adjusting the refresh interval for queries The refresh-interval attribute defines the interval, in milliseconds, between which the index reader is refreshed. The default value is 0 , which returns data in queries as soon as it is written to a cache. A value greater than 0 results in some stale query results but substantially increases throughput, especially in write-heavy scenarios. If you do not need data returned in queries as soon as it is written, you should adjust the refresh interval to improve query performance.

Commands:
// Statistics for the local cluster member SearchStatistics statistics = Search.getSearchStatistics(cache); // Consolidated statistics for the whole cluster CompletionStage<SearchStatisticsSnapshot> statistics = Search.getClusteredSearchStatistics(cache)
GET /rest/v2/caches/{cacheName}/search/stats
20.17. Sound Devices A virtual sound card can be attached to the host physical machine by using the sound element. ... <devices> <sound model='es1370'/> </devices> ... Figure 20.64. Virtual sound card The sound element has one mandatory attribute, model , which specifies what real sound device is emulated. Valid values are specific to the underlying hypervisor, though typical choices are 'es1370' , 'sb16' , 'ac97' , and 'ich6' . In addition, a sound element with ich6 model can have optional sub-elements codec to attach various audio codecs to the audio device. If not specified, a default codec will be attached to allow playback and recording. Valid values are 'duplex' (advertises a line-in and a line-out) and 'micro' (advertises a speaker and a microphone). ... <devices> <sound model='ich6'> <codec type='micro'/> <sound/> </devices> ... Figure 20.65. Sound devices Each sound element has an optional sub-element <address> which can tie the device to a particular PCI slot, documented above.

Commands:
<devices> <sound model='es1370'/> </devices>
<devices> <sound model='ich6'> <codec type='micro'/> <sound/> </devices>
Chapter 9. NUMA 9.1. Introduction Historically, all memory on x86 systems is equally accessible by all CPUs. Known as Uniform Memory Access (UMA), access times are the same no matter which CPU performs the operation. This behavior is no longer the case with recent x86 processors. In Non-Uniform Memory Access (NUMA), system memory is divided into zones (called nodes ), which are allocated to particular CPUs or sockets. Access to memory that is local to a CPU is faster than memory connected to remote CPUs on that system. This chapter describes memory allocation and NUMA tuning configurations in virtualized environments.

Commands:
Appendix A. API Response Codes The Red Hat Satellite 6 API provides HTTP response status codes for API calls. The following codes are common for all resources in the Satellite API. Table A.1. API Response Codes Response Explanation 200 OK For a successful request action: show, index, update, or delete (GET, PUT, DELETE requests). 201 Created For a successful create action (POST request). 301 Moved Permanently Redirect when Satellite is restricted to use HTTPS and HTTP is attempted. 400 Bad Request A required parameter is missing or the search query has invalid syntax. 401 Unauthorized Failed to authorize the user (for example, incorrect credentials). 403 Forbidden The user has insufficient permissions to perform the action or read the resource, or the action is unsupported in general. 404 Not Found The record with the given ID does not exist. It can appear in show and delete actions when the requested record does not exist; or in create, update and delete actions when one of the associated records does not exist. 409 Conflict Could not delete the record due to existing dependencies (for example, host groups with hosts). 415 Unsupported Media Type The content type of the HTTP request is not JSON. 422 Unprocessable Entity Failed to create an entity due to some validation errors. Applies to create or update actions only. 500 Internal Server Error Unexpected internal server error. 503 Service Unavailable The server is not running.

Commands:
Chapter 3. View OpenShift Data Foundation Topology The topology shows the mapped visualization of the OpenShift Data Foundation storage cluster at various abstraction levels and also lets you to interact with these layers. The view also shows how the various elements compose the Storage cluster altogether. Procedure On the OpenShift Web Console, navigate to Storage Data Foundation Topology . The view shows the storage cluster and the zones inside it. You can see the nodes depicted by circular entities within the zones, which are indicated by dotted lines. The label of each item or resource contains basic information such as status and health or indication for alerts. Choose a node to view node details on the right-hand panel. You can also access resources or deployments within a node by clicking on the search/preview decorator icon. To view deployment details Click the preview decorator on a node. A modal window appears above the node that displays all of the deployments associated with that node along with their statuses. Click the Back to main view button in the model's upper left corner to close and return to the view. Select a specific deployment to see more information about it. All relevant data is shown in the side panel. Click the Resources tab to view the pods information. This tab provides a deeper understanding of the problems and offers granularity that aids in better troubleshooting. Click the pod links to view the pod information page on OpenShift Container Platform. The link opens in a new window.

Commands:
7.19. btrfs-progs 7.19.1. RHBA-2013:0456 - btrfs-progs bug fix and enhancement update Updated btrfs-progs packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The btrfs-progs packages provide user-space programs to create, check, modify, and correct any inconsistencies in a Btrfs file system. Note The btrfs-progs packages have been upgraded to upstream version 0.2, which provides a number of bug fixes and enhancements over the version, including support for slashes in file system labels and new commands "btrfs-find-root", "btrfs-restore", and "btrfs-zero-log". This update also modifies the btrfs-progs utility, so that it is now built with the -fno-strict-aliasing method. (BZ# 865600 ) All users of btrfs-progs are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 6. DNS (designate) parameters You can modify the designate service with DNS parameters. Parameter Description DesignateBindQueryLogging Set to true to enable logging of queries on BIND. The default value is false . DesignateManagedResourceEmail Configure email address to be set in zone SOAs. Leaving unset results in service defaults being used. DesignateMdnsProxyBasePort Configure the base port for the MiniDNS proxy endpoints on the external/public access network. The default value is 16000 . DesignateMinTTL Configure the minimum allowable TTL in seconds. The default value is 0 which leaves the parameter unset. The default value is 0 . DesignateWorkers Number of workers for Designate services. The default value is 0 . UnboundAllowedCIDRs A list of CIDRs allowed to make queries through Unbound. Example, [ 192.0.2.0/24 , 198.51.100.0/24 ]. UnboundAllowRecursion When false, Unbound will not attempt to recursively resolve the request. It will only answer for queries using local information. The default value is true . UnboundDesignateIntegration Set to false to disable configuring neutron using the deployed unbound server as the default resolver. The default value is true . UnboundForwardFallback When true, if the forwarded query receives a SERVFAIL, Unbound will process the request as a standard recursive resolution. The default value is true . UnboundForwardResolvers A list of DNS resolver IP addresses, with optional port, that Unbound will forward resolution requests to if Unbound does not have the answer. Example, [ 192.0.2.10 , 192.0.2.20@53 ]. UnboundLogQueries If true, Unbound will log the query requests. The default value is false . UnboundSecurityHarden When true, Unbound will block certain queries that could have security implications to the Unbound service. The default value is true .

Commands:
Chapter 10. Using cups-browsed to locally integrate printers from a remote print server The cups-browsed service uses DNS service discovery (DNS-SD) and CUPS browsing to make all or a filtered subset of shared remote printers automatically available in a local CUPS service. For example, administrators can use this feature on workstations to make only printers from a trusted print server available in a print dialog of applications. It is also possible to configure cups-browsed to filter the browsed printers by certain criteria to reduce the number of listed printers if a print server shares a large number of printers. Note If the print dialog in an application uses other mechanisms than, for example DNS-SD, to list remote printers, cups-browsed has no influence. The cups-browsed service also does not prevent users from manually accessing non-listed printers. Prerequisites The CUPS service is configured on the local host . A remote CUPS print server exists, and the following conditions apply to this server: The server listens on an interface that is accessible from the client. The Allow from parameter in the server's <Location /> directive in the /etc/cups/cups.conf file allows access from the client's IP address. The server shares printers. Firewall rules allow access from the client to the CUPS port on the server. Procedure Edit the /etc/cups/cups-browsed.conf file, and make the following changes: Add BrowsePoll parameters for each remote CUPS server you want to poll: Append : <port> to the hostname or IP address if the remote CUPS server listens on a port different from 631. Optional: Configure a filter to limit which printers are shown in the local CUPS service. For example, to filter for queues whose name contain sales_ , add: You can filter by different field names, negate the filter, and match the exact values. For further details, see the parameter description and examples in the cups-browsed.conf(5) man page on your system. Optional: Change the polling interval and timeout to limit the number of browsing cycles: Increase both BrowseInterval and BrowseTimeout in the same ratio to avoid situations in which printers disappear from the browsing list. This mean, multiply the value of BrowseInterval by 5 or a higher integer, and use this result value for BrowseTimeout . By default, cups-browsed polls remote servers every 60 seconds and the timeout is 300 seconds. However, on print servers with many queues, these default values can cost many resources. Enable and start the cups-browsed service: Verification List the available printers: If the output for a printer contains implicitclass , cups-browsed manages the printer in CUPS. Additional resources cups-browsed.conf(5) man page on your system

Commands:
BrowsePoll remote_cups_server.example.com BrowsePoll 192.0.2.100:1631
BrowseFilter name sales_
BrowseInterval 1200 BrowseTimeout 6000
systemctl enable --now cups-browsed
lpstat -v device for Demo-printer : implicitclass:// Demo-printer /
Chapter 8. API configuration examples 8.1. external_registry_config object reference { "is_enabled": True, "external_reference": "quay.io/redhat/quay", "sync_interval": 5000, "sync_start_date": datetime(2020, 0o1, 0o2, 6, 30, 0), "external_registry_username": "fakeUsername", "external_registry_password": "fakePassword", "external_registry_config": { "verify_tls": True, "unsigned_images": False, "proxy": { "http_proxy": "http://insecure.proxy.corp", "https_proxy": "https://secure.proxy.corp", "no_proxy": "mylocalhost", }, }, } 8.2. rule_rule object reference { "root_rule": {"rule_kind": "tag_glob_csv", "rule_value": ["latest", "foo", "bar"]}, }

Commands:
{ "is_enabled": True, "external_reference": "quay.io/redhat/quay", "sync_interval": 5000, "sync_start_date": datetime(2020, 0o1, 0o2, 6, 30, 0), "external_registry_username": "fakeUsername", "external_registry_password": "fakePassword", "external_registry_config": { "verify_tls": True, "unsigned_images": False, "proxy": { "http_proxy": "http://insecure.proxy.corp", "https_proxy": "https://secure.proxy.corp", "no_proxy": "mylocalhost", }, }, }
{ "root_rule": {"rule_kind": "tag_glob_csv", "rule_value": ["latest", "foo", "bar"]}, }
Chapter 10. Configuring trusted certificates for outgoing requests When Red Hat build of Keycloak communicates with external services through TLS, it has to validate the remote server's certificate in order to ensure it is connecting to a trusted server. This is necessary in order to prevent man-in-the-middle attacks. The certificates of these remote server's or the CA that signed these certificates must be put in a truststore. This truststore is managed by the Keycloak server. The truststore is used when connecting securely to identity brokers, LDAP identity providers, when sending emails, and for backchannel communication with client applications. It is also useful when you want to change the policy on how host names are verified and trusted by the server. By default, a truststore provider is not configured, and any TLS/HTTPS connections fall back to standard Java Truststore configuration. If there is no trust established, then these outgoing requests will fail. 10.1. Configuring the Red Hat build of Keycloak Truststore You can add your truststore configuration by entering this command: bin/kc.[sh|bat] start --spi-truststore-file-file=myTrustStore.jks --spi-truststore-file-password=password --spi-truststore-file-hostname-verification-policy=ANY The following are possible configuration options for this setting: file The path to a Java keystore file. TLS requests need a way to verify the host of the server to which they are talking. This is what the truststore does. The keystore contains one or more trusted host certificates or certificate authorities. This truststore file should only contain public certificates of your secured hosts. This is REQUIRED if any of these properties are defined. password Password of the keystore. This option is REQUIRED if any of these properties are defined. hostname-verification-policy For HTTPS requests, this option verifies the hostname of the server's certificate. Default: WILDCARD ANY means that the hostname is not verified. WILDCARD allows wildcards in subdomain names, such as *.foo.com. When using STRICT , the Common Name (CN) must match the hostname exactly. Please note that this setting does not apply to LDAP secure connections, which require strict hostname checking. type The type of truststore, such as jks , pkcs12 or bcfks . If not provided, the type would be detected based on the truststore file extension or platform default type. 10.1.1. Example of a truststore configuration The following is an example configuration for a truststore that allows you to create trustful connections to all mycompany.org domains and its subdomains: bin/kc.[sh|bat] start --spi-truststore-file-file=path/to/truststore.jks --spi-truststore-file-password=change_me --spi-truststore-file-hostname-verification-policy=WILDCARD

Commands:
bin/kc.[sh|bat] start --spi-truststore-file-file=myTrustStore.jks --spi-truststore-file-password=password --spi-truststore-file-hostname-verification-policy=ANY
bin/kc.[sh|bat] start --spi-truststore-file-file=path/to/truststore.jks --spi-truststore-file-password=change_me --spi-truststore-file-hostname-verification-policy=WILDCARD
20.4. OpenSSH Configuration Files OpenSSH has two different sets of configuration files: one for client programs ( ssh , scp , and sftp ) and one for the server daemon ( sshd ). System-wide SSH configuration information is stored in the /etc/ssh/ directory: moduli - Contains Diffie-Hellman groups used for the Diffie-Hellman key exchange which is critical for constructing a secure transport layer. When keys are exchanged at the beginning of an SSH session, a shared, secret value is created which cannot be determined by either party alone. This value is then used to provide host authentication. ssh_config - The system-wide default SSH client configuration file. It is overridden if one is also present in the user's home directory ( ~/.ssh/config ). sshd_config - The configuration file for the sshd daemon. ssh_host_dsa_key - The DSA private key used by the sshd daemon. ssh_host_dsa_key.pub - The DSA public key used by the sshd daemon. ssh_host_key - The RSA private key used by the sshd daemon for version 1 of the SSH protocol. ssh_host_key.pub - The RSA public key used by the sshd daemon for version 1 of the SSH protocol. ssh_host_rsa_key - The RSA private key used by the sshd daemon for version 2 of the SSH protocol. ssh_host_rsa_key.pub - The RSA public key used by the sshd for version 2 of the SSH protocol. User-specific SSH configuration information is stored in the user's home directory within the ~/.ssh/ directory: authorized_keys - This file holds a list of authorized public keys for servers. When the client connects to a server, the server authenticates the client by checking its signed public key stored within this file. id_dsa - Contains the DSA private key of the user. id_dsa.pub - The DSA public key of the user. id_rsa - The RSA private key used by ssh for version 2 of the SSH protocol. id_rsa.pub - The RSA public key used by ssh for version 2 of the SSH protocol identity - The RSA private key used by ssh for version 1 of the SSH protocol. identity.pub - The RSA public key used by ssh for version 1 of the SSH protocol. known_hosts - This file contains DSA host keys of SSH servers accessed by the user. This file is very important for ensuring that the SSH client is connecting the correct SSH server. Important If an SSH server's host key has changed, the client notifys the user that the connection cannot proceed until the server's host key is deleted from the known_hosts file using a text editor. Before doing this, however, contact the system administrator of the SSH server to verify the server is not compromised. Refer to the ssh_config and sshd_config man pages for information concerning the various directives available in the SSH configuration files.

Commands:
Chapter 2. Architectures Red Hat Enterprise Linux 9.0 is distributed with the kernel version 5.14.0, which provides support for the following architectures at the minimum required version: AMD and Intel 64-bit architectures (x86-64-v2) The 64-bit ARM architecture (ARMv8.0-A) IBM Power Systems, Little Endian (POWER9) 64-bit IBM Z (z14) Make sure you purchase the appropriate subscription for each architecture. For more information, see Get Started with Red Hat Enterprise Linux - additional architectures .

Commands: