mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 3. Security and SAP Solutions Enterprises usually have substantial compliance requirements based on the industry, type of customers, geographic location, and more. Such requirements may need specific certifications, cryptographic modules, and support for encryptions. With Red Hat Enterprise Linux for SAP Solutions, Red Hat delivers a stable, security-focused, high-performance foundation for SAP business applications to support such requirements and provide an easy way to set and validate compliance policies. 3.1. SELinux for SAP production environments SELinux is a security technology for process isolation to mitigate attacks via privilege escalation. SELinux is enabled on RHEL 8 by default and security policies for system processes are maintained by Red Hat. However, this does not apply to 3rd party applications, such as SAP HANA and S/4HANA. In releases, it was recommended to completely disable SELinux on RHEL when installing SAP software. This has now changed with RHEL for SAP Solutions, and customers may use SELinux in the context of production SAP HANA and S/4HANA deployments. Additional resources For more information, see Enabling SELinux with SAP HANA DB . 3.2. SAP HANA disk encryption with NBDE Red Hat uses the Policy-Based Decryption (PBD) process by using multiple technologies to enable the unlocking of encrypted root and secondary volumes of hard drives. Network Bound Disk Encryption (NBDE), delivered along with Red Hat Enterprise Linux, is a subcategory of PBD that allows binding encrypted volumes to a special server known as a tang server. Tested for compliance with SAP HANA, customers of RHEL for SAP Solutions can use NBDE to run SAP HANA DB with encrypted hard drives leveraging automated unlocking capabilities via Tang server. Additional resources For more information, see Setting Up a RHEL System with NBDE and Installing SAP HANA DB with RHEL . 3.3. File access policy Daemon for SAP File access policy Daemon fapolicyd is a technology provided in RHEL to determine access rights to files based on a trust database and file or process attributes. It helps customers to ensure data remains protected even in case an attacker has successfully gained control over certain processes.

Commands:
15.2. Sharing an Existing Desktop By default a logged in user has a desktop provided by X Server on display 0 . A user can share their desktop using the TigerVNC server x0vncserver . Procedure 15.5. Sharing an X Desktop To share the desktop of a logged in user, using the x0vncserver , proceed as follows: Enter the following command as root Set the VNC password for the user: Enter the following command as that user: Provided the firewall is configured to allow connections to port 5900 , the remote viewer can now connect to display 0 , and view the logged in users desktop. See Section 15.3.2.1, "Configuring the Firewall for VNC" for information on how to configure the firewall.

Commands:
~]# yum install tigervnc-server
~]USD vncpasswd Password: Verify:
~]USD x0vncserver -PasswordFile=.vnc/passwd -AlwaysShared=1
Part IV. Red Hat build of OptaPlanner quick start guides Red Hat build of OptaPlanner provides the following quick start guides to demonstrate how OptaPlanner can integrate with different techologies: Red Hat build of OptaPlanner on Red Hat build of Quarkus: a school timetable quick start guide Red Hat build of OptaPlanner on Red Hat build of Quarkus: a vaccination appointment scheduler quick start guide Red Hat build of OptaPlanner on Spring Boot: a school timetable quick start guide Red Hat build of OptaPlanner with Java solvers: a cloud balancing quick start guide

Commands:
3.6. RHEA-2011:1714 - new packages: mesa-libGLw New mesa-libGLw packages are now available for Red Hat Enterprise Linux 6. The mesa-libGLw packages provide an Xt/Motif OpenGL Drawing Area Widget. This enhancement update adds the esa-libGLw package to Red Hat Enterprise Linux 6. (BZ# 729243 ) All users who require mesa-libGLw are advised to install these new packages.

Commands:
10.2.4.8. PHP The configuration for PHP has been moved from httpd.conf into the file /etc/httpd/conf.d/php.conf . For this file to be loaded, the statement Include conf.d/*.conf must be in httpd.conf as described in Section 10.2.1.3, "Dynamic Shared Object (DSO) Support" . Note Any PHP configuration directives used in Apache HTTP Server 1.3 are now fully compatible, when migrating to Apache HTTP Server 2.0 on Red Hat Enterprise Linux 4.5.0;. In PHP version 4.2.0 and later the default set of predefined variables which are available in the global scope has changed. Individual input and server variables are, by default, no longer placed directly into the global scope. This change may cause scripts to break. Revert to the old behavior by setting register_globals to On in the file /etc/php.ini . For more on this topic, refer to the following URL for details concerning the global scope changes: http://www.php.net/release_4_1_0.php

Commands:
10.2. Viewing JBoss Data Virtualization Settings Using Management CLI To view all of the current settings for JBoss Data Virtualization, run the following command within the Management CLI: To view a particular JBoss Data Virtualization setting, run the following command within the Management CLI: For example: Note To view current translator and transport (including SSL) settings refer to Section 10.4, "Managing Transport and SSL Settings Using Management CLI" and Section 10.5, "Managing Translator Settings Using Management CLI" .

Commands:
/subsystem=teiid:read-resource
/subsystem=teiid:read-attribute(name= SETTING_NAME )
/subsystem=teiid:read-attribute(name=max-active-plans)
Chapter 7. Vault SPI 7.1. Vault provider You can use a vault SPI from org.keycloak.vault package to write custom extension for Red Hat build of Keycloak to connect to arbitrary vault implementation. The built-in files-plaintext provider is an example of the implementation of this SPI. In general the following rules apply: To prevent a secret from leaking across realms, you may want to isolate or limit the secrets that can be retrieved by a realm. In that case, your provider should take into account the realm name when looking up secrets, for example by prefixing entries with the realm name. For example, an expression USD{vault.key} would then evaluate generally to different entry names, depending on whether it was used in a realm A or realm B . To differentiate between realms, the realm needs to be passed to the created VaultProvider instance from VaultProviderFactory.create() method where it is available from the KeycloakSession parameter. The vault provider needs to implement a single method obtainSecret that returns a VaultRawSecret for the given secret name. That class holds the representation of the secret either in byte[] or ByteBuffer and is expected to convert between the two upon demand. Note that this buffer would be discarded after usage as explained below. For details on how to package and deploy a custom provider refer to the Service Provider Interfaces chapter. 7.2. Consuming values from vault The vault contains sensitive data and Red Hat build of Keycloak treats the secrets accordingly. When accessing a secret, the secret is obtained from the vault and retained in JVM memory only for the necessary time. Then all possible attempts to discard its content from JVM memory is done. This is achieved by using the vault secrets only within try -with-resources statement as outlined below: char[] c; try (VaultCharSecret cSecret = session.vault().getCharSecret(SECRET_NAME)) { // ... use cSecret c = cSecret.getAsArray().orElse(null); // if c != null, it now contains password } // if c != null, it now contains garbage The example uses KeycloakSession.vault() as the entrypoint for accessing the secrets. Using the VaultProvider.obtainSecret method directly is indeed also possible. However the vault() method has the benefit of ability to interpret the raw secret (which is generally a byte array) as a character array (via vault().getCharSecret() ) or a String (via vault().getStringSecret() ) in addition to obtaining the original uninterpreted value (via vault().getRawSecret() method). Note that since String objects are immutable, their content cannot be discarded by overriding with random garbage. Even though measures have been taken in the default VaultStringSecret implementation to prevent internalizing String s, the secrets stored in String objects would live at least to the GC round. Thus using plain byte and character arrays and buffers is preferable.

Commands:
char[] c; try (VaultCharSecret cSecret = session.vault().getCharSecret(SECRET_NAME)) { // ... use cSecret c = cSecret.getAsArray().orElse(null); // if c != null, it now contains password } // if c != null, it now contains garbage
Part I. Administering and Maintaining the Red Hat Virtualization Environment The Red Hat Virtualization environment requires an administrator to keep it running. As an administrator, your tasks include: Managing physical and virtual resources such as hosts and virtual machines. This includes upgrading and adding hosts, importing domains, converting virtual machines created on foreign hypervisors, and managing virtual machine pools. Monitoring the overall system resources for potential problems such as extreme load on one of the hosts, insufficient memory or disk space, and taking any necessary actions (such as migrating virtual machines to other hosts to lessen the load or freeing resources by shutting down machines). Responding to the new requirements of virtual machines (for example, upgrading the operating system or allocating more memory). Managing customized object properties using tags. Managing searches saved as public bookmarks . Managing user setup and setting permission levels. Troubleshooting for specific users or virtual machines for overall system functionality. Generating general and specific reports.

Commands:
3.9. Additional Resources Installed Documentation ip (8) man page - Describes the ip utility's command syntax. nmcli (1) man page - Describes NetworkManager 's command‐line tool. nmcli-examples (5) man page - Gives examples of nmcli commands. nm-settings (5) man page - Describes NetworkManager properties and their settings. nm-settings-ifcfg-rh (5) man page - Describes ifcfg-rh settings plug-in. Online Documentation Red Hat Enterprise Linux 7 Security Guide Describes IPsec based VPN and its configuration. Describes the use of authenticated DNS queries using DNSSEC. RFC 1518 - Classless Inter-Domain Routing (CIDR) Describes the CIDR Address Assignment and Aggregation Strategy, including variable-length subnetting. RFC 1918 - Address Allocation for Private Internets Describes the range of IPv4 addresses reserved for private use. RFC 3330 - Special-Use IPv4 Addresses Describes the global and other specialized IPv4 address blocks that have been assigned by the Internet Assigned Numbers Authority (IANA).

Commands:
Chapter 34. ExternalLogging schema reference Used in: CruiseControlSpec , EntityTopicOperatorSpec , EntityUserOperatorSpec , KafkaBridgeSpec , KafkaClusterSpec , KafkaConnectSpec , KafkaMirrorMaker2Spec , KafkaMirrorMakerSpec , ZookeeperClusterSpec The type property is a discriminator that distinguishes use of the ExternalLogging type from InlineLogging . It must have the value external for the type ExternalLogging . Property Description type Must be external . string valueFrom ConfigMap entry where the logging configuration is stored. ExternalConfigurationReference

Commands:
8.2. Moving Resources Due to Failure When you create a resource, you can configure the resource so that it will move to a new node after a defined number of failures by setting the migration-threshold option for that resource. Once the threshold has been reached, this node will no longer be allowed to run the failed resource until: The administrator manually resets the resource's failcount using the pcs resource failcount command. The resource's failure-timeout value is reached. The value of migration-threshold is set to INFINITY by default. INFINITY is defined internally as a very large but finite number. A value of 0 disables the migration-threshold feature. Note Setting a migration-threshold for a resource is not the same as configuring a resource for migration, in which the resource moves to another location without loss of state. The following example adds a migration threshold of 10 to the resource named dummy_resource , which indicates that the resource will move to a new node after 10 failures. You can add a migration threshold to the defaults for the whole cluster with the following command. To determine the resource's current failure status and limits, use the pcs resource failcount command. There are two exceptions to the migration threshold concept; they occur when a resource either fails to start or fails to stop. If the cluster property start-failure-is-fatal is set to true (which is the default), start failures cause the failcount to be set to INFINITY and thus always cause the resource to move immediately. For information on the start-failure-is-fatal option, see Table 12.1, "Cluster Properties" . Stop failures are slightly different and crucial. If a resource fails to stop and STONITH is enabled, then the cluster will fence the node in order to be able to start the resource elsewhere. If STONITH is not enabled, then the cluster has no way to continue and will not try to start the resource elsewhere, but will try to stop it again after the failure timeout.

Commands:
pcs resource meta dummy_resource migration-threshold=10
pcs resource defaults migration-threshold=10
Chapter 5. Diagnosing and Correcting Problems with GFS2 File Systems This chapter provides information about some common GFS2 issues and how to address them. 5.1. GFS2 File System Shows Slow Performance You may find that your GFS2 file system shows slower performance than an ext3 file system. GFS2 performance may be affected by a number of influences and in certain use cases. Information that addresses GFS2 performance issues is found throughout this document.

Commands:
28.5.2. Configuration Steps Required on a Client System Complete the following steps on every client system which will use the central management method: If you do not want to generate a backtrace, or if you decided to generate it on a server system, you need to delete or comment out the corresponding rules in the /etc/libreport/events.d/ccpp_events.conf file. See Section 28.5.1, "Configuration Steps Required on a Dedicated System" for an example of such a example. If you decided to not collect package information on client machines, delete, comment out or modify the rule which runs abrt-action-save-package-data in the /etc/libreport/events.d/abrt_event.conf file. See Section 28.5.3, "Saving Package Information" to find out whether you need to collect package information in your centralized crash collection configuration and how to configure it properly. Add a rule for uploading problem reports to the server system in the corresponding configuration file. For example, if you want to upload all problems automatically as soon as they are detected, you can use the following rule in the /etc/libreport/events.d/abrt_event.conf configuration file: EVENT=post-create reporter-upload -u scp:// user : password @ server . name /directory Alternatively, you can use a similar rule that runs the reporter-upload program as the report_ SFX event if you want to store problem data locally on clients and upload it later using ABRT GUI/CLI. The following is an example of such an event: EVENT=report_UploadToMyServer reporter-upload -u scp:// user : password @ server . name /directory

Commands:
EVENT=post-create reporter-upload -u scp:// user : password @ server . name /directory
EVENT=report_UploadToMyServer reporter-upload -u scp:// user : password @ server . name /directory
10.5.18. ServerAdmin Sets the ServerAdmin directive to the email address of the Web server administrator. This email address shows up in error messages on server-generated Web pages, so users can report a problem by sending email to the server administrator. By default, ServerAdmin is set to root@localhost . A common way to set up ServerAdmin is to set it to webmaster@example.com . Once set, alias webmaster to the person responsible for the Web server in /etc/aliases and run /usr/bin/newaliases .

Commands:
12.5.2. Adding an iSCSI Target to virt-manager This procedure covers creating a storage pool with an iSCSI target in virt-manager . Procedure 12.5. Adding an iSCSI device to virt-manager Open the host physical machine's storage tab Open the Storage tab in the Connection Details window. Open virt-manager . Select a host physical machine from the main virt-manager window. Click Edit menu and select Connection Details . Figure 12.19. Connection details Click on the Storage tab. Figure 12.20. Storage menu Add a new pool (part 1) Press the + button (the add pool button). The Add a New Storage Pool wizard appears. Figure 12.21. Add an iscsi storage pool name and type Choose a name for the storage pool, change the Type to iscsi, and press Forward to continue. Add a new pool (part 2) You will need the information you used in Section 12.5, "iSCSI-based Storage Pools" and Procedure 12.4, "Creating an iSCSI target" to complete the fields in this menu. Enter the iSCSI source and target. The Format option is not available as formatting is handled by the guest virtual machines. It is not advised to edit the Target Path . The default target path value, /dev/disk/by-path/ , adds the drive path to that directory. The target path should be the same on all host physical machines for migration. Enter the host name or IP address of the iSCSI target. This example uses host1.example.com . In the Source Path field, enter the iSCSI target IQN. If you look at Procedure 12.4, "Creating an iSCSI target" in Section 12.5, "iSCSI-based Storage Pools" , this is the information you added in the /etc/tgt/targets.conf file . This example uses iqn.2010-05.com.example.server1:iscsirhel6guest . Check the IQN check box to enter the IQN for the initiator. This example uses iqn.2010-05.com.example.host1:iscsirhel6 . Click Finish to create the new storage pool. Figure 12.22. Create an iscsi storage pool

Commands:
Chapter 14. Volume cloning A clone is a duplicate of an existing storage volume that is used as any standard volume. You create a clone of a volume to make a point in time copy of the data. A persistent volume claim (PVC) cannot be cloned with a different size. You can create up to 512 clones per PVC for both CephFS and RADOS Block Device (RBD). 14.1. Creating a clone Prerequisites Source PVC must be in Bound state and must not be in use. Note Do not create a clone of a PVC if a Pod is using it. Doing so might cause data corruption because the PVC is not quiesced (paused). Procedure Click Storage Persistent Volume Claims from the OpenShift Web Console. To create a clone, do one of the following: Beside the desired PVC, click Action menu (...) Clone PVC . Click on the PVC that you want to clone and click Actions Clone PVC . Enter a Name for the clone. Select the access mode of your choice. Important The ReadOnlyMany (ROX) access mode is a Developer Preview feature and is subject to Developer Preview support limitations. Developer Preview releases are not intended to be run in production environments and are not supported through the Red Hat Customer Portal case management system. If you need assistance with ReadOnlyMany feature, reach out to the ocs-devpreview@redhat.com mailing list and a member of the Red Hat Development Team will assist you as quickly as possible based on availability and work schedules. See Creating a clone or restoring a snapshot with the new readonly access mode to use the ROX access mode. Click Clone . You are redirected to the new PVC details page. Wait for the cloned PVC status to become Bound . The cloned PVC is now available to be consumed by the pods. This cloned PVC is independent of its dataSource PVC.

Commands:
probe::nfs.aop.writepage Name probe::nfs.aop.writepage - NFS client writing a mapped page to the NFS server Synopsis nfs.aop.writepage Values wsize write size size number of pages to be written in this execution i_flag file flags for_kupdate a flag of writeback_control, indicates if it's a kupdate writeback ino inode number i_size file length in bytes dev device identifier for_reclaim a flag of writeback_control, indicates if it's invoked from the page allocator __page the address of page sb_flag super block flags page_index offset within mapping, can used a page identifier and position identifier in the page frame i_state inode state flags Description The priority of wb is decided by the flags for_reclaim and for_kupdate .

Commands:
Chapter 9. Using the AMQ Interconnect web console to monitor the router network You can use the AMQ Interconnect web console to monitor the status and performance of your router network. By default, when you create a router deployment, the AMQ Interconnect Operator generates the credentials to access the console and stores them in a Secret. Procedure In OpenShift, switch to Networking Routes , and click the console Route. The web console opens in a new tab. To connect to the web console, complete the following fields: Port Enter 443 . User name Enter the user name. To find the user name and password for accessing the web console, navigate to Workloads Secrets . The Secret containing the web console credentials is called < application-name >-users (for example, router-mesh-users ). The syntax for the user name is < user >@< domain > (the domain is the OpenShift application name, which is the name of the Custom Resource that describes the router deployment). For example, guest@router-mesh . Password Enter the password defined in the < application-name >-users Secret. Click Connect . The Routers page is displayed showing all of the routers in the router network. Use the web console tabs to monitor the router network. This tab... Provides... Overview Aggregated information about routers, addresses, links, connections, and logs. Entities Detailed information about each AMQP management entity for each router in the router network. Some of the attributes have charts that you can add to the Charts tab. Topology A graphical view of the router network, including routers, clients, and brokers. The topology shows how the routers are connected, and how messages are flowing through the network. Charts Graphs of the information selected on the Entities tab. Message Flow A chord diagram showing the real-time message flow by address. Schema The management schema that controls each of the routers in the router network. Revised on 2020-11-23 18:32:57 UTC

Commands:
Chapter 1. Disaster scenarios in IdM Prepare and respond to various disaster scenarios in Identity Management (IdM) systems that affect servers, data, or entire infrastructures. Table 1.1. Disaster scenarios in IdM Disaster type Example causes How to prepare How to respond Server loss : The IdM deployment loses one or several servers. Hardware malfunction Preparing for server loss with replication Recovering a single server with replication Data loss : IdM data is unexpectedly modified on a server, and the change is propagated to other servers. A user accidentally deletes data A software bug modifies data Preparing for data loss with VM snapshots Preparing for data loss with IdM backups Recovering from data loss with VM snapshots Recovering from data loss with IdM backups Managing data loss Total infrastructure loss : All IdM servers or Certificate Authority (CA) replicas are lost with no VM snapshots or data backups available. Lack of off-site backups or redundancy prevents recovery after a failure or disaster. Preparing for data loss with VM snapshots This situation is a total loss. Warning A total loss scenario occurs when all Certificate Authority (CA) replicas or all IdM servers are lost, and no virtual machine (VM) snapshots or backups are available for recovery. Without CA replicas, the IdM environment cannot deploy additional replicas or rebuild itself, making recovery impossible. To avoid such scenarios, ensure backups are stored off-site, maintain multiple geographically redundant CA replicas, and connect each replica to at least two others.

Commands: